我对使用大语言模型来解决软件工程问题的思考

总的来说，我对使用大模型解决软件工程问题持乐观态度。随着Agent Engineering的发展，大模型在需求分析、设计、实现、测试和运维环节均体现了其价值。但要把它用好，我们仍然需要掌握顶层架构，并使用适当的工具和方法随时监督AI的工作。

LLM对软件工程的增益有目共睹。这一点不只是主观上的。已有对照实验发现，LLM 辅助工具能够提升特定开发任务的完成效率（《The Impact of AI on Developer Productivity》 (Peng et al., 2023)）。

但面对复杂的软件工程任务，单个LLM的上下文窗口仍会限制它对项目全局的持续把握。而更糟糕的是，即使上下文窗口未满，模型也未必能充分利用其中的信息，尤其是在上下文足够长时容易遗漏长上下文中段的相关内容。（Nelson F. Liu等人的论文《Lost in the Middle》说明了这点）。此外还有很多因素，比如工具数量增长对 Function Calling 选择准确率的影响，干扰信息对模型决策的影响等。 SubAgent或许很诱人，但它也有自己的问题。智能体可能越过职责边界、遗漏重要信息，或者在缺乏验证的情况下让错误继续传播，最终导致任务失败（《Why Do Multi-Agent LLM Systems Fail?》，2025）。

所以，我们必须引入独立的，基于事实的外部机制来约束AI。从而确保整个体系的正确，并确保结果可验证。一个例子是FM-Agent：利用独立的LLM结合调用者的预期生成函数规范，再通过霍尔逻辑式的推理逐步推导后置条件，检查实现是否符合规范，最后生成并执行测试用例来确认潜在缺陷。（《FM-Agent》 Ding et al., arXiv 2026）

当然，上下文工程也是不可少的。限于篇幅，我还是提一个最直观的建议：考虑到“Lost In the Middle”效应，最能影响LLM决策的关键信息在上下文首尾。因此，不要图方便将大段代码直接贴入prompt，它是真的会让模型“变傻”呀。各种agent默认的基于function calling的文件操作是更好的选择。

综上，这也是为什么我们软院人需要学习软件工程。软件工程给我们的，是系统化思维，是设计顶层结构的能力，以及实现这些顶层设计的理论知识。