中国人民大学联合团队打造"代码建筑师"：AI能从零造出一整个软件仓库了

这项由中国人民大学高岭人工智能学院联合独立研究员及AweAI团队共同完成的研究，以预印本形式发布于2026年6月9日，论文编号为arXiv:2606.10728，有兴趣深入了解的读者可通过该编号在arXiv平台查询完整论文。

**软件工程师的"噩梦作业"：从零搭一个完整项目**

每一位写过代码的人都知道，修一个已有程序里的小虫子（bug）和从一张白纸上搭出一栋完整的"代码大厦"，根本不是一个量级的挑战。前者像找到家里漏水的水管然后补上；后者却像手持一份建筑说明书，从挖地基、砌砖墙到安装电路，把整栋楼一砖一瓦地盖起来。

过去几年，人工智能在"修虫子"这件事上表现得越来越出色。以SWE-bench这个行业公认的测试场为例，顶尖的AI系统在处理单一代码问题时已经能拿到相当高的分数，以至于这个测试本身开始变得"不够难"，不再能真正区分强手与弱手。更重要的是，修虫子只需要在别人盖好的大厦里找到某面裂缝墙然后修补——AI还没有学会从头盖一栋楼。

研究团队正是盯住了这个空缺。他们希望训练一种AI，能够读懂一份软件的"设计说明书"（也就是文档），然后把整个软件仓库从零写出来，而且写出来的代码要能真正跑通测试、证明它确实按照说明书完成了任务。这种能力被研究者们称为"长视野软件工程"——顾名思义，不是修补一个角落，而是把整幅画从头到尾画完。

**为什么这件事如此困难**

要训练AI完成这种"从零建仓库"的任务，首先得有大量的训练数据——就像要教一个厨师做菜，你至少得先给他看够多的菜谱和成品照片。然而现实是，这类"完整项目生成"的训练数据极为稀缺。现有的AI代码训练数据集，绝大多数都围绕着"修单个问题"展开，真正覆盖"整个仓库从文档生成"的数据集，在该研究发布之前，规模最大的也不过只有104条样本。

这个数字看起来有多小？这篇论文构建的数据集包含4818条样本，大约是此前最大同类数据集的46倍。这个数量级上的差距，才是研究团队认为AI在这个任务上始终"学不会"的根本原因之一。

**三道拦路虎：文档、评测、防作弊**

在正式介绍数据集的构建方法之前，有必要搞清楚这件事到底难在哪里。研究团队将挑战归结为三个核心障碍，理解这三个障碍，才能理解他们后来的解决方案为什么要这样设计。

第一个障碍是文档构建。GitHub上有数以千万计的开源代码仓库，但这些仓库自带的说明文档质量参差不齐——有的几乎空白，有的只有零散的使用说明，有的和代码实际行为完全对不上。要用文档来定义一个"从零生成代码"的任务，这份文档必须做到既完整准确，又与测试套件的行为高度一致。换句话说，文档不能只是大概说说软件是干什么的，必须精确到"调用这个函数时传入什么参数、会返回什么结果、会抛出什么错误"这个层面。

第二个障碍是评测设计。不同的软件仓库功能各异、规模不一，如何用统一、客观的标准来判断AI生成的代码是否合格？研究团队的答案是依赖原始仓库自带的单元测试——这是最客观的标准，代码能跑通测试，就说明它按照规格工作了。

第三个障碍是防作弊。这个问题听起来有些奇特，但非常现实。当AI在一个有网络访问权限的环境中工作时，它完全可以直接从GitHub上把原始代码仓库克隆下来，或者用pip安装原始包然后反查源码——相当于考试时直接把答案本拿来抄。要让评测真实有效，必须把这些"作弊通道"全部堵死。

**一、"分而治之"：把一座大山拆成若干个小坡**

面对这三道障碍，研究团队设计了一套名为DeNovoSWE的自动化流水线。整个流程的核心哲学来自一个古老的智慧：分而治之。

就像一位建筑师拿到一份摩天大楼的设计需求时，不会试图一口气把整栋楼的每个细节都想清楚，而是先把大楼分解成结构、电气、给排水、幕墙等若干子系统，再逐一深化设计——DeNovoSWE对每个代码仓库做的事情与此如出一辙。

流程的第一个阶段叫做"分割"阶段。系统会先派出一个"概述撰写代理"，通读整个仓库的代码、README文件和目录结构，生成一份高层次的仓库总览，说明这个软件是干什么的、整体架构是什么样的、主要模块有哪些。这份总览既是最终文档的开篇介绍，也是后续所有工作的全局背景。

紧接着，一个"能力提取代理"会把整个仓库分解成若干个独立的"功能能力"——比如"用户认证与连接"、"数据读写操作"、"批量更新工作流"等等。每个能力对应文档中的一个独立章节，就像把一本厚厚的产品手册分成若干个专题来写，每个专题各司其职。

