以前，一个上千行改动的 Pull Request 出现在 review 队列里，至少说明有人真的坐在那里写了一阵子。

现在不一定。

一个开发者可以早上开三个 Agent，中午回来收三份 diff，下午再让它们补测试、改文档、修 lint。到了晚上，提交记录非常漂亮：功能做了，测试绿了，PR 也挂上去了。要是公司还拿提交数、PR 数、关闭 Issue 数量当“研发产能”，那简直像是突然发现了一台永动机。

问题也从这里开始。

代码确实越来越容易生产了。理解这些代码、证明它们正确、承担上线后的后果，价格一点没降。

GitHub Copilot 与代码协作主题图

图片来源：GitHub Blog。

先别急着庆祝“产能暴涨”

2025 年 DORA 的 AI 辅助软件开发报告调查了接近 5000 名技术从业者。90% 的受访者表示工作中已经使用 AI，超过 80% 认为 AI 提高了自己的生产力。

听起来很漂亮。

同一份报告里还有另外两件事：约 30% 的受访者对 AI 生成代码缺乏信任；AI 使用和软件交付吞吐量呈正向关系，同时和交付稳定性呈负向关系。

也就是说，代码确实可以更快地往前冲。后面的测试、review、架构、发布和运维如果没有一起升级，车速越快，撞上薄弱环节时动静越大。

DORA 自己给出的总结很准确：AI 会放大一个组织原本就有的东西。工程基础扎实的团队拿它加速，流程混乱的团队也能被它加速，只不过加速的是混乱。

参考：Google Cloud：2025 DORA State of AI-Assisted Software Development

写代码的成本掉下来了，review 的一天还是只有八小时

这件事已经开始逼平台改规则了。

2026 年 6 月，GitHub 给仓库增加了 Pull Request 数量限制。官方写得很直白：维护者正在面对越来越多的 PR，其中包括重复、低质量和一次性的贡献，它们会拖慢 triage 和 review 队列。Copilot 或其他 AI Agent 创建的 PR 也算在限制里。

GitHub 随后专门写了一篇文章解释这项功能，其中有一句非常值得注意：创建 Pull Request 变得越来越容易，review 一个 PR 仍然需要人的时间。

这大概就是现在很多团队最尴尬的地方。

以前瓶颈可能是“没人写”。现在一个人能同时让几个 Agent 写，瓶颈很快就会挪到“谁来认真看”。

GitHub Pull Request 数量限制界面

图片来源：GitHub Blog。GitHub 在 2026 年增加了 PR 数量限制，用来降低低质量贡献对维护者队列的压力。

GitHub 2026 年 5 月另一篇关于 Agent PR 的文章给出的数字更夸张：Copilot Code Review 已经处理超过 6000 万次 review，使用量不到一年增长了 10 倍，GitHub 上超过五分之一的代码审查已经涉及 Agent。

当一个开发者午饭前就能启动十几个 Agent 会话时，生成侧的吞吐量可以暴涨。人的注意力没有这个扩容能力。

参考：

最危险的代码往往长得很正常

AI 生成代码有一个很麻烦的特点：它通常很像代码。

命名正常，缩进正常，注释也挺认真。接口能调通，测试还能过。真正麻烦的地方经常藏在代码库的历史里。

为什么这个权限检查必须放两层？为什么这个看起来多余的重试不能删？为什么团队宁愿保留一个丑一点的 helper，也不愿意再抽象一次？这些东西很多根本没有完整写在文档里，它们来自线上事故、兼容性坑、旧客户、某次数据库迁移，甚至来自一个已经离职三年的人的一句“这里千万别动”。

Agent 看见的是仓库里的文本。维护者脑子里还装着仓库没有写出来的历史。

GitHub 自己给 Agent PR reviewer 的建议里，专门提醒了几类问题：Agent 可能重复实现仓库已经存在的工具函数，也可能在 CI 失败时通过弱化测试、跳过 lint、修改覆盖率门槛来让流水线重新变绿。还有一类更麻烦——代码编译、测试全部通过，逻辑仍然是错的。

这也是为什么“测试全绿”从来不能直接翻译成“可以放心上线”。

技术债开始有了流水线生产能力

GitClear 做过一组很值得看的代码变更分析。他们统计了 2020 到 2024 年间约 2.11 亿行变更数据，覆盖 Google、Microsoft、Meta 以及其他企业仓库。

结果里有两个趋势很刺眼：用于重构的变更占比从 2021 年约 25% 降到了 2024 年不足 10%；被识别为复制粘贴的代码行占比从 8.3% 上升到 12.3%。

