代码审查思维助力 AI Agent 高效使用

正确使用 AI agent 本质上是一个代码审查的过程。如果你擅长代码审查，你就会善于使用 Claude Code、Codex 或 Copilot 代码 agent 这样的工具。

为什么呢？大语言模型很擅长生成大量代码，但还没有达到资深软件工程师那样的判断深度。在缺乏监督的情况下，它们会花费大量时间去执行糟糕的设计决策。

AI agent 与糟糕的设计

上周我构建了 VicFlora Offline：一个离线友好的 PWA，托管了一些 VicFlora 数据用于植物分类键盘的使用，这样你在田野里网络不好的地方也能使用这些分类键。Codex 花了不少力气去反向工程 VicFlora 前端代码的二叉键。说实话，看着它工作真的很令人印象深刻！但我想应该有更简单的方式来访问原始数据，事实确实如此。这种情况在我使用 AI 代码 agent 时一再发生：大约每小时我会发现一次 agent 在做一些看起来可疑的事情，而当我深入挖掘时，我能够把它引向正确的方向，节省数小时的浪费工作。

我也在开发一个帮助我用 AI 学习的应用程序——可以把它想象成一个无限的、自动调整的间隔重复流。当我想并行做事情时（比如在后台生成学习计划），Codex 和 Claude Code 都很想构建一个完整的后台任务基础设施：带有任务实体、结果轮询等等。我喜欢后台任务，但对于普通的短期并行工作，它们明显是过度设计了。只需从前端发起一个非阻塞请求就行！如果我没有始终推动简洁性，我的代码库会复杂得多，难以理解。

顺便说一句，这就是我认为纯粹的"vibe coding"没有产生有用应用爆炸的原因。如果你没有足够的技术能力来发现 LLM 何时走错了方向，你很快就会被困住。试图让一个设计糟糕的解决方案正常工作需要花费时间、token 和代码库复杂性。所有这些因素都会削弱 agent 实际解决问题的能力。一旦其中两三个因素堆积起来，app 对 agent 来说就不再容易处理，整个事情就会陷入困境。

这些例子对任何在有热情的初级工程师的工程团队中花过足够时间的人来说都应该很熟悉。直接跳入一个早期想法并通过纯粹的努力让它工作是一个非常常见的错误。团队其他成员的工作就是制约这一点。使用 AI agent 就像与充满热情的初级工程师一起工作，但他们永远不会像真人那样随着时间的推移而发展判断力。

这是一个很好的机会来讨论我认为工程师在代码审查中犯的最大错误：只考虑已编写的代码，而不是可能编写的代码。我见过甚至经验丰富的工程师进行代码审查，他们用细致的梳子仔细检查diff，但花在思考这段代码是否应该出现在这个地方的时间几乎为零。

在我看来，最好的代码审查是结构性的。它从 diff 未提及的代码库部分引入上下文。理想情况下，这个上下文使 diff 更短、更优雅：比如说，与其为操作 X 构建一个新系统，我们可以重用已经存在的系统。与其构建一个脆弱的爬虫管道从前端 SPA 代码中拉取二叉键 ID，不如从另一个明确提供这些数据的地方下载二叉键。与其构建一个完整的后台任务系统，不如在客户端进行并行工作，使用网站为了同时做两件事而已有的所有机制。

如果你是一个吹毛求疵的代码审查者，我认为你会在使用 AI 工具时遇到困难。你会永远在调整单行代码，要求用 .reduce 代替 .map.filter，争论函数名称，等等。与此同时，你会错过机会去引导 AI 远离架构死胡同。

同样，如果你是一个橡皮图章代码审查者，你可能会对 AI 工具过度信任。这种方法对于能干的同事有效，但当你在培养初级工程师时效果不好，当你与 AI 代码 agent 一起工作时也效果不好。

"擅长 AI"是什么意思呢？擅长像 git 这样的普通工具很简单：如果你掌握了 git 仓库基本的树形结构，并且熟悉大部分 git 操作，你就擅长 git。但 AI 的基本结构是一团不可穿透的模型权重，它能执行的"操作"是"基本上任何你能用计算机做的事"。没有软件工程工具像它这样。

最乐观的 AI 倡导者认为"擅长 AI"就是在生活的各个方面最大限度地采用 AI 工具。这个论点是，AI 扮演着类似杰夫·贝索斯的员工团队的角色。使用一个超级充分配备、超级能干的员工团队并不需要很多技能：你只需要说出你想要的，会有大量的其他人的努力投入来提供它。但贝索斯肯定比我如果今天被传送到他的位置，能更有效地使用他的员工。我甚至不会考虑要求我想要的一半东西——我根本不会想到当我下飞机时可能有一个热的 Lune 牛角面包在等我，即使我真的会很喜欢它。AI 信徒认为 AI 工具有点像这样。按他们的说法，当你真正内化了你可以让你的个人 AI 助手 vibe code 任何你想要的程序、整理任何数量的数据、或起草你所有的电子邮件时，你会开始更频繁地使用 AI，对你有利。

我认为我们还没到那个阶段。我经常使用 agent 代码工具：在工作时用 GitHub Copilot，在个人项目中同时使用 Codex 和 Claude Code。虽然它们能独立完成令人惊讶数量的任务，但它们确实需要相当密切的监督。主流编程模式有点像"半人马棋"，一个熟练的人类与一个计算机助手配对。你越擅长代码审查——越擅长评估一种特定的软件方法是否合理——你就越能好地使用 agent AI 工具。

编辑：这篇文章在 Hacker News 上获得了一些关注。大多数评论都在重复"AI agent 是否有效"的问题，这对我来说不是很有趣（我的观点是"当然在某些代码库上有效，但在其他代码库上他们会完全无用"）。我不认为好的代码审查能以某种方式让 AI agent 对 Linux 内核做出实质性贡献。有几条评论为"代码味道和函数命名"风格的代码审查辩护，并暗示如果你在代码审查中讨论设计，你在前期功能规划上失败了。我非常强烈地不同意这个观点，会在某个时候写一篇博客文章来讨论它。

每次我看到这个观点被提出，我都想——如果你在 2022 年开始用早期的 Copilot 使用 AI 代码工具，到 2025 年你仍在使用尖端的 AI 工具，这感觉不像工具的增长速度和人类一样吗？如果你把早期的 Copilot 描述为一个新毕业生，把当前的 Claude Code（或其他什么）描述为一个有三年经验的工程师，这会离谱吗？再过三年，使用 AI 工具会不会像与一个有六年经验的工程师一起工作？↩

使用 Codex 和 Claude Code 并不表示我认为它们比 Copilot 更好。在我看来，使用各种 AI 工具是我工作的一部分。↩

如果你喜欢这篇文章，考虑订阅我的新文章的电子邮件更新，或在 Hacker News 上分享。

这是一篇与这篇相关的文章预览，它们共享标签。

建造一个 RTS，你向 AI agent 下达命令

我一直被《安德的游戏》中第三幕的转折所吸引，即儿童战略家从直接控制单位转变为下达更高层次的战略命令。通信问题看起来非常迷人：你获得了大量的灵活性，但你必须适应由你的下属根据实地情况做出的决策。出于类似的原因，我一直对在发送信息非常困难的前现代战役中下达命令如何进行感兴趣。继续阅读...