在最近一期的 Dwarkesh Podcast 节目中，人工智能研究员 Andrej Karpathy（前 Tesla 人工智能和 Autopilot Vision 总监）分享了他在 AI 辅助编程方面的经验和见解。他所讨论的内容引起了我的共鸣 —— 许多程序员会意识到他所描述的同样的紧张关系和权衡。

下面我将介绍 Andrej 的主要观点（如果你有兴趣，也可以查看完整的访谈）。

编程风格

Andrej 描述了当今三种广泛的编码方法：

• 老派的 scratch 模式：完全手动编写所有内容，完全忽略 AI 工具。

• 带有自动完成功能的混合模式：你编写主要的逻辑，但依靠自动完成或 AI 建议来处理样板代码。你仍然清楚地知道事情应该如何运作 —— AI 只是帮助实现一些小部分。

• Vibe coding：你提示类似“请实现这个”的内容，让模型完成繁重的工作，然后按 Enter 键。

Andrej 将自己定位在第二种阵营：他自己编写大部分逻辑，并在有意义时使用自动完成功能。

AI 辅助代码的优点和缺点

目前的人工智能编码模型擅长创建只是复制粘贴的样板代码。

人工智能编码模型也擅长互联网上已有的内容。例如，如果你正在用 Go 构建一个 HTTP 服务器，它可以帮助轻松创建基本的 HTTP 服务器代码，因为它非常标准，因为这些模型已经在许多此类代码上进行了训练。

人工智能编码模型降低了新语言的可访问性。例如，如果你有一个非常熟悉的 Python 项目，并且你想用你不太擅长的 Rust 重新实现它（为了提高性能），那么这是一个非常适合编码模型来帮助你的场景。

虽然编码模型确实具有所有这些优点，但它们也存在一些缺陷。以下是 Andrej 分享的一些：

他们不断误解代码，因为他们的记忆中有太多的代码，这些代码通常以某种可能不适应的方式做事。一个例子：

So the way to synchronize, so we have eight GPUs that are all doing forward backwards. The way to synchronize gradients between them is to use a distributed data parallel container of PyTorch, which automatically does all the, as you're doing the backward, it will start communicating and synchronizing gradients. I didn't use DDP because I didn't want to use it because it's not necessary. So I threw it out. And I basically wrote my own synchronization routine that's inside the step of the optimizer. And so the models were trying to get me to use the DDP container, and they were very concerned about, this gets way too technical, but I wasn't using that container because I don't need it, and I have a custom implementation of something like it.

编码模型也喜欢搞乱风格，有时它们过于防御。他们会创建大量的 try-catch 语句，而程序员编写的代码已经有了安全的假设。这通常会导致非常复杂和混乱的实现。

他们偶尔也会使用已弃用的 API。同样令人恼火的是，人们需要在需要的内容上输入太多的英语，然后等待实现。

总的来说，Andrej 认为完全使用 AI 辅助编码模型编写代码不是一个好主意。它们有好的部分，但仍然有很多需要改进的地方。