DeNovoSWE: 从零生成整个仓库的长时域环境扩展

TL;DR DeNovoSWE 构建 4818 个高质量仓库生成实例，用分治与批评-修复自动清洗，微调后从文档组装完整仓库的成功率从 5.8% 骤升至 47.2%，破解长程 SWE 数据荒。

问题

问题背景：LLM-based code agents 在 SWE-bench 等局部修复任务上表现强劲，但长程全仓库生成能力正成为下一阶段突破点。

现有方法局限：

• 现有数据集（如 SWE-bench-Verified）聚焦单文件修改，缺乏大规模、可验证的从文档生成整个仓库的训练数据；
• 训练数据稀缺导致模型在需求拆解、模块规划、多文件协调等长程能力上薄弱；
• 当前基准已趋饱和，难以区分强模型的深层次推理能力，阻碍新方法迭代。

技术挑战与重要性：全仓库生成要求将高层文档描述转化为多文件仓库，需解决需求分解、跨文件一致性、自动验证等难题；数据构建时还要防止信息泄露并平衡难度与多样性。业界正推动 AI 编程从“补丁级”走向“项目级”，若能可靠实现，将极大提升开发效率——类比于从产品需求文档自动生成可运行应用，比单点补全更贴近真实工程场景。

核心洞察

• **DeNovoSWE** 通过自动化的**沙盒代理工作流**与大规模**分治**构建策略，首次实现无需人工标注的整仓库生成数据集规模化构建。 传统长程软件工程数据集依赖人工编写或局限于局部修复（如 SWE-bench），而 DeNovoSWE 利用代码代理在隔离环境中自动拆分文档为子任务，并通过**批评-修复**循环确保执行正确性，生成可验证轨迹。该可扩展方案直接解决了长程任务监督信号稀缺的核心障碍，为训练能架构完整系统的代码智能体奠定数据基础。
• 难度感知轨迹过滤通过多特征评分融合与动态选取，在数据质量与多样性间取得平衡，显著提升微调效率。 与常见的硬阈值过滤或均匀采样不同，DeNovoSWE 的难度评分框架融合执行成功率、子任务步长和修正次数等多维信号，采用优化权重加权后，按需从不同难度区间选取轨迹。该方法在保留困难样本多样性的同时剔除低质量噪声，使模型（如 Qwen3-30B-A3B）在固定微调算力下性能提升超 8 倍，展示了**难度感知数据采样**的工程价值。
• 从文档到完整仓库的生成任务，将代码智能体的能力边界从局部补丁拓展至系统级架构设计与实现。 现有评测（如 SWE-bench）主要针对已有仓库的 issue 修复，而 DeNovoSWE 要求基于高层文档从零生成整个仓库，考验模块拆分、接口设计、文件结构规划与跨文件一致性等**长程编排能力**。该设定更贴近真实软件开发起点，为评估代码智能体的高阶工程思维提供了严格检验。微调结果表明，结构化长程合成数据可让较小模型在此类任务上实现超预期提升，凸显其潜力。

方法

输入与任务定义

DeNovoSWE 的每个实例输入为一份软件仓库的文档（如 README、API 规范或功能描述），输出为一个完整可运行的代码仓库。该数据集旨在训练 LLM 从高层文档直接生成整个仓库，而不是修复局部缺陷。

关键模块：分治代理与沙盒工作流

数据集构建的核心是一个沙盒化的代理工作流，遵循“分治”（divide and conquer）与“批评-修复”（critic-repair）哲学：

• 分治（Divide）：代理首先将仓库生成任务分解为子目标，例如规划目录结构、声明接口、实现核心模块、编写测试等。每一步生成后，在沙盒中执行验证（如运行 pytest、mypy），确保即时反馈。
• 征服（Conquer）：代理逐步实现每个子任务，并在执行过程中维护依赖关系。若某步失败，critic 代理会介入分析错误并触发修复循环，直至子任务通过验证。这种迭代式自修复极大提升了最终仓库的可运行性和规范性。

难度感知轨迹过滤

为避免数据集同质化，作者引入难度感知轨迹过滤：

1. 构建难度评分框架，收集每条生成轨迹的多维度特征信号（如步骤数、错误修复次数、代码行数、测试覆盖率等）。
2. 对每个特征进行 归一化，并通过权重优化（基于少量人工标注的难度对比对）融合成单一难度分数。
3. 设定动态阈值，保留中等及以上难度且质量合格的样本，兼顾多样性与训练价值。

最终得到的 DeNovoSWE 包含 4,818 个高质量实例，覆盖多种编程语言与任务类型。

输出与模型微调

使用该数据集对 Qwen3-30B-A3B（一款 MoE 语言模型）进行监督微调，得到的模型在 BeyondSWE-Doc2Repo 基准上准确率从 5.8% 跃升至 47.2%，验证了数据集的有效性。

与同类方法的差异：与 NL2Repo、RepoBench 等依赖模板或人工筛选的仓库生成数据集相比，DeNovoSWE 的关键区别在于完全自动化的沙盒代理工作流 + 难度感知过滤，既能规模化构建，又能通过 critic 机制保证仓库级别可执行性，避免低质量轨迹污染训练。

实验

实验设计

实验基于 DeNovoSWE 数据集微调 Qwen3-30B-A3B 模型。DeNovoSWE 包含 4,818 个高质量样本，每个样本要求从文档出发生成整个代码仓库。数据通过沙箱化的 agentic 工作流自动构建，无需人工标注，并采用 难度感知的轨迹过滤策略 平衡质量与多样性。微调后，模型在 BeyondSWE-Doc2Repo 基准上评估，该基准专门衡量从文档生成完整仓库的长程软件工程能力（Long-Horizon SWE）。

