近日，开源代码编辑器Zed的开发团队发布了一篇引人深思的博文，标题直击要害：《为什么LLM无法真正构建软件》。这篇由Conrad Irwin撰写的文章不仅在技术圈引发热议，更是在Hacker News上掀起了一场关于AI辅助编程本质的深度讨论。
Irwin在文章中提出了一个关键观察：当你观察一个熟练的软件工程师工作时，会发现他们在不断循环四个步骤——构建需求的心智模型、编写代码、理解代码实际行为、识别差异并更新。而「区分优秀工程师的关键因素，是他们构建和维护清晰心智模型的能力」。
这个观点立即引起了社区的共鸣。用户usrbinbash形象地补充道：「我们不会只盯着调试器输出想着『怎么让这个错误消失』。当遇到认证错误时，软件工程师会退一步，思考整个系统，找出问题的根源。」他举例说，可能问题根本不在认证本身，而是测试用低权限用户调用了高权限函数——这种全局思考能力，正是LLM所欠缺的。
文章指出，LLM在编写代码时表现不错，在更新代码时也还可以，但它们「根本无法维持清晰的心智模型」。当测试失败时，LLM会陷入无休止的困惑——它们假设自己写的代码能工作，不知道该修复代码还是测试，最后干脆删掉重来。
用户9cb14c1ec0深有感触：「我使用Claude Code越多，就越对这个问题感到沮丧。我不确定一个基于文本的通用LLM能否真正解决这个问题。」他的经历代表了许多开发者的心声——AI工具在处理复杂项目时，往往会失去对整体架构的把握。
然而，并非所有人都认同这种悲观看法。andrewmutz反驳道：「作者不理解今天的LLM和编码工具的能力。」他分享了自己使用Cline配合Anthropic Sonnet 3.7进行TDD开发的经验，认为LLM的表现「不亚于甚至优于初级工程师」。
Irwin深入分析了LLM的三个根本性问题：「上下文遗漏」（难以发现被遗漏的上下文）、「近期偏见」（过度关注最近的信息）、以及「幻觉」（凭空捏造不存在的细节）。这些问题直接影响了它们维护心智模型的能力。
「即使不断增加上下文窗口，」文章写道，「我们人类处理问题的方式完全不同——我们能够临时存储完整上下文，专注解决问题，然后回到主线任务。我们不会简单地不断往上下文窗口里塞更多词汇。」
dlivingston提出了一个有趣的类比：「这让我想起Google的Genie 3只能运行约一分钟就会失去内部状态。我的直觉是，除非发明某种新架构——规模堪比Transformer的突破——允许短期上下文、长期上下文和自我调节模型权重，否则这个问题无法解决。」
社区对AI编程工具的看法呈现明显的两极分化。chollida1从投资者角度提供了独特视角：「多年的投资经验让我形成了一个心智模型——寻找那些虽然糟糕但仍在增长的技术。90年代的互联网很慢、经常断线，但人们还是在用；Twitter经常出现失败鲸，但人们依然用它看新闻。『永远寻找那些虽然糟糕但人们仍在使用的技术，因为它提供了价值。』」
另一边，怀疑者们则提出尖锐批评。bagacrap直言：「AI编程爱好者总是说『你只是用错了模型』。当没有模型能用时，他们又说『6个月后就会好了』。敏捷编程在复杂项目中的效用似乎永远无法被证伪。」
最有意思的是来自diwank的实践案例。他分享了一个完全由AI编写的项目steadytext：「7000行代码，包括Python库、CLI和Postgres扩展，完全由Claude Opus编写和维护。我从未看过90%的代码，但它有完整的测试覆盖，通过CI，我们在生产环境使用它！」这个案例引发了激烈讨论，有人质疑其真实性，有人则认为这代表了AI编程的未来可能。
JimDabell提供了一个更加平衡的视角：「LLM无法构建软件，是因为我们期望它们听几句话就立即开始编码直到完成原型。如果我们让人类工程团队这样做，也会得到糟糕的结果。」他建议通过可执行规范、严格测试、架构决策记录等工具，让AI在有界问题上完成同样的循环。
robomartin分享了他使用Cursor完成两个项目的详细经验：「基于这次经验，有一点非常清楚：『如果你不知道自己在做什么，你就完了。』」他发现，虽然AI能处理Django中大量的样板代码，但代码质量参差不齐，需要不断手动干预和修正。
skydhash从更哲学的角度评论：「程序员主要是将业务规则翻译成计算机世界中非常正式的流程执行。你需要知道规则的含义，也要知道计算机如何工作。翻译一开始总是混乱的，这就是为什么需要一遍遍修订。」
文章最后，Zed团队表达了他们的立场：「在Zed，我们相信人类和AI代理可以协作构建软件。但我们坚信，『至少现在，你还是驾驶员，LLM只是另一个可以使用的工具。』」
这个观点得到了许多开发者的认同。cmrdporcupine总结道：「它迫使你退一步做规划。你可以让它做苦力编码和低层分析测试，但你必须负责设计。这给了我更多时间思考大局，我喜欢这一点。」
正如ethan_smith所说：「真正的生产力提升不仅是打字速度，而是认知负载的转移——尽管我们必须小心，不要因为委托实现细节而失去维护准确心智模型的能力。」
这场关于LLM能否真正构建软件的讨论，不仅揭示了当前AI工具的局限性，更重要的是促使整个行业思考：在AI辅助编程的时代，什么是软件工程的本质？人类工程师的价值究竟在哪里？也许答案不在于AI能否取代人类，而在于如何让两者更好地协作，各自发挥所长。
评论删除后，数据将无法恢复
Zed 编辑器团队发声：LLM 为何无法真正构建软件？
近日，开源代码编辑器Zed的开发团队发布了一篇引人深思的博文，标题直击要害：《为什么LLM无法真正构建软件》。这篇由Conrad Irwin撰写的文章不仅在技术圈引发热议，更是在Hacker News上掀起了一场关于AI辅助编程本质的深度讨论。
软件工程的核心循环被AI误解了？
Irwin在文章中提出了一个关键观察：当你观察一个熟练的软件工程师工作时，会发现他们在不断循环四个步骤——构建需求的心智模型、编写代码、理解代码实际行为、识别差异并更新。而「区分优秀工程师的关键因素，是他们构建和维护清晰心智模型的能力」。
这个观点立即引起了社区的共鸣。用户usrbinbash形象地补充道：「我们不会只盯着调试器输出想着『怎么让这个错误消失』。当遇到认证错误时，软件工程师会退一步，思考整个系统，找出问题的根源。」他举例说，可能问题根本不在认证本身，而是测试用低权限用户调用了高权限函数——这种全局思考能力，正是LLM所欠缺的。
LLM的致命缺陷：无法维持心智模型
文章指出，LLM在编写代码时表现不错，在更新代码时也还可以，但它们「根本无法维持清晰的心智模型」。当测试失败时，LLM会陷入无休止的困惑——它们假设自己写的代码能工作，不知道该修复代码还是测试，最后干脆删掉重来。
用户9cb14c1ec0深有感触：「我使用Claude Code越多，就越对这个问题感到沮丧。我不确定一个基于文本的通用LLM能否真正解决这个问题。」他的经历代表了许多开发者的心声——AI工具在处理复杂项目时，往往会失去对整体架构的把握。
然而，并非所有人都认同这种悲观看法。andrewmutz反驳道：「作者不理解今天的LLM和编码工具的能力。」他分享了自己使用Cline配合Anthropic Sonnet 3.7进行TDD开发的经验，认为LLM的表现「不亚于甚至优于初级工程师」。
记忆与理解：技术瓶颈还是架构问题？
Irwin深入分析了LLM的三个根本性问题：「上下文遗漏」（难以发现被遗漏的上下文）、「近期偏见」（过度关注最近的信息）、以及「幻觉」（凭空捏造不存在的细节）。这些问题直接影响了它们维护心智模型的能力。
「即使不断增加上下文窗口，」文章写道，「我们人类处理问题的方式完全不同——我们能够临时存储完整上下文，专注解决问题，然后回到主线任务。我们不会简单地不断往上下文窗口里塞更多词汇。」
dlivingston提出了一个有趣的类比：「这让我想起Google的Genie 3只能运行约一分钟就会失去内部状态。我的直觉是，除非发明某种新架构——规模堪比Transformer的突破——允许短期上下文、长期上下文和自我调节模型权重，否则这个问题无法解决。」
实践者的两极分化
社区对AI编程工具的看法呈现明显的两极分化。chollida1从投资者角度提供了独特视角：「多年的投资经验让我形成了一个心智模型——寻找那些虽然糟糕但仍在增长的技术。90年代的互联网很慢、经常断线，但人们还是在用；Twitter经常出现失败鲸，但人们依然用它看新闻。『永远寻找那些虽然糟糕但人们仍在使用的技术，因为它提供了价值。』」
另一边，怀疑者们则提出尖锐批评。bagacrap直言：「AI编程爱好者总是说『你只是用错了模型』。当没有模型能用时，他们又说『6个月后就会好了』。敏捷编程在复杂项目中的效用似乎永远无法被证伪。」
最有意思的是来自diwank的实践案例。他分享了一个完全由AI编写的项目steadytext：「7000行代码，包括Python库、CLI和Postgres扩展，完全由Claude Opus编写和维护。我从未看过90%的代码，但它有完整的测试覆盖，通过CI，我们在生产环境使用它！」这个案例引发了激烈讨论，有人质疑其真实性，有人则认为这代表了AI编程的未来可能。
工具还是革命？业界的理性声音
JimDabell提供了一个更加平衡的视角：「LLM无法构建软件，是因为我们期望它们听几句话就立即开始编码直到完成原型。如果我们让人类工程团队这样做，也会得到糟糕的结果。」他建议通过可执行规范、严格测试、架构决策记录等工具，让AI在有界问题上完成同样的循环。
robomartin分享了他使用Cursor完成两个项目的详细经验：「基于这次经验，有一点非常清楚：『如果你不知道自己在做什么，你就完了。』」他发现，虽然AI能处理Django中大量的样板代码，但代码质量参差不齐，需要不断手动干预和修正。
skydhash从更哲学的角度评论：「程序员主要是将业务规则翻译成计算机世界中非常正式的流程执行。你需要知道规则的含义，也要知道计算机如何工作。翻译一开始总是混乱的，这就是为什么需要一遍遍修订。」
展望：不是终点，而是起点
文章最后，Zed团队表达了他们的立场：「在Zed，我们相信人类和AI代理可以协作构建软件。但我们坚信，『至少现在，你还是驾驶员，LLM只是另一个可以使用的工具。』」
这个观点得到了许多开发者的认同。cmrdporcupine总结道：「它迫使你退一步做规划。你可以让它做苦力编码和低层分析测试，但你必须负责设计。这给了我更多时间思考大局，我喜欢这一点。」
正如ethan_smith所说：「真正的生产力提升不仅是打字速度，而是认知负载的转移——尽管我们必须小心，不要因为委托实现细节而失去维护准确心智模型的能力。」
这场关于LLM能否真正构建软件的讨论，不仅揭示了当前AI工具的局限性，更重要的是促使整个行业思考：在AI辅助编程的时代，什么是软件工程的本质？人类工程师的价值究竟在哪里？也许答案不在于AI能否取代人类，而在于如何让两者更好地协作，各自发挥所长。