文章

我们不再审查代码，转而开始验证意图

了解在 AI 生成代码的工作流中，验证意图如何比审查代码更高效。学习这套改变了我们流程的框架。

Ankit Jain

Ankit Jain

·2026年10月20日·7 分钟阅读

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

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

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

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

今年早些时候，我为 Latent Space 写了 《如何终结代码审查》 。这篇文章迅速走红，此后我一直没停止谈论 AI 代码审查的瓶颈问题。

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

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

本文介绍对我们影响最大的两项实践，以及它们最终归入的框架。

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

审查意图，而非 diff

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

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

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

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

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

挖掘你的 PR 评论，它们是等待成形的不变量

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

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

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

好的不变量是平淡而具体的。例如：

  • 任何涉及货币的内容都使用 Money 类型。
  • 禁止直接写入 users 表。
  • 只使用结构化日志器，不用 print 语句。

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

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

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

代码审查没有消失，只是改变了形态

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

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

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

简而言之

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

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

复制并分享

Ankit Jain

Ankit Jain

Ankit Jain 是 Aviator 的创始人兼 CEO。Aviator 是一个开发者生产力平台，现代工程团队用它来大规模交付 AI 生成的代码——不再受困于审查瓶颈、构建失败或脆弱的部署。 他还领导着 The Hangar——一个由资深工程师和工程负责人组成、专注于开发者体验的社区，以及 Xoogler——前谷歌员工校友网络。

1 篇帖子

阅读

·

0%

本文内容

为什么为 AI 生成的代码扩展代码审查行不通审查意图，而不是 diff挖掘你的 PR 评论，它们是等待发生的不变量代码审查没有消失，只是改变了形态

复制并分享

Ankit Jain

Ankit Jain

Ankit Jain 是 Aviator 的创始人兼 CEO。Aviator 是一个开发者生产力平台，现代工程团队用它来大规模交付 AI 生成的代码——不再受困于审查瓶颈、构建失败或脆弱的部署。 他还领导着 The Hangar——一个由资深工程师和工程负责人组成、专注于开发者体验的社区，以及 Xoogler——前谷歌员工校友网络。

1 篇帖子

$?/$