AI 编码项目里检查的地位比任何时代都高。“AI 生成的代码语法层面几乎挑不出错错的都在语义层, 旧时代的门禁逻辑变了该如何立新呢门禁层让检查先于代码——约束是文本门禁是执行AI Harness Engineering · 第五篇· 王海涛公众号Jia言Yi行 · GitHubderekwang85 · 腾讯云 TVP / 架构师名人堂质量管理之父戴明说过一句让很多工厂主不舒服的话质量不是检查出来的。他主张质量要造进流程里而不是靠出厂前的检验把关。这句话是对的——但它在 AI 编码时代有一个被忽视的另一面流程里造进去的质量恰恰要靠检查来确认它真的被造进去了。戴明反对的是只靠检查他从不反对有检查。AI 编码项目里检查的地位比任何时代都高。原因在前几篇已经铺垫完了约束写在文件里战略、架构、契约但文件不会自己执行AI 会读文件也会在压力和歧义面前悄悄偏离文件。从约束写下来了到代码真这么干了中间隔着一道无人看守的峡谷。这一篇讲的就是怎么在峡谷上架桥门禁——让检查先于代码。一、旧门禁为什么拦不住 AI 生成的代码传统工程不是没有门禁。CI 里跑编译、跑静态检查、跑测试这是每个成熟团队的基本盘。但这些门禁有一个共同的假设——代码是人写的。人写的代码有人的特征会忘、会懒但不会自信地编造。AI 生成的代码特征完全不同。几组公开数据足以说明问题幻觉依赖针对 GitHub 仓库 PR 的分析CodeRabbit2026 Q1470 个仓库发现约 1/5 的 AI 代码样本包含虚假的库引用——它不是写错是一本正经地编功能与安全失衡Google Research 2025 盲评数据显示主流 AI 工具生成代码的语法通过率已达 92%但逻辑正确率仅 78%并发、事务、异常分支等复杂场景进一步降至 54%认知落差云安全联盟 CSA2026 年 4 月报告显示45%-70% 的 AI 生成代码未能通过基础安全扫描而同期的开发者调研中 75% 认为AI 写的代码比自己写的更安全。翻译一下AI 生成的代码语法层面几乎挑不出错错的都在语义层。而传统的 lint、编译、格式检查全部工作在语法层。这就是旧门禁失效的本质——你拿着查错别字的工具去查一篇立意错了的文章。错别字查得再勤也拦不下一篇文章用看似通顺的句子说了错的话。TradeOMS 全周期开发里踩的就是这个坑早期 CI 全绿、测试全过但 AI 塞进来的逻辑错误照样混进了主干——把 null 断言写成恒真、把异常吞掉当成功、把相等写成赋值。语法门禁全过了语义错误一个没拦下。二、门禁的本质把约束变成事实先分清楚两个词这是整套体系的关键约束是文本文件、规范、约定——它声明应该怎样门禁是执行脚本、测试、规则——它验证实际怎样约束不设门禁就是空话门禁不挂约束就是摆设。第一篇讲约束金字塔时给过结构战略层 → 架构层 → 契约层 →门禁层→ 实现层。当时一笔带过现在展开——门禁层是约束金字塔的闭环没有它上面四层全是纸。门禁的物理形态在 derekcoding-framework 里长这样可验证的真实结构dispatch/ ├── gates/ # 门禁脚本提交前逐项检查 ├── fulltest-system/ # 全量回归测试系统 ├── triple-track/ # 三轨制WBS / Issue / Test Case └── swarm/ # 多角色并行评审 tests/ └── fulltest-baseline-R1.md # 回归基线这套体系的核心不是某个脚本而是一条纪律AI 改完代码不能自己通过必须跑一套它无法修改的门禁。门禁由人定义、由脚本执行、结果由独立机制判定。这条纪律的存在比任何单个门禁都重要——它承认了 AI 的一个缺陷AI 没有自我怀疑它对自己的产出永远自信。让一个不怀疑自己的执行者给自己打分分数永远是满分。三、从五道门禁到六阶段门禁自己也要进化编码侧沉淀了五道门禁对应写作侧的同构体系门禁拦什么实现方式G1 风格AI 味、不规范模式规则评分器可量化的五维G2 结构文档/代码与约束脱节结构一致性检查G3 事实编造的 API、假断言引用溯源 断言有效性G4 一致性改 A 忘了 B涟漪扫描ripple-scanG5 独立评审自我放水评审与写作分离 反谄媚五道门禁是发布前的防线。但门禁本身也会老化规则库会过时、AI 会找到新的绕法、基线会失真。所以我们把它收敛成一套贯穿全生命周期的六阶段体系——G0 基线 → G1 编译通过 → G2 三层分析 → G3 涟漪扫描 → G4 复测验证 → G5 经验固化 → G6 签发放行从拦截坏产出升级为越用越准的自成长门禁。三个设计原则比门禁清单本身更重要原则一门禁必须能量化。代码质量要高不是门禁首次通过率 ≥70%才是。不能量化的门禁等于没有门禁——它无法回归、无法对比、无法改进。原则二门禁是发布前不是写作中。编码时逐行套门禁会扼杀产出写作时逐句套门禁会扼杀表达。门禁的价值在拦截不在指导。原则三失败要有返回路径。门禁失败不是终点是路由——G1 失败回改写、G3 失败回素材阶段、G4 失败回涟漪扫描。没有返回路径的门禁只会制造提交被卡死的挫败感而挫败感会逼人绕开门禁。门禁的全部意义浓缩成一句可带走的话检查先于代码错误就拦在上线之前而不是事发之后——约束是写下应该怎样门禁是证明确实这样。四、成本账门禁到底贵不贵这是所有人第一个问的问题多一套门禁会不会让开发变慢答案是门禁在 CI 上跑的时间比一次人工 review 便宜两个数量级。我们在编码框架里测过五道门禁全量跑完CI 增加的时间在分钟级而一次跨模块的人工 review是小时级。这是门禁最直白的经济账——检查是脚本的事人只审脚本查不出来的东西。更关键的是另一本账返工成本。CodeRabbit 2026 Q1 对 470 个 GitHub 仓库 PR 的分析给出一个硬数字AI 共同创作代码的 bug 率是人类写的 1.7 倍平均每段 AI 代码 10.83 个问题 vs 人类 6.45 个。GitHub 官方则披露平均每个 Copilot 用户提交的代码中 46% 是 AI 生成Java 开发者更高达 61%。AI 写得越多语义风险越大。门禁的钱不是花在多跑几秒上是花在把小时级的人工排查换成分钟级的自动拦截上。反方怎么看门禁会不会过重必须诚实面对一个反方门禁不是免费的它可能制造误报也可能重到扼杀产出。这正是门禁设计的边界问题。误报规则太死会把正常的 AI 输出误判为违规逼 AI 走形式、凑规则反而降低产出质量过重门禁全堆在提交前一次提交跑十几分钟开发者会找捷径绕开它——门禁体系反而名存实亡矫枉过正对着每个函数包 try-catch、每条注释都强制规范最后代码是干净了但没人在意它干不干得了活。这三条反方都成立所以门禁设计的真正难点不在加多少而在怎么不过度。对策有两条门禁分级——只对真约束架构、契约、安全红线设硬门禁其余用软提示。硬门禁越少误报越少越没人想绕门禁自成长——规则库记录失败模式、基线可调、误报可申诉。门禁不是一锤定音是越用越准。一句话总结这门反方的账没有门禁语义错误漏进主干门禁过重产出被规则拖垮。健康的门禁在两者之间——只拦语义错误不拦正常发挥。五、活的注脚derekinside 的门禁是什么这套让检查先于代码的门禁层在我那个本地知识库副脑derekinside里对应物是知识的入库校验和检索质量门禁。derekinside 里每一条知识进来都要过一遍结构校验——chunk 格式对不对、实体关系是否合法、与已有知识是否冲突。知识不是写进去就算数是校验通过才算数。这跟代码门禁是同一条纪律入口可以宽松出口必须设卡。知识库的质量不是靠写的时候认真维持的是靠进库的时候检查维持的——这跟 AI 代码的质量不靠生成的时候认真、靠合并之前检查是同一个道理。六、第一天就能做的三道门禁不扯理论给可直接落地的清单。任何项目今天就能加门禁 1 · 断言有效性检查拦假阳性扫描 AI 生成测试里恒真断言——assertTrue(true)、只有覆盖没有断言的用例、吞异常的空 try-catch。一行脚本就能筛出第一批。门禁 2 · 引用溯源检查拦幻觉 API对 AI 引用的一切 API/文档/函数跑一遍真实存在性校验。CodeRabbit 分析显示约 1/5 的 AI 代码样本带虚假库引用——这一道门禁能拦下绝大多数。门禁 3 · 涟漪扫描拦改 A 忘 B提交前检查改动涉及的所有调用方、配置、契约是否同步更新。规则很简单任何跨文件改动必须列出受影响清单清单上的每一项都要求已验证。三道门禁加起来是几百行脚本 一个 pre-commit 钩子的事当天能上线。最后回到戴明那句话。他说质量不是检查出来的本意是反对把检查当质量的唯一来源但 AI 编码时代这句话应该被翻译成另一句更完整的话质量不是检查出来的但没有检查的质量是声称出来的。约束写下来是第一步让约束被执行是第二步——门禁就是第二步本身它让我们遵守了约束从一个说法变成一件事实。下一篇从金字塔的顶往下走讲顺序问题实现层幂等与退化——接口幂等、降级契约AI 挂了业务不停。