当写代码不再是瓶颈：给整套敏捷做一次资产重估

一句话看懂：AI让写代码变快，敏捷不但没有更重要，反而需要一次资产重估。过去敏捷是为对冲“人力昂贵、写码慢、执行是瓶颈”而设计的；当AI把写代码这一环的成本和速度彻底改变后，瓶颈正从“写得快不快”迁移到“想得清不清、审得住不住”。DORA 2026年报告提出“验证税”概念：写的环节省下的时间，正被搬到验证环节重新花掉。结对编程、每日站会、故事点估算等六项核心实践，有的需要重构、有的需要抬升、有的该被替代。管理者的重心必须从管交付速度，转向管判断力与验证力，否则AI带来的产能提速终将被判断力的塌方抵消。

一个流行的误解：AI 让开发更快，所以敏捷更重要了

过去三年，几乎每个技术团队都在讨论同一件事：AI 编码工具把“写代码”这件事变快了多少。GitHub 在 2023 年发表的一项对照实验里，95 名开发者被要求用 JavaScript 从零实现一个 HTTP 服务器，用上 AI 结对工具的一组比对照组快了约 55%（平均 1 小时 11 分对 2 小时 41 分）。到 2025 年，谷歌云 DORA 的《State of AI-assisted Software Development》调研显示，开发者使用 AI 工具的比例已从 2024 年的约 76% 升到约 90%。Stack Overflow 覆盖约 4.9 万名开发者的调查也给出同一方向的数字：使用或计划使用 AI 工具的比例达到 84%，其中约 51% 的职业开发者每天都在用。

顺着这个数字往下想，很容易得出一个结论：既然交付更快了，那强调“快速交付、小步快跑”的敏捷方法就更值钱了，我们该把敏捷贯彻得更彻底。

这个推论听起来顺，但方向错了。敏捷这套方法论——结对编程、每日站会、Sprint 迭代、故事点估算、代码评审、完成的定义——过去二十多年之所以长成今天这个样子，是为了对冲一组非常具体的约束：人力昂贵、沟通带宽有限、写代码这一环又慢又难。

回到它诞生的语境会更清楚。敏捷宣言写于 2001 年，极限编程（XP）、Scrum 这些实践成型的年代，一个团队要把一个功能从“想清楚”变成“能上线”，绝大部分时间花在敲代码、调试、集成上。写代码是整条产线里最慢、最贵、最容易出错的一环。于是几乎每一项敏捷仪式，本质上都是在“人写代码很慢”这个前提下，想办法让稀缺的工程产能流动得更顺——小步迭代是为了让慢的东西尽早暴露问题，结对是为了让写的过程更少出错，估点是为了给“慢”这件事做计划。这些设计都很聪明，但它们聪明的前提，是执行本身很贵。

当 AI 把“写代码”这一环的成本和速度彻底改变之后，真正被冲击的不是“要不要敏捷”，而是敏捷赖以成立的那些隐含前提。瓶颈正在从“写得快不快”，迁移到“想得清不清、审得住不住”。反常识的地方就在这里：AI 让写代码变快，恰恰让“快速交付”不再是稀缺能力；变稀缺的，是判断力和验证力。 一套为“执行慢”设计的方法，遇上“执行不再是瓶颈”的世界，它的每一个零件都要重新估价。

有意思的是，最新的行业数据几乎是在替这个判断作证。DORA 在 2026 年发布的《The ROI of AI-assisted Software Development》里提出了一个“J 曲线”：团队引入 AI 之后，通常会先经历一段生产力不升反降的低谷，之后才可能收获价值。报告给这段低谷里最主要的一项成本起了个很准的名字——验证税（verification tax）：为了确认 AI 生成的代码是否可靠、安全、与既有架构一致，团队必须额外付出的那部分工作量。写的环节省下来的时间，正被搬到验证的环节重新花掉。DORA 团队还把“技能退化”和“集成困难”一并列为这类看不见的隐形税。

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

一张“重估表”：每项敏捷实践，都要重新定价

理解这场变化，最好的工具不是一份新方法论，而是一次盘点。把“写代码的成本”看成一种被重新定价的资产——它从昂贵、稀缺，变成廉价、充裕。那么建立在旧价格之上的每一项敏捷实践，都要像资产重估一样，重新标一次价。

判断一项实践该怎么重估，只需要问一个问题：它当年主要是为了对冲哪个瓶颈？那个瓶颈还在吗？

