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

论文链接：Repo0: Design-Driven Zero-to-All Code Generation 代码仓库：cslsolow/Repo0 发表时间：2026年8月（arXiv 2608.19854，2026-08-20 提交；Hugging Face Daily Papers 08-21 批次，15 票） 机构：上海交通大学、重庆大学（作者：Silin Chen、Haoyi Teng、Xiaodong Gu、Yuling Shi、Jiale Huang、Yongpan Wang、Hongyu Zhang、Haibing Guan） 领域标签：软件工程（cs.SE）、人工智能（cs.AI）

一、论文背景：从"填空"到"从零到全"，中间隔着一张架构图

要理解这篇论文在解决什么问题，得先看看代码生成这个领域一路走来的谱系。

最早的一批代码生成基准，比如大名鼎鼎的 HumanEval，考的是"函数级生成"：给一个函数签名和文档字符串，让模型补全函数体。这更像是考试里的填空题——上下文齐全，边界清晰，写完就算交卷。

接着是 SWE-bench 系列，把难度升级到"仓库级修改"：给模型一个真实 GitHub 仓库、一个 issue 描述和一段报错，让它定位并修掉一个 bug，还要通过仓库自带的真实测试。这时候模型已经开始接触真实仓库的结构——但它拿到的是一个已经存在的仓库。组件怎么划分、包怎么组织、模块之间谁依赖谁，这些决策早已由人类开发者完成。模型的任务是在既定骨架里做一次外科手术。

再往前一步，是 RepoCraft 这类**“零到全”（zero-to-all）生成基准：输入只有一份自然语言需求文档（类似项目的 README），要求模型从零构建出整个可运行的软件仓库**——不只是把功能写出来，还要同时决定整个项目的架构：有哪些组件、每个组件的边界在哪、谁依赖谁、需求如何分配到组件上。

这一步跳跃的难度常被低估。打个比方：填空式生成像是"拿着别人画好的建筑图纸，往指定房间砌墙"；零到全生成则是"客户只说了一句’我要一栋能住两百人的公寓’，你既要决定户型布局、承重结构、水电走向（架构），又要真的把楼盖起来（功能）"。功能与架构必须同时推断，而且互相纠缠——你怎么分房间，直接决定了每堵墙怎么砌。

这就引出了本文的核心命题：**软件架构设计在真实开发中扮演什么角色？**做过真实软件工程的人都明白一条铁律：架构很少在项目第一天的规划文档里就完全定型。需求里的描述是含糊的、粒度不齐的；很多模块边界是在写代码的过程中才"涌现"出来的——写着写着发现这两个类老是一起改（该合并），或者发现这个模块承担了三件不相干的事（该拆开）。高内聚、低耦合的模块化架构，是全生命周期持续维护出来的，不是一次规划画出来的。

而现有代码生成方法恰恰把软件设计当成静态制品：先一次性规划一张蓝图，然后僵化执行。这张蓝图如果在初始时刻就有结构性错误——组件边界画错了、需求归错了组——后续生成无论多努力，都是在错误的地基上盖楼。这就是"零到全"生成的核心瓶颈：如何在全生命周期内维持仓库的模块化。

二、论文定位和关联工作：一张持续修正的图，对一张一次成型的图

围绕仓库级代码生成，已有工作可以粗略分为几条路线。

第一条：无规划的 agent 直接开发。 代表是 mini-SWE-agent，一个单 agent 不断迭代读代码、写代码、跑测试。它灵活，适合在已有仓库里修修补补，但没有显式的结构规划，面对零到全任务时"走一步看一步"，大仓库上表现崩塌（后文会看到它在 statsmodels 上 Pass Rate 直接归零）。

第二条：面向科研代码的静态规划。 Paper2Code 从论文出发规划代码结构再生成，能产出结构新颖的项目，但"规划得好看"不等于"代码正确"，新颖性很少转化为正确性。

第三条：图规划的一次性生成。 代表是 RPG（Repo-by-Planning-Graph 类方法），先用 LLM 规划一张依赖图，再按图生成整个仓库。这是 Repo0 之前最强的仓库规划基线。它的关键问题正是本文攻击的靶心：图是静态的，规划一次、生成一次，编码过程中发现架构不对也不回头改图。仓库越复杂，初始规划的错误积累越多，退化越明显。

第四条：给定金架构的评估。 NL2Repo-Bench 在评估需求到仓库的生成时直接提供"金架构"（golden architecture），等于跳过了设计环节——这也侧面说明社区此前默认"架构设计太难，先绕开"。

