凌晨两点，一条流程跑完了。它把表单里的字段搬进数据库，通知了三个人，关掉了工单。第二天早上，没有人为此鼓掌，倒是有人问了一句：昨天那条没走完的单子，卡在哪儿了？
这是把自动化接进业务之后常见的落差。系统“跑通”是技术意义上的完成，业务意义上的完成要复杂得多：结果对、过程可查、出错有人接着处理。第一件事写代码能解决，后两件往往要重新安排人和制度的位置。
它到底替掉了什么
多数人对自动化的想象是替代一个人。实际更像是把几个系统之间的衔接换成程序：读一个接口、判断条件、写另一个接口、失败重试。这些动作原本由人做，做得慢、做得烦，但也正因为由人做，遇到不合常理的情况会停下来问一句。
程序不会问。它按分支走，遇到没写过的分支就报错、跳过，或者更麻烦：按默认值写下去。于是手工流程里的“犹豫”消失了，而这个犹豫往往正是质量控制发生的地方。
流程尾部比主干更长
一条流程的正常路径通常很短，三五个节点就能画完。真正耗时的是尾部那些异常：某个字段为空、某个接口偶发超时、某条记录被两个人同时改。这些情况加起来占比不大，却决定了这套东西能不能长期无人值守地跑。
- 重试要有上限，也要区分“重试有用”和“重试只会把错误重复三遍”；
- 每一步的输入输出要留痕，否则出问题时只能从头复现；
- 失败之后由谁接手，必须在流程设计时就写清楚，而不是等出事再临时找人。
这三件事都不难，但都容易被跳过，因为它们不产生“跑通了”的成就感。而自动化工作流的维护成本，几乎全部藏在这些被跳过的地方。
人没有消失，只是换了位置
我倾向于认为，成熟的自动化不是让人退出流程，而是把人从执行环节挪到判断环节：机器负责高频、确定、可枚举的部分，人负责处理那些脚本没预料到的少数。问题在于，很多团队只搬走了执行，却没有为判断留出时间和入口。结果是流程一旦报错，所有人都在找那个唯一知道怎么处理的人，而这个人往往就是当初写脚本的人。
这带来一个不太被讨论的风险：知识重新集中到个别人手里。原来流程散在几个人手上，谁都能接手；自动化之后，规则写进代码，理解成本反而变高。要缓解这点，文档和日志得跟流程一起交付，而不是事后补。
该不该交给机器
不是所有流程都值得自动化。判断标准不在技术难度，而在变化频率和责任归属：步骤稳定、结果可验证、出错能回滚的，适合；规则每周都在改、判断依赖经验、出了错后果难以挽回的，先放一放。
还有一点常被忽略：可观测性不是附加项。一条没人看着的流程，如果失败时悄无声息，它的可靠性等于零。日志、告警、失败队列，这些看起来不“智能”的东西，才是自动化能长期跑下去的前提。
所以回到凌晨两点那条跑完的流程。它跑通与否，其实不是最重要的问题。真正该问的是：如果它今天没跑通，早上有没有人会知道，知不知道该找谁。能把这两个问题回答清楚，再谈把更多环节交出去，也不迟。