顺着这个问题，每项实践会落到四种命运里的一种：

• 被替代（减记）：它的核心功能，AI 已经能直接接管，或者它衡量的东西在新约束下失去意义。这类实践要么退场，要么会主动误导团队——典型如“用产出量衡量团队”。
• 被增强（平价）：功能没变，但 AI 让它更快、更省力。这类实践基本保持原样，只是效率更高——比如自动生成文档、跑测试这些辅助环节。
• 被重构（重分类）：实践的形式还在，但重心变了——它原来服务的目的正在被掏空，必须换一个新目的重新支棱起来，否则就变成空转的仪式——典型如每日站会。
• 被抬升（增记）：因为瓶颈迁移，它反而从“锦上添花”变成“生死攸关”，团队必须往里投入更多资源——典型如代码评审和需求拆分。

一个基本规律是：凡是主要服务于“加速执行”的实践，倾向于被替代或被重构；凡是主要服务于“保障判断与验证”的实践，倾向于被抬升。 下面用六项核心实践把这张表填满。

结对编程：导师制被抽走，初级工程师的成长路径断了（被重构）

表现形式：经典的结对编程是“两个人、一台电脑”，一个人写、一个人审，边写边讨论。它表面上是为了提升代码质量，实际上承担了一个更隐蔽的功能——知识传递。初级工程师就是在与资深工程师结对的日常里，一点点吸收判断力、架构直觉和“什么是好代码”的品味。当结对变成“一个人 + 一个 Agent”，AI 补上了“随时有个搭子”的位置，但它补不上“资深工程师”的位置：它不会把你带成一个更好的工程师，它只会替你把活干了。

为什么值得警惕：GitHub 2023 年那项实验有一个常被忽略的细节——AI 带来的加速，对经验较浅的开发者最明显。这意味着最依赖 AI、最容易直接采纳 AI 输出的，恰恰是判断力还没成型的初级工程师。而 METR 在 2025 年 7 月发布的一项随机对照实验（16 名资深开源开发者、246 个真实任务、平均在相关项目上有约 5 年经验）显示，资深开发者在自己熟悉的成熟代码库里用 AI，完成任务反而慢了约 19%。两组数据拼在一起，指向一个令人不安的推断：AI 最能“帮上忙”的是新手，而新手恰恰最没有能力判断这份帮助对不对。

有一项研究把这层担忧推得更远。GitClear 在 2026 年初的一份分析里发现，重度使用 AI 的开发者，产出确实是不用 AI 者的四到十倍——但这个差距在他们用 AI 之前就已经存在。也就是说，AI 更像是被高绩效者选中的工具，而不是把普通人变成高绩效者的机器；若把同一批人和他们自己的过去比，速度提升只有约 25%。这对“给初级工程师配上 AI 就能追平资深”的期待，是一次相当直接的证伪。DORA 也在 2026 年把“技能退化”明确列为 AI 落地的隐形成本之一。

一句话影响：结对编程作为“写代码”工具的价值在下降，作为“培养判断力”机制的价值必须被重新设计，否则团队三五年后会发现自己缺一整代能扛事的中坚工程师。

每日站会：“昨天做了什么”越来越没意义，“要不要做、做对没有”越来越重要（被重构）

表现形式：每日站会的经典三问是“昨天做了什么、今天做什么、有没有阻塞”。它的价值前提是——在人写代码很慢的世界里，进度同步本身是有信息量的，谁卡住了、谁做慢了，值得每天对一次。

为什么值得警惕：当代码产出速度出现数量级提升，“昨天做了什么”这类进度播报的信息价值在迅速贬值——产出多不等于产出对。真正上升的，是另一类共识：我们到底要不要做这个、做出来的东西方向对不对、有没有偏离用户真正的需求。站会如果还停留在“报进度”，就会变成一个越来越空的仪式：每个人都报了一堆产出，团队却没人回答“这些产出加起来，是不是我们该做的事”。

一句话影响：站会不该被砍掉，但它的重心要从“同步执行进度”重构为“校准判断和方向”；否则你会开着一个准时、高效、却越来越不解决真问题的会。

速度与故事点：当交付不再是瓶颈，用产出衡量团队会奖励错误行为（被替代）

表现形式：Sprint 的核心是用故事点和 velocity（速度）衡量团队每个迭代“完成了多少”。这套度量在“执行是瓶颈”的年代很合理——产能稀缺，当然要盯着产出。

