宝玉｜AI 帮你写代码快了 50%，然后代码在审查队列里躺了三天

AI 帮你写代码快了 50%，然后代码在审查队列里躺了三天。

Nicole Forsgren 是 DORA 指标体系的创建者，《Accelerate》的第一作者。过去十年，软件行业衡量“交付快不快”的方式基本绑不开她的研究。2025 年 11 月，她和 DX 公司 CEO Abi Noda 合著的新书《Frictionless》出版，直接回应一个问题：AI 明明加速了一切，为什么团队交付还是不快？

2026 年 2 月，Forsgren 在 Gergely Orosz 主办的 The Pragmatic Summit 上做了一场对谈，覆盖 AI 时代的瓶颈转移、组织流程债务、度量陷阱和变革管理。

要点速览：

• AI 编码工具加速了开发者的**“内循环”（写代码、调试），但代码审查、CI/CD、部署等“外循环”**没有改善，整体交付速度提升有限
• 代码产出增加但审查流程没跟上，等于往堵塞的管道里灌更多水
• 组织流程债务（不再产生价值的会议、签批、旧流程）在 AI 时代变得格外刺眼
• 100% 的 AI 工具采用率 + 0% 的交付改善，完全可能发生
• Forsgren 给 CTO 的建议：追踪 Developer Flow，减少开发者被打断的频率

AI 让快的更快，慢的还是慢

Gergely 开场第一个问题：AI 时代带领工程团队，什么变了什么没变？

Forsgren 的回答是：基础面没变。清晰的目标、短反馈循环、心理安全感的文化，这些高绩效团队的要素不会因为有了 AI 就不重要。变的是瓶颈的位置。

她用了一个框架来解释：内循环和外循环。

内循环是开发者个人的工作：写代码、跑本地测试、调试。Copilot 这类工具在这个环节效果很好，确实加速了个人编码效率。

但写完代码之后呢？代码要进入审查队列等人来看，要过 CI/CD 流水线（自动化构建和测试的系统），要跑安全扫描，最后才能部署到生产环境。这就是外循环。

我们在让快的部分更快，但慢的部分还是一样慢。
（“We're making the fast parts faster while the slow parts stay just as slow.”）

Forsgren 举了个例子：AI 帮你写代码快了 50%，但代码审查因为团队壁垒或流程摩擦仍然要等三天，整体的**”价值交付时间”**其实没怎么改善。

注： DORA 指标是 Forsgren 领导的 DevOps 研究项目中提出的软件交付绩效框架，包含四个核心指标：部署频率、变更交付时间（代码从提交到上线的周期）、服务恢复时间和变更失败率。2018 年的研究成果集结为《Accelerate》一书，这套指标被全球大量工程团队采用。

代码洪水冲击审查关卡

Gergely 追问：会不会出现一场“代码海啸”冲击那些人工审查关卡？

Forsgren 说，这不是“会不会”的问题，是已经在发生。

代码产出量上去了，审查和发布流程没跟上，结果就是大规模堆积。她的建议是：AI 不应该只用来写代码，更应该用来审查代码。自动化测试也需要同步升级，减少对人工 QA 的依赖。

如果“检查”的速度跟不上“创造”的速度，你就有麻烦了。
（“If you don't scale the 'checking' with the 'creating,' you're in trouble.”）

多数公司谈 AI 编码工具时，注意力全在”怎么让开发者写得更快”。Forsgren 的提醒是，写得更快只是问题的一半，甚至是比较容易的那一半。

被 AI 照亮的流程债务

话题转到了“流程债务”。Forsgren 提出了一个概念：组织流程债务（organizational process debt）。

所有那些会议、签批、“我们一直这么做”的步骤，在它们被创建的时代可能有价值，但现在已经不再产生价值了。她认为，组织流程债务是高绩效最大的杀手之一。

在 AI 时代，这些遗留流程变得更可见，也更令人沮丧。过去开发者可能默默接受”审批要走三层”的事实，因为反正写代码本身也要好几天。但现在 AI 帮你半天写完了代码，然后你发现自己花了更长时间等各种流程走完，落差感格外强烈。

注： 技术债务（technical debt）是指软件开发中为赶进度而采取的权宜方案，日后需要花更多成本修复。Forsgren 提出的“流程债务”是类似的概念，但指向的不是代码，而是组织流程：为了当初某个原因设立的审批、会议、签字环节，早已失去存在意义，却没有人去清理。

AI 减负还是加负？

Gergely 问：AI 到底是帮开发者减轻认知负荷，还是在制造更多需要管理的东西？

Forsgren 说两者都是，所以它是双刃剑。

正面： AI 可以处理样板代码和信息检索，减少了日常负担。开发者不用再花时间写重复的模板，不用在文档里翻来翻去找一个 API 的用法。

但也有反面。 如果 AI 生成了一段开发者并不真正理解的代码，表面上省了时间，但在后续维护和调试时，认知负荷会大幅增加。你接手了一段“似懂非懂”的代码，出了问题不知道从哪里下手。

还有心流的问题。如果开发者需要花很长时间修复 AI 建议的东西，或者 AI 不断打断思路，心流就碎了。

