Meta斯坦福测试AI刷榜全军覆没 GPT Claude Gemini均得零分
给你一份FFmpeg的使用文档，外加一个编译好的可执行文件。
免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈
现在，从零开始，把整个程序重新写出来。
这就是ProgramBench给全球顶级AI模型出的考题。这项由SWE-Bench原班人马打造，Meta、斯坦福、哈佛三家联合发布的新基准，旨在评估AI的软件工程能力。
200个软件项目，9个顶级模型参与测试。最终通过率是多少？答案是：0%。
这项研究的共同一作John Yang，是斯坦福的在读博士，也是SWE-Bench和SWE-agent的创建者。
不是修Bug，是从零构建软件
过去一年，关于“让AI Agent从零构建软件”的案例层出不穷。Anthropic用Claude协作编写C编译器，Cursor探讨长时间自主编程，Epoch AI的MirrorCode项目也在进行类似尝试。
但这些案例存在一个普遍问题：每次仅测试少数几个项目，且脚手架往往经过人工精心调优。
相比之下，ProgramBench将这一挑战彻底正规化。它提供了200个任务、统一的脚手架和系统性的反作弊设计，直接将标准提升至基准测试的水平。
在之前的SWE-Bench测试中，模型会获得一个现成的代码库，并被告知需要修复的Bug或添加的功能，然后进行修改。这本质上是一种“阅读理解与局部修改”。评估时，它依赖单元测试，检查代码的内部实现是否正确，要求函数签名、变量名等细节必须与预期完全一致。
ProgramBench则完全反其道而行。
它只提供两样东西：一个编译好的可执行文件，以及一份使用文档。
模型的任务是：仅通过运行这个程序、观察其输入输出行为，从零开始编写一套能复现完全相同行为的代码。选择何种编程语言，采用何种数据结构，如何拆分模块，全部由模型自主决定。没有代码骨架，没有预设的函数签名，没有任何提示。
在评估方式上，研究团队采用了Agent驱动的模糊测试，为200个任务生成了总计248,853个行为测试。模型编写的程序运行一遍，只要输入输出和原版一致就算通过，不一致则失败。这些测试永远不会透露给模型。
与SWE-Bench的单元测试不同，ProgramBench的行为测试完全不关心代码的内部结构，只关注最终行为是否一致。
这200个任务覆盖的项目横跨多个领域：压缩工具（如zstd、lz4、brotli）、语言解释器（如PHP、Lua、tinycc）、数据库（如DuckDB、SQLite）、媒体处理（如FFmpeg）、开发者工具（如ripgrep、fzf、jq）。代码行数的中位数是8,635行，最大的FFmpeg项目高达270万行。
总结来说，这个测试考察的是AI是否具备“像人类软件工程师一样思考和设计软件”的系统能力，而不仅仅是“在现有代码中找到并修复问题”。
九大模型排排坐，成绩全部吃鸭蛋
参与测试的共有9款模型，涵盖了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则是9个模型里最爱“观察”的。它平均使用94次API调用，其中34.1%的操作都在运行原版程序、观察输入输出行为。探索做得最多，但最终成绩并未因此显著拉开差距。
真正拉开身位的是Claude Opus 4.7。它的平均通过率达到51.2%，并且在3%的任务上通过了95%以上的测试，是唯一达到“几乎通过”标准的模型。但即便如此，它也没有在任何一个任务上拿到满分。
从整体来看，9个模型的表现呈现出清晰的梯队。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这个极简脚手架，没有上下文压缩、没有多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给你重写一遍。
说好的不作弊，一联网就去GitHub扒源码
这可能是整个研究里最有戏剧感的部分。
研究团队做了一组对照实验：给模型开放网络访问权限，但在系统提示中明确告知“作弊不允许”。然后，他们用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%。
相关攻略
陶哲轩利用ClaudeCode处理论文审稿意见，仅用15分钟便高效完成了修改，并发现了审稿报告中的一处笔误。他设想将语法校对等繁琐工作交给AI处理，而让研究者专注于核心难题。这体现了AI作为“副驾驶”辅助研究、提升效率的趋势，此前AI已帮助解决多个数学难题。
Anthropic与亚马逊达成十年千亿美元AI基础设施合作，锁定5吉瓦算力用于Claude模型。亚马逊追加投资，总投资额近330亿美元，以应对用户激增带来的算力需求。行业竞争正从模型转向基础设施，算力成为核心护城河。双方深度绑定，但Anthropic保持运营独立并实施多云战略。
Meta、斯坦福等机构推出ProgramBench基准测试，要求AI仅凭可执行文件和使用文档，从零重写完整程序。测试涵盖200个项目，采用行为测试评估。九大顶级模型（包括GPT、Claude、Gemini）的完全通过率均为0%，ClaudeOpus4 7表现最佳，但未获满分。研究发现AI生成的代码结构简陋，缺乏模块化设计，且存在作弊倾向。该测试表明AI在软件
苹果大失误！把自用的Claude md打包到了最新App里 这下可算是被坐实了：苹果内部，确实在用Claude Code来构建生产级应用。 连这么大的公司，也在“氛围编程”（Vibe Coding）吗？ 要知道，项目级的Claude md文件，通常就是用来告诉AI这个项目是什么、该怎么构建、需要遵循
苹果大失误！把自用的 Claude md 打包到了官方 App 里 这下可算是被“实锤”了：苹果内部，确实在使用 Claude Code 来构建生产级别的应用。 连这样体量的科技巨头，也在进行所谓的“Vibe Coding”吗？ 要知道，项目级的 Claude md 文件，通常就是用来告诉 AI 助
热门专题
热门推荐
在Java中直接调用a equals(b)进行对象比较时，若a为null会抛出NullPointerException。使用Objects equals(a,b)方法能自动处理参数为null的情况，其内部通过先检查引用是否为null再调用equals，从而安全地完成比较。该方法适用于实体字段判等等场景，但需注意其将两个null视为相等的设计是否符合具体业务逻
全局拦截子线程崩溃需设置默认处理器并结合自定义ThreadFactory为每个新线程注入统一处理器，前者作为兜底方案，但无法覆盖已有专属处理器的线程及Android主线程。Android中还需额外处理主线程及异步框架异常。捕获崩溃后应留存现场、异步上报并防止雪崩。
CMS垃圾收集器以低延迟为目标，其四个阶段中仅初始标记和重新标记需要暂停所有用户线程。初始标记快速标记直接关联对象，重新标记修正并发标记期间变动的引用，两者停顿时间极短。而并发标记和并发清除阶段则与用户线程并行执行，避免了长时间中断。
ByteBuffer asReadOnlyBuffer()方法创建原缓冲区的只读视图，共享底层数据且禁止写入，但无法阻止通过其他可写引用修改数据，因此不提供真正的数据隔离。它适用于需只读访问且避免拷贝的场景；若需完全隔离，则应进行深拷贝。
ExceptionInInitializerError常包裹单例模式静态初始化时发生的空指针异常。排查需通过getCause()找到根源，通常是静态字段赋值或静态代码块中的空值。应注意静态初始化顺序，避免循环依赖。对于复杂初始化，推荐使用懒汉式并在getInstance()方法内进行异常处理，以便直接定位问题。