第五条：多 agent 系统。 用产品经理、架构师、程序员等角色分工协作，结构信息隐式存在于角色分工中，但没有显式的、可演化的结构状态表示，难以追溯和修正。

Repo0 与它们的关系可以总结成一张表：

一句话定位：RPG 把设计当名词（一张画好的图），Repo0 把设计当动词（一个持续修正的过程）。Repo0 站在 RPG 的延长线上，把"规划"这一步从静态前置环节，改造成了贯穿生成全过程的演化循环。

三、问题定义：模块化是涌现的，不是可预先全知的

论文的第一个关键洞察值得单独拿出来讲：仓库的模块化结构，只有一部分能从需求文档里观察出来，另一部分要在编码过程中才会显现。

为什么？需求文档是人类意图的自然语言描述，它天然携带了一部分功能聚类信息（“认证相关的需求"读起来就该聚在一起），但它不包含实现层面的耦合信息——两个需求在语义上毫无关系，实现时却可能共享同一套数据结构；一个需求看起来是一件事，实现时才发现是三件不相干的事。这些信息只有动手写代码、跑测试时才会暴露。

这个洞察直接推出一个结构性结论：**任何在 t=0 时刻一次性产出完整架构的方法，都必然带有无法自我修正的结构性错误。**错误不在"规划得不够认真”，而在"规划"这个动作的时点本身——你在信息还不齐的时候就做了不可撤销的决策。

于是论文把问题抽象为：维护一个随时间演化的架构状态 S_t = (GR_t, GC_t, A_t)，其中：

• GR（需求级 DAG）：节点是需求单元（高层需求及其子需求），边是功能性协作关系——两个需求在逻辑上总是一起被使用、需要对齐行为与输入输出。注意这不是实现依赖，而是"需求语义上的协同"。
• GC（组件级 DAG）：节点是组件（模块、对象、服务层、解析器、适配器等有界实现责任的单元），边是实现依赖（继承、复用、包含）。
• A ⊆ V_R × V_C（对齐关系）：多对多的"组件实现了哪些需求的哪部分"映射，保证从需求到代码的端到端可追溯性——任何时刻你都能回答"这个组件为什么存在"（服务于哪些需求）和"这个需求由谁负责"。

给定：自然语言需求文档。求：一个完整的可运行仓库，使得功能正确（测试通过）且架构模块化（高内聚低耦合）。约束：架构状态必须随编码进程持续可修正，修正必须可追溯（每次结构变动都能定位到它回应的需求或测试证据）。

一个贴切的类比：这非常像真实工程里的渐进式重构（incremental refactoring）。没有人要求架构师第一天就画出完美 UML 图；相反，大家接受"先有个粗略划分，写代码，发现臭味（低内聚/高耦合），重构，再写"的循环。Repo0 做的事情，本质上是把这条软件工程的经典实践——“让架构向模块化的方向持续演化直到收敛”——形式化成 agent 可执行的算法。架构演化 ≈ 渐进式重构，这个对应关系是理解全文的钥匙。

四、问题解法：三阶段流水线，演化到收敛再动笔

Repo0 的整体流水线分三个阶段。

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

输入自然语言需求文档，LLM 先提取"能力级"候选需求项（要求描述独立的仓库级功能，不把底层操作拆成顶层项），合并冗余后得到高层需求；再借鉴 Atom of Thoughts 的"先推理后标注"三段式——先尽可能完备地细化每个需求（行为、输入输出、约束、错误情形），再识别子需求，再标注子需求间的逻辑依赖——形成初始需求 DAG。然后对每个高层需求，把子需求翻译为有界组件（名称 + 职责描述 + 服务的子需求清单），得到初始组件 DAG 与对齐关系，构成初始架构状态 S_0。以 statsmodels 案例为例：一份 README 被分解为 39 个高层需求、92 个子需求，再落地为 86 个实现组件。

注意 Phase I 只求"有"，不求"对"——初始架构的质量缺陷恰恰是 Phase II 的燃料。

Phase II：模块化度量引导的结构演化

这是全文的心脏。从 S_0 出发，需求 DAG 保持固定（功能范围不能漂移），只演化组件 DAG 与对齐关系。每一轮重新计算模块化度量，触发结构动作，直到收敛。

先看两个核心度量怎么算（这些定义都建立在需求 DAG 和对齐关系之上，纯结构计算，不依赖主观打分）：

