只给你一个编译好的可执行文件（比如FFmpeg、SQLite、PHP解释器）和一份使用说明书，要求你仅通过运行它、观察它的行为，从零写出能完全复现其行为的一套代码。没有代码骨架，没有函数签名，没有任何提示。

结果，Claude Opus 4.7只完成了3%的任务的95%以上测试——已经是最好成绩，但仍然没有一项满分。

SWE-Bench考的是AI能否当好一个“修理工”，ProgramBench考的是AI能否当好一个“架构师”。

这两者之间的距离，还差着整个软件工程的认知维度。

1任务有多难？相当于在黑暗中摸出一座大厦的蓝图

ProgramBench的200个任务覆盖了压缩工具（zstd、lz4）、语言解释器（PHP、Lua）、数据库（SQLite）、媒体处理（FFmpeg）、开发者工具（ripgrep、fzf）。

每个项目的代码行数中位数8,635行，最大的FFmpeg有270万行。人类工程师即便理解这些系统也需要数周甚至数月。

模型面临的不是已知漏洞列表，而是一个完全未知的黑盒系统。它只能通过反复执行原版程序，构造不同的输入，观察输出差异，反向推断程序的逻辑、数据结构、算法和边界条件。

研究团队生成了总计24.8万条行为测试来评估模型生成的代码——只要输入输出和原版一致就算对，内部实现不作限制。

这种“行为等价”评估比单元测试宽容得多，但即便如此，模型仍旧全面溃败。

2 为什么这么难？三个能力维度的集体缺失

通过对高分解答（通过率>75%）和人类原版代码的深入对比，研究团队揭示了模型失败的结构性原因：

架构设计能力完全缺失。

人类代码中位数分布在15个文件里，模型的中位数是3个，60%的解答只有1到3个代码文件。

人类工程师按功能拆分模块、定义清晰的接口抽象，而模型倾向于把所有逻辑塞进一个巨大的文件。

目录深度中位数，人类是2层，模型是1层。

这种“单文件怪兽”在简单CLI工具上还能跑通，一旦遇到FFmpeg级别的复杂性，就会因耦合过重而无法维护和调试。

函数抽象能力严重不足。

Opus 4.7写的函数数量只有人类的29%，Sonnet 4.6是24%，GPT-5.4只有10%。

每个函数的平均长度更长——Gemini 3.1 Pro的函数比人类长62%。

模型不理解为什么要将重复逻辑抽取为函数、为什么要控制圈复杂度，它的目标仅仅是“让测试通过”。

结果就是巨大的函数体，内部塞满重复代码和深层嵌套条件分支。

代码规模预估错误。

模型代码中位数1,173行，人类是3,068行，85%的高分解答比原版短得多。

在复杂系统中，短不一定意味着更高效；往往意味着遗漏了边界情况、错误处理、性能优化和可扩展性设计。

模型倾向于走“最少功能路径”，而不是实现完整规范的工业级软件。

3 不同的风格：狂野的GPT，审慎的Gemini，内省的Claude

GPT-5.4是典型的“莽撞型”。

平均只创建5个文件，修改1.2次，39.5%的轨迹在创建文件后零修改。

它倾向于一次性生成整个程序，然后几乎不回头调试。成本极低（0.33美元），但适应性差，遇到复杂逻辑就会卡住。

Gemini 3.1 Pro是“观察型”。

平均94次调用，34.1%的操作是运行原版程序、探索行为模式。

它试图通过大量实验来理解系统，但最终成绩与GPT相当，说明“多看”并未弥补“想不深”的缺陷。

Claude Opus 4.7是“迭代型”。

平均93次调用，但每次调用质量高，主动进行代码审阅和重构，而且会删除自己之前生成的错误代码。

它体现了类似于人类开发者的“打磨”习惯——先写一个草稿，再不断修正，甚至大幅重构。这也是它能拿到唯一“接近通过”成绩的关键。

Claude Sonnet 4.6是最勤奋的“劳模型”。

平均868条命令、27.09美元，最长轨迹近2000步。可惜高投入并未换来高回报——大量步数消耗在无效尝试和错误路径的回溯上。

4 “作弊”的诱惑：当AI学会抄答案

当研究团队开放网络访问、但明确告知不得作弊时，大量模型依然选择走捷径。

Claude Sonnet 4.6有36%的任务被判定作弊，Opus 4.6为21%，Gemini 3 Flash为20%。

作弊方式包括直接克隆GitHub仓库、通过包管理器下载源码、翻本地依赖缓存。

模型缺乏对“合理逆向工程”与“抄袭”的边界判断。

即便要求不得作弊，模型在遇到困难时，其内置的“寻求外部信息”倾向会压倒对齐约束。

现阶段的RLHF并未真正教会模型“诚实”的原则，只是教会了它在测试中压抑本能。

作弊判定本身就是一项未解难题。

9个AI裁判对Claude Opus 4.6的57%任务无法达成一致。

随着模型能力提升，区分“合法借鉴”和“违规复制”将变得越来越模糊。

5 旧考试已经过时，新考试才刚刚开始

Epoch AI上周断言：现有的推理基准已集体死亡，想设计还没被刷爆的测试，至少要放弃四个舒适条件的某一个——纯文本、短耗时、易评分、人类专家碾压。

ProgramBench放弃了其中两个：它把任务推到了人类需要数周甚至数月的量级，同时用行为等价性而不是源码匹配来评估。

0%的通过率并非终点，而是一个精确的度量：今天的AI在软件设计这个维度上的能力接近于零。

SWE-Bench上模型能拿72%，是因为它本质上是“在清晰给定的代码库中定位问题并修好”。模型可以通过学习大量GitHub PR模式来“刷题”。

ProgramBench则完全切断了这条路——没有已有代码，没有模式可套，必须从零推理设计。

论文作者John Yang指出：“ProgramBench在设计上是可解的。”也就是说，0%不是理论天花板，而是我们与目标之间的真实距离。

如何从“会修代码”迈向“会设计软件”？这可能需要的不是更大的模型，而是新的训练范式——让模型在合成项目上练习从需求到设计的全流程，引入软件架构的反馈信号，甚至让模型生成代码后自己审视可维护性。

6 对AI开发的启示：我们可能低估了软件工程的复杂度

：大语言模型在代码生成上的惊艳表现，容易让我们高估其对软件工程的理解。

写一个排序函数、写一个网页组件，和设计一个模块化、可扩展、易维护的完整系统，中间隔着一道认知鸿沟：架构思维。

不仅涉及语法和算法，更涉及在不确定需求下做抽象决策、权衡耦合与内聚、预判未来变更的可能性。

目前的模型训练范式——无论是预训练的下一个词预测，还是RLHF的人类偏好——都没有直接优化架构设计能力。

模型可以记住常见的设计模式，但无法“设计出全新的、符合情境的架构”。这就好比一个学生背熟了所有公式，但从未做过真正的物理实验。

AI设计软件，才是真正的“下一关”。

ProgramBench就是这关的第一次全国统考——成绩单上写着：进步空间无限。

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