研究背景与核心观点 - 论文由浙江大学研究员刘忠鑫团队联合香港科技大学、德国斯图加特大学等机构共同完成，聚焦代码智能与AI在软件工程中的应用 [2] - 核心观点：当前LLM在「自然语言驱动功能添加」任务上的成功率仅20%，远低于Bug修复任务（SWE-bench成功率70%+），揭示AI在真实软件开发中的能力短板 [3][26] - 提出全新基准NoCode-bench，填补现有评测体系空白，推动AI从「修理工」向「开发工程师」转型 [6][27] NoCode-bench基准设计 - 数据来源：从开源项目的发行说明（Release Notes）提取开发者确认的功能添加条目，确保高质量与真实性 [8] - 构建流程： - 阶段1：筛选文档齐全且明确标记功能更新的开源项目 [10] - 阶段2：收集关联PR，要求必须包含文档修改以提供自然语言输入 [10] - 阶段3：采用Docker镜像+虚拟环境构建可扩展的测试环境 [16] - 阶段4：通过测试用例状态转变验证功能有效性，保留开发过程中的错误实例以反映真实场景 [16] - 阶段5：静态分析提取「标识符提示」减少评估偏差，屏蔽PR编号防数据泄露 [16] - 子集NoCode-bench Verified包含114个经人工验证的高质量实例，提升评估信度 [11] 基准任务挑战性分析 - 输入复杂度：文档变更平均长度为Bug报告的2倍，需更强文本理解能力 [12] - 定位难度：需修改的文件数和代码块数量远超Bug修复任务，涉及大量文件增删 [13] - 编辑量：平均修改代码行数为SWE-bench数倍，20%任务修改量超200行 [14] 模型性能评估结果 - 测试模型：涵盖Claude-4-Sonnet、GPT-4o、Gemini-2.5-Pro等6种SOTA模型 [18] - 最佳表现：Claude-4-Sonnet在NoCode-bench Verified上成功率仅15.79%，Agent框架下提升至15.79%但仍远低于Bug修复任务 [18][26] - 开源模型对比：DeepSeek-v3表现最优（14.91%），闭源模型中Claude-4-Sonnet领先 [18] 失败原因与改进方向 - 跨文件编辑能力缺失：模型倾向单文件修改，无法处理多文件协同编辑 [20] - 代码库理解不足：直接修改核心代码破坏软件架构，导致回归测试失败 [21] - 工具调用缺陷：Agent框架下无法稳定生成正确指令格式 [22] - 未来方向：需重点突破跨文件编辑、代码库整体理解和工具调用三大瓶颈 [27] 行业影响与开源贡献 - 行业价值：软件维护成本60%用于功能增强，NoCode-bench直击核心需求 [6] - 开源资源：完整数据集、构建流程和评估代码已开源，推动社区协作 [25] - 研究意义：首次系统评估LLM在无代码功能添加任务的能力，为AI软件工程师发展提供路线图 [27]