先把判断说准

「代码审查结束了」这个说法很容易传播，也很容易误导。

更准确的说法是：强制人工逐行审查正在失去中心位置。它仍会留在组织里，只是已经不适合作为所有代码进入生产环境的默认门槛。

Martin Monperrus 在 2026 年 6 月提交的论文《The End of Code Review: Coding Agents Supersede Human Inspection》把这个判断推到很前面。他的核心主张是，Coding Agent 已经跨过一个能力阈值，强制人工代码审查应由 Agent 驱动的验证取代。这个判断很激进，也不应被当成已被完全证明的事实。这篇论文没有做新的大规模实证实验，而是基于既有研究、工具进展和成本收益变化提出一个立场。

它的价值在于逼研发组织重新看一个旧问题：代码审查到底在保障什么？

如果代码审查的主要价值是找出深层缺陷，那么越来越多证据表明，人类读 diff 的可靠性被高估了。如果代码审查的价值包括知识传播、规范一致、团队感知、责任确认，那么这些目标又不应该继续全都压在人类逐行读代码这一个动作上。

AI Coding 带来的变化，不止是代码写得更快。软件交付系统的瓶颈换了位置：过去缺代码产能，现在缺验证产能。

现代代码审查本来就不是单纯找 bug

讨论 Agent 是否能替代代码审查之前，先要承认一个事实：现代代码审查本来就是混合物。

Google 的《Modern Code Review: A Case Study at Google》和 Bacchelli、Bird 对 Microsoft 开发者的研究都说明，现代代码审查承载了很多目标：发现缺陷、保持代码库一致、传播知识、让更多人知道代码正在发生什么、帮助团队形成共同所有权。

这几件事经常被放进同一个 PR 流程里。Reviewer 看 diff，顺手指出命名问题，提醒某个 API 的历史坑，判断实现是否符合团队习惯，也在脑子里更新「这个模块最近谁改了什么」。所以代码审查能长期存在，不只是因为它能找 bug，也因为它把技术检查和组织沟通绑在一起。

问题出在这里：当 AI 参与写代码后，这个混合物开始承压。

过去一次 PR 可能是几十行、几百行。Reviewer 读 diff，结合局部上下文和经验，至少还可以维持一种近似独立验证。现在 Agent 可以在很短时间里生成更多文件、更多测试、更多重构。代码看起来更整齐，注释更完整，测试也可能由同一个 Agent 一起补上。

人类读代码的速度没有同步提高。于是审查行为发生漂移：它仍然叫 review，但很多时候只是在确认「没有一眼可见的异常」。

这种漂移不能简单归咎于 Reviewer 不负责。生成侧被 AI 放大了，验证侧仍然靠人排队，系统吞吐开始失衡。

AI 提高了产出，也制造了验证债务

GitHub 曾做过一个受控实验，让开发者完成同一个编程任务。结果显示，使用 Copilot 的参与者完成速度快了 55%。这个数字被引用了很多次，它说明 AI 辅助编码确实能提高某些任务上的产出速度。

但产出速度只是半张图。

DORA 2024 报告给了另一半图：AI 对个人生产率、代码质量、文档和代码审查速度有正向关联，但对软件交付吞吐和稳定性出现了负向关联。这个结果不应该被简单理解成「AI 有害」。更合理的解释是，AI 提高了局部速度，但组织的交付系统没有自动跟上。代码更多了，验证、集成、发布、回滚和维护压力也更多了。

METR 在 2025 年对经验丰富的开源开发者做过一项研究，结果更反直觉。研究对象在自己熟悉的大型开源项目里使用早期 2025 年的 AI 工具，实际完成任务的时间反而变慢了。开发者自己以为 AI 让他们更快，但计时数据给出了相反结果。这个研究不能外推到所有团队和所有工具，但它提醒了一件事：在真实代码库里，读懂上下文、验证改动、修正 AI 产物，可能会吃掉生成速度带来的收益。

所以内部 AI Coding 工具建设不能只盯着「生成了多少代码」。更该追踪这些指标：

  • AI 生成的改动有多少需要返工。
  • PR 等待时间是否下降。
  • 合并后缺陷率是否变化。
  • 测试失败是更早暴露，还是被推迟到集成阶段。
  • 安全问题、权限问题、数据处理问题是否更容易被发现。
  • Reviewer 是在做真实判断，还是在为 AI 生成的大 diff 背书。

