如何衡量 2025 年的 AI 开发者生产力 | Nicole Forsgren
How to measure AI developer productivity in 2025 | Nicole Forsgren
嘉宾：Nicole Forsgren
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01原文文稿 · 00:00–1:07:19§01原文文稿 · 00:00–1:07:19
很多公司都在尝试衡量团队的生产力。
大多数生产力指标都是谎言。如果目标是写出更多代码行，我可以提示某个东西写出史上最长的代码。这套系统太容易被钻空子了。
我怎么知道我的工程团队推进得够不够快？他们是否还能更快？还是说他们只是没有发挥出应有的水平？
大多数团队都能更快。但为了什么而更快？我们可以每天更快地发布垃圾。我们需要战略和真正聪明的决策，才能知道该发布什么。
我们在 AI 上可能遇到的最大问题之一，是学会该在多大程度上信任它生成的代码。
我们不能只是输入一条命令，猜测它返回的东西，然后直接接受。我们确实需要评估它：有没有出现幻觉？可靠性如何？是否符合我们通常会采用的编程风格？
现在很多时间可能都会花在审查代码上，而不是编写代码上。
这里确实有机会让我们不只是重新思考工作流，还重新思考如何安排一天、如何组织工作。现在，即使是 45 分钟的工作时段也可以变得有用，因为进入心流的过程至少有一部分可以交给机器，或者机器可以通过提醒上下文、生成系统图来帮助我们重新进入心流。
你觉得工程团队或产品团队这周、下周能做什么，只做一件事，就能完成更多工作？
老实说，我觉得你能做的最好的事情是——
今天的嘉宾是 Nicole Forsgren。如今大家大量讨论 AI 如何提升开发者生产力，越来越多人开始问：‘我们该如何衡量这种生产力提升？这些 AI 工具究竟是在帮助开发者工作，还是在伤害他们的工作方式？’Nicole 在这个领域走得比任何人都久。她创建了目前使用最广泛的开发者体验衡量框架 DORA 和 SPACE，写了这个领域最重要的著作《Accelerate》，并即将出版新书《Frictionless》，为团队提供在新兴 AI 时代更快推进、完成更多工作的指南。她的核心观点是，AI 确实能加速编码，但开发者并没有像你想象的那样提速，因为他们仍然要面对构建失败、不可靠的工具和流程，以及正在出现的一批新瓶颈。在我们的对话中，我们讨论了她目前最好的、非常具体的 AI 生产力提升衡量建议；团队本可以更快推进的迹象；公司在衡量工程生产力时常犯的错误；AI 工具如何既帮助又伤害工程师，包括它们对进入心流状态的影响；她为公司建立开发者体验团队的七步流程；如何争取支持并衡量这类团队的影响，以及更多内容。本期适合所有希望提高工程团队表现的人。如果你喜欢这档播客，别忘了在你常用的播客应用或 YouTube 上订阅并关注，这会带来很大帮助。如果你订阅我的通讯年付方案，还能免费获得 15 款优秀产品一年的使用权，包括 Lovable、Replit、Bolt、n8n、Linear、Superhuman、Descript、Wispr Flow、Gamma、Perplexity、Warp、Granola、Magic Patterns、Raycast、ChatPRD 和 Mobbin。前往 lennysnewsletter.com，点击 Product Pass。接下来请听 Nicole Forsgren。本期由 Mercury 赞助。我使用 Mercury 办理银行业务已经多年。说实话，我现在无法想象还用别的方式办理银行业务。我从 Chase 换过来，天哪，差别太大了。汇款、追踪支出、让团队成员获得转账权限，都非常简单。大多数传统银行的网站和应用笨重又难用，而 Mercury 精心设计成直观、简单的体验。Mercury 把你使用资金的各种方式集中在一个产品中，包括信用卡、开票、账单支付、为队友报销以及资本服务。无论你是一家获得融资的科技初创公司，想给承包商付款并从闲置现金中赚取收益；还是一家需要开票并保持客户及时付款的代理机构；或者是一家希望掌握现金流并获得资本的电商品牌，Mercury 都可以根据你的业务需要进行调整。看看超过 20 万名企业家喜爱 Mercury 的原因。访问 mercury.com，10 分钟内即可在线申请。Mercury 是一家金融科技公司，不是银行。银行服务由 Mercury 的受 FDIC 保险的合作银行提供。详情请查看节目说明。给你出一道题：OpenAI、Cursor、Perplexity、Vercel、FLAN 以及数百家其他成功公司有什么共同点？答案是，它们都由今天的赞助商 WorkOS 提供支持。如果你正在为企业构建软件，你可能已经体会过集成单点登录、SCIM、RBAC、审计日志以及大客户要求的其他功能有多痛苦。WorkOS 将这些成交阻碍变成即插即用的 API，提供专为 B2B SaaS 打造的现代开发者平台。无论你是一家种子阶段的初创公司，正努力拿下第一个企业客户，还是一家正在全球扩张的独角兽，WorkOS 都是成为企业级产品、释放增长的最快路径。它本质上就是企业功能领域的 Stripe。访问 workos.com 开始使用，或者直接联系他们的 Slack 支持，那里有真正的工程师会非常迅速地回答问题。WorkOS 让你凭借令人愉悦的 API、全面的文档和顺畅的开发体验，像最优秀的团队一样构建。访问 workos.com，让你的应用今天就具备企业级能力。Nicole，非常感谢你来到这里，欢迎参加播客。
谢谢。很高兴来到这里。
很高兴你再次来访。我刚刚在看我们两年半前做的第一期节目。看着看着，我既震惊又不震惊：我们几乎没怎么谈 AI。那一期叫《如何衡量和提升开发者生产力》，直到节目开始将近一小时，我们才聊到 AI，还说：‘嗯，我想知道 AI 和生产力会发生什么。’这难道不让你觉得不可思议吗？
是的。因为当时它才刚刚登上舞台，已经成了很多讨论的主题；但与此同时，很多事情并没有改变。很多事情依然重要，很多事情仍然相同。是啊，已经过去两年半也有点不可思议。时间都去哪儿了？时间是社会建构的吗？
是的。我们当时的大部分对话都只是类似这样的问题：‘这可能怎样影响人们？我们会如何改变构建产品的方式？’那时它几乎还算不上什么。如今，当人们谈工程生产力时，我想他们唯一想谈的就是 AI。这正是我们今天要花很多时间讨论的内容。我之所以期待这次对话，是因为投入到提升生产力的 AI 工具上的资金实在太多了。世界上增长最快的公司就是这些工程 AI 工具公司。现在越来越多人都在问：‘我们从中获得了什么收益？它究竟在多大程度上帮助我们提高了生产力？我们怎样才能变得更高效？’你在这个领域的核心位置已经比任何人都久了。你创造了很多如今大家依赖的框架。所以我非常期待你回来聊这些内容。我想先从 DevEx 这个术语开始，它在整个领域经常出现，今天的对话也会反复用到。你能解释一下 DevEx，也就是开发者体验，究竟是什么吗？
DevEx 就是开发者体验。我们谈开发者体验时，真正谈的是开发者日复一日构建软件时的感受：他们遇到的摩擦、必须经历的工作流，以及能获得的支持。它很重要，因为如果 DevEx 很差，其他一切都帮不上忙。最好的流程、最好的工具，以及你拥有的任何魔法，如果 DevEx 很糟，所有事情都会——
生产力是 DevEx 的一部分。我认为你以及这个领域其他人的关键洞察是：这里不只有生产力，还有工程师在公司取得成功时的幸福感。我们会详细讨论其中很多部分，但你能不能先谈谈，除了生产力之外，还有哪些更广泛的因素会影响工程师在公司取得成功？
是的，我喜欢这个观点，因为首先，生产力本来就很难定义。但如果你只看产出，达到目标有很多不同方式。如果你是通过高重复劳动或高摩擦的方式达到目标，开发者最终会精疲力竭。或者，如果认知负荷特别高，以至于你连自己在做什么都很难思考，因为注意力都耗在某件事情的机制和底层管线上，那么你就没有足够的脑力去提出真正有创新的解决方案和问题。所以我喜欢把它看成一个自我强化的循环：‘你做更多工作，也做得更好。’这对人有利，对系统有利，对客户也有利。
我本来打算稍后再聊这个，但现在就想谈谈工程师的心流状态。我职业早期其实是一名工程师，读的是计算机科学，做了十年工程师。对我来说，工作最棒的部分就是写代码和构建东西时进入心流，那种感觉非常有趣。现在 AI 在很多方面似乎让这件事更困难了，因为你需要与各种代理协作，也有大量代码正在替你编写。请谈谈心流状态对开发者幸福感、开发者生产力的重要性，以及你看到 AI 产生了什么影响。你观察到 AI 如何影响这件事？
谈 DevEx 有很多种方式。其中一种是把它看成三个关键部分：每一部分本身都很重要，而且它们也会相互强化。心流状态是其中之一，认知负荷是另一个，反馈循环则是第三个。你问到心流状态，这是个很好的问题。我要承认，我们才研究了几年，目前仍在摸索，在这种工作方式下人们需要怎样的心流状态和认知条件。正如你所说，我们有时会不断被打断。你不再像过去那样进入心流、锁定状态，然后连续写大量代码、完成大量敲键盘的工作。相反，你可能要写一个提示词，得到一些代码，审查代码，并努力理解系统里发生了什么，这确实会打断心流。但另一方面，它也可能促成心流。我见过一些资深工程师搭建出非常惊人的工具链，他们找到了保持心流的方法。对他们来说，快速反馈循环确实非常有效。他们可以把不同部分分派给不同代理，让自己保持心流：心流的对象不再是逐行写代码的细节，而是‘我的目标是什么？我需要哪些部分才能达成目标？我能多快完成？’然后他们可以退一步评估整体，再深入进去修复某些部分。
关于那个找到很酷工作流的工程师，你还能再具体说说它是什么样的吗？
我和其中一些人聊过，也观察过他们工作。我还没有亲自搭建出来，已经列在我的待办清单上。他们能够设置非常惊人的工作空间和工作流。现在我们很多人会摆弄各种工具：写一个提示词，得到几行代码；或者写一个提示词，得到完整程序。但他们可以先通过提示词为代理建立上下文：‘这是我想构建的东西。它需要这些基本架构组件，需要这种技术栈，需要遵循这个总体工作流。帮我把它想清楚。’代理就会为此设计方案。然后，它会给每个部分分配一个代理并行工作，并且一开始就明确：‘这些部分必须能够协同工作，确保架构正确，使用恰当的 API 和约定。’最后，他们可以让它运行几分钟，去思考其他有趣的事情，或者提前处理预计会很棘手的问题；回来时，得到的东西可能比随手凭感觉生成的代码好得多。因为他们在一开始就进行了系统规划，所以结果离生产代码更近。
所以我听到的是，先花一点时间规划，也就是这些 AI 工程师都在做的事情，而不是直接冲上去、一边做一边想。
对。
好，很好。让我来谈一个我认为很多人都在思考的核心问题。很多公司都在尝试衡量团队生产力：‘这会提高我们的生产力吗？会损害我们的生产力吗？’我先问一个问题：公司目前在尝试衡量 AI 带来的生产力收益时，哪些做法是错误的？
我要说，大多数生产力指标都是谎言。这件事很棘手，因为从历史上看——现在，代码行数一直是个糟糕的指标，但很多人仍然使用代码行数——
[听不清 00:12:37]
……也就是把它作为产出、生产力或复杂度之类的代理指标。现在，对许多系统来说，那些曾经只小声谈、却不太公开承认使用代码行数的做法，已经完全站不住脚了，因为问题变成：‘代码行数究竟是什么意思？’如果目标是更多代码行，我可以提示某个东西写出史上最长的代码，再添加大量注释。我们知道，代理和大语言模型从定义上就往往非常冗长，所以这套系统太容易被钻空子，最终给所有工作引入复杂度和技术债。我想说，有些东西我们可以观察和关注。代码行数作为生产力指标并不好，甚至很糟；但如果我们能区分哪些代码来自人、哪些来自 AI，它现在又会变得更有相关性，因为我们可以回答后续问题：代码的存活率是多少？代码质量如何？我们的代码是否会被反馈到训练系统中？尤其是在微调和本地调优时，那些后来用于重新训练系统的代码中，有多少是机器生成的？这会形成什么样的循环？又可能无意中引入哪些模式或偏见？代码行数不是好的生产力指标，但它仍然可能有用。DORA 也是一样。我做过 DORA 指标，包括速度指标和稳定性指标。如果你只看这些指标，它们已经不够了，因为 AI 改变了我们对反馈循环的理解，反馈循环需要快得多。DORA 的用途是评估整个流水线的速度和稳定性，这仍然有效。但我们不能盲目套用过去使用的现有指标，否则会错过非常重要的现象，以及人们工作方式的变化。
有意思。你创建了 DORA，它长期以来是人们衡量生产力的主要框架。后来还有 SPACE、Core 4，可能还有其他框架。我的理解是，当 AI 贡献了大量代码时，这些框架都已经过时了。
我要说，如果一个指标是规范性的，就只能按照它规定的方式使用。
所以——
DORA 4 有四个关键指标。其中两个是速度指标：部署频率和交付前置时间，也就是从代码提交到代码部署。另外是稳定性指标：平均恢复时间 MTTR 和变更失败率。如果使用这些指标来评估流水线速度和整体表现，那很好。但如果你想用它们来理解更多事情，就要注意其中隐含了反馈循环：过去你可能主要从客户那里获得反馈，但在使用 AI 时不能再盲目这样做。现在反馈循环出现得更早，不仅存在于本地构建和测试阶段，还贯穿整个流水线，有时甚至发生在流水线中间；我们应该以过去没有充分利用的方式使用这些反馈。不是说过去做不到，只是我们没有真正把注意力放在那里。DORA 属于规范性指标。SPACE 则是一个框架，它不会告诉你应该使用什么指标。有时人们会很沮丧，因为我没有告诉他们该衡量什么，但我认为这正是它的力量。我们发现，SPACE 很适合 AI 这样的全新场景，因为我们仍然需要关注满意度，仍然需要关注绩效，也就是结果；仍然需要关注活动。代码行数和 PR 数量在某些情况下确实有用，警报数量或其他活动计数也可能有用。沟通与协作同样非常重要，因为这既涉及系统之间如何沟通，也涉及人与人如何沟通：‘有多少工作被转交给聊天机器人，而不是和团队里的资深工程师交流？’更多不总是更好，更少也不总是更好，要看具体情况。最后是效率与心流：人们能进入心流吗？完成事情需要多长时间？工作在系统中流动得怎么样？我可能还会增加几个维度。我和早期作者交流时会提到信任。不是说信任以前不重要，而是它现在特别突出。过去，代码编译成功就没问题了，但大语言模型具有非确定性。现在，我们不能输入命令，猜测它返回的东西，然后直接接受。我们必须评估：有没有幻觉？可靠性如何？是否符合我们通常的代码风格？如果不符合，是否可以接受？所以，规范性指标一定要用于合适的目的。
我们会谈到你目前认为做好这件事的最佳方式。你即将出版一本书，解释如何正确完成这件事，所以我们之后会聊到。我想强调一下我们上次对话中的一个重点：你指出 AI 可能带来的最大问题之一就是信任，也就是理解并学会该在多大程度上信任它生成的代码。你还在两年半前说过，现在很多时间会花在审查代码上，而不是编写代码上。这正是我目前听到的内容。
我认为，看看这会如何影响我们未来组织工作的方式会很有意思。我们刚刚谈到心流状态和认知负荷。现在，我们的注意力必须在特定时间集中，而且被工作方式打散了。我认为，这里确实有机会让我们不只是重新思考工作流，还重新思考如何安排一天、如何组织工作。
你能再多谈谈吗？具体会是什么样？你觉得事情会走向哪里？你看到什么做法有效？
这纯粹是推测。但比如 Gloria Mark 在注意力和深度工作方面做过很好的研究，人类每天大约只能进行四小时高质量的深度工作，大概就是这样。
是的，我能理解。
大体上，这差不多就是上限了。我相信人们会说：‘我可是超人，我能——’
如果你摄入 20 克肌酸呢？
对，如果我们微量服用呢？
对，确实。
既然知道我们每天大约只有四小时高质量深度工作……我相信很多人都经历过。我们会有状态很好的时段，有些人可能在早上，有些人可能在下午。然后你会到某个时刻，心想：‘我现在只能清理收件箱了。’你还能正常工作，但无法拿出最好的创新、解决问题、写作和写代码的表现。很多时候，要进入心流和深度工作，需要较长的连续时间。通常我说需要大约两小时；一小时可能很困难，因为进入状态本身就需要时间。想想三年或三年半前的旧日子，我们可以腾出四小时，可能完成两三个小时真正高质量的工作，因为我们当时很专注，几乎没有中断。现在，编写代码和构建系统本身就是由中断驱动的，或者至少充满中断，因为你开始做一件事后，系统就会插入新的事情。那该怎么办？四小时工作块可能仍然有用，但 45 分钟的工作块现在也可能变得有用，因为进入心流的过程至少有一部分已经交给机器，机器还可以通过提醒上下文、生成系统图以及其他方式，帮助我们重新进入心流。所以我认为这是一个非常有意思、充满问题和机会的领域。请大家研究这个问题，然后回来告诉我，因为它可能不会排进我的研究清单，但确实是个很好的问题。
这太有意思了。基本上，每个工程师都变成了工程经理，协调这些初级 AI 工程师。所以你的意思是，即使你有一个 30 小时的工作块，也可以深入代码，同时解除那些正在执行任务的 AI 工程师的阻塞。另外，正如你所说，它们会提醒你：‘你上次做到这里。’这样你就能直接跳回代码，也许再做些调整。
对。
很有意思。让我稍微拉远一点。在进入你关于如何处理开发者体验的框架，以及你最新的思考之前，除了显然‘工程师做更多事’是好事之外，你认为公司为什么应该真正、非常重视开发者体验？
我不太想说投资回报，但这里的商业价值和机会非常大。一般来说，我们会为了乐趣和爱好写软件，但我们拥有软件也是因为它满足某种业务需求：帮助获取市场份额、吸引和留住客户，以及完成各种事情。我认为 DevEx 很重要，因为它支持所有软件创作和问题解决，也支持与客户进行极其快速的实验。过去，一个原型可能需要一段时间，之后还要再花更久才能在生产系统中通过 A/B 测试上线；而现在，你可以在几小时内完成。
换到非常实际的一端，在谈更大的框架之前，你认为工程团队或产品团队这周、下周能做哪一件事，帮助改善开发者体验并完成更多工作？
老实说，你能做的最好的事情就是去和人交流并倾听。我很喜欢这档播客的听众主要是产品经理，因为他们通常很擅长这件事。我会建议先从倾听开始，而不是从工具和自动化开始。很多时候，公司会说：‘我要构建这个工具’或者‘我要做这个东西。’但他们构建的往往是自己遇到过的问题，或者某个容易实现、容易自动化的东西。如果你直接去和人交流，问开发者：‘想想昨天，你昨天做了什么？请带我走一遍。哪些时刻特别愉快？哪些时刻非常困难？什么时候感到沮丧？什么时候变慢？哪里存在摩擦？’你只要和几个人谈谈，通常就能发现一些投入不大但仍有影响的改进点，或者发现某个不必要地复杂、缓慢的流程。
所以，我听到的建议是：如果你想让团队更快推进、让工程团队更快乐，在做任何事情之前，先问他们什么事情在困扰你们。
去问他们，对。相信我，大多数开发者都会非常愿意告诉你什么坏了、什么很糟。我曾经合作过一家公司，他们有一个非常困难的流程，运行在一套老式大型机系统上。公司本来要重构整个系统，所以一直没人真正去处理或讨论它。所有人都讨厌这个流程，因为它造成了巨大的延迟。其实他们只需要改变流程。有时你只需要改变一个流程。这个案例中，他们把流程从原来的方式改掉了：我记得原来有人必须把文件打印出来，走下三四层楼去拿审批，然后另一个人再把它走回去，所以中间就产生了延迟。他们没有重构系统，也没有进行任何重大重新设计，只是发了一封电子邮件。
让我继续追问。我想知道，人们最常做的事情是什么。如果你刚开始说‘好，我们需要关注工程体验’，你发现公司最常需要做的两三个改进是什么？
我会重复刚才关于流程的观点：几乎总有一个流程可以改进，而且不需要大量工程工作或增加很多工程编制。尤其是大公司，通常都有某个流程包含很多很多步骤，只是因为‘一直以来就是这样’，所以才保持原样，但它已经不必再这样了。小公司有时则相反，流程太过随意，大家不知道该怎么做，只能四处追着人跑。因此，建立一个非常轻量的流程也会有帮助。如果你对组织其他部分了解有限，这可能是最好的起点之一。有时，仅仅改善团队流程就能产生作用。从业务领导者的角度看，你能做的很多事情是为这种组织变化提供结构和支持：沟通你在做什么，沟通优先级，沟通为什么重要，并庆祝胜利。如果大家把这件事当成一个一次性的、完全孤立的项目来做，就很难获得势头、让人关心并让他们持续参与。因为它看起来只是另一个不会产生影响、也不会得到庆祝的内部项目，但它对业务有巨大的潜在回报。
有意思，我听到的内容与工具或技术无关。不是迁移到某个云，也不是安装新的部署系统，而是流程、人员、组织和士气。
是的。现在当然有很重要的技术部分，尤其在 AI 时代，我们正在重新思考构建和测试系统如何工作，也在重新思考如何向用户提供反馈，让分享什么内容、什么时候分享都非常个性化。但其中涉及很多技术部分，却不只有技术。这些是必要条件，但不是充分条件，也不一定要从这里开始。
我想问一个谈到这里时想到的难题。这可能是大多数创始人和负责人都会思考的问题：我怎么知道工程团队推进得够不够快？他们是否能更快？还是说他们没有发挥出应有的水平？有哪些迹象能告诉你‘我的团队应该更快’，而不是‘事情本来就是这样，他们只能这么快’？
大多数团队都能更快，对吧？但考虑到我们对认知负荷的了解，并非所有速度提升都一定有益。达到某个阶段后，提升空间可能会受限，而大多数人甚至还没接近那个阶段。坦率地说，我想不出一个完全没有提升空间的团队。那怎么判断？如果你总听说构建失败、测试不稳定、流程过长；如果申请新系统或配置新环境很困难；或者很难在任务、项目之间切换，那就是信号。如果有人有机会去组织的另一部分工作，却因为一些不清楚、也不是政治因素的原因而不去；如果任何人谈到系统时都在抱怨，这通常意味着某处存在摩擦。因为一旦你终于熟悉自己的系统并能完成工作，转到别处的切换成本往往非常高。我合作过一些公司，在公司内部换组织，付出的代价几乎和新员工一样，因为系统差异很大，很多事情都充满摩擦，做起来非常困难。
我尤其喜欢你答案的第一部分：总能更快。每个创始人都会喜欢听到这一点。但正如你所说，随着时间推移会有收益递减，对吗？
对，而且你不知道质量如何。你总能更快，但为了什么而更快？我们是否做出了正确的业务决策？这正是产品经理发挥作用的地方。我们可以每天更快地发布垃圾，所以需要战略和非常聪明的决策来知道发布什么、实验什么、按什么顺序做哪些功能、如何逐步发布。战略是核心，然后再考虑如何加速。如果其他环节没有准备好，就是垃圾进、垃圾出。
我想沿着这个思路继续，但先复述一下：团队应该提高生产力的信号包括构建总是失败；测试不稳定、经常错误并产生误报；不同项目之间难以切换；以及大家都在说系统很难使用。大致是这样吗？
对。
回到刚才的观点，AI 正通过替团队写大量代码而让团队变快，未来还有异步代理和替你工作的工程师。但你的核心信息似乎是，这只是工程工作的一部分，还有大量工作，包括决定构建什么、在内部达成一致。工程绩效和生产力有很多提升机会，但还有许多事情不会通过 AI 得到改善，对吗？
是的，或者未来可能会改善，对吧？
嗯。
我认为我们可以用很多方式引入 AI 工具，帮助完善战略和信息，思考实验方法或目标，以及思考总可服务市场；但我们需要让战略和计划基本保持一致，或者至少准备两三个想测试的替代方案。现在工程工作，尤其是原型开发，可以快得多。只要基础设施到位，我们就能快速推出原型、运行面向客户的测试和实验，在过去需要几个月才能进入生产、做 A/B 测试并获得反馈的事情，现在一两天、肯定不到一周就能完成。但我们必须确保构建和测试的是正确的东西：是否与正确的伙伴合作？是否拥有所需数据？如果你与 AI 进行良好对话，再向专家确认应该看哪些数据、需要怎样的仪表盘、能做什么分析，AI 可以成为很好的伙伴。之后你还可以和数据科学团队说：‘我计划做这件事。’不要随意做 A/B 测试，因为大规模测试可能打扰用户或客户、破坏隐私或安全协议，最后还可能因为无法获得所需信号而得到不可用的数据。但我现在也看到人们把这个过程从几周加速到几天，于是他们能在信息更充分、更完整的情况下，与关键利益相关者展开讨论。
本期由 Coda 赞助。我每天都亲自使用 Coda 管理播客和社区。我会在这里放每位嘉宾的问题、社区资源并管理工作流。想象一下，你在工作中启动一个项目，愿景清晰，知道谁负责什么，也知道在哪里找到完成工作所需的数据。你不必浪费时间搜索，因为团队需要的一切，从项目追踪器和 OKR，到文档和电子表格，都在 Coda 的一个标签页中。Coda 的协作一体化工作区把文档的灵活性、电子表格的结构、应用的能力和 AI 的智能整合在一个易于组织的标签页中。正如我之前提到的，我每天都使用 Coda，超过 50,000 个团队信任 Coda 帮助他们保持一致和专注。如果你是希望提高协作一致性和敏捷性的创业团队，Coda 可以帮助你用创纪录的速度从规划走到执行。访问 coda.io/lenny，今天就能试用，并获得创业团队计划六个月免费。就是 C-O-D-A 点 I-O 斜杠 Lenny。很高兴你能和很多不同公司、不同类型的业务合作。很少有人能看到这么多公司的内部情况。你看到 AI 带来的生产力提升是什么样的？提升有多大？
我会说提升是真实的，但目前还没有很好的衡量方法。我们仍在摸索该衡量什么以及它应当是什么样。最好的指标之一可能是贯穿整个系统的速度：一个功能、产品或其他东西多快能走完整个系统，从而进入实验和测试；也可以是某个功能或组件从想法到最终结果的速度。这个指标很好，但很难直接归因于某个开发者手里的某个 AI 工具。我们也能观察一些其他事情，比如快速原型。我不喜欢代码行数，但还是要使用这个指标。我曾和一些人合作，他们观察了一整组公司，发现 AI 确实为经常使用它的人生成了显著更多的代码。但对于经常使用 AI 开发环境的开发者，工具带来的代码增长之外，工程师自己的代码增长是工具带来的两倍。所以我会说，这可能是一个次级信号：AI 能解除阻塞，加速你本来就会做的工作。有时我刚开始工作时很难启动，但一旦开始就能进入状态。因此它们非常擅长解除阻塞和激活工作。
我在 Twitter 上看到人们分享，尤其是 OpenAI Codex 很擅长找出非常棘手的 bug。我记得是 Karpathy 分享的：他被一个 bug 卡住了，没有 AI 工具能解决；后来最新版 Codex 花了大约一小时研究，帮他找到了问题。
对，我也听到过很多惊人的故事。它还可以编写和启动单元测试，创建文档、整理文档。现在人们会说：‘我们有代理，不需要读文档，因为代码在那里。’但事实证明，代理依赖高质量数据，因为一切取决于它们如何训练、如何获得依据。更好的数据会带来更好的结果，而文档和注释也属于这类数据。文档和注释越好，AI 工具的表现就越好。
AI 也能帮你写文档。我最近用 Devin 做了一些工作，它很擅长这些事情。
对。
好，我们来谈谈这个框架和这本书。你要出版一本叫《Frictionless》的书，听起来像一个梦想：怎样打造一支没有摩擦的开发团队？书名是《Frictionless：在 AI 时代移除障碍、释放价值并超越竞争对手的七个步骤》。它有一个七步流程。请带我们过一遍，也请介绍这本书的背景、目标读者、解决的问题，以及这七步。
我还要说，我是和 Abi Noda 一起写的。他创办了 DX，在这个领域有非常丰富的经验，合作过数百家公司，和他交流想法很有帮助。也感谢我们访谈过的工程负责人、DevEx 负责人、CTO 和工程师，他们帮助我们确认观察到的问题确实准确。至于这本书是为谁写的——
让我先就 Abi 和 DX 说个题外话。这个故事很有意思，也和我们正在讨论的内容直接相关。Abi 创办了 DX，这个名字非常适合开发者体验公司。他们刚刚以 10 亿美元的价格把公司卖给 Atlassian，相对于 ARR 来说是非常高的倍数。这说明这场对话为什么有价值，也说明公司愿意为改善开发者体验投入多少价值。Atlassian 愿意花 10 亿美元买下它。它是一家相对早期的创业公司，发展得很好，也深受用户喜爱，但仍然处于早期阶段，却卖了 10 亿美元。Atlassian 有大量公司在使用 Jira 和其他产品，这些客户都在想办法衡量生产力。对 Atlassian 来说，这非常有价值。我知道你也是他们早期的顾问，所以——
对。
这恰恰说明了它有多重要。
对，我认为这也说明你能从中获得多大价值。这里有很多容易取得的成果，也有很多尚未释放的潜力。即使在大型公司，那里有很多专业知识和非常聪明的人，如果你没进入这个领域、没用这种方式思考，就很难知道从哪里开始；或者很容易在前期犯简单错误，导致之后不得不重来。所以这又把我们带回了‘这本书是给谁看的’。它面向所有关心 DevEx 的人，尤其是技术领导者、想启动 DevEx 项目的人，或正在开展 DevEx 改善项目的人。我认为它对产品经理尤其相关，因为如果你管理的项目涉及软件构建和创作，改善 DevEx 只会帮助团队。此外，产品经理拥有对 DevEx 非常重要的技能、洞察和直觉，而这些东西我经常看到工程团队恰恰缺少。
好，这个框架是什么？有哪些步骤？人们该从哪里开始？
这本书介绍了一个七步流程，最后还给出了一些关键原则。第一步是开启这段旅程。也就是说，假设你要启动这项工作，你可以先踏上这段旅程。这包括我们已经谈过的内容：去和人交流，开展倾听之旅，综合你学到的内容，把工作流和工具可视化，弄清当前状况。第二步是取得一个快速成果。从小处开始，取得快速成果，选择合适的项目，分享你做成的事情。第三步是用数据优化工作。建立一些数据基础，找到已有数据，开始收集新数据，用问卷快速获得一些洞察，其中也可以包括问卷示例。第四步是决定战略和优先级。有了数据之后，你需要知道所有可能出问题的事项中，哪些最重要。如果你已经取得了快速成果，那么对于剩下的事项，‘我接下来该做什么？’我们在这部分介绍了一些评估框架。第五步是推销你的战略。作出决定后，现在你得说服其他人。因此你要征求反馈，说明为什么此时这是正确的战略。第六步是在你的影响范围内推动改变。这里我们会谈到影响范围较小的人：如果你只是在一个开发团队起步，想亲自做这件事，采取自下而上的努力；也会谈到影响范围较大的人：如果你是开发者体验副总裁之类的角色，你可以借助一些自上而下的手段。还有当你处于中间位置时如何推动改变，因为你可以利用两种战略。第七步是评估进展并展示价值，然后再回到前面循环。我要说的是，我们把书写成让你可以从自己当前所处的位置跳进任何一步。如果你正在启动一个团队或倡议，你大概会想从第一步开始，也确实应该从第一步开始。如果你加入的是一项既有倡议，可以直接进入确定优先级或落实改变的阶段。这就是七个步骤。除了这七步，我们还推荐几项实践：考虑为这件事配置资源、进行变革管理、让技术保持可持续，以及带着产品经理的视角来做这件事，‘我们如何把开发者体验当作产品来思考？又如何把我们拥有的指标当作产品来思考？’
太好了。好，我有几个问题。先请大家去看看这本书。网址是什么？怎么获得？什么时候出版？
好的，网址是 developerexperiencebook.com。现在你可以登记邮件列表。可以预订时我们会通知你，也会分享工作手册的部分内容。我们有一本将近一百页、配合这本书使用的工作手册，预计在年底前出版。
好。其中有一点是，“开发者体验”这个术语的用意似乎很明确，它不是开发者生产力，也不是开发者工作，而是我们如何让公司里的开发者体验更好。这当然包括他们能完成更多工作，但也包括他们更快乐之类的事。所以我认为这是一个重要元素，对吗？
对，绝对如此。
好。
因为，再说一次，这不只是生产力的问题。我们从“需要构建正确的东西”这个框架和视角来谈它。你希望有生产力，但你也希望思考的是……而这正是工程师特别擅长的事：给他们一个问题，不要告诉他们如何解决，他们就能把它解决得更好。他们拥有自由、创新能力和创造力，因此能解决这个问题。如果只谈生产力，那就只是代码行数、PR 数量或其他类似东西。但我们真正想谈的是价值：如何释放价值，如何更快获得价值。这当然包括让他们更有生产力、减少摩擦，因为这样他们就拥有我们谈过的心流、认知负荷等条件。
太好了。假如有人想启动这样的团队，它通常是什么样子？我记得在 Airbnb，这个团队形成时，大概就是一两名工程师开始牵头。你建议试点团队怎样配置？它成长后又会是什么样子？
有几种做法。假如你自己来做，可以由几名工程师来做，也许加一位产品经理、项目群经理或技术项目经理帮助沟通，因为沟通计划在这里确实非常重要。在小范围内，我们想寻找那些快速成果，寻找能够在小范围完成的事情。有些人把它们称作“纸割伤”之类的问题。这些小事能帮助人们亲自看到价值、感受到益处：‘怎样让开发者的工作变得更好？怎样让他们的日常工作变得更好？怎样从这里建立势头？’如果你是在自上而下的结构中工作，并且被授予了这项职责，你仍然需要一些快速成果，但这些成果的规模可以更全局一些，因为你有基础设施或支持，能够做不只局限于本地的不同类型改变。一个小型的局部改变，例如可以只是清理测试和测试套件。任何团队都能做，任何团队都能做。在更全局的范围内，可能是改变一项全组织范围内过于繁琐的流程，或者投入资源清理环境配置。
你见过这类团队成立后，对公司工程团队产生什么样的影响？
我要说，我见过对小公司产生很大影响，对大公司则可以是数十万、甚至数十亿美元的影响。不过，我们也需要学会怎样传达这种影响：‘这笔账该怎么算？’很多时候，我们可以看节省的时间、节省的成本，或很多不同事项。我们可以把价值实现速度看作上市速度，也可以看风险降低，收益确实存在。我会提到，它往往遵循类似 J 曲线的形态。你会先有几个快速成果，看起来像是一次大胜利；接着会遇到一个小低谷，因为那些最明显的项目、唾手可得的果实突然都处理完了。此时需要做一些工作，可能得多建设一些基础设施，增加一些遥测能力，以便捕捉我们想捕捉的内容。完成这些后，我们就会开始看到那些收益真正地复利累积。
回到那个衡量数字，你有什么建议？人们怎样找出这些数字？我觉得这正是这件事很有力量的一部分，比如‘我们做这件事省了一百万美元’。你会看什么来算出它？
我认为有几件不同的事需要记住，比如谁是我们的关键受众。通常我们有几个关键受众。我们确实希望能和开发者沟通，因为他们将使用这些系统。他们会与你合作构建系统，或者至少会为你的工作提供反馈。因此面对他们，我们通常要用他们关心的事情来表述，也就是节省时间。如果某件事变快，他们就能节省时间；不再需要进行设置时，就不用花时间做设置。这与减少重复劳动有关。合规和安全极其重要，但很多时候也需要好几个手动步骤。我并不是说它们毫无价值，只是从单个人的角度看，它们没有增值作用。如果能尽可能自动化，当然很好，也能改善专注时间。从开发者的角度来说是这样。领导层通常也在意这些事，但他们通常更在意其他事项。我们可以谈通常以美元计的成本：‘能否加速收入？我们的价值实现时间如何？速度如何？我们能多快从客户那里获得反馈？’对于身处竞争激烈环境的人员和组织，这会很有说服力，因为一切都关乎速度。我们也可以谈省钱。在这里可以尝试量化节省额。测试和构建就是一个例子。如果我们能够清理测试和构建套件，对开发者而言，他们想听的是节省时间、系统更可靠。重复劳动更少，因为他们不必不断重新运行测试，或去清理测试套件。从业务角度看，清理测试和构建套件可能带来云成本节省，因为所有这些测试都在某处的云上运行。如果它们总是失败，或者只是浪费支出，那么回收一些容量会很有价值。我们始终可以谈时间和生产力收益：‘我们在那些不一定增值的事项上损失了多少等值开发者时间？’有时还可以把它与业务结果相关联，相关性通常已经是我们在这里能做到的最好程度，但例如缩短价值实现时间与提高市场份额之间，可能出现相当有说服力的相关性。
我想顺着这条线索再问，回到我认为现在人们关于 AI 和生产力最大的问题。我觉得还没有人有答案，但很想听听你的看法：人们今天应该做什么？理解 AI 工具正在对生产力造成什么影响，最佳方法是什么？他们在这上面花了这么多钱。我不知道，我们得到了什么？我想事情确实推进得更快了，但我不知道。因此，如果有人必须想：‘好，我大概应该这样尝试做’，对于衡量 AI 工具对生产力影响，你最好的建议是什么？
我要说，这取决于情况。一部分取决于你的领导链真正关心什么。我们通常很擅长找出什么对开发者重要，也能把这些事传达给他们。但如果我们只是想确定两三个真正聚焦的数据点，因为刚开始做数据时有时会很有挑战性，那就要问：领导层关心什么？想想你听到的信息。他们是否一直在谈市场份额？如果他们谈的是市场份额流失或市场竞争力，就聚焦速度。想想怎样捕捉从功能到生产环境、从功能到客户，或从功能到实验的速度指标，以及反馈循环的样子。如果他们一直在谈利润率，现在，我们总会谈钱，因为这是商业；但如果这似乎是一个总括性的叙事，就寻找能省钱的方法，并把它转化为回收的人力成本。有时你会重塑、改变一个流程，之后就不再需要那么多供应商了。因此，减少供应商支出也会有帮助。我还说这取决于情况，是因为有时领导层会说一些话，并逐渐成为一种主题。如果你能解决他们的问题，或者解决他们关注的事，即使只是稍微重新表述一下，也会有帮助。比如他们把一切都称为开发者生产力，那就也称它为生产力；如果他们称之为速度，而速度对他们很重要，就想想怎样用速度来表述；如果他们在谈转型或颠覆，这怎样帮助实现颠覆？这样就会引起他们的共鸣。我们不希望让他们费力理解我们在做什么，以及我们提供的价值。
这建议太好了。我来复述一下：如果你的公司想弄清 AI 工具对公司产生了什么影响，第一步就是，公司最关心什么？领导最关心什么？可能是市场份额、利润率或速度。我们需要更高速度，或者需要转型。所以你的建议是，根据你听到的措辞和短语来弄清这一点。然后找出衡量它的方法，衡量市场份额增长、利润率提高的方法。我很喜欢这些例子，比如从功能或想法到生产环境、到实验的时间，因此也许可以开始跟踪它。如果是利润率，可以看因为更少测试失败而省下的钱，或不再需要支付的某个供应商费用之类的东西。至于速度，我想这就是 DORA 之类指标发挥作用的地方，也就是工程、交付的速度，或者……对于速度你会怎么看？
我会说，这其实属于那种……我会选择尽可能宽的范围。如果你能衡量从想法到客户，或从想法到实验，要花多久？通常要多久？在更好地使用 AI 工具、减少摩擦之后，现在要多久？我会说，这就是我们在书中稍微讨论的归因挑战：这是谁造成的？是开发者体验，还是 AI？直接披露这一点。说：‘是的，我们推出了 AI 工具，也开展了这项开发者体验工作，两者合作得非常紧密。’它们可能都对此有贡献，对吧？如果有 AI 工具却没有开发者体验改进，我们可能也会有一些改善，但远没有这么多。
如果人们今天开始做这件事，比如他们想：‘我想开始衡量开发者体验’，是否有两三个人人基本都需要、应该尽快开始衡量的指标？
如果你今天刚开始，手上什么都没有，显然先去和人交谈。之后我会做问卷，因为问卷能让你迅速得到整体状况的好视角，从而知道大的挑战在哪里。我这样说是因为，如果你刚起步，可能还没有贯穿系统的埋点和全部指标。即使已经有了，它们也可能不是你以为自己想要的。没有明确目的而设计的指标值得怀疑；为另一种目的设计的指标，可能适合你想做的事，也可能不适合，所以不能假定我们已经有这些指标。这是我喜欢问卷的一个原因，书里也给了一个示例。你只需问几个问题：‘你有多满意？对你的生产力最大的阻碍是什么，或完成工作的最大挑战是什么？’然后让他们从一组工具或一组流程中选择……让他们选三项，只选三项。在这三项中，它多久影响你一次？每小时？每天？每周？每季度？有时它每天都会困扰你，你会因此很生气；有时它每季度才发生一次，因为正值季度末，但负担极重。然后设置一个开放文本问题，如‘还有什么我们应该知道的吗？’这能给你极强的信号，因为让大家为前三项排序……如果让他们什么都选，数据会变得非常、非常混乱。但三件事加上发生频率，你就能得出一个分数，想要的话也可以得出加权分数，然后再深入研究数据应该在哪里、我们需要什么数据。同时你至少有了某种基线。它会是主观基线，但现在你会知道最大的挑战是什么。
我喜欢这一切都回到从和人交流、问他们这些问题开始。这和产品管理、打造优秀产品很像：你和客户谈过吗？每个人都以为自己在这么做，但大多数人做得不够。
我要说，思考获取数据时有一件事很有挑战性：访谈也是数据，而且很重要；问卷稍微更可量化，因为我们可以把它变成计数，但这也是我们要谨慎的地方。很多人写问卷题目时会问：‘过去一周，构建和测试系统是否缓慢或复杂？’这里其实问了四个不同问题。有人回答“是”时，是构建出了问题，还是测试？是慢，还是不稳定，还是复杂，还是别的什么？所以很难拆解你实际获得的信号。因此花时间和熟悉问卷设计的人聊聊是值得的，也可以和 Claude、Gemini 或 ChatGPT 讨论：‘这些是问卷问题。你能提出一些吗？’然后确保多来回几轮：这是不是一个好问题？我能从获得的数据回答哪些问题？我能解决哪些问题？如果不能用数据回答一个问题，就不要收集它。
书里有示例问卷，想直接复制粘贴、不想在这上面花太多脑筋的人可以使用。
对，有示例问卷和很多示例问题。我们甚至会建议格式和流程应该是什么样、应该多长、不应该多长。
我读到一点：你并不喜欢专门的幸福感问卷，也就是问工程师他们有多幸福，这是真的吗？如果是，为什么？
是的，我不喜欢。我要说，我不喜欢幸福感问卷，是因为影响幸福感的事太多了。幸福感包含很多东西，对吧？有工作幸福感、家庭幸福感、爱好幸福感、周末幸福感……有太多事情影响幸福感。这不代表我不关心幸福感。我认为幸福感问卷在这里并不特别有用。可能有帮助的是满意度，人们会说：‘那不是一回事吗？’不是，因为你可以问：‘你对这个工具满意吗？’然后再问一些追问。这两者有关，因为你越满意自己的工作、工具、工作内容和团队，就越会促进幸福感。我以前会开玩笑……记得那些高尔夫广告吗？‘快乐的奶牛做出快乐的奶酪。’
不记得。
我有一只卡拉布里亚犬。那广告最棒了。快乐的开发者写出快乐的代码。他们写出更好的程序，做出更好的工作，也是更好的团队成员和协作者。但捕捉并尝试直接影响幸福感，并不是我们在这里的任务。它太有挑战性，涵盖范围也太广。满意度可以给我们一些信号。
换个完全不同的方向，就你看到人们在用的工具而言，有没有哪一些让你觉得，‘哦，对，这个确实普遍很出色。’大家在这个工具上取得了很多成功。常见的有 Copilot、Cursor。我不知道。有没有什么突出的工具想分享，比如‘嘿，你应该看看这个工具，人们似乎很喜欢它’？
我觉得它们都很重要，对吧？Copilot、Cursor、Gemini。
Claude Code。
对，Claude Code。我很喜欢 Claude Code。
我正在写一篇完整的文章，讲如何把 Claude Code 用于非工程场景。
很酷，不错。
很有意思。比如你对 Claude Code 说：‘帮我找出清理笔记本电脑存储空间的方法。’它就会告诉你有一堆文件。它就像运行在你电脑上的 ChatGPT，可以替你在电脑上做各种疯狂的事，像一个小小的上帝。
我现在就去做这个。这太好了。
它非常好。对，这就是我在写这篇文章的原因。Dan Shipper 来过我的播客，他说 Claude Code 是被低估最严重的 AI 工具，因为人们没有意识到它能做什么。它不只是用来写代码，这正是我想进一步探索的。好，还有没有什么我们尚未谈到、你认为能帮助人们改善开发者体验、适应 AI 和工程这个新世界的有价值内容？
我觉得总体上有件重要的事，是把产品思维带入正在发生的任何开发者体验改进，也带入我们收集和捕捉的指标。我的意思是，我们要识别一个问题，确保自己是在为一组用户解决问题。我们要考虑创建最小可行产品和实验，获得快速反馈，快速迭代。我们要有战略，要知道自己的可服务市场是谁，要知道成功是什么。基本上，我们要具备上市职能。我们需要沟通，需要持续从客户那里获得反馈，需要不断改进。并且在某个时候，要考虑淘汰某项东西：它是否处于维护模式？是否正在被淘汰？我认为这总体上很重要，而现在尤其重要，因为当我们有 AI 工具、使用 AI 工具、把 AI 嵌入产品时，变化如此迅速，以至于停半拍说一句：‘好，我在这里想解决什么问题？我们过去十年一直拥有的这个指标还重要吗，还是应该淘汰，因为它已经不再重要，也没有推动我需要的那类决策和行动？’会非常重要。
在进入精彩的快问快答之前，我想带大家来到 AI Corner，这是本播客的常驻环节。你有没有在生活或工作中发现某种 AI 工具的用法，觉得分享起来很有趣、可能也对其他人有用？
我一直在做一些住宅设计和房间重新布置之类的事。我在和一位设计师合作，因为我知道自己喜欢什么，却不知道怎样实现，我不擅长这个。但我一直很喜欢用 ChatGPT 和 Gemini，特别是让它们为我渲染图片。我可以给它平面图，给它一张显然不是最终效果的房间照片，再给它几种不同物品的照片，然后只要告诉它换墙面、换家具布局或换别的东西。它能帮到我，而且相对很快。它帮助我把这些东西可视化……再说一次，我知道自己喜欢什么，却不知道怎样实现，因此我知道自己是否喜欢它。这大概是一个很随机的用法，但现在很有趣。
我妻子做的完全一样。她一直发给我：‘这是这块地毯放在我们客厅里的样子。这是这个水景。’它太好了，而且不断变得更好。你会觉得：‘哇，这就是我们家加上这块新地毯。’你只要上传这两张照片，然后问：‘好，这放在我们的房间里会是什么样？’
对，有几次让我印象深刻。机器显然在听我们说话。它给我一个房间或别的东西的效果图，然后放进一张狗床，因为我有狗。我会想：‘我没有叫你这么做，但对，这大概就是我该在这个房间里放的狗床颜色和风格。’
说到这个，你试过这种用法吗？问 ChatGPT：‘根据你对我的一切了解，生成一张你认为我家看起来是什么样的图片。’
没有。
因为它有记忆，会记住你谈过的一切，所以特别好笑。你一定要试试。
好，这放进我的待办清单。
就是这样，额外的使用案例。Nicole，说到这里，我们到了非常精彩的快问快答环节。我有五个问题要问你。准备好了吗？
太好了，开始吧。
你最常推荐给别人的两三本书是什么？
Peter Attia 的《Outlive》很棒。另一本我想也算相关，我伤了背，所以这不太好，但 Stuart McGill 的《Back Mechanic》非常出色。向所有伤到下背部的人致意。这本书让普通读者能够读懂并弄清怎样解决下背问题。这是一本有点随机的书。我要说，我很喜欢《How Big Things Get Done》。我不会念作者的名字，我想其中一位是……有一位是斯堪的纳维亚人。它剖析了近代历史中非常大型的项目，以及它们在哪里失败、为什么失败。我认为这很有意思，尤其是在当下这个 AI 时刻，我们至少所有的软件系统基本都会改变。那么我们该如何思考，怎样着手做一件本质上会是非常大的项目？抱歉，我还要额外加一本：Michael Lewis 的《The Undoing Project》。Matt Velloso 推荐给我的，它太好了。
对，我读过那本——
最后一句让我惊得倒吸一口气。
哦，我当时想：‘什么？’
我当时[听不清 01:03:48]。对，我完全没想到。
我读过那本，但不记得最后一句。天啊。好，下一题。你最近看过并喜欢的电影或电视剧是什么？
我要说，我会看《Love Is Blind》。如果一天结束时我需要放空，《Love Is Blind》很有趣。
出了新一季。
对，非常期待……还有《Shrinking》。你看过《Shrinking》吗？
没有。我想我开始看《The Therapist》了，对，我试着看过。
强烈推荐，很可爱。
很好。你最近有没有发现非常喜欢的产品？可以是应用、厨房小工具或衣服。
有，Ninja Creami 是——
你上次说过这个吗？
我不知道，也许说过。我觉得没有。
有人说过这个，我至今记得。它就像——
它太好了。
……你可以用它做冰淇淋之类的，对吗？
对，你基本上可以冷冻一杯蛋白奶昔，然后它会把它变成冰淇淋——
天啊。
……非常美味。另一个是 Jura 咖啡机。我喜欢好咖啡，但不擅长做，所以只要按一下按钮，它就能给我任何想要的饮品，包括拿铁、卡布奇诺或别的什么。因此很有趣。
很好。你有没有最喜欢的——
就是糖和咖啡因。我只需要撑过一天。
这就是工程生产力 101。
是的。
天啊。好，还有两个问题。你是否有一条常觉得对工作或生活有用、会以不同方式反复回想的人生格言？
对，我想有一句出现过几次，它不是逐字的说法，我觉得更像一种感觉：事后诸葛亮。但这句话也很蠢。我认为，如果我们在当时可获得的信息基础上作出了自己能作出的最佳决定，那么结果就是结果。如果你因为作了糟糕的决定而作出糟糕决定，明明知道得更多、手上也有那些信息，那确实不太好。但我认为我们没有给自己或其他人足够的宽容，因为后来我们总会发现更多信息。
赞同。最后一个问题。我原本想问你别的，但我们准备这次访谈时，你分享说自己在 Google 有了一个新职位。谈谈那个职位吧，你在那里在做什么，为什么加入 Google，还有任何大家应该知道的事。
当然。我是开发者智能和核心开发者部门的高级总监。这非常令人兴奋、也非常有趣，因为涉及我们谈过的所有这些事情。工作聚焦于 Google、它的所有业务资产和底层基础设施：我们如何改善开发者体验、开发者生产力、速度，以及我们谈过的所有这些方面。由于我算是关注数字的人，我们要如何思考衡量它？衡量会如何改变？反馈循环会如何改变？我们如何全面改善体验，并以有意义、有影响力、比从前更快的方式推动整个组织改变。
Google，干得漂亮，把 Nicole 招进去了。这真是大胜利。我得尽快多买点 Google 股票。好，两个后续问题：如果大家想深入了解，可以在哪里在线找到你和你的书？听众又怎样才能帮助你？
在线上，你可以在 developerexperiencebook.com 找到这本书；我在 nicolefv.com，偶尔也会上 LinkedIn。有时那里很乱，我会努力穿过所有噪音。要帮助我，就报名订阅这本书和工作手册。工作手册是免费的。我很希望得到任何反馈，知道哪些有效、哪些无效。我一直很喜欢听这些故事。
Nicole，非常感谢你来到这里。
谢谢你邀请我，Lenny。
我的荣幸，再次感谢。大家再见。非常感谢你的收听。如果你觉得本期有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用订阅节目。也请考虑给我们评分或留下评论，这确实有助于其他听众发现这档播客。你可以在 lennyspodcast.com 找到所有往期节目，或进一步了解这档节目。下期见。