如何在2025年衡量AI时代的开发者生产力
如何在2025年衡量AI时代的开发者生产力
嘉宾：Nicole Forsgren ｜ 谷歌开发者体验高级总监 ｜ 领域：开发者体验与工程效能
背景与引子
三年前，当Nicole Forsgren第一次做客这档播客时，我们关于AI与生产力的讨论只占了一个小时的尾声部分。彼时，AI还只是技术圈的热议话题，而非改变工作方式的核心力量。如今，一切都已不同。
从GitHub Copilot到Cursor，从Claude Code到各类AI编码助手，全球最快的增长公司几乎清一色是工程AI工具。数十亿美元涌入这个赛道，每家公司都在问同一个问题：这些AI工具真的让我们的开发者更高效了吗？效率提升了多少？
然而，当我们试图量化这些收益时，却发现答案远比想象中复杂。Nicole Forsgren是这个领域最有发言权的人——她创造了DORA和SPACE两大框架，撰写了被誉为“开发者效能圣经”的《Accelerate》，而她即将出版的新书《Frictionless》更是直指AI时代的开发者体验核心。
这场对话揭示了一个反直觉的真相：AI确实在加速编码，但开发者并没有像预期那样大幅提速。因为他们仍然要应对构建失败、不稳定的工具流程，以及大量新涌现的瓶颈。更关键的是，如何衡量这一切，至今仍是行业难题。
如果你正在带领工程团队、正在评估AI工具的投资回报，或者只是想知道如何让团队跑得更快，这篇文章值得你认真读下去。
一、嘉宾是谁
Nicole Forsgren在开发者体验领域的地位，无人能及。
她是DORA（DevOps研究评估）框架的创始人，这个框架在过去十年里成为全球科技公司衡量工程效能的标准方法。她还创建了SPACE框架，一个更全面的开发者体验评估体系。2018年，她与团队合著的《Accelerate》被《哈佛商业评论》评为年度最佳商业书籍之一，揭示了高效能工程团队的秘密。
在加入谷歌担任开发者体验高级总监之前，她曾帮助数百家公司优化工程效能。2024年，Atlassian以10亿美元收购了她曾担任早期顾问的开发者体验公司DX，这笔交易本身就是对开发者体验价值的最好证明。
她的新书《Frictionless》即将出版，这本与DX创始人Abby Notaro合著的著作，将为AI时代的开发者体验提供一套可操作的七步框架。
三年前她说“学习信任AI生成的代码将是最大挑战”，这个预言正在一一应验。
二、核心观点TOP10
-
大多数生产力指标都是谎言——如果目标是更多代码行数，AI可以轻松生成有史以来最冗长的代码。指标太容易被攻破。
-
代码行数不再是好的指标——LLM天然倾向于生成冗长代码。加上AI生成的代码后，我们需要区分哪些来自人、哪些来自机器，以及这些代码的长期存活率。
-
信任是AI时代的新维度——LLM是非确定性的，我们必须评估输出的可靠性、是否存在幻觉、是否符合代码风格。这不是可选项，而是必备能力。
-
代码审查的时间将超过代码编写的时间——这是三年前的预言，现在正在成为现实。我们需要重新思考工作日的结构。
-
流程优化往往比工具升级更有效——很多公司花大价钱买工具，却忽视了流程中的浪费。一次简单的流程改造，胜过多次技术重构。
-
大多数团队都可以更快——但问题是：更快是为了什么？我们可以每天更快速地交付垃圾。需要战略和明智决策来知道该交付什么。
-
倾听是改变的起点——与其购买工具，不如先去和开发者交谈。问他们昨天做了什么，哪些环节令人愉悦，哪些让人沮丧。
-
工程团队正在变成“AI工程团队的管理者”——即使只有45分钟的工作间隙，你也可以通过协调多个AI代理完成任务。AI可以帮助我们恢复上下文、快速进入状态。
-
AI代码助手真正的价值是“解锁”——研究者发现，AI生成了大量代码，但使用AI工具的工程师自己写的代码增量是AI生成量的两倍。AI更像是一个解除阻塞的催化剂。
-
开发者体验是一个产品——用产品思维来设计DX：找到要解决的问题、创建MVP和实验、持续获取反馈、适时淘汰不再重要的指标。
三、关键洞察
洞察一：AI让工程师变成了“包工头”
以前工程师需要自己一笔一划写代码，现在他们的角色正在转变为协调多个AI代理并行工作。优秀工程师的做法是：先花更多时间做前期规划，定义清楚要构建什么、架构如何、需要遵循什么规范，然后让不同的代理去并行处理各个模块。这要求更高层次的思考能力，但确实能实现更好的产出。
洞察二：45分钟工作块可能变得有价值
以往，进入心流状态需要至少两小时的专注时间。但在AI时代，机器可以帮助我们快速恢复上下文、生成系统图表、记住我们离开时的工作状态。这意味着以前“只能清理收件箱”的碎片时间，现在也可能变得有生产力。
洞察三：代码行数从糟糕指标变成了“有用但不充分”的指标
以前用代码行数衡量生产力已经很糟糕，现在有了AI，它变得更糟——因为AI生成的代码行数可以轻易爆炸式增长。但如果我们能区分哪些代码来自人、哪些来自机器，就可以回答一些有意义的后续问题：代码存活率如何？质量如何？是否在训练数据中引入了偏差？
洞察四：幸福感调查没有意义，满意度调查才有价值
幸福包含太多因素——工作、家庭、爱好、周末，不一而足。但我们可以问：你对这个工具满意吗？这两者相关但不同。更聚焦的满意度问题才能给出可操作的信号。
洞察五：DORA指标需要更新，但框架本身依然有效
DORA的四个核心指标——部署频率、变更前置时间、平均恢复时间、变更失败率——用于评估流水线的速度和稳定性依然有效。但我们不能盲目套用，因为AI已经改变了反馈循环的性质。我们需要在流水线中途就获得反馈，而不仅仅是等待最终编译结果。
四、精彩金句
“大多数生产力指标都是谎言。如果目标是更多代码行数，我可以提示AI生成有史以来最冗长的代码。这太容易作弊了。”
这句话直指指标设计的核心问题：我们测量什么，就会得到什么。当指标本身可以被轻松操纵时，它就不再反映真实情况。
“我们不能输入一个命令、得到返回结果然后直接接受。我们真的需要评估它——我们看到幻觉了吗？可靠性如何？它符合我们一贯的代码风格吗？”
信任是AI时代开发者的新必备能力。每一个AI输出都需要经过验证，而不是假设它是对的。
“我们可以每天更快速地交付垃圾。我们需要战略和真正明智的决策来知道该交付什么。”
速度本身不是目的。AI可以让我们跑得更快，但如果没有正确的方向，更快只会让我们更快地做错事。
“最好的建议就是去和人交谈、去倾听。很多时候，公司会说’我要构建这个工具’或者’我要实现那个自动化’。但如果你只是去和开发者聊聊天，问他们昨天做了什么、哪些环节很愉快、哪些很困难，你往往能发现一些相对低投入、高影响的改进点。”
大道至简。答案往往就在团队成员的口中，只是我们很少真正去问。
五、实战案例
案例一：省去三段楼梯的流程改造
Nicole分享了一个让她印象深刻的例子。某家公司有一个老旧的流程，需要工程师把文件打印出来、走下三四层楼梯获得审批、然后再走回去。整个团队都讨厌这个流程，但因为要重构整个系统太麻烦，所以一直搁置。
结果呢？他们什么都没重构，只是让这个流程改成发送一封邮件。就这样，问题解决了。没有技术债务，没有新系统，只是改变了一个早已过时的流程。
这个故事告诉我们：很多效率问题根本不需要技术方案，需要的只是有人愿意去听、去看、然后动手改变。
案例二：顶级工程师的AI工作流
Nicole观察过一些真正掌握AI工具的工程师，他们的工作方式令人印象深刻。诀窍在于前期投入更多时间：先让AI帮助设计整个架构——需要什么技术栈、遵循什么工作流、各模块如何协同。然后为每个模块分配一个代理并行工作，并明确要求它们确保各部分能协同运行、遵循正确的API和约定。
这样运行几分钟后，工程师可以切换去做其他事情，回来时得到的产出已经接近生产级代码——远优于随意的“氛围编码”。
案例三：从想法到用户的时间压缩
以前，一个功能从想法到生产环境可能需要数月。现在，具备正确基础设施的团队可以在一天或两天内完成实验和测试。但前提是：你得有正确的基础设施、有清晰的策略、知道该测试什么。
AI可以加速原型开发和实验执行，但无法替代战略决策和方向选择。
六、行动建议
建议一：本周开始“倾听之旅”
为什么要做：工具和自动化解决的是你想象中存在的问题，而不是团队真正面临的痛苦。只有通过对话才能发现真正的瓶颈。
如何开始：找三到五位开发者，问他们三个简单问题——昨天做了什么？哪些环节让你感到愉悦？哪些让你沮丧、慢下来或感到挫败？
能得到什么：你会发现一两个高影响、低投入的改进点，可能是某个流程、某个工具配置、或者某个被忽视的小痛点。
建议二：用满意度调查替代幸福感调查
为什么要做：幸福感太模糊，无法给出可操作的信号。满意度更聚焦，可以帮助我们定位具体问题。
如何开始：设计一份简短调查，包含三个维度——满意度评级（如对这个工具的满意度1-5分）、主要障碍（从给定列表中选择最多三个）、发生频率（每小时/每天/每周/每季度）。
能得到什么：一个可量化的基线数据，知道最大的挑战在哪里、影响有多频繁，可以据此排序改进优先级。
建议三：学会区分“速度”和“方向”
为什么要做：AI可以让你跑得更快，但如果方向错了，只会更快地做错事。战略决策永远是第一位的。
如何开始：每次讨论速度提升时，先问三个问题——我们在构建正确的东西吗？我们知道该优先做什么吗？我们的决策依据是什么？
能得到什么：避免“快速交付垃圾”的陷阱，确保速度提升真正转化为业务价值。
建议四：建立信任核查清单
为什么要做：AI生成的代码可能包含幻觉、风格不一致、逻辑错误。直接接受会引入技术债务和质量风险。
如何开始：为团队制定一个简单的核查清单——输出是否合理？是否符合代码风格？是否存在明显的逻辑错误？必要时补充单元测试。
能得到什么：更高的代码质量标准，更少的生产事故，团队对AI输出的信任建立在验证基础上而非假设之上。
建议五：用产品思维设计开发者体验
为什么要做：开发者体验本质上是一个产品，需要用户研究、MVP、迭代反馈，而不是一次性的大方案。
如何开始：识别你的“用户”（开发者）面临的核心问题，创建最小可行解决方案，在一个小团队试点，收集反馈，快速迭代。
能得到什么：一个持续改进的机制，而非一次性的项目，确保DX投入长期有效。
七、我的总结
Nicole Forsgren用一句话点破了AI时代开发者效能的本质：大多数团队都可以更快，但更快是为了什么？
在这场对话中，她揭示了一个重要真相——AI正在改变游戏规则，但它改变的不只是编码方式，更是整个开发体验的运行逻辑。代码行数变成了糟糕的代理指标，因为AI可以轻易生成海量代码。流程和流程中的摩擦比工具本身更重要。信任成为了新的必备维度，因为每个AI输出都需要验证。开发者正在变成协调者而非执行者，而这要求更高层次的思考能力。
她的SPACE框架在AI时代依然有效，但需要加入“信任”这个新维度。她的七步框架——从倾听开始、找到快速胜利、用数据优化、确定策略优先级、推销策略、推动变革、评估进展——为任何想要改善开发者体验的团队提供了清晰的路径。
最重要的是：答案往往就在你的团队中。去听，去问，然后动手做。
新书《Frictionless》可在 developerexperiencebook.com 获取，包含近100页的工作手册和实用调查模板。
📺 播客信息
- 发布时间：2025-10-19
- 时长：1小时7分钟48秒
- 播放量：17057 次观看
- 原版视频：『YouTube』