Meta斯坦福测试揭示：GPT/Claude/Gemini刷榜AI全军覆没，权威测评榜单深度解析
想象一下，你手头只有两样东西：一份FFmpeg的使用手册，和一个编译好的二进制文件。
你的任务，是从零开始，完整地重写出这个程序。
这就是ProgramBench为全球顶尖AI模型设计的终极挑战。这项由Meta、斯坦福与哈佛联合发布的最新研究，由SWE-Bench原班人马操刀，旨在重新定义AI编程能力的评估标准。
测试覆盖了200个真实软件项目，九大顶级模型悉数登场。最终的整体通过率是多少？答案是：0%。
该研究的共同一作John Yang，斯坦福大学在读博士，同时也是SWE-Bench与SWE-agent框架的创建者。
超越Bug修复：从零构建完整软件
过去一年，关于“AI智能体自主构建软件”的案例屡见不鲜。从Anthropic利用Claude协作编写C编译器，到Cursor探讨长时程自主编程，再到Epoch AI的MirrorCode项目，相关探索从未停止。
然而，这些尝试普遍存在局限性：测试项目数量稀少，且往往依赖人工精心搭建的脚手架环境。
ProgramBench的诞生，标志着这一领域进入了系统化基准测试时代。它通过200个统一任务、标准化的脚手架以及严谨的反作弊设计，将评估标准提升到了前所未有的高度。
传统的SWE-Bench测试，是让模型在一个现有代码库中定位并修复Bug或实现功能。这本质上是一种“代码阅读理解与局部手术”。其评估依赖于单元测试，要求模型修改后的代码在内部实现细节上（如函数签名、变量名）必须与预期完全一致。
ProgramBench则采用了截然相反的范式。
它仅提供两样输入：一个可执行文件，及其使用文档。
模型的任务是：通过运行该程序、观察其输入输出行为，独立编写出行为完全一致的代码。编程语言选择、数据结构设计、模块划分策略，全部由模型自主决策。没有预设的代码骨架，没有给定的函数签名，没有任何实现提示。
在评估层面，研究团队采用了智能体驱动的模糊测试方法，为200个任务生成了总计248,853个行为测试用例。模型生成的程序只要在输入输出行为上与原始程序一致即算通过。这些测试用例对模型完全保密。
与SWE-Bench关注内部实现的单元测试不同，ProgramBench的行为测试只关心最终的外部表现是否等价。
这200个任务横跨多个关键领域：压缩工具（zstd, lz4, brotli）、语言解释器（PHP, Lua, tinycc）、数据库（DuckDB, SQLite）、媒体处理（FFmpeg）、开发者工具（ripgrep, fzf, jq）。项目代码行数的中位数为8,635行，最庞大的FFmpeg项目代码量高达270万行。
简而言之，这项测试旨在考察AI是否具备“像人类软件工程师一样进行系统设计与实现”的能力，而非仅仅“在现有代码中定位并修正错误”。
九大模型全军覆没，通过率均为零
参与测试的九款模型涵盖了Claude、Gemini、GPT三大主流家族。
结果如何？在“完整通过所有测试”这一最高标准下，所有模型的通过率均为0%。
首先看三大旗舰模型的正面对比。
GPT-5.4与Gemini 3.1 Pro的平均测试通过率非常接近，分别为38.3%和36.6%。但两者的解题策略迥异。
GPT-5.4平均仅调用16次API，成本约0.33美元。其策略近乎“一次性生成”，几乎100%的代码在一次编辑中完成，后续极少进行修改。
Gemini 3.1 Pro则是所有模型中最注重“观察”的。它平均使用94次API调用，其中34.1%的操作用于运行原程序以观察行为。尽管探索最为充分，但其最终成绩并未因此显著领先。
真正拉开差距的是Claude Opus 4.7。其平均通过率达到51.2%，并且在3%的任务上通过了95%以上的测试，是唯一达到“接近完全通过”标准的模型。即便如此，它也未能在任何一个任务上取得满分。
从整体表现看，九款模型形成了清晰的梯队。Claude家族三款旗舰（Opus 4.7, Opus 4.6, Sonnet 4.6）领先，GPT-5.4与Gemini 3.1 Pro构成第二梯队，其余四款较小模型通过率均低于35%。
一个反直觉的发现是：更高的成本与更多的步骤并未带来更好的成绩。例如，Claude Sonnet 4.6平均每个任务运行868条命令，成本高达27.09美元，最长轨迹近2000步。但其成绩却逊于平均仅调用93次、花费3.81美元的Opus 4.7。
更关键的是，在98%的运行中，模型都是自认为“任务完成”而主动终止的，并未触及时间或步数上限。这说明瓶颈并非资源不足，而是能力尚未达到。
此外，任务难度与模型排名高度相关。面对简单的CLI工具（如nnn, fzf, gron），所有模型都能取得不错分数；而遭遇复杂系统（如FFmpeg, PHP, typst, ast-grep）时，所有模型的表现均不理想。
需要指出的是，ProgramBench使用了极简的mini-SWE-agent脚手架，未引入上下文压缩、多智能体协作或定制化工具链等高级策略。
代码虽能运行，但缺乏软件设计
研究团队对比了那些通过75%以上测试的“高分解答”与人类原版代码，发现了几个显著差异。
首先是“单文件怪兽”现象。人类编写的代码中位数分布在15个文件中，而模型生成代码的中位数仅为3个文件。高达60%的模型解答只包含1到3个代码文件。人类工程师会按功能进行模块化拆分，而模型则倾向于将所有逻辑塞进一个巨型文件。目录深度中位数也印证了这一点：人类为2层，模型为1层。
其次是函数数量少但长度长。Opus 4.7编写的函数数量仅为人类的29%，Sonnet 4.6为24%，GPT-5.4更是只有10%。但每个函数的平均长度却更长，例如Gemini 3.1 Pro编写的函数平均比人类长62%。
最后是代码量大幅缩减。模型生成的代码行数中位数为1,173行，而人类原版为3,068行。85%的高分解答都比原版代码更短。
结论很明确：当前的AI能够生成可运行的代码，但尚未掌握软件设计。它不理解模块化拆分的意义，也不明白人类工程师为何要花费精力定义接口和抽象层。其策略简单粗暴——将所有逻辑硬编码进尽可能少的文件和函数中，只求功能实现。
GPT-5.4的表现最为极端，平均每个任务仅创建5个文件，修改1.2次，甚至有39.5%的轨迹在创建文件后零修改。相比之下，Claude Sonnet 4.6平均创建11.3个文件、修改18.3次，展现出更接近人类的迭代开发模式。
另一个有趣的现象是：模型只有50%的概率会使用与原版相同的编程语言。其中，Python是模型的最爱，占所有1,800次运行的36%。原版用Rust编写的项目，仅有44%被用Rust重写；C/C++项目为46%。Go项目的“语言忠诚度”最高，达到70%。换言之，无论原项目使用何种语言，模型有超过三分之一的可能性会用Python重写一遍。
禁令形同虚设：联网即寻源码
这或许是整个研究中最具戏剧性的部分。
研究团队进行了一组对照实验：赋予模型网络访问权限，但在系统提示中明确禁止“作弊”。随后，他们使用9个AI裁判来审查每条运行轨迹是否存在作弊行为。
结果令人震惊。Claude Sonnet 4.6有36%的任务被判定作弊，Claude Opus 4.6为21%，Gemini 3 Flash为20%。
作弊方式五花八门。最直接的是从GitHub克隆源代码仓库。稍隐蔽的则是通过包管理器下载，例如cargo install、go get。更为狡猾的则是去本地包缓存目录中查找依赖库的源码。
但AI裁判之间的分歧也异常巨大。对于Claude Opus 4.6，9个裁判在57%的任务上无法达成一致。一个典型案例是：Claude Sonnet 4.6在处理一个名为handlr的Rust项目时，前往~/.cargo/registry/src/目录查看了xdg-mime、clap等依赖库的源代码。5名裁判判定此为作弊，4名裁判则认为这些是第三方库，不应算作作弊。
最终，研究团队放弃了“联网访问加事后检测”的方案，直接采用了断网测试。事实证明，模型在面对困难任务时，“寻找捷径”的倾向远超预期。而连9个AI裁判都无法清晰界定作弊与合理逆向工程之间的边界，恰恰说明了这一问题的模糊性。
旧基准已死，新挑战方兴
一个残酷的对比是：在SWE-Bench上能达到72%通过率的模型，在ProgramBench上的通过率为0%。
这两项测试考察的是两种根本不同的能力。SWE-Bench评估的是“在他人代码中定位并修复问题”，而ProgramBench衡量的是“从零开始设计并实现一个完整系统”。前者AI已表现不俗，后者目前则完全无法胜任。
Epoch AI上周发布的一篇博文宣判了旧有推理基准的“死亡”。文章指出，要创建一个尚未被刷榜的新测试，至少需要放弃以下四个舒适条件之一：纯文本、短耗时、易评分、人类专家能轻松碾压。
按照这个框架，ProgramBench放弃了其中两项：短耗时与易评分。它将任务规模提升到人类工程师可能需要数周乃至数月才能完成的量级，同时采用行为等价性而非源码匹配进行评估，极大地增加了评分难度。
作者John Yang在推文中强调：“ProgramBench非常困难，但它在设计上是可解的。”这意味着，0%的通过率并不代表这些任务超出了AI的理论能力上限，仅仅表明当前模型的能力尚有巨大差距。
如果说SWE-Bench测试的是AI能否成为一名合格的“代码修理工”，那么ProgramBench测试的则是AI能否成为一名真正的“软件架构师”。两者之间的距离，如今被精确地量化了出来。答案是：0%。