与此同时，系统还会运行仓库原有的单元测试，捕获运行时的执行轨迹，从而识别出测试实际涉及的所有函数和类。这些被识别出来的代码单元按重要程度被分为三类：直接被测试引用的"直接组件"、虽未被直接引用但对测试结果有影响的"核心间接组件"，以及对测试行为无关紧要的"非核心间接组件"。前两类会被纳入文档，获得详细的接口描述；第三类则刻意被排除在文档之外，留给AI自由发挥，既保证了任务的可解性，又避免把整个任务变成纯粹的代码抄写。

最后，一个基于大语言模型的分类器会把每个函数和类映射到它所归属的"功能能力"上，确保每个能力章节的文档都聚焦在真正相关的代码单元上，而不是泛泛地描述整个仓库。

**二、"起草—批评—修复"：反复打磨直到足够好**

完成分割之后，就进入了真正写文档的"征服"阶段。这个阶段采用了一种三人协作的迭代机制，研究团队称之为"起草—批评—修复"循环。

"起草代理"针对每一个功能能力生成初版文档。它在一个沙箱环境中工作，可以实际查看仓库的源代码，以便在需要的时候核查具体的函数签名和行为细节。

然后是"批评代理"上场。它扮演的角色类似于一位严格的技术审稿人，逐条检查文档的完整性：所有直接组件的导入路径写清楚了吗？公开API的参数类型和返回值说明白了吗？会抛出哪些错误有没有注明？文档提供的信息，足够让另一个AI从零实现这个功能并通过测试了吗？同时，批评代理还会检查另一个方向的问题：文档有没有泄露太多实现细节，把任务变成了简单的复制粘贴？

批评代理的审查结果会传递给"修复代理"，由它针对被指出的缺陷对文档进行定向修订。修复后的新版本再次交给批评代理审查，如此循环，直到文档达到标准或者迭代预算用尽为止。

这个机制的精妙之处在于，它把"写文档"这件事变成了一个有明确验收标准的工程问题，而不是凭感觉判断"写得够不够好"——标准就是：读这份文档的人，有没有足够的信息来重建原始软件的测试行为。

**三、把"作弊通道"一个不剩地堵死**

文档写完之后，每个训练实例还要经历严格的环境清理，以确保当AI尝试完成任务时，它真的只能依赖文档，而无法通过任何旁门左道获取原始代码。

清理工作分三个层次展开。第一个层次是"环境保留与源码剥离"：系统精确识别并保留原始仓库的构建配置和运行时依赖，同时把所有代码实现和测试文件彻底清除。第二个层次是"多通道泄露清除"：系统会扫描所有Python环境，删除site-packages中的相关痕迹、pip缓存的wheel文件、以及/tmp目录下的编译中间产物（比如C/Rust扩展的包装器），切断所有可能通过本地缓存恢复源码的路径。第三个层次是"Git历史净化"：系统彻底销毁并重新初始化.git目录，消除通过git reflog或松散Git对象反推历史代码的可能性。

即便如此，拥有网络访问权限的AI仍然可能试图从GitHub克隆原始仓库，或者用pip install/pip download获取原始包的源码，甚至用curl直接下载源文件。为了应对这些外部渠道，系统在Docker容器内部执行了命令限制策略，屏蔽了所有针对目标包的常见源码恢复操作。此外，系统还会用基于规则的模糊匹配过滤器检测可疑命令，并在事后用大语言模型审查AI的执行轨迹，捕捉那些难以用固定规则描述的规避尝试。

**四、难度越高，标准应当越宽容——一个反直觉的筛选策略**

数据集构建完成后，还需要生成真实的"解题轨迹"用于训练——也就是让一个强大的AI（研究团队选择了DeepSeek-V4-Pro）去实际尝试完成这些任务，记录下它的操作过程，然后用这些成功（或接近成功）的轨迹来训练目标模型。

这里出现了一个有趣的问题。传统的做法是只保留"全部测试都通过"的完美轨迹，但对于"从零搭建完整仓库"这种任务来说，这个标准太苛刻了。一个有数百个测试用例的大型仓库，即便是最强的AI也未必能一次性全部通过——就像一个学生参加数百道题的考试，偶尔答错几道并不代表这份答卷没有参考价值。

如果坚持"全通过才保留"，就会大量丢弃来自困难仓库的宝贵数据，让训练集严重偏向简单任务；但如果把筛选门槛降得太低，又会把大量低质量的答案也纳入训练，反而把模型教坏。

研究团队的解决方案是设计一套"难度感知的轨迹筛选策略"。核心思路是：对不同难度的任务，设置不同的筛选门槛——简单任务要求高，困难任务要求可以适当宽松。

