Repo0: Design-Driven Zero-to-All Code Generation —— 精读

• 论文链接：https://arxiv.org/abs/2608.19854
• 代码仓库：https://github.com/cslsolow/Repo0
• 发表时间：2026 年 8 月（arXiv 2608.19854v1，2026-08-20 提交）
• 发表机构：上海交通大学（7 位作者，主导）＋重庆大学（Hongyu Zhang，纯高校合作，无企业参与）
• 作者：Silin Chen*、Haoyi Teng*（共同一作）、Xiaodong Gu†（通讯作者）、Yuling Shi、Jiale Huang、Yongpan Wang、Hongyu Zhang、Haibing Guan

一、论文背景

1.1 代码生成 Agent 的『半路接手』假设

过去几年，LLM 代码生成 Agent 进步飞快：SWE-bench 上的 issue 修复、仓库级代码补全、跨文件协同编辑……但这些系统几乎都建立在一个隐含假设上——仓库的架构已经设计好了。Agent 接手时，模块边界、包结构、依赖关系图这些关键设计决策早已确定，它只需要在既定骨架里填代码。

这就像一个装修工人走进一栋已经封顶、砌好隔墙的大楼，只需操心水电和内饰。可现实中还有一类更极端的任务：手里只有一张写着需求的纸，要凭空盖起整栋楼。

1.2 Zero-to-All：从一句话到一个仓库

论文把这类任务命名为 zero-to-all 代码生成：不提供任何预置仓库架构，仅从自然语言需求文档出发，从零构建一个完整的、模块化的软件仓库。

它的难点是双重的：Agent 必须同时推断软件的功能（做什么）与架构（怎么组织）。这好比让你只根据『我要一个能订票、支付、退改签的 App』这样的描述，既要写出全部代码，还要自己决定该分成哪些模块、谁依赖谁、每个文件放在哪。而且好的软件必须满足软件工程的黄金原则——高内聚、低耦合。缺乏显式架构引导的 Agent 常常产出边界混乱、依赖纠缠、跨文件协调脆弱的『一团面条』。

1.3 核心矛盾：架构在动工之前定不下来

已有工作开始触碰这个问题，但都栽在同一个坑里：把软件设计当成静态产物。它们假设一次初始规划就能产出完美蓝图，然后僵硬执行。可真实世界的软件开发几乎从不这样运作——架构是涌现的：写着写着才发现某个组件职责太杂该拆、两个模块功能重叠该合、某条依赖边根本是多余的。一次性规划必然留下低内聚、高耦合、内部实现泄漏的隐患。

于是论文的核心论点出现了：zero-to-all 代码生成的瓶颈不在写代码本身，而在全程建立并维护仓库的模块度；它不是一个一次性规划问题，而是一个连续的结构演化问题。

二、论文定位和关联工作

2.1 基准演进：结构先验一步步卸下

这条脉络的方向非常清晰：给 Agent 的结构先验越来越少，方法必须学会自己从需求里长出架构。

2.2 方法演进：从角色流水线到规划图

• 多 Agent 流水线（ChatDev、MetaGPT、SoA）：用自然语言和预定义流程串联规划与实现，中间产物是无结构的文本；
• 分层草稿（CodeS、Paper2Code）：先出仓库级／文件级／函数级草图再细化，但架构仍是生成一次、执行到底；
• EvoMAC：按环境反馈演化多 Agent 协作拓扑，演化的是『谁和谁合作』而非『代码怎么组织』；
• RPG（最强基线）：引入 Repository Planning Graph，显式表示能力、文件结构、数据流与函数，把仓库生成从纯文本规划推进到图引导规划。

2.3 Repo0 与 RPG：一字之差，范式之别

RPG 把图当照片，Repo0 把图当视频。

三、问题定义

论文将 zero-to-all 仓库生成形式化为连续结构演化问题，核心是维护一个随时间 t 演进的架构状态：

S_t = (G_R^t, G_C^t, A_t)

• G_R^t：需求级 DAG。节点是高层需求及其子需求；边表达的是功能协调关系——两个需求在逻辑上会一起被使用，对齐行为、输入输出时应联合考虑。注意：这不是实现依赖，『注册账号』和『发送欢迎邮件』功能上强相关，但代码上可能分属两个模块。
• G_C^t：组件级 DAG。节点是可以落地成源码的组件（模块、解析器、适配器、服务层……），每个组件代表一个有界的实现职责；边表达实现依赖（继承、复用、包含）。
• A_t：多对多对齐关系。A_t ⊆ V_R × V_C，记录『哪个组件实现了哪条需求的全部或部分』。一个需求可能要多个组件协同实现，一个可复用组件也可能支撑多条需求。它是从需求到代码全程可追溯性的保证。

