Tessl 团队分享：不再逐行审查 AI 生成代码，改为验证意图

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

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

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

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

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

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

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

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

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

审查意图，而非 diff

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

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

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

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

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

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

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

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

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

• 任何带货币的内容都使用 Money 类型。
• 不要直接写入 users 表。
• 仅使用结构化日志记录器，不要使用 print 语句。

并非每条评论都符合条件。

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

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

代码评审没有消失，它改变了形态

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

1. 争论。让智能体在拉取请求存在之前就互相挑战对方的方案，此时改变方向成本最低。
2. 捕获。记录意图和验收标准，并把它们放到拉取请求上。
3. 固化。把团队反复重复的评论转化为不变量。
4. 辩论。把人工评审时间花在决策上，而不是 diff 上。
5. 归属。确定谁拥有验证代码的规则。

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

tl;dr

• 把 diff 评审扩展到匹配 AI 产出是行不通的。
• 在代码生成之前评审意图，并用证据验证每一条标准。
• 把你反复出现的评审评论转化为不变量。
• 让人类专注于决策以及规则的所有权。

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