AI Agent时代的代码评审：主干-枝叶树模型、爆炸半径与Agent验证

随着AI Agent生成代码的速度爆发式增长，沿用传统方式逐行阅读代码已不再可行。Lữ Minh Khương的这篇综述基于Meta高级主任软件工程师John Kim的实战分享，提出梯度评审策略：评审的深度取决于代码的安全性和影响范围（爆炸半径）。

快速回答： AI Agent生成的代码量使逐行阅读成为不可能；应改为基于爆炸半径的梯度评审。代码库按树模型分类：主干代码（Trunk Code，核心、基础设施、共享状态）需要深度评审，而枝叶代码（Leaf Code，隔离组件、位于功能开关后的新端点）只需附带证据快速浏览。编写代码的Agent必须在每个PR中附上验证证据：测试、运行时日志、可视化证明和置信度。评审Agent必须是全新上下文的新Agent，绝不能用编写代码的同一个Agent自我评审。Merge-ready只完成了80%的路程；最后20%是全功能审计和通过金丝雀部署逐步上线。

梯度评审（Gradient Review） 是一种按优先级评审AI生成代码的策略：不再对每一行代码同等对待，而是对爆炸半径大、风险高的部分进行深度评审，对已用功能开关包裹且有充分验证证据的隔离部分则快速浏览。

AI时代代码评审争论的两个极端

谈到AI时代的代码评审，工程界明显分成两个极端。一方认为，如果还坐着逐行阅读AI写的代码，就是走得太慢了，因为现在的AI Agent发现错误的能力已经超过人类。另一方则对AI slop（由无节制的vibe coding产生的AI垃圾代码）极为警惕，认为它会导致低级错误和生产环境中堆积的技术债。

John Kim的方法并不完全站在哪一边：评审的深度完全取决于代码的安全性和影响范围。本文综述了他分享中的要点，并结合综述作者的一些实战观点。

树模型：主干代码和枝叶代码有何不同？

当一名工程师可以同时启动多个AI Agent编写功能时，每天涌入的Pull Request（PR）数量巨大。如果保持对每个文件逐行细读的习惯，评审者自己就会成为瓶颈。解决方案是把代码库看作一棵树：

	主干代码（Trunk Code，主干和根）	枝叶代码（Leaf Code，枝叶）
示例	主入口、基础设施、网络、图像处理、大型共享状态（Reducer、核心服务）	单个UI组件、尚未接入生产主流程的全新API端点
风险	单向门，下游依赖众多；一处错误可能导致整个应用崩溃	相互隔离，影响范围小
评审方式	逐行细读，分析副作用，严格评审架构	快速浏览，前提是有充分证据且位于功能开关之后

为什么要从规划阶段就设计功能开关？

要敢于快速浏览枝叶代码同时还能安心，关键原则是从规划阶段就应用功能开关（Feature Gating，通过LaunchDarkly进行功能切换，或只是在配置中设置一个布尔标志）。当位于功能开关后的新代码与触及旧系统的集成层明确分离后，评审时最重要的问题就变成：如果这段代码在生产环境中出错，现有体验会受影响吗？能否通过关闭开关立即回滚？如果答案是肯定的，逐行评审的压力就会大幅降低。

Agent验证：强制AI在每个PR中提供证据

与其自己拉取分支逐一运行测试，不如配置技能，强制AI Agent自我验证并直接在PR中附上证据：

• 单元测试和集成测试： 快速浏览测试函数名和断言语句就能很快掌握逻辑。但需要为Agent训练专门的技能，避免AI写出一堆无用测试——只追求覆盖率而不检查真正的业务逻辑。
• 运行时证据： 让Agent具备读取运行时日志的能力，以便在报告之前自行运行、读取错误日志并自我修复。
• 可视化证明： 对于界面变更，强制Agent截取UI截图或录制屏幕视频，证明功能已经正常工作。
• 置信度： 要求Agent评估自己对刚写代码的置信度以及功能开关的安全性。

一个实用的细节：为Agent准备一个简洁的PR模板。没有模板时，AI经常把PR描述和测试计划写得像小说一样长——有时文字比代码差异本身还长。

为什么要终结吹毛求疵的文化并使用对抗性评审Agent？

在PR上逐行评论"这个变量名这样更好"或"我更喜欢那种风格"（nits，吹毛求疵）的时代已经过去了。随着代码生成速度加快，以及AI使重构变得极其廉价，代码风格、格式和类型检查等问题应全部交给静态分析和Linter自动处理。

特别是当用AI评审AI写的代码时（通过Claude Code或Codex GitHub集成），存在一个很大的陷阱：用刚刚编写代码的同一个Agent来评审它自己的代码。因为它掌握着之前全部的对话上下文，它往往会"作弊"并偏向自己刚做的解决方案。标准做法是启动一个全新的子Agent——对抗性评审Agent（Adversarial Review Agent）——对聊天历史一无所知，只看代码差异和技术规范，以最客观的方式发现漏洞。此外，为避免人与机器在GitHub上就琐碎评论来回拉锯，可以设置定期机制（例如每小时一次），让一个Agent自动检查PR、按评审Agent的评论自行修复、重新运行本地验证并更新PR。

Merge-ready和Launch-ready有何不同？

这是综述作者最看重的部分。许多人用AI写完一系列PR，看到测试全部通过，合并到主分支后就认为自己完成了100%的工作。实际上，按照大笔触（broad strokes）的做法，当代码达到merge-ready状态时，只完成了80%的路程。

把代码变成launch-ready的最后20%才是花费最多心智、体现工程师水准的部分，往往耗时与前80%相当。在准备向真实用户开放之前，需要从全局视角对整个功能进行全面审计：

• 检查性能、安全和边界情况错误。
• 评估产品是否符合原始规格，是否保持了human taste（流畅度、真实体验）。
• 重构并清理代码库结构，避免垃圾堆积。
• 始终通过A/B测试或金丝雀部署开放功能——通过功能开关逐步放量，观察崩溃率、指标和告警，然后再开放到100%。

总之，AI Agent让最初的几步变得极其快速，但保持系统稳定的责任仍然在于安全保障的设计思维和工程师在关键点的判断力。

常见问题

1. 应该逐行阅读AI写的每一行代码吗？ 不应该。按照这种方法，只有主干代码需要逐行细读；已用功能开关包裹且有充分证据的枝叶代码只需快速浏览。

2. 什么是爆炸半径？ 它是代码出错时的影响范围：主干代码的改动爆炸半径大，因为会影响整个应用；而隔离的枝叶代码爆炸半径小。

3. Agent验证包括哪些证据？ 单元测试和集成测试、运行时日志、可视化证明（UI截图/视频）以及Agent自我评估的置信度。

4. 为什么不能让Agent评审自己的代码？ 因为Agent掌握着之前全部的上下文，很容易偏向自己刚做的解决方案。需要一个全新的对抗性评审Agent，只看代码差异和技术规范。

5. Merge-ready就足够上线了吗？ 不够。Merge-ready只完成了约80%的路程；剩下的20%是全功能审计、性能和安全检查、规格验证，以及通过金丝雀部署逐步上线。

来源：Lữ Minh Khương于2026年11月12日在VGU Tech Alumni小组发布的综述，基于Meta高级主任软件工程师John Kim的分享。本文改写并重构了原文；文中的要点为综述作者和原分享者的观点。