为什么重要
ProgramBench 是第一个从系统级评估 AI 编码能力的基准。现有代码基准（SWE-bench、HumanEval 等）测试的是局部能力——修 bug、补功能、写函数，而 ProgramBench 直接追问：AI 能不能像真正的工程师一样，从零开始构建一个完整的软件系统？
结果令人震惊：9 个顶级模型、200 个真实项目、完整解决率 0%。即便放宽到”接近完成”（95% 行为测试通过），最强模型 Claude Opus 4.7 也仅有 3%。这暴露了当前 AI Coding 最核心的短板：擅长局部代码生成，但不擅长全局系统规划。
构建方式
- 从开源 GitHub 仓库中选取用编译语言（C/C++、Go、Rust、Java）编写的项目
- 编译项目，然后剥离所有源码和测试，仅保留可执行文件和文档
- 用 agent-driven fuzzing 自动生成 248,000+ 行为测试，覆盖各种输入输出
- 评测时不看源码相似度，只看行为等价——模型可以用完全不同的语言、算法、架构来实现
任务示例
典型任务：给定 ripgrep 的可执行文件和 --help 文档，从零实现一个行为等价的搜索工具。模型需要自行决定：
- 使用什么编程语言和构建系统
- 如何组织代码目录和模块
- 选择什么数据结构和算法
- 错误处理策略
难度范围：从简单的 CLI 工具（如 gron、fzf）到复杂系统（如 FFmpeg、SQLite、PHP 解释器）
关键发现
- 0% 完整解决率：没有任何模型能完整重建任何一个项目，这是目前代码基准中最低的通过率
- 模型倾向单体化：所有模型都偏爱生成单文件、超长函数的”巨型脚本”，与人类工程师的模块化风格截然相反
- C/C++ 项目表现最好：大量历史代码和 Stack Overflow 内容帮助模型在 C/C++ 项目上取得相对更好的成绩
- Rust 项目表现最差：Rust 的工程哲学（ownership、trait system、模块化）恰恰是当前模型最不擅长的
- Claude 系列相对领先：Opus 4.7 以 3% 的”几乎完成”率领先，但仍远低于实用水平
- 最后一公里最难：模型经常能完成 50-80% 的功能，但无法达到 100% 行为等价
与 SWE-bench 的关键区别
| 维度 | SWE-bench | ProgramBench |
|---|---|---|
| 输入 | 仓库源码 + Issue 描述 | 可执行文件 + 文档 |
| 任务 | 修 bug / 加 feature | 从零构建整个软件 |
| 评测 | 单元测试通过 | 行为等价（agent-driven fuzzing） |
| 架构决策 | 无（已有代码结构） | 完全由模型决定 |
| SOTA | ~90% (Verified) | 0% (Full) / 3% (Almost) |
争议与局限
- 记忆污染质疑：部分项目（如 FFmpeg）是知名开源软件，模型可能在训练中见过源码
- “人类也做不到”的反对意见：人类工程师也很难从零重写 FFmpeg——但 benchmark 的目标是推动能力上限
- 当前未测试完整 Agent 框架：如 Claude Code、Codex 等产品级 Agent 未被评测
- 限制了联网能力：实际使用中 Agent 通常有网络访问权限
关联基准
- SWE-bench Verified：issue 修复级评测
- SWE-bench Pro：高难度 issue 修复
- Terminal-Bench 2.0：终端任务评测
- Web-Bench：前端代码评测