Repo0：设计驱动的零到全仓库代码生成 Repo0: Design-Driven Zero-to-All Code Generation
用双DAG表示仓库架构状态，以模块度指标引导结构持续演化，从自然语言需求直接生成完整代码库
前置知识
零到全代码生成（Zero-to-All Code Generation）
指智能体不依赖任何预置仓库骨架，仅从自然语言需求文档出发构建整个软件项目，且全程维持模块化的仓库架构。与函数级代码合成或仓库补全不同，它要求智能体同时推断软件的功能与架构，难度远高于既有设定。
这是本文要解决的核心任务，理解它与“仓库补全”“一次性架构规划”的区别是读懂全文动机的前提。
有向无环图（DAG）
一种边有方向且不存在回路的数据结构。本文用它同时表示需求级与组件级结构：需求图中边表示功能协调关系（两个需求常被一起考虑），组件图中边表示实现依赖（继承、复用、包含）。
双DAG 是 Repo0 架构状态的核心数据结构，所有结构动作与模块度指标都定义在这些图的节点和边上。
内聚与耦合（Cohesion & Coupling）
经典软件设计原则：内聚衡量一个模块内部职责的相关紧密程度，耦合衡量模块之间相互依赖的强度，理想系统应高内聚、低耦合。本文将两者量化为基于需求-组件对齐图的可计算指标。
结构演化循环中 split 与 merge 动作的触发条件直接由内聚阈值 $2/3$ 和耦合阈值 $0.7$ 决定，是整个方法的灵魂。
Jaccard 相似度
衡量两个集合相似程度的指标，定义为交集大小除以并集大小：$J(A,B)=|A\cap B|/|A\cup B|$，取值 0 到 1，越接近 1 表示两个集合重叠越多。
论文用两个组件所负责子需求集合的 Jaccard 相似度定义组件耦合度，是 merge 动作的核心判据。
测试驱动开发（TDD）
先写测试再写实现的开发流程：先固定公开 API 骨架，再生成测试用例，然后实现代码使测试通过，失败则触发局部修复。论文逐组件采用“骨架→测试→实现”三步。
Repo0 第三阶段的代码生成完全建立在 TDD 工作流之上，理解它才能明白验证反馈如何驱动局部修复。
最小割图划分
图论组合优化问题，目标是以最小边权代价把图切成若干部分，常用于聚类与社区发现。论文将组件所服务子需求构成的诱导子图视为最小割目标，为拆分动作提供候选分组证据。
split 是出现频率最高的结构动作，图划分为 LLM 重写组件边界提供了数学依据而非纯靠模型直觉。
研究动机
现有 LLM 代码智能体大多建立在“代码已完成架构设计”的假设之上：Commit0 要求智能体在预定义的仓库架构、文件布局和函数接口内补全缺失代码，NL2Repo-Bench 干脆把黄金仓库架构作为输入，RPG 等图规划方法虽在编码前生成显式的仓库规划图，却把它当作一次成型、此后 rigidly 执行的静态蓝图。真实开发并非如此：架构在初始规划阶段很少就绪，随着代码生成推进，“计划中的组件是否真正内聚”“依赖边是否过度纠缠”才逐渐显形，涌现的复杂性、重复功能和验证反馈常常要求拆分低内聚组件或合并冗余组件。缺乏架构演化的后果在实验中清晰可见：不维护仓库级一致性的 mini-SWE-agent 在较大仓库上 Pass Rate 掉到 0%–37.04%，一次性规划的 RPG 在 django 上的 Pass Rate 也只有 47.33%，呈现出不一致的组件边界、脆弱的依赖结构和糟糕的跨文件协调。
本文的目标是本文目标是提出面向零到全代码生成的设计驱动框架 Repo0：只给智能体一份自然语言需求文档，让它从空白状态出发构建完整、模块化的 Python 仓库。具体包括三点：其一，把仓库生成显式建模为连续结构演化问题而非一次性规划，架构状态在开发全程可被修改；其二，用双 DAG（需求级 DAG、组件级 DAG 加多对多对齐关系）作为持久架构状态，保证从最初用户提示到最终代码的可追溯性；其三，以软件工程模块度度量（内聚、耦合）配合图划分给出结构动作的客观触发条件与显式收敛判据，演化收敛后再进入 TDD 代码生成。最终在 RepoCraft 六个真实仓库、GPT-5 mini 与 DeepSeek V3.2 两种骨干上全面领先功能覆盖率与通过率。
与已有工作不同的是，独特切入在于对“架构何时可知”的重新回答。既有方法隐含假设仓库模块性可以从需求中一次性推断出来，本文则主张：仓库模块性只能从需求部分观察，其余部分在编码过程中才逐渐涌现，因此仓库生成本质上是连续结构演化问题。技术上体现为三个与已有工作不同的决定：一是用双 DAG 把“需求级功能协调关系”与“实现级依赖”分开建模，避免二者在单一静态规划图中被混为一谈；二是把经典结构化设计度量（内聚密度、Jaccard 耦合）转化为 LLM 结构动作的触发器和终止条件，而不是让模型自己决定何时停止重构；三是用最小割图划分给拆分动作提供候选分组证据。RQ3 的对照实验直接支撑这一视角：无约束的 LLM 自主演化会过度分解架构，固定 1/3/5 轮预算的变体均劣于度量引导的收敛。
核心方法
直觉上 Repo0 像一位“先画草图、再不断重构”的资深架构师：先用需求文档搭出初始架构，再依据模块度反复调整组件边界，直到没有值得改的地方才动笔写代码。技术路线分三阶段。Phase I 把需求文档 $D$ 转成初始架构状态 $S_0=(G^R_0, G^C_0, A_0)$：抽取能力级候选需求并合并为高层需求，经 reasoning-then-labeling 三步分解为子需求并标注功能协调边，形成需求级 DAG；再把子需求落地为带职责描述的组件，推断组件间实现依赖，建立初始组件级 DAG 与多对多对齐 $A_0$。Phase II 固定需求图 $G^R_t$，通过 split/merge/revise/save 四种结构动作迭代演化组件图与对齐关系，由内聚与耦合指标触发，直到一整轮没有 eligible 动作即达到结构收敛。Phase III 将收敛后的组件图转成生成计划（包分配、文件路径、导出符号、依赖感知的生成顺序），按 TDD 工作流逐组件生成骨架、测试与实现，验证失败触发局部修复。
核心创新是把仓库架构从“一次性规划产物”变成“持久可演化状态” $S_t=(G^R_t, G^C_t, A_t)$，并以可计算的模块度指标驱动其演化。与最近邻 RPG 的本质区别有三：第一，RPG 的 Repository Planning Graph 生成后即固定为蓝图，Repo0 的组件级 DAG 与对齐关系在编码开始前持续被 split（拆低内聚组件）、merge（并高耦合组件）、revise（改职责描述与接口假设）、save（标记稳定）改写；第二，需求图的边表示“功能协调”（两个需求应被一起考虑）而非实现依赖，组件图的边才是继承/复用/包含，两图分离使功能与实现各自演化、互不污染；第三，收敛判据显式给出：内聚低于 $\gamma_{split}=2/3$ 且职责数超阈值触发拆分，两组件子需求集合的 Jaccard 耦合超过 $\theta_{merge}=0.7$ 且需求连通性大于 1 触发合并，整轮无动作即收敛。RQ3 证明收益来自“正确的结构判据”而非“更多的精化轮次”。
方法步骤详情
Phase I：(1) 从文档 $D$ 抽取能力级候选需求；(2) 合并冗余项为高层需求；(3) 对每个高层需求执行 reasoning-then-labeling：先让 LLM 详述预期行为与接口预期，再识别子需求，最后标注“v 逻辑上依赖 u”的有向边，汇总为 $G^R_0$；(4) 将子需求落地为带职责与所服务子需求清单的组件构成 $V^C_0$，每个服务关系建立对齐对 $(q,c)\in A_0$；(5) 以需求协调边为软证据推断组件依赖得到 $E^C_0$。Phase II 每轮重算指标：组件 $c$ 的职责集 $RS(c)=\{q\in V^R_t\mid(q,c)\in A_t\}$，内聚 $cohesion(c)=E_{in}(c)/(|RS(c)|(|RS(c)|-1)/2)$ 低于 $2/3$ 且 $|RS(c)|$ 超阈值时，最小割图划分给出候选分组、LLM 重写拆分；组件对 $A,B$ 耦合 $coupling(A,B)=|R_{SA}\cap R_{SB}|/|R_{SA}\cup R_{SB}|$ 超过 $0.7$ 且需求图桥接边大于 1 时经 LLM 裁决合并；整轮无动作即收敛，再做语义对齐 pass 修正。Phase III：从收敛组件图导出生成计划，逐组件按 TDD 生成骨架、合成测试、填充实现，检查失败触发局部修复。
技术新颖性
技术新颖性体现在四个层面。问题形式化上，首次把零到全仓库生成表述为连续结构演化问题，并论证“模块度只能部分从需求观察、在编码中涌现”，直接挑战 RPG 等一次性规划范式的理论根基。知识表示上，双 DAG 加多对多对齐关系同时保留需求侧功能协调与实现侧依赖，并维持从用户提示到代码文件的全链路可追溯——案例研究中 StatModeler 的 39 个高层需求、92 个子需求最终对齐到 86 个实现组件并物化为具体文件。算法机制上，把 1974 年 Stevens 等人的结构化设计原则操作化为可计算的演化触发器：内聚用子需求协调密度衡量，耦合用 Jaccard 相似度衡量，拆分候选由最小割图划分提供证据、由 LLM 落地重写，形成“度量选点、LLM 执行”的混合决策。实证上，消融与结构演化分析首次分离了“更多精化轮次”与“正确收敛判据”的贡献，发现无约束 LLM 演化会过度分解架构并损害下游正确性。
实验结果
RQ1：六仓库×双骨干的全部设置中，Repo0 的覆盖率与 Pass Rate 均为第一。GPT-5 mini 下：requests 覆盖 100.00%（RPG 90.91%）、Pass 50.98%（31.51%）、Voting 100%；statsmodels 覆盖 80.68%、Pass 85.51%（RPG 70.40%/77.90%）；django 覆盖 80.50%、Pass 74.36%（RPG 60.42%/47.33%）。DeepSeek V3.2 下：requests Pass 78.08%、statsmodels 69.03%、django 74.07%（RPG 对应 61.64%/39.29%/46.50%）。相对 RPG，覆盖率提升 4.55–20.08、Pass 提升 7.61–29.74 个百分点（金牌项目 Pass 94.12%–96.34% 仍是上限）。RQ2 消融证明四个设计均必要：去掉结构演化损失最大（requests Pass −8.47/Voting −17.86、django Pass −13.33）；去掉需求上下文 django Pass −10.00；去掉依赖感知生成顺序 statsmodels Pass −30.00。RQ3：度量引导收敛全面优于不演化（覆盖率 75.90%→80.68%、Pass 81.90%→85.51%、Voting 93.00%→98.65%），且优于固定 1/3/5 轮的 LLM 自主演化——超一轮后正确率回落，说明无判据重构会过拆分。动作分布 split 主导、save 次之；DeepSeek 下生成成本 $11.95–$28.19，多数设置低于 RPG。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 仓库生成 requests（HttpEasy，GPT-5 mini） | Functionality Coverage (%) | 100.00 | RPG 90.91；mini-SWE-agent 68.18；Paper2Code 95.50 | 较最强基线 RPG +9.09 pp |
| 仓库生成 django（PyWebEngine，GPT-5 mini） | Functionality Coverage (%) | 80.50 | RPG 60.42 | +20.08 pp |
| 仓库生成 django（GPT-5 mini） | Pass Rate (%) | 74.36 | RPG 47.33 | +27.03 pp |
| 仓库生成 statsmodels（StatModeler，DeepSeek V3.2） | Pass Rate (%) | 69.03 | RPG 39.29 | +29.74 pp |
| 仓库生成 statsmodels（GPT-5 mini） | Voting Rate (%) | 98.65 | RPG 92.00 | +6.65 pp |
| 仓库生成 requests（DeepSeek V3.2） | Functionality Coverage (%) | 100.00 | RPG 95.45 | +4.55 pp |
局限与改进
作者承认两点：其一，结构更新质量依赖骨干 LLM 的架构推理能力——模块度指标只负责挑选候选动作，具体重写组件边界、职责描述与接口假设仍由 LLM 完成，弱模型可能改错（通过多轮演化和 revise 部分缓解）；其二，实验限于 RepoCraft 六个 Python 仓库，单一语言与基准，跨语言泛化有待验证。我的补充观察：主实验只报告了 requests/statsmodels/django 三个仓库，其余三个（含最大的 sympy 与 pandas）结果放在补充材料，正文可核验性打折；阈值 $\gamma_{split}=2/3$、$\theta_{merge}=0.7$ 是在 Commit0 Lite 的两个 held-out 仓库（wcwidth、sphinx）上靠人工比对黄金架构选出的经验值，迁移性未知；Pass Rate 距金牌项目仍有约 10–20 个百分点差距，结构演化并未消除实现正确性瓶颈；结构演化只发生在编码之前，编码期发现的结构问题只能靠局部修复兜底；评估依赖跨模型语义投票与测试改写，本身引入噪声；django 上总成本 $100.06，其中评估占 $72.82，规模化评测的成本仍偏高。
独立分析的弱点
独立分析四点弱点。第一，设计与实现两阶段解耦：结构演化在代码生成前一次性收敛，TDD 阶段发现的架构级问题（如接口假设系统性错误）只能触发组件内修复或 revise，无法重新打开 split/merge，遇到“实现揭示真实边界”的场景会失效——改进方向是把验证反馈流回结构演化循环，形成贯穿编码全程的架构重构。第二，模块度度量是需求侧代理指标：内聚只看子需求协调密度、耦合只看子需求集合重叠，完全不感知代码级信号（循环依赖、扇入扇出、重复实现），可能与真实代码质量脱节——可引入代码级度量做多目标演化。第三，超参脆弱：$2/3$ 与 $0.7$ 来自两个小仓库的人工调参，$\tau_{split}(t)$ 随时间变化的机制刻画有限，换域可能需重调——建议自适应阈值或基于历史动作收益的学习式判据。第四，需求图 $G^R_t$ 早期即固定，需求理解偏差只能在演化期靠 add 动作补救，需求遗漏会级联传导到整个架构——可让需求侧也随验证证据持续演化。
未来方向
作者明确提出的方向是把架构状态、结构动作与模块度度量推广到其他语言生态与基准，验证框架的语言无关性（三个核心组件都定义在仓库架构层面而非语言语法上，具备可行性）。基于本文成果还可延伸：其一，把“度量选点、LLM 执行”的混合决策增强为可学习的结构策略，例如以最终 Pass Rate 为奖励做强化学习，摆脱手工阈值；其二，实现演化—编码交替的在线重构，让 TDD 失败模式（缺符号、签名不兼容、行为不符）直接映射为结构动作建议；其三，利用双 DAG 的对齐关系做需求变更影响分析与增量开发，新需求到来时只演化受影响的子图；其四，针对评测成本（django $100.06 中 $72.82 是评估开销）研究更便宜的代理指标与早停策略；其五，把“模块度度量作为 LLM 终止信号”这一思想迁移到测试生成、架构恢复、代码评审等相邻任务，检验其普适性。
复现评估
复现条件较好：代码与数据开源于 https://github.com/cslsolow/Repo0，补充材料提供全部六仓库结果与完整成本明细；基准 RepoCraft、基线 mini-SWE-agent/Paper2Code/RPG、跨模型评估管线均公开；双骨干覆盖闭源（GPT-5 mini）与开源（DeepSeek V3.2）。实验设置友好：温度 0 确定性解码、每设置 3 次独立运行取平均、超参 $\gamma_{split}=2/3$ 与 $\theta_{merge}=0.7$ 已在论文中给出。算力上无需任何训练，成本主要是 API 调用：DeepSeek 下每仓库生成 $11.95–$28.19、评估最多 $72.82（django），用 GPT-5 mini 复现整套实验估计需数百美元。主要风险是 LLM 非确定性带来的波动（结构演化是多轮长链决策，对提示词敏感）以及评估管线中语义投票、测试改写的实现细节；“演化架构与黄金架构的人工比对”也难以完全复刻。总体属于中等难度复现：工程量大但路径清晰。
论文图表
对比图：上半部分是旧范式——需求图经一次性规划得到固定图，随即直接生成代码，伴随低内聚、高耦合、内部泄漏等问题；下半部分是 Repo0——先由需求得到初始图，智能体在验证/执行反馈驱动下执行 split/merge/revise 动作，图在生成过程中持续演化，最终内聚更高、耦合更低、信息隐藏更好。
一图点明论文核心论点：架构不应是一次性蓝图而是持续演化的状态，是理解全文动机的入口。
列出 RepoCraft 六个仓库的规模与任务量：scikit-learn→MLKit-Py（185 文件/65,972 LOC/236 任务）、pandas→TableKit（217 文件/106,447 LOC/175 任务）、sympy→SymbolicMath（699 文件/218,924 LOC/192 任务）、statsmodels→StatModeler（271 文件/83,325 LOC/234 任务）、requests→HttpEasy（17 文件/2,793 LOC/50 任务）、django→PyWebEngine（681 文件/109,457 LOC/165 任务），仓库均以改写名称暴露以减少预训练泄漏。
界定了评测的规模跨度（2,793 到 218,924 行代码）与难度，是理解实验设置和结果适用范围的基础。
主结果表：requests/statsmodels/django 上四种方法在双骨干下的覆盖率、新颖率与 Pass/Voting。Repo0 在 GPT-5 mini 下取得 100.00/80.68/80.50 的覆盖率和 50.98/85.51/74.36 的 Pass 率，全面领先 RPG（90.91/70.40/60.42 覆盖率、31.51/77.90/47.33 Pass）；DeepSeek V3.2 下趋势一致；人工金牌项目 Pass 为 94.12/94.15/96.34 作为管线验证参照。
核心证据表，支撑“全部设置最优”的 RQ1 结论，并量化了与最强基线 RPG 及金牌项目之间的差距。
消融表：在三个仓库上分别去掉结构演化、需求上下文、组件图生成顺序、双 DAG 表示后的表现。去掉结构演化整体损失最大（requests Cov −5.68/Pass −8.47/Voting −17.86，django Pass −13.33）；去掉需求上下文 django Pass −10.00；去掉依赖感知生成顺序 statsmodels Pass −30.00；去掉双 DAG requests 覆盖 −4.55、Voting −12.14。
逐项验证四个设计选择的必要性，并指出结构演化是收益最大的组件，与 RQ3 的收敛分析互为印证。