Presentation: AI is an Amplifier: Scale High Performance, Not Dysfunction

AI 是放大器：扩展高性能，而非放大失能 - InfoQ

InfoQ 首页 演讲 AI 是放大器：扩展高性能，而非放大失能

文化与方法

扩展 OpenTelemetry：管理收集器、配置和成本（11月19日网络研讨会）

AI 是放大器：扩展高性能，而非放大失能

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

48:41

总结

Nathen Harvey 分享了 DORA 研究关于软件交付中 AI 采用的见解。他解释了为什么 AI 起到放大器的作用，DORA AI 能力模型如何驱动结果，以及为什么工程领导者必须超越代码审查等瓶颈，实现可持续的生产力，减少交付不稳定性，并在不使团队疲惫的情况下赋能开发者。

简历

Nathen Harvey 领导 Google Cloud 的 DORA 团队，利用其研究帮助组织提高软件交付速度、稳定性和效率。他专注于提升开发者体验，并致力于培育技术社区，如 DORA 社区，该社区为学习和协作提供了机会。

关于会议

软件正在改变世界。QCon 伦敦通过促进知识和创新在开发者社区中的传播，赋能软件开发。作为以实践者驱动的会议，QCon 专为技术团队负责人、架构师、工程总监和项目经理设计，这些人员在团队中推动创新。

INFOQ 活动

• 2026年10月29日，美国东部时间下午1点 从 Token 到 Features：为 AI 辅助工程构建成本归因架构 演讲者：Martin Reynolds - Harness 字段首席技术官，Barani Mohandoss - Trimble 云治理、FinOps 与 E-工具总监

• 2026年11月19日，美国东部时间中午12点 扩展 OpenTelemetry：管理收集器、配置和成本 演讲者：David Iparraguirre - Datadog 高级产品市场经理，Jessica Yang - Datadog 产品经理

演讲稿

Nathen Harvey：对于那些不熟悉 DORA 的人，我想先明确一下我们这里讨论的是哪个 DORA。其实有很多个。有一个叫 Dora 的小孩，她是我最喜欢的。在座有多少人看过《Dora 探险》这个节目？Dora 的美妙之处在于，她每次经历转变性旅程时，背包里都有地图，并且她总能分三步完成。当然，Swiper 总是试图让她偏离轨道。我要告诉你们，你们的 AI 采用旅程也会是这样。它分为三个简单的步骤，只是路上会有一些 Swiper 的干扰。当然，我们此刻在欧洲，所以我们也有《数字运营弹性法案》（Digital Operational Resilience Act）中的 DORA。我可以向你们保证，如果你们和团队在自动化方式下提升软件交付和运营能力，这会让《数字运营弹性法案》的监管机构感到满意，因为你们将变得更加有韧性。

在美国内，我来自的地方有一些州制定了特定的法律。他们称之为指定户外饮酒区（Designated Outdoor Refreshment Areas）。这意味着只要你留在指定户外饮酒区内，就可以拿着啤酒四处走动。我必须承认，这可能是我在这个世界上第二喜欢的DORA。当然还有其他类似的区域，但我无法一一列举。我今天要谈论的是这个名为DORA的研究项目，它已经持续了十多年。这项研究真正关注的是：团队如何变得更擅长技术？我们如何变得更擅长IT？我们如何变得更擅长软件交付？我们如何不仅在技术上，而且作为团队、作为人，变得更优秀？我们如何推动业务发展并真正服务客户？

DORA曾经是一个缩写，但我们现在去掉了它的缩写。DORA现在没有特定的含义，这听起来似乎也不太对。我们有一个标语，这就是DORA所代表的含义。它代表的是“不断进步”。有趣的是，我们将在演讲的最后部分讨论这一点，我开始质疑我们的标语。我担心它现在可能无法为我们服务。关于这一点，稍后我会详细说明。

2025年DORA研究

如果你对DORA有所了解，你可能知道我们每年都会进行一次调查。我们每年都会进行一次大规模的调查，也许你曾经参与过这项调查。如果你参与过，感谢你与我们分享你的数据和见解。这对我们非常有帮助。去年，我们有近5000人参与了我们的调查。我们还通过额外的定性研究来补充这些数据。定性研究基本上是定性研究员与从业者、领导者进行面对面的访谈，试图更深入地了解实际情况。

