早上打开电脑，消息框里躺着一串“已自动处理”的提示。看上去一切顺畅，直到有人问：那条被系统跳过记录的为什么没进下一步？这类问题并不戏剧化，却常出现在自动化工作流进入日常之后。流程跑起来的那一刻，麻烦才真正开始。
把步骤串起来，只是开始
很多人对自动化的第一印象，是把重复动作连成一条线：表单提交后发通知，文件到位后归档，状态变化后同步到另一套系统。单看每一步都不复杂，难的是这些步骤之间的条件。触发条件写得含糊，流程就会在边界处打转；字段含义没有对齐，后面接得再多也只是把误差传下去。我倾向于先把“什么情况下不该自动跑”写清楚，再讨论能自动跑多少。自动化工作流的价值，往往不在于动作多，而在于规则能被看懂、被修改、被追查。
异常分支才是日常
演示时，流程通常沿着顺利路径走；真实使用中，缺字段、重复提交、外部系统无响应、权限变更，都会让流程停在某个节点。若只关注主路径，异常就会变成人工补救的黑洞。设计时可以把异常分成几类：能自动重试的，等待一阵再走；需要补信息的，退回给发起人；会污染后续数据的，先挂起并留下记录。这些处理不一定复杂，但要在流程图里显性写出来，而不是藏在脚本注释里。自动化工作流真正考验的，是异常发生时，系统能不能把问题说清楚，而不是只在日志里丢下一行报错。
人该站在哪里
有些环节适合机器推进，有些环节需要人做判断。审批、对外发送、涉及权限变更的操作，设置人工复核点并不丢人，反而是流程可维护的一部分。关键是把复核点放在信息足够完整的位置：人看到的不是一堆原始字段，而是触发原因、已执行动作和待确认事项。否则复核会变成机械点“通过”，流程看似闭环，责任却悬空。我也不太赞成把自动化工作流当成万能开关。它适合承接稳定、可描述、可回滚的步骤；遇到规则频繁变化、后果难以撤回的任务，先保留人工介入，可能比强行上线更稳妥。
回到开头那个问题，答案通常不在脚本写得多巧，而在流程设计时有没有为“卡住”留位置。能让一条流程停下来、说清楚、再继续，往往比让它一直跑下去更重要。