LLM 不会设计用 LLM 的软件，一位开发者给了三种解释

LLM 不知道如何设计使用 LLM 的软件。它们写普通程序很自如，但如果你把一个问题以 AI 的形态抛给它们，它们通常会把事情搞砸。为什么会这样？

掉进符号主义的兔子洞

比如，这篇博客文章描述了一次尝试：用 vibe-code 的方式做一个能在一条记忆与另一条记忆相矛盾时发出标记的记忆工具[1]。这是一个绝佳的例子——这类任务在五年前几乎不可能完成，如今由于 LLM 的存在已相对简单。你完全可以只让 LLM 去扫描矛盾，无论是大批量处理还是两两比对[2]。

然而，当被问到“最先进”的做法时[3]，这个案例中的 AI agent 并没有推荐 LLM。它开始构建一个复杂得令人发懵的符号系统，把记忆条目转换为结构化的逻辑原子，然后用求解器机械地比较它们。这当然没用，也不可能有用，因为不存在任何解析性的方法可以判断两个自然语言句子是否表达同一个命题。

LLM 明明知道这不可能！当用户最终失去耐心，说“嘿，为什么这不管用”时，Claude 立刻解释说，这是一个已知的、有 130 年历史且无解的问题。然而它还是乐此不疲地原地打转了数周，在一条死胡同里反复迭代。

我自己也碰到过这种情况。我在构建 Autodeck（AI 生成的间隔重复卡片）时，我的 agent 常常试图用正则或关键词搜索给卡片分类，而不是干脆再发起一次 LLM 调用。

为什么 LLM 不能正确地使用 LLM？

为什么会发生这种情况？我有两个显而易见的解释和一个更深层的解释。

第一个显而易见的解释是，大部分训练代码都早于 LLM 时代。假设实验室没有把如今雪崩般的垃圾仓库直接喂给模型[4]，那么模型学习到的绝大多数代码都写于 LLM 还不可选的年代。所以它们伸手去用非 LLM 的方法就显得合理了，就像它们会选择 jQuery 而不是现代原生 JS，或选择 Backbone.js 而不是 React 一样，对吧？其实错了！LLM 并不会选择 jQuery 和 Backbone。训练过程中推动它们在其他领域掌握最新知识的那部分机制，并没有成功推动它们走向 LLM，所以这不能解释全部。

第二个显而易见的解释是，RLVR 并不是编写调用 LLM 的代码的好环境。LLM 在训练中花的大部分时间都处于强化学习环境中，由自动评分器判定它们的表现（比如运行它们写的一些代码并检查输出）。我并未确知这一点，但如果这些环境具备让 LLM 调用其他 LLM 的凭证和 API 访问权限[5]，我会感到惊讶。因此，即使预训练的 LLM 乐意写这类代码，强化学习过程也可能抑制它这么做[6]。

第三个解释——也是我最喜欢的——是当前的 AI agent 就是不太擅长软件设计。按这个解释，选择一个注定失败的符号方法、而不是简单地调用 LLM，并不是什么奇怪的偏差，而是 AI agent 选错工具的一种正常表现。我在其他场景中也见过 LLM 的这种行为：试图构建复杂（且注定失败）的共识算法，而不是容忍陈旧数据；在事件驱动系统中引入同步检查，等等。过去我把这些归因于对齐，但我愿意接受这个想法：它们只是普通的软件设计错误。

结论

一个我一遍又一遍学到的教训是：我无法用人类的标准来评判 LLM。任何有能力实现一个复杂符号求解器的人类程序员都会知道它行不通，所以如果他们提出这种方案，我会假定[7]他们有充分的理由。只有 LLM 才能既聪明到足以、又愚蠢到足以犯下这种错误。

我写过很多关于高效使用 LLM 所需技能的内容。我仍然坚持我在 2025 年 2 月写下的观点：

用好 LLM，意味着从它们擅长的地方提取价值，并避免在它们不擅长的地方浪费时间。

这出奇地难，原因就是上面那一点。LLM 的好与坏似乎是随机的：它们会努力工作上几个小时，有时却出奇地敷衍低效；它们能调动超人般广博的专业知识，却无法应用最基本的常识；它们能成功重写极其复杂的程序，却常常在设计上犯下非常愚蠢的错误。

如果你能提前预测它们在哪些方面做得好或差，你就能从 LLM 身上获得巨大的价值；如果你做不到，你很可能会浪费大量时间和 token，走上毫无希望的道路。

[1] 这里还有一个例子：用户“暗示”Opus 5.5 应该使用 judge model，而它却构建了一连串正则检查。

[2] 这里我大概会用一个 decision model。

[3] 事后看来，这可能是关键错误，虽然我不知道该怎么把它变成给非技术 vibe-coder 的建议。从不询问 agent 该领域的现状也是一个错误。再给“LLM 会奖励专业性”的说法添一笔。

[4] 我认为这是个合理的假设：尽管用低质量合成数据训练显然不会对 LLM 造成灾难性影响，但它肯定也好不到哪里去。

[5] 那会昂贵、缓慢且有风险。

[6] 这个理论也解释了为什么 LLM 很擅长把其他 LLM 当作子代理来提示，或在从头训练 LLM 方面表现出色：它们很可能直接在这些方面被 RL 和评估，而不是在编写调用 LLM 的代码方面。

[7] 好吧，我不会——我傲慢到无论如何都会问——但至少会期望一个好理由。