如果你面试过足够多的软件工程师，就会发现一个有趣的现象：真正优秀的开发者，并不是代码写得最快的人，而是那些大脑里始终能“端着”一张清晰设计图的人。这听起来有点抽象，但往下看你就明白了。
软件工程循环
当一位经验丰富的开发者投入工作时，他其实在执行一个循环，步骤大致如下：
- 先在脑海里构建需求的心理模型——搞清楚到底要解决什么问题。
- 然后写代码（但愿他真的写了？）去实现这个模型。
- 接着再构建一个关于代码实际执行过程的思维模型——想象机器会怎么跑这段代码。
- 把两个模型放在一起对比，找出差异，要么改代码，要么调整需求。
这听起来简单，但差别就在第二步和第三步之间的“心智映射”能力上。优秀工程师之所以优秀，就是因为他们能同时维持这两套清晰的思维模型，并在差异出现时迅速做出判断。
LLMs 怎么样？
平心而论，LLMs 写代码确实厉害。你指出问题，它们也能修改。它们甚至能做真工程师的大部分工作：读代码、写测试、跑测试、加日志、理论上还能用调试器。
但它们有一件事做不到——保持清晰的心智模型。
你会发现，LLMs 经常陷入某种“自我欺骗”：它们假设自己写的代码肯定能跑；测试失败的时候，它们只能瞎猜是改代码还是改测试；遇到卡壳，干脆删掉一切从头来过。这跟人类工程师的工作方式完全是两码事。
真正的软件工程师是边写边测的。测试挂了，他们心里有张地图，知道是该修代码、改测试、还是先收集更多信息再做决定。遇到瓶颈，他们会停下来讨论。就算偶尔推倒重来，那也是在脑子里已经更清楚问题所在之后。
但很快就能实现了吧？
随着模型能力提升，这些缺陷会不会被填平？也许吧。但我觉得，这需要从根本上改变模型的构建和优化方式——软件工程需要的远不止是“生成代码”这一项技能。
人类在面对复杂问题时，有一个很厉害的能力：能把完整上下文暂时存起来，专心解决一个问题，然后再恢复思维栈，回到手头任务。还能跳出细节看全局，让次要信息暂时模糊，只在需要时才深入局部。我们不会傻到把认知窗口无限拉长——那只会让人崩溃。
就算不考虑信息过载，现有的生成模型也有好几个直接阻碍它们维持清晰思维模型的硬伤：
- 上下文缺失：模型不擅长发现被省略掉的上下文——它不知道自己不知道什么。
- 近因偏差：在上下文窗口里，它特别偏爱最后看到的东西，前面说的很容易被冲淡。
- 幻觉生成：它经常自己编造一些本不存在的细节，然后信以为真。
这些问题并非无解——业界已经在给模型加“记忆”功能，试图让它们像人一样进行思维运作。但遗憾的是，现阶段它们还无法（一旦超过一定复杂度）真正理解正在发生什么。
一句话总结：LLMs 没法真正构建软件，因为它们无法同时维持两个相似的“心智模型”，无法识别差异，更无法判断是该改代码还是改需求。
那么，现在该怎么办？
这不意味着 LLMs 对软件工程师没用。恰恰相反，它们能快速生成代码，特别擅长把需求文档转化成实现。对于某些任务来说这就够了——需求足够明确，问题足够简单，它们可以一次性搞定全部。
但话说回来，任何非琐碎的任务，它们都无法准确维持足够的上下文来迭代出一个可行的方案。所以，作为软件工程师，你的角色依然是：确保需求清晰，确保代码确实实现了它声称的功能。
在 Zed，我们相信一个人和智能体协作构建软件的未来一定会来。但我们坚信——至少在今天——你才是那个掌舵的人，LLM 只是工具箱里的一件工具。