人重建情境所需的时间是硬约束，不能被压缩为零

概念解释

协议里可以安排预告，界面可以把摘要做得更短，但人把要素收成理解、再收成预测，需要的最小时间不会被这些手段消成零。情境重建时间是硬约束（SA rebuild time is a hard constraint）：它是认知过程的下限，不是动画时长，不是倒计时数字。

把接管倒计时从五秒改成两秒，省下的是等待，不是重建。

机制

知觉、理解、预测是串行的加工，每层都要吃数据。摘要再好，也要被读；因果再清楚，也要被纳入当前模型。阅读速度、注意切换、从回路外把模型热启动，都有生理和认知下限。驾驶接管文献把「可接管时间」当成车辆设计的输入，而不是当成可以靠 UI 优化刷掉的延迟。代理产品常把同一下限当成摩擦来消灭，于是用更短的模态、自动代为确认、超时默认接管来「加速」。加速的是流程时钟，不是人的模型。

硬约束的含义是：任务如果给不出这段下限，就不该把人设计成这一拍的执行者。该改的是自动化层级或急停策略，不是倒计时。

怎么研究

把预告和摘要质量做到你们认为的最优，再系统缩短可用时间，看正确干预何时崩溃。自变量：可用时间（从预告到必须动作）、摘要是否已优化、任务复杂度。因变量：正确第一拍的比例、SA 探询得分、主观「我还没看完」。

要找的是崩溃点，不是平均成绩。崩溃点不随界面变漂亮而明显右移，就是硬约束在说话。跨个体差异很大，设计得按最慢仍可接受的那一端，而不是按中位数。

边界

人一直在回路里、模型本来就是热的，下限会短很多，甚至短到一次扫视。对象极少、失败模式极熟的专家，下限也短，但不能把专家下限写进给新人的产品。急停不要求人在下限内完成理解，只要求人完成一个事先编码的动作。协议要不要安排窗口，是另一条；这里说的是窗口再安排，也不能排成零。

怎么落地

• 用真实材料测崩溃点：最优摘要下，人还需要多久才能做出正确第一拍。把这个值写成产品约束，不许被倒计时或超时默认击穿。
• 给不出这段时间的任务，不要设计成人必须在这一拍接管执行；改成系统按安全默认停住，等人自己宣布准备好。
• 验证：把可用时间减到崩溃点以下，正确第一拍应显著变差。若变差而产品仍在用这个时间，就是在用流程时钟冒充认知时钟。崩溃点不随文案缩短而消失，才算测到了硬约束。

延伸

• 同组：L4.04.1 移交需要充分的情境重建时间 · L4.04.2 移交时的系统状态需完整交代 · L4.04.3 突然移交是最危险的形式 · L4.04.4 移交质量取决于交出方是否交代了为什么会走到当前状态 · L4.04.6 系统在失去把握时才移交，而那正是情境最复杂的时刻 · L4.04.7 移交后责任立即转移，这一转移应由接管者确认而非默认成立 · L4.04.8 反向移交同样需要设计，人交回系统时须说明自己改变了什么
• 相邻：L1.05 人在回路 · L4.09 技能退化 · L4.01 自动化层级
• 站内检索：takeover time · situation awareness · hard constraint