未完成事项与异常需显式记录
别名: 未完成事项跟踪 · open-loop items
概念解释
未完成事项与异常是尚未闭合的工作回路（open-loop items），必须显式记录责任人、状态和下一检查点。它和态势叙述不是一回事——态势交接讲的是"系统现在处于什么状态、为什么"，这里讲的是"有哪些具体的事还没做完、谁该继续做"。依赖口头记忆传递这类条目，会让跨班次、多人协作中的未决风险悄然消失，尤其是那些当时看起来不紧急、后来才显出后果的项目。
机制
未完成工作占用的是离班者的前瞻记忆（prospective memory）——"稍后要做某件事"这类意图在心理学上本就比记住已发生的事更容易被打断和遗忘，接班者又完全没有这条记忆线索可用。持久记录把"稍后要做"变成一份共享的外部状态，理论上不再依赖任何人的大脑。
但记录存在不代表风险消失。如果条目只写了一句描述而没有责任人、期限或解除条件，它在阅读者眼里仍然只是一段背景文字，不是需要行动的任务——这时候记录形式没变，但它已经从"外部记忆"退化回了"文档"。另一个失效方向是条目数量：如果不加区分地把所有观察都记成待办，接班者每次接班都要扫一遍越滚越长的清单，真正有风险的那一条被淹没在大量低价值条目里，效果和完全不记录相差不大——所谓"显式记录"要求的不是记得多，而是记得对，条目和责任要一一对应。
和一次性异常相比，跨越多个班次仍未处理完的事项更容易在传递链条变长后失真——每转述一次都可能丢掉一点上下文，持久记录之所以有效，正是因为它不像口头转述那样随传递次数增加而衰减。
怎么研究
可以审计交接记录与后续班次日志，统计未决项遗漏、逾期未处理和错误关闭这几类失效各自的比例；仿真实验里可以操纵记录结构（有无责任人字段、有无关闭证据要求），测接班者能否发现条目并把工作接续下去。研究上要区分"真正完成"与"仅被标记完成"——后者的具体做法是把记录上的关闭时间戳，对照当时的设备状态或过程日志核实，看动作是否真的发生过，而不是只看勾选框。
边界
不是所有观察都应该进高优先级待办：把每一次巡检中的细枝末节都当成任务记录，会造成清单本身的信息过载，效果类似报警过多导致的注意力分散——过量的低价值条目反而掩盖了真正需要接续处理的那一项。敏感的维护信息可能出于权限管理原因限制查看范围，但这个限制不能延伸到真正的责任接班人身上——如果接班的责任人看不到与自己职责相关的未决项，记录系统本身就失去了意义。另外，"记录了"和"记录得及时"是两回事：如果异常发生后拖到快下班才补记，接班者拿到的时间窗口信息本身就是失真的。还要划清一条边界：设备自动生成的报警和操作日志不需要重复誊抄进交接记录里，显式记录该覆盖的是靠人工判断才能发现、系统不会自动留痕的那类事项——把自动记录也搬进来只会让清单更长，稀释掉真正需要人工接续的条目。
怎么落地
每条记录至少包含：对象、风险描述、责任人、下一步动作、下次检查时间、关闭所需的证据类型；状态一旦变化就追加记录而不是覆盖旧值，保留完整的时间轴。交接时逐项确认所有权，而不是笼统地问"有没有要交代的"；接班者对每一条都要明确表态"接手"还是"需要说明"。验证办法：定期抽样已标记关闭的条目，把关闭时间戳与对应的设备读数或过程日志逐一核对，凡是关闭记录早于实际状态变化时间点的，都算作虚假关闭，纳入下一轮培训或流程整改的依据。