ProjDevBench团队 投稿

量子位 | 公众号 QbitAI

AI编程是一项非常有实用价值的能力，但网络上不时也能看到程序员抱怨AI“听不懂人话”、“难以找到根本问题”，更有直接建议“每次生成代码不要超过5行”的经验分享。

而近期又有很多AI工具声称可以从零快速构建完整代码项目。

所以AI编程智能体真的能从零构建完整软件项目吗？近日一多校联合研究团队针对这一问题进行了探索。

上海交通大学、上海创智学院、加州大学默塞德分校、北京理工大学（按论文作者顺序）联合发布ProjDevBench——首个通过OJ细粒度反馈评估AI编程智能体端到端项目开发能力的基准测试，要求智能体仅凭自然语言需求文档，从零开始构建完整、可运行的软件仓库。

当任务从“补全现有代码”变为“从零构建”时，性能出现断崖式下跌。

结果令人深思：所有智能体总体提交AC率仅27.38%。

该研究得出的结论摘要：

• 六种主流编程智能体（Cursor、GitHub Copilot、Claude Code等）的总体提交AC率仅为27.38%，在从零构建任务中性能大幅下滑。

• OJ提供的细粒度诊断反馈（编译错误（CE）、运行时错误（RE）、超时（TLE）、内存超限（MLE）、答案错误（WA）等）是评估端到端开发能力的关键组成部分，远优于传统的pass/fail二元判定。

• 交互轮次与性能呈强负相关（-0.734），智能体在遇到困难时陷入低效试错循环，而非通过反思实现突破。

现有基准测试如HumanEval、MBPP聚焦于函数级代码生成，SWE-bench关注issue修复，但真实软件工程需要的远不止这些。当开发者使用Cursor或GitHub Copilot进行“vibe coding”时，他们期望智能体能够：从零设计系统架构、创建和组织多个源文件、配置依赖和构建系统（如CMakeLists.txt）、最终交付一个可编译运行的完整项目。

这种端到端的项目构建能力此前从未被系统性评估过。ProjDevBench填补了这一空白。

与传统基准的本质区别在于：HumanEval等要求智能体补全代码片段，SWE-bench要求修复现有代码库中的bug，而ProjDevBench要求智能体像真正的软件工程师一样，在没有任何初始代码模板的情况下，自主完成从架构设计到多文件编码的全流程。

双重评估机制：OJ测试 + 代码审查

与以往仅返回pass/fail的测试不同，ProjDevBench采用双轨制评估：

OJ执行评分（80%）：通过在线判题系统进行严格的黑盒测试，提供细粒度诊断信号——编译错误（CE）、运行时错误（RE）、超时（TLE）、内存超限（MLE）、答案错误（WA）等。这些信号支持智能体进行迭代调试，模拟真实开发中“编写代码-遇到报错-修改代码”的循环。

代码审查评分（20%）：结合规则脚本和LLM模拟的代码审查，检测OJ测试无法捕捉的问题：是否违反显式规则（如使用禁止的库）、是否存在作弊解法、是否利用测试套件漏洞而非遵循实际约束。

这种设计的核心洞察是：仅靠测试用例无法全面评估代码质量。一个能通过所有测试的解法，可能采用了投机取巧的方式，而非真正理解并遵循问题规范。如下图所示：

任务设计与数据来源

研究团队从上海交通大学ACM班（https://acm.sjtu.edu.cn/home）的在线判题平台精选20道高难度编程项目，涵盖算法、数据结构、解释器、管理系统、存储组件等8大类别。

这些题目经过三阶段筛选：

初始收集：从约2,800道候选题目中筛选

范围过滤：保留需要多文件实现、模块组织、构建配置的项目级任务，排除纯算法单文件题目，剩余约100道

质量过滤：选取规范清晰、测试套件完善、难度非平凡的题目，最终保留20道

两种任务模式：

• Easy模式（有代码库）：提供部分代码，要求补全项目

• Hard模式（无代码库）：仅提供自然语言规范，要求从零构建

人类参考解法平均包含约10个源文件，智能体平均需要138轮工具调用、消耗4.81M tokens才能完成一道题目，最复杂的任务需要超过两小时。

实验结果解读

研究团队评估了六种主流编程智能体：Cursor、GitHub Copilot、Claude Code、Augment、Codex CLI、Gemini CLI，搭配GPT-5、Claude Sonnet 4.5、Gemini 3 Pro等前沿模型。

