研究综述：LLM 在软件开发中的真实能力与局限

一篇整合近期多份研究（含同行评审论文与未同行评审的行业报告）的综述认为：大语言模型（LLM）在软件开发中的真实表现，远不如厂商宣传与基准排名所暗示的那样乐观；在自主长程编码、有效上下文、注意稀释、心理影响与可靠性提升成本等方面，模型均存在系统性局限。

自主长程编码与上下文天花板

综述明确指出，真正自主、可靠、能完成长程任务的智能体式软件开发，使用 LLM 实现的可能性极低，本质上属于科幻。原因之一是有效上下文长度：包括前沿超大规模 LLM 在内，其「可使用」的上下文窗口比厂商宣传的极限要小好几个数量级。当前厂商常用的「压缩」机制——由模型对上下文片段进行摘要——本身就是一种以不稳定、信息有损而著称的过程，超大上下文反而会放大错误。

信息优先级与「注意稀释」

LLM 无法区分上下文中的新旧信息；训练时学到的「主导先验」经常盖过用户给出的输入。对模型而言，新与旧、对与错都是 token、权重与概率的博弈，概率最高者胜出。上下文越长、信息越多，「注意稀释」越严重——上下文内各项概率被稀释到难以与模型内置概率抗衡，模型的判断就更倾向于回到训练时的默认行为。

团队实践的几个反直觉发现

• 仓库级别的 .md 文档往往让模型表现变差，因为其在多数具体任务中带来的是噪声而非信号；模型自动生成的 .md 尤其如此。把团队的编码规范与架构总览塞进每一次任务，反而可能适得其反。
• LLM 不擅长处理否定。明确告诉模型「不要做某事」，效果常常与「做某事」相当——这也是部分安全护栏和抛硬币差不多的根因。
• 与其描述想要什么，不如直接给示例。它们本质上是模式匹配器，「像这样」比「做这个」有效，「别这样做」基本无效。

产出上升，结果未必变好

多项大规模行业研究呈现出一致趋势：使用 LLM 后，代码量、提交次数与 diff 规模都在上升，但最终交付质量并未同步改善，甚至出现团队平均「交付更慢、软件更差」的迹象。少数团队获得温和收益，而这些团队本就具备较强的工程能力——AI 编码更像放大器，会放大团队已有的长处与短板。

认知影响与可靠性提升的代价

综述引用多项研究指出，LLM 使用与学习、认知及批判性思维下降存在相关性；开发者长期大量使用后的倦怠与动机下降，可能并非空穴来风。另一项研究还发现，与「相信 AI 输出」显著正相关的，是一个人对超自然现象的相信程度。

更深层的限制来自架构本身：深度神经网络难以学习具有长程依赖的模式，无论模型规模如何。这意味着模型始终在「雾中驾驶」，短程局部概率会压过长程全局概率，这正是其在「大图景」上力不从心的概率根源。

要把错误率从目前的约 30% 降到 3%，所需训练算力与能耗大约是当前前沿模型的 10^20 倍。因此短期内不应期待显著更可靠的模型——未来可靠性的提升主要来自「上下文工程」（决定输入什么）与更有效的输出质量把关。

对基准排名的提醒

综述也对「基准越刷越高」的叙事发出警告：一方面，许多流行基准衡量的是算法上容易量化的能力，与真实世界问题的混乱和不可预测性相去甚远；另一方面，「已发表的基准」意味着模型很可能已经针对这些测试做过训练——「如果它在外面，就很可能已经在里面」。