• 内聚度 cohesion(c)：组件 c 服务的需求集合记为 RS(c)（即对齐关系里指向 c 的所有需求）。数一数需求 DAG 中两个端点都落在 RS(c) 内部的边数 E_in(c)，除以 RS(c) 内可能的最多边数。直觉：如果一个组件负责的需求彼此毫无协作关系，它的内聚度就低——这个组件把不相干的事混在了一起。
• 耦合度 coupling(A, B)：两个组件职责集合的 Jaccard 相似度 |RS_A ∩ RS_B| / |RS_A ∪ RS_B|。直觉：两个组件若服务高度重叠的需求集合，它们大概率在做重复的事，应该合并。
• 辅助判据：职责规模 |RS(c)|（组件管了几个需求）和连接度 connectivity（需求 DAG 中桥接两个组件职责集合的边数）。

再来看结构动作。论文在方法节正式定义了 split / merge / revise / save 四种，引言与实验分析中还讨论了第五种 add（找回缺失需求以提升覆盖，未在方法节正式定义，如实注明）：

这张表有两个精妙之处值得咀嚼。第一，度量与 LLM 分工明确：split 由"内聚度 + 图划分证据"触发，是相对客观的计算；merge 由"耦合度候选 + LLM 语义验证"决定——因为高 Jaccard 相似度也可能来自分层、上下游这类合理的架构耦合，纯数值判断会误杀，所以最后一步交给 LLM 拍板。第二，save 不是废动作：实验中 save 的占比很高，说明初始架构的相当一部分组件本就稳定，演化框架的价值在于精准识别"该动的那一小部分"，而不是推倒重来。

演化收敛的判据也定义得非常干净：当完整一轮演化不再触发任何 split 或 merge，结构演化终止；随后做一次最终语义对齐检查（LLM 逐组件审查职责、需求覆盖与接口假设的一致性，不一致则施加 revise，边界不动）。为什么需要显式收敛判据而不是"多演化几轮总是更好"？后文 RQ3 的实验给出了锋利的回答：超过收敛点继续演化，会导致不必要的碎片化和补偿性重构，指标不升反降。

阈值（γ_split = 2/3、θ_merge = 0.7）不是在评测集上调的，而是在 Commit0 Lite 的两个留出仓库（小规模 wcwidth、大规模 sphinx）上，对比演化后架构与真实仓库金架构、人工选择边界最接近且不过度拆分的设置——这个留出流程值得肯定，避免了"在考试卷上调参"的嫌疑。

Phase III：收敛架构引导的 TDD 生成

结构收敛后，把组件 DAG 转成具体生成计划：包分配、文件路径、导出符号、依赖感知的生成顺序。然后逐组件走测试驱动开发（TDD）三步：先生成可导入的骨架以固定公开 API；再从对齐的需求节点合成测试；最后填实现让测试通过。每个组件的生成上下文由三部分构成：自己的职责描述、对齐的需求节点、必须先就绪的上游组件——这三样正是双 DAG 状态直接产出的信息。

每步生成后跑验证（import 检查、接口检查、pytest 执行），失败触发局部修复：只对受影响的实现、测试或包初始化文件打补丁，不做全局重构。如果验证反馈揭示组件描述或接口假设本身错了，还有一条"架构级回退通道"——在下一轮 TDD 前施加 revise 修正架构描述（边界仍不动）。可以看到，即使到了生成阶段，架构状态依然活着，只是改动方式被限制在最小范围内。

五、评估指标与实验证据：跨模型互评是点睛之笔

基准与骨干

实验基于 RepoCraft 基准的 6 个真实 Python 仓库（requests/HttpEasy 17 文件 2793 行 50 任务、statsmodels/StatModeler 271 文件 8325 行 234 任务、django/PyWebEngine 681 文件 109457 行 165 任务，以及 scikit-learn、pandas、sympy 三个大仓库，最大 699 文件近 22 万行）。骨干模型用 GPT-5 mini 与 DeepSeek V3.2 两个，覆盖不同厂商。正文详细报告了三个代表性仓库的逐项数值，摘要汇总了全部 6 仓库的对比幅度。

四个指标，各测什么