我将分享我们最近一次调查的一些数据。在这张幻灯片的底部有一个小脚注，你将会看到。这项全球调查于2025年6月13日至7月21日之间进行。我将告诉你一些关于AI采用情况的信息。你认为这些信息准确吗？我可能在欺骗你。我们将这个问题留给你来判断。去年我们发布了这份报告《AI辅助软件开发现状》。你可以在dora.dev/dora-report-2025下载2025年的报告。你可以在那里获取并阅读这份报告，它有140页，所以我将为你总结一下。我现在要测试你，因为我又放了一个二维码。这次，我真的希望你能参与进来。我希望你能回答这个问题：是什么阻止了你？你刚刚用AI生成了某些东西，或者你的同事刚刚用AI生成了某些东西。

是什么阻止了你立即将其部署到生产环境中？为什么不直接部署到生产环境？让我们看看我们现在的想法。是什么阻止了你？信任。你不信任这个解决方案。治理、安全、质量、不确定性。被解雇，有人可能因此被解雇。这很好。这很有趣，因为如果你不使用AI，你是否也会被解雇？这很有趣。你可以继续提出一些答案。我认为这些答案非常有趣。恐惧。我不知道。我们是一家银行。别用这个作为借口，你仍然可以做得更好。

我想谈谈AI的采用和使用情况，以及我们的数据发现了什么。请记住，我们是如何收集数据的？通过调查。90%的人会在调查中说实话，10%的人撒谎。这张幻灯片的问题是：在座各位中有多少人正在工作中专业地使用AI？我们调查的90%受访者回答“是”，10%的人说“我不被允许使用，所以最好回答‘否’”。请记住，这是去年6月和7月的数据。我们不会再问这个问题了。正如我所说，我们已经进行了10年的研究，从未问过“你工作中是否使用电脑”这样的问题。从现在起，我们可以停止询问“你工作中是否使用AI”，因为答案是肯定的，你确实在使用。你对它的依赖程度如何？我认为这些数字可能已经发生了变化。对某事物的依赖程度与仅仅使用它是不同的。

比如，如果我依赖某样东西，而它突然消失，这就会带来问题。我们在这里看到的是，大约35%的受访者表示“我几乎不依赖或完全不依赖”。大多数受访者表示：“是的，我依赖使用AI来完成我正在做的特定任务或任务集。”我认为这非常有趣。它是否有所帮助？我们稍后会谈到。这个发现对我来说也非常引人深思。我们问：“回想最近的工作日，你与AI互动了多少小时？”现在，请停止。我明白，我正在陷入这些糟糕的婚姻模式。我坐在家里，正和AI一起解决某个问题，眼看就要到晚餐时间了，而我的妻子已经准备好让我停止工作了。我知道，再发一个提示，再等一分钟我就到。

再发一个提示。求你了，不要12个小时。如果你是这个图表中的长尾部分，请站起来，走开。如果你正坐在这里听这个演讲，请合上笔记本电脑，停止使用AI。听我说一分钟，这会让我感觉好一些。我向你保证，这对你的长期健康更有好处。这里有趣的是中位数小时数，与AI互动的中位数是两小时。有其他研究（不是我们的研究，也不是我将引用的研究），但确实存在一些高质量的研究，它们提出了这个问题：“软件工程师每周通常花多少时间实际编写代码？”这些研究的结果差异很大，但高端估计在10%、15%、30%之间。两小时在八小时工作日中占比是多少？大约是30%。你很可能正在使用AI来帮助你编写代码。此外，我认为这对我们来说也是一大挑战，人们如何看待我们这些软件工程师？AI将取代你的工作，因为它将为你编写所有代码。它将夺走你10%时间在做的事情，因此我们不再需要你了。这种计算方式对我来说也不合理，它行不通。

它对您有帮助吗？您对使用它有什么感受？您认为它对个人生产力的影响是正面的。您感觉自己变得更高效了。我觉得自己能完成更多工作。我对当前从事的工作更有参与感了。我感觉现在花更多时间在有价值的工作上，可能减少了重复性劳动的时间。大约5%的人认为自己的生产力略有下降、中度下降或大幅下降。我使用AI时也确实经历过这样的日子。我肯定经历过这样的情况。这非常有趣。我们对它的依赖程度很高。我们使用它的频率很高。我们感觉它确实帮助我们提升了效率。那代码质量呢？您正在参与的代码库质量如何？也在提升。大约有10%的人认为使用AI后代码质量反而略有下降。我们的代码库质量确实有所下降。这是一个非常困难的问题，比如，它对代码质量的影响究竟如何？

