抖动破坏对系统的预期建模
别名: 内部模型崩溃 · 不可预测响应 · predictive model of latency
概念解释
用了几次之后，人会在脑子里给系统建一个响应模型：「保存大概这么久，搜索大概这么久，拖动几乎不晚」。下一步动作会按这个模型预瞄——手已经伸向下一键，眼睛已经看向下一项。抖动破坏的是这个模型，不只是某一拍的舒适。模型一垮，预瞄全部作废，人从流畅的序列退回逐步确认：点一下，看一下，再决定要不要点下一步。
上一条说抖动比稳定的慢更难受。这一条说难受从哪来：来自内部模型没法再拿来做预测。
机制
熟练操作是开环加偶尔校正。开环依赖对延迟的点估计。抖动让点估计的误差大到开环不敢用，控制策略切到闭环：每一步都等可视确认。闭环安全，但吞吐下降，也更累。人还会做错误归因：模型崩溃时，会怀疑「是不是没保存上」「是不是点错了」，于是重复操作、重复检查。这些行为看起来像需求不清，其实是预测失效后的防御。
模型是按入口分别建的。保存稳、搜索抖，人不会把搜索的不可预测推广成整站不可信——但会把搜索这个入口从「可连点」降级成「每次都要盯」。一个入口的模型崩溃，污染的是那条任务路径，不一定是品牌。
怎么研究
先让人在稳定延迟下练到能盲点下一步（手已经提前伸向下一控件），再在同一入口加入抖动，看开环序列是否断裂。
自变量：延迟从稳定切到抖动的时机、抖动是否只发生在某一个入口。 因变量：提前伸手或预瞄注视是否消失、逐步确认（点-看-点）的比例、错误重试与重复检查。
练习不足时，人本来就没有模型，抖动看不出破坏——实验必须先看到稳定条件下的预瞄，再引入抖动。
边界
一次性向导、首次使用没有可破坏的模型。专家用户的模型更细，也更脆：同一快捷键有时 30 毫秒有时 300 毫秒，会直接打断自动性。网络切换（Wi-Fi 到蜂窝）造成的一次性跳变是环境变化，人可以重建模型；同一网络下无规律的跳变才是模型无法重建。动画时长若每次都按内容长度变，也会被当成抖动，即使底层延迟稳定。
怎么落地
- 同一入口的响应时延要对用户可学习：不要这一次走缓存 40 毫秒、下一次走全量 800 毫秒还假装是同一种「保存」。
- 若快慢两条路径必须并存，用状态把它们分成两种操作（「已保存」对「正在同步到服务器」），让人建两个模型，而不是一个失灵的模型。
- 观察熟练用户是否还在盲点。不再盲点、开始每步盯着看，就是模型已经垮了。
- 验证：让熟练用户连续完成一条熟路径。中途只对其中一个入口注入大幅抖动。看这条路径是否从一气呵成变成逐步确认，以及其他入口是否仍被流畅使用。