NoCode-bench：自然语言驱动功能添加的评估新基准
本文由「大千AI助手」原创发布，专注用真话讲AI，回归技术本质。拒绝神话或妖魔化。搜索「大千AI助手」关注我，一起撕掉过度包装，学习真实的AI技术！
1 研究背景与动机
在人工智能技术飞速发展的今天，大型语言模型（LLMs）在代码生成和软件工程任务中展现出巨大潜力。🤖 然而，现有的评估基准（如SWE-bench）主要关注缺陷修复（bug fixing）和问题解决（problem solving），仅有约7.3%的任务涉及功能添加（feature addition）。这种评估不平衡使得我们无法准确衡量LLMs在真实软件开发场景中的能力，因为软件维护成本中约60%实际上用于功能性增强而非简单的缺陷修复。
自然语言驱动的无代码开发（Natural Language-Driven No-Code Development）代表着软件工程的未来愿景——允许用户通过自然语言描述即可为软件添加新功能，无需手动编写代码。✨ 例如，用户可能希望"为聊天工具添加邮件订阅功能"或"让表格软件支持新的导出格式"，理想情况下，AI应能理解这些需求并自动实现相应的代码修改。然而，这种"功能添加"任务与"缺陷修复"任务存在本质区别：
- 理解要求：需要全面理解自然语言描述的功能需求
- 系统理解：需要深入理解现有代码库的结构和架构
- 代码生成：需要在多个文件和位置添加新代码
- 测试意识：需要确保新功能不会破坏现有功能
- 文档更新：需要同步更新相关文档和测试用例
NoCode-bench的提出填补了这一重要空白，为评估LLMs在自然语言驱动的功能添加能力提供了专门的评估框架。
本文由「大千AI助手」原创发布，专注用真话讲AI，回归技术本质。拒绝神话或妖魔化。搜索「大千AI助手」关注我，一起撕掉过度包装，学习真实的AI技术！
往期文章推荐:
- 20.中文房间悖论：人工智能理解力的哲学拷问
- 19.曼彻斯特Mark I：世界上第一台存储程序计算机的革命性创新
- 18.AdaCoT：基于强化学习的帕累托最优自适应思维链触发机制
- 17.GThinker多模态大模型：线索引导式反思的突破
- 16.Auto-CoT：大型语言模型的自动化思维链提示技术
- 15.传统概率信息检索模型：理论基础、演进与局限
- 14.Poisson分布：稀有事件建模的理论基石与演进
- 13.Jina Embeddings：高性能多模态向量模型的演进之路
- 12.GitHub Copilot：AI编程助手的架构演进与真实世界影响
- 11.SWE-bench：真实世界软件工程任务的“试金石”
- 10.StarCoder：开源代码大语言模型的里程碑
- 9.EvalPlus：代码生成大模型的“严格考官”——基于测试增强的评估框架
- 8.艾伦·图灵：计算理论与人工智能的奠基人
- 7.Gato：多模态、多任务、多具身的通用智能体架构
- 6.图灵测试：人工智能的“行为主义判据”与哲学争议
- 5.ASQA: 面向模糊性事实问题的长格式问答数据集与评估框架
- 4.BGE：智源研究院的通用嵌入模型家族——从文本到多模态的语义检索革命
- 3.BM25：概率检索框架下的经典相关性评分算法
- 2.TF-IDF：信息检索与文本挖掘的统计权重基石
- 1.HumanEval：代码生成模型的“黄金标尺”
2 设计理念与构建方法
2.1 核心设计理念
NoCode-bench的设计遵循三个核心原则，确保了其在评估LLMs功能添加能力方面的科学性和实用性：
- 真实性（Authenticity）：基于真实的开源项目发布说明（release notes）而非合成或模拟的任务。发布说明由开发者编写，明确标注了"新增功能"，提供了高质量的自然语言描述基础。
- 全面性（Comprehensiveness）：要求每个功能添加实例必须同时包含源代码修改、测试文件更新和文档变更，反映了真实软件开发中的完整流程。
- 可复现性（Reproducibility）：为每个项目提供容器化的Docker环境，确保评估结果的一致性和可比性。
2.2 五阶段构建流程
NoCode-bench的构建经历了五个严谨的阶段，确保了数据集的质量和可靠性：
- 项目选择（Project Selection）：从SWE-bench的12个开源项目中筛选出10个符合标准的项目，这些项目必须有清晰的发布说明，并明确标注了"新增功能"，且能关联到具体的GitHub Pull Request（PR）。例如，Flask项目因缺乏明确的功能标注而被排除。
- 实例收集（Instance Collection）：从选定的项目中爬取所有与功能添加相关的PR，筛选出同时修改了源代码、测试文件和文档的PR。截至2024年8月，共收集到1,571个候选实例。
- 环境构建（Environment Construction）：为每个项目创建可复现的Docker环境，使用Anaconda管理依赖和版本隔离，确保环境一致性。
- 实例过滤（Instance Filtering）：通过测试用例验证每个任务——新增功能后，必须有测试从"失败"变为"成功"（F2P测试），证明功能有效添加。最终保留634个有效任务，构成NoCode-bench Full数据集。
- 输入优化（Input Refinement）：补充测试用例中引用但文档未提及的实体名称作为"标识符提示"，避免因命名不一致导致的评估偏差，同时移除PR编号等可能造成数据泄露的信息。
2.3 NoCode-bench Verified子集
考虑到完整数据集评估的资源消耗，研究者还创建了一个经过人工验证的高质量子集——NoCode-bench Verified。该子集从238个任务中由5名资深开发者根据任务清晰度和评估准确性进行标注，最终保留114个高质量任务，既保证了评估效果，又显著降低了评估资源需求。
表：NoCode-bench与SWE-bench的特征对比
| 特征维度 | NoCode-bench | SWE-bench | 差异说明 |
|---|---|---|---|
| 输入复杂度 | 739.06 tokens | 480.37 tokens | 文档长度约为SWE-bench的1.5倍 📝 |
| 定位难度 | 2.65个文件/任务 | 1.66个文件/任务 | 需要修改更多文件 🔍 |
| 文件操作需求 | 13.56%任务需新增/删除文件 | 1.70%任务需新增/删除文件 | 更复杂的文件操作 |
| 编辑强度 | 179.12行代码/任务 | 37.71行代码/任务 | 代码变更量约为4.75倍 📊 |
| 主要任务类型 | 功能添加（100%） | 缺陷修复（92.7%） | 完全不同的任务焦点 |
3 关键特性与评估结果
3.1 任务特性与挑战
NoCode-bench包含来自10个开源项目的634个任务，涉及约114,000行代码变更。这些任务展现了三个显著特性，对LLMs提出了前所未有的挑战：
- 输入复杂性：文档变更的平均长度达739.06个token，远超SWE-bench的480.37个token，要求LLMs具备更强的长文本理解能力和关键信息提取能力。
- 跨文件编辑需求：平均每个任务需要修改2.65个文件，13.56%的任务需要新增或删除文件，要求LLMs具备全局代码库理解能力和跨文件协调能力。
- 大规模代码生成：平均每个任务需修改179.12行代码，20%的任务变更超过200行，远超SWE-bench的37.71行，考验LLMs的大规模代码生成能力和架构一致性保持能力。
3.2 主流大模型性能评估
研究团队评估了6种最先进的LLMs（包括GPT-4o、Claude-4-Sonnet、DeepSeek-V3等），使用两种主流框架（Agentless和OpenHands）。评估结果令人惊讶：
在NoCode-bench Verified子集上，表现最佳的Claude-4-Sonnet模型成功率仅为15.79%，其他模型的表现更差。作为对比，同样的顶级模型在SWE-bench Verified上的成功率可达70%以上，突显了功能添加任务的独特挑战性。
在NoCode-bench Full数据集上，模型表现进一步下降，平均成功率仅为5.68%，这主要是由于任务更复杂且含有更多噪声。
表：主流大模型在NoCode-bench上的性能表现（%）
| 模型名称 | NoCode-bench Verified | NoCode-bench Full | 主要失败原因 |
|---|---|---|---|
| Claude-4-Sonnet | 15.79 | <5.68 | 跨文件编辑能力不足 |
| GPT-4o | <15.79 | <5.68 | 代码库理解不足 |
| DeepSeek-V3 | <15.79 | <5.68 | 破坏现有功能 |
| Gemini-2.5-Pro | 0.0（Agent框架） | <5.68 | 工具调用格式错误 |
4 失败分析与未来方向
4.1 主要失败原因分析
通过对失败案例的深入分析，研究者识别出LLMs在功能添加任务中的三大主要短板：
- 跨文件编辑能力不足：LLMs倾向于在单个文件中进行修改，而真实的功能开发往往需要跨越多个文件进行协同编辑。在多文件任务中，模型成功率仅为2.03%，表明当前模型缺乏全局代码库视角和跨文件协调能力。
- 代码库结构理解不足：模型常常为了实现新功能而直接修改现有核心代码，破坏了原有的软件架构和功能，导致大量回归测试失败。例如，DeepSeek-V3在某些任务中引入了破坏性更改，导致现有功能失效。
- 工具调用能力欠缺：在使用Agent框架时，模型无法稳定生成格式正确的工具调用指令，导致无法有效与代码库交互。例如，Gemini-2.5-Pro因格式错误导致在Agent框架下的成功率为0%。
4.2 未来发展方向
基于NoCode-bench的评估结果，研究者指出了几个未来重点发展方向：
- 增强跨文件理解能力：开发能够理解和操作多个相关文件的LLMs架构，提高模型对代码库整体结构的认知能力。
- 改进工具使用范式：设计更直观的工具调用接口和更有效的工具学习框架，降低模型工具调用难度。
- 强化代码库感知：将代码库的结构信息和依赖关系显式地融入模型训练和推理过程，减少破坏性更改。
- 长上下文优化：针对功能添加任务中长输入的特点，优化模型的長文本理解能力和关键信息提取能力。
5 影响与意义
NoCode-bench的推出对AI辅助软件工程领域具有重要意义：
- 填补评估空白：首次提供了专门针对自然语言驱动功能添加任务的评估基准，使研究者能够系统评估和比较不同LLMs在此类任务上的性能。
- 推动技术发展：通过揭示当前LLMs的局限性，为下一代AI编程助手的发展指明了方向。预计将促进更多研究资源投入到跨文件编辑、代码库理解和工具调用等关键能力的提升上。
- 促进软件开发民主化：随着LLMs在功能添加任务上能力的提升，无代码/低代码开发愿景将更接近现实，显著降低软件开发门槛，使非专业用户也能参与软件创建过程。
- 影响模型设计：该基准的评估结果可能影响未来LLMs的架构设计，特别是需要更好地整合代码库上下文、支持更长上下文窗口，以及改进工具使用能力。
6 原始论文
- Deng, L., Jiang, Z., Cao, J., Pradel, M., & Liu, Z. (2025). NoCode-bench: A Benchmark for Evaluating Natural Language-Driven Feature Addition. arXiv preprint arXiv:2507.18130. https://arxiv.org/abs/2507.18130
NoCode-bench为评估大模型在自然语言驱动功能添加任务上的性能提供了首个专门基准，揭示了当前最先进模型在此类任务上的显著不足。🚧 通过提供高质量的评估数据集和标准化评估框架，这一基准将加速AI辅助软件工程领域的发展，推动我们向着真正意义上的"无代码开发"愿景迈进。✨
正如研究者所言："NoCode-bench不仅是一张考卷，更是一张导航图，指引着我们向着更智能、更易用的软件工程未来前进。"🧭 随着模型的不断进化和发展，我们有理由相信，自然语言驱动的功能添加将成为软件开发的新范式，极大降低软件开发门槛，推动数字技术的民主化进程。🌟
本文由「大千AI助手」原创发布，专注用真话讲AI，回归技术本质。拒绝神话或妖魔化。搜索「大千AI助手」关注我，一起撕掉过度包装，学习真实的AI技术！