您说的代码质量具体指什么？这是我们研究人员面临的挑战之一。我们自己也不清楚。我们想请您告诉我们，代码质量具体指什么。您只需回答这个问题，我们就能收集数据。关键在于，您对AI生成内容的质量信任程度有多高？您对它生成的任何内容有多信任？无论是代码，还是即将发送给上司、客户或为家人制定的财务计划。您对这些内容的信任程度有多高？30%的人表示信任度较低或完全不信任。我必须告诉您，我属于中间立场。我想和您坐下来喝杯咖啡。如果您是那11%的人，认为对AI非常信任或完全不信任，那么您其实都错了。

您不应该对AI有极高的信任。这些人可能是我最想沟通的对象。我想了解他们的想法。如何？您在做什么？那些完全不信任的人，难道不觉得有错失机会的焦虑吗？您必须开始掌握这些技能。那场精彩的主题演讲，我们必须开始公开学习并积极接受这些新理念。

如果我用三张幻灯片为您总结整个2025年报告，我现在就来做。AI在软件开发中的主要角色是放大器。您在AI上的投资回报最大来源，将来自于对组织基础系统的战略关注。没有这个基础，AI往往只会创造局部的生产力提升，这些提升常常会被后续的混乱所抵消。我在LinkedIn上看到一篇帖子，有人哀叹现在虽然能用几小时就构建出某个东西，但要让这个东西进入客户手中并投入生产，仍然需要六周时间。我们加速了系统的一部分，但整个行业尚未以整体视角思考整个系统。这正是我们在数据中看到的情况。

探索AI与关键结果的关系

我们确实喜欢用DORA来报告你们告诉我们的内容，我们也试图理解和理清你们组织的复杂性，即我们正在使用的这些技术工具。AI与关键结果之间是什么关系？我向你们保证，我只会用一张图表来说明一次。我会教你们如何快速解读这张图表。我们所做的就是收集大量数据，构建一个小型模型，这会告诉我们世界的形态。作为研究人员，我们拥有这一惊人的能力：我们可以指出这个复杂世界的形态，并说：“让我们只改变一件事，看看会发生什么。”我鼓励你们回到自己的组织中，尝试只改变一件事，观察会发生什么。因为你们做不到。这是不可能的。我们的数据和模型构建方式就是如此。

我们说：“让我们改变一件事。”我们要改变什么？我们要改变你们在AI采纳方面获得的分数。我们将提高AI采纳程度，其他条件不变，然后在模型中运行大量模拟。会发生什么？如果你们在垂直条上获得的这个结果分数保持不变，你们的点会出现在代表零的虚线上。虚线右侧表示该指标增加，左侧表示减少。个人效能提升最多，软件交付的不稳定性增加。我再强调一遍，这可能并不是你们期望的结果。组织绩效、用于有价值工作的时长、代码质量、产品性能、软件交付吞吐量，以及团队表现都可能有所改善。而倦怠感和摩擦则基本保持在零。从点中间延伸出的小条形，代表我们的置信度。

我们称这些为误差条。这不仅仅是我们的叫法，它们的正式名称就是误差条。条形越宽，我们对此的置信度越低；条形越窄，置信度越高。如果你们观察倦怠感和摩擦，它们都接近于零，且误差条与零有明显重叠。对于倦怠感，这可能在六月或七月时有道理。我可能会反驳这一点。想象一下，你正在工作中，感觉很糟糕，感到筋疲力尽，质疑自己所做的一切。你的经理走过来对你说：“这里有AI工具。”猜猜怎么着？工作依然很糟糕，你依然讨厌自己正在做的事情。这显然对缓解倦怠感没有任何帮助。仅仅给你一个新工具并不能解决问题。我们看到了这一点。积极的一面是，它至少没有造成伤害，也没有让情况变得更糟。我目前确实感到担忧。

在座有多少人正在管理一个代理（agent）集群？也许“集群”这个词听起来数量太多，比如三到四个。如果你正在用三到四个代理完成工作，而它们各自执行的任务差异很大，你可能会发现自己在不同任务之间来回切换。这没问题，很酷。因为作为人类，我们都非常擅长多任务处理，有研究表明确实如此。不，等等，事实正好相反。我们其实都特别不擅长多任务处理。这很酷，我们干脆把所有任务都交给代理去做。我本人就经常发现自己会说：“我告诉这个代理我要告诉它的内容。”我们正在承受的认知过载，我认为我们尚未完全理解。我担心今年的研究可能会得出截然不同的结论。

