早上打开协作工具，先看到的不是日报，而是一串流程失败通知。原本想省掉手工汇总，结果通知比日报还准时。这个场景不新鲜：演示时，自动化工作流从表单提交跑到通知、写表、发邮件，一路顺畅；上线后，输入格式变了，权限过期了，接口偶尔超时，流程就卡在某个节点上。
问题往往不在“能不能连起来”。连接只是起点。真正消耗人的，是连起来之后那些没有被设计的岔路。
机器不会“看着办”
自动化工作流执行的是条件，不是意图。人看到一条缺了字段的记录，会去翻聊天记录、问提交人、顺手补上；机器看到空值，只会按规则继续，或者停在报错里。于是，原本用来减少重复劳动的东西，可能带来新的重复劳动：查日志、重跑、补数据、解释为什么没发出去。
这不是说流程不该做。它适合高频、规则稳定、异常可以枚举的环节。低频、规则常变、责任又重的环节，硬塞进流程里，维护成本会慢慢显出来。判断一个环节要不要交给机器，可以先看三个问题：
- 完成条件是否明确？如果“做完了”需要人凭经验判断，流程就很难收尾。
- 出错后能否回到原状？写错表、发错通知、改错状态，能不能撤回或补偿。
- 失败时人能否知道卡在哪？只收到“执行失败”四个字，等于没有信息。
这三个问题不解决，流程越自动，排查越像手工。
给异常留一个人工出口
很多人把人工确认看成自动化的反面。我的看法不同：在关键动作前保留确认节点，是在给异常留出口。对外发送、修改重要记录、跨系统同步，这些动作一旦出错，回头成本高。让机器把材料准备好、把校验做完，再由人点一下确认，并不丢人。它换来的是可控。
确认节点也要克制。如果每一步都等人，流程会变成排队；如果完全不等，异常就会直接流到下游。可以尝试的做法是，把确认放在不可逆的动作之前，把自动处理放在可回滚的搬运上。机器负责重复和搬运，人负责判断和兜底。
失败通知要带上下文
不少流程的日志里只有一行“节点执行失败”。这种通知发出来，除了制造焦虑，帮助有限。有用的失败信息至少要说清三件事：哪条记录、卡在哪个环节、当时拿到了什么输入。这样人打开通知就能判断，是重试、补数据，还是先停掉流程。
可观测性听起来像技术词，落到日常就是：失败可定位，重跑可追踪，结果可核对。没有这些，流程只是把手工操作换成了手工排查。流程跑得越快，错误传播得也越快，所以观测不是附属功能，而是流程的一部分。
回到开头那个早上。把失败通知改成带上下文的卡片，增加重试和人工确认节点，流程才可能慢慢稳定。它仍然会出错，但出错时不再是一团雾。自动化工作流的价值，不是让人从流程里消失，而是让人从重复操作里抽身，去处理机器判断不了的部分。少一点“全自动”的想象，多画几条失败路径，流程才可能真正省事。