SWE-Bench的创建者们，最近又扔出了一枚重磅冲击波——一个堪称地狱级难度的新基准测试。

测试结果，可以说相当震撼。

Claude Opus 4.7、GPT-5.4、GPT-5 mini、Gemini 3.1 Pro、Gemini 3 Flash……这一代几乎所有顶尖的大模型，交出的答卷清一色是：0%完成率。

没有一个模型，能够真正从头到尾、完整地重建一个真实的软件项目。

这背后传递的信号是什么？

一句话概括：今天的大模型，已经很会“写代码”了，但距离“做软件工程”，还有一道巨大的鸿沟。

从“补代码”到“造系统”：评估范式的根本转变

最近，Meta FAIR联合斯坦福、哈佛等机构发布了一项引人深思的新基准测试，它本质上是在重新定义我们对AI编程能力的评估方式：

ProgramBench: Can Language Models Rebuild Programs From Scratch?

过去的编程基准测试，比如SWE-Bench，测的大多是“局部能力”：补全一个函数、修复一个已知的bug、实现一个特定功能……本质上，模型还是在已有的代码框架和结构里进行“局部手术”。

而ProgramBench第一次把问题推向了真正的软件工程层面：如果只给AI一个程序的功能描述和使用文档，它能不能像一位真正的工程师那样，从零开始，重新构建出一个完整、可执行的软件系统？比如ffmpeg、SQLite、ripgrep这样的知名项目。

而且，有一个关键限制：不能联网搜索。

这其实是在追问一个更根本的问题：模型到底有没有“工程智能”？

为了测试这一点，研究团队的做法相当彻底：直接删除了原始项目的所有源代码和测试文件，只保留最终的可执行文件和用户使用文档。模型需要自己决定使用什么编程语言、设计什么样的架构、如何拆分模块、采用何种数据结构，乃至整个代码仓库的组织方式。

更关键的是评分标准。ProgramBench不再简单地比对生成代码与原始源码的相似度来打分。它采用的是“行为等价”原则。也就是说，你可以用完全不同的语言、算法、架构，甚至截然不同的工程实现方式。只要最终程序在给定输入下的输出行为与原程序完全一致，就算通过。

研究团队甚至动用了“智能体驱动的模糊测试”，自动生成海量的端到端行为测试用例来进行验证。

这是第一次，有一个基准测试开始真正逼近现实世界中的软件工程挑战，而不再只是“代码做题”。结果一出，整个AI社区都陷入了沉思。

所有参与测试的模型，无一例外，全部折戟沉沙。

如果说上面的表格（Table 2）负责制造震撼，那么下面的图表（Figure 4）则负责解释这震撼背后的细节。它告诉我们，模型并非完全束手无策，它们经常能完成一部分，甚至在少数相对简单的任务上接近成功。然而，一旦要求100%的行为等价，所有模型都会在最后关头倒下。而这“最后一公里”，恰恰是软件工程与普通代码生成之间最大的区别。如果非要在矮子里拔将军，Claude系列（尤其是Opus 4.7和4.6）的表现相对而言是最好的。

即便论文专门增加了一个“接近完成”的指标——统计那些完成度超过95%的任务，结果依然不容乐观。目前表现最强的Claude Opus 4.7，也只有区区3%的任务能接近完成。

论文中有一句话特别关键，点明了问题的核心：

“模型极度倾向于生成单体化、单文件的实现，这与人类编写的代码结构截然不同。”

翻译过来就是：模型产出的代码，往往是一大坨逻辑全部塞进一个文件里；目录结构极其扁平；几乎不做模块拆分；函数长得惊人；整个代码库看起来更像一个巨型的脚本文件。

这种风格，与优秀人类工程师的实践习惯几乎是背道而驰的。后者讲究的是模块化、关注点分离，会把代码优雅地拆分开——配置文件放这里，工具函数放那里，数据库操作单独一个模块，然后通过清晰的接口相互调用。

这暴露出了一个非常核心的问题：AI擅长的是基于上下文的“局部代码生成”，但它严重缺乏“全局系统规划”的能力。而真实的、大规模的软件工程，本质上恰恰是后者。

这也解释了为什么模型在LeetCode、SWE-Bench或者作为Copilot辅助编程时表现亮眼，一旦进入需要从头构建和维护一个大型工程系统的深水区，就会迅速失灵。

可以说，当前AI编程面临的真正瓶颈，已经不再是生成几行或一段代码的能力，而是长期的、系统性的软件构建与维护能力。

语言差异与任务难度：模型能力的稳定边界

另一个很有意思的发现，是模型在不同编程语言项目上的表现差异。

研究团队分别统计了模型在C/C++、Go、Rust等不同语言项目上的表现。可以明显看到，在传统的C/C++项目上，模型的完成度相对最高，而在Rust项目上表现最差。