为了实现这一点，团队首先需要给每个任务打一个"难度分"。难度分由三个信号融合而成。第一个是结构性信号，统计任务涉及的可执行Python代码行数，代码越多通常意味着任务越复杂；第二和第三个信号来自两个独立的大语言模型，各自对任务文档给出1到5级的难度评估。这三个信号经过归一化处理后，用加权求和的方式合并成一个0到1之间的最终难度分。权重的确定也很讲究：在一批有实际运行数据的样本上，团队通过最大化难度分与实际通过率之间的负相关性来优化权重，确保难度分确实反映了真实的任务难易程度。

有了难度分之后，筛选门槛按难度区间分五档设置。难度分在0到0.2之间的最简单任务，通过率门槛设为90%；随着难度上升，门槛依次降低到85%、80%、70%；对于难度分在0.8到1.0之间的最复杂仓库，通过率只需要达到60%就可以被纳入训练集。这样一来，那些虽然没能完美解决高难度任务、但仍然正确处理了大部分功能的轨迹，得以保留下来作为有价值的训练信号。

这套机制的实际效果体现在数据中。从难度分布图可以看出，随着难度分的上升，轨迹的平均通过率确实呈现出清晰的下降趋势，验证了难度评估的有效性。而在难度分布上，DeNovoSWE的样本分布横跨了从0到1的整个难度范围，没有明显集中在某一区段，说明数据集覆盖了从简单到极复杂的各类任务。

**五、数字会说话：这个数据集有多大、质量有多高**

最终构建完成的DeNovoSWE数据集包含4818个实例。与此前规模最大的同类数据集NL2RepoBench（104条）相比，这是约46倍的扩张；与BeyondSWE-Doc2Repo基准（50条）相比，规模更是扩大了近百倍。

在质量层面，数据集中的仓库平均测试覆盖率达到85.5%，中位数高达89.6%。这意味着单元测试覆盖了绝大多数需要实现的代码，AI的输出质量可以被充分、客观地检验。从P75到P90，覆盖率分别达到96.5%和99.9%，说明绝大多数仓库都接近被测试"全覆盖"。

复杂度方面，数据集中位数仓库有79个单元测试，分布在12个测试文件中。单元测试涉及的源代码文件数量的中位数是9个，在P75和P90处分别上升到21和42个，说明很多任务并非单个模块的简单实现，而是需要跨越多个文件协同工作的系统性开发。最极端的情况下，单个仓库有多达8903个单元测试，测试文件数量同样达到了四位数——这才是真正意义上的"长视野软件工程"挑战。

**六、成绩单：从5.8%到47.2%，性能提升的量级**

数据集构建完成后，研究团队用它对Qwen3-30B-A3B这个开源模型进行微调，验证数据集的实际效果。评测在两个专门测试"从零生成完整仓库"能力的基准上进行，分别是BeyondSWE-Doc2Repo和NL2RepoBench。

未经任何针对性训练的原始Qwen3-30B-A3B-Instruct模型，在BeyondSWE-Doc2Repo上只能拿到5.8%的分数，在NL2RepoBench上只有4.3%——这说明通用大模型在这种"从零建仓库"任务上几乎束手无策，不是不够聪明，而是根本没见过这类训练数据。

用Scale-SWE（一个专注于单个问题修复的大规模SWE数据集）训练后的模型，分数提升到29.2%和18.3%。这说明学习"修单个bug"对"建整个仓库"确实有一定迁移效果，但非常有限——就像学会了修水管，并不等于学会了建造整栋楼。

而经过DeNovoSWE数据集训练后的DeNovoSWE-Agent-30A3B，分数分别跃升至47.2%和23.0%。BeyondSWE-Doc2Repo上的成绩提升幅度超过17个百分点，相当于在"修bug"专项训练基础上再翻了将近一倍。

在更强的Qwen3.5-35B-A3B底座上，原始模型已经有不错的基础表现（43.8%和23.5%）——这个底座本身参数量更大、能力更强。经过DeNovoSWE微调后，DeNovoSWE-Agent-35A3B进一步提升到50.0%和27.1%，与顶级商业闭源模型的差距大幅收窄：距离Gemini3-Pro只差2个百分点，距离Qwen3.5-Plus只差2.4个百分点，而后者是参数规模大得多的闭源商业产品。

**七、"一刀切"门槛为什么不好用——消融实验的发现**

为了验证"难度感知筛选"策略确实比"一刀切固定门槛"更有效，研究团队专门做了对比实验。

以固定门槛0.95进行筛选时，两个评测基准上的成绩分别是48.1%和25.0%。把门槛降到0.80时，成绩提升到48.5%和25.4%。进一步降到0.60，成绩再升到48.8%和26.4%。这个趋势说明了一个重要现象：对于"从零建仓库"这类任务，一味追求高质量轨迹反而会丢掉很多来自困难仓库的有价值数据，适当降低筛选门槛有助于保留多样性，从而提升模型能力。

