没有质量门禁的 AI 编码，就是在加速制造技术债。一个真实的故事：某团队引入了 AI 编码，效率提升了 3 倍，但一个月后代码库变得一团糟——不是因为 AI 不好，而是因为没有质量门禁。

你让团队用 AI 编码。效率提升了，你很满意。但一个月后，你发现代码库变得一团糟——风格不一致、模块耦合严重、一些核心功能被 AI 悄悄改了。你问团队："怎么回事？"他们回答："AI 写的，我们也没仔细看。"

这就是没有质量门禁的后果。AI 编码的"副作用"——代码量激增、质量参差不齐、架构偏移——不是 AI 本身的问题，而是"流程的缺失"。质量门禁就是解决这个问题的：在代码流向生产环境的路径上设置关卡，确保每一段代码都经过检验。

4.1 质量治理的三道防线

质量治理不是"一个环节"，而是"三个层次"——预防、检查、审计——每一层覆盖上一层覆盖不到的盲区。

为什么是三层？ 因为 AI 编码的错误有三个层次，你需要三个层次的检测方法。编码前的预防能解决"方向对错"的问题，编码后的检查能解决"代码质量"的问题，提交后的审计能解决"系统性偏差"的问题。只做预防，你无法发现编码过程中的问题；只做检查，你无法发现系统性的趋势。三层防线互为补充，缺一不可。

第一道防线：预防

预防的成本最低，效果最好。在编码开始前确保方向正确。

蓝图评审：

• 每个项目开始前，蓝图需要经过至少一位同事评审
• 评审重点是：术语是否准确、数据模型是否完整、里程碑划分是否合理
• 评审通过后才能开始编码

验收标准前置：

• 每个里程碑开始前，验收标准就已经明确
• 验收标准写在里程碑描述中，而不是编码完成后临时想
• 验收标准应该可验证（不是"代码质量好"，而是"代码通过 Lint 检查"）

第二道防线：检查

检查是编码后的质量把关，是 AI 编码中最关键的环节。

验收强制化：

• 所有 AI 生成的代码必须经过验收才能提交
• 验收结果必须记录（通过/修复/重建）
• 验收记录作为代码审查的参考

验收三原则：

1. 功能验收：代码是否实现了需求？
2. 架构验收：代码是否偏离了蓝图？
3. 安全验收：代码是否有安全隐患？

第三道防线：审计

审计是定期的回顾性检查，发现系统性的问题。

审计频率：

• 小项目：项目结束时审计一次
• 大项目：每月审计一次

审计内容：

• 蓝图覆盖率：多少项目有蓝图？
• 验收执行率：多少里程碑有验收记录？
• 架构偏移率：多少代码存在架构偏移？
• 技术债评估：代码库的健康度如何？

4.2 三条纪律

以下三条纪律是质量管理的底线。触碰纪律的代码必须立即回滚。为什么是这三条？因为它们对应了 AI 编码的三个核心风险：没有蓝图，AI 会"猜"——猜技术栈、猜命名风格、猜数据结构；没有验收，AI 的"自洽陷阱"会把隐藏的问题固化到代码库；逢混乱不重建，代码会在"修修补补"中加速腐化。

纪律一：无蓝图不开工

描述： 项目开始前没有产出 CONTEXT.md 蓝图。**

后果： AI 编码没有方向，代码质量不可控，架构一致性无法保证。

处理方式： 暂停编码，先产出蓝图。

纪律二：无验收不固化

描述： AI 生成的代码没有经过验收就提交到代码库。

后果： 质量问题无法在早期发现，可能影响团队其他成员。

处理方式： 回滚未验收的提交，完成验收后重新提交。

纪律三：逢混乱必重建

描述： 代码出现架构偏移（篡改地基、过度设计、体积失控）时，继续在错误基础上修补。

后果： 代码结构持续恶化，维护成本爆炸式增长。

处理方式： 立即回滚，分析原因，从干净状态重新开始。

补充：安全红线

除了三条纪律，还有一条不可逾越的安全红线——安全漏洞零容忍：

• AI 代码中存在 SQL 注入、XSS、权限缺失等安全漏洞
• 后果：系统安全性受损，可能导致数据泄露
• 处理方式：立即修复，修复后进行安全审查

三条纪律是行为层面的底线，安全红线是后果层面的底线。纪律决定了"怎么做"，安全红线决定了"什么不能做"。

4.3 质量门禁设计