当我们在思考这些事情时，有些方面正在改善，而有些则变得更糟。例如，软件交付的不稳定性正在加剧。在DORA中，我们衡量软件交付不稳定性的方式是观察生产环境中的推送频率，以及这些推送是否会导致我所说的“咒骂时刻”。你们都经历过这种情况：将更改推送到生产环境后，你或你身边的人会突然喊出脏话，然后大家会惊慌失措地问：“我们该怎么办？我们必须立即采取行动，比如回滚更改或推送紧急修复补丁。”这种场景就是软件交付不稳定性。随着AI的引入，这种不稳定性正在上升。2024年的数据显示，与去年相比，软件交付不稳定性有所增加，而软件交付吞吐量则下降。但今年我们看到这一趋势正在改善，随着时间推移，我们观察到一些变化。这些变化大多与转型过程中的J曲线效应有关。

每当组织引入新事物时，通常都会经历这样的模式：引入新工具后，会先解决一些显而易见的问题（低垂的果实），这些改进会让一切看起来非常顺利。但当所有低垂的果实都被摘取后，就必须面对真正困难的部分。这时情况会变得棘手，软件交付不稳定性开始上升，组织会陷入低谷期。今天我想重点讨论这个低谷期，其中涉及两个关键因素：软件交付不稳定性，以及缺乏信任。这种信任缺失会带来大量工具验证工作，而验证过程可能还会改变工作职责。例如，我是一名软件工程师，我写代码？不，我只是审查代码，甚至只是阅读其他人的代码，而这些代码的作者可能已经不再是开发者了。

这种信任缺失会将组织带入“不稳定税”和“验证税”的深谷。但另一方面，我们之前已经经历过类似情况。DORA的研究持续了十余年，我们曾亲历云计算刚兴起时的变革。当每个组织引入云计算时，最初情况会略有改善，但随后会变得更糟，直到我们掌握如何有效利用这项技术。同样，SRE（站点可靠性工程）实践也是如此。从我们长期的数据模型来看，我们已经知道这种模式会发生。但目前还不清楚的是，由于所有这些技术都还很新，且技术变化速度极快，我们该如何跨越这个低谷？如何到达另一侧？目前我们正在集体学习答案，所有人正在共同探索解决方案。

团队绩效——七种团队画像分析

使用 DORA，我们也想了解团队的表现如何？你们做得怎么样？我们通常只关注软件交付绩效，并发布了软件交付绩效的基准，还给低绩效团队和精英团队这样的群体命名。你们中有多少人上班是为了成为低绩效团队？我不这么认为。有些人可能默默地举起了手，但你们坐在经理旁边，我理解你们。我看到了你们。我们是工程师，我们本就应该属于低绩效团队。让计算机去处理这些事情吧。我们不仅关注软件交付绩效。事实上，我们想了解团队在八个不同因素上的表现：团队绩效、产品绩效、效率、摩擦、倦怠。请记住，我们发现至少 90% 的受访者在使用 AI。我们还发现，当从这八个不同特征来看时，存在七种独特的团队类型。

这告诉我们一个重要的信息：这并不是 AI 的问题。如果每个人都使用 AI，但我们看到的绩效水平差异巨大且高度可变，那么这既不是 AI 的错，也不是 AI 导致这种情况的原因。这七种团队类型具体是怎样的？首先，由于我们有七种类型，我们不能只使用低、中、高和精英这样的分类。我们必须想出更具创意的名称。仅从这些名称来看，你可能会发现自己或你的团队。让我们看看图表吧？不，让我们看看七张图表。不，你在这里什么都看不到。这些图表真的很难读。我们可以说，这简直像是犯罪，使用这种蜘蛛图或雷达图。它们的表现方式与它们应有的方式不符。我们不会看这些图表，因为无论如何你都看不到它们。

