恢复原任务前存在可测量的恢复滞后，绩效不会瞬间回到中断前水平
别名: interruption cost · task resumption · 恢复滞后 · resumption failure
概念解释
任务被打断后重新回到原任务，人不会立刻恢复到中断前的表现水平——从重新开始动手到恢复正常速度与准确率之间，有一段可以被测出来的延迟，叫恢复滞后（resumption lag）。这段滞后是中断代价里最容易被低估的部分，因为它不发生在中断的那一刻，而发生在中断结束之后。
它和"中断打断了操作"是两回事。中断本身造成的停顿一眼就能看到；恢复滞后是停顿结束、人已经重新开始动手之后，仍然存在的那段隐性代价——表现为反应变慢、更容易出错，肉眼不一定能察觉。
机制
任务执行依赖工作记忆里维持的一套目标状态：现在在做什么、下一步该做什么、已经完成到哪一步。中断发生后，这套状态要么被清空、要么被新任务的目标状态部分覆盖。恢复原任务时，这套状态不会瞬间重建，而是需要重新激活——回忆刚才停在哪一步、重新确认接下来的操作顺序、把散落的中间结果重新拼回工作记忆。
这个重新激活的过程本身消耗时间和认知资源，在此期间执行速度和准确率都会低于中断前的稳定水平，直到状态重建完成才恢复正常。滞后的长度取决于原任务目标状态的复杂程度——步骤越多、依赖关系越复杂，需要重建的内容越多，滞后也越长。
怎么研究
标准做法是中断—恢复范式：让被试执行一个多步骤的主任务，在某个环节插入一次次任务，之后回到主任务，比较恢复后紧邻若干步骤与中断前基线步骤的反应时和错误率差异。
常见自变量：中断的时长、中断任务与主任务的相似程度、中断发生的位置（是否在子任务边界）。 常见因变量：恢复后前几步的反应时相对基线的增量、恢复后的错误率、恢复到基线水平所需的步骤数或时间。
这套范式在人机交互里常用来评估通知与打断类设计对生产力任务的实际代价——不能只统计中断本身占用的时间，因为那只是代价的一部分，恢复滞后往往比中断本身耗时更长。
方法论注意点：实验室任务通常步骤明确、边界清晰，真实工作任务的目标状态更复杂、更依赖长期记忆而非工作记忆，实验室测出的滞后值大概率低估真实场景。
边界
- 滞后的存在不依赖中断时长。 哪怕中断本身只有几秒钟，恢复滞后依然会出现，因为决定滞后大小的是目标状态需要重建的程度，不是中断占用的绝对时间。
- 训练和经验能缩短滞后，但不能消除。 对同一类任务反复练习后，重建目标状态的速度会提高，但只要存在被打断的目标状态，滞后的结构性存在不会消失。
- 原任务本身很简单、目标状态几乎不需要维持时，滞后会小到难以测量——这不是效应不存在，而是待重建的内容本来就少。
- 这条只讲恢复过程本身存在滞后，不涉及滞后的构成是什么、由哪些调节因素决定，那些是恢复代价的另外两层。
怎么落地
- 不要用"任务已经完成"或"用户已经回到原界面"作为交互设计里判断中断影响已经结束的依据——恢复滞后发生在这些时间点之后，界面层面看不出用户仍处在滞后期。
- 在高频被打断的工作流里，为恢复阶段预留缓冲：比如恢复后的头几步给出比平时更宽松的容错（撤销窗口、二次确认），因为这几步的错误率结构性偏高。
- 减少需要重建的目标状态复杂度：把多步骤任务拆解成粒度更小、每一步都能独立确认完成状态的单元，恢复时只需要定位到哪一步，而不需要从头推演整个流程。
- 验证办法：记录用户在完成一个多步骤任务过程中被打断后，重新开始的前几步与该任务无中断基线的反应时和错误率对比，滞后的存在与长度可以直接由这个对比量化出来。