门禁驱动：让机器只管机器能管的，人只判人该判的
门禁驱动：让机器只管机器能管的，人只判人该判的
——「人 × Agent 协作」系列 · 第 6 篇
前五篇搭完了整套协作模式的骨架——AI 接手工作、AI review 治理产出、三角管控、共享环境。但还剩最后一个、也是最容易被低估的工程问题：
在那个共享环境里，当 AI 跑完一批测试，说"全部通过"——人，凭什么相信？
答案藏在一个让很多人栽过跟头的认知纠偏里："完成"和"正确"，是两件根本不同的事。 围绕这个纠偏，我们设计了一套叫"门禁驱动"的机制。
一个反直觉的真实案例
先讲一个真实发生过的故事。我们管它叫 HAR-6230 事件。
某次验收，Agent 在共享环境里跑了一批标准测试。批次执行得很顺利——所有任务都跑完了，没有报错，状态全部是 completed。按照传统的理解，这是一次完美的执行：流程通畅、系统稳定、批次绿灯。
但当我们去检查最终的业务判断时，发现了一个让人后背发凉的问题。
这批测试里有"正例"——也就是应该被审核通过的单据。结果呢？这些正例，有一部分没有通过，而是进入了 REVIEW（待人工复核）状态。原因很具体：系统在审核时，没有找到足够的 Excel 单元格证据来支撑"通过"的判断，于是出于谨慎，把它扔进了人工复核队列。
从"执行"的角度看，这件事毫无异常——批次跑完了，没报错，状态正常。但从"业务正确性"的角度看，这是一次严重的回归：一个本该自动通过的单据，被错误地卡住了。如果这个版本上了生产，真实用户就会遭遇"明明合规的单据，却被要求人工复核"的体验。
这就是"完成 ≠ 通过"最残酷的写照。
completed 只表示执行链路结束了。它不代表结果是对的。一个批次可以全部 completed，同时包含一堆错误的业务判断。如果你把"批次 completed"等同于"验收通过"，你就会把 HAR-6230 这样的回归，当成成功放行。
这件事给我们的教训，凝练成一句话：
机器门禁必须检查业务 decision，而不是只检查批次状态。
顺带说一句：HAR-6230 之前，我们的验收流程其实更粗糙——人手工抽几张单据看结果，或者干脆只看批次状态是不是 completed。HAR-6230 那次，如果验收的人那天稍微偷懒、只看了批次绿灯就放行，这个回归就上了生产。是事后偶然翻到正例进了 REVIEW，才把它拦下来。这种"差点漏掉"的经历，正是我们下决心把验收规则全部写成机器门禁的起因——靠人盯，总有盯不到的那一次。
为什么"完成"会骗过所有人
为了讲透这个教训为什么重要，让我们深挖一下：为什么"完成"这么容易骗人？
因为"完成"是执行层的概念，而"正确"是业务层的概念。它们属于不同的抽象层级，却被同一个绿灯符号掩盖了。
来看一个批次执行的全过程。AI 准备好测试材料，提交一批单据让系统审核，系统对每张单据给出一个判断：APPROVE（通过）、REVIEW（待复核）、REJECT（驳回）。批次跑完后，每张单据都有了一个结果，整个批次的状态变成 completed。
现在，问题来了：这个 completed，到底证明了什么？
它只证明了三件事：
- 系统没崩——所有单据都被处理了。
- 流程跑通了——从提交到出结果，链路完整。
- 没有超时、没有
ERROR。
它完全没有证明的是：每张单据的判断，是不是对的。 一张本该 APPROVE 的正例，可能进了 REVIEW；一张本该 REJECT 的反例，可能被 APPROVE 放行了。只要系统在"执行"，这些错误的判断就会和正确的判断一起，被笼统地打包成 completed。
这就是"完成"骗人的本质：它是一个执行层的指标，却被人误读成了业务层的保证。 这两者之间，隔着一道巨大的鸿沟。而门禁驱动的全部意义，就是在鸿沟上搭一座桥。
门禁驱动：用业务 decision 而非执行状态做判定
我们的解法，是把"判定通过"的标准，从"执行状态"换成"业务 decision"。
具体怎么做？在 review-e2e 这一道门禁里，我们列出了六条让验收失败的硬条件——只要命中任何一条，就算批次状态是 completed，验收也判失败：
- 批次超时，或存在 failed case；
- 出现
ERROR； - 正例进入了
REVIEW或REJECT（本该通过的却被卡了）； - 反例进入了
APPROVE（本该被拦的却被放了）； - 缺少 manifest 中声明的场景（该测的没测到）；
- manifest 的 commit SHA 与当前 Pipeline 的 SHA 不一致（版本对不上）。
请注意第 3、4 条——这才是整个门禁的心脏。它们不再是检查"系统跑没跑"，而是检查"系统判断得对不对"。一张正例进了 REVIEW，不再是"系统正常的谨慎行为"，而是"一次必须失败的回归"。一张反例被 APPROVE 了，不再是"流程完成的副产品"，而是"一次严重的安全漏洞"。
这六条共同构成了一个原则：门禁检查的是业务正确性，不是执行顺利度。 只要业务判断错了，执行再顺利也算失败。
这里有一个微妙但极重要的设计：第 6 条——commit SHA 一致性。它看起来是个技术细节，实则是整个门禁的地基。如果 manifest（声明"我测的是什么"）和 Pipeline（实际"跑的是什么"）的 commit 不一致，那么所有的业务 decision 断言都失去了意义——你根本不知道你在断言的，是不是你以为的那个版本。这一条，正是上一篇"共享环境"里"readiness 绑定 commit SHA"在验收环节的延伸：版本一致性是所有判断的前提。
G1–G5：一道递进的判定阶梯
光有 review-e2e 一道门还不够。我们把整个判定过程，拆成了五道递进的门禁，每一道只管自己那一层的事，失败只回到对应的环节：
| 门禁 | 谁负责 | 检查什么 | 性质 |
|---|---|---|---|
| G1 | 鸣人（实现 Agent） | 本地聚焦测试通过 | 代码层：改动本身没破坏既有逻辑 |
| G2 | 平台 / CI | Cloudflare 当前 commit 的两个域名 readiness 通过 | 环境层：跑的确实是这个版本 |
| G3 | 标准 E2E | decision 全部匹配 | 通用业务层：正例通过、反例被拦 |
| G4 | 宁次（验收 Agent） | 工单特有的正例、反例、边界例匹配 | 特定业务层：这个具体问题真的解决了 |
| G5 | 用户 | 最终验收 | 人的判断层：产品行为符合真实预期 |
这五道门的设计，有几个值得品味的地方。
第一，它是分层的，每一道只管自己那一层。 G1 不管业务对不对，只管代码改得有没有破坏；G3 不管这个工单特有问题，只管通用正反例；G4 才进入工单特有的边界。这种分层避免了"一道门试图检查所有事"的混乱——也避免了某一道门因为越权而误判。
第二，它的责任人是明确的。 G1 归鸣人，G4 归宁次，G5 归用户。每一道门失败，都只回到那个责任人，而不是把整个流程推倒重来。 这是门禁驱动和"全流程一锅煮"最大的区别——它让每一次失败都精准定位，修复成本最小。
第三，它把"人的判断"放在最后一道，且只放在最后一道。 G1 到 G4 都是机器或 Agent 能判定的，G5 才是人。这不是因为人不可靠，恰恰相反——是因为人的判断太宝贵，不能浪费在 G1–G4 那些机器能搞定的事上。 人只做 G5：在所有机器门禁都通过之后，去判断"这个产品行为，到底符不符合真实业务预期"。这又呼应了贯穿全系列的那句话：把人的参与，推迟到真正需要判断的节点。
失败的现场，比成功的现场更重要
门禁驱动还有一层常被忽视的设计：失败时，保留现场。
来看我们的失败处理表：
| 失败阶段 | 处理方式 |
|---|---|
| 环境 ready 之前失败 | 尝试清理所有资源 |
| 环境已 ready、数据准备失败 | 保留环境用于诊断 |
| 标准 E2E 超时或断言失败 | 保留环境，并输出批次审核日志 |
注意中间两行。当环境已经 ready、但后续环节失败时，我们不清理环境，反而保留它。
为什么？因为失败的现场，是最珍贵的诊断材料。如果 E2E 断言失败后立刻把环境销毁，那 Agent 和人就拿不到任何排查依据——他们只知道"失败了"，却不知道"为什么失败"。而保留环境意味着：你可以直接进去，看那张进 REVIEW 的单据到底缺了什么证据，看那条被 APPROVE 的反例到底是怎么溜过去的。现场还在，真相就在。
这和上一篇"共享环境"一脉相承：环境不只是成功时给人验收用的，它更是失败时给人和 Agent 共同诊断用的。一个会被销毁的现场，等于把每一次失败都变成了黑箱。而门禁驱动要求：失败必须可追溯，现场必须可进入。
一个更深的洞察：门禁驱动是"AI 治理 AI"的最后一公里
让我把这一篇和第 3 篇做一个呼应。
第 3 篇讲的是"用 AI 治理 AI 的代码产出"——让 AI review 来压缩人需要看的 diff。这一篇讲的是"用机器门禁治理 AI 的执行产出"——让机器门禁来验证 AI 跑出来的测试结果是否真的正确。
两者是同一个思想的两面：
- 代码层：AI 写的代码，由 AI review 治理（第 3 篇）；
- 执行层：AI 跑的测试，由机器门禁治理（这一篇）。
而它们共同的根基，是同一条原则：永远不要让任何一层（无论是 AI 还是人）的"自证"成为唯一判据。 AI 写完代码不能自己说"我写对了"，必须有 review；AI 跑完测试不能自己说"我跑通了"，必须有门禁。每一层的产出，都要被另一层验证。
这就是为什么 HAR-6230 事件让我们如此警觉——它暴露的，正是"AI 自证"的危险。如果当时我们只看批次状态，就会把那次回归当成成功。是门禁的第 3 条（正例进 REVIEW 判失败）救了我们。门禁不是束缚 AI 的枷锁，而是保护整个体系不被"虚假完成"侵蚀的免疫系统。
收束：完成与正确，必须被强行分开
让我用一句话收束这一篇：
"完成"是执行的概念，"正确"是业务的概念；门禁驱动的全部意义，就是用机器把它们强行分开，让人只在这两者被彻底区分之后，才做最后的判断。
这套 G1–G5 的门禁，把判定过程从"一个模糊的绿灯"拆成了"五道精确的关卡"。每一道关卡只问一个问题，只由一个责任人回答，失败只回到一个环节。而最终留给人的 G5，是整个体系里唯一一道、也是最珍贵的一道人的判断——因为前面四道已经把所有机器能管的，都管掉了。
讲到这里，六篇的工程内核已经完整。我们会用最后一篇（第 7 篇）来收束整个系列，回答那个贯穿始终的、也是最本质的问题：
在 Agent 时代，人，到底不可替代在哪里？
当 AI 能写代码、能 review、能管控流程、能准备环境、能跑门禁——人还能做什么？这个问题的答案，不是悲观的"人会被淘汰"，而是一个让人安心的、甚至让人振奋的发现。
这是第 7 篇的主题：人在 Agent 时代的不可替代性。下篇见。
一句话结论
门禁驱动把"完成"和"正确"强行分开：用六条硬条件和 G1–G5 递进门禁，检查业务 decision 而非执行状态，让人只在所有机器能管的都被管掉之后，做最后一道判断。