MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

2026-04-16 16:30:11
文章摘要
微软亚洲研究院(MSRA)的RepoGenesis是首个面向多语言、仓库级、端到端Web微服务生成的基准,已被ACL 2026高分录用。它以贴近实际的需求文档为输入,对多个开源Agent和商业IDE进行评测。结果显示,AI能写代码、覆盖接口、跑起来,但逻辑未必全对,瓶颈在于架构、依赖等方面。

大模型写代码这件事,越来越像「既能写片段,又离真实工程差一截」。

HumanEval、SWE-Bench、ClassEval……榜单很多,但多数仍在考函数、类,或在既有仓库里打补丁。

真正让人头疼的0到1,往往是读完一份需求文档,把一整套可部署的代码仓库搭出来:目录怎么拆、依赖怎么对齐、多个文件之间的接口与错误处理怎么一致。

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

微软亚洲研究院(MSRA)的最近这项工作,把考点直接搬到了这条链路上。论文已被ACL 2026高分录用。它不设花哨的「全自动科研」叙事,而是把一个更清晰的问题说透:只给你README式的需求说明,AI能不能从零生成完整仓库,并且过黑盒测试、能部署。

这就是RepoGenesis:首个面向多语言、仓库级、端到端Web微服务生成的基准。

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

和现有基准比,RepoGenesis的差异可以用一张「能力矩阵」来理解:不止于函数级或改代码库,而是Repo-Level、NL2Repo、并且锁定微服务场景;语言上同时覆盖Python与Java。论文里的对比表把这条边界画得很清楚。

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

RepoGenesis与主流代码生成基准对比表

把「工程上真实的一单活」拆成可测的流水线

RepoGenesis的输入非常贴近实际:一份写清功能、API、模式、约束的需求文档README.md。模型或Agent的输出则是一整套仓库:源码、配置、依赖声明,最后要扛住黑盒测试。

数据规模上,论文给出106个仓库(60 Python、46 Java),横跨18个领域、11套框架,共1258个API、2335条测试。评测子集Verified为30个仓库(6个来自可部署的真·GitHub项目+24个专家监督构造),并另有76个仓库构成Train子集用于训练与轨迹蒸馏,二者分工在文中写得很明确,避免「既当教练又当裁判」。

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

Benchmark构造与difficulty分布或数据集统计表骨架

测试怎么信?他们用了很「学术会议」的一套review-rebuttal质控:多模型盲评、分歧大时人工Area Chair介入、迭代refined,直到达到约定门槛;Verified部分还报告了评分者可重复性从近乎随机提升到Krippendorff’s α≈0.69这类量化结果。大意只有一个:这不是用几条手写样例糊弄一下,而是尽量让测试本身站得住。

评测不止「过没过」:三根柱子一起看

如果只报准确率,会掩盖「写得像那么回事,但起不来服务」这类工程常态。RepoGenesis用三个维度同时打分明细:

1. Pass@1:功能是否正确,能否扛住黑盒测试(最硬)

2. API Coverage(AC):需求里的接口,实现覆盖了多少。

3. Deployment Success Rate(DSR):生成物能不能真的部署跑起来。

论文对DeepCode、MetaGPT、MS-Agent、Qwen-Agent等开源Agent,以及Antigravity、Cursor、Copilot等商业IDE做了一轮系统评测(多模型配置,主文侧重GPT-5.1、Claude-Sonnet-4.5、Qwen3-30B等组合,细节见附录)

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

各系统能力雷达

结果里有一组反差很强的数字,几乎可以直接当导语用:接口覆盖率可以冲到很高(摘要中AC最高约73.91%);部署成功率在部分配置下可以非常亮眼(摘要写DSR最高可达100%,与附录中部分IDE+模型组合一致)。但即便如此,最强系统的Pass@1仍然在Python上约23.67%、Java上约21.45%(Copilot+Claude主表结果)

翻译成人话:能写、能覆盖接口、甚至能先跑起来,并不等于逻辑全对。架构是否自洽、依赖是否严实、跨文件是否对齐,仍然是瓶颈。

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

MSRA首测AI从零建仓库:能写、能跑,但不一定对丨ACL'26

Pass@1/DSR-AC主表

失败长什么样?论文把失败病例粗分成三类,大致占比是:跨文件一致性问题合计约50.2%架构连贯性约26.0%依赖管理约23.8%。Java里依赖相关失败占比更高(表中44.7%),这也和语言与构建链路的「硬」是一致的。

另一条线:数据能不能把模型「喂上去」?

团队在MS-Agent之上扩展了面向微服务仓库生成的GenesisAgent,用成功轨迹蒸馏出16,396条高质量指令微调样本,在Qwen3-8B上微调得到GenesisAgent-8B。在Verified上,它与GPT-5 mini多指标互有往来、整体同梯队(文中Table给出DSR、AC、Pass@1的并列对比)。这至少说明一件事:这份基准是值得继续挖的训练信号,而不是一次性榜单。

当然,边界也很坦诚

RepoGenesis主要覆盖REST式Web微服务,语言集中在Python/Java;输入是结构化较好的README,真实世界里「需求含糊、反复改稿」还没完全模拟;测评以过测为主,可读性、长期可维护性、工程规范仍未系统量化。这些在论文Limitations里都写得直白。

结语

RepoGenesis的意义,未必是把代码生成再吹成一个全能故事,而是把行业里大家每天在做的那一步:从文档到仓库,变成可复现、可对比、可改进的考场。当ACL 2026给这类「贴工程」的硬评测一页版面时,讨论或许会少一些口号,多一些能落地的下一代模型与Agent。

论文标题:

RepoGenesis: Benchmarking End-to-End Microservice Generation from Readme to Repository

论文链接:

https://arxiv.org/abs/2601.13943

代码与榜单(作者公开渠道):

https://github.com/pzy2000/RepoGenesis/

公开榜(持续汇总开源Agent与商用IDE):

http://23.83.232.182:4090/

文章来自于"量子位",作者 "微软DKI团队"。

声明:该内容由作者自行发布,观点内容仅供参考,不代表平台立场;如有侵权,请联系平台删除。
标签:
大模型
代码生成