AI代码审查需要异议，而不是共识

adamsreview描述了一套由6条命令组成的代码审查流水线：并行审查视角、验证关口、人类走查、Codex同级审查，以及在提交前重新审查变更的修复循环。¹

这一设计指向了AI代码审查真正的前沿。更好的审查不是又一串机器人评论。它来自相互独立的审查者：它们可以提出不同意见，保留分歧，验证主张，并在项目把某项发现视为阻塞问题前，把判断权交还给人类审查者。

摘要

AI代码审查应当优化的是有纪律的异议，而不是共识。有效的审查系统会分配独立视角、合并重复发现、验证每一项主张，区分已确认缺陷和需要人工判断的问题，并让人类审查者保留最终审查身份。共识可能掩盖少见但重要的发现。审查包应当保留少数派主张，直到证据推翻它们；随后继续跟踪修复与复审结果。

核心要点

面向工程负责人： - 将AI审查视为证据流水线，而不是投票系统。 - 即使代理发现了真实缺陷，也应让合并权限留在人类手中。

面向代理构建者： - 为独立审查视角分配不同职责：正确性、安全、测试、用户影响、可维护性、执行环境行为和发布风险。 - 在验证推翻少数派发现前，将其作为结构化主张保留下来。

面向代码审查者： - 要求提供证据、复现步骤、受影响文件、验证器结果、人类决策状态和修复验证。 - 拒绝那些把一致意见当作置信度、却没有证明底层主张的审查系统。

为什么AI代码审查需要异议？

当所有审查者都在寻找同一类缺陷时，代码审查会悄无声息地失效。

单代理审查只有一种失败形态。模型扫描差异，产出看似合理的评论，然后漏掉注意力之外的问题。多代理审查只有在代理保持独立时，才能改善这种局面。如果5个代理读取同一个提示，继承同一套优先级，最后收敛成同一份摘要，系统买到的只是重复。

异议会改变审查覆盖面。安全审查者可以反对一个正确性审查者接受的请求流程。测试审查者可以在产品审查者认可行为后，指出缺少回归覆盖。执行环境审查者可以否决一段代码层面看起来干净、却无法满足部署约束的实现。

少数派发现之所以重要，是因为严重缺陷常常始于孤立的反对意见。共识分数可能把这种反对埋掉。好的审查流水线会让反对意见存活足够久，直到主张被证实或证伪。

独立审查者应当检查什么？

独立审查者需要的是不同职责，而不是不同名字。

视角清单应随代码库而变。支付系统需要欺诈和对账视角。编译器需要可靠性、诊断和性能视角。发布系统需要引用、SEO、翻译和缓存视角。

机制保持不变：每个视角产出的是主张，而不是裁决。

为什么共识不是可靠的审查信号？

共识回答的是错误问题。

多数投票问的是有多少审查者同意。代码审查真正需要知道的是：某项主张在面对代码、测试、执行环境和项目政策时，是否还能站得住。

一致可能说明发现显而易见。也可能说明每个审查者都有同样的盲点。分歧可能只是噪声。也可能说明某个审查者找到了真正的缺陷。

更好的指标是主张状态：

这套状态机优于共识，因为它把分歧当作证据库存来处理。流水线可以关闭噪声发现而不抹去记录，也可以在验证证明缺陷时提升孤立发现的优先级。

强大的AI审查流水线会做什么？

强大的AI代码审查流水线按阶段运行。

1. 独立检测。审查视角在看不到彼此结论的情况下检查差异。
2. 合并重复主张。系统把等价发现归组，但不抹平不同证据。
3. 低成本验证。快速检查可以拦截站不住的主张：文件是否存在、变更行是否可达、测试是否存在、类型错误，以及明显过期的上下文。
4. 深度验证。高影响主张需要更慢的审查：复现、追踪阅读、聚焦测试、安全推理，或第二模型批判。
5. 分类状态。流水线将每项发现标记为已确认、已证伪、人工判断、仅报告或低于关口。
6. 带人类走过不确定性。审查者决定需要判断的问题，提升重要主张，并拒绝低价值工作。
7. 按组修复。相关发现一起处理，避免系统应用相互冲突的补丁。
8. 重新审查修复。流水线再次审查变更后的代码，并在提交前回滚回归。
9. 写入审查包。最终产物记录发现、证据、决策、测试、提交和未解决缺口。

adamsreview提供了这种形态的具体示例。其README描述了最多7个并行子代理视角、去重、先低成本后深度的验证、可选整体审查、Codex同级审查、外部发现注入、针对不确定发现的走查，以及一个在提交前重新审查并回滚回归的修复循环。¹该README还把性能主张标为轶事性证据，这一点很重要。应将该项目视为有用的设计证据，而不是基准测试。

AI代码审查发现应当长什么样？

一项有用的发现需要足够结构化，方便另一位审查者、代理或CI任务稍后检查。

id: SEC-003
lens: security
claim: "The new webhook endpoint accepts unsigned retry requests."
severity: high
affected_files:
  - app/routes/webhooks.py
evidence:
  - "Handler reads JSON before signature validation."
  - "Test suite covers valid signatures but not missing signatures."
validator:
  cheap_check: pass
  deep_check: manual
  reason: "Reachable path confirmed; exploit impact needs owner judgment."
human_decision:
  status: promoted
  reviewer: "reviewer of record"
fix_group: webhook-auth
post_fix_review:
  status: pending
