那张表不在流程图里
设想一个小团队，把审批、提醒、单据同步串成一条流程。流程图很干净，箭头从左到右，节点各有名字。运行几个月后，有人开始维护一张表：谁改过字段、哪个条件被临时放宽、哪类请求要人工绕过。它不在白板上，也不属于任何一个系统。每次自动化工作流报错，大家先翻这张表。它像流程的影子，平时没人提，出事时会被想起。
这大概是自动化工作流常被低估的部分。搭建阶段关注节点能不能连上、接口通不通；上线之后，问题往往变成另一类：字段含义变了，临时规则没人回收，通知发给了已经离岗的账号。它们不属于某个单独环节，却会在链条里来回放大。
把流程跑通，不等于把工作交出去。异常处理如果只靠群里喊人，自动化就会变成更快的打断。一个提醒失败，背后可能是权限过期；一次同步为空，可能是上游把字段改成了新名称。系统只负责执行条件，理解条件的人还得在线。
因此我更愿意把自动化工作流看成一段需要养护的公共设施，而不是一次性项目。养护包括：谁有权改流程、改动如何记录、异常由谁接、多久清理一次临时分支。把这些写下来不显得聪明，却能减少很多“上次还能跑”的争论。
人机交接处，需要留一个缓冲
有些环节适合交给规则，有些环节适合留给人。分界不在技术难度，而在责任是否清晰。比如对外承诺、权限变更、内容发布，即使能自动执行，也值得保留确认动作。确认不是不信任系统，而是让责任有落点。
设计流程时，可以问三个具体问题：失败后谁知道？三天后谁回看？规则过期谁负责删？这些问题没有通用答案，但如果没有答案，流程越顺，后面越容易堆出无人认领的角落。
把维护写进流程
一个可行的做法，是在流程之外保留一份轻量的变更说明：这次为什么加条件、预期多久、失效后通知谁。它不需要复杂工具，哪怕是一段共享文档，只要和流程放在一起，就能让后来者知道边界在哪里。流程的价值，往往不在第一次跑通，而在半年后还有人敢改。
自动化不会消灭工作，它只是把工作挪到别处：从点击按钮，挪到定义条件；从处理单条请求，挪到处理异常和边界。愿意承认这部分劳动，流程才有机会稳定下来。否则，那张看不见的表会一直存在，只是换一个人维护。