• Functionality Coverage（功能覆盖率）：生成的仓库覆盖了需求文档中多少比例的功能需求——“该做的做了没有”。
• Functionality Novelty（功能新颖性）：生成物中超出需求描述、但真实仓库里确实存在的能力——“有没有做出需求没明说但应该有的东西”。
• Pass Rate（通过率）：用改编自真实仓库的真实测试去测生成代码的通过率——这是最硬的正确性指标，代码世界的一锤定音。
• Voting Rate（投票率）：语义层面的评估。这里有一个我认为全实验设计里最讲究的细节——跨模型互评：DeepSeek 生成的代码由 GPT 来评，GPT 生成的代码由 DeepSeek 来评，用跨模型多数投票决定语义是否达标。为什么要这么绕？因为如果用同一个模型既当运动员又当裁判，它会系统性地偏好自己的表达风格与解题思路，产生评估偏置。交叉互评把"生成偏好"与"评估偏好"解耦，让裁判对两种生成来源保持等距。这个设计对任何需要 LLM 做评估的实验都有借鉴意义。

主结果

GPT-5 mini 骨干（三个代表性仓库，Cov/Nov/Pass/Vot，单位 %）：

DeepSeek V3.2 骨干：

几个值得强调的读数：

1. 全部 6 仓库 × 2 骨干，Repo0 的 Functionality Coverage 与 Pass Rate 均为最高，Voting Rate 也全部 6 个设置居首。跨两个骨干模型都成立，说明优势来自框架而非某个模型的特性。
2. 对比最强基线 RPG：Functionality Coverage 提升 4.55～20.08 个百分点，Pass Rate 提升 7.61～29.74 个百分点。幅度随仓库复杂度放大——django 上 Pass Rate 领先 27.03 个百分点，requests 上领先 19.47 个百分点。仓库越复杂、初始规划越难一次做对的地方，正是持续演化优势最大的地方，这与论文的核心论点严丝合缝。
3. 基线的互补性弱点清晰可见：mini-SWE-agent 无规划，在 statsmodels 上 Pass Rate 归零；Paper2Code 新颖性亮眼（django 上 DeepSeek 骨干 Nov 43.46 全场最高）但 Pass Rate 只有 7.82——“想得新颖"与"写得正确"是两回事；RPG 在简单仓库 requests 上很强（61.64），一到大仓库就明显退化，静态蓝图的宿命。
4. 参照金标准：真实人类仓库本身 Pass Rate 为 94～96，Repo0 在 requests 上（DeepSeek 骨干 78.08）已进入同一量级，但差距仍在——零到全生成远未"解决”。

消融：每个组件都被证明有用

GPT-5 mini 下的消融（摘选关键数字）：

三个结论：结构演化是最大功臣（去掉后 requests 三项指标全面最大退化，Voting Rate 掉 17.86）；双 DAG 的分离表示有独立贡献（换统一图后 requests Coverage -4.55、django Pass -10.00）；依赖感知生成顺序在复杂仓库至关重要（statsmodels 上去掉后 Pass Rate 骤降 30 个百分点）。

RQ3：度量引导 vs LLM 自由演化

最有说服力的一组对照：固定初始架构，让 LLM 在没有内聚/耦合度量约束下自主决定结构动作（固定 1/3/5 轮预算）。结果显示自由演化全面劣于度量引导的 Repo0（statsmodels 上 Coverage 75.90→80.68，Pass 81.90→85.51，Voting 93.00→98.65），且演化一轮之后继续动作，Coverage/Pass/Voting 全线下降——LLM 倾向于过度分解组件，碎片化带来补偿性重构，反而伤害正确性。这从反事实角度证明了：不是"让 LLM 改架构"有价值，而是"让度量决定何时改、何时停"有价值。

成本方面也有意外之喜：更模块化的架构减少了冗余与冲突代码，修复迭代更少，GPT-5 mini 下 Repo0 在所有仓库生成成本最低；DeepSeek 下 requests/statsmodels 端到端成本比 RPG 更低（RPG 分别贵 9.32 与 35.59 美元），仅 django 因评估成本占主导（72.82 美元）总成本略高。演化架构没有付出显著代价，反而省了钱。

六、效果优势的根源解释：为什么是结构上必然更好

第五部分的数字很好看，但"指标好看"和"证明了论点"是两回事。这一节建立从方法差异到指标提升的因果链。

因果链第一环：双 DAG 把"为什么做"与"怎么做"分开表示，让结构决策有了可计算的依据。 需求 DAG 编码的是功能协同（用户视角的"哪些事总是一起发生"），组件 DAG 编码的是实现依赖（工程视角的"谁建立在谁之上"）。这两个视角的聚类本来就不重合——功能协同强的需求可能分属不同实现层，实现上纠缠的组件可能服务完全不同的用户需求。分开表示之后，内聚度（需求图上的内部边密度）与耦合度（职责集合的 Jaccard 相似度）才能被干净地定义和计算。消融中"去掉双 DAG 换统一图"导致 django Pass Rate -10.00，证明的正是这一环：没有分离表示，模块化度量就退化成模糊启发式，结构动作失去依据。

