AI 编程圈最近出现了一个新的基准测试：ProgramBench。表面上看，它给出的结果很让程序员安心：九个主流模型在 fully resolved 指标上全部是 0%，没有任何模型能完整通过一个任务。
但这件事真正值得紧张的地方，不是今天的大模型还做不到，而是完整软件工程第一次被清楚地做成了一套可评测、可排名、可反复优化的题。
一旦任务被定义清楚，AI 行业最擅长的事情就会发生：刷题、迭代、追榜，然后把原来做不到的事情一点点推到可用边缘。
ProgramBench 到底在测什么
很多编程基准测试，测的是补函数、改 bug、通过单元测试，或者在已有项目里完成一个小功能。ProgramBench 更狠，它不给源代码，也不给项目结构，更不给现成测试用例。
它给模型的材料主要只有两类：
- 一个已经编译好的可执行文件。
- 这个程序的使用文档。
模型需要自己运行可执行文件，观察输入输出行为，理解命令行参数、边界情况、错误信息、数据存储方式，然后重新实现一个行为一致的程序。
这已经不是“写一段代码”，而是一个简化但完整的软件工程任务：要理解需求、探索行为、选择语言、设计结构、写源码、提供构建方式，并尽量通过隐藏测试。
根据 ProgramBench 官方介绍，它目前包含 200 个任务，覆盖从小型命令行工具到 PHP、FFmpeg、SQLite 等大型真实项目。测试集由 agent-driven fuzzing 生成，总量超过 248,000 个行为测试。
如果把测试流程拆开，ProgramBench 大致是在考四件事：
- 读懂文档：理解程序应该提供哪些命令、参数和输出。
- 探索行为：反复运行二进制程序，观察正常输入、异常输入和边界情况。
- 重建实现：自己选择语言和项目结构，写出一个行为接近的替代程序。
- 通过隐藏测试：不仅常规行为要对，错误处理、输出格式和边界条件也要尽量一致。
所以它的搜索价值不只是“又一个跑分”，而是回答一个更具体的问题：大模型能不能在没有源码的情况下，只靠文档和黑箱行为，从零复刻一个真实软件。
为什么结果是 0%
ProgramBench 的主要指标是 fully resolved，也就是一个任务里的测试全部通过才算完成。当前 leaderboard 上，九个模型在这个指标上都是 0%。
参与测试的模型包括 Claude、GPT、Gemini 等系列，统一使用 mini-SWE-agent 作为基线 agent。Claude Opus 4.7 在 almost resolved 指标上表现最好，大约有 3.0% 的任务通过了至少 95% 的测试；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。
这说明今天的大模型加一个轻量级 agent，还无法从零重建完整软件。即使是最简单的任务，也很难做到所有细节都完全对齐。
但也要注意：这次测试用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。换成更强的 coding agent、更多工具链支持、更长时间的探索流程，结果可能会提高。所以这个结果更准确的说法是：当前模型加轻量 agent，还不足以稳定完成完整软件重建。
fully resolved 和 almost resolved 是什么意思
读 ProgramBench 的结果时，最容易误解的是这两个指标。
fully resolved 是最严格的指标：一个任务里的所有隐藏测试都通过，才算完整解决。只要还漏掉一个边界条件、一个报错格式、一个命令参数行为，就不能算 fully resolved。
almost resolved 则更像“接近完成”：如果一个任务至少通过了 95% 的测试，就算进入 almost resolved。它能反映模型有没有把大部分行为做出来，但还不能代表程序已经可以替代原软件。
这也是为什么 0% 要分开看。fully resolved 的 0% 说明模型还无法完整交付；almost resolved 的差距则能看出哪些模型已经在部分任务上接近复刻成功。比如 Claude Opus 4.7 的 almost resolved 约为 3.0%，说明它确实在少量相对简单的任务上更接近完成，但距离稳定重建完整软件仍然很远。
为什么 mini-SWE-agent 会影响测试结果
这次测试使用统一的 mini-SWE-agent，好处是公平：不同模型都跑在同一套轻量 agent 框架里，结果更容易横向比较。
但它也会限制上限。完整软件重建不只取决于模型本身，还取决于 agent 是否会规划探索策略、是否能管理长期任务、是否会自动生成测试、是否能反复定位失败原因、是否能整理项目结构。
mini-SWE-agent 更像一个统一基线，而不是最强工程环境。Claude Code、Codex 这类更完整的 coding agent，通常会提供更强的工具调用、上下文组织、任务拆解和多轮修复能力。如果换成这些工具，结果可能会更好。
所以 ProgramBench 这次结果更适合理解为：当前模型在轻量 agent 环境下还做不到完整软件重建。它不是在证明“模型永远做不到”，也不是在完整评估所有商业 coding agent 的上限。
它和 SWE-bench 的差别
SWE-bench 已经是 AI 编程领域里很重要的基准。它让模型在真实 GitHub 仓库里读 issue、改代码、提交补丁，用来测试模型解决真实 bug 的能力。
但 SWE-bench 本质上仍然是在已有项目上修车：车还在，技术栈、目录结构、代码组织、架构设计都已经有人完成了。模型只需要找到问题，把坏掉的零件修好。
ProgramBench 更接近重新造车：你只知道这个车应该有什么行为，看到红灯会停、遇到行人会鸣笛，剩下的结构、语言、模块、构建方式，全都要自己决定。
这就是为什么它难得多。它不再只考局部补丁能力，而是在考软件架构、系统推理、行为探索、自动测试、多轮纠错和长期工程设计。
可以用一张表来理解两者差别：
| 维度 | SWE-bench | ProgramBench |
|---|---|---|
| 起点 | 已有 GitHub 仓库和 issue | 已编译可执行文件和使用文档 |
| 是否给源码 | 给源码 | 不给源码 |
| 主要任务 | 修复已有项目里的 bug | 从行为重新实现一个完整程序 |
| 技术栈 | 原项目已经确定 | 模型自己选择 |
| 项目结构 | 原项目已经存在 | 模型自己设计 |
| 测试方式 | 提交补丁后跑测试 | 用隐藏行为测试验证复刻程度 |
| 主要考点 | 读代码、定位问题、补丁修复 | 行为探索、系统抽象、架构设计、完整实现 |
这也是为什么 ProgramBench 更适合被看作下一阶段 AI Coding 的目标：它把“修现有代码”推进到了“重建完整软件”。
0% 并不等于安全
看到 0%，很多人的第一反应可能是：程序员饭碗暂时保住了。
短期看，这句话没错。今天的大模型还不能稳定完成完整软件工程，尤其是在没有源码、没有测试用例、没有项目结构的情况下。需求澄清、架构设计、长期维护、安全控制、团队协作、业务理解，仍然是人类软件工程师的重要优势。
但如果把 0% 理解成“AI 编程到头了”，就太乐观了。
ProgramBench 真正改变的是问题定义。以前大家知道 AI 可以补代码，也知道 AI 可以修 bug，但“从一个可执行文件和文档重建完整软件”这件事没有被清楚地放到统一赛道里。现在它被做成了 200 道题、统一评测、统一排名。
这意味着模型公司、agent 公司、开发工具公司都知道下一步该往哪里发力：让 AI 从写代码片段，进化到维护、重建和交付完整软件系统。
为什么要断网和防作弊
ProgramBench 的设计里有一个细节很重要：它要防止模型作弊。
早期测试中，模型会尝试直接从 GitHub 找源码，或者通过包管理器下载包含源码的包，甚至去系统缓存目录里翻找已经下载过的软件包。这样当然会破坏测试目的，因为问题就不再是“能不能从行为重建软件”，而是“能不能找到原始源码”。
所以 ProgramBench 使用了沙箱和断网环境，不允许访问互联网，也不允许反编译、反汇编或读取可执行文件内容。模型只能执行程序，观察行为，再自己实现。
这个限制让测试更干净，也更接近它真正想回答的问题：大语言模型能不能从程序行为和文档出发，自己构建一个可运行的软件项目。
更值得警惕的是代码形态变化
ProgramBench 还有一个比 0% 更值得软件工程师思考的发现：模型生成的代码往往不像人类工程师会写的项目。
公开材料里提到，模型倾向于生成更少的文件、更浅的目录、更少的函数，以及更长的单个函数。也就是说，它可能写出一个巨大的、能跑的脚本，而不是一个结构清晰、便于人类维护的软件工程项目。
从传统软件工程角度看，这通常是很差的代码。文件太少、函数太长、抽象不足、模块边界不清，都会让人类难以维护。
但问题在于，AI 未必需要按照人类维护代码的方式写代码。
人类强调抽象、命名、目录结构和模块边界，主要是因为人类记忆有限、团队需要协作、代码需要长期复用。AI 如果可以用更长上下文、检索系统和自动测试反复重写代码，它可能并不那么需要人类熟悉的这些工程规范。
这会带来一个很现实的风险：未来 AI 写出的软件也许能跑、甚至很快，但人类越来越难插手维护。
程序员真正要升级什么
ProgramBench 的结果对程序员不是简单的好消息，也不是简单的坏消息。
短期看，完整软件工程仍然很难，程序员不会因为这次 benchmark 立刻失业。尤其是架构判断、需求澄清、安全把控、质量验收和业务理解，仍然需要人类负责。
长期看，程序员的工作会继续上移。真正危险的不是“不会写代码”的人，而是只会写代码、但不会定义问题、验证结果、组织工具链和控制风险的人。
未来的软件工程师可能更像：
- 需求定义者：把模糊业务问题变成可执行目标。
- 系统验收者：判断 AI 生成结果是否真的满足需求。
- 工具链组织者：组合模型、agent、测试、部署和监控。
- 质量负责人：控制安全、可维护性、边界条件和长期风险。
- 业务和技术之间的翻译者：把真实问题转成工程系统能处理的约束。
如果 AI 真的从代码助手变成完整软件工程师，人类程序员的价值就不再只是亲手写每一行代码，而是定义什么值得写、怎样算写对、哪里不能出错。
小结
ProgramBench 的 0% 不是终点，而是新阶段的起点。
它说明今天的大模型还不能从零稳定重建完整软件系统；但它也把下一代 AI Coding agent 的目标定义得非常清楚：从局部补丁走向完整项目，从代码片段走向系统交付。
对程序员来说，短期可以松一口气，但长期不能只盯着“AI 现在还不行”。更重要的是尽快把自己从代码执行者升级为问题定义者、结果验收者和风险控制者。
真正值得紧张的不是 AI 今天考了 0%，而是题目已经摆出来了。