先别急着宣布它已经无人值守
那次有人问我，电影智能粗剪是不是已经可以无人值守了。这个问题听起来像是在问一个功能有没有做出来，真正回答起来，却不能只看有没有脚本、有没有成功跑过一集，甚至不能只看状态文件里是不是写着完成。
我先把主链路拆开看：导入、粗剪、观察运行状态、收尾。几个控件已经在真实机器上操作成功，说明它们不是停留在猜测里的按钮；但继续往下盘点时，结论变得不那么漂亮：一共 8 个控件达到了 live_verified，却没有任何一个达到 unattended_verified。另一侧的 Windows 能力，甚至还停留在 hypothesized。
这不是在故意把一个已经能用的流程说得很差，而是在区分两种不同的事实。有人在场时点通一次，说明路径存在；没有人盯着、可以从中断处继续、失败不会污染下一项，并且最后产物真的通过验收，才接近可以托付。
一个流程跑通过一次，只能证明它曾经成功，不能证明它已经适合被放手运行。
这件事表面上是粗剪，实际上是责任边界
当时最容易看到的是界面问题：导入是否完成，粗剪按钮是否出现，窗口是否处于正确状态。但如果只沿着界面往下点，最后得到的往往是一段“看起来已经完成”的记录，而不是一条可追责的生产链路。
比如，导入阶段并不要求素材已经出现在时间线上。这个细节很重要。若把“时间线上暂时看不到”直接当作导入失败，自动化就可能重复导入；若反过来把“导入动作已经发出”当成导入成功，后面的粗剪又可能在没有输入的情况下继续跑。表面上是一个界面判断，实际上是在决定下一步能不能被放行。
我后来把问题改写成了几个更窄的判断：权限是不是在无人值守时仍然成立？桌面是不是被别的窗口抢走？中途退出后能不能从检查点继续？重复启动会不会把已完成项再做一遍？后台没有响应时，谁来发现？最后生成的文件，谁来证明不是空文件、残片或错误版本？
如果这些问题不处理，最坏的结果不一定是程序立刻报错，而是它安静地把错误传到后面。状态显示完成，目录里也出现了文件，人却要在交付前重新打开每一部成片，才能发现某一项没有真正导出。无人值守没有减少人的工作，只是把人工检查推迟到了更昂贵的位置。
live_verified 和 unattended_verified 不是同一个勾
我选择把成熟度写成阶梯，是因为“已验证”这个词太容易把不同证据压成一层。hypothesized 表示根据结构或设计推断它应该可行；live_verified 表示在真实环境里实际操作成功；unattended_verified 则要求它在没有持续人工盯守的条件下，完成一轮可恢复、可验收的运行。
这 3 个状态不是给报告增加术语，而是给承诺划边界。一个控件可以已经 live_verified，但仍然不能被批量驱动。因为真实点击只回答了“这次有人操作时能不能动作”，没有回答“失去焦点、发生重启、遇到慢响应时会不会把后续步骤送错地方”。
这里最容易误判的错误捷径，是看到历史上成功跑过一集，或者看到状态文件写着完成，就宣布无人值守已经完成。历史成功只证明过去发生过一个好结果；状态文件只证明某个程序写过一个状态。两者都不能替代重启、续跑、异常隔离和最终产物验收。
状态文件是证据链的一部分，不是证据链本身。
我没有把所有控件都直接提升到最高状态，是因为成熟度必须由最弱的关键环节限制。只要粗剪分支还有窗口白名单缺口，自动化就可能把动作发到错误窗口；只要后台导出没有收口，前面的导入和剪辑再稳定，也不能声称整条链路无人值守。保守一点，会暂时少一个“已完成”的标签，但能避免把尚未承担的责任提前交出去。
真正的分水岭是续跑，而不是首次成功
另一条已经实跑过的批量流程给了我一个对照。它不是靠一个很长的脚本从头冲到尾，而是有常驻驱动，有防止系统休眠的措施，有幂等的续跑逻辑，也有看门狗。每个阶段留下可以判断的进度，重新启动时先识别已经完成的部分，重复执行不会把同一项无条件再提交。
这让我意识到，自动化的核心不是把人的点击速度复制给机器，而是把“下一步能不能安全发生”变成明确条件。常驻驱动解决的是流程不会因为一次命令结束就失去上下文；防休眠解决的是机器在长任务中悄悄改变运行条件；幂等续跑解决的是中断后不必从头赌一遍；看门狗解决的是没有人守在旁边时，沉默的卡死也能被发现。
如果没有幂等续跑，失败后的人工处理就会变成猜谜：这一项究竟已经导入，还是只写了状态？重新执行会不会生成重复素材？如果没有看门狗，程序既不报错也不前进，最后看起来像“还在处理”，实际上只是把时间耗完。无人值守的关键不是不需要人，而是把需要人判断的时刻推迟到明确的异常处。
因此，我会把“续跑成功”看得比“首次跑通”更重。首次成功说明顺利路径存在；续跑成功才说明流程对现实世界的打断有准备。现实里会有重启、窗口抢焦点、导出变慢、权限失效和单个素材损坏，成熟系统必须允许这些事情发生，而不是假设它们永远不会发生。
最后验收的是产物，不是过程的自我描述
状态、日志和阶段标记都很有用，但它们仍然属于过程证据。真正交付时，我还需要回到产物本身：成片是否被回拷到约定位置，文件是否完整可读，媒体探针能否读出合理的时长和轨道，抽取的画面是否真的有内容，文件是否对应本次任务而不是上一次残留。
我把这一步放在最后，不是因为它最次要，而是因为它负责裁决前面的乐观判断。导入完成不等于粗剪完成，粗剪完成不等于导出完成，导出完成也不等于交付有效。每一个阶段都需要一个能被外部观察的结果，不能只引用内部状态来证明自己。
如果不做产物验收，会导致一个很危险的错觉：系统在过程里一路显示绿色，人也因此认为它没有问题；直到用户打开文件，才发现画面为空、时长不对，或者成片根本不是这一轮任务生成的。那时再回头追日志，通常已经很难判断错误从哪一步开始。
所以我的方法是把验收拆成两个方向。一边看流程证据：权限继承、独占 UI、检查点、重复跳过、看门狗是否都留下记录；另一边看结果证据：文件回拷、可读性、媒体信息和抽帧结果是否通过。缺任何一边，都只能保留在较低成熟度。
一套可以复用的成熟度规则
以后再盘点类似的自动化系统，我会先建立一张证据表，而不是先问“脚本有没有写完”。第一层只记录假设，不把结构存在当成能力存在。第二层要求在真实环境里完成一次关键动作，确认权限、控件定位和输入输出确实成立。第三层才进入无人值守验证：让流程在独占 UI 下跑一轮，故意经过可以恢复的中断，确认它能从检查点继续，并且已经完成的项目会被跳过。
接着检查失败隔离。一个素材坏了，不能让整批任务的状态变得不可解释；一个窗口失去焦点，不能让下一步悄悄发送给别的应用；后台长时间没有进展，必须有看门狗把它标成需要处理，而不是继续假装运行。最后再做产物验收，把成片回拷、媒体探针和抽帧结果接到完成条件里。
这套方法的规则可以写得很简单：只要权限继承、UI 独占、检查点续跑、重复跳过、看门狗和最终验收中有一项没有证据，就不把状态提升到 unattended_verified。Windows 侧仍然是推断，就明确写成推断；某个控件只在现场点通，就保留为 live_verified。成熟度不是奖励，而是系统愿意承担多少失败后果的证据。
这件事让我重新意识到，自动化真正替代的不是手指，而是临场记忆。没有检查点时，人要记得做到哪一步；没有失败隔离时，人要记得哪些项目不能重复；没有产物验收时，人要记得最后打开文件确认。把这些判断写进流程，系统才开始从“会执行”走向“可托付”。
下次我会怎么做
下次遇到“是不是已经无人值守”的问题，我会先拒绝用一个笼统的“可以”回答。先列出主链路，再把每个关键控件和阶段放到成熟度阶梯里，明确哪些是猜测，哪些是真实操作，哪些经过了无人值守续跑。这样可以先把能力范围说清楚，也不会因为某个局部成功就替整条链路背书。
然后我会优先补最容易造成错误扩散的环节：窗口白名单、独占 UI、权限继承和检查点。它们决定动作是不是发给正确对象、流程能不能从中断处回来。最后再做一轮带看门狗的真实运行，并把媒体信息和抽帧验收接上。没有真实续跑和产物证据，就把结果留在较低状态，不用漂亮的状态名掩盖缺口。
我更愿意把它看成一种工作习惯，而不是一个技巧。完成是过程写下了一个结论；成熟则要求现实能够反驳这个结论，而且系统知道怎样停下来、怎样恢复、怎样把错误交给人。只有当这条证据链闭合，我才会说：这条流水线不只是跑过，而是已经值得托付。