关键发现

• 微调前，基础模型 Qwen3-30B-A3B 在 BeyondSWE-Doc2Repo 上的 Pass@1 仅为 5.8%。
• 经 DeNovoSWE 数据集微调后，相同模型的 Pass@1 飙升至 47.2%，相对提升超过 8 倍。
• 这一飞跃表明：尽管前沿模型在 issue 级任务上表现强劲，但通过专门设计的全仓库生成数据训练，可解锁架构级推理与多文件协同实现的深度能力。
• 数据构建的 “分治+ critic-repair” 范式（将仓库生成分解为子任务并迭代修复）可能为长程任务提供了有效的监督信号。

与基线的深度解读

基础 Qwen3-30B-A3B 的 5.8% 得分说明，仅靠预训练获取的代码能力无法直接泛化到从零生成整个项目，长程规划、跨文件依赖管理及自我纠错等核心技能严重缺失。DeNovoSWE 通过提供 可验证的完整仓库轨迹，让模型学习到“如何从文档原子能力组合为系统工程方案”。47.2% 的 Pass@1 仍然留有较大提升空间，但路径已清晰：大规模、可自动扩展的长程训练数据是突破代码 agent 能力天花板的关键。与基于 issue 修复的 SWE-bench 相比，Long-Horizon 基准更能区分 agent 的架构思维，DeNovoSWE 有望成为推动下一代代码 agent 发展的核心数据基础设施。

行业影响

落地场景

DeNovoSWE 训练出的长时程代码生成能力可直接嵌入多种开发者工具与自动化平台：

• 低代码/无代码平台：将产品需求文档或设计规范自动转化为可运行的完整项目骨架，大幅减少手动搭建前端/后端模板的时间。
• SDK 与 API 客户端自动生成：根据 API 文档（OpenAPI/Swagger）一键生成整个客户端库（包含认证、分页、错误处理），而不仅是接口定义。
• 遗留系统迁移：输入旧系统接口文档，生成等效的新技术栈仓库，适用于微服务拆分或框架升级。
• 教育/培训：根据教材中的习题描述自动生成练习项目的完整仓库，供学生直接使用。

商业价值

• 降本：将软件实现环节的重复性劳动自动化，使资深工程师聚焦架构设计而非代码搬砖，开发人力成本可降低 30%-50%。
• 增收：缩短从需求到原型的交付周期，让产品团队能更快验证想法，抢占市场窗口；企业也可对外输出“需求→仓库”的自动化能力而形成新的 API 服务收入。
• 体验提升：开发者从繁重的模板编写中解放，专注于业务逻辑创新；非技术人员（如产品经理）也能通过文档直接获得可运行原型，降低跨职能协作摩擦。

与现有产品/工作流的接口

• IDE 插件：集成至 VS Code 或 JetBrains 插件链，通过右键选项将 .md 需求直接转换为仓库；或作为 git init 的增强钩子，根据 README 自动生成初始提交。
• CI/CD 流水线：在分支创建或 issue 提交时触发，根据 spec.md 自动生成 Pull Request 含完整实现代码，配合代码审查工具仅需人工确认关键逻辑。
• 项目管理工具：与 Jira/Linear 连接，将标签为 spec-ready 的 issue 描述自动转化为代码仓库并链接回原工单，形成“需求→代码”的闭环追溯。

具体落地用例

• 电商商品中心微服务：根据一份商品数据模型与 API 行为文档，DeNovoSWE 微调模型生成包含数据库 ORM、CRUD 接口、库存校验、缓存层以及 Dockefile 的完整仓库，30 分钟内即可部署到 k8s 集群进行联调。
• 金融合规报告系统：监管机构发布新的披露要求文档，模型直接从该文档生成报告生成器的全量代码，包括数据抽取逻辑、模板渲染与 PDF 输出，将原本需 5 人周的开发压缩至半天。

局限

• **数据集自动构建可能引入隐性质量问题**。DeNovoSWE 完全依赖沙盒代理工作流和 critic-repair 机制生成训练样本，虽然无需人工标注，但自动验证主要基于功能测试通过率，难以覆盖代码可读性、架构合理性、命名规范等工程维度。分治策略生成的仓库可能存在文件间耦合松散、全局设计不一致的风险，但自动筛选流程未必能有效过滤这类缺陷，导致模型学到次优模式。
• **分治策略简化任务，可能损害仓库级架构学习**。将整个仓库生成按文件或模块拆分子任务，虽降低了单步难度，但代理在生成每个部分时缺乏全局上下文，容易忽略跨文件的接口定义、依赖关系和架构约束。最终拼接出的仓库可能在功能上通过测试，但模块划分、职责分离等宏观结构不尽合理，这与真实世界中从零开始设计仓库的流程存在差距，限制了模型对长程系统设计能力的提升。
• **评估框架和模型泛化性有待加强**。论文仅在 Qwen3-30B-A3B 上微调，并在自行提出的 BeyondSWE-Doc2Repo 基准上评测，缺乏在其他主流基座模型或不同分布文档（如非 Python 生态、非库类项目）上的验证。此外，功能正确性之外的代码质量指标（如圈复杂度、重复率）未纳入评估，使得难以全面衡量生成仓库的工程实用性。