文章探讨了大型语言模型（LLMs）在软件开发中的局限性。虽然LLMs擅长编写和修改代码，但它们无法像人类工程师那样构建和维护清晰的心理模型，这是有效软件工程师的核心能力。软件开发涉及对需求的理解、代码的实现以及不断调整模型与代码之间的差异，而LLMs缺乏这种深层次的认知和迭代能力。

为什么大型语言模型（LLMs）无法真正构建软件？

在软件开发领域，大型语言模型（LLMs）虽然在某些方面表现出色，但它们仍然无法完全替代人类软件工程师。本文通过分析软件工程师的工作流程，探讨了LLMs在构建软件时的局限性。

软件工程的核心循环

优秀的软件工程师通常会遵循以下步骤： 1. 构建需求的心理模型。 2. 编写代码以实现这些需求。 3. 理解代码的实际行为。 4. 识别差异并更新代码或需求。

这一过程的关键在于工程师能够构建并维护清晰的心理模型，而这是LLMs目前无法做到的。

LLMs的局限性

LLMs在编写代码和修复已知问题方面表现不错，但它们无法像人类工程师那样维护清晰的心理模型。LLMs常常陷入混乱：它们假设自己编写的代码是正确的；当测试失败时，它们无法判断是代码还是测试出了问题；在遇到挫折时，它们可能会删除所有内容并重新开始。这与人类工程师的行为截然相反。

人类工程师在开发过程中会不断测试代码，当测试失败时，他们会根据心理模型决定是修复代码还是测试，或者收集更多信息再做决策。即使他们决定重新开始，也是在充分理解问题的基础上进行的。

未来会改变吗？

随着模型的进步，这种情况可能会有所改变，但这需要模型构建和优化方式的根本性变革。软件工程需要的不仅仅是生成代码的能力，还需要模型能够像人类一样处理复杂的情境。人类工程师能够在遇到问题时暂时搁置上下文，专注于解决问题，然后再回到原来的任务。他们还能够从宏观角度审视问题，暂时忽略细节，必要时再深入细节。

当前的生成模型在处理复杂情境时存在以下问题： - 上下文遗漏：模型难以发现遗漏的上下文。 - 近期偏差：模型在上下文窗口中存在强烈的近期偏差。 - 幻觉：模型常常生成不应存在的细节。

虽然这些问题并非不可克服，但目前的研究仍在探索如何为模型添加记忆功能，使其能够像人类一样进行心理操作。然而，目前LLMs仍然无法在复杂情境下真正理解问题。

LLMs的实用性

尽管LLMs无法完全替代人类工程师，但它们在生成代码、合成需求和文档方面非常有用。对于某些简单任务，LLMs可以一次性完成。然而，对于任何非平凡的任务，LLMs无法准确维护足够的上下文以迭代到可行的解决方案。软件工程师仍然需要确保需求清晰，代码功能正确。

在Zed，我们相信未来人类和智能体可以协作构建软件，但至少在目前，人类工程师仍然处于主导地位，LLM只是另一个工具。

评论内容总结：

1. LLM的局限性：

   • LLM在处理复杂问题时难以维持清晰的思维模型，尤其是在调试和解决宏观问题时表现不佳。
     • "what they cannot do is maintain clear mental models" (评论1)
     • "Software engineers are able to step back, think about the whole thing, and determine the root cause of a problem." (评论3)
   • LLM存在上下文遗漏、近期偏差和幻觉等问题，这些问题在人类工程师中也很常见。
     • "Context omission: Models are bad at finding omitted context." (评论7)
     • "Hallucination: They commonly hallucinate details that should not be there." (评论7)

2. LLM的优势：

   • LLM在微观任务和代码生成方面表现良好，尤其是在处理小规模任务和代码风格一致性时。
     • "It's good at micro, but not macro." (评论2)
     • "I’ve had relatively good success with more targeted tasks, like 'Add a modal that does this, take this existing modal as an example for code style'." (评论5)
   • LLM可以快速处理编译错误和代码重构，减少开发者的重复劳动。
     • "LLMs fix it for you. Now you can just tell Claude to change all the code in a loop until it compiles." (评论12)

3. LLM的未来发展：

   • 尽管LLM目前存在诸多问题，但随着技术的进步，未来可能会解决这些局限性。
     • "LLM's amy not be able to build software today, but they are 10x better than where they were in 2022." (评论14)
     • "It's pretty reasonable to assume in 5 years they will be able to do these types of development tasks." (评论14)
   • LLM需要与开发工具（如IDE）更深度地集成，以提升开发效率。
     • "I want AI workflows as part of my IDE, like Visual Studio, InteliJ, Android Studio are finally going after." (评论17)

4. LLM的使用策略：

   • LLM应被视为工具箱中的一种工具，而非独立的解决方案，开发者需要制定有效的使用策略。
     • "I think they’re another tool in the toolbox not a new workshop." (评论8)
     • "Improvements in model performance seem to be approaching the peak rather than demonstrating exponential gains." (评论15)
   • 通过分阶段任务和明确提示，可以提升LLM的输出质量。
     • "I also break my problem down into smaller chunks, and give them one by one to the LLM." (评论5)
     • "This helps the LLM understand the TDD mental model rather than just seeing 'broken code' that needs fixing." (评论20)

5. LLM的讨论与评价：

   • 讨论LLM时应明确所使用的具体模型，不同模型的表现差异较大。
     • "These LLM discussions really need everyone to mention what LLM they’re actually using." (评论9)
     • "Am I the only one continuously astounded at how well Opus 4 actually does build mental models when prompted correctly?" (评论16)
   • LLM的成功不仅依赖于模型本身，还依赖于围绕模型构建的系统。
     • "The success of agentic coding solutions depends on not just the model but also the system that the developers built around the model." (评论23)

总结：LLM在软件开发中表现出一定的潜力，尤其是在处理微观任务和代码生成方面，但在处理复杂问题和维持思维模型方面仍有较大局限性。未来，随着技术进步和与开发工具的深度集成，LLM可能会在软件开发中发挥更大的作用。