周一早上七点半，一封汇总邮件准时进了收件箱。写这封邮件的人，八点半才打开电脑。这中间的一个小时里，没有人偷懒；只是“整理、核对、发出去”这件事，从人的日程里挪走了。
很多人对自动化工作流的想象停在这里：接上几个节点，把重复动作交给机器，人腾出手做更重要的事。这个想象不算错，但它只描述了开头。
它擅长的是“不用想”的部分
把一条流程拆开看，里面其实混着两类动作。一类是判断已经做完、只剩执行的，比如把表单里的字段搬到另一张表，比如在状态变成“已完成”之后通知相关的人。另一类则要临场决定：这条数据看着不对，是先拦下来还是先放过去；这个人不在，该找谁顶替。
自动化工作流在第一类动作里几乎不会出错，因为条件明确、分支有限、结果可判定。到了第二类，它就显得局促：倒不是做不到，而是每加一个“看情况”，流程里就多一处需要人维护的判断。写规则的人越多，规则之间的缝隙也越多。
复杂度不会消失，只会换个地方出现
一条链路搭起来通常很快，一两个小时能跑通。难的是让它半年后还能跑。凭证会过期，上游系统会改字段名，某个接口偶尔超时，某天数据量突然翻了几倍。这些事不会天天发生，但只要有几次，就得有人半夜被叫起来。
于是出现一种微妙的分工转移：原本做事的人，变成了照看流程的人。盯失败日志、补重试、改分支条件、给新来的同事解释这条线为什么这么连。工作量未必减少，只是从“执行”变成了“维护”。这部分经常不计入当初的收益估算里。
省下来的时间去了哪里，也值得追问。如果它立刻被新的任务填满，那么自动化带来的就不是空闲，而是节奏变快。对组织来说这未必是坏事；但对具体的人来说，如果没人说清楚收益怎么分配，感受上更接近“事情变多了”。
先让它会失败，再让它跑起来
我的看法是，判断一条流程该不该自动化，看的不是它有多长，而是两件事：它出现的频率，以及每次判断的难度。高频、判断成本低的，交出去几乎没有争议；低频但每次都要重新想的，硬塞进流程里，规则会越写越厚，最后没人敢改。
还有一条常被跳过：失败要能被看见。静默失败的流程比不自动化更麻烦，因为没人知道它没跑，直到某天有人问“这个月的表怎么还没来”。所以重试要有上限，重复执行要不出副作用，出错时要有一个人能接手的位置。这几件事做在前面，比多接几个节点实在。
自动化工作流真正考验的，往往不是工具选型，而是愿不愿意承认流程里有一部分本来就说不清楚。把这些部分留给人，并不丢人；把它们硬写成规则，才是后面所有麻烦的起点。
所以每次讨论“还能自动化什么”的时候，我总想先问另一句：自动化之后，谁来照看它。这个问题答不上来，链路接得再顺，也只是把问题往后推了一段。