因果链第二环：结构动作全部作用在对齐关系上，可追溯、可局部化。 因为每个组件都通过 A 关联到明确的需求子集，split 才能精确地"抽取诱导子图找分组"，merge 才能算出"职责重叠度"，revise 才知道"哪个组件的接口假设需要改"。对比 RPG：它的规划图没有需求层与对齐关系，结构错误一旦发生既检测不到（无度量可算）也定位不了（无追溯路径），唯一的选择是带着错误生成到底。RPG 在 requests 上尚可、在 django 上塌掉，根源就在这里：仓库越复杂，一次性蓝图的结构错误概率越高、错误传播越深，而它没有任何机制能中途纠偏。

因果链第三环：度量引导 + 显式收敛，防住了"自由演化"的过度分解陷阱。 RQ3 的反事实实验是关键证据：同样让 LLM 改架构，没有内聚/耦合阈值约束时，LLM 系统性地把组件越拆越碎——碎片化意味着更多的接口假设、更多的跨组件协作失败点，Pass Rate 随之下降；而 Repo0 的 split 需要同时满足"内聚度低于 2/3 且职责规模超阈"，merge 需要 LLM 语义验证，save 让稳定组件免遭折腾，收敛判据（一轮无 split/merge 即停）在恰好的时刻关掉了演化开关。“一轮之后继续演化全线退化"的实验结果，反过来证明了这个停止规则捕捉到了真实的结构最优区。

因果链第四环：收敛的高内聚低耦合架构，直接降低了 Phase III 的生成与修复难度。 内聚高的组件职责单一，生成上下文（职责描述 + 对齐需求 + 上游组件）短而准；耦合低意味着依赖接口少，跨组件的签名冲突与行为期望错位自然减少。这解释了两件事：为什么 Pass Rate 的提升幅度（最高 +29.74）大于 Coverage 的提升幅度（最高 +20.08）——架构质量不仅让"该做的做了”，更让"做出来的能通过测试"；为什么修复成本反而更低——冲突代码少了，昂贵的 TDD 修复迭代就少了。

整条链合起来：分离的双表示（可计算）→ 结构动作可追溯可验证（可修正）→ 度量引导收敛（不过度）→ 架构质量转化为正确性与低成本（可收益）。每一环都有对应的消融或对照实验背书，不是"用了演化所以好"的口号式归因。

七、必要知识反推：做出这项工作最少要知道什么

假设一个完全空白的研究者要复现这条路线，他至少需要掌握哪些知识？

领域知识层：真实的软件工程经验，特别是模块化设计原理——高内聚低耦合为什么重要、什么信号暴露了坏架构（改一个功能要动三个模块 = 高耦合；一个模块承担八竿子打不着的职责 = 低内聚）。还有对软件开发生命周期的现实认知：架构是活的、在编码中持续被修正。没有这层认知，会自然落入"先画完美蓝图"的思维定式，根本意识不到"一次性规划"是个伪前提。

方法论知识层：（1）图论工具——DAG 表示、诱导子图、图划分/最小割（split 的核心证据来源）、Jaccard 相似度（coupling 的定义）；（2）代码生成研究脉络——HumanEval 到 SWE-bench 到 RepoCraft 的谱系，以及 RPG、Paper2Code、多 agent 系统各自的强弱，才能找准"静态规划"这个靶心；（3）结构化推理前序工作——Atom of Thoughts 的"先推理后标注"被直接借鉴到需求分解；（4）TDD 实践——骨架固定 API、测试先行、局部修复的工程闭环。

工程知识层：LLM agent 的流程编排（何时调用 LLM、何时用确定性计算）；评估体系设计——尤其是跨模型互评防偏置的意识，以及"阈值必须在留出集上定"的实验卫生（wcwidth/sphinx 留出）；消融实验设计——把双 DAG、结构演化、依赖顺序逐个剥离的变量控制。

