这篇文章的核心观点可以用一个简单的问题来概括：如果让 AI 写代码，又让另一个 AI 来检查代码，但没有一个“标准答案”在旁，会发生什么？
作者 Christo Zietsman 认为，目前的行业做法（用 AI 检查 AI 写的代码）存在一个巨大的逻辑漏洞。他提出了三个核心假设，并给出了一套新的解决方案。
为了让你更容易理解，我们把软件开发想象成**“建造一座摩天大楼”**。
1. 核心问题：两个 AI 在“自说自话”
现状： 现在的做法是，AI 建筑师（生成模型）画出了图纸，然后 AI 监理（审查模型）拿着图纸去检查。
漏洞： 这两个 AI 都是同一家公司训练的，它们读的书、学的规矩、甚至“性格”都差不多。
- 比喻： 想象两个双胞胎兄弟，哥哥画了一张可能有错误的地图，弟弟拿着这张地图去检查。如果哥哥画错了（比如把“悬崖”画成了“平地”），弟弟因为学的也是同样的知识，大概率也会觉得“嗯，这里确实是平地”。
- 结果： 它们互相确认了错误，而不是发现了错误。这就是论文说的**“循环论证”**。没有外部的“标准答案”（规格说明书），AI 审查只是在检查代码“像不像”代码，而不是检查代码“对不对”。
2. 三个核心假设（用比喻解释）
假设一：同病相怜，错误会“传染”
- 论文观点： 如果生成代码和审查代码的 AI 来自同一个“家族”（训练数据相似），它们的错误是相关性的，而不是独立的。
- 比喻： 就像两个都吃同一种“坏苹果”长大的孩子。如果苹果里有毒，两个孩子都会中毒。你指望其中一个孩子去检查另一个孩子有没有中毒，是没用的，因为他们都会觉得“这苹果挺甜的”。
- 实验证据： 作者做了一些小实验。
- 简单错误（如数学计算）： AI 都能抓出来，因为这是常识。
- 行业潜规则错误（如航空燃油储备、医疗编码规则）： 如果这些规则没写在代码里，也没写在训练数据里，AI 就会自信地胡说八道。比如，它会把错误的燃油储备量当成正确的，并告诉你“没问题”。
- 结论： 没有外部标准，AI 审查在复杂领域会失效。
假设二：把“复杂”变成“麻烦”（Cynefin 框架）
- 论文观点： 软件开发通常分为“复杂领域”（不知道会发生什么，只能摸索）和“麻烦领域”（有明确规则，可以分析）。AI 擅长处理“麻烦”的事，但怕“复杂”的事。
- 比喻：
- 没有规格说明书时（复杂领域）： 就像在迷雾中开车。AI 只能凭直觉猜路，它可能会开进沟里，因为它不知道路在哪。
- 有了可执行的规格说明书（麻烦领域）： 就像给车装上了GPS 和导航仪。你告诉 AI：“必须停在红灯前，必须走这条道”。这时候，问题就从“猜路”变成了“按导航走”。
- 关键转变： 可执行的规格说明书（比如 BDD 场景）就像**“导航仪”**。它把模糊的“我想做个好用的软件”变成了具体的“如果用户点 A，必须显示 B"。有了这个，AI 就不再是猜谜，而是做填空题。这让 AI 变得真正有用且便宜。
假设三：AI 审查只能管“剩下的”
- 论文观点： 并不是所有错误都能被规格说明书抓住。那些抓不住的错误，才是 AI 审查真正该干活的领域。
- 比喻： 想象一个**“三层过滤网”**：
- 第一层（规格说明书/GPS）： 抓最明显的错误（比如红灯不停、路走反了）。这是确定性的，必须 100% 准确。
- 第二层（AI 审查/老练的顾问）： 抓那些 GPS 没写到的“潜规则”或“结构问题”。比如：代码写得太乱、模块之间耦合太紧、或者虽然功能对了但架构设计很丑。
- 第三层（人类/用户）： 抓“需求错了”的问题。比如：我们造了一辆完美的法拉利，但用户其实想要一辆拖拉机。这是 AI 和代码都解决不了的，必须靠人。
3. 作者建议的新架构（怎么做？）
作者建议把现在的流程倒过来，建立一个**“规格说明书优先”**的流水线：
- 第一步：先写“导航仪”（规格说明书）
- 在写代码之前，先写好可执行的测试场景（BDD）。告诉 AI 和人类：我们要什么，不要什么。这是**“真理”**。
- 第二步：让“机器”做检查（确定性验证）
- 用自动化脚本运行这些“导航仪”。如果代码不符合“导航仪”，直接报错，不许通过。这一步不需要 AI 猜，是硬性的。
- 第三步：让"AI 顾问”看结构（AI 审查）
- 只有当代码通过了“导航仪”检查后，才把 AI 审查派上用场。这时候 AI 的任务不是找逻辑错误（因为机器已经找过了），而是找“结构问题”：代码写得乱不乱？架构好不好？有没有违背设计初衷？
- 这时候，AI 就像一个**“经验丰富的老建筑师”**，它不看具体的砖块（逻辑），而是看大楼的结构稳不稳。
总结
这篇文章不是在说"AI 审查没用”，而是在说**“用错了地方”**。
- 现在的错误做法： 让两个 AI 互相检查，没有标准答案。这就像让两个盲人互相摸象，谁也摸不准。
- 正确的做法： 先给 AI 一个**“标准答案”（规格说明书），让机器先做硬性的对错判断。然后，再请 AI 来当“顾问”**，去检查那些机器看不出来的“结构美感”和“设计隐患”。
一句话总结：
不要指望 AI 去猜“什么是对的”，要先给它“什么是对的”的标准；然后，再让它去帮你看看“做得漂不漂亮”。
《规范即质量门禁：AI 辅助代码审查的三个假设》技术总结
1. 核心问题 (Problem)
当前行业应对 AI 生成代码质量问题的主流方案是部署"AI 审查员”（AI Reviewers）。然而，本文指出这种架构存在**结构性循环（Structural Circular）**缺陷：
- 缺乏外部参照：当生成代码的 AI 和审查代码的 AI 缺乏外部可执行规范（Executable Specifications）时，两者都基于同一份代码 artifact 进行推理。
- 训练分布同质化：生成者和审查者通常来自同一模型家族，共享相同的训练语料、架构和奖励信号。
- 相关性错误：根据集成学习理论，如果估计器（Estimators）的失败是相关的（Correlated），堆叠它们不会减少错误，反而会固化错误。AI 审查员实际上是在“检查代码是否符合其自身生成的代码”，而非“检查代码是否符合意图”。
- 后果：DORA 2026 报告指出，高 AI 采用率导致吞吐量增加的同时，系统不稳定性也上升。时间从“写代码”转移到了“审计代码”，但瓶颈并未解决，因为审查环节缺乏确定性的质量门禁。
2. 方法论 (Methodology)
本文通过三个相互关联的假设构建论证，并结合文献综述与受控实验进行验证：
2.1 理论框架
- 相关性错误假设：基于机器学习集成理论，论证同质化 LLM 管道中的错误会相互呼应而非抵消。
- Cynefin 领域转换假设：利用 Cynefin 框架（复杂域 vs. 繁杂域），论证可执行规范（如 BDD 场景）能将“使能约束”（Enabling Constraints）转化为“治理约束”（Governing Constraints），从而将问题从“复杂域”（因果仅在事后可知）转移到“繁杂域”（因果可通过分析预知）。
- 缺陷分类学：基于“预言机问题”（Oracle Problem），提出一个基于“可规范度”的缺陷分类体系，界定 AI 审查的有效边界。
2.2 实验设计
作者进行了三个小型的、受控的“人为实验”（Contrived Experiments），使用植入的 Bug 语料库（Planted Bug Corpus）而非自然缺陷样本，旨在提供方向性证据：
- 实验 1（经典边界条件）：Claude 模型生成代码，Claude 审查。测试离群值、循环终止等经典边界 Bug。
- 实验 2（领域规范违规）：测试仅相对于特定领域规范（如保险精算、航空维护、金融估值）才成立的逻辑错误。审查者被剥夺了文档中的规范信息，仅凭代码审查。
- 实验 3（跨家族审查面板）：引入四个不同模型家族（Anthropic, OpenAI, Google, AWS）审查同一组领域不透明（Domain-Opague）的 Bug，测试多样性是否足以消除相关性错误。
3. 关键贡献 (Key Contributions)
3.1 提出“相关性错误”理论
论证了在缺乏外部规范的情况下，AI 生成与 AI 审查的同质化管道会导致相关性失败。即使使用跨家族模型（Cross-family），若缺乏外部规范，审查者仍会共享训练数据中的盲点，无法识别未明确指定的领域规范。
3.2 定义“规范即门禁”的架构
提出可执行规范（如 Gherkin/BDD）不仅仅是文档，而是确定性验证管道。它将问题从概率性的“复杂域”转化为确定性的“繁杂域”，使得 AI 在经济上大规模应用成为可能。
3.3 提出基于“可规范度”的缺陷分类学
将缺陷分为五类，重新定义了 AI 审查的适用范围：
- A 类（理论上可规范但未规范）：需通过规范纪律解决，AI 审查在此无效（除非有规范）。
- B 类（理论上可规范但经济上不划算）：适合属性测试和多样化采样。
- C 类（运行时不可规范）：如竞态条件、性能退化，需运行时验证（ML 异常检测），而非预部署审查。
- D 类（结构与架构属性）：代码满足所有规范但架构漂移。这是AI 审查的唯一合法且有限的目标，用于检测未编码的架构意图和结构一致性。
- E 类（规范本身的缺陷）：需求错误，需通过用户反馈循环解决，无法自动化。
3.4 实验证据
- 实验 1：AI 能 100% 检测经典边界 Bug（属于繁杂域），但这不能证明其在复杂域的有效性。
- 实验 2：在去除规范文档后，AI 对领域规范违规的检测率从 100% 降至 0%（如
interpolate_rate 函数）。AI 倾向于用训练数据中的“合理猜测”填补空白，甚至自信地确认错误的领域规范。
- 实验 3：跨家族模型在特定领域（如 ICD-10-CM 医疗编码规则、ICAO 燃油储备规则）上表现极差（0/5 检测率），甚至自信地确认错误规则。这证明多样性不足以替代规范。
4. 实验结果 (Results)
| 实验场景 |
发现 |
结论 |
| 经典边界条件 |
AI 审查检测率 100% |
经典 Bug 属于“繁杂域”，AI 擅长处理，但这不能证明 AI 能处理“复杂域”问题。 |
| 领域规范违规 |
检测率 0% - 100% (取决于训练数据覆盖度) |
当规范未显式表达时，AI 无法识别领域逻辑错误，甚至产生“幻觉”确认错误。 |
| 跨家族审查 |
特定领域（如医疗、航空）检测率 0% |
即使模型家族不同，若缺乏外部规范，共享的训练分布盲点依然存在。 |
| BDD 场景 |
100% 检测所有植入 Bug |
可执行规范作为确定性门禁，能独立于模型训练数据发现逻辑错误。 |
| 置信度偏差 |
模型在 ICAO 燃油规则上自信地确认错误 |
AI 不仅会漏报，还会错误地确认不存在的规范，这是比漏报更危险的失效模式。 |
5. 意义与架构建议 (Significance & Architecture)
5.1 核心结论
AI 审查并非毫无价值，但其价值取决于基础架构。
- 没有规范：AI 审查是循环论证，检查代码是否符合代码，无法发现领域逻辑错误。
- 有规范：AI 审查应仅作为**结构性残留（Structural Residual）**的补充，用于检测未编码的架构意图和代码风格一致性。
5.2 推荐的 AI 辅助开发架构
- 规范优先 (Specifications First)：
- 使用 BDD 场景、契约测试（Contract Testing）和变异测试。
- 将问题从复杂域转换为繁杂域，消除 A 类缺陷的相关性错误。
- 确定性验证管道 (Deterministic Verification Pipeline)：
- 作为行为正确性的审查员（Pass/Fail），不依赖概率模型。
- 架构工具与 AI 审查 (Architectural Tooling & AI Review)：
- 针对 D 类缺陷（架构漂移、未编码的意图）。
- AI 在此扮演“专家架构师”角色，提供非循环的信号，但人类需做最终决策。
- 运行时验证 (Runtime Verification)：
- 针对 C 类缺陷（竞态、性能），使用 ML 异常检测和可观测性工具。
- 用户反馈循环 (User Feedback Loops)：
- 针对 E 类缺陷（需求错误），通过用户测试和设计思维解决。
5.3 局限性与未来工作
- 实验基于植入的 Bug 语料，非自然缺陷分布，结论为方向性证据而非统计显著性结论。
- Cynefin 框架的映射尚未经过该社区正式验证。
- 缺陷分类学（特别是 A 类与 D 类的边界）需要更多实证研究。
总结：本文主张在 AI 辅助开发中，可执行规范是打破 AI 审查循环性的唯一解。行业应从“用 AI 审查 AI 代码”转向“用规范定义意图，用确定性管道验证行为，仅用 AI 辅助处理架构残留”。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。