第一次把审批、通知、归档串成一条自动化工作流时，演示往往很顺：单据一提交，消息弹出，文件归位，像一条没有红灯的路。真正上线后，路中间会冒出各种东西——字段填错、附件缺失、审批人休假、金额需要拆分。系统停在某一步，等人来认领。
这些时刻决定了流程能不能长期跑下去。把重复动作交给机器并不难，难的是机器遇到没见过的情形时，知道该找谁、留下什么线索、什么时候停。
顺滑的演示，卡在例外上
例外不是故障，它是流程边界的显影。规则写得再细，也会遇到规则之外的组合。若把所有例外都塞回人工，自动化工作流就变成一条“正常时轻快、异常时堆积”的通道：人要先看懂系统停在哪儿，再绕过它。若强行让系统猜，错误会被放大，后面的人需要花额外时间清理。
我更愿意把例外分成两类看待：一类可以补齐信息后继续，一类必须由人判断。前一类适合做校验、提醒、退回补充；后一类需要明确交接点，而不是让流程原地空转。分类动作本身不复杂，复杂的是团队是否愿意承认“这里机器不该继续”。
先把例外分流，再谈全自动
设计时可以从三个问题入手：谁会收到例外、他需要看到什么、处理完之后流程从哪里接上。把这三件事写清楚，往往能减少空转的自动节点。下面这份检查清单不追求完整，但能暴露常见缺口：
- 例外是否有明确的接收人，而不是一个公共群组；
- 页面是否展示当前步骤、失败原因和已尝试的动作；
- 人工处理结果能否回写，并让流程从断点继续；
- 同一类例外反复出现时，是否有入口把它收敛成规则；
- 流程停摆超过一定时间，是否有提醒和升级路径。
这些内容听起来像“配套功能”，实际是自动化工作流的主体。没有它们，系统只是在正常路径上跑得快；有了它们，异常路径才不会把节省下来的时间又吐回去。
留一个退出按钮
人工兜底不是失败，而是设计的一部分。关键在于兜底要可预期：谁能暂停流程、暂停后状态如何标记、恢复时是否需要重新校验。若退出机制含糊，操作者会绕开系统，用聊天消息和表格私下补位，流程表面还在，实际已经分叉。
维护成本也常被低估。规则会过期，接口会变化，组织调整会让某个审批节点失去意义。一条自动化工作流是否耐用，不只看搭建那天有多顺，也看三个月后是否有人知道某条分支为什么存在。给每条分支留下简短说明和负责人，复杂编排才有维护的余地。
我的判断是，这类系统的价值不在于把人完全移出流程，而在于把人的注意力挪到需要判断的位置。重复动作交给系统，例外交给人，交接处留下清楚的痕迹。系统不必假装无所不能；它只需要在该停的时候停稳，在该继续的时候接得上。