阅读论文
代码和网站概述
NL2Repo-Bench 的测试起点位于函数补全和仓库修复基准测试的终点。测试对象接收一个自然语言文档和一个空的工作区，然后必须选择架构、创建所有文件、管理依赖项、实现跨模块行为，并打包一个可安装的 Python 库。在主要评估过程中，源代码、脚手架或测试用例均不可见。最终生成的仓库会被安装到一个受控镜像中，并使用原始项目的上游 pytest 测试套件进行检查。
这 104 个任务涵盖九大类：Web 开发、测试、实用程序库、机器学习、数据分析与处理、数据库交互、网络、批处理文件处理和系统工具。输入文档平均包含约 18,800 个词元。难度根据原始源代码的大小而定：26 个简单代码库，代码量不超过 1,500 行；46 个中等代码库，代码量在 1,500 至 4,000 行之间；32 个困难代码库，代码量超过 4,000 行。候选代码库必须是近期发布的，至少拥有十颗星，并且通过了自身的测试才能被纳入。
规范的生成是通过逆向工程而非自由形式的摘要。抽象语法树扫描器会清点函数、类、签名和位置；标注者会描述项目、环境、文件结构、API 行为和关键实现节点；静态检查会将文档与清点结果进行比较。初步的代理失败结果随后会由资深 Python 工程师进行审查，以便修复文档或容器中的遗漏，而不是将其计入模型失败。
为什么这很重要
代码库的生成会随着时间的推移和文件的增多而累积错误。一个看似合理的解析器实现仍然可能导致评分器出错，打包可能会使原本正确的模块失效，而早期的架构选择可能会导致后续行为无法调和。对隐藏测试结果进行平均可以反映部分功能进展，而完整测试套件的 Pass@1 计数则表明该进展是否最终会转化为可交付的代码库。
该基准测试也明确了信息边界。当论文在 Claude Code 中向 Claude Sonnet 4.5 公开所有隐藏测试时，平均通过率从 40.2% 提升至 59.4%，完全通过的存储库数量也从 3 个增加到 18 个。在这种人为降低的条件下，仍然存在 40 个百分点的差距，这表明缺失的需求只是问题的一部分；协调和大规模实施仍然是制约因素。
贡献
- 从单个需求文档开始正式生成存储库：代理程序不会收到任何脚手架、文档之外的函数签名、源文件或可见的测试。
- 构建了 104 个质量控制的 Python 库任务，涵盖九个类别，规范平均包含 18,800 个标记，难度根据原始存储库的大小进行划分。
- 将每个任务与经过验证的 Docker 镜像和未修改的上游 pytest 行为配对，从而产生基于执行的评估，而不是 LLM 或定性评判。
- 对十二种模型框架配置进行基准测试，并分析长期失效模式，包括提前停止、未完成行为、工具使用分配、上下文压力和迭代限制。
方法与评估
- 候选代码库必须包含 300 至 120,000 行代码，至少有 10 个 GitHub 星标，创建或更新时间不超过三年，包含 pytest 测试，并在精选环境中通过其完整的原生测试套件。
- 标注人员对每个代码库进行逆向工程，生成一个包含四个部分的文档：项目描述、支持、API 使用指南和实现节点。AST 扫描器会清点类、函数、签名和位置，以检查规范覆盖率。
- 人类专家审查签名和行为，静态检查将记录的 API 与源清单进行比较，高级 Python 工程师检查初步代理运行情况，以消除规范或环境故障。
- 评估时，工作区仅包含任务文档。代理程序可以使用其可用工具，无需人工干预或固定的迭代次数限制，然后提交一个软件包，该软件包将被安装到任务的受控测试镜像中。
- 隐藏的上游 pytest 测试套件会执行所有可收集的测试用例，即使出现一些收集错误。每个任务的测试通过率是 104 个任务的平均值；单独的 Pass@1 计数记录了所有测试都通过的任务。
评估指标
平均测试通过率——越高越好。在 104 个生成的代码库中，隐藏的上游 pytest 测试用例通过的平均百分比；这是论文的总体评分。评分范围：[0, 100]。
仓库通过率@1 — 数值越高越好。生成的软件包在一次运行中通过所有上游测试套件的仓库数量。分数范围：[0, 104]。
难度通过率——越高越好。平均测试通过率按原始项目规模划分：简单（不超过 1,500 行代码，26 个任务），中等（1,500–4,000 行代码，46 个任务），困难（至少 4,000 行代码，32 个任务）。分数范围：[0, 100]。
排行榜
所有行都使用相同的 104 个规范和隐藏的上游测试。OpenHands 是默认框架；Claude Code 和 Cursor 变体均已明确标记。Gemini 3 Pro 使用 Cursor，因为论文报告称 OpenHands 中存在代理循环错误。
| # | 模型 | 平均考试通过率（%） |
|---|---|---|
| 1 | 克劳德十四行诗 4.5（克劳德代码） | 40.2 |
| 2 | 克劳德·索内特 4.5 (OpenHands) | 39.9 |
| 3 | 克劳德十四行诗 4.5（光标） | 39.2 |
| 4 | 克劳德·索内特 4（敞开的手） | 37 |
| 5 | Gemini 3 Pro（光标） | 34.2 |
| 6 | DeepSeek-V3.2（OpenHands） | 27.6 |
| 7 | Kimi-K2（OpenHands） | 22.7 |
| 8 | DeepSeek-V3.1（OpenHands） | 22.2 |
| 9 | GPT-5（OpenHands） | 21.7 |
| 10 | Qwen3-235B-指令（OpenHands） | 17.9 |
| 11 | GLM-4.6（OpenHands） | 17.5 |
| 12 | Qwen3-235B-思考（OpenHands） | 13.8 |
阅读结果
在 Claude Code (40.2)、OpenHands (39.9) 和 Cursor (39.2) 三个测试中，Claude Sonnet 4.5 占据了前三名。这一分的差距印证了论文的观点，即对于此模型和设置而言，更换硬件组件的影响远小于更换底层模型的影响。Claude Sonnet 4 以 37.0 的成绩紧随其后，Cursor 中的 Gemini 3 Pro 以 34.2 的成绩位列第三；DeepSeek-V3.2 是 OpenHands 系统中性能最强的，得分为 27.6。
平均测试通过率和完整代码库的成功率呈现出截然不同的结果。排行榜冠军仅完整通过了 104 个代码库中的 3 个，而得分较低的 Claude Sonnet 4 则完整通过了 5 个。对于冠军系统而言，平均通过率从简单任务的 51.8% 下降到中等任务的 44.5%，再到困难任务的 25.1%。因此，该基准测试表明，部分实现普遍存在，但可靠的端到端完成率却非常低，尤其是在原始代码库超过 4000 行之后。
图表
← 返回研究