流程自动化项目上线前，为什么人工兜底、审计和回滚要先设计，而不是出事后再补？

很多演示只覆盖正常路径：资料完整、状态正确、接口响应稳定、下游系统也正好可用。可真实业务里最常见的，恰恰是字段缺失、规则冲突、重复触发、外部接口超时和人工中途改状态。只要这些异常没有设计进去，自动化上线后就会不断把问题推给人补。

这也是为什么我不太把“是否已经调通接口”当成自动化 readiness 的主要判断。更关键的是：流程规则是不是足够稳定，异常有没有被分类，失败后系统是停在可理解的中间状态，还是直接留下一个谁都说不清的脏结果。

很多团队说自己留了人工兜底，实际做法只是任务失败后发一条消息给群里，或者在后台挂一个报错提示。这样的兜底很快就会失效，因为没人知道谁必须处理、多久要处理、处理后要不要补写状态、是否需要重新触发自动化。

真正可用的人工兜底，应该像流程节点一样被设计出来。谁是默认接手人，什么条件下升级给上一级，人工处理后系统如何继续往下走，是否保留重试按钮，是否允许人工确认后恢复自动执行，这些都要在第一版先说清楚。

只要自动化会改状态、发通知、生成记录、同步第三方系统，审计就不只是为了排查 bug。业务方需要知道是谁触发的、用了什么输入、系统做了什么判断、写入了哪些结果、什么时候被人工改过。没有这条链路，团队一旦遇到争议，就只能靠猜。

回滚也是同样的逻辑。不是所有动作都能简单撤销，但至少要明确哪些结果可以自动回退，哪些只能人工补偿，哪些要保留原值和变更前快照。否则每次失败都只能让开发临时查库、补数据，系统会越跑越不敢放开。

如果一期就想把整条长流程全部自动掉，往往最先崩的不是模型或接口，而是团队对异常没有共同处理方式。更稳的方案通常是先挑一段高频、规则相对稳定、失败成本可控的环节，把触发、执行、异常、日志和人工接管跑成闭环。

这个闭环跑稳后，团队会更清楚哪些规则真的稳定，哪些环节值得继续自动，哪些动作必须保留人工确认。自动化真正节省成本，不是因为少写了几个页面，而是因为它能长期稳定地减少人工操作，而不是把人工工作换成了人工救火。