编程的艺术：我为什么看错了 LLM

两年前，我写过一篇博客：

编程的艺术：我为什么拒绝使用 LLM

它火了，还一度排到 Hacker News 第 2 名。我收到了很多友善的邮件，来自那些被这篇文章触动的人。当时我写这篇文章，是基于一种想法：LLM 会把架构思考和解决问题的乐趣从编程里拿走。这个想法让我一直没有尝试 LLM。我的固执让我紧紧抓住原来的工作流不放，并迫使自己想出一些肤浅而艺术化的理由，好让自己继续停在原地。

发生了什么变化？

后来我明白，LLM 的上限取决于使用它的人。一个人如果只对 LLM 说“帮我做一个漂亮的网站，不要犯错”，几乎注定会得到不令人满意的结果。这是一个没有方向的 prompt，LLM 除了回归平均水平之外别无选择。

LLM 不能替代好的技术判断和审美判断，而这些判断来自一个人长期积累的经验。LLM 会，而且经常会犯一些对我们来说很明显的错误，也会做出品味糟糕的判断。发现这些问题、承担责任，并相应地修正方向，是使用者自己的事。

我错在哪里？

在原来的那篇博客里，我说过：“用 LLM 写代码，就像请一个艺术家替你作画。”只有在 LLM 和称职工程师处于同等水平时，这句话才成立，但事实并非如此。LLM 缺少工程师的经验和技术品味。用 LLM 写代码，并不意味着把整个编程过程都交给它。相反，这是一个协作过程：想法来回碰撞，代码在迭代中不断打磨。

我还曾把使用 LLM 等同于不够投入、不够关注细节。实际上，它反而让我能把更多心力放在这些事情上。LLM 帮我发现过一些我原本不会发现的边界情况和 bug，让我能够构建更可靠的软件。真正的问题在于，是否用心并不取决于过程中使用了什么工具。它是一种心态，也是一套自己为自己设定的标准。

把乐趣最大化

工程里有些部分至少对我来说并不好玩：又一次搭 REST 后端脚手架、把各个服务串起来、准备测试数据、搭建 CI/CD 管线，如此等等。它们重复、缺少想象力，但又是工作流中重要且必要的一部分。让 LLM 替我处理这些杂活，可以让我把注意力放在工程中有趣的部分，比如设计和编排系统，为小众问题想出新颖的解决方案，调整 UI 元素直到它们达到像素级精确，学习新东西，等等。

事实上，也有一些时候我会选择不用 LLM 来写代码。其中一个例子是构建 novem，它是一个基于 GPUI 的 GitHub PR 审阅工具。我喜欢写 Rust，也想学习 GPUI。当我想深入那些非常具体的细节时，让 LLM 替我写代码就没有意义了。在这种情况下，我会把 LLM 当成导师来用。它可以轻松浏览 GPUI 代码库，因此让我更快、更深入地学习 GPUI。

能力无法被替代

我再说一遍：

LLM 的上限取决于使用它的人。

它不是用来掩盖个人技能和知识短板的拐杖。一个没有设计品味的人，不可能只靠 prompt 就得到一个精心打磨的用户界面。不过，如果使用得足够用心，LLM 确实可以放大一个人的能力。它让我更有信心地构建东西，也让我能承担更多任务，但我从来没有把解决问题这件事委托给它。它让我能更快、更深入地学习新东西。

在一个充满低质内容的世界里，需要能力和判断力，才能从大量可丢弃的垃圾里分辨出真正有价值的东西。而这两者只能通过一路的磨练和考验培养出来。