系列第 6 篇。上一篇《踩了 5 次"本地全绿、生产失效"之后，我把交付流程做成了 SOP》里提了一句"九步走 + 三道闸门 + 十条纪律"，评论区有人问闸门具体怎么设——这篇就把它单独拆开讲透。
一、先说一个反直觉的结论
复盘我做过的交付项目，上线出事的时间点，几乎从来不是"写代码写错了"的时刻，而是"错误的状态被推进到了下一个阶段"的时刻。
- 口径还没锁定，开发已经开工了——返工
- mock 从没验证过签名，"全绿"就敢上生产——翻车
- 放量当天有异常，还抱着"再观察观察"的心态往前走——事故扩大
这些问题代码层面都能修，但真正的病根是：流程里没有一个强制"停"的机制。代码有事务回滚，流程却常常"一路狂奔不带刹车"。
所以我给交付流程装了三道闸门。所谓闸门，就是：不满足条件，物理上不允许进入下一阶段——没有商量，没有"应该差不多"。
二、三道闸门全景
| 闸门 | 卡在哪 | 一句话判据 | 不过怎么办 |
|---|---|---|---|
| ① 决策门 | 开工前 | 关键口径已书面锁定 | 不锁定不开工 |
| ② 就绪门 | 上线前最后一个可用工作日 | 一笔真实小额打穿 | 放弃本期放量，提前报备 |
| ③ 放量门 | 正式放量日 | 试运行异常清零 | 有异常先回滚 |
看起来朴素，但每一道都是用真实的返工换来的。下面逐个拆。
三、决策门：分歧不过夜，口径不留口头
场景还原：接一个支付抵扣模块，对方接口文档写着 16 个接口，我读对方路由表一数——30+ 个。如果我当时按"文档白名单逐条放行"的思路做网关配置，上线当天必漏一半请求。
还有更隐蔽的：双方对"有效期"两个字的理解差了一个边界（含不含当天）。这种分歧放在口头，联调时才会爆炸，而且双方都会觉得是对方的错。
决策门的机制设计：
列出所有"关键口径"：接口范围 / 计费规则 / 有效期边界 / 单号唯一性 / 状态机
能确定的 → 写进《口径确认单》，客户书面确认（一页、业务语言，客户看得懂才会签字）
确定不了的 → 不开放式提问，给"我方默认口径"让对方二选一：确认 / 否掉
全部收敛之前 → 不开工
第 3 条是精髓：闭式选择远快于开放式问答。"按 A 还是按 B？"一轮就能收敛；"你觉得应该怎么算？"能扯三天。
顺带一个纪律：能从报文实样和源码里读出来的答案，不问人。我上一次项目对外提问数是 0——联调反而更快了。
四、就绪门：一笔真实小额打穿，不过就撤
这是三道门里最难执行、也最值钱的一道。
场景还原：上线截止日到了，本地 mock 全绿，部署完成，检查清单也过了一遍。上不上？
常规操作是上。但我踩过 5 次"本地全绿、生产失效"之后学乖了——全绿只证明一件事：你的 mock 和你的错是匹配的。签名只签了 6 个字段？mock 也没验签，当然全绿。返回字段名读错了？mock 照着错的实现，照样绿。
就绪门的机制设计：
时点：上线前最后一个可用工作日（不是截止日当天！）
判据（全部满足才算过）：
□ 部署完成，回滚命令已验证可用
□ 上线检查清单全过
□ 一笔真实小额打穿：真实扣款 + 业务生效 + 落库，三者齐活
不过 → 放弃本期放量，提前报备，不硬上
两个执行细节：
- "一笔真实小额"是唯一能戳破 mock 幻觉的针。预置额度、小额资金，走一遍全链路。它贵在"真实"——第三方的验签、状态机、字段名，全都会暴露真面目。
- "放弃放量"要提前报备，而不是临场甩锅。闸门的本质是把"上不上的决策"从情绪化的截止日当天，提前拉到一个理性的工作日。没打穿就报备延期，天塌不下来；硬上了打穿失败再回滚，客户信任才真的塌。
五、放量门：异常不清零，就别往前走
就绪门过了，正式放量日还有最后一道门。
机制很简单：试运行期间异常清零 → 放量；出现任何异常 → 先回滚到上一稳定态，查清楚再说了。
配套的回滚三级（触发即执行，不用等批准）：
| 级 | 动作 | 适用 |
|---|---|---|
| 1 | 关功能开关 | 单段异常，主链路无损 |
| 2 | 摘除入口，外部改回原流程 | 大面积失败，用户无感回退 |
| 3 | 换回上一版本产物 | 严重缺陷 |
三条铁律：任何回滚不重启数据库、不丢数据；回滚后逐项补验证并记台账；回滚不是失败，带病放量才是。
六、一个 90% 的人不知道的细节：闸门要算"假期窗口"
这条是我最想安利给所有人的。
设闸门时必须看一眼截止日后面是什么。如果截止日之后紧接着一个长假（国庆/春节），而且假期无人值守，那么——
截止日前没做完的活，最早要到复工第一天才能动。
因为：假期里发现异常 → 没人回滚 → 只能干看着 → 复工才能处理。这等于给整个交付强行加了一段"冻结期"，排期必须提前把它算进去。我见过太多项目倒在"赶在放假前上线"，实际上线时间点恰恰是最不该出事的时间点。
所以我的排期表上，长假前面永远有一道就绪门：要么提前打穿上线，要么直接排到复工后，没有"放假前勉强上"这个选项。
七、怎么在你的流程里装闸门（可抄清单）
不用推翻现有流程，三步就能装上：
- 找出你的"不可逆点"——每个流程里都有几个一旦越过就难回头的时刻（开工、对外承诺、部署生产、放量）。闸门只装在这些点前面，别到处都是门，否则流程就瘫痪了。
- 每个门给一条"机器可判"的判据——"基本没问题"不是判据。"口径确认单有客户书面确认"、"一笔打穿且落库记录可查"、"异常数为 0" 才是。判据模糊 = 门是装饰。
- 预设"不过"的剧本——闸门真正的价值在"不过"的分支：报备话术提前写好、回滚命令提前验证、延期预案提前想好。没写剧本的闸门，临场一定会被"再试一次"冲垮。
八、写在最后
闸门机制说白了就一句话：用少数几个刚性的"停"，换掉流程里无数个软性的"快一点"。
九步走解决"做什么、按什么顺序"，三道闸门解决"什么时候必须停"，十条纪律解决"日常怎么不埋雷"。三者合起来，才是完整的交付骨架。
完整 SOP（九阶段逐阶段的准出判据 + 5 类标准模板 + 5 类踩坑对策）全部开源：
GitHub：github.com/yang-shenxu/engineering-delivery-playbook（含 mock-api / report_tool / prompts / ai-collab 四个可运行模块）
💬 评论钩子：你的项目里有没有"明知道该停但没停下来"的时刻？评论区聊聊，我看看大家的"闸门"都卡在哪个环节。
