研究背景与目的 - 针对AI编程智能体能否从零构建完整软件项目的疑问，多校联合研究团队进行了探索并发布了首个评估基准ProjDevBench [1][2] - 现有基准测试如HumanEval、MBPP聚焦于函数级代码生成，SWE-bench关注issue修复，但真实软件工程需要从零设计系统架构、创建组织多文件、配置依赖和构建系统并交付可运行项目的端到端能力，此前从未被系统性评估 [3][4] 基准测试设计 - ProjDevBench要求智能体仅凭自然语言需求文档，从零开始构建完整、可运行的软件仓库，填补了端到端项目构建能力评估的空白 [2][4] - 基准采用双重评估机制：OJ执行评分占80%，提供编译错误、运行时错误、超时、内存超限、答案错误等细粒度诊断反馈；代码审查评分占20%，检测是否违反显式规则、存在作弊解法或利用测试套件漏洞 [7] - 任务设计从上海交通大学ACM班在线判题平台约2,800道题目中，经多阶段筛选出20道高难度编程项目，涵盖算法、数据结构、解释器等8大类别，并设置Easy（有代码库）和Hard（无代码库）两种模式 [7][8][9] 实验结果概览 - 评估了六种主流编程智能体（Cursor、GitHub Copilot、Claude Code等）搭配前沿模型，所有智能体总体提交AC率仅为27.38% [2][5][10] - 从零构建时性能出现断崖式下跌，当任务从Easy模式变为Hard模式时，多数配置出现显著性能下降，例如GitHub Copilot + Sonnet-4.5从71.10分降至36.63分，Gemini CLI + Gemini-3-Pro从74.57分降至35.53分 [11] - Codex + GPT-5配置取得最高综合得分77.85分 [10] 智能体失败模式分析 - 提交状态分布显示，答案错误占比最高，达41.86%，其次是超时占13.91%，运行时错误占7.01%，编译错误占4.52%，内存泄漏占3.51% [13] - 智能体存在规范理解偏差，经常生成语法正确但遗漏关键业务逻辑的框架代码，例如在火车票管理系统任务中所有智能体都遗漏了座位管理系统 [13] - 边界情况处理薄弱，大量运行时错误源于空指针解引用、数组越界等问题，在Bookstore任务中所有智能体都未能通过隐藏测试点 [13] - 时间复杂度分析缺失，在ICPC管理系统任务中智能体得到O(K×N log N)的次优解法，而非正确的O(K log N)解法 [14] - 资源管理存在局限，在BASIC解释器任务中，当std::stoi()抛出异常时，已分配的表达式对象未被释放，导致内存泄漏 [14] 交互行为与性能关联 - 交互轮次与性能呈强负相关，相关系数为-0.734，token消耗量与得分的相关系数为-0.668，表明智能体在遇到困难时陷入低效试错循环，而非通过反思实现突破 [5][15] - 交互轮次与token消耗量高度相关，相关系数达0.898，增加的token主要来自重复的交互轮次，而非少量深入的长推理步骤 [15] 代码审查揭示的深层问题 - 智能体对软件开发工作流理解存在盲点，例如经常在本地修改代码并创建commit，却未push到远程仓库，导致提交不完整 [16] - 智能体存在规范遵从失败，包括构建系统配置错误、生成错误名称的可执行文件、使用禁止的标准库头文件、遗漏必需文件、修改受保护的模板等 [16] 研究结论与意义 - 研究首次证实当前AI编程智能体在处理真实复杂的端到端软件开发任务时仍处于初级阶段，擅长局部代码修补，但在全局架构设计、时间复杂度优化、资源管理及复杂逻辑推理上尚未达到可用标准 [17] - 该基准为评估和改进下一代自主软件开发智能体提供了更贴近真实工程场景的标准，明确了从“代码补全工具”到“软件工程师”的能力鸿沟，并指出未来研究方向应让智能体更有效地利用反馈信号，从“试错”转向“推理” [18]