一个团队把每周的数据汇总做成了流程：几个来源自动取数、清洗、拼表、发进群。头两周确实省事。第三周某个来源改了字段名，流程照常跑完，只是结果空了一列。没人收到提醒——因为流程本身没坏。等有人发现，已经用错了两期。
这类事见得多了，会发现一个共同点：出问题的不是那些画得最复杂的节点，而是没人盯着的接缝。
跑通和跑得住，是两件事
搭一个流程，最兴奋的时刻往往是第一次端到端跑完。屏幕上绿灯亮起，人会觉得事情成了。但演示环境和日常运行之间隔着一段很长的时间：来源会变，权限会过期，某一步的返回值会从空字符串变成 null，某个接口会在凌晨两点超时。这些都不是设计缺陷，是运行环境本来的样子。
所以判断一条自动化工作流是否真的站住了，标准不是「能不能跑」，而是「出错的时候，谁会在多久内知道」。这个问题答不上来，后面所有的效率测算都缺少实际支撑。
例外才是成本所在
规则能处理的部分通常很规整：字段固定、路径单一、量足够大。麻烦在于剩下的那一小截——格式不对的输入、需要人判断的边界情况、只能口头确认的例外。它们占比不高，却最容易拖垮整条链路。
常见的处理方式有两种，各有代价。一种是硬编码，把所有能想到的例外都写进分支，结果是流程越来越臃肿，改一次要动好几处，最后没人敢碰。另一种是干脆不管，让例外直接失败中断，结果是使用者碰到两次卡壳，就绕开流程自己动手了。
更可行的做法，是把例外显式地接住：失败时保留原始输入，交给一个明确的人，并记录是谁、在什么时候处理了什么。这样流程不追求覆盖全部情况，只保证不确定的部分有去处。
- 失败必须留痕，而不是静默跳过
- 每个环节有明确的责任人，而不是「大家一起看」
- 重复执行不会产生重复结果，重试才是安全的
它挪动的是判断，不是取消判断
有段时间流行一种说法，认为自动化工作流的目标是把人从流程里拿掉。实际做下来，人并没有消失，只是换了位置——从执行步骤的人，变成设计规则和处理例外的人。这个位移本身有代价：设计规则需要的抽象能力，比照着清单操作要高；而一旦规则写错，影响面也比单个操作失误大得多。
所以有些环节不适合塞进流程。发生频率低、每次判断都不一样、做错的代价又说不清楚的，硬做成自动化，只是把成本从操作转移到了维护和排查上，账面上不一定划算。反过来，高频、变化小、失败信号清晰的事情，哪怕看起来琐碎，也值得先做。
最后回到开头那个空了一列的表。它提醒的其实是一件很朴素的事：流程不会自己变得可信，可信是被人一次次确认出来的。在扩大一条自动化工作流的覆盖范围之前，先想清楚它在什么地方会安静地出错——这个问题比多接几个系统重要得多。