有一次看朋友调试一条自动化工作流，脚本没问题，接口也没报错，可任务就是在某个节点停住。查了半天，原因很朴素：上一环节输出的字段名，和下一环节期待的差了两个字。人眼看一眼就明白的事，机器认死理，于是整条链路卡在那里。
这类事故听起来琐碎，却几乎每天都在发生。很多团队对自动化的想象是“把重复劳动交给机器”，真做起来才发现，重复劳动之所以重复，往往因为中间藏着一堆没写下来的默契。
难的不是连起来，是连起来之后还说得清
搭建一条自动化工作流的门槛已经很低。触发器、条件判断、动作节点，拖拽几下就能连成一条线。问题在于，工具解决的是“能不能连”，而业务关心的是“连起来之后，出了偏差怎么办”。
我见过一种常见做法：先把顺畅路径跑通，异常情况留给人来兜。这在早期无可厚非，可一旦流程被高频调用，人的兜底就会变成瓶颈。更麻烦的是，兜底的人往往不是设计流程的人，他看到的只是一条失败记录，不知道上游为什么长这样。
所以判断一条流程是否值得自动化，我的习惯是先问三个问题：触发条件是否唯一可判？异常分支是否穷举得出来？出错后由谁接手、依据什么判断？三个问题里有两个答不上来，我倾向于先别急着上工具。
触发条件写得太宽，等于给自己埋雷
触发器是自动化工作流最容易写松的地方。为了省事，很多人用模糊条件开局，比如“收到邮件就处理”“文件有更新就同步”。在测试环境里一切正常，上了真实环境，噪音立刻涌进来。
比较稳妥的做法，是把触发条件写得窄一点，宁可多写几条规则，也不要一条规则覆盖所有情况。窄条件的代价是维护成本，收益是每一次触发都可解释。可解释性在流程出问题时格外值钱——你能迅速定位是哪条规则误判，而不是对着一屏日志猜。
- 触发条件尽量带上具体来源、具体字段或具体状态，避免“任意”式描述。
- 对同一类事件的不同来源分开建规则，后续调整时互不牵连。
- 给规则留一句备注，写清它为什么存在，半年后回看会感谢自己。
异常分支才是流程的主体
顺畅路径通常只占设计工作的一小部分。真正耗神的，是把那些“偶尔发生但必须处理”的情况想全：字段为空、重复提交、超时未响应、上游改了格式、下游暂时不可用。
我不是主张把每条分支都做成自动处理。有些异常天然需要人判断，硬塞给机器只会把错误放大。合理的分工是：机器负责识别和归类，人负责决策。比如让流程在遇到无法归类的输入时，自动挂起并附上上下文，而不是强行猜一个结果继续往下走。
这也解释了为什么有些团队上线自动化工作流之后，反而更忙。不是工具不好用，而是流程从来没有被认真梳理过，自动化只是把原本散落在各处的模糊，集中暴露在一条链路上。
人工兜底不是退步，是设计的一部分
谈自动化时容易产生一种错觉，仿佛人介入越少越先进。我的看法相反：人该出现在需要承担责任的位置，而不是被当成效率的敌人。
一条成熟的流程，通常会明确标出哪些节点可以放手，哪些节点必须留一道人工确认。这道确认不是为了拖慢速度，而是为了让结果有人认领。尤其在涉及对外输出、变更生效这类动作时，多一次确认的成本，远低于一次错误造成的返工。
另一个容易被忽略的点是交接。流程从一个系统走到另一个系统，中间的信息损耗往往比想象中大。字段类型变了、时间格式不一致、状态值对不上，这些细节不会在流程图里显示，却会在运行时制造麻烦。设计时多花十分钟对齐字段，能省下后面几小时的排查。
先让流程能被讲清楚，再谈让它自己跑
回到开头那条卡住的工作流。最后解决它的办法不是改脚本，而是把两个环节的负责人叫到一起，用一张纸把输入输出的字段逐个对齐。半小时的沟通，解决了几天调试没找到的问题。
这大概是我对自动化最朴素的判断：它奖励那些原本就想得清楚的团队，也会毫不客气地暴露那些靠默契运转的环节。工具在进步，搭建越来越简单，但流程本身的清晰度，仍然要人来完成。与其急着让工作流跑起来，不如先确认一件事——如果不用工具，这条流程你能完整讲给一个新人听吗？