团队停止逐行审查代码，转而验证意图：应对 AI 生成代码的评审瓶颈

作者：Ankit Jain，为 AI Native DevCon 撰写

当你的团队合并的拉取请求数量是一年前的四倍，而且几乎没有任何代码是由人类敲出来的，你会怎么做？

这就是我的团队如今的现状。我们交付的几乎所有内容都是 AI 生成、人类辅助的，而且数量还在不断攀升。我们首先做了最显而易见的事。我们尝试通过使用 AI 审查工具或增加更严格的检查清单来扩展代码审查。这些都没有奏效。
真正奏效的是彻底放弃逐行阅读代码，并围绕意图构建一个验证层。

为什么为 AI 生成的代码扩展代码审查没有奏效

今年早些时候，我为 Latent Space 写了如何终结代码审查。那篇文章火了，从那以后我就一直在谈论 AI 代码审查的瓶颈问题。

这个问题不断出现，因为它的成因不会消失。在四倍的数量下，审查成了交付过程中最慢的一步。

大多数使用 AI 编码工具的团队都会遇到代码审查瓶颈，并试图通过增加审查人员、添加 AI 代码审查工具或对代码生成施加更严格规则等组合方式来解决问题。但真正的问题在于被审查的内容是什么。差异（diff）告诉你改了什么，但不会告诉你这个改动本应做什么。

本文涵盖了对我们影响最大的两项实践，以及它们最终契合的框架。

作为基线，我们现在维护一项共享技能，我们称之为“offer-skill”，以最初发起它的工程师命名。它变成了所有人用来理解代码改动的技能。

传统观点认为，人的判断应放在最后。由某人阅读代码并判断它看起来是否正确。

对于 AI 生成的代码，这会让审查者陷入困境。他们阅读 400 行代码，试图逆向推断这个改动原本要做什么。工单描述只有在团队有维护良好工单的纪律时才有帮助。现实是，大多数工单起草得很糟糕，实际的意图和行为会偏离工单。

所以我们把人的判断移到了前端。在生成任何一行代码之前，我们先审查意图：验收标准、约束条件和边界情况。这正是资深工程师的注意力最有价值的地方，因为在这个阶段，一个错误的想法修复起来几乎不花什么成本。
然后我们把该意图当作一份可以验证的契约。每条标准都会得到一个确定性的判定，并附上证据。

现在的审查看起来不一样了。审查者不再滚动浏览 500 行 AI 生成的差异。他们看到的是五条标准的判定结果，附有截图和展示实际发生情况的请求追踪。

这对开发者意味着什么？作者和审查者在合并之前都清楚代码应该做什么。而且，如果你在改动存在之前说不出它应该做什么，那么事后阅读它也不会告诉你。

每个团队都有一些存在于资深工程师头脑中的标准。它们通过一条条审查评论被强制执行。

翻看你的审查历史，你会看到同样的评论被一遍又一遍地写出来。那些就是隐藏在纯文本中的团队标准。在四倍的 PR 数量下，手动重复它们本身就成了一种瓶颈。

所以我们回溯了 X 上我们反复出现的审查评论，把它们转化为不变量：机器在每次改动时强制执行的可复用规则。

一个好的不变量是乏味且具体的。例如：

并非每条评论都够格。

如果你想尝试，先从最近 1,000 条评审评论开始。你重复最多的那 20 条就是你的第一批不变量。你不是在发明规则，你是在把已有的规则写下来。
一旦某项标准成为不变量，就再也不用有人去标记它了。

要记住，这个转变不会一夜之间发生。第一个月很可能感觉团队在做双份工作：评审代码，同时构建不变量。要和团队设定明确的预期：规则登记册的建立需要时间。到了第二个月，登记册能拦下足够多的问题，评审就会缩减。到了第三个月，评审者读的是意图，而不是代码。

我们仍然在评审。改变的是评审的目的。上面这两项实践，是我现在用来描述它的五步形态中的一部分：

对我们来说，结果是代码评审不再是瓶颈。资深工程师不再去读 500 行 AI 生成的 diff。

当 AI 写了你的大部分代码时，人类的评审最好花在这次变更应该做什么上。我会在 AI Native DevCon 上完整讲解这套工作流，并带来不变量定义的实例和前后对比指标。