两个工程师的同一天
A 是某互联网公司的流程经理。去年花了半年时间梳理"统一请假审批流程"，目标是把平均审批时长从 6 天压到 2 天以内。上线半年后内部调研结果让人哭笑不得：平均每次请假要走 4.7 天才能完成审批链。
她去看后台数据，发现流程在第 3 个节点之后就开始"卡"——不是审批人不在，而是审批人不知道这单该不该自己批。审批人开始打电话问隔壁部门的同事"按惯例你们 Q3 这种合同怎么批"，打电话找不到人就拉个会议专门协调。
B 是某团队的 SRE。今年花了两个月把公司的发布流程改造成 Jenkinsfile 。两个月后他们统计：每次发布平均要花 2.5 小时才能走完流水线——其中 1.5 小时是在等"上游镜像构建失败"的错误信息传到 stage 5。
他去看 pipeline 日志，发现 stage 1 拉镜像失败之后，stage 2/3/4 还在傻跑，等跑到 stage 5 才报错。流水线跑得越长，等待时间越多。
两个人在不同领域做优化，最后列出的"问题清单"惊人地相似。
- 审批流程要靠打电话、开会、发邮件才能走通。
- 发布流水线要跑到最后一步才发现第一步出错。
- 流程图里塞了不该有的业务数据。
- Jenkinsfile 里塞了不该有的业务规则。
这不是巧合。A 和 B 碰到的是同一个老问题的不同侧面。
第一个坑：业务规则出现在不该出现的地方
流程侧的糟心例
某公司的合同审批节点，审批人要在系统里手动判断"这单合同是否超过部门 Q3 预算"。
审批人该做的决定是"批 / 不批"。但系统逼他做了第二个决定——"算不算超预算"。
审批人不是财务，业务判断跑到了不该出现的地方。结果是：
- 审批速度变慢——审批人要查预算、翻历史数据。
- 判断标准不一致——每个审批人口径不同，有的宽松有的严格。
- 出了错没人负责——超预算的合同签了，所有审批人都会说"我以为财务算过"。
流水线侧的糟心例
同一个团队改造的发布流水线，Jenkinsfile 的 deploy stage 里塞了一段判断"这次部署是否冲突下个季度的产品发布窗口"。
pipeline 该做的是"构建产物 + 推到目标环境"。但它偷偷干了"判断发布时机"这种业务规则。
结果是：
- pipeline 越长、业务人员越看不懂。
- 出了错不知道是构建的错还是业务的错。
- 业务规则改一次，pipeline 要跟着改一次。
共同的发现
两边都在"该做决定的人/系统"身上塞了"不该做的决定"。
审批节点该做的是"按业务规则执行"，不是"自己造业务规则"。
pipeline 该做的是"按规矩跑构建"，不是"自己定规矩"。
判断归决策层，执行归执行层。审批节点是执行层，pipeline 是执行层，它们都不该做判断。
第二个坑：错误被拖到最后才暴露
流程侧的糟心例
某 OA 系统的报销流程有 8 个节点。员工小王填了第 2 步"项目编号"——手抖填错。
流程继续往下走，到第 8 步才被退回，理由是"项目编号无效"。此时小王已经等了 5 天，前面 6 个审批人也都白签了。
错得越晚发现，整个流程浪费得越厉害。小王后来学乖了，每次报销前先打电话问财务"项目编号怎么填"，又给财务增加了工作量。
流水线侧的糟心例
同一个团队的 Jenkinsfile 有 5 个 stage：lint → test → build → package → deploy。某次发布因为第一个 stage 用的基础镜像 tag 被误删，结果跑到 stage 5 才报错"找不到镜像"——前面 4 个 stage 全跑了 30 分钟才白费。
错在源头，但等到终点才发现。
共同的发现
两边都在"错误该早点暴露的地方"让错误拖延了。
流程的"快速失败"靠前置校验——第 2 步就该校验"项目编号是否合法"，不该等到第 8 步。
pipeline 的"快速失败"靠 stage 1 就做基础检查——基础镜像、依赖、配置，每个都在进入下一个 stage 前校验完毕。
让错误在该浮出来的地方就浮出来，不要让流程和 pipeline 越长越能藏错。
第三个坑：决定的事和被决定的事搅在一起
流程侧的糟心例
某公司的请假流程，审批节点要求填"请假者上月绩效分"。
审批人看到绩效分后，决策被绩效影响了——绩效低的员工请假就被卡得更严。
但绩效分跟"该不该批假"是两件事。做决定的事（审批）和被决定的事（绩效数据）搅在了一起。
结果是：
- 审批节点失焦——审批人不知道该看"事实"还是"绩效"。
- 决策被业务数据污染——同一个请假理由，绩效 A 可能批、绩效 C 可能不批。
- 流程图变成数据搬运图——节点越多、搬的数据越多、流程图越长。
流水线侧的糟心例
同一个团队的 Jenkinsfile，build stage 要写"这次是否新功能、是否涉及支付链路"。
但这些跟"构建"没关系——它们是部署决策的依据，不该出现在构建配置里。pipeline YAML 越长，业务参数越塞越多，最后维护 pipeline 的人成了"业务翻译官"。
共同的发现
两边都在"做决定的位置"塞了"被决定的东西"。
做决定该看的是规则，不是数据。pipeline YAML 该承载的是执行编排，不是业务参数。
做决定的事（流程图 / pipeline YAML）和被决定的事（业务数据 / 业务参数）必须分离。前者是控制面，后者是数据面。
第四个坑：流程反向吞噬工作（最关键的一个）
前三个坑都能在"代码层面"修补——改一个字段、改一段配置、加一个 stage 校验。但第四个坑必须靠组织能力修。
反面：流程要靠"流程外"的手段补缺
差流程的典型状态——流程要走通，得靠流程以外的东西补：
- 要打电话问"这步到底该谁批"。
- 要拉会议协调"下一步谁接"。
- 要发邮件确认"前置条件齐不齐"。
- 要翻一份冗长操作手册查"流程图之外的细节"。
工作者花在"应对流程"上的时间，比做工作本身还多。流程不是工具，反而成了另一种工作。
某 IT 公司的内部调研显示：员工平均每周花 6.4 小时在"应对流程"上——开会协调、写邮件确认、打电话问下一步。流程不仅没省事，反而成了最大的时间黑洞。
正面：流程主动引导工作
好流程是什么样的状态——工作者不需要了解流程本身：
- 系统提示"现在该做什么、约束是什么、下一步交给谁"。
- 所有节点都在系统里走完，完全不需要打电话、开会、发邮件、查说明书。
- 工作者的注意力只在"工作"上，不在"流程"上。
这是流程的"隐形"——最好的流程是工作者感受不到它的存在。
某 SaaS 公司的 oncall 流程改造：oncall 收到告警后，系统直接告诉他"这是第几类问题、按 runbook 走哪个 play、要不要叫人"。oncall 平均处理时间从 22 分钟降到 6 分钟——不是因为他变厉害了，而是因为流程不再让他"应对流程"。
关键能力：职责划分
要让流程变成"引导者"而不是"负担"，核心能力是职责划分：
- 流程设计者要先回答"这个工作由谁负责、边界是什么、上下游如何交接"，把工作范畴划分清楚。
- 对每个划分出来的职责，要么自己设计具体执行步骤，要么把"怎么做"交给该职责的负责人，让他们做可执行管理设计。
这是一种职责逆转：不是"先有流程让工作去适应"，而是"先有职责划分让流程去承载"。
工作完全线上化流程化，是这种职责划分能力的直接体现——好的流程设计本身就是一个能力的体现。流程设计者划分工作范畴，对每个职责做具体设计，或者交给每个职责负责可执行管理设计。
为什么这一坑最深
前三个坑（业务规则越界、错误延迟、控制/数据混淆）都可以靠"代码层面的纪律"修——多一次校验、多一层抽象、多一份规范。
唯独这一坑必须靠组织能力——没有"会做职责划分的人"，再多的工具都没用。
这也呼应了开头讲的"数智化 ≠ 上工具"——好流程的本质不是流程图，是划分工作范畴的能力。
收尾：四个坑是一个老问题的四种投影
这四个坑看似独立，其实是同一个老问题的四种投影：
- 第一个坑：把判断放错了地方。
- 第二个坑：让错误延迟暴露。
- 第三个坑：把数据塞进了控制。
- 第四个坑：让流程反向变成工作的负担。
它们都指向同一件事——workflow 这个东西，本来该让事情更省力，但很多人把它做成了反过来的样子。
不论是组织里的审批流程，还是技术里的 CI/CD 流水线，坑长得几乎一模一样，因为它们本质上是同一种东西——都是"把工作串起来"的载体。
下篇要谈的不是"再加几条原则"，而是"在数智化的成熟态，这种载体该怎么重新被组织起来"。我们会把流水线拆成三层，看清每层该管什么、不该管什么；再给一张判断表，让不同阶段的团队知道"自己该做到什么程度"。
参考
- 流程驱动工作：从纸质审批到智能门闩 —— 上篇四个坑里"流程侧的糟心例"的源头
- 基础篇总结：从手动部署到声明式流水线 —— 上篇四个坑里"流水线侧的糟心例"的源头
- 流程即镜像：数智化语境下流水线该怎么设计（下） —— 本文下篇