而研究团队设计的难度感知筛选策略（对简单任务门槛为0.90，对困难任务门槛降至0.60），在这些对比中取得了最好的成绩：50.0%和27.1%。它不仅比最宽松的固定门槛方案（0.60固定门槛）表现更好，也超越了所有中间配置。

这背后的逻辑并不复杂：固定的低门槛虽然保留了困难任务的数据，但同时也引入了简单任务中的劣质轨迹——因为简单任务里低通过率的轨迹通常代表执行出了问题，而非任务本身的难度。难度感知策略的高明之处在于，它能区分"这个轨迹的通过率低是因为任务很难"和"这个轨迹的通过率低是因为AI答得很差"这两种完全不同的情况，对症下药地设置门槛。

研究团队还测试了一个稍微宽松的难度感知配置（最简单任务门槛从0.90降到0.80），结果成绩反而略有下降，验证了对简单任务保持严格筛选标准的必要性。

**说到底，这件事的意义在哪里**

归根结底，这项研究做的事情可以用一句话来概括：它造了一批"建筑蓝图"，然后用这些蓝图训练AI，让AI学会从零建造完整的"代码大厦"。

在此之前，最大的同类训练数据集只有100来条，相当于只给学生准备了几十道例题就让他去参加高考。DeNovoSWE把这个数字扩大到了4818条，并通过自动化的"分而治之"流水线保证了每条数据的质量。更重要的是，它设计了一套从根本上防止AI"看答案"的评测环境，让训练和评测都真正有意义。

对于普通用户来说，这项研究的影响可能还不会立竿见影地体现在日常使用的产品上，但它指向的方向非常清晰：未来的AI编程助手，将不仅仅是一个帮你修代码的"维修工"，而是一个能读懂你的需求文档、从头构建出整套软件的"架构师"。当这一天真正到来时，开发一个功能完整的软件项目所需要的人力和时间，将会发生根本性的变化。

这项研究同时揭示了一个更广泛的道理：数据的质量和多样性，在很多情况下比模型本身的规模更加关键。一个只见过简单修补任务的AI，即便参数量再大，面对从零建仓库的任务也会不知所措；而用精心设计的长视野数据训练的较小模型，却能追平甚至超越参数量大得多的通用大模型。这对整个AI研究领域都有参考价值：当某个任务上的AI表现不尽如人意时，与其一味扩大模型规模，不如先认真审视训练数据是否真正覆盖了这类任务所需的能力。

读到这里，你可能会好奇：这套流程需要多少人工干预？答案是几乎不需要——整个数据集的构建都是全自动完成的，没有人工标注。当然，自动化也意味着存在一些局限：文档的质量最终取决于生成模型（GPT-5.4/5.5）的能力，而生成模型对代码的理解可能存在盲点。如何进一步提升文档的准确性和完整性，以及如何将这套方法扩展到Python以外的其他编程语言，或许是后续研究值得探索的方向。

如果你对这项研究的完整细节感兴趣，可以在arXiv平台通过编号2606.10728找到原始论文，所有方法细节、实验数据和提示词模板都有完整记录。

---

Q&A

Q1：DeNovoSWE数据集和普通代码训练数据集有什么区别？

A：普通代码训练数据集大多围绕"修复单个bug"展开，相当于教AI做局部修补工作。DeNovoSWE则专门针对"从零生成完整软件仓库"这种更高难度的任务，每条训练数据都要求AI读懂一份完整文档然后重建整个项目，并且有真实的单元测试来客观验证结果是否正确。规模上，DeNovoSWE包含4818条样本，是此前同类最大数据集的46倍左右。

Q2：难度感知轨迹筛选策略为什么比固定门槛更有效？

A：固定门槛无法区分"轨迹通过率低因为任务很难"和"轨迹通过率低因为AI答得差"这两种情况。对困难任务用高门槛会丢弃大量有价值的数据；对简单任务用低门槛则会引入低质量答案。难度感知策略根据每个任务的难度动态调整门槛，既保留了困难任务中的有效探索，又对简单任务维持严格的质量控制，实验结果显示这种策略在两个测试基准上都取得了最佳成绩。

Q3：DeNovoSWE训练出来的模型能达到什么水平？

A：以Qwen3-30B-A3B为底座，未经训练的原始模型在BeyondSWE-Doc2Repo基准上只有5.8%，经过DeNovoSWE训练后提升到47.2%。以更强的Qwen3.5-35B-A3B为底座，训练后达到50.0%，与顶级商业闭源模型Gemini3-Pro的差距仅为2个百分点，与Qwen3.5-Plus的差距约为2.4个百分点，但使用的是参数量小得多的开源模型。