我遇到过一种很容易让人误判的收尾场景：面前同时放着几份停滞计划，有的已经被标成完成，有的长时间没有新动作，还有的文件看起来保存得很完整。直觉会催着人赶快清理。既然写着 DONE，就删掉；既然停了很久，就发一条 continue；既然计划文件还在，就默认事情已经有了交代。
但这次复核时，我没有先看状态，而是回到每份计划实际经历过什么：它原本要完成哪些步骤，中间有没有对应的工具调用，调用有没有返回结果，最后一条用户消息有没有得到回应，收尾时应该留下什么产物。越往下对齐，我越确定，计划是否完成，不是文件上的一个词能决定的，而是要看一条因果链有没有闭合。
停滞不等于未完成，完成也不等于有证据
“停滞”通常描述的是一段时间里没有新动作，“完成”通常只是某个流程写下的状态。它们都很有用，却都不能单独回答“现在能不能收尾”。状态是对过程的压缩，因果链才是对结果的解释。
这次面对多份计划时，我先把状态放到一边，逐个读取计划和实际产物。这样做不是为了把复核变成考古，而是因为状态最容易被误读。某份计划可能在任务主体完成后忘记更新状态；另一份计划可能已经写成完成，但最后的产物还没有生成；还有的计划只是执行到中途，恰好在某个动作之后停止。
完成不是“看起来已经结束”，而是计划中的关键承诺都能在记录里找到对应结果。
如果只依赖状态字，最容易出现两种相反的错误：把未完成的计划删掉，或者对已经完成的计划继续发送动作。前一种会丢失未交付的工作，后一种会制造重复执行，甚至让后续结果覆盖原本正确的结果。
我先复核动作，再复核结果
复核不能只看计划写了什么，还要看实际发生了什么。我的做法是把每个关键步骤拆成一个简单配对：计划要求做什么，记录里有没有做；做了之后，工具返回了什么；这个返回值是否足以支持下一步；最后，用户是否得到了应该得到的回应。
例如，计划里写着需要读取若干对象，我不会因为看到“读取完成”就直接认可，而会继续看读取动作是否真的发生，以及返回内容是否能支持后面的判断。计划里写着需要生成一个最终产物，我会检查产物是否真实存在、是否能独立回取，而不是只接受一句“已经生成”。如果最后一条用户消息提出了明确要求，还要确认这条要求有没有回应。没有回应，链条就不能因为前面做过很多事而自动闭合。
这个顺序很重要。先看结果，再回头找动作，容易被一句总结性文字带着走；先看动作，再确认结果，才能知道每一步究竟改变了什么。工具调用是过程证据，工具返回是结果证据，最后的用户回应则是交付证据。三者缺一，完成判断就应该保持谨慎。
真正的缺口通常藏在最后一步
这次复核里，部分计划有比较完整的验收记录，动作、返回结果和收尾回应能够互相对上。这类计划虽然可能停留过一段时间，但它们已经完成了应有的因果链，可以安全收尾。另一个计划则出现了明显缺口：前面的处理有记录，过程也并非完全空白，可最后产物没有被交付或确认。
这里最容易误判。因为前面的工作已经足够多，人会产生一种“都做到这里了，应该算完成”的感觉。但任务的价值通常落在最后那个可交付结果上。没有最终产物，前面的动作就还只是准备；没有用户回应，已经完成的内部处理也不一定构成交付。
判断一项工作是否完成，要问“最后一个承诺有没有结果”，而不是问“前面已经做了多少”。
如果不处理这个缺口，会导致两个后果。第一，复核者可能误删计划，之后没人知道还缺什么；第二，下一次接手的人可能重复执行前面的步骤，却仍然不知道真正欠的是哪一个交付动作。更糟的是，系统会留下一个看似干净、实际无法追溯的结果。
所以我把“最终产物能否独立回取”作为一个单独检查。它不要求所有中间过程都完美，但要求别人不依赖当前聊天记忆，也能拿到计划承诺的结果，并知道它对应哪项任务。
最容易走的错误捷径
错误捷径有几种。看到 DONE 就删除，是把状态当成事实；看到停滞时间超过某个阈值，就发送 continue，是把时间当成意图；看到计划文件存在，就把文件存在误认为工作存在。它们之所以诱人，是因为都能快速减少待处理数量。
但数量变少不等于问题变少。删除动作不可逆时，误删会直接丢失线索；自动续接没有判断依据时，可能把已经完成的计划重新打开；只保留文件而不看产物，则会让“有记录”和“有交付”混成一件事。
我选择建立因果配对，是因为它比状态和时长更接近任务本身。状态可以写错，停滞时间只说明没有新事件，文件也可能只是过程残留；动作与结果之间的对应关系，却能回答“这一步到底有没有产生下一步所需的条件”。这不是让复核变慢，而是把最可能造成损失的判断放到前面。
一条可以复用的收尾规则
现在我会用一条很短的流程复核停滞计划。先读计划中的目标和步骤，确认它承诺了什么；再按步骤寻找对应的工具调用和返回结果；然后检查最后一条用户消息是否得到回应；最后确认最终产物能否独立回取。每一项都能对上，才进入收尾。
如果链路闭合，就可以删除或归档，并保留必要的完成证据。如果只有状态完成、没有结果证据，就不能直接清理；如果前面动作完整、最终产物缺失，就保留计划，并报告具体缺口；如果最后一条用户消息还没有回应，就先处理回应，再重新判断。不同的证据对应不同的动作，不能把所有停滞计划统一处理。
我也会把“缺口”写得足够小。不要只说“任务未完成”，而要说明缺的是最终产物、用户回应，还是某次工具调用的返回结果。缺口越具体，后续接手的人越容易从正确的位置继续，也越不容易重复已经完成的工作。
保留一份有明确缺口的计划，并不是把混乱继续留在列表里，而是给下一次行动留下入口。它至少应该说明已经完成到哪里、还缺什么、缺口为什么会阻止收尾。如果这些信息都没有，只留下一个模糊的“待处理”，那份记录既不能帮助继续，也不能帮助判断是否可以结束。复核的目的，是让未完成变得可接手，让已完成变得可证明。
这件事让我重新意识到，成熟的工作流不是把所有状态都变成绿色，而是让每个结论都能沿着证据倒推回去。一个流程成熟的标志，不是它能很快清空列表，而是清空之后，仍然说得清为什么可以清空。
下次我会怎么做
下次再遇到多份停滞计划，我会先暂停“清理”的冲动，把每份计划当成一条待验证的因果链。先找承诺，再找动作；先看返回，再看收尾；最后把用户消息和最终产物放到交付位置上检查。
我不会因为看到 DONE 就直接删除，也不会因为停了很久就自动发送 continue。状态和时间可以作为筛选线索，但不能代替完成证据。真正需要做的，是把计划中的每一步和实际记录逐一对齐：有动作，才谈结果；有结果，才谈交付；有交付，才谈收尾。
只有当关键动作、对应结果、用户回应和最终产物首尾相接，计划才算真正完成。
这条规则不只适用于计划清理，也适用于任何需要判断“事情是否做完”的协作。看见一个结束标记时，我会多问一句：它结束的是状态，还是事情本身？答案必须由因果链给出来。