微软研究称编码 Agent 让 PR 增加 24%，但别把 PR 数当生产力
作者：林岚
林岚
OC 原创示意图。
据 微软研究人员发表的大规模企业研究 显示，在微软内部使用命令行编码 Agent 的工程师，合并 Pull Request 的数量出现了明显增长。论文把多种分析结果放在一起后，给出了约 24% 的代表性提升数字。
一句话结论： 这项研究提供了目前少见的真实企业证据，说明编码 Agent 确实能提高代码交付频率，但它测到的是“合并了多少 PR”，不是代码质量、业务价值或团队整体生产力。
研究覆盖数万名微软工程师，观察期从 2026 年 1 月初持续到 4 月底。研究者分析了 GitHub Copilot CLI 和 Claude Code 的使用记录，再把工程师使用 Agent 前后的工作表现进行比较。为了尽量减少“本来就更高产的人更愿意用 AI”这种偏差，论文采用了合成对照和同一个人在不同使用强度周之间的比较，而不是只把用户与非用户简单分组。
结果很有意思：使用 Agent 三天的周，PR 数量平均增加约 15%；使用五天以上时，增幅达到 50.1%。按“某一周是否使用”来分，Claude Code 对应的增幅是 11.4%，Copilot CLI 是 24.9%。但这并不能直接推出 Copilot CLI 比 Claude Code 强一倍。微软员工的工具接入、代码托管方式、任务类型和内部支持都可能偏向自家产品，两个工具用户承担的工作也未必相同。
OC 原创解释图：PR 数量是可观察指标，不等于完整生产力。
论文里另一个容易被标题漏掉的发现，是 Agent 的采用很像一种团队行为。一个工程师的直属经理在使用工具，他尝试工具的几率会上升 82%；如果有至少四分之一的隔级同事在用，上升幅度达到 216%。身边评审者使用得越多，个人也越容易开始使用。AI 编程工具能否落地，看来不只取决于模型能力，还取决于同事是否已经形成可模仿的工作方式。
不过，PR 是一个很容易被优化的数字。一项大改动可以拆成十个小 PR，也可以合成一个；更多提交可能意味着反馈更快，也可能只是工作被切得更碎。论文没有测量缺陷率、返工时间、事故数量、代码维护成本和功能带来的收入，而且只观察 Azure DevOps 中可见的工作。研究者自己也承认，重度使用 Agent 的周可能恰好安排了更适合自动化的轻任务。
本站编辑林岚认为，这篇论文最有价值的地方不是给管理者一张“AI 能提升 24%”的采购海报，而是提醒团队把评估做得更细。可以同时观察从需求到合并的周期、评审时间、线上缺陷、回滚率和开发者满意度，再看 Agent 到底把瓶颈移到了哪里。代码产出变快以后，评审、测试和需求判断往往会成为新的限速环节。
对开发者来说，结论也不必过度复杂：编码 Agent 已经足以改变日常产出，但“写得更多”不自动等于“做得更好”。真正成熟的用法，是把它放进有测试、有评审、有反馈的工程系统里，而不是用 PR 数给人和模型排排行榜。
评论
围绕这篇文章补充信息、提出问题或分享观察。