remaining_gap: "Need replay test against malformed retry payload."

具体字段可以变化。纪律不应变化。发现应命名主张、证据、验证器结果、人类决策、修复分组、修复后状态和剩余缺口。只写“检查webhook auth”的评论，无法支撑负责任的合并决策。结构化发现可以。

为什么人类必须保留正式审查者身份？

GitHub的审查模型为审查者提供了3种高级结果：评论、批准，或在合并前请求变更。²AI审查可以为这些结果提供信息，但不应悄然取代它们。

Rust的LLM政策草案清晰划出了这条边界。截至2026年5月18日，该政策仍是一个开放的pull request，并非已采纳的Rust政策。³草案允许私下使用LLM审查，但禁止将LLM审查视为足以合并或拒绝变更的依据。草案还说明，审查机器人必须保持顾问性质，机器人评论本身不能构成阻塞，人类审查者必须明确认可他们希望处理的评论。⁴

这条边界保护的是问责。机器人可以发现真实缺陷。机器人也可能产出过期评论、肤浅的风格异议，或自信的误报。正式审查者负责决定是阻塞、合并、请求变更，还是忽略该主张。

人类角色应体现在产物中：

当AI审查让人类审查更敏锐时，它会赢得信任。当它把权限藏进机器人裁决时，它会失去信任。

审查包应包含什么？

审查包会把一次审查运行变成持久的决策对象。

最低字段：

审查包不应像一份逐字记录。逐字记录展示发生过的一切。审查包展示的是负责任的审查者做决定所需的信息。

审查包还会保留组织记忆。当同一个误报下周再次出现时，团队可以看到它为什么失败。当少数派发现变成生产缺陷时，团队可以检查该主张在系统中如何流转。

关于代理式PR失败，研究怎么说？

这种失败模式不只存在于审查机器人。

一篇MSR 2026论文分析了GitHub上33000个由代理编写的pull request，发现文档、CI和构建更新任务的合并成功率最高，而性能和缺陷修复任务表现最差。⁵作者还发现，未合并PR往往触及更多文件、改动更大，并且CI失败。他们的定性分析识别出一些被拒绝模式，例如审查者参与不足、重复PR、不受欢迎的实现，以及代理与维护者目标不一致。⁵

这些发现支持一条实用规则：AI代码审查不应只问差异里有没有缺陷。它还应追问代理工作流是否给维护者提供了可审查的对象。大型、错位、审查薄弱的PR需要更好的审查包、更窄的提交边界，以及更强的人类决策点。

团队应如何开始？

从一个小型审查系统开始，目标是产出更好的决策，而不是更多评论。

1. 为风险最高的代码路径选择2到3个视角。
2. 要求每项发现都包含主张、证据、受影响文件和验证结果。
3. 在验证器证伪前保留少数派发现。
4. 将需要人工判断的主张转交给人类审查者，而不是藏在分数之下。
5. 跟踪误报，让系统学会团队会拒绝什么。
6. 在提交前重新审查修复。
7. 将审查包附到PR上。

不要从自动打补丁开始。先从可信的审查产物开始。当发现流水线赢得信任后，才可以增加狭窄的自动修复通道：机械性测试、明显的null检查、错别字级修正，或人类在走查中提升的修复。

目标不是让代码审查显得自治。目标是让人类审查更不容易被误导。

简要总结

AI代码审查需要独立异议，因为仅凭一致意见无法证明某项发现。强大的系统会按职责拆分审查者，保留少数派主张，验证证据，将不确定性转交给人类，并在提交前重新审查修复。GitHub的审查契约最终仍落在人类审查状态上。²Rust政策草案要求LLM审查保持顾问性质，直到人类认可该主张。⁴adamsreview展示了当前一种包含视角、关口、走查和修复复审的流水线形态。¹

胜出的产物不是机器人评论。胜出的产物是能让人类负责任地做决定的审查包。

FAQ

什么是AI代码审查？

AI代码审查使用语言模型或代理检查代码变更、识别可能缺陷、解释风险、建议修复，或为人类准备审查产物。严肃的系统应为每项发现提供证据和状态，而不是只发布评论。

AI代码审查应使用多个代理吗？

当每个代理都有独立职责，并且流水线会保留分歧时，多个代理是有帮助的。如果每个代理看到同一个提示，产出同一份摘要，并收敛成一个共识分数，那么多代理价值有限。

为什么在AI代码审查中，异议比共识更好？

异议会让少见发现保持可见，直到证据证明或推翻它们。当多数审查者都漏掉同一个边界情况时，共识可能隐藏严重的少数派发现。代码审查需要经过验证的主张，而不只是意见一致。

AI审查者可以阻塞pull request吗？

团队应让阻塞权限留在人类手中。Rust的LLM政策草案规定，LLM审查必须保持顾问性质，审查者必须明确认可LLM评论后，才能用其阻塞PR。⁴这条规则符合更广泛的问责原则：合并决策由人类审查者负责。

AI审查包应包含什么？

AI审查包应包含范围、视角、发现、证据、验证结果、人类决策、修复分组、复审结果、相关时的发布证明，以及未解决缺口。审查包应让审查决策可审计，而不迫使读者通读完整记录。

团队什么时候应允许自动修复？

团队应在发现流水线赢得信任后，才允许自动修复。从机械性、低风险修复开始，或从人类在审查中提升的发现开始。每一次自动修复都需要修复后审查和回滚路径。

参考资料