早上打开电脑，消息框里躺着一串“已自动处理”的提示。流程跑得很顺，直到某个字段为空，整条链路停在半路，没人知道该找谁。很多团队对自动化工作流的想象，正是从这种落差开始的。
工具能把表单、通知、审批、文档串起来，这并不难。难的是串联之后，系统开始替人做判断：什么算完成，什么算异常，异常出现时是重试、跳过，还是交回给人。规则写得越细，例外越容易从缝隙里冒出来；规则写得太粗，自动化就成了“看起来跑过”的摆设。
例外不是噪音，而是流程的一部分
把自动化工作流当成一条直线，容易忽略它其实由许多交接点组成。每个交接点都在问同一个问题：信息够不够清楚，责任有没有落地。若只盯着“能不能自动”，就容易把例外当成故障；可例外往往在提示规则本身不完整。与其追求一次覆盖所有情况，不如先让例外可见：记录它从哪一步进入，停在哪一步，最后由谁接住。
这也是观察自动化是否成熟的一个角度。顺利时没人注意，出问题时却能快速定位，已经足够说明问题。没有日志、没有失败通知、没有人工入口的流程，表面上省了操作，实际上把不确定性藏到了更晚的地方。
先决定哪些事不该自动
并非所有环节都适合交给自动化工作流。输入稳定、规则明确、出错代价可控的任务，适合先跑起来；需要大量上下文、判断标准会变、返工成本高的任务，可以保留人工确认。这个边界不必一次划清，可以在运行中调整。重要的是，别把“自动”当成目标本身。
- 把完成和失败写成可检查的条件，而不是模糊描述。
- 给每个自动化环节留一个能停下来的人工入口。
- 让异常通知带上上下文，减少来回追问。
- 定期回看被跳过的步骤，判断规则是否该改。
我更愿意把自动化工作流看成一种协作约定：机器处理重复动作，人负责定义边界和处理意外。约定清楚，流程才会安静地运转；约定含糊，再漂亮的连线图也只是把混乱搬到了后台。真正值得关注的，不是它连接了多少工具，而是当事情不按预期发生时，系统有没有给人留下一条回去的路。