ProjDevBench: Benchmarking AI Coding Agents on End-to-End Project Development
核心思想
现有 AI 编程基准（SWE-bench、HumanEval 等）只测试修补 bug或写函数片段，不测试 AI 能否从零构建完整软件项目。
ProjDevBench 是首个端到端项目开发基准：
- 输入：自然语言需求规格
- 输出：多文件可执行仓库（含 CMakeLists.txt 构建配置）
- 评估：Online Judge 执行测试 + LLM 代码审查
- 结果：6 个主流 AI 编程智能体的整体通过率仅 27.38%
背景知识
现有编程基准的局限
| 基准 | 任务类型 | 局限 |
|---|---|---|
| HumanEval | 单函数补全 | 不涉及项目结构 |
| SWE-bench | 修复已有仓库 bug | 不需要从零设计 |
| MBPP | 简单编程题 | 算法题，非工程 |
| ProjDevBench | 从零建项目 | 全流程：设计→编码→构建→测试 |
真实软件开发 vs 写函数
| 方面 | 写函数 | 建项目 |
|---|---|---|
| 文件数 | 1 | 多个（.h/.cpp/CMakeLists.txt） |
| 架构设计 | 无 | 需要模块划分 |
| 构建系统 | 无 | CMake 配置 |
| 性能约束 | 通常无 | 时间/内存限制 |
| 边界处理 | 简单 | 必须全面 |
| 资源管理 | 通常无 | 内存泄漏/异常安全 |
方法详解
1. 问题收集流水线（三阶段）
Stage I：初始收集
从大型 OJ 平台（本科计算机科学教育用）采集约 2800 个候选题目。
Stage II：范围过滤
仅保留项目级开发任务（多文件实现、显式模块组织、构建系统配置、可复用抽象）。筛选后剩约 100 题。
Stage III：质量过滤
选出 20 个最终题目，要求：
- 清晰的需求规格
- 全面的测试用例（覆盖功能和边界）
- 非平凡难度
- 无法通过捷径/取巧解决
2. 最终数据集
20 题，8 类：
| 类别 | 题数 | 示例 |
|---|---|---|
| 算法 | 3 | 排序、搜索 |
| 管理系统 | 3 | 火车票管理、ICPC 管理 |
| 游戏 | 1 | 扫雷 |
| 解释器 | 4 | BASIC 解释器、Mini-Aidiv-N |
| 汇编 | 1 | 汇编模拟器 |
| 数据结构 | 4 | int2048 大整数、B+Tree |
| 存储 | 2 | 数据库存储引擎 |
| 优化 | 2 | 性能优化问题 |
两种模式：
- 项目创建：无初始代码，从零构建
- 项目补全：给部分代码框架，补全剩余部分
3. 评估协议
3.1 执行测试（80% 权重）
通过 Online Judge 平台自动评测：
\[S_\text{raw} = \sum_{i=1}^{N} w_i \cdot \mathbf{1}[\text{test case } i \text{ passed}]\] \[S_\text{exec} = \frac{S_\text{raw}}{\sum_{i=1}^{N} w_i} \times 100\]其中 $w_i$ 是每个测试用例的权重（根据重要性/难度设定）。
细粒度反馈信号：
| 状态 | 含义 |
|---|---|
| AC（Accepted） | 通过 |
| WA（Wrong Answer） | 答案错误 |
| TLE（Time Limit Exceeded） | 超时 |
| MLE（Memory Limit Exceeded） | 超内存 |
| RE（Runtime Error） | 运行时错误 |
| CE（Compile Error） | 编译错误 |
| Memory Leak | 内存泄漏 |
每题有独立的时间限制（0.5-40 秒）和内存限制（6-6144 MiB）。
3.2 代码审查（20% 权重）
两层审查：
规则检查（自动化 Python 脚本）：
ensure_gitignore_contains：检查 .gitignoreforbid_pattern_in_files：禁止特定模式（如禁用库）ensure_files_exist：必要文件是否存在ensure_cmake_outputs_code：CMake 构建是否正确ensure_files_unchanged：不可修改的文件是否被改动
LLM 审查（定性评估）：
llm_as_a_judge：检查规格合规性和代码质量
3.3 最终分数
\[S_\text{final} = 0.8 \times S_\text{exec} + 0.2 \times S_\text{cr}\]功能正确性占 80%——能跑对是最重要的。
4. 评估环境
Docker 容器（Ubuntu 24.04）：
- GCC-13, G++-13, CMake
- Python 3.12
- 8 GB 内存，4 核 CPU
- 完整网络访问（用于智能体操作）
评估流水线：
- 加载题目配置
- 初始化 Docker + Git 仓库
- 给智能体标准化提示
- 智能体自主编码 + 提交 OJ
- 收集判定结果 + 代码审查
5. 被评估的智能体
| 智能体 | 模型后端 |
|---|---|
| Augment | GPT-5, Sonnet-4.5 |
| Codex CLI | GPT-5, Sonnet-4.5 |
| Gemini CLI | Gemini-3-Pro-Preview |
| Cursor | GPT-5, Sonnet-4.5, Gemini-3 |
| GitHub Copilot | GPT-5, Sonnet-4.5, Gemini-3 |
| Claude Code | GPT-5, Sonnet-4.5, DeepSeek-V3.2, GLM-4.6, Kimi-k2 |
实验结果
主要排名
| 智能体 | 模型 | 最终分 | 执行分 | 审查分 |
|---|---|---|---|---|
| Codex | GPT-5 | 77.85 | 76.73 | 82.31 |
| Cursor | Gemini-3 | 75.32 | 72.52 | 86.51 |
| Augment | GPT-5 | 72.35 | 72.13 | 73.26 |
| Cursor | GPT-5 | 71.85 | 69.26 | 82.23 |
| Claude Code | Sonnet-4.5 | 68.87 | 63.76 | 89.31 |
| Copilot | GPT-5 | 61.73 | 58.64 | 74.06 |
Claude Code 的代码审查分最高（89.31） 但执行分较低 → 代码规范好但功能不够完整。
整体提交状态分布
| 状态 | 数量 | 占比 |
|---|---|---|
| AC（通过） | 484 | 27.38% |
| WA（答案错误） | 740 | 41.86% |
| TLE（超时） | 246 | 13.91% |
| RE（运行时错误） | 124 | 7.01% |
| CE（编译错误） | 80 | 4.52% |
| Memory Leak | 62 | 3.51% |
| MLE（超内存） | 24 | 1.36% |
不到三分之一的提交通过——AI 编程智能体距离可靠的项目开发还很远。
难度影响
| 难度 | Codex+GPT-5 执行分 | Copilot+Sonnet-4.5 执行分 |
|---|---|---|
| 简单（有部分代码） | 79.24 | — |
| 困难（从零开始） | 69.22 | 36.63 |
从零开始比补全已有代码难得多——Copilot 下降了近 35 分。
交互长度与性能的关系
| 变量对 | Spearman $\rho$ | 含义 |
|---|---|---|
| Token 消耗 vs 分数 | -0.734 | Token 越多，分越低 |
| 交互轮次 vs 分数 | -0.668 | 轮次越多，分越低 |
| 轮次 vs Token | +0.898 | 高度正相关 |
关键发现：更多交互不代表更好结果——反而意味着智能体在”挣扎”。难题触发冗长的调试循环，但智能体往往无法将调试转化为进展。
开源模型对比（Claude Code 框架下）
| 模型 | 最终分 |
|---|---|
| Sonnet-4.5 | 68.87 |
| GLM-4.6 | 57.95 |
| Kimi-k2 | 52.77 |
| DeepSeek-V3.2 | 50.33 |
开源模型落后闭源模型 10-18 分。
六大失败模式详析
1. 规格对齐失败（41.86%，最大类）
功能不完整：
- 火车票管理系统：所有智能体都实现了用户管理，但遗漏了关键的座位管理
- 扫雷：智能体只访问了 3789/3825 个安全格子
结构误解：
- int2048：智能体在提交代码中包含了带
main()的测试代码 → 与 OJ 的main()冲突 - Mini-Aidiv-N：Softmax 对整个矩阵求和而非按行 → 准确率 0.02
2. 边界处理缺陷（RE + 部分 WA）
- 空指针解引用（树实现中）
- 数组越界
- 未初始化变量导致段错误
- 子串匹配 vs 精确匹配的混淆（书店系统）
3. 时间复杂度分析不足（13.91%）
- ICPC 管理系统：每次解冻后重新排序所有队伍 $O(K \cdot N \log N)$，而非利用排名局部性 $O(K \log N)$
- 使用
map（$O(\log N)$）而非unordered_map（$O(1)$） - 无缓冲 I/O 导致连锁性能问题
4. 资源管理缺陷（3.51% + 1.36%）
- BASIC 解释器：
std::stoi()抛异常后未释放已分配的表达式对象 → 25 处内存泄漏 - 偏好手动
new/delete而非 RAII 模式 - 防御性编程不完整
5. 高级 C++ 概念不足（4.52%）
- 模板编程：假设类型有默认构造函数
- 命名空间/头文件管理：合并文件时出错
- 开发环境 vs 提交环境的区别处理不当
6. 版本控制和工作流误解
- 本地修改代码但忘记 push 到远程仓库
- 遗漏必要文件
- 违反构建系统规格
代码审查验证
| 指标 | 值 |
|---|---|
| 二元规则验证准确率 | 0.852 |
| Cohen’s $\kappa$（与人类标注一致性） | 0.710（实质性一致） |
| 连续质量评分 | 与人类评分强相关 |
LLM 审查可靠地近似人类判断。
个人思考
- 27.38% 通过率是对 AI 编程能力的清醒评估——在完整项目开发中，AI 还远未达到”自动化程序员”的水平。
- “交互越多，分越低” 是最令人警醒的发现：说明当前智能体缺乏有效的自我纠错能力——遇到困难时陷入低效循环而非策略调整。
- 规格对齐是最大瓶颈（42%）：AI 不是不会写代码，而是不能完整理解需求——这与人类初级程序员的最大问题惊人地一致。
- 复杂度优化失败（14%） 揭示了一个深层问题：AI 善于写”正确但低效”的代码，而高效算法需要对问题结构的深层理解——这目前还是人类的优势。
- 从零建项目 vs 补全代码的巨大差距说明：AI 在有”脚手架”时表现尚可，但架构设计能力严重不足——这正是资深工程师最重要的技能。
- Claude Code 审查分最高但执行分不高：暗示 Sonnet 模型更注重代码规范性但在功能实现上不如 GPT-5——不同模型有不同的”性格”。