NoCode-bench

当用户只需写下“增加导出为 CSV 的功能”，AI 就能自动完成代码修改、测试并通过构建——这是否意味着真正的“无代码开发”时代正在到来？

要回答这个问题，首先需要一个可靠的衡量标准。为此，研究团队推出了 NoCode-bench，一个专门用于评估大语言模型（LLMs）在自然语言驱动下实现功能添加能力的新基准。

与以往聚焦于错误修复或代码补全的测试不同，NoCode-bench 直面更复杂的现实场景：仅凭文档描述，让模型理解需求并自主实现新功能。

这不仅是技术挑战的升级，更是对“AI 编程助手”是否真正具备工程化能力的一次检验。

为什么需要 NoCode-bench？

当前主流的代码智能基准（如 SWE-bench）多集中于两类任务：

• 修复已知 bug
• 执行明确的代码变更

但它们并未触及软件开发中更常见的场景：功能演进。

在真实项目中，大多数变更源于产品文档、发布说明或用户需求的更新。例如：

“新增 Dark Mode 支持”
“允许用户将数据导出为 PDF”
“集成第三方登录方式”

这些变更通常由产品经理或用户提出，不附带具体实现方案。而 NoCode-bench 正是基于这类文档驱动的功能添加请求构建的。

它的目标很明确：

评估大模型能否仅通过自然语言输入，理解上下文、定位相关文件、生成正确代码，并通过测试验证。

数据来源与任务构成

NoCode-bench 从多个真实开源项目中提取了 634 个功能添加任务，涉及约 11.4 万次代码变更，覆盖 Web 开发、数据处理、CLI 工具等多个领域。

每个任务包含三部分核心内容：

此外，研究团队还构建了一个高质量子集：NoCode-bench-Verified，包含 114 个经过人工验证的任务实例，确保任务描述清晰、目标明确，适用于高置信度的人工评估。

构建流程：五阶段质量控制

为了保证任务的有效性与可评估性，NoCode-bench 采用系统化的五阶段构建流程：

1. 项目选择：筛选高质量、维护活跃的开源项目，确保代码结构清晰、测试完备。
2. 实例收集：通过分析 release notes 和 PR 描述，识别出明确的功能新增请求。
3. 环境构建：为每个任务重建独立的开发环境，包括依赖安装与测试配置。
4. 实例过滤：运行原始项目的测试用例，验证补丁是否能通过，剔除不可复现或测试缺失的任务。
5. 输入细化：对自然语言输入进行标准化处理，去除歧义，提升可读性。

这一流程确保了所有任务均可在隔离环境中执行和验证，提升了基准的可靠性。

评估方式与核心指标

NoCode-bench 支持两种主流 AI 编程框架的接入：

• Agentless：基于流水线的方法，分为定位、生成、验证三个阶段
• OpenHands：基于代理的交互式框架，允许模型调用编辑器、终端等工具

评估过程模拟真实开发流程：模型接收到文档变更后，需自主完成代码修改，并提交补丁。系统通过以下指标衡量其表现：

其中，“任务成功率”是最核心的指标。

实验结果：AI 距离“自主开发”仍有巨大差距

研究团队对多个先进 LLM 进行了测试，结果令人清醒：

即使是最强模型，在完整集上的成功率也不足 7%。

失败原因分析

通过对失败案例的深入分析，研究发现当前 LLMs 在以下方面存在明显短板：

1. 跨文件编辑能力弱
   许多功能涉及多个模块协同修改，模型常遗漏关键文件或接口调整。
2. 代码库结构理解不足
   模型难以准确识别核心组件、依赖关系和扩展点，导致实现偏离设计。
3. 工具使用不熟练
   在基于代理的框架中，模型频繁误用编辑命令或搜索工具，降低效率。
4. 缺乏迭代与验证意识
   多数模型“一次性输出”补丁，缺少运行测试、查看日志、修正错误的闭环能力。

意义与展望

NoCode-bench 的意义不仅在于暴露了当前 AI 编程的局限，更在于定义了一个新的能力维度：从“响应式修复”走向“主动性开发”。

它提醒我们：

真正的智能编程助手，不应只是“写代码更快”，而是能理解业务意图、规划实现路径、并独立交付可运行功能的协作者。

未来，随着代理架构、记忆机制、测试反馈循环的演进，我们有望看到模型在 NoCode-bench 上的表现逐步提升。而这一进步，将直接推动无代码/低代码平台向更复杂场景延伸。