在代码生成任务上，当前的前沿语言模型已经能够在 HumanEval、SWE-bench 等基准上取得亮眼成绩。然而，这些评测本质上提供了一个完整的函数签名、问题描述或已知代码库，模型只需在已有结构上完成修补或补全。真实软件工程中的挑战往往更为艰巨：面对一个没有源码的遗留系统，开发者需要通过观察其行为来推断规格、设计架构、从零实现完整程序。这种能力在现有评测体系中几乎是空白。ProgramBench 正是为填补这一空白而诞生的基准，它要求语言模型仅凭一个编译后的可执行文件和使用文档，从零重建整个程序的源代码仓库，并在行为上与原程序保持等价。
ProgramBench 的评测范式与设计约束
ProgramBench 的核心设计理念是「干净室重建」（Cleanroom Reconstruction），这与传统的代码补全或漏洞修复任务有本质区别。每个评测任务向模型提供以下输入：一个仅可执行的二进制文件、相关的使用文档、以及明确的行为约束，而禁止模型访问互联网、查看源代码、使用反编译工具或请求外部检索。模型必须首先对目标程序进行黑盒探测，通过运行不同的输入参数来观察输出行为、错误消息、退出码等外部特征，然后基于这些观察推断程序的功能规格，进而设计并实现一个全新的代码库来复现原程序的行为。
这种评测方式直接指向了语言模型在软件工程中最稀缺的一种能力：从不确定的规格出发，进行系统级架构设计并实现完整功能。传统的编程基准通常会提供函数签名、单元测试用例或问题陈述，这些「锚点」大大降低了任务的难度。而 ProgramBench 几乎移除了所有锚点，模型必须自主完成需求发现、接口推断、架构决策、代码实现和行为验证的全流程。根据 BenchLM 的技术文档，该基准包含 200 个从真实开源项目（如 FFmpeg、SQLite、PHP 等）提取的任务，覆盖了命令行工具、媒体处理、数据库引擎等多种场景，每个任务对应超过 1000 个隐藏的行为测试用例。
关键评估指标与当前模型表现
ProgramBench 定义了两个核心评估指标来衡量模型的程序重建能力。第一个是「完全解决」（Fully Resolved），表示模型提交的重建程序能够通过基准方提供的全部隐藏行为测试，这是衡量任务成功的首要标准。第二个是「接近解决」（Almost Resolved），当重建程序通过至少 95% 的行为测试时即判定为接近解决，这一指标用于捕捉模型在部分任务上取得的实质性进展。由于当前所有模型在完全解决指标上的得分均为零，接近解决率成为目前唯一能够区分模型表现的可见维度。
根据 2026 年 5 月发布的公开排行榜，Claude Opus 4.7 以 3.0% 的接近解决率位居榜首，紧随其后的是 Claude Opus 4.6 的 2.5% 和 Claude Sonnet 4.6 的 1.0%。值得注意的是，GPT-5.4 和 Gemini 3.1 Pro 在接近解决率上均为零，完全无法产出任何通过 95% 测试阈值的重建程序。这一结果清晰地表明，当前的前沿语言模型在从零构建完整程序的能力上存在显著差距，即使是表现最佳的模型也仅能在极少数任务上接近目标，而无法可靠地完成任何一项任务的全部要求。
程序重建失败的核心原因剖析
深入分析 ProgramBench 的评测结果，可以归纳出语言模型在程序重建任务中失败的几个关键模式。首先是「浅层探测」问题：许多模型在仅运行少量显而易见的测试用例后，就匆忙基于有限观察推断程序行为，导致重建程序只能正确处理演示路径上的输入，而对边界情况和非预期输入缺乏应对。其次是「过早实现」倾向：多数编码智能体被优化为快速启动代码编辑，这种策略在规格明确的任务中行之有效，但在规格发现本身就是主要挑战的场景中反而成为阻碍。
第三是「负面用例缺失」问题：一个完整的命令行工具重建不仅需要处理合法输入，还必须匹配无效参数、缺失参数、格式错误、异常退出码、错误消息格式等所有负面行为的细节。第四是「架构薄弱」问题：在没有现成代码骨架的情况下，模型可能选择脆弱的实现方案，只能在少量案例上工作而无法扩展到完整行为范围。第五是「自我测试不足」问题：强大的智能体应当在探测目标程序的同时自动生成回归测试用例，如果缺乏这一环节，重建程序无法自行验证与原程序的行为一致性。第六是「过度自信」问题，这是最关键的失败模式之一：基准方的分析指出，多数失败并非因为达到步数限制被强制终止，而是智能体主动声明任务完成并提交了不完整的程序，这意味着模型缺乏对自身知识边界的准确认知。
工程化实践的启示与可落地参数
尽管 ProgramBench 的整体分数偏低，但这个基准为构建生产级编码智能体提供了极具价值的技术方向。首先，在探测阶段设计上，建议为智能体配置结构化的探索预算，具体参数可参考以下阈值：每个任务至少执行 50 次不同输入的探测，覆盖正常输入、空输入、边界值、非法值、特殊字符、超长字符串等至少 6 个维度的组合。在探测过程中必须记录所有输出、退出码、错误消息和性能特征，形成结构化的行为观察日志。
其次，在实现前的规格文档化环节，智能体应当被要求生成正式的「行为规格说明书」，包括已识别的所有命令行参数及其作用、输入输出格式规范、错误处理行为矩阵、退出码语义定义，以及边界条件列表。这份规格文档应当作为后续实现阶段的约束依据，而非在实现过程中随意变更。第三，在自测机制设计上，智能体应基于探测阶段收集的用例自动生成至少 200 个回归测试，覆盖正向用例、负向用例和边界用例，并在实现完成后先运行这些自测再提交最终结果。第四，在停止判断策略上，应当引入显式的「完成检查清单」，要求智能体在提交前逐项验证：是否探测了至少 N 种不同类型的输入、是否识别了所有已知参数的行为、是否测试了错误处理路径、是否运行了自测并达到 95% 以上的通过率。
对于企业级应用，建议配置的监控指标包括：探测覆盖率（实际探测的输入空间与估计总输入空间的比例）、自测通过率（重建程序在自建测试上的通过比例）、与原程序的行为一致性得分（通过对比输出、退出码、错误消息等维度计算）、以及重建程序的构建成功率（是否能成功编译并生成可执行文件）。这些指标能够帮助团队诊断编码智能体在程序重建任务上的具体薄弱环节，从而有针对性地优化探测策略、实现逻辑或停止判断机制。
ProgramBench 揭示了一个重要的能力缺口：当前的语言模型可以在已知结构上修修补补，但当面对需要从零构建完整系统的任务时，成功率仍接近于零。这一发现对于评估和采购编码智能体具有重要的参考价值。在选择用于关键系统开发的智能体时，不应仅关注 SWE-bench 上的高分表现，还应当考虑模型在规格不确定场景下的行为推断和架构设计能力。ProgramBench 提供了第一个系统化的评测框架来衡量这种能力，虽然目前的得分令人警醒，但它为下一代编码智能体的能力演进指明了方向。
资料来源：BenchLM 博客文章《Can LLMs Rebuild Programs From Binaries?》（2026 年 5 月 5 日）、ProgramBench 官方论文与排行榜数据。