新智元报道
最近，Meta、斯坦福大学和哈佛大学联手推出了一个名为ProgramBench的新测试平台，用于评估顶级AI模型在软件开发中的表现。这项新挑战源自SWE-Bench团队，并且它要求参与者从零开始编写200个完整的软件项目。
ProgramBench的目标是检验人工智能是否具备像人类工程师那样思考和设计复杂系统的技能。
任何拿到72%分数的模型，在这个全新的测试下都只能得到零分。
这次评估不仅包括了C编译器等经典任务，还涵盖了数据库、媒体处理工具等多个领域的项目。
据悉，ProgramBench是由SWE-Bench的主要开发者John Yang等人共同开发的。
在这次大规模测试中，九款顶级模型均未能完成任何一项挑战。所有项目的通过率为零。
这位在读博士同时也是开源软件项目SWE-Bench和SWE-agent的设计者之一。
与以往不同的是，ProgramBench要求从头开始编写代码，而不是修复或改进现有程序。
最近有关AI代理独立完成编程任务的报道层出不穷。
Anthropic使用Claude创建了一个C编译器，Cursor博客文章中探讨了长时间自主编程的概念，而Epoch AI的MirrorCode也在进行类似的工作。
然而，这些案例通常只涉及少量项目，并且依赖于手工优化脚本环境。
相比之下，ProgramBench提供了一个标准化、系统化的测试框架。
该平台包括了200个任务和一套统一的开发工具，能够全面地评估模型的能力并防止作弊行为。
这项研究不仅关注代码的质量，还强调了对整体项目设计的理解与实现能力。
SWE-Bench测试的重点在于通过单元测试来验证AI修改现有程序错误或添加功能时的表现。
而在ProgramBench中，模型需要根据给定的可执行文件和文档从零编写代码，确保输出结果的一致性。
ProgramBench完全摒弃了传统的评估方式。
它只提供编译后的程序及其使用说明，要求参与者仅靠观察其输入输出行为来重建整个系统。
所有的编程语言选择、数据结构和模块划分都需要模型自行决定，并且没有任何提示或代码框架可供参考。
测试团队采用了一种基于模糊测试的评估方法，为每个任务生成了超过24万个行为测试案例。
只有当程序的行为完全一致时才能算通过测试，即使在某些细节上略有不同也会被判定为失败。
涵盖的项目范围广泛，包括压缩工具、语言解释器和媒体处理软件等复杂系统。
这些项目的代码量从几千行到数百万行不等。
也就是说，这项测试旨在评估AI模型是否具备独立设计完整系统的潜力，而不仅仅是修改现有程序的能力。
在九个顶级模型中，所有者的通过率为零。
其中最引人注目的是Claude Opus 4.7，在三项任务中的表现接近满分，但仍然没有达到全胜标准。
总体来看，这些模型的表现呈现出明显的层次结构。Claude系列的旗舰产品在本次测试中领先，其次是GPT-5.4和Gemini 3.1 Pro。
花费大量时间和资源并不能显著提高成绩，即使是Sonnet 4.6这种高级别的模型也不例外。
更令人惊讶的是，在面对实际编程任务时，AI模型倾向于采用与人类工程师完全不同的策略。
它们往往使用较少的文件和更长的函数，并且大多数情况下不会超出时间限制或步数上限自行终止运行。
代码布局方面也存在显著差异。例如，Claude Sonnet 4.6倾向于创建更多独立文件，而GPT-5.4则偏好于将所有逻辑集中在一个或少数几个文件中。
此外，在选择编程语言时，AI模型显示出了一定的倾向性。比如Python成为了最受欢迎的选择之一。
不过，当网络访问被允许的情况下，许多模型会尝试通过各种方式寻找源代码来获取答案。
然而，不同AI裁判对这种行为的判定存在巨大分歧，这表明识别作弊和合理逆向工程之间的界限并不清晰。
由于这些问题的存在，最终研究团队决定直接切断网络连接，以确保公平性。
当前的测试结果清楚地表明，虽然AI在处理特定任务上表现出色，但它们尚未达到能够独立设计复杂系统的水平。
SWE-Bench和ProgramBench分别考察了AI模型作为程序员和工程师的能力差距。
随着这项新挑战的到来，旧有的推理基准测试已经被宣判“死亡”。
ProgramBench打破了几个传统舒适条件，并且其任务规模已经接近人类开发者的实际工作量。
尽管当前的AI模型尚未达到预期目标，但作者John Yang认为这些问题是可解的。目前的结果只是说明了现有技术尚存差距而已。
通过这个新的评估体系，人们可以更准确地衡量AI在软件工程领域的进步空间。
不是考试时间不够，是真的做不到。
此外，任务难度和模型排名高度一致。
简单的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上周刚发了一篇博文，宣判旧推理benchmark集体死亡。想搞出还没被刷爆的测试，至少得放弃四个舒适条件中的一个，纯文本、短耗时、易评分、人类专家碾压。
按这个框架来看，ProgramBench放弃了其中两个，短耗时和易评分。
它把任务拉到了人类工程师可能需要数周甚至数月才能完成的量级，同时用行为等价性而非源码匹配来评估。
作者John Yang在推文中强调，「ProgramBench非常难，但它在设计上是可解的。」
也就是说，0%不代表这些任务超出了AI的理论极限，只是说明今天的模型还远远不够。
SWE-Bench测的是AI能不能当一个好员工。ProgramBench测的是AI能不能当一个工程师。
这两件事之间的距离，今天刚被精确测量出来。答案是0%。
参考资料：
https://programbench.com/static/paper.pdf
https://x.com/jyangballin/status/2051677497562210552?s=20
https://x.com/EpochAIResearch/status/2051760424891392204?s=20
https://epochai.substack.com/p/rip-classic-reasoning-benchmarks