把日报生成、审批提醒、内容分发串成一条链路，流程图看上去很顺：触发器亮起，节点依次通过。真正让人停下来的，常常是末端那个“请确认”按钮。
这不是否定自动化工作流。它擅长处理确定性高、重复性强的步骤，也擅长把分散的系统连起来。问题在于，流程一旦跨过系统边界，进入人的判断区域，设计者就得换一种思路：不是把人工节点删掉，而是把它放在可解释、可追踪的位置。
交接处比中间段更容易失控
节点之间传参数，通常有明确格式；人把任务交给流程，或流程把结果交给人，信息却容易变形。邮件里一句“按上次口径处理”，在流程里可能变成缺失字段；审批人临时出差，任务就停在待办列表里。自动化工作流需要为这些停顿留位置：谁接手、超时怎么办、退回后回到哪一步、附带的上下文是否完整。
有些团队把人工节点当成临时补丁，等流程跑顺了再拆掉。实际运行中，人工确认往往承担着责任划分和异常兜底的功能。把它删干净，流程可能更快，但出了偏差很难追溯。保留一个轻量确认点，同时把确认依据写清楚，反而更稳。
异常队列不是附属品
流程设计容易把注意力放在正常路径上：触发、判断、执行、通知。异常路径却决定它能不能长期运行。接口超时、权限过期、字段缺失、重复触发，这些情况不会因为流程图好看就消失。与其在每个节点里塞重试，不如单独设一个异常队列，记录失败原因、重试次数和当前上下文，让人能接手，也能让流程继续。
这里有个容易被忽略的细节：重试不等于恢复。一次发送动作失败后重试，可能造成重复发送；一次状态更新超时后重试，可能覆盖别人的修改。流程编排需要幂等设计，也需要在关键动作前留检查点。否则自动化越深，清理现场的成本越高。
维护成本藏在依赖里
一条流程刚上线时，节点少、依赖清晰。过一阵子，接口字段改了，权限策略调整了，通知模板换版了，流程图还是那张图，运行结果却开始漂移。维护自动化工作流，很多时候不是改节点，而是排查节点背后的依赖：哪个字段来自哪个系统，哪一步依赖人工填写的备注，哪个通知渠道已经不再使用。
这也解释了为什么流程文档不能只画方框和箭头。至少要写清楚输入输出、失败处理、责任人、回滚方式。文档不必厚重，但要能让接手的人知道从哪里查起。
先画停机方案，再谈无人值守
自动化工作流的价值不在于把人都赶出流程，而在于让人只在必要的位置出现。设计时可以先问几个问题：哪一步必须有人签字？系统不可用时，任务退回哪里？重复触发如何识别？权限变更后，哪些节点会失效？这些问题不解决，流程跑得越快，偏差扩散得越远。
一个可操作的顺序是：先把人工交接点标出来，再为异常路径留队列，最后补上日志和回滚。顺序反过来也能做，但容易把自动化做成一条脆弱的直线。流程图上多一个分支，运行时可能少一次深夜排查。
下次画流程图，不妨先停在那个“请确认”按钮前，问一句：如果这个人不在，流程应该怎么走？