为什么值得警惕：一旦执行不再稀缺，用“完成的故事点”衡量团队，会开始激励错误行为——产出膨胀，但价值不增。DORA 2024 年报告给出了一个很硬的旁证：调研发现，AI 采纳度每提升 25%，交付吞吐量反而下降约 1.5%、交付稳定性下降约 7.2%（DORA 明确说明这是相关性而非因果）。报告推测的机制是，用 AI 后单次变更的批量（batch size）变大了，而大批量变更风险更高。换句话说，AI 让人更容易“写出更多代码”，但更多代码堆进一次交付，反而拖累了真正重要的交付表现。

值得补一句避免误读：DORA 2025 年的调研显示，随着实践成熟，吞吐量的负相关已经基本消失、追平，但稳定性受影响的问题仍然存在。这说明问题不是“AI 天然拖累交付”，而是“用旧度量管新产能”会出事。

更值得警惕的是，旧度量的问题还没解决，一批更糟的新度量已经冒出来了。DORA 在 2026 年点名了一种叫 tokenmaxxing 的新风气：一些组织开始统计并奖励员工消耗的 AI token 量，甚至做成内部排行榜来推动采纳。这种做法或许能推动观望者动手试试，但把“token 花了多少”当成绩效指标，是一个相当危险的陷阱——它把“用了多少 AI”直接等同于“创造了多少价值”，比故事点更彻底地脱离了结果。一个团队如果同时在用故事点和 token 排行榜考核，等于把“奖励产出量”这件事做了两遍。

一句话影响：继续用 velocity 当团队的产能 KPI，等于奖励团队制造更多、更难维护的代码；度量必须从“产出了多少”转向“交付是否稳定、是否真的改变了业务或用户指标”。

代码评审：从新瓶颈，升级为团队最该重投入的环节（被抬升）

表现形式：AI 可以在几秒内生成大量代码，写代码这一环的产能被彻底放开。于是瓶颈顺着水管往下走，卡在了下一环——人工评审。一个人一天能认真读懂、审明白的代码量是有上限的，这个上限不会因为 AI 而提高。

为什么值得警惕：评审不仅成了新瓶颈，它的重心也变了。过去人工评审很大一部分精力花在语法、风格、低级错误上，这些恰恰是 AI 现在最擅长兜住的。真正需要人来把关的，转移到了机器判断不了的地方：意图是否正确（这段代码做的，是不是我们真正想要的）、安全性、以及和整体架构是否一致。这正是 DORA 所说的“验证税”落地的地方——它不是一笔可以省掉的开销，而是新产能的必要配套成本。

开发者自己的态度，是这笔税最直白的证据。Stack Overflow 那份覆盖约 4.9 万名开发者的调查显示，尽管使用率升到 84%，信任却在反向下滑：认为 AI 输出准确的比例从上一年的约 40% 跌到 29%，明确表示不信任的（46%）已经超过信任的（33%），“高度信任”的仅约 3%；越资深越谨慎，资深开发者里高度信任的只有约 2.6%。开发者列出的头号困扰也很说明问题——约 66% 的人选了“AI 给出的方案几乎对、但又不完全对”，而这类“看起来能跑”的答案，恰恰最耗验证时间。

这种不信任不是偏见，而是理性的——它对应的正是“AI 能写、但不保证写对”这个客观事实。METR 实验里那个著名的落差最能说明问题：开发者事前预期 AI 让自己快 24%、事后仍自认为快了约 20%，实测却慢了 19%。人们系统性地高估了 AI 的帮助、低估了自己在“看懂和验证”上悄悄多花的时间——而这部分时间，正是评审。

这里有一个容易被忽略的连锁反应：当写代码的成本趋近于零，“重写”往往比“读懂再改”更省事。于是评审者面对的不再是一份需要理解的方案，而是一批随时可以推倒重来的候选。这看似灵活，实则危险——它让团队更容易跳过“到底为什么这么设计”的追问，直接在几个能跑的版本里挑一个。评审的价值，恰恰在于逼团队回答那个 AI 回答不了的问题：这段代码解决的，是不是我们真正的问题。

一句话影响：评审不该被当成交付流程末端的例行公事，而应被当成 AI 时代最该被保护、被投入资源的环节；评审能力（尤其是判断意图和架构一致性的能力）会成为团队最稀缺的资产之一。

