给AI一个程序,它能从零＂重建＂吗?——ProgramBench:大模型工程能力的终极考验

想象这样一个场景：你把一个编译好的程序（比如一个命令行工具的Linux二进制文件）交给一个程序员，告诉他”请从零开始重新实现这个程序的功能”。这个程序员需要先运行程序、观察它的行为、理解它的功能，然后选择编程语言、设计架构、编写代码、配置构建系统，最终编译出一个行为完全一致的新程序。这对人类程序员来说已经是一个不小的挑战——它考验的不仅是编码能力，更是软件设计的全局思维。

现在，把这个程序员换成AI。它能做到吗？

论文《ProgramBench: Can Language Models Rebuild Programs From Scratch?》提出了ProgramBench——一个全新的基准测试，专门用来评估大语言模型（LLM）及其驱动的软件工程Agent能否从零开始重建一个已有程序。这不是简单的”写一个函数”或”修复一个Bug”，而是要求AI独立完成从需求理解、架构设计到代码实现、编译构建的完整软件工程流程。实验结果既令人振奋又发人深省：最强的模型Claude 3.5 Sonnet仅能通过约20.5%的测试用例，而所有模型的平均通过率更是低至个位数。这意味着，尽管AI在代码生成方面取得了巨大进步，但真正的软件工程能力——架构设计、系统分解、工程决策——仍然是AI尚未跨越的鸿沟。

近年来，评估大模型代码能力的基准层出不穷——HumanEval、MBPP、SWE-bench、LiveCodeBench等。然而，这些基准都有一个共同的局限：它们只测试了软件工程能力的一个侧面，而非全貌。

HumanEval和MBPP测试的是”函数级代码生成”——给定函数签名和文档字符串，生成函数体。这本质上是”填空题”，模型不需要思考架构设计、模块划分或构建配置。SWE-bench测试的是”基于已有代码库的Bug修复”——模型在一个已经存在的代码库中定位和修复问题。这虽然是更复杂的任务，但架构设计已经由原始开发者完成，模型只需要理解现有代码并做局部修改。

ProgramBench要测试的，是这些基准都未能覆盖的能力：从零开始的完整软件构建能力。具体来说，给定一个编译好的程序（如Linux ELF二进制文件或macOS .dmg安装包）和它的文档，AI Agent需要自主完成以下所有步骤：运行程序、理解其功能和行为、选择编程语言和构建系统、设计代码架构、编写源代码、编写构建脚本、编译并验证结果。每一个软件设计决策——从目录结构到错误处理策略——都完全由模型自主做出。

这种”从零重建”的设定，比任何现有基准都更接近真实世界中”从需求出发构建软件”的场景。它迫使模型面对人类程序员在日常开发中不断遇到的核心问题：该用什么语言？代码怎么组织？数据结构怎么选？错误怎么处理？这些架构层面的决策，远比写几行代码更能体现一个”软件工程师”的真实能力。

ProgramBench的评测流程设计精巧而严格。整个流程分为四个阶段：任务构建、Agent执行、功能验证和代码质量评估。

在任务构建阶段，研究者从GitHub上筛选开源仓库，选择那些使用编译型语言（C/C++、Go、Rust、Java等）编写的项目。对于每个选中的仓库，研究者编译出可执行文件（如Linux ELF二进制），并提取项目的README文档。然后，他们编写一组全面的测试用例，覆盖程序的各种功能和边界情况。这些测试用例基于原始可执行文件的行为来编写，确保它们准确反映了程序的预期功能。最终，每个ProgramBench任务包含三个要素：编译好的可执行文件、项目文档和测试套件。

在Agent执行阶段，SWE-Agent（即配备Agent脚手架的LLM）接收可执行文件和文档，通过终端环境与系统交互。Agent可以运行程序来观察其行为，可以创建和编辑文件，可以执行编译命令。Agent的目标是：编写源代码和构建脚本，使得编译出的新程序能够通过尽可能多的测试用例。整个过程中，Agent拥有完全的自由度——编程语言、项目结构、构建系统，一切由它自主决定。

