我这次处理的是一个看起来很小、实际很容易反复出现的问题：桌面自动化完成一段文字转语音后，能不能无论由谁调用、打开了哪一个草稿，最后都回到编辑器首页？原来的流程在成功时大多没有问题，声音生成出来，文件也能拿到，界面就回去了。真正麻烦的是报错、超时或者进程意外中断时，草稿会留在编辑器里。下一次任务再启动，面对的就不再是一个干净的入口。
这件事让我重新意识到，自动化流程的“完成”不能只看主要产物有没有生成。它还要回答两个问题：任务中途改变的状态有没有收回来，过程中产生的临时东西什么时候才允许被清理。如果只把收尾写在成功分支里，流程顺利时看不出缺陷，异常一多，缺陷就会变成下一次任务的起点。
表面上是没有回首页
最开始看到的现象很直观。某个 TTS 调用结束后，编辑器还停留在刚刚使用的草稿里，没有回到首页。有时这只是一个空的过程草稿，有时则会让后续流程误以为已经处于正确页面。人工操作很简单，点一下关闭或返回就行；但自动化不能把“最后应该点什么”交给运气。
原有回首页逻辑只覆盖成功路径。也就是说，正常返回值出来以后，调用方顺手做一次关闭；如果中间抛错，或者编辑器刚打开还没有走到成功回调，那个关闭动作就永远不会发生。多个调用方看上去各自负责一段 TTS，实际排查后发现，它们最终汇到两条共享的执行通道。继续在每个调用方末尾补一遍清理，表面上很快，实际上只是把同一个责任复制了很多份。
如果不处理这个问题，会导致的不只是界面不好看。残留草稿可能让下一次任务打开错误对象，失败现场也可能被后续流程覆盖；更危险的是，清理逻辑越分散，越难知道某条异常路径究竟漏没漏。一个流程必须在错误发生后仍然有确定的出口，而不是希望每一层都记得替上层收尾。
真正的问题是状态没有汇合
我一开始以为需要继续补“返回首页”的动作，后来发现真正要处理的是状态汇合。两个 TTS lane 虽然入口不同，但它们都可能打开编辑器、进入某个草稿、生成音频，再退出这个临时状态。既然最终都经过共享汇合点，就应该在那里安装一次幂等的 closeout，而不是让每个上游调用方各自猜什么时候该关。
这里的幂等很重要。成功路径可能已经主动关过一次，退出兜底随后又被触发；如果两次关闭都会造成新的副作用，就会从“没有收尾”变成“重复收尾”。所以我选择让 closeout 记录当前流程是否已经完成，并把关闭草稿、回到首页的动作设计成可以重复调用而不会扩大影响的操作。我判断这是更稳的边界，是因为调用方只需要报告自己的结果，状态收口由共享位置统一负责。
一个流程是否可靠，不看它在顺利时多快，而看它在失败时能不能回到可预测的状态。
这也解释了为什么退出兜底要在“可能打开编辑器”的阶段就注册，而不是等生成成功后再注册。只要编辑器已经可能被打开，异常就已经有了需要处理的状态。注册的兜底只负责关闭本流程打开的草稿并回到首页，不负责杀掉编辑器进程，也不删除真实用户稿。边界越窄，恢复动作越容易证明不会误伤。
不能把清理散落在调用方
最容易误判的错误捷径，是在每个 TTS 调用方的最后加上几行删除和返回代码。这样做看起来符合“谁打开谁关闭”，但它把异常处理变成了调用方自觉：每个分支都要记得写，新增调用方还要复制，未来改动时又可能只改到其中一条。只要有一个调用方忘了注册兜底，问题就会重新出现。
另一个错误捷径，是把“文件已经生成”当成“可以删除草稿”。这两个判断不是一回事。文件可能还只存在于草稿目录里，拷贝尚未完成；也可能生成动作返回成功，但实际文件不完整。此时删除过程草稿，等于同时删掉了唯一能继续排查或取回的产物。
所以我没有把删除放进 closeout 的无条件部分。回首页是状态收口，删除过程文件是资产清理，它们的前置条件不同。前者可以在成功或异常时尽力执行，后者必须等到产物已经独立落盘并完成验真之后，才有资格发生。
先验真，再决定草稿命运
这次对草稿的判断也需要分层。对于流程临时创建的草稿，如果 WAV 已经拷出草稿目录，就要继续确认文件确实存在、大小合理，并完成哈希校验。哈希一致，说明拷贝前后的内容没有变化；再结合记录中的流程身份，确认这个文件确实属于当前这次生成，而不是碰巧同名的旧文件。
这些检查不是为了把一个简单流程变复杂，而是为了避免不可逆的错误。删除前少做一次校验，失败时就可能只剩一个“生成过”的日志，没有可以播放、比对和复现的声音文件。删除过程文件的前提不是“程序说成功”，而是“最终产物已经独立、完整、可确认地保存”。
验真通过后，如果编辑器已经退出，就可以立即删除这次流程创建的过程草稿。若编辑器仍然存活，删除动作就延迟到后续 sweep，等环境安全时再处理。这样做不是拖延，而是给正在使用的文件留出一个恢复窗口。自备的草稿不动；失败的草稿也暂时保留，方便定位问题。只有身份明确属于本流程、产物已独立保存、当前没有占用风险的临时草稿，才进入清理范围。
把收尾拆成两条责任链
后来我把这套流程理解成两条责任链。第一条是状态链：进入可能打开编辑器的阶段时注册退出兜底，任务结束时由共享汇合点执行 closeout；成功路径完成后标记兜底已经处理，避免重复关闭。即使程序在中途异常退出，兜底也只尝试把本流程留下的编辑状态收回到首页。
第二条是产物链：先把 WAV 拷到草稿目录之外，再做存在性、完整性和哈希检查，确认流程身份，最后才决定立即删除还是延迟 sweep。两条链不能互相替代。回到首页不能证明文件安全，文件存在也不能证明编辑器状态已经收口。
真正成熟的收尾，不是把“清理”写得更早，而是把每个清理动作的证据写得更清楚。
这件事让我重新意识到，临时文件不是天然该删的垃圾，它是流程在某个阶段承担的保险。只要最终产物还没有离开临时环境，它就有价值；一旦产物完成独立验真，临时文件才从保险变成负担。自动化的判断不是“能不能删”，而是“现在删了，失败时还剩不剩恢复路径”。
这套方法可以怎样复用
以后遇到任何会打开桌面编辑器、创建临时对象并导出产物的流程，我会先画出调用方最终汇到哪里。只要存在共享 lane，就把 closeout 放在汇合点；只要某一步可能改变外部状态，就在这一步之前注册退出兜底。兜底要限定对象、限定动作、限定影响范围，并且允许成功路径安全地把它标记为已处理。
然后把过程文件分成至少3类：用户自备的原始对象、成功但尚未验真的过程对象、已经完成独立验真的临时对象。第一类默认不动，第二类保留，第三类才按编辑器是否仍在使用决定立即删除或延迟清扫。清扫任务也要带流程身份，不能只按文件名或时间猜测归属。
这套方法的核心不是某个桌面软件的按钮，也不是某一条脚本技巧，而是把“状态收口”和“资产清理”分开。一个负责让环境回到可预测的入口，一个负责证明产物已经安全脱离过程环境。当动作可能不可逆时，先保存证据，再执行清理；当状态可能半途改变时，先注册兜底，再开始操作。
下次我会怎么做
下次再接入一个新的 TTS 调用方，我不会先问它成功后在哪里返回，而会先确认它最终进入哪条共享 lane，以及这条 lane 是否已经拥有统一 closeout。进入可能打开编辑器的阶段后，我会立即登记退出兜底，并用成功、报错、超时和进程中断几种情况验证它是否都能回到首页。
涉及草稿删除时，我会把“拷出 WAV”“独立校验”“确认流程身份”“判断编辑器是否仍存活”列成连续判断。任何一步没有证据，就保留过程草稿并延迟清理。这样失败现场虽然暂时多了一个文件，却不会丢掉唯一产物；成功时也能放心删除，而不是靠一次顺利运行建立错误的安全感。
一个流程成熟的标志，不是它能跑通一次，而是它能在下一次少依赖临场记忆。收尾如果只存在于成功分支里，顺利只是偶然；当汇合点、退出兜底和产物验真都成为固定规则，流程才真正拥有了面对失败的能力。