《2025朵拉》

在2025年，技术领导者面临的核心问题不再是是否应该采用AI，而是如何实现其价值。DORA的研究包含超过100小时的定性数据和来自全球近5000名技术专业人员的调查回复。研究揭示了一个关键事实：AI在软件开发中的主要作用是放大器。它放大了高绩效组织的优势和困难组织的功能障碍。

AI投资的最大回报不是来自工具本身，而是来自对基础组织系统的战略关注：内部平台的质量、工作流程的清晰度以及团队的协调性。没有这个基础，AI只会创造局部的生产力提升，往往在下游的混乱中丧失。

基于定性数据和2025年6月13日至7月21日期间进行的全球调查，本报告揭示了AI辅助软件开发现状的几个关键发现，包括：

AI采用已变得几乎普遍。大多数调查受访者（90%）在工作中使用AI，并相信（超过80%）它提高了他们的生产力。然而，有相当一部分（30%）目前对AI生成的代码报告几乎没有信任，表明需要关键验证技能。

成功的AI采用需要的不仅仅是工具。我们新的DORA AI能力模型(DORA AI Capabilities Model)识别了七个基础实践——包括明确的AI政策、健康的数据生态系统和以用户为中心的信任关注——这些被证明能够放大AI对组织绩效的积极影响。

AI采用现在改善了软件交付吞吐量，这是与去年的关键转变。然而，它仍然增加了交付不稳定性。这表明虽然团队正在适应速度，但其基础系统尚未发展到能够安全管理AI加速开发。

今年的研究识别了七种不同的团队档案，从”和谐的高成就者”到陷入”遗留瓶颈”的团队，为有针对性的改进提供了新的框架。

价值流管理(Value Stream Management, VSM)，即可视化、分析和改进从想法到客户的工作流程的实践，作为AI的力量倍增器，确保局部生产力收益转化为团队和产品绩效的可衡量改进。

90%的组织已经采用了平台工程(Platform Engineering)，使高质量的内部平台成为AI成功的基本基础。

我们新的DORA AI能力模型揭示，AI的价值不是通过工具本身解锁的，而是通过周围的技术和文化环境。我们已经识别

虽然大多数开发者使用AI来提高生产力，但对其输出质量存在健康的怀疑。这种”信任但验证”的方法是成熟采用的标志。

平台工程现在几乎普遍（90%的采用率）。我们的数据显示高质量内部平台与组织解锁AI价值的能力之间存在直接关联。将其平台视为的组织

包括明确的AI政策、采用转向有效使用。您的旨在改善开发者

健康的数据生态系统、质量培训项目应该专注于体验的系统显著

内部平台和以用户为中心教授团队如何批判性地指导、获得更大回报。

放大AI对性能的积极影响。 AI生成的工作，而不是优先考虑并资助您的平台

变革。最大的回报将来自 ## 七种团队表现特征碎片化工具可能会阻碍

数据生态系统，以及您团队我们识别出七种不同的 ## 系统观点指导AI的潜力

是将AI潜力转化为可衡量独特的性能、稳定性和今年的研究证实

组织绩效的基本前提。福祉组合。这个模型提供 VSM创造了专注的

执行摘要

使用本报告

DORA社区

为什么加入DORA社区？

及时了解研究动态： 第一时间了解DORA的新信息和出版物。

前言

Gene Kim 研究员，Vibe编码者，合著者 Vibe Coding, The Phoenix Project, DevOps Handbook, Accelerate

需要严格的计划和批准，通常涉及数百个风险高、容易出错的手动步骤。尽管经过规划和谨慎操作，部署仍然会造成巨大的混乱和中断，这就是为什么我们每年只敢进行一次部署的原因。

前言

现在，12年过去了，作为一个技术社区，我们再次面临着一项卓越的新技术——AI(人工智能)。正如十年前一样，我们在问：这项新技术是否真的能够实现更好的软件交付和组织绩效？

在2024年，DORA发布了一份具有里程碑意义的报告，测量了AI对软件交付性能的影响，这是此类研究中的首批系统性研究之一。结果令一些人感到震惊。数据表明，使用AI越多，软件交付的稳定性和吞吐量就越差——这正是软件开发专业人员在过去十年中一直努力改善的属性。

是的，我见过并体验过使用AI如何导致问题，从静默删除测试、明显损坏的功能，甚至删除生产数据等各种问题。但我也见过AI被用来大幅改善结果。我开始称去年的报告及其发现为”DORA 2024异常现象”——即一个令人兴奋的待解之谜。

这种信念是基于过去一年与Steve Yegge合作的经验而形成的，他因在Amazon和Google的20年工作经历而闻名。他记录了Amazon创始人Jeff Bezos的一份备忘录如何推动Amazon从软件单体架构转变为数千个微服务。这一转变帮助在2015年实现了每天136,000次部署，这一成就多年来一直激励着DORA研究。

Steve和我共同撰写了一本即将出版的书《Vibe Coding》，在书中我们将”vibe coding”定义为任何不用手工敲代码的编程形式。相反，代码是通过与AI的迭代对话产生的。

我们描述了vibe coding如何改变了我们的生活——它使我们能够更快地构建我们想要的东西，追求更雄心勃勃的项目，更自主地工作，获得更多乐趣，并探索更广阔的选择空间(FAAFO!)。

Steve和我见过vibe coding如何出错，导致测试被删除、服务中断，甚至代码仓库被删除。但我们得出结论，这是因为几十年来为我们提供良好服务的工程直觉现在被证明是严重不足的。

假设你曾经行走的最快速度是每小时4英里，有人要求你以每小时50英里的速度驾驶汽车。如果没有练习和训练，你无疑会撞车。

我们得出结论，当AI显著加速软件开发时，我们的控制系统——也就是我们自己——也必须加速。换句话说，十年的DORA研究很可能已经表明整个软件开发行业的实践必须演进。

• 我们需要快速反馈循环——比以往任何时候都更快——以匹配AI加速的代码生成。

• 我们需要在软件架构内工作，这些架构为我们提供行动的独立性——比以往任何时候都更需要，我们需要能够独立地开发、测试和部署软件。

• 我们需要学习的氛围，特别是考虑到AI的特殊性质及其快速发展的速度。

在《Vibe Coding》中，Steve和我包含了以下案例研究，暗示了相关的原则和实践——以及为什么它们在AI时代如此重要。

快速反馈循环和软件架构

Fernando Cornago，Adidas全球数字和电子商务技术副总裁，管理着近千名开发人员。在他们的生成式AI(gen AI)试点项目中，他们发现在松散耦合架构中工作并具有快速反馈循环的团队”体验到20%到30%的生产力提升，以提交、拉取请求和整体功能交付速度的增加来衡量”，并且”快乐时间”增加了50%——更多的实际编码时间，更少的管理负担。

相比之下，由于与企业资源规划(ERP)系统紧密耦合而导致反馈循环较慢的团队，几乎没有从AI中获得任何好处。

学习文化

我们也很欣赏来自Bruno Passos的案例研究，他是Booking.com开发者体验的产品经理，该公司拥有超过3,000名开发人员的团队。在他们的gen AI创新努力中，他们发现”开发人员对vibe coding和编码助手工具的采用是不均匀的…Bruno的团队很快意识到缺失的成分是培训。当开发人员学会如何给他们的编码助手更明确的指示和更有效的上下文时，他们发现合并请求增加了30%，工作满意度也更高。”

这两个案例研究都指向了一个令人兴奋的可能性：AI放大了我们工程实践的优势和劣势。拥有优秀工程实践的个人、团队和团队的团队有望从AI中获得出色的好处。

我们相信那些没有这种实践的人很可能会遇到困难和复杂的问题。

我很感激并且很荣幸能够与Google的DORA团队合作，以及我们的扩展专家和研究人员团队，我钦佩他们的工作和成就，帮助为今年的研究提供信息。

最让我兴奋的是2025年研究的规模：有近5,000名参与者，我们将能够进行实践调查，希望能产生像十年前那样的”尤里卡!“时刻。我相信我们将在未来几个月看到类似的突破。

一些发现已经进入了报告，但还有许多更诱人的见解正在涌现，我很兴奋在未来几个月和几年中分享这些发现。

我要感谢整个DORA团队和扩展贡献者，是他们使这项开创性的研究成为可能。

[1. ] [[控制理论中的奈奎斯特稳定性准则告诉我们，任何控制系统的运行速度必须至少是其所控制系统的两倍。]]

[2. ] [Kim, Gene, and Steve Yegge.][ Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond][. Foreword by Dario Amodei ]

软件交付性能

新软件发布的时刻值得庆祝，因为只有当世界能够使用它时，才能确定其主要价值。这些用户可能是客户、合作伙伴、同事、陌生人，甚至是其他技术系统。

这也是我们开始了解软件在生产环境中如何表现，以及它如何满足用户需求的时刻。当然，有很多原因可能让你想要或需要更改应用程序，包括修复安全漏洞、提高性能、降低运营成本或减少碳足迹。这些考虑因素，加上更快行动和取得更大成功的业务需求，使得DORA将软件交付性能作为我们研究的焦点。

在这个时刻之前，我们可以做很多事情来增加对软件会按我们预期运行的信心，但发布的那一刻是理论变为实践的时刻——或者并非如此。

启动新软件不仅仅是启动新的应用程序和服务。一旦应用程序发布，用户的反馈将鼓励（或迫使）你进行改进。

我们还需要考虑负责构建、部署、运营和持续支持应用程序的团队的长期健康和福祉。我们需要具备正确的能力和条件，让这些团队能够以可持续的方式推动成功的结果。从本质上讲，这些考虑因素可以帮助用户和应用程序的长期成功。

软件交付性能因素

DORA的软件交付性能因素从整个交付过程的高层视角出发，专注于两个关键因素：吞吐量和不稳定性。

吞吐量

吞吐量是衡量在一段时间内有多少变更能够通过系统的指标。更高的吞吐量意味着系统可以将更多变更推送到生产环境中。

不稳定性

不稳定性是衡量软件部署进展情况的指标。当部署进展顺利时，团队可以自信地将更多变更推送到生产环境，用户在部署后立即遇到应用程序问题的可能性较小。

需要在部署后立即干预的部署比率。可能导致变更回滚或快速修复以迅速解决任何问题。

这两个软件交付性能因素结合起来，为团队提供了对其软件交付性能的高层理解。随时间测量这些因素可以深入了解软件交付性能的变化情况。这些因素可用于衡量任何应用程序或服务，无论其技术栈、部署过程的复杂性或最终用户如何。

超越软件交付性能

虽然这五个指标提供了性能的重要快照，但它们最终只是结果。它们告诉你正在发生什么，但不能解释为什么。低部署频率可能是由技术债务、官僚流程或团队倦怠造成的——仅凭指标无法区分它们。

为了将性能数据与驱动它的人力体验联系起来，我们进行了聚类分析。这种方法超越了孤立的数字，揭示了七种常见的团队画像，每种都讲述了关于性能、福祉和环境之间相互作用的更深层故事。

寻找共性

我们进行了聚类分析，以了解软件交付性能背后的人力和系统因素，并识别常见模式。我们的统计聚类方法在考虑以下因素的同时揭示了七种团队类型：

组织、团队和产品性能，软件交付吞吐量，个人效能，以及有价值的工作提升团队性能，个人通常努力

个人直接团队的感知效能和自我评估的协作实力。这个因素衡量个人在工作中的效能感和成就感。这个因素捕获了个人的

这个因素衡量个人花费时间做他们认为有价值和有意义工作的数量。

我们的分析揭示了七种不同的团队原型，范围从那些在健康、可持续环境中表现出色的团队（和谐的高成就者）到那些受技术债务困扰的团队（传统瓶颈）或低效流程（受流程约束）。

产品或服务的成功和质量，基于帮助用户完成重要任务和保持信息安全等特征，以及延迟等性能指标。

这衡量摩擦阻碍个人工作的程度。较低的摩擦量通常被认为是积极的结果。

这衡量与工作相关的疲惫和愤世嫉俗感受。较低的倦怠量通常被认为是积极的结果。

团队性能倦怠产品性能摩擦软件交付吞吐量有价值的工作软件交付不稳定性个人效能

每个集群的名称和描述是对数据的解释。您的团队可能看到与给定集群类似的性能水平，但可能不觉得集群名称或描述很好地描述了您的团队。图2：七种团队原型的性能水平

集群1：基础挑战

这些团队陷入生存模式，面临重大挑战，在流程、环境和结果方面存在根本性差距。

集群1：基础挑战团队性能倦怠产品性能摩擦软件交付吞吐量有价值的工作软件交付不稳定性个人效能

性能指标： 与团队产出、产品交付和价值创造相关的关键性能指标持续偏低。

集群4：高影响，低节奏团队性能倦怠产品性能摩擦软件交付吞吐量

集群2：传统瓶颈

这个集群中的团队处于持续反应状态，不稳定的系统决定着他们的工作并破坏他们的士气。

团队福祉： 数据表明工作环境要求很高。团队成员报告摩擦和倦怠水平升高。

性能指标： 产品性能的关键指标较低。虽然软件交付吞吐量

团队表现聚类分析

系统稳定性： 尽管团队定期交付更新，但价值因持续的质量问题而减少。软件及其运营环境的稳定性面临重大挑战，导致大量计划外的响应式工作。

聚类4：高影响力，低频次

聚类5：稳定且有条不紊

聚类3：受流程约束

这些团队就像在跑步机上运转。尽管在稳定的系统上工作，但他们的努力被低效的流程所消耗，导致高倦怠感和低影响力。

团队福祉： 数据显示倦怠感和摩擦力都很高。这表明当前的工作流程和流程正在创造一个充满挑战且不可持续的工作环境。

表现指标： 关键表现指标显示低有效性和有限的客户或业务价值创造。

系统稳定性： 团队的软件和运营环境稳定可靠。这表明技术不稳定性不是表现和福祉挑战的主要因素。

聚类4：高影响力，低频次

这些团队产生高影响力的工作，体现在强劲的产品表现和高个人有效性上。然而，这与低频次交付模式相结合，其特征是低软件交付吞吐量和高不稳定性。

团队福祉： 数据表明低摩擦环境，说明团队流程高效且协作性强。

表现指标： 团队始终达到顶级生产力水平。有效性和产品表现指标都很强。

系统稳定性： 运营环境的特征是高度不稳定。这种波动性对服务可靠性和长期可持续性构成重大风险。

聚类7：和谐的高成就者

v. 2025.1 摩擦软件交付

集群5：稳定而有条不紊

这些团队是软件世界中稳定的工匠，以深思熟虑和可持续的节奏交付高质量、有价值的工作。

集群4：高影响力，低节奏

集群5：稳定而有条不紊

团队福利： 数据显示倦怠和摩擦水平较低，这表明团队环境健康且可持续。

绩效指标： 产品质量和价值创造的关键绩效指标始终为正。然而，团队的软件交付吞吐量处于较低百分位，表明工作节奏更加深思熟虑。

系统稳定性： 团队的软件和运营环境以高稳定性和可靠性为特征。

集群1：基础挑战

集群2：受流程约束

集群3：有价值的软件交付

集群6：务实的表演者

这些团队以令人印象深刻的速度和稳定性持续交付工作，即使他们的工作环境尚未达到峰值参与状态。

团队福利： 这个集群与绝对顶级团队不同的地方在于团队福利指标。数据显示倦怠和摩擦水平一般。这表明工作环境功能正常且可持续，但可能缺乏强有力的参与驱动因素。

绩效指标： 软件交付的关键绩效指标强劲，吞吐量高于平均水平，不稳定性低。团队保持稳定的有价值产出节奏，可靠地满足期望。

系统稳定性： 团队的软件和运营环境稳定可靠，为他们的高绩效提供了所需的坚实基础。

集群7：和谐的高成就者

这就是卓越的样子——一个良性循环，稳定、低摩擦的环境使团队能够可持续地交付高质量工作而不会倦怠。

集群7：和谐的高成就者

软件交付吞吐量有价值的工作软件交付不稳定性团队绩效个人效能倦怠产品绩效

受访者百分比： 团队幸福感： 工作环境的特点是燃尽感和摩擦程度较低。

20%的调查受访者属于集群7。 绩效指标： 团队在多个领域显示出积极的指标，包括团队幸福感、产品成果和软件交付。

系统稳定性： 团队在稳定的技术基础上运作，该基础支持其工作的速度和质量。 不稳定性 个人效能

图10为DORA研究的一个核心原则提供了有力证据，即”速度与稳定性”权衡是一个神话。最佳表现者（集群6和7）在两个维度上同时表现出色。相反，在频谱的另一端明显存在困难。一些群体，如面临基础挑战的群体（集群1），在吞吐量和稳定性方面都有困难，而其他高影响力、低频次的团队（集群4）表明没有稳定性的速度是危险和不可持续的主张。

卓越是可以实现的。集群6和7代表了总样本的近40%。它们的存在为可能的情况提供了经验锚点——组织可以努力达到的基准。虽然达到这种状态显然很困难，但这些群体有力地证明了高速度、高质量的软件交付不是理论理想，而是可观察的现实。

软件交付绩效

你的表现如何？

你可能想知道你的团队与今年研究中其他参与者相比表现如何。重要的是要记住，这些测量是在应用程序或服务级别进行的。这样做鼓励跨职能的所有权和改进责任。

此外，软件交付绩效最好、最有洞察力的比较是针对同一应用程序或服务随时间的变化。目标是持续学习和改进，而不一定是达到顶级软件交付绩效。

图11到15提供了我们在2025年DORA调查中收到的回复分布的洞察。

变更前置时间分布

调查问题：你的变更前置时间是多少（即从代码提交到代码在生产环境中成功运行需要多长时间）？

部署频率分布

变更前置时间级别	百分比	排名前百分比
超过六个月	2%	100%
一个月到六个月之间	13.2%	98%
一周到一个月之间	28.3%	84.7%
一天到一周之间	31.9%	56.4%
少于一天	15%	24.4%
少于一小时	9.4%	9.4%

调查问题：你的组织多久向生产环境部署代码或向最终用户发布一次？

失败部署恢复时间分布

部署频率级别	百分比	排名前百分比
少于每六个月一次	3.6%	100%
每月一次到每六个月一次之间	20.3%	96.4%
每周一次到每月一次之间	31.5%	76.1%
每天一次到每周一次之间	21.9%	44.6%
每小时一次到每天一次之间	6.5%	22.7%
按需（每天多次部署）	16.2%	16.2%

调查问题：当生产环境的变更或向用户发布导致服务降级（例如，导致服务损害或服务中断），随后需要修复（例如，需要热修复、回滚、前向修复或补丁）时，通常需要多长时间恢复服务？

变更失败率分布

失败部署恢复时间级别	百分比	排名前百分比
超过六个月	1%	100%
一个月到六个月之间	4.9%	98.8%
一周到一个月之间	9.4%	93.9%
一天到一周之间	28%	84.5%
少于一天	35.3%	56.5%
少于一小时	21.3%	21.3%

调查问题：大约有多少百分比的生产环境变更或向用户发布会导致服务降级（例如，导致服务损害或服务中断），随后需要修复（例如，需要热修复、回滚、前向修复或补丁）？

返工率分布

软件交付性能

将软件交付性能付诸实践

软件交付性能指标提供了整个交付过程的高层视图。这些指标随时间的变化可以洞察事情是在改善还是在恶化。改变这些指标所需的干预措施对于每个应用程序可能会有所不同；尽管可能会出现一些常见模式，例如冗长的审查和批准周期。

让我们通过一个假设的例子来说明。在一次定期回顾(retrospective)中，团队讨论了他们的软件交付性能。他们注意到他们负责的应用程序的变更前置时间开始增加。

他们可能通过查看仪表板注意到了这一点，但同样可能是通过简单的观察注意到的。这些指标的精确性并不总是必需的，团队通常会知道它们随时间的变化情况。

团队希望扭转这一趋势，但为此需要了解可能的原因。这就是额外数据可能有用的地方。团队可能会查看来自他们开发系统的数据——比如他们的代码库或分析工具——并发现代码审查似乎花费更长时间。

团队同意这是他们想要改进的领域，并讨论潜在的干预措施，包括将代码审查重新优先考虑为日常工作的一部分，并努力进行可能更容易审查的较小变更。确定了这些具体步骤后，他们同意在一个月后审查变更批准时间和所有软件交付指标，以了解他们的进展情况。

无论您的团队被识别为”受流程约束”还是”稳定且有条理”，目标都是相同的：培养持续改进的心态，使您朝着更加和谐和高成就的状态发展。

AI采用和使用

随着我们继续探索软件开发行业的AI采用趋势，AI在软件开发中的使用已经显著扩展。在这个快速发展的领域，我们努力制定基于证据的指导，帮助软件开发社区应对这些变化。今年的”AI辅助软件开发状态”代表了我们迄今为止对AI辅助开发最深入的分析。

主要发现

总的来说，我们关于软件开发人员采用和使用AI的发现表明，AI在各种不同任务中得到了广泛采用和深度依赖。这为个人生产力和代码质量都带来了感知到的好处。

采用情况

今年90%的调查受访者报告在工作中使用AI，比去年报告中的同一指标增长了14.1%。这种在工作中使用AI的极高普及率表明，AI在软件开发中的使用现在已经成为标准。

经验

变更失败率级别	百分比	排名前百分比
0%-2%	8.5%	8.5%
2%-4%	8.1%	16.7%
4%-8%	19.6%	36.2%
8%-16%	26%	62.2%
16%-32%	19.5%	81.6%
32%-64%	12.5%	94.1%
>64%	5.9%	100%

每月AI用户采用情况每月开始使用的新用户数量，以及关键行业事件

