ProgramBench：最硬核编程测试中，所有公开AI模型得分均为0%

ProgramBench是一项严苛的新LLM编程基准测试，它瞄准了大多数排行榜几乎未涉及的能力：模型能否仅通过观察行为，在从未见过源代码的情况下重构整个程序？the-verification-horizon-why-rewarding-coding-agents-is-getting-harder

设置直接但惩罚性强。智能体获得一个编译后的可执行文件及其使用文档。它的任务是：探测程序、推断其工作原理、选择实现策略、编写源代码、制作构建脚本，并提交候选程序。然后，输出结果将通过隐藏的行为测试与原始程序进行比较。

这与完成单个函数、解决竞赛问题或修补已知代码仓库的任务相去甚远。

ProgramBench 测试了其他基准未测试的内容

ProgramBench主要用于评估编程智能体，而非聊天模型。如果你的工作流程是“让模型编写一个小函数”，那么ProgramBench可能过于困难且不直接。HumanEval、LiveCodeBench以及特定语言的编程评估将提供更多信息。如果你的工作流程是“让模型修补已知代码仓库”，那么SWE-bench Pro、SWE-Rebench和SWE-bench Verified仍然更直接相关。

当任务不那么结构化时，ProgramBench才变得有趣。对于模型买家而言，它尚不是“挑选顶级模型并投入生产的”排行榜。它更像一个警告：当源代码、问题描述和脚手架消失时，当前的编程智能体仍然步履蹒跚。对于智能体构建者来说，它是一个诊断工具，揭示了智能体是否能在实施之前进行调研。the-verification-horizon-why-rewarding-coding-agents-is-getting-harder

ProgramBench建立在“洁净室重构”概念之上。每个任务从一个编译后的可执行文件和文档开始。模型必须决定向可执行文件提出哪些问题。它可以用输入运行程序并观察输出，但不能窥视底层实现。这使得ProgramBench成为架构和规范发现的基准，而不仅仅是代码编写。

ProgramBench 与主要编程基准的比较

大多数编程基准仍然为模型提供了大量结构。HumanEval提供了函数签名和文档字符串。SWE-bench Verified提供了现有代码仓库和特定问题。LiveCodeBench提供了竞赛式编程问题陈述。ProgramBench去除了大部分这些脚手架。它考察智能体能否仅通过交互来重构目标行为。

这一区别之所以重要，是因为现实中的软件工程通常始于部分规范。开发者逆向工程工作流程、探测API、探索老化系统，并从观察到的行为中推断边缘情况。ProgramBench将这类工作压缩到一个评估环境中。why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

最接近的比较是SWE-bench，但任务形态几乎相反。SWE-bench考察智能体是否能正确修改真实的代码库。ProgramBench考察智能体是否能发现程序的功能，并构建一个行为相同的全新代码库。the-migration-isnt-finished-until-the-build-server-says-it-is-why-ai-agents-keep-failing-at-enterprise-java

当前排行榜：一幅令人清醒的图景

初始的公开排行榜刻意令人警醒：

• Claude Opus 4.7：完全解决 0.0%，接近解决 3.0%
• Claude Opus 4.6：完全解决 0.0%，接近解决 2.5%
• Claude Sonnet 4.6：完全解决 0.0%，接近解决 1.0%
• GPT 5.4：完全解决 0.0%，接近解决 0.0%
• Gemini 3.1 Pro：完全解决 0.0%，接近解决 0.0%

主要指标是完全解决的任务。目前所有公开模型均为 0%。ProgramBench 还报告了“接近解决”的任务，即通过至少 95% 行为测试的运行。BenchLM 在展示页面上使用该辅助指标，因为它目前是模型之间唯一可见的区分项。

如何正确解读排行榜

ProgramBench 排行榜需要比普通编程基准更仔细地解读。在大多数编程排行榜上，更高的分数直接意味着解决了更多任务。在当前的 ProgramBench 上，官方主要指标是平的：每个评估过的公开模型完全解决率均为 0%。唯一的区分来自辅助的“接近解决”率。

这意味着三件事。首先，不要对排名前三的模型过度排序。Claude Opus 4.7 以 3.0% 的接近解决率领先，这是一个有意义的信号，表明它更频繁地接近目标，但这并非生产级别的成功率。其次，不要将 0.0% 的接近解决率视为模型质量相同。一个模型可能以多种方式在 ProgramBench 上失败。第三，要预期框架效应的重要性，ProgramBench 是智能体基准，而非纯模型基准。

暴露的失败：为什么分数接近零

低 ProgramBench 分数同时暴露了多种失败模式。浅层探测导致智能体从过少的观察中推断过多。过早实现，这在许多针对快速编辑优化的智能体工作流程中被鼓励，但当主要挑战是发现规范时会适得其反。缺失负面案例意味着智能体忽略了无效标志、错误和退出代码。缺乏骨架的弱架构导致无法扩展的脆弱实现。糟糕的自我测试阻止智能体验证其替代方案。过度自信是一个严重的实际问题：智能体经常宣布完成并提交不完整的作品，正如 LocalLLaMA 发布讨论中所指出的。工具循环的脆弱性甚至可能扼杀强大的基础模型。

这些失败模式正是 ProgramBench 有用的原因。它们也是为什么未来的公开排行榜应该报告多于一个数字的原因。对于严肃的分析，我们需要知道失败是来自糟糕的探测、糟糕的代码、构建失败、时间限制、遗漏的边缘情况还是错误的停止决策。why-your-ai-agent-might-ace-the-task-but-flunk-the-process-enter-skillcoach

如何运行 ProgramBench

团队已发布 GitHub 仓库、Hugging Face 数据集以及 Docker/推理材料。基本的本地工作流程是安装包并使用 programbench eval 评估提交。智能体必须保留基准设置：无互联网访问、无直接源代码查找、无反编译捷径。对于构建编程智能体的团队而言，实际价值不在于追逐当前排行榜，而在于进行受控的内部实验。

基准测试的后续步骤

如果公开提交能够将模型质量与框架质量分开，如果开源权重模型的结果得到更广泛的覆盖，并且如果主要的解决指标有所变化，ProgramBench 将变得更有用。BenchLM 在专门的基准测试页面上跟踪 ProgramBench，并使其在编程排行榜上仅以展示形式存在，直到信号变得更加稳定。目前，最好将其视为关于当前编程智能体在洁净室重构中能力极限的前沿警示灯。all-llms-corrupt-your-documents-when-you-delegate-a-close-look-at-the-delegate-52-benchmark