中断时机应选在子任务边界

概念解释

同一个中断放在不同时刻，代价不一样。放在一个子任务边界——一小段工作刚好完成、下一段还没开始的间隙——恢复代价最低；放在子任务执行到一半的地方，恢复代价明显更高。这条讲的是"为什么边界更便宜"，是恢复代价本身推导出的一条结论，而不是一套挑选边界的操作方法。

机制

恢复代价的大头来自重建被中断打断的目标状态：还有哪些子步骤没做完、上一步做到哪、中间结果放在哪。子任务边界之所以便宜，是因为这些需要重建的东西在边界处几乎是空的——上一个子任务已经完整交付了结果，没有半成品的中间状态需要维持，下一个子任务还没开始，也没有已投入但未完成的进度。中断发生在这个真空点上，工作记忆里没有正在悬置的半成品需要保护，恢复时只需要确认"接下来该开始哪一个子任务"，不需要倒回去拼凑一个被打断在中途的状态。

如果中断落在子任务内部，情况完全不同：这个子任务的中间状态（已经比较到第几项、已经算到哪一步）此刻还完全依赖工作记忆维持，中断一来，这部分状态要么被中断任务覆盖，要么因为工作记忆容量有限被冲淡，恢复时必须重新构建这个中间状态才能继续——这正是恢复代价里最贵的那部分。子任务边界省掉的，就是这部分重建。

怎么研究

研究这条常沿用中断—恢复范式，专门操纵中断发生的相对位置：把同一个多步骤任务分成若干子任务，让中断分别落在子任务之间的边界处和子任务内部的中途，其余条件（中断时长、中断内容）保持一致，比较两种位置下恢复后的反应时代价与错误率。

常见自变量：中断相对子任务边界的位置、子任务本身的长度与复杂度。 常见因变量：恢复后的反应时增量、错误率、是否出现子任务内部状态被记错的情况。

这套操纵在人机交互里常用来为"系统该在什么时候弹出中断类提示"提供直接证据——比较边界处打断与任意时刻打断的代价差异，量化"选对时机"能省下多少恢复成本。

方法论注意点：这条结论只回答"边界为什么更便宜"，不回答"如何在真实使用中识别边界"——真实任务的边界往往不像实验室任务那样有清晰的完成标记，识别边界本身是一个需要单独处理的问题。

边界

• 前提是"子任务"本身有清晰的完成标志。 如果任务步骤之间没有明确的完成点（比如连续的自由写作），边界处与非边界处的代价差异会缩小，因为很难界定哪里算真正的空隙。
• 边界处的代价优势只针对"重建目标状态"这一部分。 恢复代价里靠记忆才能补上的另一部分——记得自己还欠着一件被中断打断的次要任务——不会因为选在边界打断而消失，这部分代价是独立的。
• 过于频繁地利用边界打断，会让边界本身失去保护作用。 如果每完成一个子任务就被打断一次，用户会不断在"完成—重新启动"之间切换，边界虽然单次代价低，累积起来仍然可观。
• 这条只回答为什么边界更便宜，具体在真实任务流里如何找到边界、有几种粒度的边界可用，是需要单独展开的问题。

怎么落地

• 在设计需要主动打断用户的功能（弹窗提示、系统通知的强制展示）时，优先检测用户是否处于两个子任务之间的空隙，而不是在任意时刻触发——即使只是简单判断"当前有没有未提交的操作、有没有正在编辑的字段"，也能过滤掉大部分高代价的中途打断。
• 对分步骤的任务流（表单、向导式操作），把每一步的完成作为潜在的安全打断点，因为这些点上用户的中间状态天然是"空"的，不需要额外机制去保护。
• 无法判断用户是否处于边界时，宁可延迟打断，也不要在不确定的时刻强行插入——延迟带来的代价通常小于打断在子任务中途造成的重建代价。
• 验证办法：记录同一类中断分别发生在边界处与子任务中途时，用户恢复主任务的反应时与错误率差异；差异越大，说明当前系统在选择打断时机上越需要优化。

延伸

• 同组：A5.08.2 系统应保留中断前的状态与位置 · A5.08.3 恢复原任务前存在可测量的恢复滞后，绩效不会瞬间回到中断前水平 · A5.08.4 恢复成本包含重新执行主任务与记住被中断任务两部分，需分别核算 · A5.08.5 自我发起的中断比外部强加的中断恢复成本更低 · A5.08.6 中断内容与原任务共享信息越多，恢复所需的重建工作量越大
• 相邻：A5.14 中断的时机与打断点（边界的粒度划分、通知合并策略、免打扰时段等具体打断时机策略）
• 站内检索：subtask boundary · natural breakpoint · interruption timing · task resumption