“嗯，我认为在过去一年左右的时间里，人们已经意识到生成式AI(generative AI)在很多事情上确实有效。现在这已经是既定事实，每个人都有可以在某种程度上从生成式AI中受益的应用程序。所以我认为有很多动机来启用新功能，在某些事情上节省成本，减少创建某些东西所需的时间。所以我认为没有人想要落后…我确实认为随着时间的推移，它将越来越多地集成到所有事物中，如果你没有以某种方式使用生成式AI，那么，是的，我认为将很难跟上。”

我们的受访者报告了使用AI工具的各种经验，中位数为16个月，平均值为16.22个月的经验。作为参考，ChatGPT于2022年11月发布，大约在我们调查启动前31个月。

数据，我们在这个时间线中既捕获了早期采用者[Jul]，也捕获了后期采用者[Nov] [Mar] [Jul] [Nov] [Mar] [Jul] [Nov] [Mar] [Jul] [2022] [2022] [2023] [2023] [2023] [2024] [2024] [2024] 2025 2025，并观察到在2023年末至2024年中期之间出现了明显的采用激增。

时间

在最近工作日使用AI的时间

我们样本中的AI用户在最近工作日与AI交互的时间也有所不同。调查受访者报告在最近工作日与AI交互的时间中位数为两小时，约占八小时工作日的四分之一。

反射性使用

反射性AI使用

尽管在我们的样本中AI使用几乎无处不在，但反射性使用——在面临问题时默认使用AI——并非如此。在AI用户中，只有7%的人报告在面临需要解决的问题或需要完成的任务时”总是”使用AI，而39%的人只是”有时”寻求AI帮助。

尽管如此，我们调查中60%的AI用户在遇到需要解决的问题或需要完成的任务时，“大约一半时间”或更多时间都会使用AI，这表明AI已经成为开发过程中的常见组成部分。

总是：7% 大部分时间：27% 大约一半时间：26% 有时：39% 从不：1%

依赖性

工作中对AI的一般依赖性

除了频繁使用，我们还发现开发专业人员在工作中严重依赖AI工具。在我们样本中，只有5%的AI用户报告在工作中”完全不”依赖AI，而65%的人报告”适度”依赖AI（37%）、“大量”依赖（20%）或”极大”依赖（8%）。

任务

正如我们2024年DORA报告中所述，今年调查受访者中AI工具的首要用途是编写新代码，71%的编写代码的受访者使用AI来协助他们完成这项工作。

工作涉及这些职责的大多数受访者也将AI用于文献综述（68%）、修改现有代码（66%）、校对（66%）以及创建或编辑图像（66%）。

在工作涉及这些职责的受访者中，AI的较少见用途包括分析需求（49%）、内部沟通（48%）和日历管理（25%）。

按任务的AI依赖性

编写新代码：71%（60%）创建/编辑图像：66%（16%）一般校对：66%（33%）文献综述：68%（18%）修改现有代码：66%（55%）编写文档：64%（59%）创建测试用例：62%（36%）解释概念：62%（55%）头脑风暴：62%（57%）外部沟通：61%（17%）分析数据：61%（44%）调试：59%（49%）创建/编辑报告：59%（32%）理解技术文档：59%（55%）清理/组织数据：57%（31%）创建规范：56%（31%）代码审查：56%（53%）维护遗留代码：55%（35%）创建/编辑视频：55%（7%）规划和战略制定：54%（54%）记笔记：51%（38%）安全分析：51%（23%）性能分析：50%（33%）分析需求：49%（48%）内部沟通：48%（58%）日历管理：25%（25%）

[误差条显示89%可信区间] [括号内是执行该任务的所有受访者的百分比。排除”其他”类别]

AI采用和使用：定制化如何支持开发者参与

研究内容

随着AI助手在开发工作中变得越来越普遍，加州大学伯克利分校的一个研究生团队研究了学生开发者在实际中如何使用AI驱动的集成开发环境(IDE)。该团队使用眼动追踪数据和访谈，观察具有一到五年经验的Python开发者如何处理两个简短任务：一个涉及不熟悉的库，另一个需要解释复杂的函数。

通过应用这项研究的见解，所有经验水平的开发者都可能找到与AI编码助手合作的方式，更好地满足他们的需求。

AI何时成为障碍

虽然AI编码助手旨在节省时间和减少工作量，但加州大学伯克利分校进行的一项研究发现，它们在某些任务中也可能带来阻力。例如，学生开发者在处理机械性任务(如编写样板代码和安装包)时接受AI，但当需要更深入理解时(如解释复杂代码)，这些学生开发者很大程度上忽略了AI建议。

眼动追踪显示，在解释性任务中，对AI聊天的视觉注意力不到1%，而在更机械性的任务中接近19%。这项研究中的学生经常选择手动完成任务以保持控制和理解，甚至忽略准确、节省时间的建议。

定制化作为解决方案

为了减少阻力并更好地支持专注工作，开发者和团队可以定制他们的AI工具。大多数IDE现在提供切换内联建议、启用”仅按需”模式或调整建议样式和结构等功能。

存储库级配置文件和链接代码文档可以帮助AI助手遵循既定协议。尝试这些设置可以使AI行为与不同任务的认知需求保持一致，有助于减少干扰并提高AI助手的有用性。

团队要点

为了充分利用AI编码助手，开发者和团队应该投资于定制化。这项研究表明，AI可能通过增加认知负荷来干扰解释性任务，特别是当开发者试图理解不熟悉的代码时。

关键是使AI支持与任务性质和开发者偏好保持一致。调整设置可以将AI从阻力源转变为更高效、更令人满意的开发体验。

界面：人们与AI交互的地方

人们与AI交互的地方

对话式AI聊天机器人是与AI交互的最常见方式，其次是嵌入IDE中的AI。

受访者报告与AI作为自动化工具链和其他开发工具平台一部分的交互频率较低，但这可能是这些AI工具对用户较不可见的特征。

AI使用模式

除了询问受访者在哪里与AI交互以及出于什么目的外，我们还询问了他们与以下每种”模式”的AI交互频率： 1) 聊天，代表任何类型的轮流文本交互； 2) 预测文本，如tab自动完成代码建议； 3) 协作，使用AI对代码库进行更广泛的更改； 4) 代理(agent)，其中AI被允许相对无监督地操作并在没有直接监督的情况下进行更改。

与聊天机器人和IDE内交互在我们的受访者中最频繁相对应，文本聊天和预测文本模式是受访者与AI交互的最常见模式。AI代理的使用最不常见，大多数(61%)受访者报告”从不”以代理模式与AI工具交互。这种使用模式可能反映了这些AI模式的相对成熟度；代理AI的较低采用率与其相对于更成熟的聊天和预测文本功能的较新出现一致。

AI交互模式频率

个人生产力

对个人生产力的感知影响

受访者对AI如何影响其生产力的评估

今年超过80%的调查受访者表示他们认为AI提高了他们的生产力。虽然超过40%的受访者报告说他们的生产力只是”略有”提高，但不到10%的受访者认为AI对他们的生产力产生了任何负面影响。

[极大提高] [13%] [适度提高] [31%] [略有提高] [41%] [无影响] [9%] [略有降低] [3%] [适度降低] [1%] [极大降低] [1%]

代码质量

对代码质量的感知影响

除了感知到对生产力的积极影响外，大多数(59%)调查受访者还观察到AI对他们的代码质量产生了积极影响。31%的人认为这种提高只是”轻微的”，另外30%的人既没有观察到积极影响也没有观察到消极影响。然而，只有10%的受访者认为使用AI对他们的代码质量产生了任何负面影响。

[极大改善] [7%] [适度改善] [21%] [略有改善] [31%] [无影响] [30%] [略有恶化] [7%] [适度恶化] [2%] [极大恶化] [1%]

“我觉得AI有时会写出比我更好的代码，主要是因为我觉得它经过了很好的训练。我之前提到过：代码是非常二元的。它要么有效，要么无效。AI编写的代码通常足以满足我的目的。而且它经常使用我可能意外忘记的代码标准，或者我懒得回去重构。所以我觉得它以更加连贯的方式创建东西。”

AI采用和使用

信任

AI在软件开发中的可信度仍然是一个重要的辩论和研究话题，我们之前已经确定了帮助培养开发者对AI信任的五种策略。然而，我们的数据表明开发者可能已经在他们的工作中考虑到了AI的这种局限性。

与2024年DORA报告类似，今年的发现揭示了用户对AI生成输出信任的细致情况，明显多数的受访者(70%)对其质量表达了某种程度的信心。这包括近四分之一的受访者(24%)报告对AI生成输出的质量有”很大程度”或”很多”信任。而30%的受访者表示更保守的立场，对AI生成输出的质量只有”一点”(23%)或”完全没有”(7%)信任。

这一数据突出了一个关键洞察：高水平的AI采用和感知收益可以与对信任的谨慎和细致方法共存。我们的发现表明，绝对信任并不是AI生成输出有用的先决条件。这种模式与既定行为一致；在我们的访谈中，开发者将此与他们对其他广泛使用资源(如在Stack Overflow上找到的解决方案)应用的健康怀疑态度进行比较，这些信息被使用，但并不总是被隐含地信任。

AI生成输出质量的信任

[很大程度] [4%] [很多] [20%] [一定程度] [46%] [一点] [23%] [完全没有] [7%]

最终思考

综合来看，这些发现表明AI在软件开发中的使用已经变得几乎无处不在。AI被用于广泛的开发任务，作为受访者工作流程的一部分被依赖，并在面临问题时经常被求助。

虽然受访者继续对AI生成代码的可信度表示担忧，但他们广泛认识到AI对其个人生产力的积极影响并观察到代码质量的显著提升。因此，尽管存在一些担忧，他们仍然继续使用AI。

去年，我们发现竞争压力是软件开发中AI采用的关键驱动因素。许多受访者将此表达为对”错失机会”或被同行开发者和竞争对手公司”落后”的恐惧。

但是，社会压力是否是采用新技术的合理动机是有争议的。虽然我们的数据显示AI采用的许多积极结果，但我们也记录了显著的缺点。

我们理解关于AI应在多大程度上集成到软件开发中的决策是困难的，最好基于数据做出。因此，在我们关于DORA新AI能力模型的章节中，我们探讨了组织中的文化和技术能力如何影响这些决策。

无论保守还是宽松的方法是否正确将取决于具体情况。但是，AI的广泛采用表明组织不能再忽视其使用的影响。

AI 采用和使用

探索 AI 与关键成果的关系

AI 已成为软件开发的新常态

在短短三年内，AI 采用和使用发生了显著变化。开发者使用 AI 在 2022 年可能还令人惊讶，但今天 90% 的技术专业人员在工作中使用 AI。AI 采用和使用章节显示了近乎普遍的采用，这一趋势远超我们的数据范围。

2025 年 Stack Overflow 开发者调查发现，84% 的开发者现在正在使用或计划在其开发过程中使用 AI 工具，比前一年的 76% 有显著增长。

日常使用也很常见，47% 的受访者每天都在使用 AI 工具。支持这一趋势的是，Atlassian 的 2025 年 DevEx 状态调查报告显示，几乎所有开发者（99%）现在都通过使用 AI 工具节省时间。

个人的热潮在企业战略中也有所体现。据 LinkedIn 企业传播 2025 年报告，88% 的商业领袖表示加速 AI 采用是一个优先事项。麦肯锡调查发现 78% 的受访者报告他们的组织在至少一个业务职能中定期使用 AI。

这一优先级也体现在支出上：斯坦福 2025 年 HAI AI 指数报告显示，2024 年全球企业对 AI 的总投资达到 2523 亿美元，比前一年增长 26%。也许没有什么比公司招聘的技能更能说明这一新现实：仅 2023 年，美国提及生成式 AI 技能的职位发布就增长了 323%。

AI 采用的影响是什么？

鉴于这种采用热潮，组织了解是否有相应的收益热潮非常重要。广泛采用并不自动等于广泛价值。我们需要承认采用可能是混乱的，更多地由炒作和错失恐惧症（FOMO）驱动，而不是明智的策略。

采用也可能受到组织系统的限制和约束，正如我们在 2024 年 DORA 报告中得出的结论，该报告发现 AI 返回了许多有前景的结果，但也增加了软件交付不稳定性并降低了软件交付吞吐量。同样的 2024 年 DORA 研究发现，AI 采用每增加 25%，软件交付吞吐量估计减少 1.5%，软件交付不稳定性估计增加 7.2%。

我们的研究并不孤单地突出这些复杂性。例如，来自模型评估与威胁研究（METR）的最近研究表明了感知与现实之间的stark误match：被 AI 工具拖慢 19% 的开发者仍然认为这些工具使他们提高了 20% 的效率。类似地，其他第三方研究已经开始表明 AI 对认知和福祉的潜在影响，进一步强调作为一个行业，我们仍处于理解 AI 采用真正影响的早期阶段。

然而，当开发者被要求在 SPACE 框架的每个领域评估 AI 时，他们报告了大多数积极影响和少数负面影响。我们 AI 采用和使用章节中的大多数受访者也表示 AI 对他们的代码和生产力产生了积极影响。

这些混合信号向我们表明，应该进行更多基于证据的工作来评估 AI 对产品开发的真正影响，特别是考虑到 AI 投资和采用的巨大规模。我们认为开发者社区和雇主应该设定现实的期望，获得对 AI 实际影响的清晰视角是负责任地管理这些期望的第一步。

测量 AI 采用

为了理解关键成果如何因 AI 采用而不同，我们需要能够测量 AI 采用。

包容性： 我们的测量不应偏向任何单一角色（或者确实，系统性地

依赖性： 在过去三个月中，您在工作中对 AI 的依赖程度如何？

信任度： 在过去三个月中，您对工作中 AI 生成输出质量的信任程度如何？

反射性使用： 在过去三个月中，当您在工作中遇到需要解决的问题或需要完成的任务时，您使用 AI 的频率如何？

由于这些不完善之处，似乎 AI 使用已迅速成为大多数从事软件开发的组织的标准做法。

因此，我们告诫不要将这些关于 AI 普遍性的发现解释为所有组织都应该迅速采用 AI，无论其具体需求如何。相反，我们将这些发现解释为一个强烈信号，即每个从事软件开发的人——无论是个人贡献者、团队经理还是执行领导者——都应该深入思考 AI 是否可以和应该在他们的工作中应用，以及在哪里和如何应用。

为了这个原因，我们提醒不要将 AI 采用努力的结果解释为所有组织都应该将 AI 整合到其流程中可以成功做到这一点的方式，而是为选择这样做的组织提供洞察。

[1.] [Introducing ChatGPT | OpenAI. https://openai.com/index/chatgpt] [2.] [Accelerate State of DevOps 2024. https://dora.dev/dora-report-2024] [3.] [Fostering developers’ trust in generative artificial intelligence. https://dora.dev/research/ai/trust-in-ai]

[除了 AI [因子]] [依赖] [信任] 采用之外的任何其他分数)。例如，软件

开发人员不应该仅仅因为他们使用 [AI 采用] AI 进行编码就自动获得更高的分数。这个度量需要

数据驱动： 正如我们每三年调查项目的回答方式信任是使用的前提，但使用是

所做的那样，我们让数据先行— 高度相似。建立信任的机制。这创造了

这个过程的一部分包括这提供了证据表明存在足够信任一个系统去使用它时，

进行探索性一个单一的潜在构造他们增加的使用建立了进一步的

因子分析，[14] 这较少导致这三个变量一起移动。依赖和更深的信任，创造了

对 AI 采用的概念化和三个概念上相互关联的确实，这种循环性质使得

测量应该与普遍接受的维度：行为维度（使用）、结合这些变量成为因子的

AI 使用理解和我们的依赖维度（AI 如何深度完美候选，特别是考虑到

定性工作相联系。融入个人的工作流程），我们的调查是快照，而不是

我们可以确定在比较不同这是组织整体成功的这捕获了个人对

基本形式是：[21] 市场份额和客户满意度主要应用程序或服务的基础。

AI 采用水平更高的人这个因子测量个人自我评估效能和在工作中的

但探索这些平均效应 [这测量基于帮助用户] [做他们感到有价值和有意义]

可以发现一般模式。 [完成重要任务、保持信息] [的工作的自我评估数量。]

报告的人的目标的结果。速度和效率。详见这测量与个人工作相关的

简而言之，我们想要以 [了解你的软件交付绩效] 疲惫和愤世嫉俗的感觉。

我们认为对技术专业人员章节获取更多详细信息。较低的倦怠量通常被认为

[AI 采用对关键结果的估计效应，89% 可信区间] [AI 采用对关键结果的估计效应，89% 可信区间]

[对于橙色结果，如倦怠，负效应是理想的。] [对于橙色结果（例如倦怠），负效应是理想的。] [图28：AI 影响的景观]

我们估计在两个共享相同特征的人之间 • 更高水平的产品绩效为了构建这些假设，

环境和流程，我们的定性工作，我们的主题专家，以及我们从 DORA 社区学到的内容。更多详情请参见方法论章节。

• 更高水平的个人有效性 • 更高水平的团队绩效 • 相似水平的倦怠感 • 更高水平的软件交付不稳定性 • 相似水平的摩擦 • 更高水平的组织绩效 • 更高百分比的时间用于做有价值的工作 • 更高水平的代码质量

探索 AI 与关键结果的关系

自去年的报告以来，几项结果继续与 AI 采用保持积极关联。让我们列出它们：

• 更高水平的个人有效性 • 更高水平的代码质量
• 更高水平的团队绩效 • 更高水平的组织绩效

这些稳定的积极关系正在成为一个熟悉的故事。我们将它们视为基线而非头条新闻，因为它们与去年的发现一致，并与许多从业者的体验相符。可能有无数潜在机制，其中许多可能特定于您的组织、团队、环境和情况。

AI 可以通过处理样板代码和其他常规脚手架来帮助个人，快速提供合理选项，提供高度针对问题的输出，总结和综合大量不同信息，并完成设计、规划和分析等高阶任务。这些个人提升可能会累积和复合——跨人员和周期的小胜利相乘——从而使团队和组织受益。

• 与摩擦无关系 • 与倦怠感无关系 • AI 与软件交付不稳定性增加相关

我们认为这些结果的顽固性更多地与个人所嵌套的系统、流程和文化有关。目前，AI 往往出现在键盘前，这可以解释为什么代码质量和生产力受益，但周围的系统和文化可能不会。

我们认为这些结果主要是社会技术系统（结合流程和文化）的属性和后果。尽管有所有的好处，摩擦仍然未受影响，倦怠感保持平稳，交付不稳定性上升——除非周围的系统和文化发生变化。

虽然一个旨在自动化重复任务的工具似乎是通向更顺畅工作流程的明确路径，但我们的数据表明，工作场所摩擦是一个比仅仅完成例行任务更大更复杂的问题。正如我们所指出的，一些研究将摩擦指向超出个人范围的流程产物。

• 基础设施问题，如”不稳定和缓慢的系统和工具” • 过时的文档 • 管理工作负担 • 时间压力 • 重复性任务

例如，在没有相应的一套演进的护栏、角色和”黄金路径”的情况下增加变更量可能会增加验证和协调成本。他们的一个结论是管理者应该”优先考虑并针对改进流程和工具的行动”。

然而，我们不认为摩擦的故事纯粹是系统性的。对于个人来说，摩擦并不会消失而是转移：它从手动工作转移到决策和验证，可能以提示迭代、结果审查和评估看起来非常类似于正确代码的代码形式出现。这可能会导致总摩擦大致没有变化，尽管能够产生更有影响力的输出并自动化某些例行任务。

“我们了解到 AI 在增强有才华的工程师技能时最有效。通过自动化繁琐、重复的任务，AI 释放了我们的开发人员专注于战略问题解决和创新。”

虽然很容易假设提高生产力的工具会缓解倦怠感，但我们的发现表明倦怠感对技术解决方案顽固地抵抗。倦怠感可能很大程度上受到一个人所处工作文化的影响。

我们在多年的数据中注意到了这一点。倦怠感与领导力、优先级稳定性和生成性文化密切相关。2017年的一项荟萃分析发现了一些反复出现的倦怠感前因：工作场所支持不足、缺乏工作场所公正、奖励低、工作不安全感。即使 AI 减少了倦怠感，这种效果也可能会被以下因素抵消：

此外，我们的定性工作中出现了一些明确信号，这些信号与工作强化文献一致，表明从 AI 辅助开发工具获得的感知能力提升在一些组织中引发了对工作产出的更高期望。在这些情况下，即使 AI 提高了个人有效性，

被文化的重要[需求和资源之间的平衡]影响所掩盖，保持不变。

探索AI与关键结果的关系 [[40]]

“由于AI，软件开发确实发生了变化，我今年确实感受到了这种变化。

去年并没有真正感受到。但是，我认为随着MCP[模型上下文协议服务器]的最新创新，以及能够与模型一起编程，我认为这确实改变了很多[在]发布功能、功能时间线，以及在特定时间内可以完成多少工作方面…利益相关者期望在[产品]内以更快的方式完成更多工作。所以截止日期和项目的时间更紧迫，这确实改变了我的工作方式。这让我有点担心，因为我认为他们从领导层和产品领导层那里得到了一个相当严格的截止日期，在交付该产品方面。”

软件交付不稳定性

也许这些技术能力比以往更加重要，如果DORA的11年教会了我们什么的话，那就是组织的技术实践和流程与软件交付性能密切相关。缺乏这些基础能力会完全抵消AI带来的任何收益。它们必须为AI时代而发展、被替代或得到补充。

例如，一个采用了AI的团队如果没有建立强大的软件交付管道，并且高度依赖其他团队来交付软件，可能仍然会遇到不稳定性。然而，我们的数据显示，AI采用不仅未能解决不稳定性问题，目前还与不稳定性增加相关。

也许通过启用如此快速的错误修复和更新，要求更严格地遵循其原则，对最终用户的负面影响被最小化。

然而，这可能还不够。也许证据指向一个更颠覆性的结论：这些技术能力和度量不再足够。