演化过程中 G_R 通常很早稳定（功能范围锁定），而 G_C 和 A_t 持续更新直到模块度达标。目标因此是双重的：既捕获跨仓库的长上下文关系以正确生成代码，又在全生命周期内建立并改进仓库模块度。

四、问题解法

Repo0 的完整生命周期分三个阶段。一个贴切的类比：Phase I 是画初稿图纸，Phase II 是反复拆改非承重墙直到户型合理，Phase III 才进场精装修。多数现有方法跳过 Phase II 直接装修，户型不合理就只能在装修时打补丁。

4.1 Phase I：需求分解与初始架构

从需求文档 D 到初始状态 S_0，分五步：

1. 抽取候选需求：LLM 按『每条描述一个仓库级能力或系统约束、包含相关操作与子特性、不把低层操作拆成顶层条目』的规则抽取；
2. 合并成高层需求（HLR）：合并冗余与被包含项，HLR 只是分解锚点，不对应文件或模块；
3. 推理后标注分解子需求：受 Atom of Thoughts 启发的三段式——先让 LLM 尽可能详尽地扩写需求（预期行为、输入输出、约束、接口期望、错误情形、模糊边界），再基于丰富描述识别子需求（只说清『要什么功能』，不指定文件类库），最后标注子需求间的逻辑依赖边，形成局部需求 DAG；
4. 生成初始组件与对齐：把每个 HLR 的子需求翻译成一组有界组件（名称＋职责描述＋所服务的子需求清单），组件入 G_C，服务关系入 A_0；
5. 推断组件依赖：LLM 推断组件间必须存在的实现依赖初始化 E_C。需求图的协调边只作软证据参考，不直接照抄到组件图——这是双图分离原则的第一次落地。

论文用一个 HttpEasy（requests 的化名）仓库示例演示了全流程：候选需求（HTTP 方法助手、查询/表单/JSON 体、multipart 上传……）合并为 HLR，分解出『请求构造→传输执行→响应解析』的协调链，再落地为 RequestBuilder、TransportAdapter、ResponseParser 等组件。

4.2 Phase II：模块度引导的结构演化（核心创新）

此阶段 G_R 冻结（保住功能范围），G_C 与 A_t 通过五类结构动作演化：

两类模块度指标是发动机：

内聚度——组件 c 所辖子需求集合 RS(c) 内部，需求图实际边数占可能边数的密度：

cohesion(c) = E_in(c) / (|RS(c)|·(|RS(c)|−1)/2)，|RS(c)|≤1 时取 1

好比一个部门内部员工的『协作密度』：分到一个组件里的需求如果彼此毫无协作，说明它们只是被硬塞进同一个抽屉——内聚度低于阈值 γ_split = 2/3 就触发拆分候选。拆分怎么拆？Repo0 对该组件诱导的子需求子图跑图分割（视为最小割目标），用图割结果作为证据交给 LLM 重写组件边界——图算法提供证据，LLM 执行改写，而非让 LLM 拍脑袋。

耦合度——两个组件 A、B 所辖子需求集合的 Jaccard 相似度：

coupling(A,B) = |RS_A ∩ RS_B| / |RS_A ∪ RS_B|

两个组件服务的需求高度重叠，说明职责切重了——耦合度超过 θ_merge = 0.7 且需求图上跨两组件的连通边多于 1 条，成为合并候选。但指标可能误伤合法的分层、适配器、上下游关系，所以最终由 LLM 复核裁决。

收敛判据是整个框架最妙的一笔：当一整轮演化下来没有任何符合条件的 split 或 merge 动作，即宣告结构收敛。收敛后再做一次全局语义对齐检查，用 revise 修正组件职责、需求覆盖与接口假设间的不一致。两个阈值在 Commit0 Lite 的两个 held-out 仓库（小规模 wcwidth、大规模 sphinx）上对照黄金架构人工选定，不与评测集混用。

4.3 Phase III：收敛架构之上的 TDD 代码生成

架构收敛后冻结，转入代码生成：先把 G_C 转成具体生成计划（包分配、文件路径、导出符号、依赖感知的生成顺序），再对每个组件以三源上下文（职责描述＋对齐的需求节点＋必须先就位的上游组件）执行 TDD 工作流：先生成可导入的骨架钉死公共 API → 从对齐需求合成测试 → 填实现过测试。每步之后跑导入检查、接口检查与 pytest；失败触发局部修复补丁；若发现组件描述本身有误，可先 revise 再进入下一轮 TDD。

五、评估指标与实验证据

5.1 基准、基线与指标

实验基于 RepoCraft 六个真实 Python 仓库（全部改名防预训练泄漏），且作者请两位工程师改写任务描述，剔除所有仓库结构线索与函数级接口细节，只保留功能需求——让设定真正对齐 zero-to-all：

