AI 编码提速后瓶颈去哪了？用验证税重估六项敏捷实践与研发度量

先说结论

团队接入 Copilot、Cursor、Claude Code 这类 AI 编码工具之后，"写代码"这一环确实快了。但很多团队随后发现：迭代产出翻倍，交付却没有更稳，返工和评审队列反而变长了。

原因不复杂：瓶颈没有消失，只是从"写得快不快"迁到了"想得清不清、审得住不住"。 敏捷里的结对编程、站会、故事点、代码评审、需求拆分、完成的定义（DoD），是为"人力贵、写码慢"这个约束设计的。约束变了，每项实践都要重新估一次价。

本文给出一张可以直接拿去团队复盘用的"重估表"，外加三项工程检查。

一、先看数据：快了多少，又在哪里还回去

几组常被引用的数字：

• 提速：GitHub 2023 年的对照实验中，95 名开发者用 JavaScript 从零实现一个 HTTP 服务器，使用 AI 结对工具的一组平均 1 小时 11 分完成，对照组 2 小时 41 分，快约 55%。
• 普及：Google Cloud DORA《State of AI-assisted Software Development》（2025）显示，开发者使用 AI 工具的比例从 2024 年约 76% 升到约 90%；Stack Overflow 约 4.9 万人的调查中，使用或计划使用的比例为 84%，约 51% 的职业开发者每天使用。
• 反向信号：METR 2025 年 7 月的随机对照实验（16 名资深开源开发者、246 个真实任务）里，资深开发者在自己熟悉的成熟代码库中用 AI，完成任务反而慢了约 19%；而他们事前预期快 24%，事后仍自认为快了约 20%。

DORA 2026 年的《The ROI of AI-assisted Software Development》把这个落差命名为 验证税（verification tax）：为确认 AI 生成的代码可靠、安全、与既有架构一致而额外付出的工作量。写的环节省下的时间，被搬到验证环节重新花掉。报告同时提出了引入 AI 后先降后升的"J 曲线"，并把技能退化、集成困难列为隐性成本。

一句话：产能没有凭空多出来，它换了个地方要账。

二、判断方法：这项实践当年在对冲哪个瓶颈？

给每项实践只问一个问题——它当年主要为了对冲哪个瓶颈，那个瓶颈还在吗？ 答案会落到四类之一：

重估结果	含义	典型实践
被替代（减记）	核心功能已被 AI 接管，或衡量对象失去意义，继续用会误导团队	用 velocity / 故事点衡量产能
被增强（平价）	功能不变，AI 让它更省力	文档生成、跑测试等辅助环节
被重构（重分类）	形式还在，但原目的被掏空，需要换新目的	结对编程、每日站会
被抬升（增记）	瓶颈迁移后从"锦上添花"变成"生死攸关"	代码评审、需求拆分

规律：服务于"加速执行"的实践倾向于被替代或重构；服务于"判断与验证"的实践倾向于被抬升。

三、六项实践逐条重估

1. 结对编程：被重构

经典结对表面上保障代码质量，实际承担着知识传递——初级工程师在和资深工程师结对中积累架构直觉和代码品味。换成"一个人 + 一个 Agent"后，AI 补上了"随时有个搭子"，补不上"带教"。

需要警惕的组合：GitHub 实验里 AI 对经验较浅的开发者加速最明显，而这群人恰恰最难判断 AI 输出对不对。GitClear 2026 年初的分析还发现，重度使用 AI 者的产出是不用者的 4–10 倍，但这个差距在使用 AI 之前就已存在；和自己的过去相比，提速只有约 25%。"给新人配上 AI 就能追平资深"并不成立。

工程动作：结对的目标从"写代码"改为"培养判断力"，把评审 AI 输出作为带教场景。

2. 每日站会：被重构

"昨天做了什么"在产出速度数量级提升后信息量迅速贬值——产出多不等于产出对。站会重心应从同步进度转向校准方向：这件事要不要做、做出来的方向对不对。

3. Velocity 与故事点：被替代