如果这些指标没有改善，AI Coding 只是把工作从「写代码」转移到了「审代码、修代码、解释代码」。

人类 Review 的缺陷检测价值被高估了

代码审查最容易被神化的部分，是找 bug。

很多团队默认相信，只要另一个资深工程师读过代码，深层问题就会更少。但现代代码审查研究一直在提醒，人工审查在缺陷检测上的价值没有想象中稳定。人类擅长发现表面问题：命名不一致、风格偏差、明显遗漏、边界条件看起来不对、实现和团队习惯冲突。遇到跨文件数据流、并发状态、权限传播、序列化边界、缓存一致性，人类逐行读 diff 的可靠性会快速下降。

AI 生成代码加剧了这个问题。因为模型生成的代码通常「看起来像好代码」。格式规整，命名自然，注释有条理，测试也像模像样。它不像初级工程师手写的粗糙代码那样容易触发 Reviewer 的警觉。

这类代码最危险的地方，在于表面合理。

一个典型例子是 API 契约。Agent 可能正确调用了函数名，也写出了通过当前测试的实现，但误解了某个隐含约束：返回值是否允许为空、重试是否幂等、日志里是否能出现用户标识、权限检查应该在业务层还是数据层。Reviewer 如果没有完整上下文，只看 diff 很难稳定发现这些问题。

所以 Monperrus 的论文说人工审查提供的保障带有幻觉成分。这个说法尖锐，但有现实依据。很多时候，人工批准给组织提供的是心理安全感，离可重复、可量化、可审计的质量保障还有距离。

机器审查机器代码已经有现实基础

Agent Review 并不是空想。

2022 年的 CodeReviewer 研究把代码审查活动拆成多个任务，包括质量估计、评论生成和代码精化。它说明模型可以被训练来处理一部分代码审查活动，虽然当时的能力还远不能替代完整工程判断。

SWE-bench 这类基准又从另一个方向证明了 Coding Agent 的进步。它要求系统在真实开源仓库里修复 issue，涉及读代码、定位问题、修改文件、跑测试。基准本身不能等同于生产环境，但它把评价从「会不会写函数」推进到了「能不能完成真实仓库里的维护任务」。

OpenAI 的 CriticGPT 更直接指向「AI 审 AI」这条路线。OpenAI 让模型辅助人类标注者检查 ChatGPT 写出的代码，目标是发现其中错误。官方文章没有宣称模型已经可以独立审查所有代码，它给出的更实际信号是：用模型批评模型输出，可以提高人类发现问题的能力。这正好对应内部工具建设中的中间阶段：Agent 不必一开始就拥有最终批准权，它可以先成为强力的验证助手。

这些证据合在一起，支撑一个比较稳的判断：Agent 审查会先替代大量低价值人工审查，再逐步进入更高风险区域。

它会优先接管这些工作：

  • 格式、命名、注释、文档规范。
  • 常见 bug 模式和危险 API 使用。
  • 测试缺口提醒和测试生成。
  • 依赖升级、简单重构、重复代码清理。
  • PR 摘要、影响面分析和 reviewer context 准备。
  • 安全规则的系统性枚举，比如 CWE、权限、输入校验、敏感信息泄露。

它不应立即接管这些工作：

  • 架构方向选择。
  • 复杂业务语义判断。
  • 法律、合规、隐私和伦理责任。
  • 跨团队接口契约变更。
  • 高风险生产系统的最终授权。

所以，「Agent 能不能 Review」已经不是最好的提问。更好的提问是：哪些 Review 目标应该交给 Agent，哪些必须升级给人类。

安全证据让事情更复杂

AI 生成代码不是天然安全的。

《Asleep at the Keyboard?》这篇早期研究评估了 GitHub Copilot 生成代码的安全性，结果显示模型在不少任务里会生成带安全问题的代码。即使今天模型能力已经显著提升，这个方向的风险仍然存在：模型会复制不安全惯例，会把缺失校验的实现写得很自然，也可能在压力下选择「能跑」而不是「安全」。