基线三类：mini-SWE-agent（直接编码 Agent）、Paper2Code（分阶段多 Agent）、RPG（图规划 SOTA），另报 Gold Project 作参照。骨干模型双份：GPT-5 mini（闭源）与 DeepSeek V3.2（开源），温度 0，每组三跑取均值。指标沿用 RPG 管线：Functionality Coverage（参考功能类被覆盖比例）、Functionality Novelty（生成物中未被参考类匹配的多余功能比例）、Pass Rate（改造后的真值测试在生成仓库上的通过率）、Voting Rate（多数投票语义评审找到匹配接口的任务比例）。为防评审偏置，采用交叉模型评审：DeepSeek 评 GPT-5 mini 的产出，反之亦然。所有方法共享同一套下游 TDD 生成/验证/修复脚手架，唯一变量是仓库架构从哪来。主实验报 requests（轻量）、statsmodels（中等）、django（大型）三仓，其余在补充材料。

5.2 RQ1 主结果：全设置制霸

GPT-5 mini 下三仓成绩：

DeepSeek V3.2 下同样全部夺魁（如 requests 100.00/78.08，django 79.17/74.07）。六仓库 × 双骨干的全部设置中，Repo0 均取得最高 Functionality Coverage 与 Pass Rate；Voting Rate 六个设置也全部第一。对最强基线 RPG：Coverage 提升 4.55～20.08 个百分点，Pass Rate 提升 7.61～29.74 个百分点——GPT-5 mini 下 requests Pass Rate 50.98 vs 31.51（+19.47），django +27.03；DeepSeek 下 statsmodels Pass Rate 69.03 vs 39.29（+29.74）。基线各有短板：mini-SWE-agent 大仓库上保不住全局一致性；Paper2Code 新颖度虚高但换不来正确性；RPG 虽验证了显式规划的价值，复杂仓库上仍明显退化。

5.3 RQ2 消融：四件设计缺一不可

去结构演化伤得最重且三仓全退——连续演化架构状态的价值坐实。去组件图依赖序在 statsmodels 上 Pass Rate 暴跌 30 个点：仓库越复杂，按依赖拓扑顺序生成越关键。去需求上下文主要伤正确性（相邻需求的协调信息帮助保持跨功能行为一致）。去 Dual-DAG 合成单图则覆盖或正确性总有一头受损。还有个反直觉发现：部分消融变体在 statsmodels 上 Novelty 反而更高——多余功能变多了，恰好说明它们以牺牲忠实实现为代价乱生功能。

5.4 RQ3 收敛分析：指标引导优于 LLM 自决

在 statsmodels（GPT-5 mini）上对比四种替代方案：不演化（直接用初始架构）与固定预算的 LLM 自决演化（允许 1/3/5 轮，不用内聚/耦合指标判断该动谁、何时停）。结果 Repo0 全面最优：从不演化的 Cov 75.90%→80.68%、Pass 81.90%→85.51%、Voting 93.00%→98.65%；更重要的是它打赢了所有给了额外演化轮数的自决变体——收益不来自『多改几轮』，而来自指标把架构真正推向收敛。LLM 自决缺显式停机判据，改过收敛点还在继续拆——第 1 轮之后覆盖率、通过率、投票率集体下滑，过度分解让仓库离合理边界越来越远。

动作分布上，两骨干均以 split 为主、save 次之，merge/revise/add 较少——演化主要是组件边界的局部更新，且不少初始组件本来就稳。GPT-5 mini 触发 revise/add 更频繁；控制变量实验（固定同一个 GPT-5 mini 初始架构，分别用两骨干演化）显示 DeepSeek 此时的 revise 数与 GPT-5 mini 几乎相同——动作分布取决于初始架构质量而非骨干模型，初始描述越含糊，revise 越重要。

5.5 成本：好结构反而更便宜

DeepSeek V3.2 下 Repo0 生成成本为 requests $11.95、statsmodels $28.19、django $27.24（django 评测开销 $72.82 占大头，总计 $100.06）。对比 RPG：requests 与 statsmodels 生成开销分别高出 +$9.32 与 +$35.59（django 低 $8.83）；GPT-5 mini 下 Repo0 生成成本三仓全低于 RPG。原因很直白：内聚高、耦合低的结构从源头减少了需要生成与修复的冗余、冲突代码，昂贵的 TDD 修复迭代自然更少。

六、效果优势的根源解释

Repo0 的优势可以还原成一条清晰的因果链。

第一层：从『静态一次性图规划』到『可演化架构状态』。 RPG 们的图是开工前的快照，初始规划的误差被原封不动锁进整个仓库；Repo0 把架构变成持久状态 S_t，允许在证据（分解质量、模块度指标、验证反馈）涌现时持续修正。消融里去掉结构演化后 requests Pass −8.47、django Pass −13.33，正是这条链的因果证据。

