来自Zed：为什么大语言模型还不能真正写软件

在过去的几年里，我花了不少时间面试软件工程师。面试本身就是一门手艺，不存在什么万能解法，但这让我逐渐形成一个直观：一个真正厉害的软件工程师，和只是“会写代码”的人，差别究竟在哪里。

答案很简单：在于他们如何建立和维护“心智模型”。

软件工程的循环

如果你观察一位经验丰富的工程师，你会发现他们在不断进行一个循环：

1. 1. 先在脑子里构建一份关于需求的心智模型
2. 2. 写出一段（希望正确的）代码
3. 3. 再建立一份关于“代码实际行为”的心智模型
4. 4. 对比两者的差异，然后选择更新代码或更新需求

这就是典型的软件工程循环。
真正高效的工程师，并不是因为写代码速度快，而是因为他们能在大脑里维持清晰的模型，知道自己在做什么。

那么，LLM 呢？

公平地说，LLM 在写代码方面确实很强。你告诉它一个问题，它往往能写出一份看起来八九不离十的解决方案。如果你指出 bug，它也能尝试修复。甚至你让它加日志、写测试、读代码，它都能做。

问题在于：它们没有稳定的心智模型。

• • 它们会默认自己写的代码一定是对的。
• • 当测试挂了，它们不知道该怀疑代码还是测试。
• • 如果卡壳了，它们干脆推倒重来。

而真正的工程师在面对同样的情况时，会做出完全不同的选择：
他们会用心智模型去判断失败的原因，是需求错了，代码错了，还是测试错了。
他们会知道什么时候该继续收集信息，什么时候该寻求帮助。
即便是推倒重来，也是基于对问题更清晰的理解。

模型变强了，这会改善吗？

也许会。
但我认为，这不是单纯把模型做“大”就能解决的。

软件工程需要的不仅仅是会写代码的工具，而是能够像人一样处理复杂上下文：

• • 可以暂时把整个问题压栈，专注于眼前的小问题，再把上下文恢复回来；
• • 可以随时缩放视角，放眼全局，也能深入细节；
• • 可以长期维护两份近似的模型（需求 vs. 实际代码），并不断对比、修正。

而目前的 LLM 有几个根本性缺陷：

• • 上下文遗漏：它们很难捕捉被省略的关键信息。
• • 近因偏差：上下文越靠后的内容越容易被放大，越靠前的容易被遗忘。
• • 幻觉：它们经常“编造”不该存在的细节。

研究界也在尝试给模型加“记忆”，让它们能做类似人类的心智操作。但至少现在，它们还无法真正理解正在发生的事。

那么，现在我们该怎么用 LLM？

这并不意味着 LLM 没用。恰恰相反，它们已经是软件工程师的好帮手：

• • 需要快速生成一段代码？它们很快。
• • 需要整理需求或写文档？它们很强。

只要需求足够清晰、问题足够简单，它们甚至能一次性搞定。

但对于那些复杂、迭代性强的问题，责任仍然在工程师自己身上：确保需求清晰，确保代码符合预期。