Zed 编辑器的博客发的新文章，提出了“心智模型”的说法，可以看看。

Why LLMs Can’t Really Build Software — Zed’s Blog

为什么大语言模型（LLM）还不能真正开发软件

我花了很多时间做的一件事，就是面试软件工程师。这显然是个难题，我也不敢说有什么灵丹妙药；但它确实让我有机会深入思考，那些真正优秀的软件工程师到底是怎么工作的。

软件工程的循环

当你观察一位经验丰富的软件工程师时，你会发现他们总是在重复以下几个步骤：

• 构建对需求的心智模型（mental model）。
• 编写代码（希望它能实现需求！）。
• 构建对代码实际运行情况的心智模型。
• 找出两者之间的差异，然后更新代码（或者调整需求）。

完成这些步骤的方法有很多，但优秀工程师的显著特点在于他们能够构建并维护清晰的心智模型。

那么，大语言模型（LLM）呢？

公平地说，大语言模型在编写代码方面确实相当出色。当你指出问题所在时，它们在修改代码方面也表现得相当不错。它们还能做很多真正软件工程师会做的事情：阅读代码、编写和运行测试、添加日志，甚至（大概）使用调试器。

但它们无法做到的是：维护清晰的心智模型。

大语言模型会无休止地陷入困惑：它们会想当然地认为自己写的代码是正确的；当测试失败时，它们会不知所措，不知道该修改代码还是修改测试；而当它们感到沮丧时，干脆就把所有东西都删掉，从头再来。

这与我所寻找的优秀工程师特质恰恰相反。

软件工程师在工作过程中会不断测试。当测试失败时，他们可以对照自己的心智模型来决定是修改代码还是修改测试，或者只是收集更多数据再做决定。当他们感到沮丧时，可以通过与人交流来寻求帮助。虽然有时他们也会删除所有代码从头再来，但那是在对问题有了更清晰理解之后。

但很快就会改变，对吗？

随着模型能力越来越强，这种情况会改变吗？也许吧？！但我认为这需要改变模型的构建和优化方式。软件工程需要的模型，不仅仅是能生成代码那么简单。

当一个人遇到问题时，他们能够暂时搁置全部上下文，专注于解决当前问题，然后“弹出”他们的思维堆栈，回到手头的主要任务。他们也能够“放大”视野，关注大局，让细节暂时消失，只在必要时才深入到小块内容中。我们不会仅仅因为要处理更多信息，就不断往自己的“上下文窗口”里塞更多文字，因为那会把我们逼疯。

即使不考虑上下文过多的问题，我们也知道当前的生成式模型存在几个直接影响它们维护清晰心智模型能力的问题：

• 上下文遗漏：模型不擅长发现被遗漏的上下文信息。
• 近因偏差：它们在上下文窗口中存在强烈的近因偏差（即更关注最近的信息）。
• 幻觉：它们经常会“幻觉”出一些本不该存在的细节。

这些问题希望不是无法克服的，目前也正在进行相关工作，试图为模型添加记忆功能，让它们能像我们一样进行类似的“思维技巧”。不幸的是，就目前而言，它们（一旦复杂度超过一定程度）还无法真正理解正在发生什么。

它们无法开发软件，因为它们无法维护两个相似的“心智模型”，找出差异，并判断是应该更新代码还是调整需求。

那么，现在怎么办？

显然，大语言模型对软件工程师来说非常有用。它们可以快速生成代码，并且在综合需求和文档方面表现出色。对于某些任务来说，这已经足够了：需求足够清晰，问题足够简单，它们可以一次性完成整个任务。

话虽如此，对于任何非简单的任务，它们都无法准确地维护足够的上下文，从而迭代出一个可行的解决方案。你，作为软件工程师，仍然需要负责确保需求清晰，并且代码确实实现了它所声称的功能。

在 Zed，我们相信一个人类与智能体（agents）可以协作开发软件的世界。但是，我们坚信（至少目前）你才是驾驶员，而大语言模型只是你触手可及的另一个工具。