知识融合的关键节点：最关键的化学反应发生在软件工程经典理论与图算法的结合处——“内聚"和"耦合"本是教科书里定性叙述的概念，作者发现一旦有了双 DAG + 对齐关系，它们可以变成纯结构可计算的量（内部边密度、Jaccard 相似度），于是"渐进式重构"这条人类实践就变成了 agent 可执行的算法循环。第二个融合节点是度量与 LLM 的分工哲学：度量触发候选（客观、可复现），LLM 做语义裁决（merge 验证）与创造性改写（split 的组件重写）——既不放任 LLM 自由发挥（RQ3 证明会过度分解），也不让死板数值误杀合理架构（分层耦合）。

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

灵感一：设计是过程，不是制品。 核心思想：任何领域里，如果一项设计决策所依赖的信息要随工作推进才逐渐显现，那么把设计当一次性前置产物就是结构性错误，应当改为"持续演化的状态 + 显式的修正动作”。论文证据：RPG 一次性规划在 django 上 Pass Rate 落后 27.03 个百分点；Repo0 演化至收敛全面领先。推广场景：产品设计（原型迭代替代完美 PRD）、城市规划（修编替代总图一次成型）、组织架构设计（随业务演化调整部门边界）、科研方案设计（实验中修正假设树）。

灵感二：用显式的双表示分离两类纠缠的关注点。 核心思想：当"意图侧结构"（需求、目标、用户视角）与"实现侧结构"（组件、资源、工程视角）天然不重合时，分开建两个表示并维护显式对齐关系，比对在一个混合表示上好。论文证据：统一图消融使 django Pass Rate -10.00、requests Coverage -4.55。推广场景：产品管理（用户故事地图与微服务边界分开维护并互相追溯）、知识管理（概念图与文档库分离+链接）、机械设计（功能结构树与零件装配树对齐）、课程设计（学习目标图谱与知识点模块对齐）。

灵感三：度量引导的演化优于自由演化，且必须配显式收敛判据。 核心思想：让智能体（人或 LLM）自由地持续改进一个结构，往往滑向过度动作（过度分解、过度重构）；用少量可计算的客观度量做触发门槛，并在"一轮无改进动作"时显式停止，才能落在最优区。论文证据：LLM 自由演化一轮后 Coverage/Pass/Voting 全线下降，度量引导的 Repo0 全面更优。推广场景：提示词/文档的迭代优化（设停止准则防过度打磨）、组织流程再造（改到"一轮无部门调整"即停）、个人知识库重构、模型微调（早停防过拟合的同构逻辑）。

灵感四：跨来源互评防止评估偏置。 核心思想：当评估者与被评者同源（同一个人、同一个模型、同一套偏好），评分会系统性偏向自己的风格；让评估者与生成者交叉（A 评 B 的产出，B 评 A 的产出），可解开"生成偏好"与"评估偏好"的耦合。论文证据：Voting Rate 采用 DeepSeek 评 GPT 生成、GPT 评 DeepSeek 生成的跨模型多数投票。推广场景：论文评审（避开同门派评审人）、代码 review（交叉审查而非自审）、面试评估（跨部门面试官）、AI 评估流水线（评测模型与被测模型异源）。

灵感五：稳定部分显式冻结，演化火力集中在不稳定部分。 核心思想：演化系统中大量组成部分其实是健康的，无差别的持续改进会浪费资源甚至引入退化；显式标记"稳定/可变"状态（save 动作），让改动只落在被证据（低内聚/高耦合/测试失败）指认的局部。论文证据：save 在动作分布中占比很高，且邻居更新后组件可"复活"重新参与演化。推广场景：增量编译与缓存失效（只重编受影响模块）、组织变革（稳定团队不动、试点团队先行）、持续交付（金丝雀发布替代全量重启）。

总结。Repo0 的贡献可以压缩成一句话：它把软件工程里"架构在编码中持续演化直至模块化收敛"这条古老实践，翻译成了 LLM agent 可以执行的算法——双 DAG 架构状态让它可计算，五种结构动作让它可修正，模块化度量让它有分寸，收敛判据让它知道何时收手。在 6 个真实仓库 × 2 个骨干上的全面领先，以及"去掉结构演化退化最大、LLM 自由演化反而更差"这两组对照，共同把论文的论点钉得很实：**零到全代码生成的瓶颈不在写代码的能力，而在维持结构的能力；设计不是一个开始时的动作，而是一个贯穿全程的过程。**当然也要看到边界：与人类金标准仍有差距，超大仓库（sympy 近 22 万行）的绝对通过率依然不高，且方法目前验证于 Python 生态——设计驱动生成的故事，才刚刚写到第一章。