这项研究来自一家商业开发分析公司，而且这些趋势不能简单证明“全部都是 AI 造成的”。但把它和现在 Agent 擅长的工作方式放在一起看，还是很值得警惕：找到一个现成模式，复制，改几个名字，让当前任务通过。

GitClear 对包含克隆代码块提交比例的统计

图片来源：GitClear 2025 AI Code Quality Research。该图展示其样本中含克隆代码块的提交比例变化。

软件最初当然能跑。

半年以后，仓库里出现四套几乎一样的参数校验、三套稍微不同的 retry、五个名字不同但作用差不多的 helper。再过一年，没人敢删，因为没人能确定哪个客户还在走那条分支。

技术债以前主要靠人手工生产。现在也可以自动化了。

参考：GitClear：AI Copilot Code Quality 2025 Research

最荒唐的绩效，是拿“生成了多少代码”奖励开发者

如果一个团队在 AI 时代还盯着 LOC、commit 数、PR 数、完成 Issue 数量考核开发效率，这套指标已经不只是过时了，它会主动把项目往沟里带。

模型最擅长满足这种指标。

想要更多代码？它一天能写几万行。

想要更多 PR？把任务拆小一点，可以源源不断地开。

想让 Issue 看起来关得很快？先实现 happy path，边界问题以后再补。

这些数字放到周报里都很好看。到了线上，它们可能变成更多告警、更多回滚、更多没人理解的模块和下一轮“全面重构”。

真正有价值的开发工作里，有很大一部分根本不增加代码量。

删掉 2000 行重复逻辑，可能比新增 5000 行功能更值钱。花一天确认某个需求根本不该做，可能给团队省下一个月。把一个复杂服务合并回已有模块，PR 看起来甚至会是负增长。

可惜这些事情在“AI 产能大屏”上通常不好看。

我们甚至会误判自己到底快了多少

2025 年 METR 做过一个很有争议、也很有意思的随机对照实验：16 名熟悉自己大型开源项目的资深开发者完成 246 个真实任务，一部分允许使用 AI，一部分不允许。

这些开发者在开始前预计 AI 能让自己快 24%。实验结束以后，他们仍然觉得自己大约快了 20%。

实际记录的结果是：允许使用 AI 的任务平均多花了 19% 的时间。

这个结果当然不能拿来推出“AI 编程一定更慢”。METR 自己反复提醒，这只是早期 2025 工具、资深开发者、熟悉大型代码库这一类场景的快照。到了 2026 年，METR 甚至因为越来越多开发者不愿参加“禁止使用 AI”的实验组，认为新的实验样本出现选择偏差，主动调整了研究设计。

真正有意思的是另一件事：人在评估“AI 到底让我快了多少”这件事上，可能非常不准。

AI 写出第一版代码太快了，那种速度感很强。后面阅读 diff、纠错、补测试、处理回归、返工和 review 等待，全被分散在几个小时甚至几天里。大脑很容易记住“十分钟写完”，忘掉后面两小时在收拾。

参考：

真想用好 AI，流程也得跟着升级

我当然不赞成因为这些问题就把 AI coding 扔掉。那基本等于因为编译器会优化错就坚持手写机器码。

AI 在写样板代码、补测试、读陌生代码、生成迁移脚本、整理文档、定位调用链上已经非常好用。真正需要改的是团队对“完成”的定义。

一个 Agent 说“done”，最多说明它停止生成了。

任务真正结束，至少还得有人能回答：需求到底满足没有？新代码有没有重复已有能力？权限边界动没动？测试有没有真的覆盖风险路径？CI 有没有被偷偷放宽？出了问题怎么回滚？半年以后谁能接手？

这也是为什么我越来越倾向于让 AI 多写，但把 PR 做小；让 AI 先 review，但关键路径必须有人顺着执行逻辑走一遍；让 Agent 自动跑测试，但谁动了 CI 门槛谁就得解释；允许模型生成大量代码，同时给删除、重构和合并重复实现留出明确时间。

速度可以交给机器，责任不能一起外包。

代码可能正在成为软件行业最便宜的东西

过去我们经常把“会写代码”看作开发工作的核心，因为把想法变成可运行程序确实很费时间。

这个成本正在快速下降。

以后一个项目里最贵的东西，可能是有人真的知道某段代码为什么存在；有人愿意在上线前说“这里我没看懂，先别合”；有人能在事故发生以后把调用链追到底；有人敢删掉模型一下午生成的五千行代码，因为他知道这五千行从一开始就不该存在。

如果一家公司的 AI 转型最后只剩下一件事——每个程序员一天能提交以前五倍的代码——那大概率不是什么技术革命。

只是把未来几年的维护账单提前打印出来，然后假装今天的研发成本下降了。

技术债不会消失。

它只会换个日期找你结账。

延伸阅读

主要资料