在功能验证阶段，研究者运行Agent生成的代码，将其输出与原始可执行文件的输出进行对比。通过率（Pass Rate）是核心指标——即Agent生成的程序通过了多少比例的测试用例。这个指标直接反映了Agent重建程序功能的完整程度。

ProgramBench的数据集构建过程极为严格，体现了研究者对评测质量的追求。初始阶段，研究者从GitHub上筛选了392个使用编译型语言编写的开源仓库。这些仓库涵盖了多种编程语言（C、C++、Go、Rust、Java等）和多种应用类型（命令行工具、库、系统服务等）。

然而，并非所有仓库都适合作为评测任务。研究者制定了一套严格的筛选标准：项目必须有清晰的文档说明其功能；必须能成功编译为独立的可执行文件；功能不能过于简单（如”Hello World”级别的项目被排除）；也不能过于复杂（如整个操作系统内核级别的项目被排除）；测试用例必须能可靠地验证程序行为。经过多轮筛选和人工审核，最终保留了39个高质量任务，构成了ProgramBench的核心评测集。

这39个任务在多个维度上具有多样性。编程语言方面，覆盖了C、C++、Go、Rust、Java等主流编译型语言。项目规模方面，从几十行的小型工具到数千行的中型项目不等。功能类型方面，包括文本处理、数学计算、文件操作、网络通信等多种类别。这种多样性确保了ProgramBench能够全面评估Agent的软件工程能力，而不是仅仅测试某一种特定类型的编程任务。

论文使用多个主流LLM作为SWE-Agent的后端进行了全面评测，包括Claude 3.5 Sonnet、GPT-4o、Gemini 2.5 Pro、DeepSeek V3等。评测结果揭示了当前AI软件工程能力的真实水平。

Claude 3.5 Sonnet以20.5%的测试通过率领跑所有模型，这意味着平均每个任务它只能通过约五分之一的测试用例。GPT-4o紧随其后，但通过率同样不高。更令人担忧的是，所有模型的平均通过率都处于较低水平，距离”可靠地从零构建软件”还有巨大的差距。

从累积分布图可以更清晰地看到这个差距。大部分任务上，所有模型的通过率都低于50%——也就是说，对于大多数程序，AI重建的版本连一半的功能都无法正确实现。只有极少数相对简单的任务上，模型才能达到较高的通过率。这表明，当前的AI模型在”理解程序功能”和”从零设计实现”之间存在巨大的能力鸿沟。

为什么AI模型在ProgramBench上表现如此不佳？论文通过详细的错误分析，揭示了四个主要失败模式。

根因一：功能理解不完整。许多模型未能充分理解程序的全部功能。它们可能抓住了程序的主要功能，但忽略了边界情况、错误处理或高级特性。例如，对于一个文本处理工具，模型可能实现了基本的搜索替换功能，但忽略了正则表达式支持、编码检测或递归目录遍历等高级特性。这种”理解不完整”直接导致了测试用例的失败。

根因二：架构设计能力不足。即使模型正确理解了程序的功能，它也可能设计出糟糕的代码架构。论文发现，模型生成的代码往往存在过度复杂的抽象层次、不合理的模块划分、或者缺失关键的架构组件（如配置管理、日志系统）。人类程序员在设计架构时会考虑可扩展性、可维护性和代码复用，而AI模型往往只关注”让代码跑起来”，缺乏长远的架构思维。

根因三：构建系统配置困难。这是ProgramBench独有的挑战。在传统的代码生成基准中，模型只需要生成源代码，不需要关心编译和构建。但在ProgramBench中，模型还需要编写正确的构建脚本（如Makefile、CMakeLists.txt、go.mod等）。论文发现，构建配置是模型失败的高频原因之一——模型可能写出了正确的代码，但因为构建脚本错误而无法编译。

