从Debugger到Developer : 低代码时代新基准NoCode-bench，SWE-Bench作者力荐

当前，大型语言模型（LLM）在软件工程领域的应用日新月异，尤其是在自动修复 Bug 方面，以 SWE-bench 为代表的基准测试展示了 AI 惊人的潜力。然而，软件开发远不止于修 Bug，功能开发与迭代才是日常工作的重头戏。

那么，当我们将任务从「修复一个已知问题」升级为「根据软件文档添加一个新功能」时，当今最强的 AI 模型表现如何？

近日，由浙江大学牵头，联合香港科技大学、德国斯图加特大学等机构的研究者们，共同推出了一个全新的评估基准 NoCode-bench。这项研究直面真实世界中更为常见的「自然语言驱动功能添加」任务，意外发现：即便是当前最佳 LLM，在此任务上的成功率也仅有两成，揭示了当前 AI 在真实软件开发能力上的巨大挑战。

• 论文标题: NoCode-bench: A Benchmark for Evaluating Natural Language-Driven Feature Addition

• 论文链接: https://arxiv.org/abs/2507.18130

• 项目开源链接: https://github.com/NoCode-bench/NoCode-bench

• 排行榜链接: https://nocodebench.org

现有的基准测试（如 SWE-bench）大多聚焦于根据 Bug 报告（Issue Description）来修复代码，更像是「封闭式问答」。而 NoCode-bench 指出未来的软件开发可能完全由软件文档驱动，提出了一个更开放、更接近真实开发协同的评估场景：

开发者更新了软件文档，AI 能否自动理解文档变更，并完成相应的代码修改以实现新功能？

在软件维护成本中，约 60% 用于功能性增强，而非简单的缺陷修复。 NoCode-bench 正是为此而生，它旨在弥补现有评测基准的空白，推动 AI 从「修理工」向「开发工程师」的角色转变。

SWE-bench 主要作者、普林斯顿大学研究科学家 Ofir Press 也推荐了该评估基准。

NoCode-bench 是如何构建的？

构建 NoCode-bench 要求识别开发者认可功能添加。与直接从 GitHub Issues 中挖掘数据不同，NoCode-bench 提出从开发者维护的发行说明（Release Notes）出发来实现这一目标。发行说明中通常包含由项目核心开发者人工确认的「功能增加」条目，为筛选高质量、真实的功能添加实例提供了可靠的源头，有效减少了噪音。

Seaborn 项目发行说明节选

为了确保任务的真实性和高质量，研究团队设计了一套严谨的构建流程。这套流程以发行说明为起点，包含 5 个阶段：

• 第一阶段（项目选择）： 从一系列维护良好、文档齐全的开源项目中，筛选出在发行说明中明确标记了「功能」或「增强」类型更新的项目 。

• 第二阶段（实例收集）： 收集与功能添加相关联的 Pull Request（PR），要求每个实例的 PR 必须包含对软件文档的修改，确保了每个任务都有明确的自然语言描述（即文档变更）作为大模型输入 。

• 第三阶段（环境构建）： 采用了更具扩展性和资源效率的策略：为每个项目构建一个基础 Docker 镜像，使用虚拟环境管理不同版本。结合自动脚本与人工检查修复环境构建问题，提升覆盖范围。

• 第四阶段（实例过滤）： 通过验证测试用例状态从「失败」到「通过」的转变来确认功能的有效添加。与只关注 Bug 修复的基准不同，该流程会保留在功能实现前存在 ImportError 和 AttributeError 等错误的实例，因为这正是功能添加场景的真实反映。

• 第五阶段（输入精炼）：通过静态分析提取代码中已实现但文档中未提及的新实体名称作为「标识符提示」（Identifier Hints） ，以减少因命名不一致导致的评估偏差，并屏蔽 PR 编号等可能导致数据泄露的信息。这一阶段是关注 Bug 修复的基准所不具备的。

此外，为了方便研究者在有限资源下进行轻量级且可靠的评估，团队还精心构建了一个经过人工验证的子集 NoCode-bench Verified。该子集包含 114 个高质量实例，其任务描述的清晰度和评估测试的准确性都经过了人工验证，确保了评估的信度和效度。

对比现有基准，NoCode-bench 的任务呈现出三大挑战：

1. 输入更复杂：文档变更的平均长度几乎是 Bug 报告的两倍，要求模型具备更强的长文本理解和关键信息提取能力。

2. 定位更困难：平均每个任务需要修改的文件数和代码块（hunks）数量都远超以往，且涉及大量的文件新增或删除，对模型的跨文件编辑能力提出了极高要求。

3. 编辑量更大：平均修改的代码行数是 SWE-bench 的数倍，近 20% 的任务修改量超过 200 行，这极大增加了代码生成的难度和引入错误的风险。

SOTA 模型集体「翻车」，问题出在哪？

研究团队在 NoCode-bench 上全面评估了包括 Claude-4-Sonnet、DeepSeek-V3、GPT-4o、Gemini-2.5-Pro 在内的六种业界领先的 LLM。 结果令人意外：

• 在经过人工验证的子集 NoCode-bench Verified 上，表现最好的 Claude-4-Sonnet 模型，其端到端任务成功率也仅有两成。

• 作为对比，同样的顶级模型和框架在 SWE-bench Verified 上的成功率可以达到 70% 以上，但在 NoCode-bench 上却骤降，证明了自然语言驱动的功能添加是一个远未被解决的难题。

通过对失败案例的深入分析，团队总结了三大主要原因：

1. 缺乏跨文件编辑能力：模型倾向于在单个文件中进行修改，而真实的功能开发往往需要跨越多个文件进行协同编辑，导致模型无从下手。

2. 缺乏对代码库结构的整体理解：模型常常为了实现新功能而直接修改现有核心代码，破坏了原有的软件架构和功能，导致大量回归测试失败。

3. 工具调用能力不足：在使用 Agent 框架时，模型无法稳定生成格式正确的工具调用指令，导致无法有效与代码库交互，甚至直接导致任务失败。

总结与展望

这项研究通过 NoCode-bench 的构建与评估，为我们揭示了 AI 在自动化软件开发领域的真实进展和未来方向。

• 提出全新基准：NoCode-bench 首次系统地评估了 LLM 在「无代码」功能添加任务上的能力，填补了现有评测体系的空白。

• 揭示严峻挑战：实验结果表明，当前最先进的 LLM 远未准备好应对真实的、文档驱动的功能开发任务，其成功率极低。

• 指明未来方向：研究识别出的三大失败原因 —— 跨文件编辑、代码库理解和工具调用，为下一代 AI 软件工程师的研发提供了清晰的改进路线图。

研究团队已将 NoCode-bench 的完整数据集、构建流程和评估代码全部开源，希望能推动社区共同攻克 LLM 在复杂软件工程任务中的瓶颈，为实现软件开发的大众化奠定基础。

文章来自于微信公众号“机器之心”。