让我们来看看这里的两个不同群体。受流程限制的团队。他们就像在跑步机上奔跑。尽管他们正在处理稳定的系统，但他们的精力被低效的流程消耗，导致高倦怠和低影响力。你们中有多少人现在感到被理解？在这里可以看到，倦怠程度很高。摩擦也很高，或者我告诉你，因为上面写着。个人效率很低。我花在有价值工作上的时间很少。我的软件交付不稳定性实际上很好，比其他人的都要低。我的吞吐量也比其他人的略低。这不是一个完美的团队，但也不算糟糕。我们见过更糟的情况。我们并没有真正交付很多价值。让我们将这与和谐的高绩效团队进行对比。当你回到工作岗位时，你可以告诉老板，我们是一个和谐的高绩效团队。就像这样，这就是卓越的表现，我们认为。

我们拥有一个良性循环、稳定且低摩擦的环境，赋能团队可持续地交付高质量工作而不至于筋疲力尽。我们必须思考这些方面：我们能否可持续地交付质量？我们能否在组织内以低摩擦的方式实现这一点，同时不耗尽员工的精力？这些都是非常重要的考量因素。关键在于，如果我们让所有人都使用AI，但团队表现存在巨大差异，我们该如何克服这种差异？这里有哪些信号？我有一个问题想问你：为了自信地信任AI生成的解决方案，你环境中需要改变哪一件事？我们刚刚问过你什么阻碍了你。让我们换个角度探讨这个问题：什么阻碍了你？你现在能改变哪一件事，从而打开某些大门？同样的二维码，新的答案：防护措施、测试、测试过程、安全装置、管理、能力、端到端测试、自动化测试。我特别关注其中一点，即验证。我的经理。这是真实的。可观测性。教育。获取更好的模型。治理。这非常棒。

DORA AI能力模型

如果问题不在于你是否使用AI，可能在于你使用AI的方式。我们以前就见过这种情况。多年前我们研究云计算时，发现有些团队从云中获得了大量价值，而有些团队却认为云更慢且更昂贵。为什么我们要转向云？这并不是因为你有没有云。而是你使用云的方式。Nicole Forsgren博士经常提到这个现象，她将其比作健身房会员资格。在座有多少人拥有健身房会员资格？有多少人经常去健身房？仅仅拥有会员资格是不够的。它不会让你变得健康。你必须付出努力。我们对此进行了研究。我们想了解，是否存在某些特定因素，让一些团队能从AI中获得比其他团队更多的价值？我们识别出的七个能力，当它们与采用率结合时，能推动更好的成果。

你可能已经听过几个主题。有一场演讲讨论了AI的采用、AI的部署和AI的价值。你仅仅通过购买工具无法获得采用。你仅仅通过采用也无法获得价值。没有采用，你就无法产生影响。坦白说，这让我们面临许多挑战。我与Blanca讨论过度量问题。我们如何知道它是否有效？让我们去度量它。我希望你对度量保持谨慎。度量中最重要的事情之一是理解我们要回答的问题是什么。我与另一个人讨论时，他谈到自己组织的情况。他恰好坐在董事会。他参加董事会会议。董事会成员会问：我们正在用AI做什么？我们使用AI了吗？大家都在使用吗？

他们唯一关心的问题是采用率。告诉他们你正在推进采用，展示相关数据，到此为止。这已经足够回答他们当前的问题。你只需要这些数据来回应这个问题。明年他们可能会问：“你们都采用了这些技术，我们的回报在哪里？”这时问题就不同了。我可以向你保证，如果没有采用，就别指望能获得回报。你必须从这里开始。我们都知道，仅仅衡量采用率是不够的。这还不够。请以你所信仰的任何神圣事物为证，停止衡量AI生成了多少行代码。有多少软件工程师曾经喜欢被用编写代码行数来衡量工作表现？为什么AI就不同？这是一个愚蠢的指标。停止这样做。真正重要的事情是这七大能力。如果你的团队和组织具备这些能力和条件，就能将你目前高度关注的采用率转化为真正对我们有意义的成果。

我们已经明确了立场并进行了有效沟通。如果你不清楚在组织中何时、何地、哪些AI可以使用、哪些不能使用，这将给员工带来各种摩擦。如果我不知道是否应该使用AI，会发生两种情况：要么我干脆不用，对此心安理得；要么我知道AI的威力，因为我在家已经用过，我会把它带到工作中并无论如何使用。然后我会担心被发现并因此被解雇。确保你的立场清晰且已传达。接下来，我们需要一个健康的数据生态系统并能访问内部数据。你希望AI为你做得更好？确保它理解组织的政策？