第二层：用显式量化指标＋收敛判据取代 LLM 自决。 LLM 自己决定『拆谁、合谁、何时停』时，没有客观的停机信号，结构动作会越过收敛点继续过度分解——固定预算实验中 1 轮之后即退化就是直接证据。内聚度（密度 <2/3 拆）与 Jaccard 耦合度（>0.7 合）把 1974 年结构化设计文献里的『高内聚低耦合』变成可计算、可触发的硬规则，再配『一整轮无拆合动作即收敛』的判据，演化有了明确的终点。这是把软件工程先验注入 Agent 决策环、约束 LLM 自由度的典范。

第三层：双图分离与依赖序放大结构收益。 功能协调关系（需求图）与实现依赖关系（组件图）本来就是两种语义，混在一张图里会互相污染——消融显示合并单图后各仓至少一项指标受损；多对多对齐关系则保证需求→组件→文件全程可追溯，TDD 测试可直接从对齐需求合成。收敛后的组件 DAG 提供依赖拓扑序，statsmodels 去掉它 Pass −30.00，说明复杂仓库里『先有地基再砌墙』的顺序本身就是正确率的来源。

此外还有一个自洽的经济学解释：模块度好的架构让每个组件的职责单一、接口清晰，TDD 骨架与测试更准，修复迭代更少——结构质量兑换成了金钱成本。

七、必要知识反推

若想复现或超越这篇工作，需要哪些知识储备？

领域知识层：软件工程的结构化设计原理——高内聚低耦合（Yourdon & Constantine 1977、Stevens et al. 1974）是全文指标的源头，不掌握就无法理解内聚/耦合定义为何长这样；仓库级代码生成的任务谱系（补全 vs 从零构建），决定了问题设定的合法性。

方法论知识层：图论工具箱——DAG 建模、图分割与最小割（Wagner 1993）为 split 提供候选划分证据；Jaccard 相似度（1996）量化集合重叠；Atom of Thoughts 的推理分解范式支撑需求拆解；TDD（Kent Beck）纪律支撑生成阶段。还有评测方法学——交叉模型评审防评估偏置、held-out 调参防阈值泄漏、三跑取均值抗随机性。

工程知识层：LLM Agent 的提示工程与状态管理——如何让 LLM 在图状态上可靠执行结构动作；导入/接口/pytest 三级验证脚手架的搭建；成本核算纪律（生成与评测分开记账）。

知识融合的关键节点：把『软件的模块度可以被图密度与集合重叠度量化』这一老洞见，嫁接到『LLM Agent 的自主结构决策需要外部判据约束』这一新问题上——只懂软件工程会停在指标定义，只懂 LLM 会再做一次自决演化，两者接通才有 Repo0。

八、论文中可以提取的通用性灵感

1. 设计是过程，不是产物。架构、计划、方案都不该在开工前一次性冻结，而应作为可演化的持久状态随证据持续修正。推广：产品路线图应随用户反馈演化；科研方案应随实验证据修订；任何长时程任务的中间表示都值得设计成『活的』。

2. 用显式量化指标＋收敛判据约束自主决策。LLM 自由发挥的结构动作会越过最优点继续退化；『密度低于 2/3 拆、重叠高于 0.7 合、一整轮无动作即停』证明：给自主系统装上可计算的触发器与停机条件，比给它更多轮数更有效。推广：自动化流程的准入/退出规则、AI 写作的字数与结构约束、投资再平衡的阈值纪律。

3. 关注点分离＋多对多对齐，保住全程可追溯性。需求图与组件图分开维护、用对齐关系连接，避免了两种语义互相污染，又让每条需求都能追到实现它的代码。推广：需求-任务-代码的工程管理映射、政策-执行-效果的政策追踪、课程目标-教学活动-考核的对齐设计（Constructive Alignment）。

4. 图算法提供证据，LLM 执行决策。split 由最小割给出候选划分、由 LLM 重写边界；merge 由 Jaccard 提名、由 LLM 复核合法耦合。经典算法的客观性与 LLM 的语义灵活性各司其职——让确定性工具当检察官、让模型当执行者，比全交给模型或全交给规则都强。推广：检索器+生成器、静态分析+AI 修复、规则引擎+大模型兜底。

5. 上游结构质量决定下游成本。内聚/耦合的改善直接减少了冗余代码生成与 TDD 修复迭代，省钱是结构好的副产品。推广：数据管道里早清洗胜过晚修补、组织架构清晰胜过流程补救、磨刀不误砍柴工的现代化版本——在结构层多花的每一分钟，都会在修复层省回来。