这里有一个时间错配：AI 在当下节省的时间，可能在未来以更隐蔽的方式被“还回去”。

注： Forsgren 的 DevEx（开发者体验）研究框架将心流状态列为开发者体验的三大核心维度之一，另外两个是认知负荷和反馈循环。

害怕被取代的人不会好好用工具

Gergely 把话题拉回心理安全感：这个概念如何影响团队采用 AI？

Forsgren 说得很直接：如果开发者害怕 AI 是来取代自己的，或者用 AI 实验出了错被惩罚，他们要么抵制这个工具，要么隐藏自己怎么在用它。两种反应对团队都没好处。

“隐藏使用方式”背后的含义是，在一些组织里，AI 的真实采用情况可能和管理层看到的数据完全不同。有人在偷偷用但不敢说，有人在刷使用量但并没有真正从中获益。

Forsgren 给出的解决框架是**“结果所有权”**。高绩效团队拥有的是结果，不是代码行。AI 是帮他们达成结果的工具，但为什么选了某条技术路线，决策质量是否经得起检验，这个责任仍然在人身上。

高绩效团队拥有高度所有权。他们负责的是成果，不是代码行数。
（“High-performing teams have high ownership. They own the outcome, not just the lines of code.”）

100% 的采用率 + 0% 的改善

Gergely 问了一个很多管理层想知道的问题：怎么衡量 Copilot 的 ROI？

Forsgren 先笑了一下，说每个人都想要一个简单的数字。但**“代码行数”和“每天 PR 数”是糟糕的指标**，容易被刷，也说明不了价值或质量。

她建议采用多维度指标策略。一方面看 DORA 指标，比如部署频率和变更交付时间（代码从提交到上线生产环境的时间），看交付速度有没有真的提升。另一方面看开发者体验：开发者是不是没那么沮丧了？“首次绿色测试”的时间有没有缩短？

Gergely 接着提到，很多公司在汇报的只是**“席位利用率”**，就是多少人激活了 Copilot 许可证。

Forsgren 直接说，那只是采用指标，不能说明工具有没有在起作用。

你可以做到 100% 的采用率和 0% 的交付改善。
（”You can have 100% adoption and 0% improvement in actual delivery.”）

要看的是系统层面的影响：代码质量有没有提高？交付速度有没有加快？团队健康状况有没有改善？只衡量采用率，漏掉了全部重点。

注： DORA 的四个指标中，部署频率衡量代码部署到生产环境的频率，变更交付时间衡量从代码提交到部署上线的时间跨度。高绩效团队的变更交付时间通常在一天以内。

上面清路，下面实验

Gergely 问这么大的变革该怎么推动。

Forsgren 说必须两头推。自上而下，领导者需要清路：移除流程债务、提供资源、定调文化。自下而上，要让团队自己去实验，找出 AI 在自己特定工作流中到底哪里能产生价值。

如果试图从上层精确规定 AI 该怎么用，一定会失败。每个团队面对的代码库、工作流、技术栈不同，AI 在每个场景中的有效性差异很大。统一的使用规范可能反而变成新的流程债务。

Gergely 问到新书《Frictionless》的核心理念：零摩擦的工程组织有可能吗？

Forsgren 说完全零摩擦可能做不到，但比现在好很多是完全可以的。

目标是让“正确的方式”成为“容易的方式”。
（“The goal is to make the 'right way' the 'easy way.'”）

2026 年 CTO 最该追踪的一个指标

观众提问环节出了两个好问题。

第一个问题：怎么防止大家都变成不会调试的 prompt engineer？ Forsgren 的回答是，必须加倍投入基本工程技能。在 AI 时代，代码审查变得更重要，不是更不重要。初级开发者需要更多的导师指导，确保他们理解所构建系统的底层原理。

第二个问题更直接：2026 年 CTO 如果只能追踪一个指标，应该是什么？

Forsgren 没有选 DORA 里的任何一个。她选的是 Developer Flow：衡量开发者被糟糕流程、慢工具、不必要的会议打断的频率，然后努力减少这个数字。速度、质量、人才留存，都会随之改善。

度量开发者心流。如果你能减少打断的频率，其他一切自然会跟上。
（“Developer Flow. If you can measure how often your developers are getting interrupted… everything else will follow.”）

注： Forsgren 与 DX 公司深度合作，DX 的核心业务就是开发者体验度量。她推荐 Developer Flow 作为核心指标，与 DX 的商业方向一致。这不意味着建议本身无效，但读者应知晓这一利益关联。

Forsgren 在这场访谈中反复传递的信号可以归结为三句话：AI 加速的是内循环，但真正的瓶颈在外循环；工具采用率不等于价值交付；度量开发者体验，而不只是度量代码产出。

不过这场对谈也留了两个问题没有回答。Developer Flow 具体怎么量化？是问卷调研还是自动化埋点？Forsgren 没有展开。还有一个更根本的问题：她说目标是“让正确的方式成为容易的方式”，但在绝大多数组织里，“正确的方式”是什么、谁来定义，恐怕本身就是最大的摩擦来源。