见过一个挺典型的场面：一个报销单在系统里转了三天，状态一直停在“待审批”。没人收到提醒，审批人也没觉得自己漏了什么——因为按规则，金额超过某个数才需要他点一下，而这张单子刚好卡在两条规则的缝里。系统不认为它出错，人也不认为它出错，单子就这么悬着。
这类事情在自动化工作流里不算罕见。流程跑得顺的时候，大家看到的是速度；一旦碰到规则没覆盖的边角，暴露的往往是设计时没想清楚的问题。
顺的时候看不出问题，卡一次就全露出来
自动化工作流的基本思路并不复杂：把重复的判断和转交固定成规则，让事情自己往前走。它擅长处理那些边界清晰、条件明确的环节，比如表单校验、状态流转、定时提醒。问题在于，真实业务里总有一部分内容是模糊的——金额该不该特批、这份材料算不算齐全、这次延期要不要追究，这些判断往往依赖上下文，而不是一个字段。
设计流程的人容易把注意力放在主路径上：正常情况下怎么走、几步能完成。异常路径则常被压缩成一句“人工处理”，至于谁来处理、多久处理、处理不了怎么办，写得含糊。于是流程越自动化，异常就越像被藏起来，直到某天冒出来，才发现没有出口。
被省掉的那部分，往往是判断
有个容易被忽视的成本：自动化把执行变快了，但判断并没有消失，只是被推到了流程设计阶段。以前一个人处理十张单子，每张都顺手判断一下；现在规则替他判断，他只处理规则判断不了的那一张。听起来省事了，可一旦规则写得不合适，错误会被批量复制，而且不容易被发现——因为每一步都在“正常”执行。
所以流程设计里真正难的部分，不是把步骤连起来，而是想清楚哪些条件必须写死，哪些要留出人来拍板。写死的部分越多，流程越稳定，也越僵硬；留白越多，灵活性上去了，人对流程的依赖反而更强。这个取舍没法一次定好，它需要随着业务变化反复调整。
让流程能停下来，也是一种能力
很多团队在设计时会默认一个前提：流程应该尽量不中断。但中断本身不一定是坏事。关键是中断之后有没有明确的下一步——通知谁、给多少信息、允许多长时间、超时怎么升级。如果这些都没有，中断就变成了悬置。
比较务实的做法，是在流程里显式地设置几类出口：正常的完成状态、需要人补充信息的等待状态、以及无法继续时的挂起状态。挂起不是失败，它意味着系统承认自己处理不了，把决定权交回去。承认处理不了，比假装处理完了要诚实，也更容易维护。
- 明确哪些异常必须由人介入，而不是笼统写“人工处理”
- 为等待和挂起设定时限，以及超时后的去处
- 记录每次人工介入的原因，作为后续调整规则的依据
人留在流程里的位置
讨论自动化工作流时，常有一种隐含的期待：最好人什么都不用管。但实际运行下来，人并没有消失，只是换了个位置——从执行者变成了规则的维护者和异常的处理者。这个位置听起来更轻松，实际上要求更高：需要理解流程在做什么，也需要判断什么时候该改规则。
这带来一个现实问题：如果团队里没人真正清楚规则是怎么写的，流程跑得越久，维护成本就越高。文档、命名、变更记录这些看起来琐碎的东西，在流程出问题时决定了能不能快速定位。它们不产生直接产出，却决定了流程能不能被放心地改动。
自动化工作流能省掉重复劳动，这一点没有疑问。但它省不掉的是对业务的梳理和对边界的判断。把这些前置工作做扎实，流程才跑得久；指望流程自己兜住所有意外，通常会在某张卡住的单子上收到提醒。