整体表现：Codex + GPT-5取得最高综合得分77.85，但所有智能体的总体提交AC率仅为27.38%。

从零构建时性能断崖式下跌：这是最关键的发现。当任务从Easy（有代码库）变为Hard（无代码库）时，大多数配置出现显著性能下降。例如：

• GitHub Copilot + Sonnet-4.5：71.10 → 36.63

• Gemini CLI + Gemini-3-Pro：74.57 → 35.53

• Codex + Sonnet-4.5：66.07 → 31.88

这表明当前智能体擅长在现有代码基础上进行修补，但缺乏从零开始进行宏观架构设计的能力。

失败模式深度分析

研究团队对所有提交进行了系统性分析，揭示了智能体的核心短板：

提交状态分布：

Accepted：27.38%

Wrong Answer：41.86%

Time Limit Exceeded：13.91%

Runtime Error：7.01%

Compile Error：4.52%

Memory Leak：3.51%

规范理解偏差：智能体经常生成语法正确但遗漏关键业务逻辑的框架代码。在火车票管理系统任务中，所有智能体都实现了用户管理和列车查询，却遗漏了座位管理系统。在扫雷任务中，智能体访问了3,789个安全格子中的3,825个，表明实现不完整而非逻辑错误。

边界情况处理薄弱：大量运行时错误源于空指针解引用、数组越界等问题。在map实现中，红黑树的旋转函数缺乏空指针检查；在Bookstore任务中，所有智能体都未能通过隐藏测试点，暴露了对空字符串、文件I/O异常、嵌套场景的处理不足。

时间复杂度分析缺失：在ICPC管理系统任务中，智能体在每次解冻操作后重新排序所有队伍，得到O(K×N log N)的解法，而正确做法是利用排名变化的局部性实现O(K log N)。智能体倾向于使用熟悉但次优的模式，而非分析问题特性进行针对性优化。

资源管理局限：在BASIC解释器任务中，当std::stoi抛出异常时，已分配的表达式对象未被释放，导致内存泄漏。智能体处理显式错误路径，却忽略正常操作中可能出现的异常。

交互长度与性能的负相关

研究团队发现了一个反直觉的现象：智能体的交互轮次越多、消耗的token越多，最终得分往往越低。

• Tokens与得分的相关系数：-0.734

• 交互轮次与得分的相关系数：-0.668

• 交互轮次与token消耗的相关系数：0.898

这意味着当智能体遇到困难时，它们往往陷入低效的“尝试-报错-再尝试”死循环，无法像人类专家那样通过深度思考找到更优解。增加的token主要来自重复的交互轮次，而非少量但深入的长推理步骤。

静态代码复杂度（文件数量、修改行数）与性能的相关性较弱，表明任务难度主要体现在延长的交互和降低的性能上，而非直接由代码规模决定。

代码审查的独特价值

除执行结果外，代码审查揭示了智能体在软件开发工作流理解上的盲点：

版本控制误解：智能体经常在本地修改代码并创建commit，却未push到远程仓库，导致提交不完整。这表明智能体隐式假设“写代码=完成任务”，忽略了进度必须通过版本控制显式记录和提交的要求。

规范遵从失败：构建系统配置错误、生成错误名称的可执行文件、使用禁止的标准库头文件、遗漏必需文件、修改受保护的模板。这些问题揭示了智能体将规范要求视为次要于功能正确性的倾向。

这些发现表明，智能体尚未将软件开发理解为一个结构化的工作流程，而仅仅是代码生成任务。

总结与意义

ProjDevBench首次证实了当前AI编程智能体在处理真实、复杂的端到端软件开发任务时仍处于初级阶段。它们擅长局部代码修补，但在全局架构设计、时间复杂度优化、资源管理及复杂逻辑推理上尚未达到可用标准。

学术贡献：

• 提出首个端到端提供细粒度反馈的项目开发基准，要求智能体从零构建完整可运行的软件仓库

• 建立结合OJ细粒度反馈与LLM代码审查的双重评估协议

• 系统性揭示智能体在规范对齐、边界处理、复杂度优化、资源管理等方面的失败模式

实际意义：

• 为评估和改进下一代自主软件开发智能体提供了更贴近真实工程场景的标准

• 明确了从“代码补全工具”到“软件工程师”的能力鸿沟

• 指出了未来研究方向：如何让智能体在交互中更有效地利用反馈信号，从单纯的“试错”转向真正的“推理”