质量门禁是自动化或半自动化的质量检查点，在代码流向生产环境的路径上设置关卡。为什么需要四个门禁？因为每个门禁解决一个不同的问题：本地验收门解决"有没有认真做"的问题，代码审查门解决"做对了没有"的问题，集成验证门解决"合在一起有没有问题"的问题，部署门解决"能不能上线"的问题。

门禁一：本地验收门

位置： 开发者本地，AI 完成编码后

检查项：

• 功能完整性检查
• 架构合规检查
• 安全检查（基础）

通过条件： 全部检查通过，或 NEEDS_FIX 已修复

门禁二：代码审查门

位置： 提交到共享分支前

检查项：

• 代码风格检查（自动化）
• 测试覆盖率检查（自动化）
• 代码审查（人工）

通过条件： 自动化检查通过 + 至少一位同事审查通过

门禁三：集成验证门

位置： 合并到主分支前

检查项：

• 构建检查（项目能否成功构建）
• 测试套件（所有测试通过）
• 集成测试（跨功能验证）

通过条件： 所有检查通过

门禁四：部署门

位置： 部署到生产环境前

检查项：

• 安全审查（全面）
• 性能测试（如有需要）
• 变更记录检查

通过条件： 所有检查通过

4.4 架构偏移审计

架构偏移是 AI 编码中最容易被忽视、但影响最大的质量问题。为什么影响最大？因为其他问题（功能 bug、安全漏洞）是"显性的"——你会立即发现。架构偏移是"隐性的"——代码能跑通、功能正确，但结构不对。它不会立刻引发问题，但会持续增加维护成本，直到某一天你发现改一个 bug 需要牵动五个文件。

什么是架构偏移

架构偏移是指：AI 生成的代码在功能上正确，但在结构上偏离了原始设计。

例子：

• 蓝图约定 API 放在 app/api/ 下，AI 把新的 API 放在了 pages/api/ 下
• 蓝图约定使用 Prisma ORM，AI 在某个功能中直接用了原生 SQL
• 蓝图约定组件放在 components/ 下，AI 把组件放在了页面文件中

架构偏移的危害

单个架构偏移看起来很小（"不就是放错了一个文件吗？"），但累积起来会：

1. 导致代码结构混乱，新成员难以理解
2. 增加维护成本，每次修改都需要额外的时间
3. 降低 AI 编码的质量——AI 基于混乱的代码生成更多混乱的代码
4. 最终导致"代码腐化"——系统从有序变为无序

架构偏移的检测方法

自动化检测：

• 使用 git diff 检查新增/修改的文件是否在约定的目录下
• 检查新增的依赖是否在允许列表中
• 检查单个文件的长度是否超过阈值

人工检测：

• 代码审查时重点关注架构问题
• 定期架构审计

4.5 质量报告

定期产出质量报告，让团队和管理者了解代码库的健康状况。

报告模板

# 代码质量月度报告

## 概览
- 项目数：5
- 蓝图覆盖率：80%（4/5）
- 验收执行率：85%
- 架构偏移率：12%

## 详细数据
| 项目 | 蓝图 | 验收率 | 偏移率 | 健康状况 |
|:---|:---:|:---:|:---:|:---:|
| 项目 A | ✅ | 95% | 5% | 健康 |
| 项目 B | ✅ | 90% | 8% | 良好 |
| 项目 C | ❌ | 60% | 25% | 需关注 |
| 项目 D | ✅ | 100% | 3% | 优秀 |
| 项目 E | ✅ | 80% | 15% | 需关注 |

## 需要关注的项目
- 项目 C：没有蓝图，验收率低，架构偏移率高
  - 建议：暂停新功能开发，先补蓝图和验收

## 改进建议
1. 在 CI/CD 流程中增加架构偏移检测
2. 组织一次架构偏移专题培训
3. 更新验收模板，增加架构检查项

本章小结

质量治理不是"一个环节"，而是"三个层次"——预防、检查、审计——每一层覆盖上一层覆盖不到的盲区。三条纪律（无蓝图不开工、无验收不固化、逢混乱必重建）对应了 AI 编码的三个核心风险。四个质量门禁各解决一个不同的问题——从"有没有认真做"到"能不能上线"。架构偏移是隐性的"慢性病"，比显性的 bug 更具破坏性。定期质量报告让团队了解代码库的健康状况。下一章，我们学习如何衡量 AI 编码的效果。