根因四：测试驱动迭代不足。人类程序员在开发过程中会不断编译、运行、测试、修改，形成快速的反馈循环。而AI Agent虽然也有终端访问权限，但往往不能有效地利用这个反馈循环。论文发现，许多Agent在生成初始代码后，要么不进行充分的测试，要么面对编译错误时无法有效地定位和修复问题。这种”缺乏迭代”的开发模式严重限制了代码质量的提升。

除了功能正确性，论文还对AI生成的代码质量进行了深入分析。分析维度包括代码复杂度、函数数量、代码行数与原始代码的对比等。

一个有趣的发现是：AI生成的代码往往比原始代码更冗长。在通过至少75%测试用例的解决方案中，AI生成的代码行数平均是原始代码的1.08到1.5倍。函数数量也普遍多于原始代码。这表明AI倾向于”展开”逻辑而非”抽象”逻辑——它可能把一个复杂的函数拆分成多个简单函数，或者用更verbose的方式实现相同的功能。虽然这种风格在某些场景下可能更易读，但也反映了AI在代码抽象和简洁性方面的不足。

另一个重要发现是编程语言选择的偏好。尽管ProgramBench允许Agent自由选择编程语言，但大多数Agent倾向于选择Python等脚本语言，即使原始程序是用C或Go编写的。这种偏好可能源于训练数据中Python代码的占比更高，但也可能导致性能和功能上的差异——例如，Python版本可能无法精确复现C程序的某些底层行为。

一个自然的问题是：ProgramBench和SWE-bench的结果为什么差异如此巨大？在SWE-bench上，顶级Agent已经能达到30-40%以上的解决率，而在ProgramBench上，最强模型仅能通过20.5%的测试用例。这种差距的背后，是两种任务本质上的不同。

SWE-bench是”局部优化”问题。Agent在一个已经设计好的代码库中工作，架构已经确定，编码规范已经建立，只需要定位Bug并修复。这就像在一栋已经建好的房子里修水管——你不需要设计房子的结构，只需要找到漏水的地方并修好。Agent可以通过阅读现有代码来理解架构，通过运行测试来定位Bug，任务的范围是明确且有限的。

ProgramBench是”全局创造”问题。Agent需要从零开始构建整个程序，没有任何现有代码可以参考。这就像在一片空地上建房子——你需要先设计图纸、选择材料、规划布局，然后才能开始施工。每一个决策都影响最终的结果，而错误的早期决策可能导致后期的巨大返工。这种”全局创造”需要的能力——系统思维、架构设计、技术选型——远比”局部优化”更复杂、更难评估。

论文通过对比实验进一步证实了这一点。即使在功能相对简单的任务上，Agent的表现也远不如预期。这表明，瓶颈不在于编码能力（AI已经很强了），而在于软件设计能力（AI还很弱）。编码是”执行”，设计是”决策”——当前的AI擅长执行，但不擅长决策。

ProgramBench的意义在于，它为”AI软件工程师”的能力评估提供了一个更加全面、更加接近真实场景的标尺。

在学术层面，ProgramBench填补了现有代码基准的一个重要空白。它证明了一个关键观点：代码生成能力不等于软件工程能力。一个能在HumanEval上获得90%通过率的模型，可能在ProgramBench上只能通过20%的测试。这个发现对于AI代码能力的研究方向有重要的指导意义——未来的研究不应该仅仅追求”写对代码”，更应该关注”设计好系统”。

在产业层面，ProgramBench为AI编程工具的能力评估提供了一个更加现实的框架。当前，许多AI编程工具（如GitHub Copilot、Cursor等）主要辅助”局部代码修改”，而非”全局系统设计”。ProgramBench的结果表明，AI距离成为真正的”独立软件工程师”还有很长的路要走。这对于产业界合理设定AI编程工具的期望值、避免过度宣传具有重要的现实意义。

