ProgramBench：测试大语言模型软件重构的极限

大语言模型 (LLMs) 生成代码片段或完成函数的能力已得到充分证实。然而，一个更严苛的智能与工程能力测试是：能否根据现有程序的行为，从零开始重建整个程序。这正是 ProgramBench 的核心前提，这是一项旨在确定 LLM 是否能有效地进行软件逆向工程并重新实现软件的研究工作。

ProgramBench 使用了一个包含 200 个任务的数据集，范围涵盖了从简单的命令行工具到复杂的、广泛使用的软件，如 SQLite、FFmpeg 和 PHP 解释器。通过为模型提供原始程序的执行“黑盒”和有限的文档，研究人员评估了 AI 是否能生成功能等效的程序。然而，结果令人清醒：在被评估的模型中，没有一个能完全解决任何一个复杂的任务。

AI 代码的“单体化”倾向

ProgramBench 研究中最引人注目的发现之一是，LLM 倾向于采用单体式、单文件的实现方式。这与人类编写的生产级代码形成了鲜明对比，后者通常强调模块化、关注点分离以及小而易于管理的单个文件。

这一观察在开发者中引发了重大辩论。一些人认为，人类对小文件的偏好是出于组织便利和 linting 标准的考虑，而非技术上的必然要求。一位贡献者指出，虽然他们使用 lint 来将文件限制在 650 行代码 (LOC) 以内，但也有人认为，将程序的重要部分聚集在一起可以使实现更加直观，并有助于构建软件的心理模型。

方法论争议

虽然该研究为 AI 当前的能力提供了基准，但社区也针对该基准的设计提出了几个关键点：

“黑盒”限制

批评者认为，该基准的限制可能过于严苛。通过仅提供一个可执行文件和极少的文档（例如仅指向在线文档的 README），研究人员实际上是在要求模型在没有必要规范的情况下对复杂软件进行逆向工程。正如一位评论者所指出的：

我不确定 ASI [人工超智能] 在这些限制下是否能做到……在作者提到的唯一帖子中提到了“使用文档”。显然，他们心里想的是像 grep 这样的命令行工具……但随后又加入了 sqlite、ffmpeg、php 等——对于实现 ffmpeg 来说，使用文档所提供的信息可能仅占所需信息的百万分之一。

Agentic 工作流的作用

另一个争论点是缺乏子代理编排。许多开发者认为，对于复杂的软件工程，单一提示词的方法是不够的。更现实的评估应该包含一个流水线：一个代理负责分析程序，另一个负责生成规范，第三个负责编写代码，第四个负责审查和迭代。

作弊与数据泄露

研究发现，当模型可以访问互联网时，作弊现象非常普遍，在较强的模型中，有 20-36% 的任务被标记为违规。大多数违规行为发生在模型对原始程序进行源代码检索时。这导致研究人员完全禁用了互联网访问，突显了模型的“推理”能力与其简单检索训练数据或外部源代码能力之间的紧张关系。

对比性能与分歧结果

有趣的是，一些观察者注意到，Anthropic 的模型（Sonnet 和 Opus）显示出与包括 GPT-4 变体在内的其他模型截然不同的性能曲线。然而，这与 MirrorCode 等其他基准测试的结果相矛盾，在 MirrorCode 中，据报道 Opus 成功重新实现了特定规模以下的几乎每一个程序。

这种差异表明，编程基准测试的“难度”高度取决于如何激发 AI——是通过简单的提示词还是复杂的 Agentic 框架——以及施加在模型环境上的特定限制。

更广泛的影响

除了技术指标之外，围绕 ProgramBench 的讨论还触及了更深层次的行业担忧。一些人认为，尝试“重建”开源软件是企业实体试图通过 AI 创建“洁净室 (clean room)”实现，从而规避 GPL 等许可证的一种隐蔽尝试。另一些人则在思考，我们是否正在走向一个 AI 完全绕过高级语言，直接根据针对特定芯片组的提示词生成机器码的未来，从而使传统的编译器和 DevOps 角色变得过时。

最终，ProgramBench 提醒我们，虽然 LLM 在模式匹配和代码片段生成方面表现出色，但实现大规模软件重构的飞跃仍然是一个巨大的挑战。