然而，当我们超越纯粹的软件交付度量来看时，这个论点站不住脚。为了评估这一主张，我们检查了AI采用是否削弱了[不稳定性对历史上受不稳定性伤害的结果的危害]。

有些人可能会认为，不稳定性是AI辅助开发所带来的开发吞吐量收益的可接受权衡。

理由是AI辅助交付的数量和速度可能会减轻不稳定性的有害影响，或许通过最小化对最终用户的负面影响。

我们没有发现此类缓解效应的证据。相反，不稳定性仍然对产品性能和倦怠等关键结果产生重大有害影响，这最终可能抵消吞吐量方面的任何感知收益。

表明适应性

每一个都表明人员、团队和工具都已适应。人们又有了一年时间来学习如何使用AI，组织和团队又有了一年时间来重新配置，AI公司又有了一年时间来开发更好的模型和体验。[34]

我们可以从工具本身开始。在许多基准测试中，AI工具正在变得更好。[35,36,37] 在你自己的数据上微调预训练模型过去是一项需要深度机器学习专业知识的复杂任务，但现在，许多平台已经创建了简化的工作流程。

云提供商也开发了强大的工具，允许你将私有、专有数据源（如客户数据库、内部文档和代码库）连接到微调过程中，而不会将该数据暴露给公共互联网或基础模型提供商。

与此同时，组织使用AI的方式继续发展，这可能为AI在重要任务（如代码审查、测试生成、调试、代码重构、文档编写和错误解决）方面提供了一些额外的能力和护栏。

个人和团队可能已经开始理解AI在哪里、何时以及如何最有用。一方面，人们可能正在学习将平凡、乏味和重复的任务卸载给AI，并将更多时间花在问题解决、设计和创造性工作上。这将解释为什么AI采用开始预测（与去年发现相反）更高比例的宝贵工作时间。

确实，如果AI正在处理一些编码过程中的基础工作（脚手架、样板代码、常规转换），开发人员可能有更多时间专注于部署代码，从而提高软件交付吞吐量，最终改善产品性能。

我们也可能正在观察组织系统适应到更有利于AI的环境中，这可能赋予个人和团队从AI使用中获得更多收益，同时帮助其好处惠及团队、产品和组织。

我们在DORA AI能力模型和AI镜像章节中探讨了一些可能有助于解释这一点的潜在系统约束。

合理的疑问是为什么其中一些效应受到适应性影响而其他效应没有（例如，软件交付不稳定性）。调查数据并不能让我们很好地回答这个问题。这可能是人们关注重点、某些约束的显著性和某些问题的挑战性的混合。这可能相当于不同的学习曲线。

“如果它能帮助我，或者能在30分钟内完成我需要两个小时或更长时间才能完成的工作，那就很好，因为现在我有了那段时间，我可以做其他事情。我可以做不同的事情。我可以只是做更多的事情。

而且，这也帮助你在职业生涯中进步得更快。对吧？因为你也能更快地学习新事物。”

结论

在不同层面上，AI对大多数结果都产生积极影响，但有一些值得注意的例外：它与倦怠和摩擦没有可衡量的关系，并且持续对软件交付稳定性产生不利影响。

重要的是要注意，AI并没有让技术专业人员的一切都变得更好。一些问题的顽固持续存在，包括不稳定性的增加、摩擦水平的平坦化和倦怠，这不完全是工具的失败，也是系统未能适应它的失败。这些影响的持续存在表明，与其说是AI的失败，不如说是承担所嵌套的组织系统重量的负担——以及这些系统中的一些可能未能适应新范式的失败。

我们相信AI的价值不会通过技术本身来释放，而是通过重新构想它所栖息的工作系统来实现。我们在DORA AI能力模型和AI镜像章节中进一步探讨了这一点。

将2025年的一些发现与去年的进行比较，我们感觉到语言模型、工具和工作流程正在与与它们交互的人员和组织系统一起发展。人们已经找到了使用AI将努力重新导向他们认为更有价值的工作的方法，我们开始找到让AI采用提升到更好的交付吞吐量和产品性能的方法。

AI对专业开发者的社会认知影响

从根本上说，DORA的重点是开发软件的人员。开发者工作的环境在他们如何体验工作生活方面起着关键作用。随着组织重塑其优先级、领导者找到创新的新方法以及AI越来越多地集成到他们的工作流程中，AI有望改变这种环境。

历史表明，技术进步可能导致人们心理模型的实质性变化。在Uber之前，为了搭乘陌生人的私家车而付费的想法几乎是不可想象的。然而今天，在美国和加拿大，大约有3100万人每月至少使用一次该服务。

AI有可能改变开发者从事的工作类型和他们处理的问题。专业开发者处于这种AI驱动转型的前沿，我们的目标是捕捉他们体验中发生的变化。

我们选择调查六个社会认知构建，探索开发者如何看待自己与工作的关系：

AI采用评分规模化对关键结果的估计效应点是后验均值；线是89%可信区间

真实的自豪感

自豪感是一种基本情感。当我们将成就归因于内在和可控的原因——我们的行为时，我们会感到自豪。例如，有人在跑完马拉松后可能感到的自豪，因为他们知道为了到达那里所需要的所有训练里程。当我们获得掌握或完成困难任务时，我们对自己感觉良好。

为什么在AI的背景下衡量自豪感？因为存在两个相互对立的假设，每个都有重要的含义。人们可能严重依赖AI并自动化他们的工作，留下很少的努力成就空间。或者，AI可能解放人们去做他们认为有价值并为之自豪的工作。我们找到了支持后一种假设的证据：

有意义的工作

有意义的工作是指人们希望他们的工作生活花费在做一些重要事情上的愿望。研究表明，通过工作获得意义感的人有更高的幸福感和工作满意度。

我们想要检查AI采用是否影响专业开发者对他们所做工作是否有意义的感知。我们假设AI采用要么(1)通过允许他们自动化繁重任务并增加他们花费在有价值工作上的时间来增加开发者对工作意义的感知；要么(2)通过干扰他们的能力来减少开发者对工作意义的感知。

认知需求

AI的出现为人们提供了一种快速简便的方式来减轻他们的心理负担。学术研究的一些数据显示，学生开发者报告当他们想要”关闭大脑”时使用AI。

虽然有些人深深享受参与心理活动，但AI可能通过提供轻松获取答案的途径来抑制这种享受。复杂的问题现在可以立即解决，这可能导致一些人对心理努力的享受减少。

但我们的发现表明，AI采用并没有导致开发者参与心理活动需求的变化。

更高的AI采用率与更高水平的真实自豪感相关（见图29）。这个数据集还表明了一个清晰的机制：更高水平的AI采用率导致更多时间从事有价值的工作，而那些花费更高比例时间从事他们认为有价值工作的人报告更高的自豪感。

这些发现显示了开发者学习将日常任务卸载给AI的潜在下游收益。他们获得了对最宝贵资产——时间——的控制权，并且能够自由地参与对他们重要的项目和想法。

AI与关键结果关系的探索

存在性连接

存在性连接是感受在你自己的内心世界和他人世界之间架起桥梁的感觉。哲学家威廉·詹姆斯指出，这种差距使得真正了解另一个人的经历变得困难。这个概念捕捉了我们与他人形成深层、人性化联系的能力，让我们在自己的观点中感到不那么孤独。

我们选择研究开发者的存在性连接，因为AI的兴起可能会改变我们在工作中的互动方式。AI提供即时、个性化的答案，这可能减少开发者向同事寻求帮助的需求。虽然高效，但这可能导致更少的对话和共享的问题解决会议。

我们想知道更多依赖AI而减少依赖彼此是否会削弱工作场所关系，让人们感到更加孤立。然而，我们的研究发现AI采用和开发者的存在性连接感之间没有关联。

这可能意味着现在看到这项新技术的影响还为时过早。也有可能对于AI替代的每一次人际互动，它都通过帮助我们分享和建立在更广泛的集体知识基础上创造了新的连接机会。

结果表明AI对开发者感知其工作更有意义或更无意义没有影响。同样，我们可能在这种转变中还处于太早期，无法检测到这些变化。

心理所有权

心理所有权是感觉某样东西是”你的”感觉，即使它实际上并不属于你。我们可以对有形物体和无形构造（如我们的想法）产生所有权感觉。许多开发者对他们编写的代码感到所有权感，我们想知道在AI协助下编写代码是否会削弱对该代码的个人所有权感。

我们的发现以78%的确定性表明，AI采用与开发者感到对其工作的个人所有权感减少无关。简单地说，当他们在AI协助下编写代码时，他们并不认为代码”不那么属于他们”。这支持了当今AI工具作为复杂助手而非自主代理的解释。

因为AI被视为要运用的工具而不是分享功劳的合作者，开发者已经在心理上将其整合到他们的工作流程中，就像编译器或代码检查器一样。

然而，有一个小的（21%）但显著的概率表明AI会降低个人所有权感（见图30）。当开发者在没有AI协助的情况下编写代码时，很明显是他们在进行编写。对一些人来说，AI注入到他们的代码编写过程中可能会模糊谁在进行编写的界限，减少他们感知的投入和个人控制，这是感觉对对象或任务拥有所有权的两个关键心理路径。

技能重新优先排序

随着开发者越来越多地与AI合作，关于这种协作如何改变不同技能相对重要性的讨论越来越多。我们想要检验AI采用是否影响开发者认为哪些技能对他们完成工作更重要或更不重要。

我们假设AI特定技能和以人为中心的技能可能被视为比代码编写特定技能更重要。

我们要求参与者将以下八项技能从最重要到最不重要进行评分：

不出所料，AI采用影响了对提示工程(prompt engineering)感知重要性。AI采用也增加了对编程语言语法记忆感知重要性。这一发现很有趣且值得进一步研究，因为人们可能期望语法记忆是在AI时代第一批被认为过时的开发相关技能之一。

最令人惊讶的发现是AI采用并未影响对任何其他技能感知重要性。

我们还没有准备好从这些数据中得出结论，因为这些发现有许多潜在解释。这些结果可能表明开发者

要点

总的来说，这些发现表明AI采用并未有意义地影响开发者如何体验他们的工作生活。我们将继续主动监控这个领域的任何变化。

与此同时，我们建议组织给予开发者自由，让他们加倍投入他们认为有价值的工作。继续创造机会让开发者学习如何利用AI为他们带来优势，这样他们就可以卸载繁重的任务，在他们的日常工作中腾出空间，花更多时间做重要的工作。

2. 新的AI驱动工作流程，或者开发者将AI视为一种工具问题解决技能

3. 提示工程(Prompt engineering) 他们独特的专业知识将这项技术变得更加

