一张客户需求登记表提交后，系统自动建任务、发通知、归档。演示时，这条链路看起来干脆利落。真正上线几周，问题往往从边角冒出来：客户名称填错，通知发给了无关的人；附件缺失，任务却已经流转到下一环；有人临时改了字段，旧规则还在按原样执行。
连起来，不等于跑得稳
自动化工作流常被理解成“触发器—条件—动作”的拼接：表单提交触发动作，条件判断决定走向，若干节点串成一条线。这套模型足够表达常规路径，却很难预先写尽现实中的分支。流程一旦跑起来，例外不会消失，只会换一种方式出现。它们可能停在失败日志里，也可能被同事用私聊、表格和手动补录悄悄接住。
一套可靠的自动化工作流，需要把例外当作流程的一部分，而不是故障附录。谁接收失败任务，多久内处理，处理结果如何回写，原始数据是否保留，回滚由谁触发——这些问题不解决，节点连得再多，也只是把等待从一处挪到另一处。
省步骤之外，还要省注意力
很多流程改造容易盯着点击次数：少填一个字段，少开一个页面，少发一条消息。但人的消耗常发生在上下文切换。通知弹出，同事要判断它属于哪类任务、该看哪份资料、是否需要拉人确认。自动化如果只把消息转发出去，判断成本仍留在人这边。
一种做法，是把规则能确定的部分先做掉，再把不确定的部分整理成可判断的选项。例如自动补齐已知信息、标注缺失项、把相关记录放在同一处，并留下人工确认的入口。机器负责搬运和校验，人负责取舍。这种分工不新鲜，却常被“全自动”的叙事盖过去。
边界要写进流程
并非所有环节都适合交给机器。涉及规则解释、责任归属、对外承诺的动作，保留人工确认。但也别把“人工兜底”当成万能补丁：如果例外队列没有负责人、没有时限、没有回看机制，它很快会变成新的堆积点。
- 为失败任务设置明确的接收人和处理时限，而不是只发一条告警。
- 保留关键字段的变更记录，让回查有依据。
- 把人工确认设计成流程节点，而不是流程外的私聊。
- 定期查看例外类型，判断是规则缺失，还是流程本身需要调整。
这些动作不显眼，却决定自动化工作流能否长期运行。流程的价值不在于一次演示多顺滑，而在于遇到偏差时，系统能否把问题交到合适的人手里，并留下可追溯的痕迹。
把审批流交给机器之前，先问一句：例外发生时，谁接得住？如果答案还模糊，那条流程大概只是看起来跑通了。