这并不意味着应该禁止 AI 写代码。它意味着安全验证不能继续靠随机的人类审查。

安全审查天然适合系统化。人类 Reviewer 往往是 ad hoc 的，想起什么查什么。安全 Agent 可以按规则表、威胁模型、CWE 分类、数据流、权限边界和历史漏洞模式逐项检查。专用安全 Agent 的价值不在于比最强安全专家更聪明，而在于它可以每次都跑、每次都留下证据、每次都覆盖同一套清单。

但安全 Agent 也带来新的攻击面。OWASP Top 10 for LLM Applications 2025 把 Prompt Injection 放在首位。放到代码审查场景里，问题会变得很具体：恶意提交者可以在注释、字符串、测试数据或文档里放入自然语言指令，诱导审查 Agent 忽略某个问题，或者相信某段伪造上下文。

这要求内部工具建设把「审查 Agent 被输入操纵」当成正式威胁，不能当成边缘情况。

最低限度的设计应该包括：

  • 系统指令和待审代码严格分离。
  • 注释、字符串、README、测试 fixture 默认当作不可信数据。
  • 审查结论必须引用可定位证据，不能只给自然语言判断。
  • 安全 Agent 和编码 Agent 使用不同模型、不同提示、不同工具权限。
  • 高风险发现不允许由同一个 Agent 自行关闭。
  • 所有自动批准都要留下审计日志和可复跑命令。

AI 写代码带来的安全债，不能用「让另一个 AI 看一眼」来偿还。它需要一个有边界、有权限、有证据的验证系统。

专家意见的共同点：少信感觉，多建系统

不同专家对 AI Coding 的态度差异很大，但有一个共同点：不能把生成结果当成可信事实。

OpenAI 做 CriticGPT 的动机，来自一个现实问题：模型越强，人类越难发现它的微妙错误。让模型帮助人类批评模型，是一种把验证能力系统化的尝试。

DORA 的研究也给出相似方向。AI 可能提升局部开发体验，但组织如果没有稳定的交付能力、清晰的流程和健康的工程文化，局部效率不会自动转化成整体交付表现。

METR 的研究则提醒，开发者的主观感受可能和真实耗时相反。AI 让过程感觉更顺，但真实任务里可能多了验证、回读、返工和上下文切换。

这些意见放在一起，得到的判断很清楚：AI Coding 工具的下一步不该只追求更会补全、更会改文件、更会开 PR。更重要的是让组织知道一段 AI 参与生成的改动为什么可信，哪里不可信，谁签过，出了问题怎么回滚。

这也是「从人审代码到 Agent 自治」这句话里最容易被忽略的部分。自治不等于无人负责。自治是把可自动化的判断交给系统，把需要人类承担的判断暴露出来，并且让整个过程有证据。

内部 AI Coding 工具要从 Copilot 思维升级

很多公司建设内部 AI Coding 工具时，第一反应是做一个更懂内部代码库的 Copilot。接入私有仓库，补内部 API 文档，支持 IDE 插件，能生成单测，能解释报错。

这一步有价值，但不够。

如果工具只提高生成速度，它迟早会把压力推给 Review、CI 和发布流程。成熟的内部平台应该从一开始就把验证放进核心设计。

可以把能力拆成四层。

第一层是 PR 级 Agent Review。

每次 push 后，Agent 自动读取 diff、相关文件、调用链、测试、历史提交和文档，输出结构化审查报告。报告不应该伪装成人类评论线程，而应该像 CI 产物一样可机器读取：风险分类、置信度、证据位置、建议修复、需要人类确认的原因。

第二层是风险分层门禁。

低风险改动可以由 Agent sign-off：依赖小版本升级、格式化、简单重构、测试补充、无业务逻辑变化的文档和配置更新。中风险改动需要 Agent 给出报告，人类抽查。高风险改动必须人工审批，比如支付、权限、用户数据、加密、核心业务状态机、生产发布脚本。

第三层是异质化验证。

编码 Agent、通用审查 Agent、安全 Agent、测试 Agent 不应完全同源。至少在模型、提示、工具权限和任务目标上要分开。原因很简单：同一个模型族可能共享盲点。让它审自己的产物，容易形成漂亮但脆弱的闭环。

