I4.07.2freshness expectation from content type设计
用户对实时性的预期取决于内容类型而非系统实际能力
别名: 按内容类型预期 · expected freshness · 不是按能力预期
概念解释
人觉得行情该跳、邮件列表可以停在打开那一刻、百科可以停在上一次编辑，这些预期在碰这套系统之前就已经带着。预期取决于内容类型，而不是系统实际能力：做了推送，不会让人把帮助文档当成行情；没做推送，也不会让人接受聊天晚一分钟。能力可以高于或低于预期，体验的对错按预期算，不按能力算。
机制
内容类型在日常里已经训练过「它该不该自己动」。报价、在线状态、未读角标，被编成活的；文章、说明书、已完成的订单快照，被编成静的。这套分类来自对象在世界里的变化方式，不是来自某个产品用了什么通道。打开一个界面，人先按类型套模型，再看它动不动。动得比模型勤，会被当成闪、当成吵；动得比模型慢，会被当成坏了。
能力一旦拿来当借口，就会出现两种错配。能力很强、内容是静的：文档标题在人阅读时自己换成最新版，模型被打破。能力很弱、内容是活的：对话还显示「正在输入」的上一分钟，人开始手动刷新。错配的修复是改这块的节拍去贴类型，或改类型的呈现去贴节拍（明确说这是延时报价），不是再堆通道。
边界
新出现的类型还没有稳固预期（某类 AI 生成状态、某类协作画布），不能直接套「该静」或「该跳」，要在产品里把模型说出来。同一种对象在不同任务里类型会变：股票在交易屏是活的，在年报里是静的快照。跨文化、跨行业的「多快算活」不一样，体育比分和银行余额都「该新」，但可接受的延迟差出一个数量级。预期会被上一次使用教出来——一个产品若长期把静的东西做得很跳，人会把跳当成这类的默认，换到别的产品时会短暂错位。
怎么落地
- 按内容类型（活的状态 / 进行中的会话 / 文档 / 快照 / 报表）列出人带来的新鲜度模型，再对照实际节拍，找「比模型勤」和「比模型慢」两列。
- 活的类型跟不上预期时，优先改节拍或明示延迟，不要用「后台其实已经是最新」来辩护。
- 静的类型不要因为通道闲着就自动刷新正文；刷新应是进入、手动、或版本提示。
- 验证：把一段聊天故意延迟到明显慢于「对话」模型，人应开始下拉或抱怨，即使状态栏写着已连接。把一篇正在读的帮助文在眼皮下换成新版，人应感到被抢走，即使技术上那是更新。两列都要能复现。