那次任务的要求其实很明确：在一个可以看见的面板里，生成一份视频制作计划。重点不只是得到一份计划，还包括让任务在可见面板中运行，方便观察过程和结果。任务创建以后，我先发出了指令，之后才想到要把界面切换到计划模式。切换动作发生时，面板这一轮前台运行被中断，最后显示成“用户已取消”。
如果只看到这几个字，最自然的反应是认为计划没有生成，或者认为刚才的指令已经失效。可继续看会话记录和目标文件后，事实却不是这样：后台会话仍然完成了计划文件的写入。表面上是一次任务被取消，实际上是前台状态和后台产物没有在同一个时刻结束。
这次真正需要判断的，不是面板上的一个状态词，而是创建、切换、执行和产物之间的因果链。
我一开始把状态当成了结果
面板状态很有诱惑力，因为它把复杂过程压缩成了一个短标签。“已完成”让人放心，“失败”让人警觉，“已取消”则很容易被理解成什么都没有发生。但状态是某个界面对某个运行阶段的描述，不一定等同于后台所有动作的最终结果。
这次尤其如此。任务先被创建并发出指令，模式却没有在最开始确定。后来切换到计划模式，切换动作中断了正在运行的前台轮次，于是面板写入“用户已取消”。这个标签能够说明前台轮次发生了中断，却不能单独证明后台工作没有继续。
如果不处理这个区别，会导致一个很实际的后果：把已经写好的计划当成失败结果，再次派发同一任务。重试可能造成重复文件、重复执行，或者让后来的人误以为第 1 次确实没有产生任何东西。更糟的是，重试会遮住原来的时序问题，让我们只记住“重跑后好了”，却不知道为什么第 1 次出现了误导性的状态。
这件事让我重新意识到，状态是证据的一部分，但不是证据的全部。它适合告诉我先去哪里查，不适合直接替我下最终结论。
真正的问题藏在模式切换的时机
后来把动作顺序拆开，问题就清楚了。第 1 步是创建任务，第 2 步应该初始化模式，第 3 步才是发出指令，第 4 步是执行，第 5 步才是回读结果。实际发生的顺序却是创建任务、发出指令、执行过程中再切换模式。模式不是一个可以随时改动的显示选项，它会影响当前前台轮次的运行边界。
模式切换不是执行中的普通设置，它会改变当前任务所处的运行环境。
所以，切换模式本身并不一定是错误；错误在于把它放到了已经发出指令之后。任务一旦开始，前台这一轮就已经有了自己的上下文。此时改变上下文，界面为了响应切换而中断正在运行的轮次，是可以预期的结果。后台会话是否继续，则要看它和前台显示层之间的关系，不能凭一个面板标签猜。
这里最容易误判的是，把“我是在切换模式”理解成“我只是把显示方式换一下”。如果模式参与任务执行，切换就是生命周期操作，而不是外观操作。越早确认这一点，越不容易在任务中途制造竞态。
我选择把模式初始化放到发指令之前，是因为这样能把一次任务的运行条件固定下来。任务先知道自己要在哪种模式中工作，后面执行过程就不需要依赖临时的界面操作。即使执行结果需要继续核对，也是在同一条因果链上回读，而不是边跑边改变入口。
先查因果链，再看哪个文件存在
面对“已取消”，我没有直接重新执行，而是按动作顺序回看。先确认任务什么时候创建，再确认指令什么时候发出；接着查模式切换发生在什么位置，最后看会话是否还有完成动作，以及目标文件是否已经写入。这样查的好处是，面板状态不再是孤立的结论，而会被放回时间顺序里。
查到后台会话仍然完成计划写入后，判断就发生了变化。文件存在并不自动说明整个任务完全正确，但至少证明“没有生成任何结果”这个猜测不成立。接下来要问的是，文件内容是否对应本次请求，写入是否发生在预期的位置，前台状态为什么没有同步反映出来。
验收时要把面板状态、会话因果链和目标产物放在一起看，三者不一致时先定位竞态，不能先重派任务。
这也是我不选择“看到取消就重试”的原因。重试是动作，不是诊断。它可能让面板最后显示一个更漂亮的结果，却没有解释第 1 次为何被标记为取消。没有解释，下一次只要时机再次变化，问题还会回来。
一个状态词不能覆盖两层执行
这次还暴露出另一个容易忽略的边界：前台轮次和后台会话并不一定拥有同一条生命周期。前台轮次负责让面板及时反馈，后台会话负责继续完成实际工作。当模式切换打断前台轮次时，后台仍可能把已经开始的工作做完。
这并不意味着所有“已取消”都可以忽略。若目标文件没有出现，会话记录也没有完成迹象，那就要按失败处理；若文件存在但内容不对，也不能因为文件名出现了就算成功。区别在于，状态词只提供了一个入口，最终判断还要结合其他证据。
我会把结果分成几个问题来问，而不是只问“成功还是失败”：面板这一轮是否被打断？后台会话是否继续？目标产物是否写入？产物是否对应当前指令？这几个问题的答案可以不同，恰恰因为它们测量的是不同层次。
如果不把层次拆开，后续协作会出现两种对立的错误。一种是过度相信面板，看到“已取消”就丢掉已有结果；另一种是过度相信文件，只要文件存在就忽略执行过程中的中断。前者会重复劳动，后者会漏掉模式和状态同步问题。可靠的验收必须同时保留结果证据和过程证据。
把任务生命周期固定成 5 步
这次之后，我把这类带模式的任务整理成 5 步：创建、模式初始化、发指令、执行、结果回读。创建时先确定任务要服务的目标；模式初始化时确认计划模式已经生效；发指令前不再依赖后续切换；执行中禁止改变模式；结束后同时检查面板、会话和目标文件。
这套流程看起来比“先创建，跑起来再调整”慢一点，但它减少的是更昂贵的歧义。前面多花一个确认动作，后面就少一次猜测：到底是没有运行，还是运行了但显示层被打断？到底是文件没有写入，还是已经写入但状态没有回读？
一个带模式的任务，最稳的边界是“模式先于指令，结果晚于证据”。
这里的“结果晚于证据”不是把验收拖到很久以后，而是不要用单一界面状态代替完整检查。面板状态用于发现异常，会话记录用于还原顺序，目标文件用于确认产出。三者一致时，可以结束；三者不一致时，先记录不一致发生在哪一步。
这个方法也适用于其他有前台控制层和后台执行层的工作。只要存在模式、队列、会话或界面切换，就要警惕“操作已经改变了运行边界，但状态还没有说明全部事实”。把生命周期拆开，往往比增加一次重试更能解决问题。
下次我会怎么做
下次再创建需要计划模式的任务，我会在创建任务的同一轮先把模式确定好，并确认模式已经生效，然后才发出指令。任务运行期间不切换模式，也不把界面上的状态变化当作后台结果的最终结论。
如果面板出现“已取消”，我会先按顺序核对：前台轮次在哪一步被中断，会话是否继续完成，目标文件是否存在且对应本次请求。只有当这些证据都指向没有产出，才考虑重新派发；如果文件已经写好，就先处理状态与结果不一致的问题，不用重做一遍。
这件事让我重新意识到，工具最容易让人误判的地方，不是它没有信息，而是它把不同层次的信息压缩得太像。一个状态词可以很快，但不能替代判断。真正成熟的流程，不是保证面板永远显示理想状态，而是在显示与结果不一致时，知道沿着哪条因果链把事实找回来。