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 像一台放大器放大高效组织的长处也放大失序组织的问题。过时的是那些默认执行是瓶颈而设计出来的具体仪式和度量。按约束理论优化非瓶颈环节不会提升系统产出只会让瓶颈处堆积更严重。写代码的约束被解除后继续在写上加码只会让想清楚和审得住堵得更死。