此外，不同模型在面对不同难度任务时的排序高度一致：像nnn、fzf、gron这类相对简单的命令行工具，模型普遍能拿到更高的通过率；但面对FFmpeg、php-src、typst、ast-grep这类复杂的系统，几乎所有模型都举步维艰。这说明ProgramBench测量到的并非某个模型的偶然失误，而是复杂的软件系统本身就对当前一代模型构成了稳定的、系统性的压制。

这个结果其实并不令人意外。

互联网上关于C/C++的历史代码、工程实践和问答（比如Stack Overflow）实在太多了，模型已经被这些模式和范例“浸泡”了很多年。

而Rust语言的工程哲学本身就更强调模块化、所有权系统、特质系统以及长期的可维护性，这些概念恰恰是当前基于统计模式的大模型最不擅长理解和复现的东西。

从某种意义上说，Rust项目测出来的，其实不是单纯的“代码能力”，而是更深层次的“工程能力”。

争议与价值：超越记忆的工程智能

随着ProgramBench引发热议，围绕这项基准测试的争论也开始迅速扩散。其中最主要的质疑之一是：这不就是在考模型有没有“背过”FFmpeg的源码吗？毕竟，ProgramBench里选用的很多项目本身就是公开的开源软件。

对此，知名硅谷投资人Deedy Das专门发文进行了回应。他的核心观点是：任何基准测试都可能面临“过拟合”或“被背诵”的风险。

SWE-Bench的bug可能被记住，LeetCode的题目可以被背熟，甚至未来的ARC-AGI也可能需要通过隐藏题库来避免泄漏。单纯讨论“是否存在记忆”本身，并不能否定一个基准测试的价值。

他认为，如果模型真的试图用“蛮力背诵”的方式来应对这些任务，其能力往往会在其他方面出现明显的退化。因为真正的大模型训练，并不是简单地把整个FFmpeg的源码库塞进参数里。更何况，研究人员完全可以通过比对生成代码与原始源码的相似度，来检测是否存在直接的“记忆复制”。

他真正想强调的是，从底层重建一个真实世界的软件系统，本身就是一种高价值、长跨度、极其复杂的任务。如果模型真的能够通过推理来完成这类任务，那么这种能力很可能泛化到大量其他的工程场景中。

另一类争议则更有意思。有人吐槽说：连人类工程师都不可能从零开始重写一个FFmpeg，这个基准测试根本不合理。

Deedy Das的回应是：那又怎样？今天很多大模型能做到的事情，人类的平均水平同样做不到。

基准测试的目标，从来不是模拟普通人的平均能力，而是为了推动模型向更高层次的智能逼近。人类做不到，并不意味着这个测试没有价值。

比如，AlphaGo下棋超过了绝大多数人类，但这并不影响它推动了整个AI领域的发展；同样，一个远高于普通工程师能力边界的基准测试，也可能是未来自主智能体系统必须攻克的关卡。

当然，他也承认ProgramBench目前仍然存在不少缺陷。例如，它没有测试像Claude Code、Codex这类更完整的智能体工作流；它只统计“是否完成”，缺乏更细粒度的进展衡量指标。同时，它限制了联网能力，虽然这是为了避免明显的作弊行为，但也可能让模型失去了一种重要的辅助手段。

Deedy Das同意，这可能导致模型为了在特定指标上取得高分而走向歧途（即“在错误的事情上爬山”）。不过，人们也随时可以增加一项允许网络访问的对比测试，来观察模型在有外部知识辅助下的表现。

还有人建议：为什么不用一个完全没人解决过的新问题来测试？对此，Deedy Das表示，那样会让基准测试几乎无法构建。

你很难为一个没有标准答案的问题设计出完备的测试套件；也很难判断这个任务是否真的属于现实世界的工程挑战，还是研究者凭空捏造出来的“难题”。

但这些问题，其实都可以随着基准测试本身的迭代而逐步修正。

真正重要的是，ProgramBench第一次把AI编程的评估尺度，从“函数级”拉到了“系统级”。它暴露出的，也是整个行业当前面临的最大断层：真正的软件开发，从来都不是写一个孤立的函数，而是如何构建一个能够被长期维护、灵活扩展、便于团队协作的工程系统。

今天的大模型，已经非常擅长生成局部的、片段式的代码。但它们依然严重缺乏长期、一致、稳定地维护复杂系统的能力。

所以你会发现，最近整个行业的研究焦点，都开始疯狂地转向另一批关键词：记忆（memory）、智能体（agents）、仓库级推理（repo-level reasoning）、长程规划（long-horizon planning）、自主软件工程（autonomous software engineering）。

因为下一阶段的竞争，可能已经不再是谁能一次性生成更长的代码片段，而是谁能在长时间、多轮交互、复杂上下文中，持续且稳定地维护一个“活着”的、不断演进的软件系统。

论文链接：https://programbench.com/static/paper.pdf