第四层是 IDE 内实时反馈。

PR 审查太晚。等代码已经提交，开发者已经切换上下文，反馈成本就上来了。更好的体验是 Agent 在 IDE 里实时提醒：这个接口有隐含约束，这个日志可能泄露 PII，这个重试缺少幂等保障，这个测试只覆盖 happy path。很多问题应该在提交前消失。

这四层合起来，才是内部 AI Coding 工具从「辅助写代码」走向「辅助交付」。

人类角色会变少，也会变重

如果 Agent Review 做得好，人类 Reviewer 的日常负担会下降。命名、格式、简单 bug、重复建议、测试缺口、PR 摘要，这些工作不值得继续消耗资深工程师注意力。

但人类责任不会消失。它会集中到更少、更重的位置。

开发者需要更擅长写规格。Agent 能不能做对，取决于需求、约束、验收标准和上下文是否清楚。模糊需求在人工开发时代也会制造返工，在 Agent 时代只是返工速度更快。

技术负责人需要更擅长定义风险阈值。哪些路径可以自动合并，哪些必须人审，哪些需要安全团队签核，哪些要走架构评审，这些规则要被写成系统配置，不能靠 Slack 里临时喊人。

团队需要保留知识传播机制。过去很多知识藏在 Review 评论里。Agent 接管低价值评论后，组织要用 ADR、设计讲解、结对编程、变更摘要和事后复盘保留隐性知识。否则 Review 负担下降了，团队理解力也可能一起下降。

管理者需要改变指标。不要只看 AI 生成了多少代码、节省了多少小时。更值得看的指标是 lead time、change failure rate、PR wait time、review返工率、线上事故、回滚次数、安全发现前移比例。

Agent 自治越强，人类越要从执行者变成规则制定者、异常处理者和责任承担者。

三阶段迁移更现实

直接取消人工代码审查并不现实，也不负责。更好的路线是三阶段迁移。

第一阶段，Agent 只给建议，人类保留最终决策。

这个阶段的目标是建立信任基线。平台要记录 Agent 发现了什么，人类采纳了什么，后来线上问题有没有被 Agent 漏掉。没有这批数据，后面的自动批准没有依据。

第二阶段，低风险变更由 Agent 自动批准。

前提是风险分类足够清楚，审计日志足够完整，回滚路径足够成熟。这个阶段最适合从小范围仓库开始，比如内部工具、非核心服务、测试代码、文档和低风险重构。

第三阶段，Agent 驱动质量管道，人类处理异常。

这时审查已经变成系统能力：测试、静态分析、安全扫描、Agent 推理、运行时观测和回滚策略共同决定一段改动能不能进入生产。人类不再默认读每个 diff，主要处理高风险、高不确定性、跨团队影响和责任归属。

这条路线要优先保证每一步都有证据。没有数据的自动化会把风险藏起来。带审计的自动化，才是在暴露风险。

结论：代码审查会离开「读 diff」这个动作

代码审查不会结束。它会重新分层。

风格检查交给 formatter 和 linter。常见缺陷交给静态分析和 Agent。安全问题交给专用安全 Agent 和规则扫描。测试缺口交给测试 Agent 和覆盖率门禁。变更理解交给自动摘要和影响面分析。架构判断、业务语义、合规责任和价值取舍交给人。

过去，代码审查把这些东西塞进一个动作：找人读 PR。

AI Coding 时代，这个动作承受不了新的吞吐。继续把「人类批准」当成唯一安全阀，会让团队同时失去速度和真实保障。

更有说服力的判断是：未来的软件质量会越来越依赖持续运行的验证系统，单纯增加人力阅读更多 diff 很难跟上。Agent Review 是这个系统的一部分，不是全部。人类仍在系统里，但位置变了。

内部 AI Coding 工具建设应该从这个判断出发。不要只做更快的代码生成器。要做能解释、能验证、能分级、能审计、能让人类在关键位置介入的交付系统。

所谓从「人审代码」到「Agent 自治」，迁移的是质量责任的承载方式，不只是按钮权限。