AI审AI代码靠不住

寂静回声

当前行业内存在一种普遍思路，将代码评审环节自动化，低风险的代码变更直接通过 CI（持续集成）检查完成校验，把研发人员的精力留给那些超出风险阈值的变更，相较于等待同事抽空人工评审的传统模式，这一模式确实有所进步，但并非完整的解决方案。
紧随其后出现了第二种思路，即由 AI 完成 AI 生成代码的评审。Sonar 旗下的 Gitar、CodeRabbit、Cursor 推出的 Bugbot 等工具，已经能够基于完整的仓库上下文读取合并请求，标注问题甚至直接修改代码，修改完成后返回 CI 流程验证，仅在无法给出明确判断时才引入人工介入，这是近年来增长速度最快的工具品类之一。其解决的痛点也切实存在，以往必须由人工跟进的代码分析工作，如今仅需数分钟即可完成，无需再等待人工排期。

DORA 于 2025 年第三季度开展了一项专项深度研究，面向 Google 工程师回收了 1110 份开放式问卷，该调研区别于其年度大规模调研，结果显示，AI 工具的采纳度越高，软件交付的吞吐量与交付不稳定性会同步上升，二者并非此消彼长的关系，而是呈现同步增长的态势。

Checksum 发布的《2026 年 AI 代码现状报告》调研了 105 位工程负责人，其中 61% 的受访者表示，过去 90 天内曾出现过生产事故，诱因是已经通过评审与单元测试的 AI 生成代码，同一份报告显示，超过半数的工程负责人称，自引入 AI 编程工具后，代码评审周期反而增长了 25% 以上，而 AI 生成单元测试的采纳率尚不足一半，这一环节原本的作用是弥补人工评审可能遗漏的问题。
仅靠提升自动化关卡的运行速度，无法解释这一矛盾现象，仅靠 AI 评审 AI 的模式同样无法解释。

目前有一种方向较为明确的结构性解释，有研究人员开展了一组实验，使用 Claude 模型评审 Claude 生成的代码，在预先植入缺陷的测试集上运行后发现，若代码生成模型与代码评审模型出自同一厂商，二者会存在相同的认知盲区，评审过程最终变成了用另一款模型对自身产出的评价做对照，而非基于原始需求开展校验，该研究作者也表示这一结论仅为方向性证据，并非严格控制下的实验结果，但这与 DORA、Checksum 的调研数据相契合，代码生成的速度与检查质量之间，正在出现越来越大的差距。
这是对上述差距的一种合理解释，并非最终定论，但无论如何，单纯依靠 AI 搭建的验证体系，运行速度再快也只是在固有逻辑内循环，它需要一种与代码来源不同的参照物完成校验。
正式撰写的需求文档可以作为一种校验锚点，它是对软件预期行为的描述，独立于任何具体的实现方式，但需求本身也需要对应的验证手段，这一环节只有确定性的非 AI 工具才能真正发挥作用。

这类工具的诞生时间有些远早于当前的问题场景，McCabe 于 1976 年提出的圈复杂度概念，用于计算函数控制流图中线性独立路径的数量，这套度量标准不关注代码的编写主体，也不与任何训练数据分布相关联，对所有来源的代码都采用统一的评判标准。但它仅能反映代码的结构特征，无法验证代码的逻辑是否匹配需求，一个函数可能拥有极简的结构，却依然存在逻辑错误。从本质上看，这类机械化检查只是完整验证体系中的一个层级，无法替代对业务意图的验证，测试、契约校验、静态分析、安全扫描、构建检查等环节各司其职，全部都是固定的确定性流程，而非交由模型进行主观判断。

这套完整架构成型后的形态，并非 “代码评审的自动化版本”，而是实现各层级的分工协作，需求文档明确业务意图，确定性流水线校验代码的机械属性。AI 评审则安排在确定性流程执行完成后，仅处理那些真正需要主观判断的剩余事项，即便是主营 AI 代码评审业务的 Sonar 公司，也对其产品做出了这样的定位，Gitar 的 AI 评审功能与 SonarQube 的确定性分析是并行运行的关系，而非替代关系，AI 评审不再被视为完整的验证系统。

代码评审环节的核心诉求并非提升速度，它需要一种处于体系之外的参照物完成校验。以往软件开发生命周期中的每个检查点都能提供这一参照物，只不过当所有开发阶段坍缩为与模型的持续对话后，这一关键参照物便消失了，搭建扎实完善的持续验证体系，不是对代码评审的温和升级，而是用不会与被校验对象存在相同盲区的全新组件，重新构建起评审环节一直依赖的核心校验基础。