你试图服务的客户是谁？确保所有这些信息对AI都是可访问的。接下来的两个要点与AI无关。首先是强大的版本控制实践。如果你没有信心能轻松回滚更改，AI可能会走向非常混乱的路径。我与很多人交谈过，他们说：“我发现自己现在更频繁地提交版本控制。”对此我问：“你在说什么？为什么不是每两分钟就提交一次版本控制？为什么这个做法现在才出现？它确实出现了，是时候了。学习这些版本控制实践。你真正需要知道的只是提交和回滚。如果你能安全且自信地做到这些，你将处于更好的位置。”下一个同样重要的要点是小批量工作。

如果DORA没有发现其他内容，那就是：如果你想提高软件交付吞吐量和软件交付稳定性，最有效的方法是通过交付更小的变更。当你以小批量工作时，你可以清楚地理解自己在更改什么。当出现问题时，你可以清楚地理解如何撤销更改、如何修复问题。在部署变更时，不要一次性部署给所有人。我们是否有渐进式交付？能否逐步推出？以小批量工作是一种强大的方法。不幸的是，机器人出现了，它们说：“我看到你的小批量工作。我要给你一个50,000行的PR。这是你的小批量任务。发布它吧。”即使机器人也会表现得更好，如果我们给它们更小、更明确的任务。这完全合情合理。

然后，我想进一步探讨两个方面：以用户为中心的焦点和高质量的内部平台。拥有以用户为中心的焦点意味着我们创建的每一份软件都是为人而设计的。即使这些软件的使用者是机器人，我们也是为人类而开发。最终目标是让这些软件改善某个人的生活。这就是我们存在的意义。AI或许能成为我们的一种推动力。作为软件工程师，我们的工作不是编写代码，而是解决问题。我们的工作是了解用户是谁，并构建他们需要的东西，构建能改善他们生活的工具。这正在从根本上改变我们的工作方式。我个人对此持乐观态度，我认为这帮助我们更接近用户，更好地理解并共情他们，从而为他们构建更好的解决方案。在我们的研究和数据中发现，当团队拥有以用户为中心的焦点时，团队表现会得到提升。

另一个我们发现的有趣现象是，当团队缺乏以用户为中心的焦点时，其表现实际上会下降。这非常有力。我认为在AI领域，我们现在可以做一件非常有趣的事情。是的，AI可以在你原本需要10行代码的时间内生成一个5万行的PR。它能以更快的速度完成任务。这对我们还有什么帮助？这真正解锁了选择的自由度。现在，我可以在更短的时间内原型设计出五件事情，而不是之前只能设计一件。你知道我们最不擅长的是什么吗？是准确理解用户真正想要的东西。让我们去构建六件事情吧。让我们去构建十件事情，尝试它们。让我们团队一起讨论它们。在投入实际生产之前，让我们邀请一些用户来讨论这些想法。

等等，为什么只选一个？我们一直在构建A/B测试框架。为什么不构建A-B-C-D-E-F-G？我们能在生产环境中同时运行多少种不同的方案，获取真实的用户反馈来帮助我们做出更好的决策？如果你具备让产品开发团队帮助你构建更高保真原型的能力，我们就能探索各种不同的选项，最终找到最佳选择。我们可以将这些最佳选择呈现给用户，收集他们的反馈，再将这些反馈重新投入循环中。我们正在与用户建立这种紧密的联系。这真的很棒。让我们实现它。

另一个可能并不令人意外但确实有帮助的因素是，高质量的内部平台能将AI的采用转化为组织的实际价值。当我想到高质量的平台时，首先想到的是显而易见的好处。平台帮助我们在一个组织内扩展某种能力或技术，因为我们集中了一些能力，使它们对所有人可用。另一个平台工程领域常见的说法是：将平台视为产品。你听过这句话吗？产品的一个特点是它们有客户。平台的客户是谁？在AI出现之前，平台的客户是谁？是其他软件工程师。是其他开发者。我对此有很深的共情，我理解他们的痛苦，知道他们正在经历什么。现在情况正在改变。我不仅在为其他开发者构建，也在为机器人构建。