执行不再稀缺时，用"完成的故事点"考核会激励产出膨胀。DORA 2024 年报告的相关性数据（非因果）：AI 采纳度每提升 25%，交付吞吐量下降约 1.5%，交付稳定性下降约 7.2%，推测机制是单次变更批量变大。DORA 2025 年数据显示，随实践成熟，吞吐量的负相关基本消失，但稳定性问题仍在。

DORA 2026 年还点名了 tokenmaxxing：统计并奖励员工消耗的 token 量、做内部排行榜。它把"用了多少 AI"直接等同于"创造了多少价值"，比故事点更脱离结果。

4. 代码评审：被抬升

AI 几秒生成大量代码，瓶颈顺流而下卡在人工评审——一个人一天能读懂的代码量不会因 AI 提高。评审重心也变了：语法、风格、低级错误交给工具兜底，人要审的是意图是否正确、安全性、与整体架构是否一致。

开发者的信任数据说明这笔税为什么省不掉：Stack Overflow 调查中，认为 AI 输出准确的比例从约 40% 降到 29%，明确不信任（46%）超过信任（33%），约 66% 的人把"几乎对、但不完全对"列为头号困扰——这类"看起来能跑"的答案最耗验证时间。

还有一个连锁反应：写代码成本趋近于零时，“重写"比"读懂再改"更省事，评审容易退化成在几个能跑的版本里挑一个，跳过"为什么这么设计”。

5. 需求拆分：被抬升

AI 产出质量几乎由输入清晰度决定：需求含糊，它会自信地生成方向错误但能跑的代码。"把问题想清楚、拆干净"从软技能变成决定良品率的硬前提。

6. 技术债与 DoD：被重构 + 被抬升

GitClear 与 GitKraken 2026 年的《可维护性缺口》分析了 2023–2026 年约 6.23 亿行代码变更：

指标	变化
每百万行变更中的重复代码块	2023 年 40.3 处 → 2026 年至今 73.0 处（+约 81%）
“移动代码”（重构/复用）占比	2022 年约 21% → 2023 年 13% → 2026 年至今约 3.8%
对既有代码的维护性重构	相比 2023 年下降约 74%

GitClear 把重复代码的代价叫作"传播税"：改一份副本，就要找出所有兄弟副本逐一判断是否同步。技术债不报警，只会让之后每个季度的改动更慢、更险。所以 DoD 必须从"能在生产跑起来"升级为"被验证过、可维护、有人能对它负责"。

四、三项可以本周落地的工程检查

检查 1：度量面板里，哪些指标在奖励"更多代码"？
逐条过看板和绩效面板：故事点、代码行数、提交数、token 消耗排行榜，降权；换成交付失败率、返工率、以及迭代是否推动了某个业务或用户指标。度量什么，团队就优化什么。

检查 2：评审和"就绪的定义"有没有正式工时？
既然验证税是必付成本，就列进预算：为代码评审预留明确产能；把 Definition of Ready 做得和 DoD 一样严格；让资深工程师把时间花在审意图、审架构、审边界上。

检查 3：初级工程师能否讲清"为什么这样写"？
要求不能直接采纳 AI 输出，必须说明为什么这样写、可能哪里有问题、自己改了什么；把评审当结构化学徒场景；有意识安排一部分不使用 AI 的基础训练。

这套重估思路最早来自 Runwise 对 AI 时代研发管理的分析，原文把六项实践的判断依据和数据来源列得更完整，可以参考这篇《当写代码不再是瓶颈：给整套敏捷做一次资产重估》。

五、边界说明

这不是说敏捷过时。"小批量、快反馈、持续验证"的原则在 AI 时代更重要——DORA 连续几年的数据都提示：小批量、健壮测试这些基本功没做好，AI 的产能提升会直接变成交付风险。DORA 的描述是，AI 像一台放大器，放大高效组织的长处，也放大失序组织的问题。

过时的是那些默认"执行是瓶颈"而设计出来的具体仪式和度量。按约束理论，优化非瓶颈环节不会提升系统产出，只会让瓶颈处堆积更严重。写代码的约束被解除后，继续在"写"上加码，只会让"想清楚"和"审得住"堵得更死。