本帖最后由 cattenlinger 于 2025-8-20 13:29 编辑
为什么 LLM 不能真地去干软件工程
（by Conrad Irwin，at 八月十四，2025 年，Catten Linger 译）
在与软件工程师面谈，是我花时间最多的一件事。这绝对是个难事，我不觉得这会有什么效率神器。但这也给了我时间去反思，到底有效率的软件工程师实际上在做的是什么。
软件工程循环
当你看到一个知道自己在做什么的人，你会见到他们在以下步骤中循环：
- 在心中构建一个对需求的思维模型
- 写点代码，实现它（期望能？）
- 构建一个“代码实际干了什么事情”的思维模型
- 对比且定位之间的不同，并更新代码（或者需求）
做事的方式有很多种，但有效率的工程师所具备的区别性因素在于构建和维护清晰的思维模型。
那 LLM 呢？
不可否认，LLM 在写代码这方面是真的挺不错的。它们也十分地擅长在你将需要修复的问题指出后，更新对应的代码。它们甚至能做所有软件工程师可以做的事情：读代码、写与运行测试、加日志输出，甚至（可能会）用调试器。但它们不能做到的地方是：维护清晰的思维模型。
LLM 们会陷入无限的困惑中：它们从来假设代码是可用的；当测试失败时，它们只会留下修代码还是修测试的猜测；且当它们沮丧了，它们就选择直接全盘推翻，从头开始。这完全和我的需求背道而驰。
软件工程师会不断测验自己的工作。当测试失败了，他们能通过自己的思维模型来决定是修代码还是修测试，还是等拿到更多的数据再作决定。当他们感到沮丧了，他们会通过将想法讲出来以寻求帮助。
但这也快了，是吧？
这种情况会随着模型能干的事情越多而变化吗？可能会？？但我觉得这将需要改变模型们的构建和优化方法。软件工程师需要的不仅是能生成代码的模型。
当一个人搞砸了掉进了问题，他们懂得先临时将整个上下文先搁置“入栈”，专注解决问题，然后将整个思考“出栈”并回到当初的问题。他们也可以从细节离开并关注整个蓝图，允许一些细节临时消失。我们不会在自己的“上下文窗口”增加更多的内容，因为这会把我们搞疯。
即便那里没有太多的上下文情景去处理，我们知道当前的生成式模型受到一些问题的直接影响，导致它们不能维持清晰的思维模型：
希望这些都是些可以通过添加“记忆”来解决，实现和我们类似的思维技巧，而不是什么不可逾越的问题。但很可惜，现在为止，他们还不能在一定的复杂度过后，明白当下到底在发生什么事。
因为它们不能保持两种类似的“思维模型”，定位区别，并决定出要不要更新代码或需求，所以还不能担当软件的构建工作。
所以呢？
很明显，LLM 们对于软件工程师来说还是很有用的。它们能快速生成代码，且它们在总结需求和文档方面十分迅速。对于一些需求很简单、能直接命中整个目标的工作来说足够了。
也就说，对于不是很常见的工作，他们无法保持足够清晰的上下文来迭代出一个有效的解决方案。你，一个软件工程师，有责任去保证需求是清晰的且代码也符合意图。
在 Zed，我们相信一个人和 LLM Agent 互相合作构建软件的世界。但，我们（至少现在为止）坚信，你是那个司机，而 LLM 仅仅是另外一个载你到目的地的工具。
原文：Why LLMs Can't Really Build Software | 
|Archiver|小黑屋|技术宅的结界
( 滇ICP备16008837号 )|网站地图
发表于 2025-8-17 22:06:31
发表于 2025-8-19 10:52:36