我最近审查一套桌面编辑工具的自动化流程时，先看到的是一条看起来很完整的安全链路：操作可以先预览，真正执行需要经过确认，完成后还有结果检查。这样的结构很容易让人放松，以为危险动作已经被统一管住了。
但继续往下看，我发现“有预览”不等于“每个子命令都有预览”。清理流程里的某个删除动作可以绕过同一套纪律，直接作用在源视频上；更麻烦的是，这个源视频可能仍被其他待保留条目引用。另一处问题出现在导出：轮询超过等待时间后，流程仍有机会返回成功状态。前者可能造成真实数据损失，后者则会让人带着错误回执继续往下做。
这件事让我重新意识到，危险操作的风险通常不藏在主流程的名字里，而藏在那些被当作“小步骤”的调用里。一个流程是否安全，不能看它有没有一个总的预览开关，而要看每个有副作用的动作能不能独立证明自己被允许执行。
先把“看起来安全”拆开
审查覆盖了说明书、脚本、测试和真实产物验收。这样做的原因很现实：说明书可能描述了理想流程，脚本可能实现了另一套默认行为，测试可能只覆盖正常路径，而真实产物又可能暴露异步状态没有被正确表达的问题。只读其中一层，很容易把“写过”误认成“守住了”。
我一开始也差点接受“大流程已经有 dry-run”这个判断。后来把调用方逐个列出来，才发现需要先问的不是“入口有没有预览”，而是“从入口往下，所有会改变外部状态的动作有哪些”。删除文件、覆盖已有内容、移动或替换素材、提交不可撤销的变更，都应该被列在同一张清单里。它们不因为被包在清理、导出或收尾函数里，就自动变成普通读取。
这里最容易误判的是命令名称。一个叫“清理”的操作，可能只是生成待处理列表，也可能已经开始删除；一个叫“导出”的操作，可能只是提交后台任务，也可能已经覆盖了旧结果。真正要看的是它是否改变了文件、任务或外部系统的状态，而不是它在界面上被归到哪个功能组。
如果不先完成这一步，后续的安全检查就会漏掉隐形入口。主命令有确认弹窗，子命令却直接调用删除；文档说默认预览，某个内部调用方却没有传入预览参数。用户看到的是一条安全流程，系统执行的却是两套规则。
删除不是一个普通的后处理步骤
这次最具体的风险出现在预览清理。它本来想在处理完成后删除不再需要的源视频，但判断“是否不再需要”时，没有充分验证其他保留条目是否仍然引用同一个源文件。于是，一个看似已经被当前任务淘汰的源视频，可能仍是别的任务的输入。
这类问题难在删除动作通常发生在流程末尾。前面的编辑、导出和预览都成功了，操作者的注意力已经从“数据是否完整”转向“临时文件是否需要清掉”。越接近收尾，越容易把删除当成清洁动作，而不是一次新的业务决策。
我选择把删除目标确认单独拿出来，是因为“当前条目不再使用”与“系统中没有任何条目使用”不是同一个判断。前者是局部视角，后者需要检查全局引用关系。只有在目标唯一、引用关系已经回读确认、并且当前执行明确允许删除时，清理才有资格进入不可逆阶段。
任何删除都应该先回答两个问题：它要删的到底是哪一个对象，以及这个对象是否仍被其他工作引用。
这也解释了为什么默认预览不能只停留在总入口。预览结果应该列出具体目标，让人能看到“将删除什么”，而不是只显示“清理即将执行”。如果目标在预览和真正执行之间发生变化，还需要重新确认，而不能把旧预览当成永久授权。
显式执行是第二道门
审查还发现，部分删除命令没有显式执行参数。调用后，它们会直接触发不可撤销操作。这里的问题不只是少了一个参数，而是默认行为把“表达意图”和“改变状态”合并了：调用方只要走到这一步，删除就已经发生。
我没有选择在每个调用方旁边补一条提醒，因为提醒无法保证所有新调用方都遵守。更稳妥的做法是让安全状态成为默认值：没有明确传入执行许可时，只生成预览或拒绝执行；只有调用方显式表达“现在执行”，底层动作才允许继续。这样，遗漏参数会把流程留在安全状态，而不是把它推向不可逆结果。
显式执行也不能被理解成一个孤立的布尔开关。它至少要和目标、模式及当前上下文一起被记录。否则，一个调用方可能传了执行参数，却没有确认它执行的仍是刚才预览过的那批目标。执行门的意义，是让系统在最后一步再次要求意图清楚，而不是给危险函数加一个形式上的装饰。
错误捷径是看到顶层已经 dry-run，就默认所有子命令都安全。这个捷径很诱人，因为大多数顺利路径确实会通过总入口。但安全边界不能靠调用者记忆维持。只要有一个旁路能直接删除，整体流程就存在一个不受预览约束的缺口。
默认预览、显式执行和目标唯一性应该同时成立，缺少其中任何一项，都不应把动作当成安全完成。
导出成功不能只看退出码
删除问题解决之后，我继续看异步导出。这里的表面问题是轮询超时：任务在规定时间内没有返回终态。真正的问题是，超时分支仍可能沿用先前的成功变量，最后把一个没有完成的导出报成成功。
这类错误比直接报失败更危险。失败至少会让人停下来检查；假成功会让人相信产物已经存在，继续发送、发布或删除源文件。如果不处理，后面的动作就会建立在一个不存在的结果上，错误可能一直到交付之后才暴露。
我判断需要把提交、执行中、超时、失败和产物验收分开建模，是因为它们代表不同事实。提交成功只说明任务被接受；执行中说明后台还没有给出终态；超时说明等待窗口结束，但不等于任务失败或成功；任务成功也还需要独立确认产物可读、位置正确、内容符合预期。把这些状态压成一个“成功或失败”，一定会丢掉关键判断。
真实产物验收尤其重要。进程退出码只能说明某个进程如何结束，不能自动证明文件已经生成，也不能证明生成的是本次任务的结果。验收至少要回读目标是否存在、是否可打开，以及它是否与当前任务对应。对于可能覆盖旧文件的动作，还要确认覆盖目标和新产物之间没有混淆。
一个成熟的流程不是永远不出错，而是在等待结束、后台失联或结果不完整时，仍然能诚实地表达“现在不知道”。在异步任务里，未知状态必须保持未知，不能为了让界面整洁而被填成成功。
用反例检查安全边界
把规则写进说明书还不够，我会用反例去验证它们是否真的落在代码和结果上。删除相关的反例包括：没有显式执行参数时不能删除；预览目标与执行目标不一致时不能继续；目标仍被其他条目引用时必须拒绝；同一目标出现多个解释时不能默认为其中一个。
导出相关的反例则要覆盖：轮询超时不能返回成功；后台明确失败时不能只看进程退出码；任务提交成功但产物缺失时不能通过；旧产物存在时不能把旧文件误当成本次结果。反例的价值在于，它们直接对应“如果不处理会怎样”，而不是只证明正常路径可以走通。
我也会把检查分成几层。先做语法和静态检查，确认入口和分支没有明显错误；再跑针对危险动作的测试，确认默认状态和失败状态没有被绕过；最后做真实产物验收，确认系统对外报告的结果和实际文件一致。每一层回答的问题不同，不能用前一层的通过替代后一层。
这件事让我重新意识到，审查自动化工具时，最值得花时间的不是寻找最多的检查项，而是把每条检查和可能的损失连起来。删除旁路对应数据损失，假成功对应错误交付，引用未回读对应误删风险。这样才能判断哪些门必须放在动作发生之前，哪些结果必须独立读取。
下次我会怎么做
下次审查类似工具，我会先画出有副作用的动作图，不从菜单或功能名称出发，而从“哪些调用会改变外部状态”出发。每个动作都记录调用方、默认模式、目标来源、是否可逆、失败后如何恢复，以及完成后怎样独立验收。
然后我会逐项确认4个问题：默认是不是预览，执行是不是显式，目标是不是唯一且经过回读，失败和超时是不是保持真实状态。只要有一项回答含糊，我就不会把这个动作归入已安全流程。
对于删除和覆盖，我会要求执行前重新核对目标及引用关系；对于异步任务，我会把提交、等待、超时、失败和产物验收拆成不同状态。最后用反例测试去撞这些边界，再用真实产物回读检查回执是否可信。
我更愿意把这看成一种工作习惯，而不是一个技巧。工具真正可靠的标志，不是它在顺利时能自动完成多少步，而是它在接近不可逆动作时，愿意多停一下，把判断交给明确的门，把结果交给独立的证据。多这一道执行门，牺牲的是一点顺滑，守住的却是下一次还能继续工作的可能。