ProgramBench：没有一个 LLM 能从零重建完整项目 — 最新基准测试解读

2026 年 5 月 5 日，来自普林斯顿、Meta 和宾夕法尼亚大学的研究团队发布了 ProgramBench——一个专门测试 LLM 从零构建完整软件 能力的基准测试。结果相当扎心：9 个模型无一能在 200 个任务中完全通过任何一个。

即使是最强的模型，也只有 3% 的任务通过了全部测试用例。模型还表现出一个显著趋势：倾向于写 单体单文件实现，与人类工程师习惯的模块化、多文件结构截然不同。

在 AI 编码 Agent 轰轰烈烈取代人类写代码的今天，这个基准测试像一盆冷水。这不是说 AI 不能写代码，而是说 AI 距离真正独立构建软件还有多远。

ProgramBench 测的是什么

现有的代码生成基准测试（如 SWE-bench、HumanEval）大多聚焦于局部任务：修一个 bug、补一个函数、实现一个特定功能。这就像测试一个实习生能不能写一个排序算法——能写好，但交给一个完整项目可能就懵了。

ProgramBench 做的是完全相反的事：给定一个可执行程序和它的文档，Agent 必须从零设计并实现一个代码库，使最终的输出行为与参考程序一致。没有预设的 API 签名、没有单元测试脚手架、没有项目结构限制——一切都由 Agent 自己决定。

评估方式也很有意思：通过Agent 驱动的模糊测试自动生成端到端的行为测试。你不告诉模型怎么通过测试，而是让测试从参考程序的真实行为中派生出来。这种方式避免了"教学式测试"的问题——模型只能通过理解需求来过关。

200 个任务：从 CLI 工具到 SQLite

ProgramBench 包含 200 个编程任务，涵盖的软件规模跨度极大：

• 小型工具：如 JSON 格式化器、文件监控器、Markdown 解析器等 CLI 工具
• 中型应用：如 HTTP 服务器、模板引擎、编译器前端
• 大型系统：如 FFmpeg 子集、SQLite 核心引擎、PHP 解释器

有趣的是研究团队没有人为挑选"对模型友好"的任务。FFmpeg 和 SQLite 这种工业级软件也在测试集中，直接测量模型能否在没有人力辅助的情况下从零复刻它们的关键功能。

结果，FFmpeg 和 SQLite 相关的任务无一成功。

关键发现：9 个模型全部不及格

研究团队测试了 9 个主流语言模型，包括 GPT-4o、Claude Sonnet、Llama 4、Qwen 3、DeepSeek-V4 等。结果如下：

• 完全通过率：没有模型在任何一个任务上通过全部测试
• 最佳成绩：最强模型仅 3% 的任务通过了 95% 的测试用例
• 平均表现：大部分模型在 70-80% 的任务中都有超过半数测试失败

这不是说模型写不出代码。ProgramBench 的设定比实际开发场景更宽松——模型能看到完整的文档、参考程序的行为，甚至能通过对话反馈反复修正。但即使在这样的条件下，模型也无法从零构建一个在行为上与参考完全一致的软件。

模型为什么失败：单体文件的诅咒

ProgramBench 揭示了一个特别值得注意的模式：模型生成的代码在架构层面与人类代码存在系统性差异：

单体化倾向：模型强烈倾向于生成单文件实现。即使是需要多个模块协同工作的复杂系统，模型也会把所有逻辑塞进一个文件。这不仅违背了软件工程的基本实践，在实际维护中也是灾难性的。

为什么？研究团队推测，这是因为模型的训练数据中混入了大量教学用途的代码片段（如 Jupyter Notebook、教程代码），这些代码天然是单文件的。模型学会了"看起来正确的代码风格"，但没有学会"可维护的工程实践"。

架构决策缺失：模型能写好函数级别的代码，但当需要做高层架构决策时——如何划分模块、如何设计接口、如何处理跨文件依赖——能力急剧下降。简单说，模型是一个优秀的函数实现者，但不是一个合格的软件架构师。

调试能力有限：当生成的代码不通过测试时，模型的自我修正能力相当有限。不像人类工程师能通过日志、断点、二分法定位问题，模型的"修复"往往是在同一个地方打转——换一种写法但逻辑一样。

对 AI 编码 Agent 开发者的启示

ProgramBench 的发现对正在使用或开发 AI 编码 Agent 的人有几点直接启发：

不要高估 Agent 的自主能力

"给我一个提示，我帮你建一个完整应用"——这在 demo 里看起来很酷，但 ProgramBench 证明，完全自主的代码生成在复杂的软件工程任务上还不可靠。当前的最佳实践应该是人机协作：人类负责架构和设计决策，AI 负责实现和补全。

项目脚手架仍然重要

既然模型倾向于写单体文件，预定义的项目结构和脚手架就显得更加重要。Agent 需要被引导到正确的架构轨道上，而不是从一张白纸开始自由发挥。这解释了为什么像 Agent Skills（Addy Osmani 的项目）这类提供预构建工程技能的工具正在流行。

测试驱动生成

ProgramBench 使用模糊测试自动生成评估，这给 Agent 开发者一个启发：与其让模型自由生成代码然后手动检查，不如先给模型提供测试用例，让生成过程变成"通过测试"的导向任务。这正是 SWE-Agent 等工具采用的方法。

上下文窗口不是万能药

更大的上下文窗口（现在的模型动辄 128K、200K token）并没有解决架构层面的问题。问题不在于模型"记不住"，而在于模型"不会设计"。上下文工程解决的是记忆问题，架构能力需要的是训练数据的质变。

ProgramBench vs 其他基准

软件工程 Agent 评估领域今年出现了多个基准，ProgramBench 填补了其中独特的空白：

• SWE-bench：测的是"修 bug"——给一个 GitHub issue，修复已有代码库中的问题
• HumanEval / MB：测的是"写函数"——给 docstring，补全函数实现
• ProgramBench：测的是"建项目"——给需求文档和参考行为，从零构建完整软件

ProgramBench 是最贴近真实软件工程场景的评估。它不给你代码骨架，不给你测试框架，不给你 API 设计指引——就像真实世界中产品经理丢给你一段需求描述："做出来，行为要和这个一样。"

结果显示，这件事远比修 bug 或写函数难。

对未来的展望

ProgramBench 曝光了当前 LLM 在软件工程能力上的天花板，但也指明了方向：

数据层面：需要更多高质量的多文件、模块化代码作为训练数据。目前训练语料中单文件代码块占主导，这直接影响了模型的输出偏好。

评估层面：单纯测补全和修 bug 是不够的。业界需要像 ProgramBench 这样覆盖完整软件工程生命周期的评估标准。如果你在做一个 AI 编码产品，应该把 ProgramBench 作为重要的能力指标。

架构层面：或许未来的编码 Agent 不再是一个"大模型写所有代码"，而是多个专业化 Agent 协作——一个做架构设计、一个写接口定义、一个实现功能模块、一个写测试。这正是 Deer-Flow 这类 SuperAgent 编排框架在探索的方向。

ProgramBench 的论文标题很谦逊——"Can Language Models Rebuild Programs From Scratch?"——但答案已经很清楚了：现在还不行，但知道了差距在哪里，总比不知道好得多。