我需要提升开发者体验，也需要提升代理体验。事实证明，我们为其中一方所做的某些事情对另一方也有好处。当我们拥有更好的文档时，这可以帮助我们的开发者，当然也能帮助我们的代理。我知道这一点，因为现在你们都在编写文档。每个人都在编写文档。DORA多年来对此进行了研究并指出：“我们看到文档就像阳光一样，它能够释放组织内部的诸多能力。”大家可能会说：“是的，但编写文档真的很痛苦。”你们有多少人写过代理文件或技能？现在你们正在编写文档。什么发生了变化？作为一名高级工程师，我不会再为了帮助初级工程师而编写文档。我将为了帮助机器人而编写文档。老实说，这有点混乱。为什么？因为当我为初级工程师编写文档时，他们可能需要一年甚至更长时间才能进步。

编写文档后，我是否写得好这一反馈周期非常漫长。当我为代理编写文档时，我能够立即获得反馈。我修改了代理并重新运行了提示，立刻就能看到结果。这非常有趣。他们做了一项研究，稍微调查了一下这些代理文件是否真的有助于生成更好的输出。他们的发现是，不，作用不大。我认为有趣的是，作为用户，由于代理文件，我对输出是否更有信心？我觉得我有了更多的控制感，这可能让我对结果更有信任。我们确实知道，无论在哪里，信任会带来采用，而采用又会带来信任。你使用某样东西越多，就越信任它；越信任它，就越会使用它。虽然这可能目前对机器人帮助不大，但也许对我有帮助。也许这就足够了。

关于AI还有另一件事需要考虑。我们讨论了内部平台。我们从开发者体验开始，现在必须考虑代理体验。我想回到最初的那个问题：是什么阻止你将AI刚刚生成的东西直接部署到生产环境？因为现在你组织中的每个人都是构建者。我们从开发者体验转向代理体验，再转向构建者体验。我如何帮助会计部门的Jane将她昨晚构思并用AI构建的应用程序部署出去？听起来是不是很可怕？也许这就是新的工作内容。也许这就是新的平台工程。我们如何让组织中更多构建者能够安全地存在？这很可怕。也许这就是我们必须做的事情。否则，事情的另一面会是什么？影子IT、影子AI。在我看来，这一直是一个标签，你可能不认同这一点。

我觉得影子IT是一个标签，我们这些技术人员用来贬低另一方的。那些业务人员，以及他们的影子IT。你认为他们为什么这么做？为了让你继续有工作。他们正在解决自己的业务问题。当存在影子IT时，我们应该感到不安。这向我们发出信号，存在一个真正的业务问题，问题如此严重，以至于他们愿意绕开与我们合作。我们需要去支持他们。我认为平台团队，以及这种平台的理念，也许你们更多的工程能力应该转向支持构建者，而不是继续推出下一个功能。这只是个值得思考的方向。

DORA AI 能力模型实践

我将向您展示 DORA AI 能力模型的实际应用。如果您访问 dora.dev，可以亲自体验，或者您也可以在这里观看。我将点击这个小 AI 人物。我想向您展示这个能力模型。我们将在这里探索一下。假设您是传统瓶颈的一部分。传统瓶颈面临的一个挑战是产品性能较低。您作为团队决定，我们想要提高产品性能。您可以来到这个模型，点击产品性能，它将向您展示哪些能力与 AI 采用共同推动产品性能。通过这个模型，您可以弄清楚，等等，产品性能？这到底是什么意思？我们是如何评估它的？您可以点击这个“如何评估”按钮。小批量工作、AI 可访问的内部数据、明确且沟通的立场。

这些意味着什么？您可以弄清楚如何评估它们，并了解更多关于它们的信息。不过，这个模型的工作方式是，您正在实施 AI 采用。您想要推动一个或多个结果。您想要改进这些方面。您如何做到这一点并确保 AI 采用正在发生？通过这些能力和条件，沿着这些箭头向后追溯。您的 AI 采用更有可能对另一侧的这些结果产生影响。

持续改进 vs 彻底变革

一个糟糕的系统每次都会打败一个优秀的人。这是 W. Edwards Deming 的话。我记得的引用之一。想想看。当涉及到采用 AI 并改变您的工作方式时，您可能会采取两种不同的方法。如果您是丰田生产系统（Toyota Production System）的粉丝，您可能知道“Kaizen”和“Kaikaku”这两个术语。改进，即我们审视当前系统并尝试使其变得更好一点。这是持续改进。这就是 Kaizen。然后是演变。演变类似于，也许我们扔掉一切。也许我们从头开始，设计完全不同的系统。这就是 Kaikaku。这就是彻底变革。当我回到这张幻灯片时，我问大家的问题，您会改变什么来使其更安全，以信任 AI 生成的代码并将其部署到生产环境？