4. 编程语言语法 [继续是不可或缺的。 [自主化，开发者仍然要]

[1. ] [[我们使用了一个成熟的真实自豪感衡量标准。Tracy, Jessica L., Joey T. Cheng, Richard W. Robins, and Kali H. Trzesniewski. “Authentic and ]]

[hubristic pride: The affective core of self-esteem and narcissism.” Self and identity 8, no. 2-3 (2009): 196-213.]

[2. ] [[Steger, Michael F., Bryan J. Dik, and Ryan D. Duffy. “Measuring Meaningful Work: The Work and Meaning Inventory (WAMI).” Journal of Career ]]

[3. ] [Schmidt, Dusana Alshatti, et. al. “Integrating artificial intelligence in higher education: perceptions, challenges, and strategies for academic ]

[innovation.” Computers and Education Open, vol 9 (2025). https://www.sciencedirect.com/science/article/pii/S2666557325000333]

[4. ] [Cacioppo, John T., and Richard E. Petty. “The Need for Cognition.” Journal of Personality and Social Psychology, 1982, 42, no. 1. 116–131.]

[5. ] [[Pinel, Elizabeth C., Anson E. Long, Erin Q. Murdoch, and Peter Helm. “A prisoner of one’s own mind: Identifying and understanding existential ]]

[6. ] [Peck, Joann, and Suzanne B. Shu. “Psychological Ownership and Feelings of Possession.” ][The SAGE Handbook of Consumer Psychology][, edited by ]

探索AI与关键结果的关系

[1. ] [2025 Stack Overflow开发者调查。https://survey.stackoverflow.co/2025]

[2. ] [[“Atlassian研究：AI采用率正在上升，但摩擦仍然存在。” https://www.atlassian.com/blog/developer/developer-experience-report-2025]]

[3. ] [“AI采用从高层开始：LinkedIn上添加AI素养技能的高管比两年前增长了3倍。”]

[5. ] [2025 AI指数报告。https://hai.stanford.edu/ai-index/2025-ai-index-report, 247. 来源quid 2024.]

[8. ] [“衡量2025年初AI对经验丰富的开源开发者生产力的影响。”]

[9. ] [[“根据MIT的一项新研究，ChatGPT可能正在削弱批判性思维技能。” https://time.com/7295195/ai-chatgpt-google-learning-school]]

[10. ][Gerlich, Michael. “AI Tools in Society: Impacts on Cognitive Offloading and the Future of Critical Thinking.” Societies, 2025, 15, no. 1. Article 6. ]

[11. ] [“生成式AI对批判性思维的影响：知识工作者调查中自我报告的认知努力减少和信心效应。” https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf]

[12. ][Forsgren, Nicole, Margaret-Anne Storey and Chandra Maddila. “The SPACE of Developer Productivity: There’s more to it than you think.” ]

[13. ][“AI的SPACE：AI对开发者影响的真实世界经验。” https://arxiv.org/pdf/2508.00178]

[14. ][Quantitative Developmental Systems Methodology Core, Penn State. “介绍 - 基础探索性因子分析。”]

[15. ][Lee, John D., and Katrina A. See. “Trust in automation: Designing for appropriate reliance.” Human factors 46, no. 1 (2004): 50-80.]

[16. ][Cody-Allen, Erin, and Rajiv Kishore. “An extension of the UTAUT model with e-quality, trust, and satisfaction constructs.” In Proceedings of the 2006 ]

[ACM SIGMIS CPR conference on computer personnel research: Forty four years of computer personnel research: achievements, challenges & the ][future, pp. 82-89. 2006.]

[17. ] [[依赖通常被认为是信任的行为表现：“自动化中的信任：整合影响信任因素的实证证据”。]]

[18. ][J. J. Po-An Hsieh and Wei Wang, “Explaining Employees’ Extended Use of Complex Information Systems,” European Journal of Information Systems ]

[19. ] [[采用是动态的，但鉴于我们有一个快照，我们将这些高度共同决定的现象视为单维的。如果我们有面板数据，我们可以更明确地说明这个循环。]]

[20. ][去年，我们用”效应”这个词。然而，今年我们将用”比较”这个词。虽然我们试图做工作来创建]

[在因果条件下说话，我们不想给出错误的保证说我们理解潜在的因果结构。偶尔我们会用因果术语说话，但最终，我们在做比较。这种推理在《回归和其他故事》中得到了总结：“严格来说，将这些标记为’效应’是不合适的——至少，没有很多假设的情况下不合适…观察到的是一种观察模式…这些数据允许人与人之间的比较…回归最安全的解释是作为比较…回归是一个用于预测的数学工具。回归系数有时可以解释为效应，但它们总是可以解释为平均比较。” Vehtari, Aki, Andrew Gelman 和 Jennifer Hill, 回归和其他故事 (Cambridge University Press, 2020), 84-85.]

[21.] [遵循《回归和其他故事》第85页建议的形式。] [22.] [技术上是标准化beta权重。]

[23.] [技术上，这些是标准化beta权重，相当于与AI采用标准差增加相关的结果中估计的标准差差异。]

[24.] [我们的数据集有限，所以它们不是严格相同的，但它们在我们认为对阻断偏倚路径重要的方面是相同的。] [25.] [Bauer, Jared. “GitHub Copilot能否提高代码质量？数据是这样说的。” GitHub博客。2024年11月18日。2025年2月6日更新。https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/]

[26.] [这在去年被称为”生产力”。测量方法略有不同，“个人效能”是更准确的标签。] [27.] [Meyer, André N., Earl T. Barr, Christian Bird, 和 Thomas Zimmermann. “今天是美好的一天：软件开发者的日常生活。” IEEE软件工程交易，2019年，47卷，第5期。(2019): 863—880.]

[28.] [专注时间效能：计算机辅助保护时间对信息工作者福祉和工作投入的效果。] [29.] [“自动化的讽刺。” https://www.sciencedirect.com/science/article/abs/pii/0005109883900468] [30.] [Arnold B. Bakker, Evangelia Demerouti, 和 Ana I. Sanz-Vergel, “工作需求-资源理论：十年后，” 组织心理学和组织行为年度回顾 10 (2023): 25–53.]

[31.] [DevOps状态加速2024。https://dora.dev/dora-report-2024] [32.] [Aronsson, Gunnar, Töres Theorell, Tom Grape, Anne Hammarström, Christer Hogstedt, Ina Marteinsdottir, Ingmar Skoog, Lil Träskman-Bendz, 和 Charlotte Hall. “包括工作环境和倦怠症状荟萃分析的系统评价。” BMC公共卫生，2017年，17卷，第1期。264.]

[33.] [工作强化：1989年至2022年研究的系统评价。] [34.] [“技术性能 | 2025年AI指数报告 | 斯坦福HAI。” https://hai.stanford.edu/ai-index/2025-ai-index-report/technical-performance] [35.] [斯坦福HAI的2025年AI指数报告有很多2023年到2024年的基准测试例子。《自然》杂志反对AI基准测试：https://www.nature.com/articles/d41586-025-02462-5]

[36.] [“技术性能 | 2025年AI指数报告 | 斯坦福HAI。” https://hai.stanford.edu/ai-index/2025-ai-index-report/technical-performance] [37.] [Imarena概览排行榜 (https://lmarena.ai/leaderboard) 显示较新的模型位于顶部。]

探索AI与关键成果的关系 [48]

DORA AI

[49] DORA AI能力模型 DORA长期以来不仅致力于描述软件交付的状态，还帮助

组织做出基于数据的决策，以应对不断变化的开发工具、技术和技术格局。AI正在显著改变软件开发。虽然快速的进步带来了许多令人兴奋的可能性，但它们也带来了关于软件开发如何演进以最好地满足这一时刻的新问题。

因此，今年我们超越了谁在采用AI以及他们如何使用AI的问题，去调查AI辅助软件开发者观察到最佳结果的条件。

我们将这些发现作为我们首个DORA AI能力模型来呈现。这个首创模型中的七个AI能力被证明能够放大AI采用的好处。涵盖组织的技术和文化方面，我们的研究表明，投资于发展这些领域可以帮助释放AI工具的潜力。

正如DORA核心模型一样，我们将继续通过进一步的研究验证、修订和完善DORA AI能力模型。我们渴望与DORA社区分享未来的迭代。

为了开发这个模型，我们假设了一系列可能有助于AI辅助开发团队取得更好成果的能力，基于78次深度访谈、来自领先主题专家的知情意见和之前的DORA研究。

通过广泛的辩论和优先级排序过程，我们选择了一组初始的15个候选能力纳入今年的

调查中发现，这组七个AI可访问的、内部质量AI能力显示出与AI使用存在实质性的内部数据、平台、强版本、控制实践交互的证据。也就是说，当团队将这些能力与AI采用相结合时，AI在重要结果上产生的影响被放大了。

DORA AI能力模型

“明确且有效沟通的AI立场”是指组织在其开发人员如何使用AI辅助开发工具方面的官方立场的可理解性和认知度。我们对明确且有效沟通的AI立场的衡量是一个单一因素，由四个个体指标组成，衡量受访者对以下方面的看法：

通过这种方式，拥有明确且有效沟通AI立场的组织是指鼓励并期望其开发人员使用AI，支持其开发人员在工作中尝试AI，并明确表明允许使用哪些AI工具以及AI政策对其员工的适用性。

明确且有效沟通的AI立场调节AI对个人效能的影响

明确且有效沟通的AI立场决定AI对组织绩效的影响

明确且有效沟通的AI立场调节AI对摩擦的影响

明确且有效沟通的AI立场调节AI对使用AI的最近工作日吞吐量的影响

我们以高度确定性发现，AI采用的积极效益取决于组织是否拥有明确且有效沟通的AI立场，即当他们这样做时：

以较低的确定性，我们还发现，在存在明确且有效沟通的AI立场的情况下：

在我们今年进行的深度访谈中，开发人员经常且一致地表达出对其组织在软件开发中使用AI立场缺乏清晰度和认知。重要的是，这种缺乏清晰度和认知可能表现为：1）过于保守的开发人员，由于害怕超出组织可接受使用参数而使用AI少于他们本可以使用的程度；以及2）过于宽松的开发人员，以他们不应该的方式使用AI。

这些新的调查结果证实了为每个个人、团队和组织这样做的重要性。

值得注意的是，这种AI能力衡量的是组织在软件开发中使用AI立场的清晰度和认知度——而不是具体内容。这意味着组织和团队可以根据他们的独特需求、基于他们的行业、角色和数据基础设施，做出关于什么AI立场适合他们的自己的决定。

并非所有这些情况都是最优的。这些案例既没有超出我们建议投资于明确表达和广泛沟通的组织参数，也没有让组织在AI辅助开发方面的立场变得清晰并传达给其软件开发人员，以及展示出他们在软件开发流程中采用AI所带来的可衡量的积极成果。

“为什么[我]没有更早地探索[AI]？部分原因可能是有一种污名化的感觉——‘我不知道团队其他成员和管理层会如何看待这件事’…没有人在谈论这个话题。所以，我认为并没有’天哪，我会因此惹麻烦’的担忧。

但是，同时也有’我不确定这会得到多大程度的鼓励，以及这是否是他们希望我们继续做的事情’的想法。所以，我也不想偷偷摸摸地去做。我们确实有AI政策，但更多的是关于我们可以向AI提供什么信息，涉及客户保密性等方面的内容。但我认为如果得到鼓励的话，我可能会更多地将其用于一些更常规的任务。”

健康的数据生态系统

“健康的数据生态系统”是指组织内部数据系统的整体质量。在我们的分析中，数据生态系统的健康程度被衡量为一个单一因素，由三个独立指标组成，衡量受访者对以下方面的感知：

通过这种方式，拥有健康数据生态系统的组织可以被理解为一个内部数据高质量、易于访问且统一的环境。

我们非常确信地发现，AI采用的积极效益取决于组织拥有健康的数据生态系统，这样当它们拥有时，AI对组织绩效的积极影响就会被放大。

人们常说AI模型的好坏取决于训练它们的数据质量。在这种情况下，这一传统智慧似乎在组织层面也适用。

当组织投资于创建和维护高质量、可访问、统一的数据生态系统时，他们可以为其组织绩效带来比单独采用AI更高的效益。

数据生态系统健康程度调节AI对组织绩效的影响

AI可访问的内部数据

“AI可访问的内部数据”是指AI工具与内部组织数据源和系统连接的程度。AI可访问的内部数据被衡量为一个单一因素，由四个独立指标组成，衡量受访者的：

通过这种方式，拥有AI可访问内部数据的组织可以被理解为工作人员观察到内部数据可供其AI系统使用，并使用AI工具访问和处理这些数据的组织。

我们非常确信地发现，AI采用的积极效益取决于组织拥有AI可访问的内部数据，这样当它们拥有时：

这也表明，投资时间将AI工具连接到内部系统的组织可能会观察到比依赖通用基础模型提供的较少专业化知识的组织更好的结果。

换句话说，最大化AI在个人效率和代码质量方面的效益可能需要比简单采购AI许可证更深入的投资。在某些方面，这一发现并不令人意外——如果AI无法访问内部公司数据，它真的能有多大用处呢？

虽然基于通用知识集训练的AI工具帮助开发人员感到更有效并产生更高质量的代码，但这一发现表明，当AI能够访问允许开发人员为其AI工具提供公司特定上下文的内部数据源时，AI在实现这些目标方面可能更具影响力。

AI可访问的内部数据调节AI对个人效率的影响

AI可访问的内部数据调节AI对代码质量的影响

[“我认为我的许多现有客户都还没有达到能够有效使用任何AI系统的阶段…他们甚至还没有达到能够妥善组织数据的阶段…数据分散在整个公司各处，没有标准系统来实际存储数据，或者以标准格式存储。然后，如果他们想要使用AI，还需要——实际上不是一点点，而是大量的——数据工程工作，以便将数据转换为生成式AI系统实际可以使用的方式。我觉得许多公司甚至还没有达到能够有效使用AI的阶段。”]

版本控制习惯和变更。具体来说，在AI采用过程中，强调这些实践对于最大化AI收益同时减轻其风险至关重要。

强大的版本控制实践长期以来一直是高性能软件开发团队的基础。这些工具提供了一种系统化的方式来管理代码和其他数字资产随时间的变更。

在生成式AI时代，代码生成的数量和速度急剧增加，这些实践的重要性得到了放大。我们的研究表明，成熟的版本控制实践与AI采用之间存在强大的协同效应，突出了频繁回滚的存在，AI对团队性能的积极影响得到了放大。

版本控制的一个关键方面是它作为”心理安全网”的功能。这个安全网让开发团队能够自信地进行实验和创新，因为他们知道如果出现问题，可以轻松回退到稳定状态。最显著的例子之一是对回滚或撤销功能的依赖。能够迅速且无缝地撤销更改不仅仅是一种便利；它是速度和韧性的关键推动因素。

我们高度确信地发现，AI采用的积极收益取决于受访者版本控制提交的频率。具体来说，在频繁提交的情况下，AI对个人效果的积极影响得到了放大。

此外，我们发现AI采用的积极收益取决于受访者使用其版本控制系统”回滚”功能来撤销或恢复更改的频率。

AI产生代码的速度可能帮助开发者感觉更有生产力。但是，正如我们在”探索AI与关键结果的关系”章节中讨论的，AI使用也与更高程度的软件不稳定性相关。

因此，虽然回滚依赖并不直接减少不稳定性，但我们怀疑它对AI辅助团队性能的积极影响可能与在处理大批量代码及其可能产生的不稳定性时能够快速撤销更改的重要性有关。

我们高度确信地发现，AI采用的积极收益取决于团队进行小批量工作，这样做时：

相反，我们也发现，对于小批量工作的团队，AI采用对个人效果的收益略有减少。

“小批量工作”是一个长期存在的DORA能力，指的是团队将变更分解为可管理单元的程度，这些单元可以快速测试和评估。小批量工作作为单一因子进行衡量，包含三个独立指标：

虽然这些结果是混合的，但我们相信，总体而言，它们指向小批量工作对AI辅助团队的净积极影响。观察到的报告增长中的减少对于优先考虑小批量工作的团队来说，观察到个人效果收益的团队会稍微少一些。

更重要的是，我们认为个人效果本身不应该被追求作为目标。相反，个人效果是实现更大组织、团队和产品性能以及改善开发者福祉的手段。

在这种情况下，小批量工作增加了报告的产品性能，同时也为AI辅助团队减少了感知的摩擦。我们认为，小批量工作对AI辅助团队减少感知摩擦的这些收益，加上小批量工作的那些已经确立的收益，超过了对个人效果的任何潜在损害。

完成[7]中分配的工作，AI在小团队工作中的应用以及个人效率方面的[长期验证，作为我们]

一个在小批次工作方面得分更高的团队通过帮助开发者快速生成大量代码来增强个人效率的感知。

是指每次变更提交更少代码行、每次发布更少变更，并分配可以在更短时间内完成的工作的团队。

通过这种方式，具有用户中心关注点的团队是优先考虑用户体验并理解其与业务成功联系的团队。我们长期认为，用户中心关注点可以帮助团队明确目标并朝着共同战略方向努力，其中用户体验作为北极星。

“用户中心关注点”也是我们年度调查过去版本中包含的一项衡量指标。用户中心关注点是指团队考虑其主要应用程序或服务最终用户体验的程度。

受访者用户中心关注点的程度作为单一因子进行衡量，由三个七点李克特量表指标组成，衡量受访者同意以下观点的程度：

我们高度确信地发现，AI采用的影响取决于团队是否具有用户中心关注点。具体而言，当在采用用户中心关注点的团队中使用时，AI对报告的团队性能的积极影响会被放大。

重要的是，我们还发现，在缺乏用户中心关注点的情况下，AI采用对团队性能产生负面影响。

这些发现共同表明，投资发展用户中心关注点可以为AI辅助团队的性能带来重要好处——而未能这样做可能是有害的。没有用户中心关注点，AI采用不太可能帮助团队。甚至可能伤害他们。

这对AI辅助开发团队来说似乎特别正确；当他们以用户为中心时，他们从AI中获得更大的好处，而当他们不这样做时，会从AI采用中体验到负面影响。

这些发现表明，鼓励AI采用的组织将受益于将对最终用户、他们的目标和反馈的丰富理解融入到他们的产品路线图和战略中。它们也提供了一个重要警告：在缺乏优先满足最终用户需求的用户中心关注点的情况下，AI采用可能会损害您的团队性能。

“百分之百，这就是为什么我在这里待了五年——我觉得我在做有意义的事情并帮助普通人。所以，即使我只是为一个人做这件事，对我来说也是巨大的。但是，在这里，我为数百万用户做这件事…当有一些糟糕的日子，比如我心情不是最好的时候，

如果我知道我做的一切都是为了这个目的，那么这个想法会让我的一天变得更好，并激励我工作，基本上，我今年仅仅通过开发这个小功能就要帮助100,000个用户。”

“一个关键的’顿悟’时刻是意识到临床医生不需要更多工具——他们需要更少的噪音。最初的假设是价值将来自于给临床医生更高级的能力。我们发现的恰恰相反：技术的简单性和不可见性才是真正的创新。AI-人类混合模型在准确性、共情能力和信任度方面比独立自动化提供了卓越的表现。”

具有高质量内部平台，AI对组织性能的积极影响被放大。通过这种方式，高质量内部平台可以通过增加对所需能力的访问和限制对不需要能力的访问来发挥其功能。

理解高质量内部平台的好处一直是我们过去调查的一部分。相反，我们发现AI对受访者报告的体验影响是中性的，因为我们尚未达到标准化集合

在我们的调查中，“平台”是指一组在多个应用程序或服务中共享的能力，旨在使这些能力在整个组织中广泛可用。

这些平台的质量是作为单一分数来衡量的，表明受访者表示其内部平台具有12个特征中的多少个。请参阅附录了解定义我们调查中高质量内部平台特征的完整列表。

我们高度确信地发现，AI采用的影响取决于组织是否拥有高质量的内部平台。具体来说，在拥有高质量内部平台的组织中，冲突的存在是有害的。也就是说，在拥有高质量内部平台的组织中，受访者体验到更多的冲突。

尽管结果参差不齐，我们相信，总的来说，这些发现指向高质量内部平台对AI辅助开发工具的最佳实践产生净正面影响。我们假设高质量的内部平台可能主要具有后一种效应——防止不当使用。这可能解释了重度AI采用者冲突的增加，这对组织来说不一定是负面后果。

由于这个原因，以及它们对组织绩效的好处，我们相信设计和维护高质量的内部开发平台是组织在AI辅助环境中成功开发软件的重要能力。

虽然高质量的内部平台通过提供开发团队可以轻松构建的统一能力集来提高个人效率，但内部平台设定的标准也可能通过定义具有比外部对应部分更高安全控制的内部专用API等方式，为开发工具的使用划定边界。

内部平台调节AI对组织绩效的影响

DORA AI能力模型

将DORA AI能力模型付诸实践

本章的发现表明，在软件开发中成功利用AI并不像仅仅采用新工具那么简单。相反，组织必须培养特定的技术和文化环境才能获得最大回报。

DORA AI能力模型

明确并推广您的AI政策

围绕AI的模糊性会抑制采用并产生风险。建立并推广关于允许的工具和使用方式的明确政策，以建立开发者信任。这种明确性提供了有效实验所需的心理安全，减少摩擦并放大AI对个人效率和组织绩效的积极影响。

将您的数据视为战略资产

健康的数据生态系统显著放大了AI对组织绩效的好处。投资于内部数据源的质量、可访问性和统一性。当您的AI工具能够从高质量的内部数据中学习时，它们对您组织的价值就会增加。

将AI连接到您的内部环境

将您的AI工具连接到内部系统，以超越通用辅助并释放个人效率和代码质量的提升。这意味着不仅仅是采购许可证，还要投入工程努力为您的AI工具提供对内部文档、代码库和其他数据源的安全访问。这提供了工具达到最大效率所需的公司特定环境。

拥抱并强化您的安全网

AI辅助编码可以增加变更的数量和速度，这也可能导致更多的不稳定性。您的版本控制系统是关键的安全网。鼓励团队变得高度

减少工作项目的规模

虽然AI可以通过生成大量代码来提高个人效率的感知，但我们的发现表明这不一定是最重要的指标。相反，要专注于结果。执行小批量工作的纪律，这可以改善产品绩效并减少AI辅助团队的摩擦。

将用户需求置于产品策略的中心

当个人采用AI时，他们的个人效率可能会大幅提升。但是，如果用户的需求不是他们的关注点，他们可能会快速朝着错误的方向前进。我们发现，采用AI辅助开发工具可能会损害那些没有以用户为中心关注点的团队。相反，将用户需求作为产品的北极星可以引导AI辅助开发者走向适当的目标，并对使用AI的团队绩效产生异常强烈的积极影响。

投资您的内部平台

高质量的内部平台是放大AI对组织绩效积极影响的关键推动因素。这些平台提供了必要的护栏和共享能力，使AI收益能够在整个组织中有效且安全地扩展。

熟练使用回滚和还原功能，因为这种实践与AI辅助环境中更好的团队表现相关。

[1.] [“DORA研究项目。” https://dora.dev/research] [2.] [“培养开发者对生成式人工智能的信任。” https://dora.dev/research/ai/trust-in-ai] [3.] [“超越AI输出准确性的担忧。” https://dora.dev/research/ai/concerns-beyond-accuracy-of-ai-output] [4.] [“帮助开发者采用生成式AI：组织的四个实用策略。” https://dora.dev/research/ai/adopt-gen-ai] [5.] [“小批量工作。” https://dora.dev/capabilities/working-in-small-batches] [6.] [“DORA研究项目。” https://dora.dev/research]

平台工程

我们的2024年报告开始探索内部平台对软件交付性能的影响。[1] 我们发现平台对组织绩效和生产力有积极影响。然而，这些收益伴随着权衡：软件交付不稳定性增加和吞吐量下降。

今年的研究超越了确认平台工程价值，探索成功平台如何运作和提供价值。数据显示，平台不仅仅是工具的集合，而是一种直接影响性能、福祉和组织利用变革性技术能力的整体体验。我们发现用户将其平台视为单一实体；其整体有效性比平台中任何单独功能的质量更重要。

本章揭示了定义平台工程状态的关键模式，从普遍采用和团队结构到其作为创新和风险管理战略基础的关键作用。

我们的主要发现

平台采用几乎普及：90%。 改善组织绩效，高质量平台是力量倍增器，提升生产力和团队福祉。

专门的平台团队是主导的组织模式，占76%。这将领导力挑战从采用转向多团队环境的有效治理。

高质量平台放大了AI采用对组织绩效的影响。当平台质量高时，AI对组织绩效的积极影响很强。

平台作为管理风险的引擎发挥作用，实现与软件交付不稳定性小幅但可信增长相对应的速度和实验：为整体更高性能的可管理权衡。

平台格局：普遍、复杂且团队驱动

大多数组织现在都有内部平台，显示对话已从是否需要平台转向应该如何构建平台。我们的数据显示90%的组织至少采用了一个平台，29%的组织现在使用多平台环境。

相应地，76%的组织至少有一个专门的平台团队，超过四分之一的所有受访者(29%)在拥有多个平台团队的组织中工作。多平台使用和多个专门平台团队的普遍性不太像冗余工具的标志，更像是组织正在超越一刀切模式的反映。相反，他们正在创建联合和专门的平台和团队来服务不同的领域和技术栈。

对领导者的挑战已从简单的”拥有平台”转向”治理平台的平台”。像应用程序一样，平台将受益于采用DORA的松散耦合团队能力，[2] 以帮助管理复杂性。这样做需要在团队之间建立明确的章程和接口，以确保他们的生态系统共同改善开发者体验，而不是创建新的组织孤岛。

整体体验才是关键

我们要求受访者根据其平台执行某些能力的程度对其平台进行评级。例如，“平台帮助我构建和运行安全的应用程序和服务。”

我们发现了体验差距。核心技术能力，如”平台有助于可靠性和安全性”，被认为提供得很好，而用户体验功能，包括”响应反馈”和”任务自动化程度”，稍微落后。

平台能力感知每个平台特征的存在按预期工作帮助我遵循所需流程帮助我构建和运行安全应用程序帮助我构建和运行可靠应用程序提供我独立工作所需的工具和信息用户界面(UI)清洁直观隐藏底层基础设施复杂性团队对反馈响应迅速易于使用为我的任务提供清晰反馈自动化我执行的任务

[0% 25% 50% 75% 100%] 受访者百分比 [极其] [非常] [中等] [轻微] [完全没有]

平台工程

开发者对平台的整体印象，无论是作为有用的合作伙伴还是摩擦的来源，都深深影响着他们对每个具体功能的评价。功能的相对紧密分组显示受访者并不认为平台是离散部分的清单；他们将其体验为一个整体实体。

这些数据表明，在用户体验得到解决之前，平台的全部价值仍未实现。

拥抱平台即产品的思维模式，意味着你将内部开发工具视为产品，将开发者视为客户，这有助于确保用户始终是焦点——这是2024年报告的一个关键发现。

以用户为中心是避免构建内部开发者平台时常见陷阱的方法，例如：

• 建好了他们就会来： 团队基于他们认为开发者需要的东西构建平台，而不进行任何用户研究、访谈或验证。他们完全专注于技术和工程，假设其价值将是不言而喻的。

• 为什么失败： 平台最终成为鬼城，因为它没有解决开发者真正痛苦的问题，或者不适合他们现有的工作流程。

• 产品方法从开发者同理心和发现开始。平台团队持续与用户接触，了解他们最大的挑战，确保他们构建的是人们真正想要和会使用的东西。

• 工单运维陷阱： 平台团队像基础设施的自动售货机一样运营。他们没有愿景或路线图；他们的工作完全是被动的，由来自开发者的无穷无尽的工单队列驱动（如”为我提供一个数据库”、“设置CI/CD管道”）。

• 为什么失败： 这为平台团队和开发者都创造了瓶颈和繁琐工作。团队将所有时间花在一次性请求上，永远没有能力构建有凝聚力的自助服务能力。

• 产品方法专注于构建具有明确路线图的自助服务平台。目标是通过授权开发者通过自动化、可重用的工具和黄金路径自行配置资源来消除工单队列。

• 象牙塔平台： 在这里，中央团队从高处指定平台的架构和工具，在没有协作或反馈循环的情况下强制执行严格的标准。他们充当技术的看门人而不是开发者的赋能者。

• 为什么失败： 这种方法可能让开发者感到无力，并经常创建影子IT或非官方的变通方法来绕过平台的约束，违背了其目的。

• 平台的产品经理积极寻求反馈，将开发者视为客户。平台被设计为赋能的，不仅仅是限制性的，提供易于使用和理想的铺路，但不一定是强制性的。

平台功能相关性矩阵

当考虑功能以及它们如何相互关联时，所有功能都或多或少地均匀相关。然而，有两个功能从其他功能中脱颖而出。

首先，与积极用户体验最相关的功能是为任务提供清晰的反馈。当平台在任务成功或失败时提供清晰的反馈时，用户感到有能力采取行动、故障排除和采取下一步行动，而不必筛选事物并自己弄清楚。

其次，“UI简洁明了”的相关性较低：虽然拥有干净的UI可能会改善感知，但这并不一定意味着拥有有效的平台。

即使提供清晰的反馈和UI与其他功能紧密相关，它们在感知方面仍被评为最低的。

为了改善平台的感知质量，团队必须将其视为整体的内部产品，并专注于改善整个开发者旅程。如果平台在技术上很优秀但不以用户为中心（参见2024年DORA报告），它就不能被认为是成功的。

性能的力量倍增器

健康、幸福感和风险

一个高质量的平台，如我们能力所定义的，在各个方面都具有广泛的、统计上积极的影响。它与更高的组织绩效、产品性能和生产力相关联。

与过去的研究一致，我们发现更好的平台与软件交付不稳定性的小幅但可信的增加相关，这意味着更高的变更失败率和增加的返工。

*对于橙色结果（如倦怠感），负面影响是理想的。 89%可信区间

“总的来说，我们的想法是尽可能多地进行持续交付，如果你把它放到主线中，就发布出去，尝试加入一些测试来捕获问题，但只需部署它。在大多数情况下，这是可以的，因为即使部署过程中出现问题，也有很多小的措施来防止站点宕机。所以，部署可能会失败，我们可能需要快速修复。但是，站点仍在运行。”

一个出色的平台充当力量倍增器，直接转化为更好的性能和生产力。相应的不稳定性增加可能代表了一个健康的高速度系统，在这种系统中，额外的不稳定性是可以接受的，只要它不影响产品性能。

尽管稳定性有所增加，但性能的提升表明了一种风险补偿形式，即平台使从故障中快速且低成本地恢复成为可能，团队有能力进行更多实验，并在追求速度的过程中接受更高的小故障率。

稳定性的轻微增加应被视为平台带来的显著性能提升的可管理风险权衡。产品性能的改进可能比交付吞吐量的适度提升和交付稳定性的降低更具影响力。

投资高质量平台是一个强有力的战略杠杆，具有广泛的回报。

平台工程

战略必要性：您的平台是解锁AI的关键

当平台质量较低时，AI采用对组织绩效的影响微不足道，但当平台质量较高时，影响是强烈且积极的。这对于任何投资AI的领导者来说都是一个关键发现。

“Wayfair了解到，最大的收益不仅来自更快地检测故障，还来自减少修复它们所需的努力。将AI嵌入CI/CD循环表明，当这些建议在开发者已经使用的工具中无缝交付时，开发者最能接受有针对性的、可解释的建议和自动生成的修复。”

高质量平台在放大AI对组织绩效影响时有两个目的。首先，它充当分发和治理层，需要将AI的好处从个人生产力提升扩展到系统性的组织改进。

如果没有这个基础，AI采用仍然是一系列不相关的局部优化。平台提供了集中化的上下文，并抽象化了使AI在规模上可用和有效的困难或繁琐部分。也就是说，AI正在快速变化。要谨慎不要过度标准化AI实践、工具和方法，因为这可能会限制积极影响和适应AI变化的能力。

其次，当平台在考虑AI时充当风险缓解器时，其风险缓解效果对AI同样有用。平台应该用于创建一个安全空间，允许个人学习和实验。实验的安全空间将帮助平台和平台团队成长和适应，以更好地支持新模型、交互模式和开发应用程序的方式。

此外，无论代码是手工创建还是由AI创建，都会应用相同的自动化测试和部署流程，本质上有助于确保引入应用程序和服务的更改是安全的。

在没有相应投资高质量平台的情况下投资AI，不太可能在组织层面产生显著回报。要真正利用AI获得竞争优势，领导者必须将平台工程视为基础性战略推动因素。

平台时代的三个要务

拥抱整体体验

让你的平台成为AI的基础

使用你的平台来校准风险偏好

将您的平台视为一个整体，轻松逆转。AI的组织价值。[通过让失败成本低廉来管理风险]

产品，专注于整个开发者体验从反馈循环到自动化。这是将您的AI投资转化为真正竞争优势的引擎。

理解并管理速度与由此产生的不稳定性之间的权衡，认识到平台并不能消除该风险的局部影响。

[1.] [Accelerate State of DevOps 2024. https://dora.dev/dora-report-2024] [2.] [“Loosely coupled teams.” https://dora.dev/capabilities/loosely-coupled-teams] [3.] [Accelerate State of DevOps 2024. https://dora.dev/dora-report-2024]

平台工程

价值流管理

每个组织都面临着更快创新的压力。我们都在采用AI，自动化流程，构建平台，并以极快的速度发布功能。但我们真的在变得更好吗？还是我们只是在更快地创建不提供价值的功能，更快地让团队疲惫不堪，更快地引入复杂性？如今最大的风险不是落后，而是将大量投资倾注到不能推动进展的混乱活动中。

十多年来，DORA的研究一直被一个核心信念指导：最高绩效的组织不仅仅采用新工具，他们成为交付价值系统的专家。他们具备”变得更好的能力”的经验证能力。他们能够理解自己的工作流程，识别真正的约束，并有意图和重点地应用资源。

今年，我们确认了阐述和管理价值流的能力是真正区分无组织活动与有重点改进的关键。在我们2025年的研究中，我们发现专注于理解价值流的团队将显著更多的时间投入到有价值的工作中。

更重要的是，我们发现价值流管理(VSM)是将AI投资转化为竞争优势的力量倍增器，确保这项强大的新技术解决正确的问题，而不是仅仅创造更多混乱。

如何实现有重点的改进：价值流管理的原则

价值流管理(VSM)是可视化、分析和改进从想法到客户的工作流程的实践。这不是一个重量级流程，而是一套四个原则，用于获得专注于最重要改进的清晰度。

有关如何进行价值流映射练习的详细分步指南，请参阅DORA价值流管理指南。[1]

从思维混乱到共享地图

试图理解复杂系统是困难的。对任何人来说，记住所有错综复杂的细节都是巨大的精神负担，这妨碍了对大局的理解。

当团队集体映射系统时，它将所有这些细节从他们的头脑中转移到共享空间。突然间，系统的结构——以及任何隐藏的模式——变得明显。这种可视性使得就什么有效、什么无效进行真正的对话变得更加容易。这正是VSM的核心所在。

实践本身是关于绘制整个软件交付生命周期，从初始概念一直到客户。这张地图涵盖了一切：产品发现、设计、开发、测试、部署和运营。创建这种共享表示允许团队对工作流程形成集体理解，使发现真正阻碍进展的瓶颈和低效率变得更加容易。

从概念到客户映射整个系统是目标，但您不必一次性解决所有问题。关键是从您能产生最大影响的地方开始。

在深入之前，高层次地查看您的工作流程以识别主要约束，这样您就不会优化不是真正瓶颈的流程部分。例如，如果您团队最大的挑战在于产品发现，那可能是一个更有效的开始地点。

尽管如此，一个强大且经过验证的起点，也是DORA多年来使用的，是从代码提交到生产的范围。我们从那里开始，因为流程的这一部分最容易标准化和优化效率。

更重要的是，这是团队通常拥有最多主动权的阶段，因此他们可以立即进行有影响力的改进。这与发现工作形成对比，发现工作的主要目标是优化有效性。

成功完成这个核心流程会创造快速胜利，建立影响更广泛的产品发现和客户反馈系统所需的动力和可信度。

[开始] [代码搜索] [分析] [编写代码] [(故障排除] [生成] [代码] [待办清单] [代码库] [通过IDE] [和重用)] [单元测试] [调试] [提交] [生产] [反馈]

[需求] [审查] [系统] [代码] [代码] [代码审查] [功能] [设计] [迁移,] [准备] [文档] [改进]

专注于流程，而不仅仅是速度

创建文化

[一旦你绘制了价值复杂性，就像，’需要多少工作量才能完成？’以及’你如何估算？’总是不确定的，然后就像缺乏控制一样。我们是否能够按需进行更改并完成工作？还是我们必须经历一个两到三周的流程，每次我们想要的时候，比如防火墙规则更改？诸如此类的事情。有太多不同的方式会拖累我们的工作。我认为[特别是]更资深的人从在其他大公司工作中非常熟悉这一点。]

真正的目标是让工作流动得顺畅且可预测。价值流映射(VSM)不是一次性的练习，而是一个持续的改进循环。定期重新审视你的团队创建的价值流图，并将其作为每次改进讨论的起点。

你应该从衡量重要的事情开始。跟踪关键指标，比如前导时间、处理时间以及增值与等待时间的比率。这些数字为你提供关于真正约束的数据并提供清晰的基线，这样你就知道你的改进是否真正有效。

这种系统级视角对于识别应用新解决方案或技术的最佳位置至关重要。例如，团队可能通过映射发现代码审查是一个重大瓶颈。有了这个洞察，他们可以决定应用AI来改进代码审查过程，而不是使用AI简单地生成更多只会加剧瓶颈的代码。

真正的胜利是使用AI来改进代码审查过程本身，清除系统中的实际阻塞。这就是专注于流程的全部意义：你想要解决整个系统最大的问题，而不只是加速单个步骤。

多年来，DORA一直倡导使用VSM等实践来创建快速的工作流。[3,4] 但特别是随着AI的广泛采用，这个建议是否仍然成立？

我们的发现证实，拥抱VSM原则的组织看到了显著的、可衡量的益处。

首先，我们的研究证实VSM实践对性能有直接而强大的影响。我们发现了以下方面的强有力证据：

• VSM推动团队绩效。 持续审查和改进其价值流的团队报告性能明显更高。

• VSM带来更有价值的工作。 这些团队将明显更多的时间花在对组织及其客户重要的工作上。

• VSM改善产品性能。 最终，这种对价值流的关注转化为更好的产品结果，这可以说是最重要的结果。

培养一种文化至关重要，在这种文化中，团队有权进行实验、学习和适应。[2] 这意味着设定明确的目标，但也为团队提供自主权来弄清楚如何实现这些目标。

他们需要自由进行实验、学习和适应，而不用担心报复。鼓励团队与组织的其他部分分享他们学到的东西也很关键。

通过这样对待VSM并记录每次迭代改进，你创建了进度的活历史。随着时间的推移，你可以反思并建立一个清晰的故事，说明每个变化如何提高了你向客户交付价值的能力。

没有技术卓越的基础，快速、顺畅的流程是不可能的，而这个基础通常是设计良好的内部平台。通过为开发人员提供测试和交付等能力的[“铺好的道路”]，强大的平台抽象了复杂性并使高性能工作可扩展。

强大技术基础与组织绩效之间的关系在[平台工程章节]中详细探讨。

这些数据讲述了一个简单的人类故事：一起工作来理解其价值流的团队很重要。当团队对其整个价值流有清晰的理解时，他们可以专注于最重要的工作，将这种清晰度转化为有意义的影响。

这种清晰度是释放AI等新技术潜力的关键。它不是简单地向问题投掷工具，而是让团队能够具有战略性。你不再只是优化一个小步骤；你正在从系统最大的约束中消除摩擦。

• VSM将AI转化为组织优势： 我们假设VSM调节AI采用与组织绩效之间的关系。具有成熟VSM实践的团队可以将AI的生产力提升导向解决系统级问题，确保个别改进转化为更广泛的组织成功。没有VSM，AI可能会创造局部效率，这些效率简单地被下游瓶颈吸收，对整个组织没有提供真正价值。

在具有强大VSM实践的组织中询问您的团队：“我们能在白板上画出软件交付价值流吗？”

这证实了VSM是从AI投资中获得最大收益的关键推动因素。如果答案是否定的，或者如果图画揭示了更多问题而不是答案，您就找到了起点。通过确保团队级别和个人生产力提升专注于最重要的系统级约束，VSM帮助将本地改进转化为有意义的组织影响。那单一的对话是变得更擅长变得更好的开始。

[1.] [“如何使用价值流映射改进软件交付：价值流映射指南。”]

[2.] [“如何转变您的组织。” https://dora.dev/guides/how-to-transform] [3.] [“价值流中工作的可见性。” https://dora.dev/capabilities/work-visibility-in-value-stream] [4.] [“视觉管理。” https://dora.dev/capabilities/visual-management]

[去年的DORA报告发现，使用AI的团队报告了更低的吞吐量和软件交付中更多的不稳定性。意外的发现引发了激烈的辩论—为什么一项旨在加速工作的技术会与更慢、更不稳定的结果相关联？]

[今年，情况发生了一些变化。AI采用现在帮助吞吐量略有上升，但不稳定性仍然存在。进步与摩擦的混合促使我们深入挖掘，超越简单的二元AI比较来理解真正决定其影响的因素。]

[我们发现的结果指向比工具和技能更大的东西：最重要的是，AI所嵌套的环境塑造了它的影响。]

今年研究中最令人兴奋的成果之一是DORA AI能力模型。AI使用对吞吐量、代码质量以及团队和组织绩效等结果的影响被七项能力一致放大：

这些系统性条件反映了组织如何构建其工作、支持其团队，并将其环境与现代开发实践保持一致。这些能力可以帮助确定使用AI工具是否转化为有意义的结果，这使它们成为放大器。它们都是团队和组织级别的事实强化了我们需要在如何思考AI在软件交付中的作用方面做出的关键转变。

我们看到AI对性能的影响取决于工作发生的系统。例如，与AI工具集成的健康数据生态系统(data ecosystem)可以帮助创造条件，将AI的好处从个人生产力改进提升到组织飞跃。没有这些基础努力来为AI用户设置成功条件，其好处可能会停滞、停滞不前或保持不均匀分布。

[为了利用这一洞察，我们应该将聚光灯从个人如何使用AI转移到组织如何设计围绕它们的系统。]

要理解从个人生产力提升扩展AI影响到组织级别收益所需的条件，我们需要考虑系统。组织更像是相互依赖部分的网络，而不是个人和工具的集合。工作流经团队、流程、政策、基础设施和共享规范。虽然个人能力在塑造结果中发挥关键作用，但整体性能来自所有这些部分如何相互作用。

它能提供多少价值。专注于约束以外的任何事情可能感觉有成效，但不会有意义地改善价值流。

新的、强大的技术只有在围绕它们的系统演进时才会产生相应的变革性结果。

这一想法是系统思维的核心，这一观点塑造了高绩效组织的演进方式。W. Edwards Deming，现代质量的奠基人之一

[这就是为什么AI采用需要被视为转型努力。如果组织想要更快地移动、更多地实验，并改变开发人员如何花费时间，它将需要重新审视工作本身如何流动。]

这对AI采用有影响。当开发人员使用AI工具并更快地编写代码时，代码仍然需要通过测试和审查队列，然后是集成和部署过程。

总体交付速度不太可能显著改变，除非周围的工作流程为开发人员的新工具和提高的速度进行更新。系统不是为了承载收益而设计的，更不用说放大它们了。

[下游系统—如集成、测试、部署和合规性—是否足够灵活和响应来利用AI的速度？决策结构是否跟上工作的节奏？团队是否被激励委派任务、大规模验证AI输出，并以新方式分享知识？]

在向云端转移的过程中，仅仅迁移基础设施而不重新思考架构和交付实践的公司看到的收益有限。然而，那些为云原生工作流重构其应用程序、团队和运营的组织能够释放真正的价值。敏捷和DevOps也是如此：只有当它们与角色、反馈循环和团队边界的深度变化相结合时，才能兑现承诺。

管理学认为，大多数性能问题不是源于人员，而是源于系统。正如著名的说法：“一个糟糕的系统总是会击败一个优秀的人。”

在系统中，改进一个部分并不能保证整体的更好结果。事实上，如果系统的其余部分无法适应，局部改进可能会被阻塞、稀释，甚至逆转。

这也是约束理论的核心洞察。每个系统都有一个限制因素——一个约束——它决定了

在没有对工作流、角色、治理和文化期望进行有意识改变的情况下，AI工具很可能在其他方面保持不变的系统中仍然是孤立的提升——这是一个错失的机会。为了扩大AI的影响，组织应该投资于重新设计他们的系统。这意味着识别约束、简化流程，并创造局部加速成为组织动力的条件。

AI镜像

两种方式的转型：

增强和演进

当组织追求AI的全部价值时，我们可以沿着两条互补的路径思考转型。一条专注于增强现有系统以消除摩擦并支持AI工具引入的速度。另一条则想象AI如何为全新的工作方式打开大门。

增强：准备系统承载收益

当开发人员开始使用AI工具并体验到生产力改进时，但团队没有看到相应的吞吐量或交付速度提升，系统本身可能就是限制因素。

增强意味着识别和解决那些摩擦点，使个体加速能够向下游流动。

代码审查和交接： 考虑AI可以在哪里加速和澄清现有步骤。例如，AI生成的初审可以快速发现问题并减少例行反馈的时间。构建AI输入以突出风险或总结差异也可以使人类的审查更容易、更快速。

集成和部署管道： AI生成的代码移动很快——你的系统能跟上吗？持续集成和部署管道可能需要演进以减少等待状态并允许更高频率的交付。由AI驱动的质量检查可以在不添加手动门控的情况下分层加入，在不牺牲保证的情况下改善流程。

数据基础设施： AI能力模型指出了投资更新数据基础设施的价值。首先，当AI模型和工具连接到内部数据时，AI对生产力和代码质量的好处会被放大。想想仓库、工作跟踪工具、文档，甚至决策日志和通信工具。添加这些有价值的上下文改善了AI工具的输出。与关键上下文相关的是，第二个发现是当数据生态系统健康时——即当数据是AI可访问的、准确的和完整的时候——AI对组织绩效的好处更大。

安全和隐私协议： 随着AI现在参与开发和运营工作流，安全实践必须演进。这包括确保安全的工具使用、更新政策，并引入AI感知的监控系统，在不引入瓶颈的情况下维护信任。自动化这些流程的部分可以帮助团队保持速度。

变更管理和文化对齐： 像任何组织转型一样，AI采用需要愿景、支持和沟通——这些都是转型领导力的特征。领导者应该阐明AI转型的长期目标——无论是创新、速度还是质量——并通过培训、共享实践和现实期望来支持转型。

文化也很重要。团队需要获得实验、犯错误、建立熟练度和分享所学的许可。奖励验证、委派、提示策划和代理编排等行为向AI加速环境中成功的样子发出正确的信号。

演进：为AI使其成为可能而设计

除了增强现有系统外，AI还提供了设计新工作流的机会——那些原生于AI运作方式的方法。

AI原生交付管道： AI可以持续分析代码中的错误、安全漏洞和违反团队标准的情况。它可以建议测试甚至动态生成测试。通过正确的数据和集成，AI还可以在部署风险和性能回归发生之前预测它们。

AI原生数据系统： AI可以通过组织、标记、清理和分析数据来帮助维护自己的环境。这使得更强大的洞察生成和基于数据决策的更快迭代成为可能。它还揭示了团队工作方式的模式，为运营改进提供了新的杠杆。

AI原生安全： AI可以通过更早检测威胁、识别异常行为，甚至自动化事件响应流程的部分来扩展安全团队的能力。对于经常资源不足的安全团队来说，AI的作用可以是缓解压力同时改善响应时间。

AI原生协作模型： 正在兴起的实践，如代理工作流(agentic workflows)和群集(swarming)，开始重新塑造人类和AI如何协同工作。代理工作流将任务分配给自主AI代理(agents)，而群集使团队和AI能够动态聚合来解决复杂问题。虽然仍处于早期阶段，但这些模式暗示了新的、更具适应性的协作方式。

新兴趋势如持续AI展示了AI原生工作流如何能够长期维持。持续AI将AI系统视为开发管道的活跃组成部分和团队流程的参与者。

持续AI持续感知项目环境中发生的事件，通过自主而协作的操作，促进团队互动并与团队一起调整方向。关键是让AI系统或代理不断更新相关上下文，并持续评估准确性、有用性和成本。

这使AI与组织不断演进的架构、实践和优先级保持一致，确保其输出在环境变化时保持相关性和高质量。

在增强和演进中，共同的线索是意图(intention)。仅仅部署AI工具不会产生转型，但与务实和富有远见的系统级变革相结合，采用AI可以成为重塑软件构建、交付和安全方式的催化剂。

AI镜像

起步指南：AI转型的实践步骤

组织越早开始将AI采用视为转型努力，就越能控制转型如何展开。技术发展迅速，但真正的差异化在于组织如何有效应对。在旧流程围绕新工具固化之前开始，意味着组织可以塑造其系统的未来，而不是默认继承它们。

一个自然的第一步是审视今天的工作实际如何流动。在实践中，这意味着创建对想法如何从构思到交付流动的共同可见性。这个过程，通常称为价值流管理(value stream management)，可以帮助团队可视化交付的每个阶段，从编码和代码审查到测试、部署和生产。

当做得好时，映射工作流程会暴露协调成本积累的地方，延迟和返工常见的地方，以及系统吸收或阻止AI工具带来的加速的地方。它可以帮助聚焦于约束理论所说的最能实现价值的因素。

要开始映射工作流程，组织可以组建小型跨职能工作组，由嵌入在日常软件交付操作中的实践者组成，包括工程师、产品经理、数据工程师、运维和安全人员。这些小组最有能力从内部映射系统，并揭示协调故障和瓶颈，以及识别AI可以发挥转型作用的地方。

当这些努力得到高管赞助时最为有效。这种支持标志着战略重要性，确保工作得到资源支持，并创建从发现到行动的清晰路径。这些工作组的任务是制定战略建议：系统应该在哪里适应以容纳AI？AI可以在哪里增强流程或角色？需要开发什么能力来释放长期价值？

在某些情况下，外部协调员或顾问可以帮助指导流程，提供基准，并使对话专注于能够释放更广泛改进的系统性机会。

为了使变革扎根，洞察必须来自系统内部。当实践者推动发现，领导层致力于实现结果时，有意义转型的条件开始形成。

至关重要的是，这项工作必须用系统思维来处理。如前所述，组织是复杂系统，改进一个节点，如加速代码生成，不会改善性能，除非相邻组件并行演进。DORA AI能力模型为组织级干预将如何放大AI收益提供洞察。

例如，工作组可能发现，虽然AI工具能够提供有价值的建议，但它们经常生成缺少关键上下文的响应，如团队约定、架构历史或过去的事件。

这对许多组织来说可能并不令人意外，因为这些信息经常埋藏在不同的系统和非正式的知识渠道中。

作为回应，小组可能建议以结构化、安全的方式向AI模型公开内部文档、决策记录和历史工单。他们可以提议构建自动标记和在开发或审查期间浮现这种上下文的工作流，减少开发人员搜索的时间并提高AI输出的质量。

这样做可以帮助将碎片化的知识转化为结构化、可操作的资产。

除了流程变更，这些工作组还可以揭示对新技能和角色的需求。随着开发人员将更多工作委托给AI工具，验证、编排和工作流设计等任务变得更加重要。这包括提供超越工具的针对性培训，涉及AI如何改变开发工作的本质。

这些变化都不会自动发生，也不会一蹴而就。它们需要意图、所有权和持续支持。然而，它们不需要的是完美。

设计系统实际执行与文档声明之间的不一致性将变得更加核心化。从一开始就需要解决这个问题。

组织需要定义这些角色的具体形式，如何支持它们，以及如何相应地调整激励机制。

当组织从小规模开始时，有目的地投资，并在各个角色之间建立共同责任，它们就能建立动力。一步一步，一个能力接一个能力，转型就能扎根。

“文化转型与工具同样重要。成功不仅需要引入自动化和指标，还需要让团队围绕共同目标和所有权保持一致。”

AI镜像

AI有可能重塑软件构建方式，但它本身并不会改变组织系统。它确实做的事情，而且通常很快，就是反映这些系统的实际运作方式。

这就是为什么AI既是镜像又是放大器的原因。它照亮了什么在起作用，通常加速已经在进行的事情，但它也暴露了需要改变的地方。

在协调良好的组织中，AI放大了流程。在分散的组织中，它暴露了痛点。拥有强大实践、灵活工作流程和共享上下文的团队通常会立即看到好处。

依赖脆弱流程和隐性知识的团队可能会发现这些差距比以往任何时候都更加明显。

对于准备好观察的组织来说，AI提供的反映成为了路线图。正如我们在过去的其他转型中所看到的，愿意将AI采用视为发展工作方式机会的组织将是受益最多的组织——既从工具中受益，也从它们使之成为可能的转型中受益。

AI：技能发展的威胁——和机遇

Matt Beane, Ph.D. 加州大学圣巴巴拉分校副教授，斯坦福大学和麻省理工学院数字研究员，SkillBench首席执行官/联合创始人

在技能发展方面，软件与其他职业相似。专业知识应该从高级员工流向初级员工，理想情况下，新的视角和技能应该向上传递。

高级开发人员不仅仅是审查拉取请求(pull requests)；他们教授初级开发人员如何进行架构思考。结对编程(Pair programming)不仅仅是为了发现错误；它是为了传递难以记录的隐性知识。在最好的情况下，三代模型——初级、中级、高级——帮助开发人员通过联合问题解决获得技能，而不是正式培训。

我们需要调查AI部署对这一理所当然过程的影响。我的职业生涯一直在研究智能自动化和技能，并在31个以上的职业中证明，智能自动化的默认使用改变了传统的学徒模式，为新手参与对其发展至关重要的实践工作留下了更少的机会。

专家可以自助服务，所以他们这样做了。少数初级开发人员尽管有这种参与障碍仍能学习，但大多数人都在挣扎。自2023年以来，我只研究复杂任务性能中的AI使用，最近在软件工程中，这种模式在我的早期发现中也很明显。

但也有有趣的例外，需要更多的理解。像过去其他突破性技术一样，从印刷机和个人计算机到互联网，AI正以前所未有的速度被开发和部署。我们不知道人类能力将如何适应这些变化。

相反，许多人专注于衡量与AI相关的生产力。我们跟踪采用率、生成的代码行数、合并的拉取请求。这些不是表明技能发展的指标，比如随时间推移的语言或风格多样性。

最佳组织将联合优化员工的生产力和技能发展。事实上，在我的一些研究中，只有坚持同时进行技能发展才能实现卓越的生产力。衡量和推动两者是可持续性能的路径。

AI是软件开发未来的组成部分——这包括技能发展。例如，我们可以使用AI来解析开发人员-AI交互，将此链接到版本控制交互，然后链接到技能和关键工作成果。

这在以前是不具成本效益的，但标记的API成本正在快速下降。通过AI，我们可以获得重构工作所需的见解，并为开发人员提供如何保持学习优势的指导——并帮助其他人做同样的事情。

默认的AI使用模式正在为大多数开发人员提供突破性的生产力并阻碍技能发展。要保持我们的创新优势——无论是个人还是集体——我们需要使用AI本身来同时衡量技能发展和生产力。

指标框架

选择适合组织目标的测量框架

衡量软件开发的框架类型

能够推动有影响力的变革。话题（例如，开发者目标和决策测量）

然而，这是一项复杂的任务，经验）转化为可以测量的不同概念（如速度或满意度），因为框架在其总体目标上有所不同。

开始可能令人望而却步，因为它涉及理解你应该测量什么，以及确定你能够测量什么。当我们谈论测量软件开发的各个方面时，他们经常引用诸如SPACE[1]、DevEx[2]、HEART[3]和DORA的软件交付指标[4]等框架。例如，软件开发行业和学术界的常见框架专注于测量开发者体验、产品卓越性和组织效率。

最重要的部分是你想要通过测量在组织中推动变革。为此，我们建议你使用框架来指导你的测量策略。

选择一个框架来测量软件开发可能是一个困难且令人困惑的步骤，但它不必如此。这些总体目标中的每一个都会以稍微不同的视角来理解软件开发（见图52）。

指标框架

要确定哪个框架最适合你组织的特定体验和目标，将框架视为测量背后的”为什么”会很有帮助。它们帮助你定义为什么要尝试测量，并指导你基于发现采取的行动。

框架提供了一个透视数据的视角，确保你的努力与组织目标保持一致。要决定使用哪个框架，你可以考虑：为什么是现在？是否有什么变化激发了测量的愿望？你将如何基于洞察采取行动？是否有你可以通过测量实现的决策或改进？

现在，你要测量的”什么”是实际的指标，是有助于总体框架的关键概念，如速度或采用指标。

一般来说，你可以采取两种不同的数据收集方法。这是数据收集的”如何”，将帮助你得出指标。

自报告数据

自报告数据涉及直接从开发者那里收集关于他们体验的信息。这可以通过以下方法实现：

• 访谈和焦点小组 - 使用一对一和小组讨论来深入了解特定体验和话题。

• 调查 - 使用问题收集关于工作各个方面的意见、满意度水平和看法。

自报告数据的优势在于其捕获主观体验和难以通过自动化手段量化的概念的能力，如满意度、幸福感或感知效率。自报告数据的一个关键优势是它通常不需要广泛的仪器化或对开发者工具链的深度可观察性。

然而，自报告数据在标准化、跨团队可比性和大型组织的可扩展性方面确实存在挑战。其固有的主观性意味着解释可能会有所不同，并且可能更容易受到偏见的影响（包括回忆偏见和社会期望偏见）。

基于日志的测量

基于日志的测量是从开发者使用的工具和系统中自动收集的。这些可以包括以下指标类型：

• 频率 - 测量特定时间窗口内的速率。例如，每月部署或每周每个开发者的PR。

• 基于时间 - 记录在特定活动上花费的时间。例如，编码或审查所花费的时间。

基于日志的测量的主要好处是它们能够提供连续测量和大规模标准化数据。它们提供了活动和输出的详细视图。

然而，它们需要对开发者工具链有足够的可观察性，这意味着必须有必要的集成和数据收集机制，这可能会产生更高的准入门槛。

也有一个常见的误解，认为基于日志的指标是客观的。仪器化方法各不相同，错误可能会造成不准确性，解释容易受到偏见的影响。

框架选择考虑

框架将为你提供你想要测量的概念，但最终你实施什么取决于你的资源和你可以访问的数据。你是否对工具链有可见性以进行基于日志的方法，或者有研究团队来支持自报告数据收集？

重要的是要认识到，并非所有组织都具有相同的资源和能力来以特定框架可能推荐的方式实施指标。

即使存在组织限制，框架也是一个指南，一个帮助你更好理解复杂行为的视角——但它们无法完全捕获它。

餐点的味道都会不同，但一些基本成分是共享的，在许多情况下，你不需要拥有所有成分就能制作出美味的食物。组织可能会使用这些指标来衡量新团队结构的影响（组织效率），评估开发者工具的效果。

它们旨在让你更接近一顿美味的餐食。工具（产品卓越），以及

框架和指标如何关联时，底层指标会重叠。下面的更专业化的。开发者福祉，

配料，将框架视为构成框架的指标以及它们如何关键组成部分，

用配料制作的食谱，经常重叠。例如，生产力通常不是[组织效率]

这样思考会很有帮助。一些核心配料指标（如代码提交或或产品卓越框架中的主要指标。

方式重新排列来制作不同的食谱所有三个框架测量。选择使用单一

（框架），而其他的则是 [框架可以帮助为你采取的行动提供焦点]

[适用于不同框架的指标示例] [很好的开始方式。但是，你]

你可能想知道，AI引入随着我们看到AI的更多实质性组织面临的一个常见问题是

开发工作流程是否改变了进步，谁在做 AI对代码质量的影响。[6] 当我们看到AI被用来

框架是否适用，还是我们需要任务是什么——将会改变。因此，有一个特别的担忧，即我们

技术颠覆时，似乎包括不同的用户配置文件短期内开发者速度的提高

有必要完全并捕获变化的工作流程，可能看起来是积极的；但是，如果质量低，

策略。我们建议仔细体验的核心目标可能没有改变。产生负面影响。

需要改变，特别是总体目标是相同的， [为了解决这些担忧，你的]

在考虑AI的影响时。你不需要改变你的目标可能是确保组织的

调整你的目标以更好地你的测量来适应 [采用AI驱动的工具]时保持高水平。

只需要更新几个即使你的目标确实改变了，可能包括你已经捕获的

指标，允许你保持这也不一定意味着指标（如代码质量、工具

使用现有的测量作为框架做出贡献，你通常可以现有指标，同时引入

基线，帮助识别快速反应并重新安排指标新的指标。例如，将

你可能需要添加理解AI驱动的开发者工具框架（如HEART）结合。可以

关于AI建议接受率、模型对正在生产的代码的影响有效地理解

现有的开发者以前没有面临过的新目标。这 AI驱动的工具以及

体验测量，如感知特别具有挑战性，因为对软件交付的影响。[7]

• 计划(Plan)： 明确你的目标，选择一个框架，并获得领导层支持

[1.] [“开发者生产力的SPACE：比你想象的更复杂。” https://queue.acm.org/detail.cfm?id=3454124] [2.] [“开发者体验：真正驱动生产力的因素：以开发者为中心的生产力测量和改进方法。” https://queue.acm.org/detail.cfm?id=3595878] [3.] [“大规模用户体验测量：Web应用程序的用户中心指标。” https://research.google/pubs/measuring-the-user-experience-on-a-large-scale-user-centered-metrics-for-web-applications] [4.] [“DORA的软件交付指标：四个关键。” https://dora.dev/guides/dora-metrics-four-keys] [5.] [“通过结合DORA和H.E.A.R.T.解锁产品成功。” https://cloud.google.com/transform/unlocking-product-success-by-combining-dora-and-heart] [6.] [“测量AI代码助手和智能体。” https://getdx.com/research/measuring-ai-code-assistants-and-agents] [7.] [“通过结合DORA和H.E.A.R.T.解锁产品成功。” https://cloud.google.com/transform/unlocking-product-success-by-combining-dora-and-heart]

指标框架

最终思考：

从洞察到行动

十多年来，DORA一直是软件开发社区的可信合作伙伴，提供研究和洞察来帮助团队改进。随着行业快速发展，采用AI和平台工程等新技术，我们的承诺保持不变：调查和分享培养高绩效团队的实践。

今年的研究揭示了一个关键洞察：我们仍处于AI辅助软件开发的初期阶段，这是一个技术和实践快速演进的时期，过早的标准化将是不合适的。我们的发现表明，简单地部署AI工具并不是转型的万能药。实际上，AI对团队绩效的影响显著依赖于一个关键因素：以用户为中心的焦点。

DORA AI能力模型

今年，我们推出了首届DORA AI能力模型，这是我们研究的重大演进。当组织应对AI采用的复杂性时，这个模型提供了一个基于数据的框架来指导他们的旅程。它突出了七个关键能力，当培养这些能力时，能够放大AI对重要组织成果的积极影响。

这些能力包括： • 明确且传达的AI立场 • 健康的数据生态系统 • AI可访问的内部数据 • 强大的版本控制实践 • 小批量工作 • 以用户为中心的焦点 • 高质量的内部平台

这个模型是我们的第一次迭代，我们将其视为与DORA社区和拥抱AI辅助软件开发的组织持续对话的起点。我们渴望从你们应用这些洞察的经验中学习，并期待在我们未来的研究中验证和完善这个模型。

我们发现，有很高的确定性表明，当团队采用以用户为中心的焦点时，AI对其绩效的积极影响会被放大。相反，在缺乏以用户为中心焦点的情况下，AI采用可能对团队绩效产生负面影响。

这一发现强调了对所有组织的重要信息：投资和培养对终端用户的深度理解不仅有益，而且是AI成功的先决条件。没有以用户为中心的策略，AI采用不太可能有所帮助，甚至可能阻碍你团队的绩效。

将研究付诸实践：轮到你进行实验了

今年报告中的发现很复杂，有时甚至可能显得矛盾。这反映了一个变化中领域的现实。我们鼓励你将我们的发现不是作为严格的处方，而是作为你自己实验的假设。

• 在你的组织中进行实验： 使用DORA的发现来制定假设并在你的团队中测试它们。这将让你了解更多关于你特定的运营环境，并识别最有影响力的改进领域。

• 进行内部调查： 从今年调查中使用的问题中获得灵感来设计你自己的调查。用更细致的、直接与你的团队和项目相关的问题来定制它们。

• 拥抱整体体验： 记住，改进单一功能不会修复有缺陷的平台。将你的内部平台视为产品，专注于从反馈循环到自动化的整个开发者旅程。

• 分享你学到的： 当你进行自己的实验并收集洞察时，在你的组织中传播这些知识。这可以通过正式报告、非正式的实践社区或随意对话来实现。目标是培养持续学习的文化。

在这个不断演变的环境中，最大的风险不是落后，而是大量投资于无法提供有意义结果的混乱活动。选择与你的组织产生共鸣并激励你采取行动的框架和方法。

加入对话

通过加入DORA社区，分享您的经验，向同行学习，并寻找灵感：https://dora.community.

[1.] [“DORA Research: 2025 Survey questions.” https://dora.dev/research/2024/questions]

结语

致谢

数千名研究人员、专家、实践者、领导者和变革推动者慷慨地分享他们的知识和经验。这份报告是集体努力的直接成果。我们也要感谢您，读者。我们希望这些发现能够帮助您和您的团队推动有意义的变革，并在您的组织内实现持续改进。

赞助商

2025年DORA报告得到以下赞助商的支持。在DORA网站上了解更多关于这些赞助商的信息。[1]

研究合作伙伴

DORA报告团队

Matt Beane博士 James Brookbank Kim Castillo Sarah D’Angelo博士 Derek DeBellis Rob Edwards Edward Fraser Benjamin Good Nathen Harvey Sarah Inman博士 Eirini Kalliamvakou博士 Gene Kim Eric Maxwell Ambar Murillo Allison Park Daniel Rock博士 Kevin M. Storer博士 Daniella Villalba博士 Steve Yegge Jessie Young

编辑

Seth Rosenblatt Accuracy Matters[2] Vivian Hu Jez Humble Michelle Irvine Ben Jose Deepti Kamat Amanda Lewis Mike Long Steve McGhee

Jerome Simms Thomas De Meo Dustin Smith Nicole Forsgren博士 Dave Stanke Laura Tacho Adrienne Braganza Tacke Finn Toner Cedric Yao

DORA社区指导

DORA社区成员

Rebecca Murphey Jacek Ostrowski Justin Reock Willy Rouvre Ryan J. Salva Harini Sampath Dadisi Sanyika Robin Savinar Sean Sedlock

研究和设计合作伙伴

Apparent:[3] DORA品牌设计 Human After All:[4] DORA报告设计 Prolific:[5] 研究基础设施支持 User Research International:[6] 研究基础设施支持

该领域的顾问和专家

Ameer Abbas Colette Alexander Christy Barrett Sander Bogdan Kevin Borders Adam Brown Michele Chubirka Andrew Davis

[1.] [“DORA 2025 Sponsors.” https://dora.dev/research/2025/sponsors] [2.] [“Accuracy Matters.” https://accuracymatters.co.uk] [3.] [“We Are Apparent.” https://apparent.com.au] [4.] [“Human After All: Clarity through creativity.” https://www.humanafterall.studio] [5.] [“Prolific | Easily collect high-quality data from real people.” https://www.prolific.com] [6.] [“User Research for Product Development | User Research International.” https://www.uriux.com]

作者

Derek DeBellis

Derek DeBellis自2022年以来一直领导DORA的研究项目，现在很高兴与Kevin M. Storer博士共同领导。

他被一个核心问题驱动：什么能帮助人们快乐而有效地协同工作？这个问题激励着他在DORA的工作以及他对权力动态、学习架构和信念传播的独立研究。

当他不在分析数据时，Derek可能在科罗拉多洛基山脉跑步（扭伤脚踝），阅读卡夫卡和博尔赫斯的作品，或者录制音乐。

Kevin M. Storer

他的工作重点是了解组织如何最好地调整其软件开发实践，以应对生成式AI(Gen AI)的最新进展，特别是在编码中的应用。

Nathen Harvey

Nathen Harvey领导Google Cloud的DORA团队，利用其研究帮助组织提高软件交付速度、稳定性和效率。

他专注于提升开发者体验(Developer Experience)，致力于培育DORA社区等技术社区，为学习和协作提供机会。

Matt Beane博士

Matt Beane是加州大学圣巴巴拉分校技术管理副教授、斯坦福大学和麻省理工学院数字研究员，以及SkillBench的首席执行官兼联合创始人，该公司帮助企业通过生成式AI使用提升生产力和技能。

自2011年以来，他一直研究智能技术的部署。他是《技能代码：如何在智能机器时代拯救人类能力》(The Skill Code: How to Save Human Ability in an Age of Intelligent Machines，HarperCollins出版社，2024年)的作者。

Rob Edwards

他与客户合作，帮助他们的工程团队更顺利、更可靠地构建和发布软件。

他坚信最佳的技术解决方案来自于人们为了共同目标而协同工作，使技术成为业务成功的工具。

Edward Fraser

Edward Fraser是加州大学伯克利分校信息学院的研究生，探索人机交互和新兴技术如何创造更直观、更具赋权性的体验。

凭借设计和产品管理的专业经验，他最近的工作涵盖了使用AI编码助手的开发者眼动追踪研究、企业AI工具的用户体验研究，以及为在押学习者设计教育平台。

作者

Benjamin Good 是 Google 的 Eirini Kalliamvakou 是 GitHub Gene Kim 是一位获奖的云解决方案架构师。 CEO 的员工研究员转研究顾问。研究员和作者。自 1999 年以来， Eirini 的专注点是理解开发者他一直在研究高绩效技术组织。他热衷于通过云技术和的需求、动机和行为。自动化改进软件交付实践。她的工作为 GitHub 的评估、他的书籍销量已超过 100 万册作为解决方案架构师，他通过创新战略和故事讲述提供信息， ——他是《独角兽项目》的 WSJ 畅销提供架构指导、技术指南发布她在 AI 工具和 DevEx 方面书作者，以及《凤凰项目》、和开源贡献来帮助 Google 的获奖研究正在塑造行业《DevOps 手册》和两本新乡 Cloud 客户解决问题。在加入实践和社区影响。出版奖获奖书籍《加速》和 Google 之前，Ben 在丹佛/ 《连接获胜组织》的合著者。博尔德地区的几家公司负责云运营，期间构建了多个平台。 2025 年，他获得了美国质量学会 (ASQ) 的 Philip Crosby 奖章。他的最新著作《Vibe Coding》与 Steve Yegge 合著（2025 年 10 月出版）。

Eric Maxwell 的职业生涯始于 Sarah D’Angelo 是 Google Ambar Murillo 是 Google 软件工程一线，他始终被自动化核心实验室团队的高级员工 AI 和基础设施团队的员工的热情和对同行从业者的强烈 UX 研究员。 UX 研究员。共鸣所驱动。这一基础经验是他今天作为 Google 10x 技术咨询实践负责人工作的基石。

Eric 为全球顶级公司提供建议，指导他们如何通过技术、流程和文化的战略性改进来转型组织，从而更快地交付价值。他为著名的 DORA 团队贡献 Sarah Inman Daniella Villalba, Ph.D. 专业知识。在加入 Google 之前， Eric 曾在 Chef Software 工作， Sarah Inman 是 Google Daniella Villalba 是 Google 在那里他磨练了基础设施自动化 Chrome 团队的高级 UX 研究员。 Cloud 的高级 UX 研究员。和创造卓越成果的技能。她的研究专注于理解开发者。

人口统计和公司统计

DORA 研究项目已经研究高绩效、技术驱动组织的能力、实践和衡量标准超过十年。在这段时间里，我们听取了大约 45,000 名来自各种规模组织和多个不同行业的专业人士的意见。

今年，来自世界各地各行各业的近 5,000 名在职专业人士分享了他们的经验，帮助我们增进对 AI 如何改变软件开发领域以及组织在这一新范式中继续蓬勃发展的条件的理解。在本章中，我们将分享更多关于我们受访者的信息，包括他们的身份、地理位置以及他们在软件开发中的角色。

调查受访者人口统计

今年，总共有 4,867 名受访者回答了我们的调查，涵盖了各种人口统计、地理位置和行业。

个人信息

我们以开放文本回答的形式询问受访者的年龄。我们样本的中位年龄为 41 岁。

我们询问调查受访者报告他们的性别。62.8% 的受访者认定为男性，19.2% 为女性，1.1% 认定为非二元性别，0.5% 选择自我描述，2.1% 拒绝回答。

男性 62.8% 女性 19.2% 不愿透露 2.1% 非二元性别 1.1% 或者，用你自己的话 0.5%

我们根据华盛顿小组简短设置指导原则，从六个维度识别残疾。这是我们第六年询问残疾情况。

以上都不适用于我 91.5% 不愿透露 2.8% 用你自己的话 2.2% 我失明/视力有困难 1.3% 我失聪/听力困难 1.3% 我无法/难以在没有辅助的情况下行走或站立 1.0% 我无法/难以打字 1.0%

我们在调查中包含了大量 [后端开发人员] [9.3%] [其他（请注明）] [7.2%]

软件开发的 [QA或测试开发人员] [3.2%] [数据工程师] [2.9%] [产品经理] [2.8%]

众多方式。 [系统管理员] [2.6%] [数据科学家或机器学习专家] [2.4%]

代表性最高的 [站点可靠性工程师] [1.7%] [开发者体验] [1.6%]

职位是全栈 [学术研究员] [0.9%] [桌面或企业应用开发人员] [0.9%] [不愿回答] [0.9%]

经理和后端 [移动开发人员] [0.8%] [嵌入式应用或设备开发人员] [0.6%]

![图57：受访者职位分布] [[调查问题：‘以下哪项描述了您当前的工作…？’]]

团队经验 [受访者团队任期分布] [受访者团队任期分布]

在办公室工作时间分布 [在办公室工作时间分布]

编程语言 [编程语言使用情况] [编程语言使用情况] [调查问题：‘您在工作中使用的前3种编程语言是哪些？’]

![图61：编程语言使用情况] [[选择各语言的受访者比例。] [受访者百分比]]

识别其组织的员工 [8.7%] [5001 - 10,000 员工] 人数，使用九个区间。

受访者工作的组织中 [1001 - 5000 员工] [14.5%] 最常见的是拥有 [501 - 1000 员工] [8.8%] 10,001名或更多员工

(22.4%)，51至200名 [201 - 500 员工] [12.2%] 员工(16.2%)，以及 [51 - 200 员工] [16.2%] 1,001至5,000名员工(14.5%)。

人口统计和公司统计

我们要求受访者表明 [比较同意] [16.9%] 他们是否同意其应用程序或服务在过去三个月中 [有些同意] [20.9%] 积极添加了AI驱动的体验。

大致相等数量的受访者 [有些不同意] [6.1%] 同意和不同意，超过四分之一的人强烈不同意 [比较不同意] [9.4%] 他们的应用程序在此时间线内添加了AI驱动的体验。

我们要求受访者通过表明 [很大程度] [51.8%] 主要应用程序不可用对组织实现目标和服务客户能力的影响程度，来说明其应用程序对雇主的关键性。

超过一半的受访者认为 [较小程度] [6.2%] 他们应用程序的不可用会对公司产生”很大程度”的影响。

[问题：‘此应用程序/服务的不可用会产生什么程度的影响？’]

主要服务或应用程序年龄分布

我们要求参与者表明他们工作的主要应用程序或服务大约存在了多少年。我们受访者的应用程序中位年龄为8年。

大多数受访者正在开发业务应用程序，大致相等数量的人在为内部和外部受众开发。

人口统计和公司统计

今年，我们有来自100多个国家的受访者。我们最多的受访者位于美国，其次是英国和印度。

加拿大 比利时 印度尼西亚 乌克兰 巴哈马 巴拉圭

荷兰丹麦 阿拉伯联合酋长国 阿富汗 巴林 摩尔多瓦共和国

澳大利亚 挪威 保加利亚 厄瓜多尔 白俄罗斯 索马里

法国 爱尔兰 克罗地亚 萨尔瓦多 玻利维亚 斯里兰卡

葡萄牙 智利 哥斯达黎加 约旦 布基纳法索 前南斯拉夫马其顿共和国

波兰 菲律宾 尼日利亚 肯尼亚 刚果民主共和国 突尼斯

墨西哥 希腊 俄罗斯联邦 立陶宛 埃塞俄比亚 乌干达

[瑞典] [以色列] [土耳其] [马耳他] [格林纳达] [也门]

[西班牙] [新加坡] [孟加拉国] [韩国] [香港（特别行政区）] [赞比亚]

[格鲁吉亚] [奥地利] [哥斯达黎加] [塞浦路斯] [伊朗]

[意大利] [捷克共和国] [埃及] [科特迪瓦] [哈萨克斯坦]

[南非] [阿根廷] [拉脱维亚] [多米尼加共和国] [黎巴嫩]

[巴西] [哥伦比亚] [巴基斯坦] [危地马拉] [卢森堡]

颜色深度表示来自每个国家的调查受访者数量，颜色较深代表参与者数量较多。

人口统计和企业统计

访谈参与者人口统计

访谈的唯一纳入标准是参与者以某种方式参与专业软件开发。我们的筛选器不收集参与者的人口统计信息，除了确认其工作、地点和语言资格所需的信息。总共，我们访谈了78名符合这些标准的参与者。

虽然这些职责表明他们的角色通常是多方面的，但我们询问参与者如何最好地描述他们的工作，选项包括：“我是软件开发者”、“我管理软件开发基础设施”、“我管理开发软件的人员”、“我为我的组织制定关于软件开发的政策”、“我做出关于软件开发中使用的产品和服务的采购决策”、“我的工作与软件开发完全无关”、“我的工作以这里未列出的方式与软件开发相关”。

67名受访者将自己描述为主要的软件开发者，7名将自己描述为主要的软件开发者管理者，1名表示主要是软件开发基础设施的管理员，3名表示他们的工作主要以其他方式与软件开发相关。

当被问及其职责时，70名访谈参与者表示他们亲自编写或修改源代码，37名表示他们管理软件交付管道和/或开发基础设施，15名表示他们做出关于开发产品和服务的采购决策，12名表示他们定义和更新关于技术使用的组织政策，2名表示他们的工作仅以其他方式与软件开发相关。

76名受访者位于美国，1名位于墨西哥，1名位于特立尼达和多巴哥。绝大多数参与者位于美国并不令人意外，考虑到访谈者的语言流利度和时间安排限制。

方法论

调查开发

问题选择

• 已确立，以便我们可以将我们的工作与之前的努力联系起来？

• 捕获我们认为将帮助人们实现目标的能力（例如，高质量文档）？

• 帮助我们评估样本代表性的内容（例如，角色或性别）？

• 帮助我们阻断偏见路径的内容（例如，编程语言或角色）？

• 对绝大多数受访者来说可能以至少相当准确的程度回答的内容？

我们查阅文献，与DORA社区互动，进行认知访谈，开展并行定性研究，与主题专家合作，举办团队研讨会，以告知我们是否在调查中包含某个问题的决定。

调查体验

我们非常注意提高调查的可用性。我们进行认知访谈和可用性测试，以确保调查达到某些规格要点：

• 费力程度应该相当低，这是一个巨大的挑战，考虑到概念的技术性质

数据收集

本地化

世界各地的人们每年都会回应我们的调查。今年我们努力通过将调查本地化为英语、西班牙语、法语、葡萄牙语、日语和简体中文，使调查对更大的受众更加易于访问。

调查流程

今年我们有很多想问的问题，但没有足够的时间来问。我们的选择是…

收集调查回应

我们使用多个渠道进行招募。这些渠道分为两个类别：有机招募和专家小组招募。

有机招募方法是使用我们所有可用的社交手段让人们知道我们希望他们参与的调查。我们创建博客文章，使用电子邮件活动，在社交媒体上发布，并要求社区中的人们也这样做（即滚雪球抽样）。

我们使用专家小组方法来补充有机渠道。在这里，我们尝试招募在更广泛的技术社区中传统上代表性不足的人群，并努力从某些行业和组织类型中获得足够的回应。

简而言之，这是我们对招募获得一些控制权的地方——这是我们在有机方法中没有的控制权。专家小组方法还允许我们简单地确保获得足够的受访者，因为我们永远不知道有机方法是否会产生进行我们所做的分析类型所需的回应。今年我们有足够的有机回应来运行我们的分析，专家小组帮助完善了我们的参与者群体。

我们没有想要放弃任何兴趣，所以我们选择随机分配参与者到四个独立流程中的一个。四个不同流程之间有很多重叠，但每个流程都在不同的空间中深入探讨。

方法论

访谈

去年我们引入了深度半结构化访谈的使用，特别是与AI辅助和AI驱动开发范式中的新兴实践相关的方面。

今年，我们通过从2024年7月到2025年7月持续访谈开发专业人员，显著扩展了定性数据在我们研究设计中的作用。除了使用这些见解来澄清我们调查设计的发现外，我们还使用定性数据来生成新的假设，作为我们调查的一部分进行测试。

在整个过程中使用的访谈指南旨在涉及AI在软件开发领域使用的一系列基础话题，同时为探讨参与者提出的感兴趣话题提供灵活性。访谈会话设计为每次大约90分钟，并远程进行。

总共，我们访谈了78名参与者，他们通过筛选调查和电话筛选确认专业从事软件开发。所有访谈都进行了视频和音频录制。所有访谈都使用自动化软件进行转录。本报告最终发布中出现的引用在包含之前都经过了重新审视和手动转录。作者在参与者引用中添加或更改的词语用方括号（[]）表示，删除的词语用省略号（…）表示。编辑仅在需要清晰度或匿名性的情况下进行。

统计分析

本节概述了我们的分析方法，该方法深深植根于《统计反思》和《回归与其他故事》的著作中。我们可以在每个句子上附上其中一篇的脚注。我们通过一个简化的例子来演示我们整个工作流程的一些方面，以保持对核心工作流程的关注。

这是一个高级概述；我们将通过一个模拟的、简化的、理想化的例子来实现。我们将平滑或甚至跳过一些复杂性。本指南旨在让您了解适当的信任水平，以便对我们的结果进行信任并复制我们的方法。

2024年DORA报告在方法论部分探讨了我们分析背后的理论原则。今年，我们专注于实际应用：我们如何进行分析。

如果您完成这个小节，希望您能更好地了解是否信任我们，有复制这项工作的愿望，以及掌握一些新的统计技巧。

完整的分析讨论较轻或根本没有讨论，都是为了保持对核心要点的关注。

步骤1：定义我们的因果理论（DAG）

所有统计模型都包含因果假设；我们的方法是使其明确。相关性可能不意味着因果关系，但您如何思考因果关系将影响您的相关性。我们在有向无环图（DAG）中编码我们关于世界如何运作的理论。

这个DAG是我们因果景观的地图，基于先前的研究、定性工作和领域专业知识构建。通过可视化我们的假设，我们使它们透明且可辩论，这是严格科学的基石。

对于这个例子，我们极其简化的DAG假设individual_experience（个人经验）、resources（资源）和stability（稳定性）

# 加载必要的库
library(dagitty)
library(ggdag)
library(tidyverse)
library(brms)
library(lavaan)
library(tidybayes)
library(ggplot2)
library(emmeans)
library(performance)
library(semPlot)

# 在我们简化的DAG中定义因果关系
simple_dag <- dagitty('dag {
  ai_adoption [exposure]
  individual_effectiveness [outcome]
  individual_experience [adjusted]
  resources [adjusted]
  stability [adjusted]
')

是个体AI采用的常见原因[[ individual_experience -> ai_adoption; resources -> ai_adoption; ] [stability -> ai_adoption] [ai_adoption] 和 [individual_] [ ai_adoption -> individual_effectiveness] [effectiveness] . [ individual_experience -> individual_effectiveness; resources -> ]]

[从我们的因果理论 ] [[# 用特定路径系数定义模型来生成数据]]

让我们使用因果结构 [ ai_adoption_factor =~ 0.8*use + 0.7*reliance + 0.6*trust]

在我们的DAG中定义来模拟这个 [ individual_effectiveness_factor =~ 0.8*effective + ]

从已知的因果结构创建数据 [ # -- 结构模型 (基于DAG的路径) --]

为我们提供了一个 [[ ai_adoption_factor ~ 0.4*individual_experience + 0.3*resources + ]]

完美的”基本事实”。这是 [ individual_effectiveness_factor ~ 0.3*ai_adoption_factor + ][0.2*stability]

非常有用的，因为它允许 [0.3*individual_experience + 0.2*resources + 0.15*stability"]

如果我们的分析不能从这个 [[simulated_data <- simulateData(model_specification, sample.nobs = ]]

[我们的测量工具是可靠的] [ ai_adoption_factor =~ use + reliance + trust]

[使用验证性因子] [[ individual_effectiveness_factor =~ effective + productivity + ] [6] [分析 (CFA)。] [此步骤验证] [impactful + flow]]

[构念 (Kline, 2015)。] [cfa_fit <- cfa(measurement_model, data = simulated_data)] [我们通过]

[以及通过修正指标] [summary(cfa_fit, fit.measures = TRUE, standardized = TRUE)]

[没有主要压力点来评估模型。] [modificationindices(cfa_fit, sort = TRUE, minimum.value = 10)]

[lavaan 0.6-19 在34次迭代后正常结束] [[ 用户模型对数似然 (H0) -5515.401]]

方法论 [[118] [如何解释CFA] 2. 增量拟合指数 (CFI 解释： 该值

lavaan[7]输出提供了丰富的基线模型进行比较，其中没有变量 [平均标准化差异]

1. 卡方检验 (χ2)。 这是 CFI = 1.000, TLI = 1.014 [修正指标 (输出]

假设，即模型完全拟合 指导原则： 我们检查值因子载荷来检查载荷是否

数据。 > 0.90 (可接受) 和 > 0.95 在因子内部是实质性的和相似的。[9]

df = 13, P值 = 0.870 或高于理论最大值高修正指数表明潜在的为1.0。这表明完美拟合 [模型错误指定区域。]

指导原则： 我们希望得到一个相对于基线模型的非显著结果 (p > .05)。 (注意：TLI在拟合良好的模型中在这个例子中，所有指标都表明有时可能超过1.0。) [每一个拟合指数都指向]

解释： P值 [一个几乎完美拟合数据的模型。] 非常高(0.870)，意味着这正是我们在这种特定情况下我们无法拒绝零假设。 3. 绝对误差指数 希望看到的结果。因为我们检验表明我们的模型结构 (RMSEA 和 SRMR)。 这些指数直接从这个模型的规格中在统计学上无法区别于测量”拟合不良度”或模型生成数据，完美拟合确认了完美拟合。[8] 预测与实际数据之间的我们的分析方法工作正确平均误差。并且能够恢复已知结构。

警告： 这是传统的、然而，关键是要注意，正式的模型拟合统计检验。 你的RMSEA结果： 在真实世界的调查数据中然而，对于像DORA这样的 RMSEA = 0.000，90%置信区间看到如此完美的结果将是大样本，这个检验过于敏感，为[0.000, 0.023] 高度不寻常和几乎令人担忧的。几乎总是表明”拟合差”， [真实世界调查数据中] 在真实分析中如此完美的拟合即使模型非常优秀。因此，可能表明模型对于数据的我们将其作为参考，但更多 指导原则： 我们检查点估计复杂性来说过于简单，或者依赖于下面的实用指数。 < 0.08(可接受)和< 0.06(优秀)。在某些情况下，模型通过大量调整被”过度拟合”。

解释：你的RMSEA为零，整个置信区间都远低于优秀拟合的阈值。这表明几乎没有近似误差。

通过验证的测量，我们使用结构 [# 检查局部拟合的特定区域] 方程建模(SEM)对我们整个因果理论 [residuals(sem_fit, type = “standardized”)] 进行整体拟合检验。SEM的目的是 [modificationindices(sem_fit, sort. = TRUE,] 将我们的DAG所暗示的协方差结构 [minimum.value = 10)] 与我们数据中观察到的协方差结构进行比较。 [[# — 生成最小化、单色SEM路径图 —]] [semPaths(sem_fit,]

一个好的模型是理论预测与现实 [# — 核心内容 —] 密切匹配的模型。我们正在评估我们的 [what = “std”, # 重要：在路径上显示] 理论模型与观察结果的匹配程度。 [标准化系数] [whatLabels = “est”, # 显示估计值] [值(系数)]

[# — 布局和大小 —] [layout = “tree2”, # 一个清洁的层次化] [布局] [#定义我们的理论模型] [rotation = 2, # 旋转布局以获得] [更好的视觉效果(通常是从上到下)] [# 用特定路径系数定义模型以生成数据] [sizeMan = 8, # 显性变量的大小] [structural_model <- ”] [变量(方形)] [ # – 测量模型 –] [sizeLat = 10, # 潜在变量的大小] [变量(圆形)]

[ ai_adoption_factor =~ use + reliance + trust] [[edge.label.cex = 0.8, # 路径系数的字体大小]] [productivity + impactful + flow] [ individual_effectiveness_factor =~ effective + ] [[nCharNodes = 0, # 确保显示完整的变量]] [名称]

[# – 结构模型(基于DAG的路径) –] [# — 极简美学 —] [[style = “ram”, # 来自RAM规格的]] [ ai_adoption_factor ~ individual_experience + ] [清洁绘图风格] [resources + stability] [residuals = FALSE, # 隐藏残差] [方差以减少混乱] [ individual_effectiveness_factor ~ ai_adoption_] [factor + individual_experience + resources + ] [[intercepts = FALSE, # 隐藏截距以]] [stability] [保持简洁]

[”] [# — 单色主题 —] [color = “white”, # 所有形状的填充颜色] [# 将完整的SEM拟合到数据以估计] [shapes] [路径系数] [edge.color = “black”, # 所有箭头的颜色] [sem_fit <- sem(model_specification, data = ] [simulated_data)] [border.color = “black”, # 形状的边框颜色] [shapes] [# 运行完整摘要以获得拟合测量、] [[border.width = 1.5, # 边框的厚度]] [载荷和路径系数] [borders] [sem_summary <- summary(sem_fit, standardized = ] [[label.color = “black” # 箭头上文本的颜色]] [TRUE, rsquare = TRUE)] [)] [sem_summary]

方法论 [[120] [我们如何评估SEM] RMSEA： 均方根近似误差检查是否缺少大值是一个”拟合不良度”指数， [例如，没有绝对值> 2.58]] 判断模型是否”良好”需要测量平均模型误差。我们检查，这将表明特定关系被对几个指标进行整体检查。数值< 0.08(可接受)或< 0.06 我们的理论预测得很差。我们将这些分为两类： (优秀)。

修正指数： 这些”假设” 1. 全局拟合： 30,000英尺 2. 局部拟合： 检查底层机制。统计数据告诉我们模型在视图。[9] 这些指数告诉你这些诊断帮助我们在模型哪里承受最大压力。我们模型作为整体如何再现数据。内部找到特定的压力点。检查大值以诊断问题 (比如一个调查项目同时测量两个概念)，

卡方检验 (χ²)： 这是完美拟合的检验。它检验模型与数据完全拟合的零假设。

CFI & TLI： 比较拟合指数和塔克-刘易斯指数衡量我们的模型比”最坏情况”模型好多少。我们检查数值 > 0.90（可接受）或 > 0.95（优秀）。

因子载荷： 在标准化输出中，我们检查项目在各自潜在因子上的高显著载荷（理想情况下 > 0.50）。这确认我们的测量模型是强健的。

标准化残差： 这些显示模型中每个单独关系的误差。但我们避免在没有强理论依据的情况下盲目地基于它们修改模型。

良好的模型具有可接受的全局拟合、强因子载荷，且没有重大的局部应变迹象。正是这种证据的综合体让我们对模型结构有信心。

方法论

测试理论模型的含义

我们的DAG(有向无环图)还生成一组可测试的预测，称为”隐含条件独立性”。这些关注于这些变量不相关的情况。可以将此视为测试理论模型的不在场证明。如果它们成立，你就有更多理由相信它。

当我们运行 impliedConditionalIndependencies(simple_dag) 时，我们注意到： - ind ⊥ rsrc - ind ⊥ stbl
- rsrc ⊥ stbl

这些陈述是我们因果模型的核心预测，表明个人的个人经验、他们可用的资源和他们团队的稳定性彼此都是独立的。换句话说，了解团队可用资源的水平不能提供关于该团队个人经验或团队整体稳定性的任何信息。

我们首先通过检查原始模型中的协方差来非正式地检查这一点。它们都接近0，所以我们有一些相当好的证据。

我们也可以尝试更正式的测试，在结构方程模型中构建这些含义。我们通过将这些参数约束为0来做到这一点。在我们最后的模型中，我们要求模型估计这些参数，因为我们相信它们可以自由地成为任何值。现在，我们说它们是零。

# 检查输出的"协方差"部分
summary(sem_fit, standardized = TRUE)

# 正式测试隐含条件独立性
# 获取隐含条件独立性
impliedConditionalIndependencies(simple_dag)

# 我们可以检查协方差
sem_summary$pe %>% filter(op == "~~",
lhs %in% c("individual_experience",
"resources",
"stability"))

# 1. 定义一个新的约束模型字符串
constrained_model_string <- "
# -- 测量模型 --
ai_adoption_factor =~ use + reliance + trust
individual_effectiveness_factor =~ effective + 
productivity + impactful + flow

# -- 结构模型（基于DAG的路径）--
ai_adoption_factor ~ individual_experience + 
resources + stability
individual_effectiveness_factor ~ ai_adoption_
factor + individual_experience + resources + 
stability

# -- 新约束 --
# 我们现在基于DAG的含义明确强制协方差为零
individual_experience ~~ 0*resources
individual_experience ~~ 0*stability
resources ~~ 0*stability
"

# 2. 拟合约束模型
constrained_fit <- sem(constrained_model_string, 
data = simulated_data)

# 3. 比较原始模型(sem_fit)与约束模型
# 非显著的p值意味着数据支持约束
anova(sem_fit, constrained_fit)

关键结果来自anova()函数，它执行正式的卡方差异检验。这提供了原始模型(sem_fit)和更严格的模型(constrained_fit)之间的正式比较，在后者中你强制协方差为零。关键问题是：“强制这些关系为零是否显著损害了模型的拟合？”

结果表明，限制或约束这三个协方差为零并没有显著损害模型。

	Df	AIC	BIC	Chisq	Chisq diff	RMSEA	Df diff	Pr(>Chisq)
sem_fit	28	10952	11040	21.454
constrained_fit	31	15319	15420	24.980	3.5267	0.018739	3	0.3173

你的结果： 3。这是正确的，因为你强制三个协方差为零。

Chisq diff（卡方差异）： 这是当你添加约束时拟合变差程度的原始测量。

Pr(>Chisq)（P值）： 这是最重要的数字。它告诉你如果约束在总体中实际为真，看到3.5267或更大的Chisq diff的概率。

第4步：使用贝叶斯模型估计比较

在对我们DAG结构获得信心后，我们转向主要问题。我们使用DAG来识别正确的调整集，然后拟合贝叶斯模型。

设置先验

确定调整集

虽然我们的框架是因果性的，但我们将结果解释为有原则的比较，承认观察数据的局限性(Gelman et al., 2020)。比较挑战。更重要的是，不要在模型中包含哪些变量。

为了解决这个问题，我们在每个模型中为我们的预测器实现了一致的、怀疑的贝叶斯先验。[10] 这作为防止被随机性愚弄的有原则的防御。通过设置怀疑性先验(student_t(3, 0, 0.5))，[11] 我们正式建立了真实效应可能很小的信念，这降低了假阳性率。[12]

如果你的DAG(有向无环图)是正确的，包含这些变量应该能防止偏见路径影响你对AI采用对个人效果(结果)影响的估计。

方法论

识别调整集

准备数据

定义先验

拟合模型

使用LOO比较模型

带有89%可信区间的系数摘要

S类错误(近似p值)

我们相信单一指标永远不足以理解一个模型。相反，我们通过四个关键视角来评估证据，拥抱数据中的不确定性作为知识的来源。

1. 预测准确性是否提高？(LOO结果)

是的。LOO比较显示对full_model的明确偏好(elpd_diff = 10.7, se_diff = 5.2)。[13] 这是我们的第一个证据：包含ai_adoption_score创建了一个预期在新数据上做出更好预测的模型。这不仅仅是统计噪声；它是一个预测有用的变量。

2. 效应是否一致地在零的一侧？(S类错误)

AI采用系数的89%可信区间(从Q5.5到Q94.5)是[0.13, 0.26]。整个区间都远高于零。这意味着S类(符号)错误的概率很低。我们可以高度确信这种关系是正向的。

3. 我们对效应大小有很好的了解吗？(M类错误)

是的。模型提供了清晰的量级感知。我们的最佳估计是AI采用每增加一个标准差，效果就增加0.20个标准差。可信区间[0.13, 0.26]为我们提供了这种效应的合理范围。这不是一个巨大的效应，但也不是微不足道的，估计相当精确。这种清晰度通过防止我们夸大效应的重要性来帮助我们避免M类(量级)错误。

4. 这是否与我们的理论一致？

是的。我们最初的DAG假设了从AI采用到个人效果的直接、正向因果路径。我们收集的所有统计证据——从SEM(结构方程模型)的结构验证到LOO比较和最终后验估计——都与这个理论主张一致。数据支持我们开始时的故事。

综合

通过结合这四个视角，我们超越了简单的”它重要吗？“思维模式。证据汇聚表明AI采用和效果之间的关系在预测上有用、方向稳定、量级适中但清晰估计，并且理论上合理。这种方法帮助我们避免”被碰巧超过统计显著性阈值的噪声模式摆布”。[14]

第5步：诊断模型的可信度[15]

拟合模型并不是结束。我们执行一系列严格的诊断检查以确保结果可靠。[16] 这包括检查MCMC收敛性(hatR < 1.01，高ESS)，运行后验预测检查以确保模型能够重现观察到的数据，以及通过残差分析检查模型假设(Gelman et al., 2013)。这个主题本身就值得写一章。我们只是简单分享一些内容。

计算健康性：

我们首先确保模型的算法正确运行并产生稳定的估计。这是对模型计算引擎的技术检查，确保其结果可靠(例如，检查R^统计量是否小于1.01)。

预测对齐：

统计有效性：

最后，我们验证模型的核心统计假设是否得到满足。这涉及检查模型的错误(其残差)以确保我们没有违反基本原则，例如线性关系的假设。

重要的诊断检查

需要考虑的重要诊断检查。这些值得了解，因为它们适用范围广泛，从基础模型到高级模型都适用。基本类别包括：

然后我们检查模型的预测是否与我们开始使用的真实世界数据一致。我们使用模型来模拟数据，看看它是否”看起来像”我们实际观察到的数据。一个无法重现过去的模型无法被信任来解释现在。

方法论

后验预测检查

线性度

方差齐性

有影响力的观察值

共线性

残差正态性

步骤6：可视化估计效果

最后，我们将统计结果转化为直观的可视化。我们通过检查主要参数的完整后验分布来解释我们的模型，绘制条件预测（或估计边际均值）来理解比较的幅度，并在原始数据的背景下查看回归线。

对于我们的最终结果，我们报告89%可信区间，这个选择有意显示了以p值为中心的思维的任意性，并专注于后验的稳定、高密度区域（McElreath, 2020）。

AI采用对个体效率影响的三个视角

预测个体效率

AI采用与效率之间的关系

AI采用分数的后验分布

方法论

[# --- 打印校正后的图表 ---] [[# --- 打印并保存最终组合图表 ---]]

[combined_plot <- (plot_comparison + plot_] [print(“--- 工作流程完成 ---”)]

[caption = “顶部：结果尺度上的预测。底部：标准化系数的后验分布。”]

这个工作流程——从明确的理论到严格的验证、估计和诊断——旨在产生透明、可信和稳健的洞察。

我们希望在这里分享我们的过程以及《我们的研究模型及其理论》章节能让读者更好地评估我们的工作。我们也希望这能使复制成为可能，并鼓励人们利用一些有趣的统计方法。

[1. ] [McElreath, Richard. ][统计反思：使用R和STAN的贝叶斯课程 (Chapman and Hall/CRC, 2020). ][2. ] [[Gelman, Andrew, Jennifer Hill, and Aki Vehtari. 回归和社会研究分析方法的其他故事 (Cambridge University Press, ]]

[3. ] [《我们的研究模型及其理论》章节提供了这一成文理论的概述。] [4. ] [Pearl, Judea. ][因果关系][ (Cambridge University Press, 2009).]

[5. ] [《我们的研究模型及其理论》章节有更全面的概述。] [6. ] [[在进行验证性因子分析之前，我们进行探索性因子分析，以了解因子在我们用理论模型约束参数之前是如何分解的。这与其他诊断相结合，帮助我们更好地理解]]

[7. ] [Rosseel Y (2012). “lavaan: 结构方程建模的R包。][” 统计软件期刊, 48(2), 1–36.]

[8. ] [[这对更简单的模型来说是好消息。它本质上是在说，通过不自由估计某些参数，我们不会丢失太多信息。]]

[10. ][良好的建模不仅仅是关于拟合；它是关于找到拟合良好的最简单模型（奥卡姆剃刀）。你可以继续添加参数来实现]

[这一点。问题是哪个参数是合理的，以及在不丢失太多理解的情况下你能修剪多少。]

[11. ] [[我们还测试结果对各种先验的稳健性。最终，我们决定我们希望防止假阳性多于假阴性。]]

[12. ][这里有一个关于这个话题的很好的讨论：https://discourse.mc-stan.org/t/why-studentt-3-0-1-for-prior/8102] [13. ][对于交互项，我们使用更加怀疑的先验（normal(0, 0.3)），因为这些效应预期会更小。] [14. ][顶部的模型是做出最佳预测的模型。elpd_diff应该大于se_diff。当elpd_diff大于2倍se_diff时，我开始感到特别]

[16. ][探索描述性统计中的分布和模式是一个有时乏味但关键的部分，在考虑模型之前就在开始时进行]

[“理论代表一个本质的决定，它使世界看起来完全不同——在完全不同的光线下。理论是一个主要的、原始的决定，它决定什么重要，什么不重要…”]

本章概述了支撑我们分析和估计的理论模型。它是与DORA社区讨论、负责在公司实施变革的主题专家经验、文献和大量定性数据的产物。该模型不仅仅是连接的练习

这个模型对DORA来说在两个关键方面是独特的。首先，我们主要专注于AI采用的影响以及这种影响被修正的条件（AI能力(capabilities)）。这意味模型主要设计用于获得关于AI采用对我们认为对高效能重要的结果影响的准确估计

因为其中包含的理论和不可避免的随意假设指导分析。小的变化对分析有很大的影响。相关性并不意味着因果关系，但我们关于因果关系的假设确实会影响我们发现的相关性。

通常，模型试图预测能力和许多结果之间的关系。本章与方法论章节相结合，提供了结果背后的理论和分析的概述。它应该暴露我们的假设。我们希望这种理解提供足够的信息来复制、利用和评估我们的工作。

其次，模型在结构方程模型的层面进行评估，但该分析的结果仅用于建立模型的合理性。从那里，我们构建有针对性的贝叶斯模型，以生成更集中和精细的估计。

我们的研究模型及其理论

我们因果模型中的概念（表示为框）是高层次的分组。这些分组简化了可视化，不一定代表我们分析中使用的确切测量。该模型包含帮助我们理解受访者情况的上下文概念。这包括环境特征、服务特征、过程和个人特征。

AI采用是来自我们验证性因子分析的特定潜在因子，它是反思性使用、信任和依赖的复合体。然后是我们的结果，在执行摘要和AI影响章节中有更详细的解释。

我们喜欢认为这里没有概念是多余的。获得AI采用效果的良好估计需要映射该效果所在的复杂现实。

我们使用结构方程建模和有向无环图来评估这个理论模型与观察到的数据的匹配程度。当模型得到验证时，我们使用DAG来调整我们的分析以获得更好的估计。

方法论章节深入细节。在这里，我们将重点关注支撑这个模型的概念和理论。

概念

AI采用

AI采用衡量AI集成到个人工作流程和思维模式中的程度。这个概念将简单的工具使用与技术的更深层伙伴关系区分开来。

我们通过三个核心指标测量AI采用： • 信任 • 反思性使用 • 依赖

过程和实践

这个类别涵盖了一系列广泛的能力。有些是AI特定的。有些是群体层面的过程。有些是个人层面的过程。它们都代表了行动和工作方式。

与此相关的有许多构造： • 明确和沟通的AI立场 • 健康的数据生态系统 • AI可访问的内部数据 • 强大的版本控制实践 • 小批量工作 • 以用户为中心的关注 • 高质量的内部平台

这些构造中的每一个都是我们在AI能力模型章节中讨论的首创AI能力模型的一部分。

个人特征

这个类别涵盖了个人的具体特征，包括他们的角色、年龄和在团队中的任期。它还涵盖了他们工作的性质，比如他们花在AI相关任务上的时间。这些细节为理解一个人的经验以及他们如何与技术互动提供了关键背景。

这个概念通过以下观察来探索或构成： • 使用AI的时间 • 在团队中的年数 • 个人角色 • 个人年龄 • 个人任务 • AI特定任务

环境和组织特征

这些概念描述了工作发生的更广泛的结构背景。这包括公司规模和行业等稳定因素，以及资源可用性和优先级稳定性等更动态的条件。这种环境创造了要么促进要么约束技术采用和整体绩效的条件。

服务特征

这个因子衡量团队正在构建的产品或服务的成功和质量，基于帮助用户完成重要任务、保持信息安全以及延迟等性能指标等特征。

团队绩效

• 代码质量： 这捕获了个人工作的主要应用程序或服务底层代码的感知有效性和质量。

产品绩效

个人结果

• 个人有效性： 这个因子捕获了个人在工作中的自我评估有效性和成就感。

• 有价值的工作： 这衡量了个人花费时间做他们认为有价值和有意义的工作的自我评估数量。

服务特征定义主要应用程序或服务的关键特性

服务特征定义个人工作所依赖的主要应用程序或服务的关键特性。了解服务的年龄、关键性，以及是否融入了AI技术，对于理解性能指标的背景和某些技术实践的相关性至关重要。

组织绩效

这衡量组织整体成功的高层次指标，基于盈利能力、市场份额和客户满意度等特征。

软件交付绩效

这代表软件交付过程的速度和效率。详情请参阅《理解你的软件交付绩效》章节。

软件交付不稳定性

这是软件交付过程质量和可靠性的衡量指标。详情请参阅《理解你的软件交付绩效》章节。

摩擦力

这衡量摩擦力在多大程度上阻碍个人的工作。较低的摩擦力通常被认为是积极的结果。

倦怠感

这衡量与工作相关的疲惫和愤世嫉俗的感受。我们认为倦怠感是个人工作的关键障碍。

我们的研究模型及其理论

理论基础

如果我们的发现是结构，我们的分析是建构，那么理论就是基础。本节解释了我们模型中关键路径的理论基础，这些路径使我们能够准确估计AI的影响。为了保持清晰，本节重点关注模型内的高层次关系。我们将突出显示我们预期需要最多证明的路径。

虽然我们的分析依赖于特定构念之间的细粒度关系，但我们的重点仍然是总体理论连接。我们突出显示的每个路径都基于既定文献、定性工作和主题专业知识，并通过我们十年来对高绩效驱动因素的研究得到强化。

服务特征 → 软件交付绩效

服务的固有特征决定了其交付的挑战。例如，较老的服务通常承载着大量技术债务，这会产生摩擦并减慢交付速度。另一方面，服务的关键性作为组织关注和资源的强大催化剂。

非关键服务往往缺乏这种投资，导致忽视、风险累积，并对绩效产生拖累，这种拖累只有在为时已晚时才会显现。融入AI的服务引入了MLOps的许多挑战，每一个都从根本上改变了交付管道的稳定性和速度。

流程和实践 → （多重结果）

DORA的研究在过去十年中证明，人员和团队的工作方式决定了他们交付软件、有效工作、协作并最终构建优秀产品的能力。虽然今年探索的具体实践可能有所不同，开发世界现在充斥着AI，但这一基本原则仍然成立。

精心设计的流程能够： 1. 将软件吞吐量和稳定性转化为可重复的成功结果 2. 减少协调开销，让团队能够将精力投入到开发和学习上，而不是救火和抑制过程 3. 减少认知负荷并缓冲个人压力 4. 在不损害安全性、软件交付性能或可靠性的情况下，帮助想法变为现实

团队绩效 → 个人结果

功能良好的团队不仅仅交付产品；它承载着个人。协作、可靠和高效的团队增强和放大个人的绩效。缺乏这些特质的团队会抑制和约束个人，创造消耗他们的需求。通过这种方式，高绩效团队既提供了良好工作的条件，也提供了让这项工作产生影响的途径。

环境特征 → 个人结果

工作环境对个人施加影响他们如何工作以及如何体验工作的力量。我们可以通过工作需求-资源(JD-R)模型来理解这些力量，该模型将造成压力的因素（需求）与促成成功的因素（资源）分开。

较大的组织，例如，通常会创造诸如应对官僚主义和处理变化优先级等需求。行业都有独特的需求，这些需求可能改变倦怠感的普遍性和体验。

此外，某些行业可能面临外部压力，由于不确定感而产生压力源。组织在资源可用性（例如工具）和优先级稳定性方面也差异巨大。资源缺乏使工作变得困难。另外，不稳定的优先级创造了移动目标，这会抑制雄心勃勃的长期项目。

结论

我们专注于模型最关键的路径，而不是为每个链接提供详尽的证明。这是一个有意的选择，旨在为指导我们结论的核心假设提供清晰度和透明度。

通过提供这个蓝图，我们邀请您严格评估我们的发现，补充您自己的思考，并将这些因果故事应用于您面临的挑战。

这个模型是我们的地图；我们鼓励您使用它、质疑它，并帮助我们改进它。

[1. ] [韩炳哲. 爱欲的苦痛, 第1卷][ (麻省理工学院出版社, 2017), 47.]

[4. ] [Forsgren, Nicole, Jez Humble, 和 Gene Kim. ][加速：精益软件和DevOps的科学：构建和扩展高性能技术]

[6. ] [[Sculley, David, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, ]]

[和 Dan Dennison. “机器学习系统中隐藏的技术债务。” 神经信息处理系统进展, 2015. 28.]

[7. ] [我们不想引用自己的研究，但我们10多年的研究强调了这一点。][8. ] [[MacCormack, Alan, John Rusnak, 和 Carliss Y. Baldwin. “探索复杂软件设计的结构：开源的实证研究”]]

[9. ] [Hackman, J. Richard. 领导团队：为卓越表现搭建舞台 (哈佛商业出版社, 2002).]

[10. ][Bakker, Arnold B., 和 Evangelia Demerouti. “工作需求-资源模型：最新技术。” 管理心理学杂志, 2007, 22, no. 3.]

[11. ] [[Demerouti, Evangelia, Bakker, Arnold B., Nachreiner, Friedhelm, 和 Schaufeli, Wilmar B. (2001). “倦怠的工作需求-资源模型。”]]

[12. ][Forsgren, Nicole, Jez Humble, 和 Gene Kim. ][加速：精益软件和DevOps的科学：构建和扩展高性能技术]

[13. ][MacCormack, Alan, John Rusnak, 和 Carliss Y. Baldwin. “探索复杂软件设计的结构：开源的实证研究]

[14. ][Hackman, J. Richard. ][领导团队：为卓越表现搭建舞台][ (哈佛商业出版社, 2002).]

[15. ][Demerouti, Evangelia, Bakker, Arnold B., Nachreiner, Friedhelm, 和 Schaufeli, Wilmar B. (2001). “倦怠的工作需求-资源模型。”]

[16. ][Bakker, Arnold B., 和 Evangelia Demerouti. “工作需求-资源模型：最新技术。” 管理心理学杂志, 2007, 22, no. 3.]

[17. ] [[Bakker, Arnold B., 和 Evangelia Demerouti. “工作需求-资源模型：最新技术。” 管理心理学杂志, 2007, 22, no. 3.]]

[18. ][Aiken, Michael, 和 Jerald Hage. “组织疏离：比较分析。” 美国社会学评论, 1966, 31, no. 4. 497–507. 他们]

[19. ] [[Maslach, Christina, 和 Michael P. Leiter. “理解倦怠体验：最新研究及其对精神病学的意义。” 世界]]

[20. ][当进行这项调查时，美国的许多行业都在经历转型，委婉地说。][21. ] [Hobfoll, Stevan E. “资源保存：压力概念化的新尝试。” 美国心理学家, 1989, 44, no. 3. 513–524.]

[22. ][Crawford, Eean R., Jeffery A. LePine, 和 Bruce Louis Rich. “将工作需求和资源与员工参与度和倦怠联系起来：一个]

[理论和元分析回顾。” 应用心理学杂志, 2010, 95, no. 5. 834–848.]

我们的研究模型及其理论

后续步骤

加入DORA社区讨论、学习，并在改善技术驱动团队和组织影响方面进行协作。

阅读这本书：流程工程：从价值流映射到有效行动。IT革命出版社。

阅读这本书：加速：精益软件和 DevOps的科学：构建和扩展高性能技术组织。IT革命出版社。

阅读这本书：团队拓扑：为快速流动组织业务和技术团队。IT革命出版社。

阅读这本书：技能代码：在智能机器时代如何拯救人类能力。哈珀柯林斯出版社。

附录

结果评估方法

组织绩效：这是基于盈利能力、市场份额和客户满意度等特征的组织当前成功的高级衡量标准。

• 可用性和易于导航你会如何评价你的团队在以下领域的表现？

对于以下每一项绩效指标，您的组织在过去一年中相对于其目标表现如何？

• 增加的客户数量 • 主要产品的相对市场份额 • 您组织的整体性能 • 您组织的整体盈利能力 • 组织和使命目标的实现 • 运营效率 • 客户满意度 • 提供的产品或服务质量

团队绩效： 该因子衡量个人直接团队的感知有效性和协作强度。

软件交付吞吐量： 这代表软件交付过程的速度和效率。详情请参见[了解您的软件交付性能章节]。

产品性能： 该因子根据帮助用户完成重要任务、保护信息安全等特征以及延迟等性能指标，衡量团队构建的产品或服务的成功。

对于您工作的主要服务或应用程序，您如何评价其在以下领域的当前性能？

• 执行其应有的功能 • 帮助人们完成对他们重要的事情 • 延迟等性能指标

• 您的组织多久向生产环境部署一次代码或向最终用户发布？

• 您的变更前置时间是多少（即从代码提交到代码在生产环境中成功运行需要多长时间）？

• 当向生产环境的变更或向用户的发布导致服务降级（例如，导致服务受损或服务中断）并随后需要修复（例如，需要热修复、回滚、前向修复或补丁）时，通常需要多长时间来恢复服务？

软件交付不稳定性： 这捕获软件交付过程的质量和可靠性。详情请参见[了解您的软件交付性能章节]。

• 大约有多少百分比的生产变更或向用户的发布导致服务降级（例如，导致服务受损或服务中断）并随后需要修复（例如，需要热修复、回滚、前向修复或补丁）？

• 在过去六个月中，大约有多少百分比的部署不是计划内的，而是为了解决应用程序中面向用户的错误而执行的？

代码质量： 这捕获个人对其工作的主要应用程序或服务底层代码质量的评估。

• 您如何评价您工作的主要服务或应用程序底层代码的质量？

个人有效性： 该因子捕获个人自我评估的有效性和工作成就感。

• 在过去三个月中，您在工作中执行任务和职责的有效性如何？

• 在过去三个月中，您多经常能够在工作中达到高度专注或实现”心流”状态？

有价值的工作： 这衡量个人自我评估花费在他们认为有价值和有意义的工作上的时间量。

• 在过去三个月中，您大约有多少百分比的时间花在感觉有价值和有意义的工作上？

• 对工作感到冷漠或愤世嫉俗 • 因工作感到倦怠 • 在工作中感到无效 • 您对工作的感受负面影响了您的工作之外的生活

AI 采用不是关键结果，但它是整个报告中使用的核心衡量标准。以下是我们如何衡量它的更多背景信息。

AI 采用： 该因子衡量个人将 AI 整合到日常工作中的程度以及他们对此的态度。

在过去三个月中，当您在工作中遇到需要解决的问题或需要完成的任务时，您多经常使用 AI？

在过去三个月中，您对 AI 生成代码在开发工作中的输出质量有多信任？

平台： 平台是跨多个应用程序或服务共享的一组能力。公司可能有多个重叠的平台，但我们将这些整体称为”平台”。

平台团队： 平台工程团队是一群专门构建和运行平台的人员。

• 平台帮助我构建和运行可靠的应用程序和服务 • 平台的用户界面(UI)简单明了 • 平台提供我独立工作所需的工具和信息 • 平台帮助我遵循所需流程（例如，代码审查、安全签发） • 平台为我提供任务结果的清晰反馈 • 我在平台上执行的任务都有良好的自动化

平台工程团队不是必需的，我需要独立工作的信息。平台团队根据我提供的反馈采取行动。

附录

Google LLC的”AI辅助软件开发现状”根据CC BY-NC-SA 4.0许可证授权。

目录

AI辅助软件开发现状

2025

目录

执行摘要

使用本报告

DORA社区

为什么加入DORA社区？

前言

前言

快速反馈循环和软件架构

学习文化

软件交付性能

软件交付性能因素

吞吐量

不稳定性

超越软件交付性能

寻找共性

集群1：基础挑战

集群2：传统瓶颈

团队表现聚类分析

聚类4：高影响力，低频次

聚类5：稳定且有条不紊

聚类3：受流程约束

聚类4：高影响力，低频次

聚类7：和谐的高成就者

v. 2025.1 摩擦 软件交付

集群5：稳定而有条不紊

集群4：高影响力，低节奏

集群5：稳定而有条不紊

集群1：基础挑战

集群2：受流程约束

集群3：有价值的软件交付

集群6：务实的表演者

集群7：和谐的高成就者

集群7：和谐的高成就者

软件交付绩效

你的表现如何？

变更前置时间分布

部署频率分布

失败部署恢复时间分布

变更失败率分布

返工率分布

软件交付性能

将软件交付性能付诸实践

AI采用和使用

主要发现

采用情况

经验

时间

在最近工作日使用AI的时间

反射性使用

反射性AI使用

依赖性

工作中对AI的一般依赖性

任务

按任务的AI依赖性

AI采用和使用：定制化如何支持开发者参与

研究内容

AI何时成为障碍

定制化作为解决方案

团队要点

界面：人们与AI交互的地方

人们与AI交互的地方

AI使用模式

AI交互模式频率

个人生产力

对个人生产力的感知影响

受访者对AI如何影响其生产力的评估

代码质量

对代码质量的感知影响

AI采用和使用

信任

AI生成输出质量的信任

最终思考

AI 采用和使用

探索 AI 与关键成果的关系

AI 已成为软件开发的新常态

AI 采用的影响是什么？

测量 AI 采用

v. 2025.1 摩擦软件交付