响应时间三界：三层时钟，和 trigger 到结果之间的中间态
它是干嘛的。 决定一次交互要多快才算跟手、慢了该拿什么顶上，让等待时间是设计出来的，不是硬熬过去的。
三个界（Nielsen 1993）。 0.1 秒感觉是瞬时的；1 秒思路不断；10 秒是没人喂信息时注意力能撑的极限。每档差 10 倍：0.1，1，10。这是人身上三层不同的钟，不是同一把尺上的三个点：0.1 秒是感知，1 秒是思路，10 秒是注意力。
数从哪来。 0.1 秒来自 Model Human Processor（Card、Moran、Newell 1983）里约 100 毫秒的感知周期：反馈在这个窗口内到，大脑直接把它算成你自己动作的结果，东西感觉就在手里动；超过这个窗口，用户就感觉到是系统在事后反应。1 秒是脑子里一个念头不靠外力能不断线撑多久。10 秒是没人喂信息时注意力能盯着一件事多久。这些是量出来的经验规律，不是定理：没法从第一性原理推出来，只能测，数字本身带着实验的浮动。
Doherty 阈值 400 毫秒（Doherty 和 Thadhani 1982）。 IBM 当年实测：系统响应压到 400 毫秒以下，人的产出不是线性涨一点，而是跳涨一大截。400 毫秒以内，人根本不进入“等”的状态，一直保持连续工作的节奏；一过，人就开始等、切出去，节奏碎了。400 毫秒落在 0.1 到 1 秒之间，是工程上的甜点：处处做到 0.1 秒没必要，压进 400 毫秒就已经拿到了大部分收益。
trigger 到结果之间的中间态。 数字本身很薄，知道了就是知道了。深的地方是感知可以被工程操纵：从 trigger 到最终结果，中间可以插状态，制造出跟手的假象。三种，骗的是不同的钟：
- 确认态：按钮先变色、圈选先高亮、转圈先出来。骗的是 0.1 秒的因果钟：用户要的不是结果，是“系统听见我了”。
- 渐进态和流式态：骨架屏、先出结构后填内容、token 一个一个往外蹦。骗的是 10 秒的注意力钟：每来一点新信息，注意力就重新锚一次，钟就重拨一次。
- 乐观态：最终结果先显示出来，事后再慢慢对账，像点赞先变红、消息先出现在聊天框里，服务器确认是后面的事。赌的是绝大多数操作都会成功，所以根本不用等。
中间态的规矩。 每个中间态必须一直往前走、不能跟最终结果打架。进度条倒回去、骨架屏一直不填内容、乐观更新被当众撤回，假象一破，比老实等着更糟。还有个上限：中间态只能买时间，不能变出时间。最终结果要 30 秒，插什么都没用，那就得改结构，让它后台跑、好了再通知你。
阶梯形状本身就是资源分配原则。 收益是悬崖形的，不是线性的，所以 600 毫秒压到 400 毫秒，比 400 毫秒压到 200 毫秒值钱得多：前者是跨过悬崖，后者只是在平地上磨。这直接决定优化力气花在哪。
实测：Lucerna 阅读页。 点词出释义是本地数据，目标就是 0.1 秒，至少不能超过 400 毫秒的 Doherty 阈值，不然读者读句子的思路就断了。圈选后的 AI 文案做不到快，那就得全套编排：1 秒内先给反馈（高亮、转圈、“正在想”），token 流式输出让注意力不断重新锚住，超过 10 秒就得给进度、最好允许用户继续往下读，骨架屏先把版式占住。
Transfer。 这三层钟管着 fitts-law 和 hicks-law 地盘上的每一次交互：Fitts 定目标大小，Hick 定选项多少，这三个界定等待多久。点得快、选得快的顶栏，答案来得晚，照样栽在钟上。
给 agent 的检查清单。读完本节点，按每一条去验界面，验出结果要带证据。
- 量出这次交互的真实延迟分布（p50、p95），不是最好情况，写明它落在哪个钟下面。
- 跨了钟的话，该用哪种中间态：确认态、渐进或流式态、还是乐观态？
- 每个中间态是不是一直往前走、跟最终结果一致？写明哪个状态可能跟结果打架。
- 加了中间态还超过 10 秒的活，是不是改成了后台跑加通知？
- 优化力气花在哪：哪次跨越是跨悬崖，哪次只是在平地上磨？