五千字需求文档扔给 AI，最好的也只完成了 14%：这个基准撕开了”AI 写代码”的另一面
AI飞行客 五千字需求文档扔给 AI，最好的也只完成了 14%：这个基准撕开了”AI 写代码”的另一面
如果你只看过去一年的新闻，你可能会得出一个结论：AI 写代码已经无所不能了。SWE-bench 上刷到 70% 多，闭源模型一个接一个发版，开源这边也紧追不舍。
然后复旦、港城大、港中文的团队做了一个叫 LoLBench 的基准。
他们把 AI Agent 放进了真实的大型软件系统——平均约 240 万行源代码——给了它一份平均约 5000 个英文单词的功能提案，然后看它能不能真的把新需求实现。
最好的模型，完成了 14%。
SWE-bench 上 70% 的选手，在被放进真实软件工程的上下文时，交出了这个数。
这不是模型变笨了。是之前的评测，没有回答那个真正的问题。
SWE-bench 测的是什么——以及它没测什么
SWE-bench 是目前最主流的代码 Agent 评测。它给 Agent 一个代码仓库和一个具体的 Bug 报告，让 Agent 找到问题、修改代码、通过测试。
它测的是修 Bug——在已知问题的情况下，找到根因，写一个补丁。
不需要理解”这个 Bug 是哪个需求变更引入的”，不需要判断”修这个会不会影响其他模块”，不需要知道”这个模块的设计意图是什么”。
SWE-bench 的满分，是一个能在已知框架内完成局部修复的模型。
LoLBench 测的是另一回事：从零交付一个新功能。
产品经理甩过来一份五千字的提案，你要自己读懂、自己分析影响范围、自己确定改哪些文件、自己写代码、自己验证。在这个过程中，没有人为你指出”问题出在第 42 行”。
这是真实世界里的软件开发。
实验设计：5000 个单词，240 万行代码
LoLBench 从真实社区的功能提案（Enhancement Proposal）和对应的已合并 PR 里，选了 100 项任务，覆盖 29 个系统、8 种语言和 5 个领域。
Agent 拿到的是：提案原文 + 实现前的全部代码。提案平均约 5000 个英文单词。Agent 必须自己在代码库里找到该改什么、怎么改。
评测在断网的 Docker 环境里进行——Agent 不能上网搜文档，不能检索上游实现。只能靠自己读代码。
实验暴露了关键的断点：Agent 可能改对局部，却漏掉其他模块里必须同步的改动。
你改了 A 模块的接口，但没改 B 模块里调用这个接口的地方。测试通过了（因为局部改了就好了），代码合进去了（因为审查也没发现），然后上线报错了。
在真实的软件工程里，这就是一个标准的线上故障。在 SWE-bench 里，它不会被测出来，因为评测任务没有”跨模块依赖”这一项。
14%，这是因为模型不够聪明吗？
不是。
LoLBench 的分析指出，问题出在两个层面：
感知复杂性：读懂提案、识别隐含约束和跨模块依赖、推导修改范围与实现规范的难度。5000 个词的提案不是一个”在代码里找到 TODO”这么简单的事。它需要你对整个系统的架构有理解，对提案里没写出来的约束有推断。
实现复杂性：把分析结果转成正确的跨文件修改，并通过测试和修复避免破坏已有功能的难度。你是改了正确的文件，但文件里还有 2000 行你没碰的代码，你的改动跟它正不正确，你验证了吗？
SOTA 模型在感知端的问题更加突出：读懂了任务，但没找到所有需要改的文件；找到了文件，但没理解模块之间的依赖关系。
如果能给模型”实现指引”——告诉它该改哪些文件——多数任务仍未解决。也就是说，问题不出在”写不出正确的代码”，出在”不知道在哪写”。
我的判断
第一，SWE-bench 就像考卷上的选择题，LoLBench 像是写论文。
选择题你能考 90 分，写论文你可能只有 14 分——这不能说明你在作弊，只能说明你还没有掌握一个更复杂的知识。
但行业现在的问题是：大家都在拿选择题的成绩来宣传自己已经毕业了。
SWE-bench 的分数被放在模型发布的头条，被用作定价依据，被拿来比较”谁才是编程最好的模型”。但 SWE-bench 的高分和”这个模型能不能把五千字需求变成一个新功能”之间，隔着一条巨大的鸿沟。
第二，LoLBench 的 14% 不是某个模型的失败，是这个行业对”代码 Agent”的定义太窄了。
一个 Agent 能写出一段正确的代码，不等于它能交付一个完整的功能。
交付功能需要：
– 理解一段模糊的、有隐含约束的自然语言需求 – 在几十万、几百万行的代码库里找到需要改的文件 – 判断这个改动会不会影响其他模块 – 修改所有受影响的文件 – 验证修改没有被破坏
这五件事里，至少前三件目前还没有任何 Agent 做得好。
而这三件事，恰好是软件工程师最值钱的那部分劳动——不是写代码，是想清楚在哪里写代码、写什么代码。
第三，这个 14% 会给行业带来好的变化，但不是立刻。
有实际经验的人看到 14% 会觉得”果然如此”——软件开发原本就不只是写代码，从理解需求到落地交付的理解与分析，从来都是最有价值的环节。
但压力向上传导，会在几个层面上展开：
– 评测领域：更多关注软件工程而非代码生成的 benchmark 会涌现 – 产品定位：”端到端功能交付”会成为下一个 Agent 的竞争指标，而不是”代码能力” – 实际使用：低门槛场景的自动化会继续推进，因为那是它的主场；需要深度的上游决策也会继续留给程序员来做指示
对于每天在用 AI 写代码的人来说，这条基准给出了一个诚实的方向感：Agent 写一个函数没问题，但让它独立完成一个新功能，你得准备好做它的项目经理。
这也反过来让我想起前几天 DeepSeek 的那个 Super-agent——它做的正是”Router 负责接收消息、判断归属、协调 Worker”。如果 LoLBench 的短板是”没找到改哪”，那 Super-agent 的方向”先判断再执行”刚好对着这个问题开刀。
精度和阅读理解力的提升，通常需要的是比”代码生成”更深一层的架构设计，而不是”再换一个更强的模型”。
—
*基准：LoLBench — 复旦大学 / 香港城市大学 / 香港中文大学* *规模：100 个任务 / 29 个系统 / 8 种语言 / 5 个领域* *提案长度：平均 ~5000 英文单词 / 仓库规模：平均 ~240 万行源代码* *最好成绩：约 14% 的完整交付率* *关键发现：Agent 能修局部但漏跨模块依赖，感知复杂性是更大瓶颈* *论文：arXiv（待附链接） / 数据集：GitHub（待附链接）* *来源：新智元 / 36氪*