打断后返回容易丢步，需保留进度位置
别名: 恢复延迟 · 断点续做 · task resumption failure
概念解释
一个多步序列被打断后，回来继续做的那一刻是遗漏最容易发生的时间点：当事人必须靠纯粹的记忆重建「我刚才做到哪了」，如果重建不完整或出了偏差，续做时就可能从错误的位置接上，跳过某些自己以为已经做完、实际没做的步骤。这个现象的核心不是「忘了整件事」，而是恢复延迟（resumption lag）——重新进入任务状态本身需要时间和认知资源，这段过渡期正是丢步风险最集中的窗口。
机制
进行中的任务在大脑里维持着一份「问题状态」——目标是什么、已经做到哪、下一步是什么。打断发生时，这份状态失去了外部支持，只能悬置在记忆里；打断持续得越久、打断期间处理的信息越多，这份悬置状态被覆盖或模糊的概率就越高。恢复时，当事人需要重新调取这份状态才能准确判断下一步该做什么；如果调取只成功了一部分——比如记得任务的大致目标，却记不清具体做到哪一步——续做的位置就会出现偏差，某些步骤要么被误判为已完成而跳过，要么被重复执行。
怎么研究
研究这个现象的常见做法是在多步任务的不同节点上人为插入打断，事后测量参与者恢复到正确执行状态所需要的时间（恢复延迟），以及恢复后续做位置是否准确。这类实验里一个稳定的发现是：打断插入在一个子目标刚完成、下一个子目标还没开始的边界处，比插入在一个步骤执行到一半时造成的干扰更大——边界处的问题状态更容易被误判为「已经清空」，反而更容易丢步；另外，如果恢复时能看到外部的检索线索，恢复延迟和续做错误都会明显下降。
边界
这个效应的强弱取决于打断的长度和任务的熟练程度——非常短的打断，或者高度熟练到几乎不需要维持问题状态的任务，受打断的影响很小；只有当打断长到足以让问题状态被覆盖，或者任务本身还需要主动维持问题状态时，恢复延迟才会明显转化为丢步。另外，外部线索只在恢复的那一刻真正被看到才有效——把进度记录写进日志里但恢复时不主动展示，等于没有线索，用户不会为了找线索而先去翻记录。
怎么落地
把当前进度位置持久化保存，并且在用户中断后返回时主动展示出来，而不是要求用户自己回忆或去翻找——具体做法可以是高亮当前应该继续的字段、显示一条面包屑式的步骤轨迹，或者直接把光标/焦点恢复到中断前的位置，且这个状态要能扛住应用被切到后台或页面被关闭再打开。验证办法：设计测试时故意在任务中途插入模拟打断（比如一条通知或切换页面），打断后观察参与者恢复时是否准确接续到正确步骤，还是出现跳步或重复；对比有进度提示和没有进度提示两种条件下的续做准确率。