你们中没有人提到代码审查。你们中有多少人觉得代码审查是新的瓶颈？我认为是时候了。我是一个坚定的 Kaizen 和持续改进的倡导者，而不是 Kaikaku，彻底变革。也许是时候让代码审查消失了。也许是时候让它们消失了。这会让你们感到多么不舒服？非常不舒服。我们为什么要进行代码审查？为了验证是否有缺失的测试。我们为什么要进行代码审查的另一个原因？为了学习。再给我一个进行代码审查的原因。两个大脑比一个更好。分享知识。你们中有多少人曾经带着一个大型语言模型（LLM）走到一个全新的代码库旁边，并迅速了解了这个代码库？我们可以更快地分享知识。你们中有多少人编写了测试来验证您为这个东西编写了测试，或者有其他方法来验证这一点，而无需让人查看这个东西来验证是否存在测试？

有多少人曾经坐下来进行结对编程？你们知道什么比异步代码审查更好吗？同步代码审查。一起编写代码。在编写过程中，我们有四双眼睛在关注代码。这样更好。也许是时候摒弃代码审查了。我们投入在代码审查上的每一分工程能力，都比投入在更好的防护措施和更深入理解我们试图构建的目标意图上更好。我知道，这听起来很激进。他们称之为“激进变革”并非没有原因。我认为现在是时候了。我们需要以整个行业的眼光来思考这个问题。我提到的那份2025报告并不是最新的报告。这是最新报告，DORA AI能力模型报告，dora.dev/dora-aicmr。这份报告发布于12月，深入探讨了这七大能力，对每项能力进行了更详细的说明。如何衡量它们？如何在组织内部实践中应用它们？所有这些问题，我强烈建议你下载这份报告并仔细阅读。

从洞察到行动

我想用一些最后的想法来结束今天的分享。第一个最后的想法可能是我今天要说的最重要的事情。不要相信我，也不要相信我们的研究。DORA进行研究的方式是深入世界进行调研，尽可能收集所有输入信息。你们中没有人服务于整个世界。有些人可能参与了某些项目，比如你可能在那个项目中。你并不在“世界”中工作，而是在你所在的组织中，与它的客户和上下文一起工作。即使在你自己的组织内部，你可能也并不为整个组织工作，而是为某个业务部门或某个应用工作。你们必须将我们发现的内容进行情境化处理。将我们的研究结果作为你们的假设来使用。DORA发现，当我们有清晰且明确传达的立场时，人工智能的采用会带来更好的结果。

让我们尝试实践一下这个想法。此外，你无法独自完成这一切。没有人能够独自改进。环顾四周，这些都是你的同行。我们都在一起学习。此外，如果你加入DORA社区，你将能够与全球成千上万的从业者、领导者和研究人员一起，将这些想法付诸实践，并探索它们在实际应用中的意义。

查看更多带文字稿的演讲

录制时间：

2026年10月21日

演讲者：

• Nathen Harvey

#### 相关赞助商

#### 相关赞助商

• 2026年11月19日，美国东部时间中午12点 扩展OpenTelemetry：管理收集器、配置和成本 演讲者：David Iparraguirre - Datadog高级产品市场经理，Jessica Yang - Datadog产品经理

#### 本内容属于“文化与方法”主题

##### 相关主题：

• 开发

• 文化与方法

• DevOps

• 持续交付

• 敏捷技术

• 代码质量

• QCon伦敦2026

• 质量

• 自动化部署

• 持续改进

• IT服务管理

• QCon软件开发会议

• 文字稿

• 管理

• 采用

• 软件工艺

• 人工智能

• 生产力

• 敏捷

• 性能

• InfoQ

• 云计算

• 相关编辑

• InfoQ热门文章 AWS推出Well-Architected Agent预览版 万物皆可逆向工程：AI代理进军二进制分析领域 Web应用的未来：AI代理能否实时生成用户界面？ Google采用Pyrefly实现更快速精准的Python类型检查 AWS推出Strands Decider 2B和Strands Box AI代理开发工具 Java新闻速递：JDK 28 JEP、Azul Payara、Gatherers4j、Google ADK、Yupiik、Apache Camel相关CVE漏洞