AI 代码审查倒置：当作者是机器时应关注什么

你的代码评审正在优化错误的目标。当 AI 智能体（agent）贡献了你大部分的代码提交（commits）时，评审局部正确性——这个函数的功能是否如其所述？——就像是通过检查笔迹来给数学考试评分一样。机器已经通过了你的代码检查工具（linter），运行了你的测试套件，并按照规范格式化了输出。它所引入的 Bug 并不是行内（line-by-line）评审所能捕捉到的那种 Bug。

一项针对 GitHub Pull Request 的大规模研究发现，AI 协同编写的 PR 包含的缺陷是纯人工 PR 的 1.7 倍——其中包含多出 75% 的逻辑和正确性问题、2.74 倍的安全漏洞以及 3 倍的可读性问题。这并不是因为代码看起来有问题，而是因为它在错误的地方做了错误的事情，且对系统的其他部分持有错误的假设。这些恰恰是为捕捉拼写错误和风格违规而优化的传统代码评审所无法发现的故障模式。

评审原则需要反转。不再是问“这段代码正确吗？”，首要问题变成了“机器是否理解了我们真正想要的是什么？”

AI 编写代码质量的悖论

这是一个令人沮丧的现实：AI 生成的代码在局部是连贯的，但在全局是脆弱的。它遵循惯用法，通过测试，能干净利落地处理正常流程（happy path）。然后，它会引入安全漏洞，调用具有错误分页语义的 API，或者悄无声息地忽略一个错误，从而将局部失败转化为隐蔽的数据损坏。

尽管通过了自动化检查，约 48% 的 AI 生成代码仍包含安全漏洞。在一项被广泛引用的研究中，AI 生成代码中约 60% 的逻辑错误完全通过了测试套件——直到进入生产环境才被发现。这些数据并非源于 AI 写错了语法，而是源于 AI 不知道它对你的系统有哪些未知的盲区。

根本原因在于上下文窗口。智能体可以看到你要求它编写的函数、该函数所在的文件以及少数相关文件。但它看不到上游三个服务之外的鉴权合约、与下游依赖协商的重试预算，或者是你在 2023 年迁移后某个字段绝不能为空的约束。它在已知信息的范围内编写了正确的代码，而它失败的地方正是它看不到的部分。

这不是一个当今模型可以修复的局限性——它是智能体在大型代码库中进行推理的结构性特征。你的评审流程需要直接考虑到这一点。

转变一：评审意图，而非实现

当人类编写代码时，你可以询问他们试图实现什么目标。代码是该意图的产物。而当智能体编写代码时，代码是唯一的产物——除非你保留了对话记录。

意图对齐现在是有效评审的第一道关口。在阅读任何一行代码之前，请回答以下问题：

• 给智能体的工单或规格说明（spec）是什么？
• 智能体在执行之前说它打算做什么？
• PR 描述（如果有）是否与 diff 包含的实际内容匹配？

这里的意图失调比任何实现细节的修复成本都要高得多。一个将“存档记录”误解为“删除记录”的智能体，会写出整洁、测试充分但却做错事的代码。你无法通过检查变量名来发现这一点。

适应了高 AI 贡献率的团队将智能体的对话历史视为一等公民产出（first-class artifact）——有些团队甚至要求像附带设计文档一样将其附在 PR 中。关于“为什么”进行更改的权威记录存在于对话中，而不是提交信息中。

如果你在不知道智能体被要求做什么的情况下评审 PR，那么你是在盲审。

转变二：把控全局一致性

在意图对齐之后，第二道关口是全局一致性：这一更改是否与智能体看不到的内容相冲突？

这就是上下文窗口限制表现得最具体的地方。智能体在 API、框架和模式的公共约定上受过训练。但它们没有在你的特定代码库约定、你与特定服务的内部合约，或者你两年前选择某种非显式实现的理由上受过训练。它们会用合理的默认值来填补这些空白——而合理的默认值在你的上下文中往往是错误的。

边界是问题显现的地方：鉴权流程、服务合约、缓存语义、错误处理策略、功能开关（feature flags）、分页行为。这些是触及多个文件和服务的横向关注点（cross-cutting concerns）。视野有限的智能体写出的代码在孤立状态下是有意义的，但在衔接处违反了合约。

一个实用的评审启发法：在代码“触及现有系统”的地方投入的时间，应比例性地多于它“执行新功能”的地方。一个新函数通常没问题。但该函数调用现有服务、读取共享缓存或写入具有现有 Schema 的表的地方——那才是你需要关注的重点。

一些团队在 AGENTS.md 或类似文件中明确记录这些横向合约，并将其注入智能体的上下文中。这很有帮助，但需要自律来保持更新，且无法替代了解系统的评审人员。

转变三：审计测试究竟在测试什么

AI 代理会编写测试。它们编写的测试往往验证的是它们自己的假设，而非你的规范。

加载中…