自然语言规划的模糊性让仓库生成屡屡翻车。微软 RPG 用图谱取代文字，节点代表功能与文件，边标注依赖与接口。基准显示，功能创新率 11-13%，代码通过率 69.7%，远超 Claude Code，为大规模 AI 开发铺平道路。
近年来，大模型写代码的能力突飞猛进。在函数级、文件级上，生成已相当可靠；开发者一句描述就能得到完整函数或模块。
但当视野扩展到整个仓库时，难题随之而来：数十上百文件、类与函数之间交织着复杂依赖，要从抽象描述落到完整仓库，始终充满挑战。
现有方法多依赖自然语言规划来决定「做什么、怎么做」。这种方式虽直观，却天生模糊、缺乏结构，难以长程稳定地追踪依赖。
结果就是两类常见失效：要么功能提案不全，难以覆盖需求；要么实现过程漂移，接口和模块边界逐渐错乱。
为解决这一问题，微软提出了 Repository Planning Graph (RPG)，以结构化图谱替代脆弱的文字规划，把功能、文件、依赖和数据流统一在一张蓝图中，从而让仓库生成首次具备可控、可扩、可验证的基础。
从需求到仓库的统一蓝图
Repository Planning Graph (RPG)是一种结构化表征，它把仓库生成的全过程统一到一张图里。
RPG 的节点可以是功能目标、文件、类或函数，边则显式标注接口调用、依赖关系和数据流动。
这种设计既能回答「要实现什么」（提案层），也能回答「如何实现」（实现层），从而保证高层意图与底层实现的一致性。
在此基础上，研究团队提出了 ZeroRepo 框架。ZeroRepo 从用户的自然语言描述出发，分三步逐步构建 RPG 并在其指导下生成代码：
第一步：提案级构建
ZeroRepo 不再让模型「即兴发挥」，而是先把用户的自然语言需求落到 RPG 上，逐步长成一张功能图谱。
它依托一个庞大的功能树去检索和拼接节点，比如「用户登录」「购物车管理」「支付处理」，像搭积木一样组合成完整蓝图。
这样，系统不但覆盖了所有关键功能，还能保证结构清晰、层次合理。
第二步：实现级构建
有了功能蓝图，还需要明确每个模块「落地到哪里」。
ZeroRepo 会把功能节点继续展开，写成具体的文件、接口和数据流，并一一标注进 RPG。以「支付处理」为例，它会被拆解成 payment_service.py、api / payment_api.py等文件，并明确依赖订单与库存模块的输出。
这样，模块间的边界和依赖被牢牢固定，再也不会在生成过程中走偏。
第三步：图驱动生成
最后，ZeroRepo 按照 RPG 的拓扑顺序推进代码生成。每实现一个文件或函数，就会先生成测试用例，再写函数体，并把结果回写到 RPG 中。
这形成了「生成 — 验证 — 更新」的闭环。
整个过程像是沿着蓝图施工：有规划、有校验，仓库规模不断扩展，但始终保持接口对齐、结构稳定。
实证 ZeroRepo：从蓝图到真实仓库
为全面评估仓库级生成能力，他们构建了全新基准 RepoCraft。
不同于以往依赖现成仓库或提供详尽文档的设置，RepoCraft 不提供完整架构蓝图，还涵盖 6 个真实项目、共 1052 个任务：
scikit-learn，pandas，requests，django，statsmodels，sympy。
真正考察模型从模糊需求到结构化实现的能力。
功能覆盖与规模：覆盖率达 81.5%，比最强基线Claude Code 高27.3 个点；还能生成超 100 个新功能（创新率 11–13%），远超其他方法。生成仓库平均 36K 行代码、445K tokens，是 Claude Code 的 3.9 倍、其他方法的 64倍，复杂度接近人工项目。
正确性与一致性：代码通过率为69.7%，比 Claude Code 高35.8 个点，接近人工项目上限（81%）。RPG 的结构化约束有效保证了模块边界和接口设计的一致性，使生成结果更稳定、更贴近设计初衷。
复杂依赖与协同：以 Qwen 3 Coder 生成的结果来看，RPG 不仅清晰组织了文件层次和模块流程，还显式捕捉了跨模块调用与反馈依赖，使复杂关系能够被稳妥管理，仓库在复杂度提升的同时仍保持整体协调。
随着迭代次数增加，RPG 引导的规划让新功能和新增代码能够稳步扩展，而不是像基线方法那样在早期就陷入停滞。这样的线性扩展能力证明他们具备支撑大规模仓库持续开发的潜力。
此外，RPG 提供的全局结构视角显著提升了代理的仓库理解与定位能力，使其能够更快地追踪依赖、定位问题并完成模块集成，从而加速整个开发流程。
总结与展望
ZeroRepo 展示了结构化图谱在仓库生成中的独特价值：它不仅提升了功能覆盖率、代码规模和正确性，还解决了长期困扰自然语言规划的模糊与漂移问题，使自动化仓库生成首次逼近真实的软件开发过程。未来，研究团队计划进一步拓展 RPG 的适用范围，包括支持多轮需求变更下的交互式开发、跨仓库的协同演化，以及与现有工程工具链的深度融合。
参考资料：
https://arxiv.org/abs/2509.16198