需求拆分：“想清楚”从软技能，变成决定产出质量的硬前提（被抬升）

表现形式：用户故事和需求拆分，过去常被当成“开工前的准备动作”——重要，但没人会说它是瓶颈，因为再清晰的需求，也得靠工程师慢慢把它写出来，写的过程本身就是大头。

为什么值得警惕：当写这一环被 AI 大幅压缩，“想清楚”的前置价值就被空前放大了。AI 产出的质量，几乎直接由输入的清晰度决定：需求描述得含糊，它就自信地生成一堆貌似能跑、方向却错的代码；需求描述得精确，它的产出质量会陡增。这意味着“把问题想清楚、拆干净”从一项可有可无的软技能，变成了决定整条产线质量的硬前提。团队最贵的时间，正在从“写”迁移到“想”——想清楚要什么、边界在哪、什么算对。

一句话影响：需求拆分的严谨度，现在直接决定 AI 产出的良品率；一个“想不清楚要什么”的团队，AI 越强，它制造的偏差和返工反而越多。

技术债与完成的定义：看不见的债在快速堆积，“能跑”不再等于“完成”（被重构 + 被抬升）

表现形式：AI 快速生成的代码，往往能跑、能通过测试，却在悄悄制造“看不见的技术债”——重复的代码块、没有被抽象成可复用模块的逻辑、临时凑合的实现。

这不是一种感觉，而是被大样本量化过的趋势，而且还在恶化。GitClear 与 GitKraken 在 2026 年发布的《可维护性缺口》分析了 2023 至 2026 年约 6.23 亿行真实代码变更，跟踪七项代码质量信号，结论相当一致：每百万行变更中的重复代码块，从 2023 年的 40.3 处升到 2026 年至今的 73.0 处，比 2023 年高出约 81%，为有记录以来最高；代表重构与复用的“移动代码”占比，则从 2022 年的约 21%、2023 年的 13%，一路跌到 2026 年至今的约 3.8%；对既有代码的维护性重构，相比 2023 年下降了约 74%。更早的那版研究已经记录下一个标志性时刻：2024 年是有记录以来第一次，复制粘贴的代码量超过了重构（复用）的代码量。

这些都是可维护性正在滑坡的信号——AI 让“写一段新的”比“复用一段旧的”更省事，而复用恰恰是人类工程师积累经验、控制复杂度的主要手段。GitClear 给重复代码块起的名字很形象：传播税。当一个开发者改动某个五行代码块的一份副本，他就自动背上了一项义务——找出散落在各处的所有兄弟副本，逐一判断这次改动要不要同步过去，而那些文件和业务域，他很可能根本不熟悉。

为什么值得警惕：技术债的可怕之处在于它不报警。它不会让一次交付失败，只会让第三个季度、第五个季度的每一次改动都变慢一点、变险一点。当团队沉浸在“我们这个迭代产出翻倍了”的兴奋里时，债务正在资产负债表的另一侧无声累积。这直接冲击“完成的定义”（Definition of Done）：在旧世界，“能在生产环境跑起来”基本就等于完成；在新世界，一段能跑但无人真正读懂、重复冗余、没人敢改的代码，不该被算作“完成”。完成的定义必须升级——从“它跑起来了”升级为“它被验证过、可维护、有人能对它负责”。

一句话影响：如果不升级完成的定义、不把可维护性明确写进验收标准，AI 带来的产出提速会以技术债的形式，在未来某个季度连本带息还回来。

视角转换：敏捷的任务，从“管交付速度”变成“管判断力与验证力”

把这六项拼起来看，一条清晰的主线浮现出来。敏捷方法论诞生的初衷，是在一个“人贵、写码慢、执行是瓶颈”的世界里，让稀缺的工程产能尽可能顺畅地流动——它本质上是一套管理执行速度的操作系统。

而 AI 结对编程做的事，是把“执行速度”这个约束大幅松开。当执行不再稀缺，敏捷的工作重心必须整体平移：从管理交付速度，转向管理判断力与验证力。 用一个更具体的说法——过去团队最容易卡在“做得完做不完”，未来团队最容易卡在两处：一是“该不该做、做的是不是对的”（判断力），二是“做出来的东西到底对不对、稳不稳、能不能维护”（验证力）。

