很多人第一次把自动化工作流跑通时，会有一种轻微的错觉：事情终于自己动起来了。表单提交后自动建单，建单后自动通知，通知后自动归档，屏幕上的进度条一格一格往前走，像一条不需要人看管的传送带。
但跑上一两周，问题往往出现在同一个地方——那条线在等人。
卡住整条线的，常常是一个“确认”
把流程画在白板上时，最容易被低估的环节是审批。它看起来只是一个方框，写着一行小字：等待确认。可一旦这条线进入真实业务，这个方框会变成整条链路里最不确定的一段。机器执行一步是毫秒级，人做一次判断可能是半天。
于是就出现一种反差：自动化程度越高，等待越显眼。以前人工处理时，慢是均匀的慢，大家习以为常；现在前后都提速了，唯一没提速的那一环反而被放大。有人把这归咎于“人不够快”，但更准确的说法是，流程设计者把人和机器放在了同一条时间尺度上考虑，而它们本来就不在同一个尺度上。
处理这件事的思路，通常不是催人，而是改线。一种做法是把确认动作拆细：真正需要人判断的只是少数边界情况，其余按规则自动放行；另一种做法是把等待显性化，让上游知道当前卡在谁那里、卡了多久，而不是让整条线安静地停在某个看不见的角落。前者减少等待发生的次数，后者减少等待造成的混乱。
异常回流比正常路径更考验设计
正常路径通常好写。真正吃时间的是异常：字段缺了、附件格式不对、下游系统临时不可用。人工处理时，这些情况靠经验兜底，处理者顺手改一下、补一句说明就过去了。搬到自动化工作流上，兜底动作必须被显式地设计出来，否则流程只会停在报错页，然后等人去发现。
这里有个常被忽略的细节：异常不只要被捕获，还要被送回一个合适的位置。全部退回起点，等于让已经完成的工作重来一遍；全部原地挂起，又会让队列越积越长。比较稳妥的做法是给异常分级——能在当前环节补齐的就地解决，需要上游决策的退回到最近一个可控节点，需要外部条件的转入待处理池并设定复查节奏。分级本身不复杂，复杂的是事先想清楚每一级由谁负责。
- 报错信息写给谁看：是写给排障的工程师，还是写给补数据的业务同事，决定了错误提示该详细到什么程度。
- 重试要不要有上限：无上限的重试会把一次故障放大成持续的资源消耗。
- 人工介入是否留痕：介入动作如果没被记录下来，后续复盘就只剩猜测。
看得见，才谈得上信任
自动化工作流跑起来之后，团队对它的态度往往经历一个变化：从兴奋，到不放心，再到有条件地信任。推动这个变化的不是流程本身多聪明，而是它是否可被观察。一条看不见内部状态的流水线，出问题时只能靠人猜；而一条能说清“现在走到哪、上一步用了多久、失败过几次”的流水线，即便偶尔出错，也容易被接受。
可观测性听起来像技术词，落到实处却很朴素：每一步有记录，每次失败有原因，每个等待有归属。这些东西不会让流程跑得更快，但会让人敢把更多事情交给它。反过来说，如果一条线只能看到最终成功或失败，中间是黑箱，那么再多环节的自动化，实际使用中也会被人为地加回几道人工核对。
边界在哪里
需要承认的是，并非所有环节都适合自动化。判断标准通常不在技术可行性，而在错误的代价和责任的归属。代价低、可回退、责任清晰的步骤，交出去比较放心；一旦涉及对外承诺、不可逆操作或需要承担判断后果的决定，保留人工节点反而是更稳的选择。
所以讨论自动化工作流时，与其问“还能自动化多少”，不如问“哪些地方必须留人”。把这句话想清楚，流程的形状往往会变简单：人守在少数关键位置上，机器负责其余的路程，两边都不用假装对方的速度。
那条传送带不必一直转得飞快才算成功。它能在该停的地方停住，在该走的时候走完，已经比大多数追求“全自动”的方案更接近可用。