多AI智能体协作时代，如何高效审查代码

dev.to · AI#AI编程#代码审查#Agent

Editor brief · 编辑速览

AI智能体生成的代码表面干净但意图未必正确；审查时应先问「为什么改这个文件」，再定位测试验证其是否真正能捕获实现错误。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

我批准了一个通过所有测试的交付物。

这些测试同样是由同一个 agent 编写的，用空实现去跑也会通过。

与信任的同事合作时，你相信他的意图，只审查执行。与 AI agent 合作时，意图是不确定的部分：它可能理解错了什么、解决了相邻的问题、或者只是修了表象。代码无论如何都会输出得很干净，因为写出干净代码是它最擅长的事。

审查 AI agent 交付物时，从哪里开始？

最便宜也最能揭示问题的问题是："为什么改了这个文件？"列表中出现一个你意料之外的文件，是任务理解出现偏差的最可靠信号。十秒钟就回答了，节省了你读三百行代码的时间。

读实现之前，先找到测试。两个问题：测试存在吗？如果实现是错的，它会失败吗？第二个才是关键。用空实现也能通过的测试在 AI agent 输出中很常见，因为它是冲着"通过"去的，而不是冲着"证明"去的。

还要找一样特定的东西：哪些假设是没有明说就被接受了的。比如网络有响应、列表不为空、用户有权限、日期在正确的时区。这正是 agent 输出最容易出问题的地方，而在流畅阅读中这完全是隐形的。

当三个 AI agent 并行工作时，历史变成了一根辫子，按提交逐条阅读讲不出任何人的完整故事。一次审查一个完整的正面，问"这个任务完成了吗？"，只有在确认之后才去看各正面之间的交互。

那个交互的地方就是并行特有的缺陷所在：每个正面单独看都是对的，放在一起就矛盾了。按正面逐个审查发现不了这个问题，这就是为什么在合并之前运行完整测试套件不是可选项。

值得，但有一个条件：必须来自另一家公司。同一家公司的两个模型给出的是同一观点的两个版本。来自不同公司，它们会真正产生分歧，而分歧指向的是你需要重读的地方。它不能替代你的审查，只是缩短了你的审查时间。

要求更小的交付物。大型任务产生大型交付物，检查慢、拒绝难——错了的时候你就在"接受一大块"和"全部重做"之间二选一。三个小正面比一个大正面强，因为你可以增量审批。