这背后其实是一个很老的道理——约束理论：优化非瓶颈环节，不会提升整个系统的产出，只会让瓶颈处的堆积更严重。过去大家默认瓶颈在“写代码”，所以拼命优化写这一环；现在写这一环被打通了，如果继续往那里加码，只会让下游的“想清楚”和“审得住”堵得更死。DORA 自己的分析人员就提出过一个耐人寻味的假设：写代码，本来就不是交付可靠软件的瓶颈。AI 只是把这个一直存在、却被“写码慢”掩盖住的真相，赤裸裸地摆到了台面上。

DORA 2026 年那份报告的结论，几乎可以看作这个判断的组织版本：AI 更像一台放大器，它放大高效组织的长处，也放大失序组织的功能障碍；最大的回报并不来自工具本身，而来自底层的组织系统——内部平台的质量、工作流的清晰度、团队之间的协同状态。工具是同一套工具，装进不同的系统里，结果会朝相反的方向跑。

这对管理者意味着一个更根本的转变：团队价值的重心，正在从“能产出多少代码”转向“有多强的判断力和验证力”。它会一路影响到团队怎么构成、招什么样的人、给谁涨薪——一个只会快速产出、却不会判断和验证的团队，在 AI 时代不是变强了，而是变脆了。

需要说清楚：这不是说敏捷过时了。恰恰相反，敏捷强调的“小批量、快反馈、持续验证”这些底层原则，在 AI 时代反而更重要——DORA 连续几年的数据都指向同一个提醒：基本功（小批量、健壮的测试）没做好，AI 的产能提升会直接转化成交付风险。过时的不是敏捷的原则，而是那些默认“执行是瓶颈”、并据此设计出来的具体仪式和度量。把它们逐一重估、该重构的重构、该抬升的抬升，才是对敏捷精神真正的继承。

三件今天就能动手的事

第一，重估你的度量，别再用产出量当团队 KPI。 打开你团队的看板和绩效面板，逐条问：这个指标奖励的是“更多代码”，还是“更对的代码”？故事点、代码行数、提交数这类产出量指标，在 AI 时代会系统性地激励错误行为；如果你的组织最近还上了 token 消耗排行榜，那就是又加了一层。把它们的权重降下来，把重心换成结果与稳定性指标——这个迭代有没有真的推动某个业务或用户指标、交付失败率和返工率有没有下降。度量什么，团队就优化什么；用旧度量管新产能，是当前最容易踩的坑。关于 AI 落地中的度量陷阱，88% 用上了 AI，只有 6% 真正赚到钱：AI 落地的价值鸿沟一文有更系统的拆解。

第二，把“评审”和“想清楚”当成一等公民，明确拨给它们时间和人。 在很多团队里，评审和需求拆分都是“挤时间做”的隐性工作，不占正式工时、也没人为它负责。这在 AI 时代是致命的，因为瓶颈恰恰迁移到了这两件事上。既然验证税是必付的成本，就该把它明明白白列进预算，而不是让它以“加班和返工”的形式偷偷结算。具体做法：给代码评审预留明确的产能，别让它被交付压力挤成走过场；把“就绪的定义”（需求是否想清楚）做得和“完成的定义”一样严格；让最资深的人把时间花在审意图、审架构、审边界上，而不是继续拼手速写代码。类似的组织系统问题，在企业AI创新案例｜8个月让20万名员工完成接入，摩根大通先统一的不是模型，而是风险边界里也有体现。

第三，主动重建初级工程师的成长路径，别让 AI 把他们养成“接受键操作员”。 结对导师制被削弱后，判断力的传承不会自动发生，必须刻意设计。可落地的做法包括：要求初级工程师不能直接采纳 AI 输出，而要能讲清“为什么这样写、哪里可能有问题、我改了什么”；把评审当成结构化的学徒场景，让他们在审别人（和审 AI）的过程里练判断；有意识地安排他们做一些“不许用 AI”的基础训练，把地基打牢。一个团队如果三年内没能培养出能独立判断的中坚，AI 给的产能提速终将被判断力的塌方抵消。

想把这套打法用到你自己的业务上？

如果你正在为团队的AI落地效果和敏捷实践调整而头疼，可以让AI顾问针对你的具体业务场景做一次快速诊断，看看瓶颈到底卡在判断力、验证力还是度量体系上。

💎 核心承诺：先诊断、再合作，思路不对不推进。

专属咨询热线：400 822 8832

扫码加顾问 Ben 评估