在方法论层面，ProgramBench引入的”从零重建”评测范式可以推广到其他领域。例如，”从零重建一个数据管道”、”从零重建一个Web应用”、”从零重建一个机器学习系统”——这些评测可以全面评估AI在不同领域的工程能力，而不仅仅是代码生成能力。

基于ProgramBench的发现，未来的AI软件工程研究有几个关键方向。

方向一：增强架构设计能力。当前的LLM在编码层面已经相当强大，但在架构设计层面仍然薄弱。未来的研究可以探索如何让模型更好地进行系统分解、模块设计和接口定义。一种可能的方法是在训练数据中加入更多的架构设计文档和设计决策记录（ADR），让模型学习人类架构师的思维方式。

方向二：改进反馈循环。ProgramBench的分析表明，AI Agent未能有效利用编译和测试的反馈来迭代改进代码。未来的Agent框架可以设计更智能的反馈机制——例如，自动分析编译错误并生成修复建议，或者通过差异测试（Diff Testing）来发现功能偏差。这种”快速反馈+自动修复”的循环，可以显著提升Agent的代码质量。

方向三：多Agent协作。真实的软件开发通常是团队协作的结果——架构师设计系统，开发者编写代码，测试工程师验证功能。未来的AI软件工程系统可以模拟这种团队协作模式，使用多个专门化的Agent分别负责架构设计、代码实现、测试验证等不同角色，通过协作来完成从零构建的任务。

最后，从”模仿”到”创造”的跨越是最具野心的方向。ProgramBench要求模型”重建”一个已有程序，本质上是一种”模仿”。但真正的软件工程不仅是模仿，更是创造——从模糊的需求出发，创造出前所未有的解决方案。未来的评测基准可以进一步挑战AI的创造能力：给定一个需求描述（而非已有程序），让AI从零设计并实现一个全新的软件系统。这将是对AI软件工程能力的终极考验。

ProgramBench的故事，本质上是一个关于”期望管理”的故事。过去两年，AI代码生成的进步速度令人目眩——从最初的简单函数补全，到如今能够处理整个文件的代码编辑，再到SWE-bench上不断刷新的解决率记录。这些进步很容易让人产生一种错觉：AI即将取代程序员。然而，ProgramBench用冷冰冰的数据告诉我们：AI离”取代程序员”还有很远的距离。

这个发现不是悲观的，而是清醒的。它帮助我们更准确地理解AI在软件工程中的角色定位：AI是一个极其强大的”编码助手”，但它还不是一个合格的”软件工程师”。编码和软件工程之间的差距，就像写字和写小说之间的差距——前者需要的是语言能力，后者需要的是创造力、系统思维和全局视野。AI已经掌握了”写字”的能力，但离”写小说”还有很长的路要走。

更深层次地看，ProgramBench触及了一个关于AI发展的根本问题：从”执行”到”决策”的跨越。当前的大模型在执行层面已经非常强大——给定明确的指令，它们能生成高质量的代码、文本、图像。但在决策层面——面对开放性的问题，需要在多个可行方案中做出权衡和选择时——它们的能力仍然有限。软件架构设计正是这种”决策密集型”任务的典型代表：没有标准答案，需要在多个维度（性能、可维护性、可扩展性、开发效率等）之间做出权衡。

ProgramBench的价值在于，它为这种”决策能力”提供了一个可量化的评测框架。随着评测的深入和方法的改进，我们可以期待AI的软件工程能力逐步提升——从”能写代码”到”能设计系统”，从”能修Bug”到”能建系统”。这个过程可能需要数年甚至更长时间，但每一步的进步都将是有意义的。毕竟，真正的”AI软件工程师”不是一天建成的——就像真正的软件工程师也不是一天练成的。ProgramBench为我们提供了衡量这段旅程的标尺，而这段旅程本身，或许比目的地更加精彩。