L4.13.5later escalation means longer replay设计研究
求助时机越晚，人需要回溯的执行历史越长
别名: 晚求助历史长 · reconstruction cost grows with delay · 早上报
概念解释
从第一次做不到，到人看见，中间每多留一拍，历史就多一截：多一次重试、多一次改道、多一个被改过的对象。人要把情境重建到能处理缺口，必须把这一截走完。越晚求助，回溯越长（later escalation means longer replay）把上报时钟当成重建成本的控制器：早，缺口短、残骸少；晚，接管变成读史。
压缩成三栏能减轻阅读，消灭不了已经发生的步。晚的代价在世界上，不在文案上。
机制
情境重建时间是硬约束，输入量是历史长度。晚上报把输入量单向加大：重试写入更多事件，近似可能已把错误成品交出去，部分完成的清单更长。人不是不能处理晚的上报，是处理所需的窗口按历史涨，而产品给接管的窗口往往仍按「刚失败」来开。这和重试推迟人看见是同一条链的两端：推迟是时钟，长度是时钟走完之后桌上的纸。
早上报不是催人，是把重建锁在第一次失败附近。
怎么研究
把上报延迟设为首次失败后 0、k 次重试后、任务超时后。因变量：人重建到能正确处理的时间、读过的步骤数、误伤已做步骤的次数、主观「我在读史」。自变量：上报包是否已压缩成缺口、过程视图是否默认展开到失败点。
重建时间应对延迟回归。压缩文案若几乎不降低重建时间，说明成本在事件量上，不在叙述上。
边界
瞬时故障的有限重试会引入很小的延迟，只要事件量仍短、且可见，重建成本可接受。已经对外造成不可逆后果时，晚不只是长，是世界已经变了，重建窗口再长也补不回。缺口怎么写、清理清单怎么附，减轻的是读，不是事件本身。突然移交叠加在晚上报上会更糟，但突然是时序惊吓，这里是量。
怎么落地
- 把「首次做不到 → 人看见」写成时限，时限内允许的只是瞬时重试。时限一到必须上报，不管内部还想试。
- 晚到的上报默认把过程视图停在第一次失败点，而不是停在最后一次重试，减少从末尾往回翻。
- 验证：对比首次失败立即上报与超时才上报的重建时间。后者显著更长，时钟就在制造读史。把时限收到首次持久失败，重建时间应跟着掉——掉了，晚就是原因，不是人读得慢。