[译]dora：ai 辅助软件开发状态报告
执行摘要
在 2025 年，科技领导者面临的核心问题已不再是“是否要采用 AI”，而是“如何实现其价值”。 DORA 的研究基于超过 100 小时的定性访谈和来自全球近 5,000 名技术专业人士的问卷调查。研究揭示了一个关键事实：AI 在软件开发中的主要角色是“放大器”。它会放大高效能组织的优势，也会凸显组织的缺陷。
关键结论：AI 是放大器
AI 投资的最大回报并非来自工具本身，而是来自组织底层系统的战略性建设：
高质量的内部平台
清晰的工作流
团队的协同能力
缺少这些基础，AI 只会带来局部的生产力提升，但接踵而来的混乱会吞噬这些微弱优势。
主要发现
本报告基于 2025 年 6 月 13 日至 7 月 21 日期间开展的定性研究与全球调研，包含了关于AI 辅助软件开发现状的若干关键发现，其中包括：
AI 采用已几乎普及：90% 的受访者在工作中使用 AI，超过 80% 的人认为它提高了生产力。但仍有 30% 的人表示对 AI 生成的代码几乎没有信任，这表明“验证与批判性能力”仍然关键。
AI 落地需要进行系统化建设：新的 DORA AI 能力模型识别了七个基础实践（例如明确的 AI 政策、健康的数据生态、用户中心化），它们能够放大 AI 对组织绩效的积极影响。
与去年相比，采用 AI 技术的确提升了软件交付的吞吐量，但同时也降低了交付的稳定性。这意味着团队正在加速，但底层系统尚未能应对这样的交付效率。
研究识别了七种不同的团队类型，从“和谐的高成就者”到被“遗留系统瓶颈”困住的团队，为定向改进提供了新框架。
价值流管理（VSM）：通过可视化、分析和改进从创意到客户的工作流，VSM 成为 AI 的倍增器，确保局部的效率提升，能够真正地增进产品质量和团队效能。
平台工程成为基础：90% 的组织已采用平台工程，高质量的平台成为 AI 落地的必由之路。
面向技术领导者的分析与建议
成功采用 AI，本质上是一个系统性问题，而非单纯的工具问题
我们全新的 DORA AI 能力模型认为，AI 的价值并非来自于工具本身，而是依赖于其所处的技术与文化环境。我们识别出七项基础能力（包括清晰的 AI 政策、健康的数据生态、优质的内部平台，以及以用户为中心的关注点）已被证明能够显著放大 AI 对组织效能的正向作用。
将 AI 采用视为一次组织级的转型。对基础系统的投入将会产生更大回报，这些系统能够放大 AI 的效益：你的内部平台、你的数据生态，以及团队的核心工程能力。AI 是否能真正地提升组织效能，很大程度上取决于这些基础能力。
广泛采用 AI，但保持理性怀疑
尽管大多数开发者使用 AI 来提升生产力，但他们对其输出质量仍保持健康的怀疑态度。这种“信任但验证”的做法，正是成熟采用的标志。
讨论的重点必须从“是否采用”转向“如何高效使用”。培训计划应聚焦于帮助团队学会如何批判性地引导、评估和验证 AI 生成的成果，而不仅仅是简单地鼓励使用。
七种团队
仅依靠简单指标远远不够。我们识别出了七种团队，每一种都在效能、稳定性与幸福感上呈现出独特的组合。这个模型为理解团队所面临的具体挑战、及制定有针对性的改进路径，提供了更细致的视角。
利用这些画像，可以对团队健康状况进行诊断，而不仅仅局限于软件交付性能指标。你可以识别出一个团队是否高效但高压，或者 稳定被拖慢，并据此采取正确的干预措施。
高质量的平台释放 AI 的价值
平台工程如今已接近普及（采用率达 90%）。我们的数据表明，高质量的内部平台与组织释放 AI 价值的能力之间存在直接相关性。那些将平台视为内部产品、以提升开发者体验为目标的组织，能够获得显著更高的回报。
因此，应优先考虑并投入资金支持平台工程建设。糟糕的开发者体验和割裂的工具链，可能会严重削弱你的 AI 战略成效。
系统化视角引导 AI 潜力
今年的研究证实，价值流管理（VSM）能够改善聚焦情况，推动更高水平的团队与产品效能。
VSM 作为 AI 投资的倍增器，通过在系统层面的全局视角，确保在正确的方向上应用 AI。这样，局部的生产力提升就能转化为显著的组织优势，而不是仅仅制造更多后续的混乱。
前言
许多人认为，科学的目标是用最少的原理解释尽可能多的现象，既能印证人们的直觉，又能揭示出令人惊讶的新洞见。DORA 十多年来一直在践行这一目标。
今年的研究内容让我大受鼓舞，它帮助我们更好地理解使用 AI 改进软件的方法。
Gene Kim 研究者、Vibe Coder、《Vibe Coding》《凤凰项目》《DevOps 手册》《Accelerate》共同作者
2013 年，我有幸与 Nicole Forsgren 博士和 Jez Humble 一起开展了 《DevOps 状态》研究。这项工作奠定了 DevOps Research and Assessment（DORA）的基础，并在 2018 年成为 Google Cloud 的一部分。
对于许多人来说，很难想象仅仅十多年前，软件部署还是危险且复杂的操作。那时的部署需要精心的计划与审批，通常包含数百个高风险、易出错的手动步骤。部署常会造成严重的混乱与中断，所以我们每年只敢做一次软件部署。
到了 2013 年，State of DevOps 的研究表明，每天进行多次部署并不是天方夜谭；相反，保持可靠性似乎需要小规模高频率的部署活动。更令人振奋的是：你不必身处初创公司或硅谷才能做到这一点。
你只需要：
优秀的技术实践（如自动化构建、自动化测试、自动化部署、主动的生产监测）；
能支持独立行动的架构（团队可以独立开发、测试和部署，而几乎无需协调成本）；
以及持续学习的文化。
如今，12 年过去了，作为一个技术社区，我们再次迎来了一项非凡的新技术——AI。正如十年前一样，我们又在追问：这种新技术是否真的能提升软件交付和组织能效？
2024 年，DORA 发布了一份里程碑式的报告，系统性地衡量了 AI 对软件交付能效的影响，这是同类研究中最早的一批。结果令一些人感到震惊：数据表明，AI 使用得越多，软件交付的稳定性和吞吐量反而越差——而这正是过去十年来软件工程专业人士持续努力改善的关键属性。
确实，我亲眼见过、也亲身经历过使用 AI 所带来的问题：从测试用例被悄悄删除、功能受损，到生产数据被误删。但与此同时，我也看到过 AI 在某些场景中带来巨大的改进效果。
因此，我开始把去年的这份报告及其结论称为 “DORA 2024 异常”——这是一个令人兴奋的谜题，亟待被解开。
过去一年，我与 Steve Yegge 合作。他因在 Amazon 和 Google 的 20 年经历而闻名。他回顾了贝佐斯的一份内部备忘录如何推动 Amazon 从单体软件转型为成千上万的微服务。这一转型帮助 Amazon 在 2015 年实现了每日 136,000 次部署的壮举，这一事实长期以来都在激励着 DORA 的研究。
我和 Steve 合著了即将出版的《Vibe Coding》一书，我们将“Vibe Coding” 定义为：任何不需要亲手逐字敲代码的编程形式。相反，代码通过与 AI 的迭代对话而逐渐成形。这种方式改变了我们的生活：它让我们能够更快地构建想要的东西，追求更雄心勃勃的项目，更加自主地工作，获得更多乐趣，并探索一个更为广阔的可能性空间（FAAFO!）。
当然，Steve 和我也亲眼见过 Vibe Coding 使用不当的情况：测试被删除、服务中断，甚至整个代码库被误删。但我们最终得出的结论是：造成这些问题的根本原因，并不是 AI 本身，而是我们数十年来依赖的工程直觉已经不足以应付新的工作模式了。
假设你人生最快的移动方式，就是以每小时 4 英里的速度步行。这种情况下，如果没有合适的学习和训练，去开一辆时速 50 英里的汽车，交通事故在所难免。
我们因此得出结论：当 AI 显著加速软件开发时，我们的控制系统——也就是开发者自身——也必须随之加速。换句话说，十余年的 DORA 研究很可能已经证明：整个软件开发行业的实践必须随之演进。
我们需要更快的反馈回路——比以往任何时候都更快，以适应 AI 加速的代码生成节奏。
我们需要支持独立行动的软件架构——比以往任何时候都更需要具备独立开发、测试和部署软件的能力。
我们需要学习型的氛围，特别是在 AI 具备高度不确定性且发展极为迅速的背景下。
在《Vibe Coding》一书中，Steve 和我收录了一系列案例研究，它们揭示了相关的原则和实践——以及为什么这些在 AI 时代如此至关重要。
快速反馈循环与软件架构
Adidas 全球副总裁（数字与电商技术）Fernando Cornago 负责管理近千名开发人员。在他们的生成式 AI 试点中发现：
在松耦合架构下工作、并拥有快速反馈循环的团队，生产力提升了 20% 到 30%（通过提交次数、PR 数量、整体功能交付速度等指标衡量）；
他们的快乐时间（Happy Time）（专注编程、减少行政性负担的时间）增加了 50%；
相反，那些因与 ERP 紧密耦合而反馈循环缓慢的团队，几乎没有从 AI 中获益。
学习文化
另一个案例来自 Booking.com 开发者体验团队的产品经理 Bruno Passos。Booking.com 拥有超过 3,000 名开发者。在他们的生成式 AI 创新实验中发现，开发者对“氛围编程”和代码助手的使用并不均衡——团队很快意识到缺失的关键因素是：培训。
当开发者学会如何为代码助手提供更明确的指令与更有效的上下文时，他们发现：合并请求增加了 30%，工作满意度也显著提升。
这两个案例表明了一个令人振奋的可能性：
AI 会放大工程实践的优劣。
拥有优秀工程实践的个人、团队及跨团队组织，将从 AI 中获得非凡收益；
缺乏这些实践的人，则可能遭遇严重问题——这也正是 “DORA 2024 异常” 所暗示的。
我非常感激并荣幸能与 Google 的 DORA 团队及众多专家研究者合作，他们的工作与成就让我深感敬佩。
最令我振奋的是 2025 年研究的规模：共有近 5,000 名参与者，这使我们能够开展一项实践性调查，并有望产生如同十年前那样的“灵光乍现”时刻。
我坚信，在未来数月中，我们会看到类似的重大突破。部分研究成果已体现在本报告中，但还有更多引人期待的洞见正在浮现，我也期待在未来的数月和数年里与大家分享。
我向整个 DORA 团队和所有贡献者致以衷心感谢，是他们让这项开创性的研究成为可能。
理解你的软件交付绩效：七类团队画像
软件交付效能
新软件的面世是值得庆祝的一件事，因为软件的的真正价值只能在被使用的情况下才能提现出来。软件的用户可能是客户、合作伙伴、同事、陌生人，甚至其他技术系统。
这也是我们开始理解软件在生产环境中表现如何、以及它是否满足用户需求的关键时刻。我们可以提前做很多准备，以增强软件按预期运行的信心。但只有在发布的那一刻，理论才会被证实，或者证伪。
发布新软件不仅仅是发布一个新的应用或服务。一旦应用发布，用户的反馈会推动或者强迫你进行改进。
当然，修改应用有很多理由，例如修复安全漏洞、提升运行性能、降低运营/运维成本，或者降低碳排放。这些考量的核心都是帮助用户，并促进应用的长期成功。
为了团队的长期健康，我们还必须考虑负责构建、部署、运维和支持等因素。我们需要具备合适的能力与条件，确保这些团队能够以可持续的方式持续成功。
这些考虑，加上企业对更快交付和更大成功的要求，使得 DORA 将软件交付效能作为研究的核心切入点。
软件交付效能的两大维度
DORA 的软件交付效能指标，从整体流程的高层视角进行审视，并聚焦于两个关键因素：吞吐量与不稳定性。
吞吐量（Throughput）
衡量在一段时间内，系统能有多少变更流入生产环境。吞吐量越高，说明系统能更快地交付更多变更。DORA 从三个角度来判断软件交付的吞吐量：
变更交付周期：从变更提交到版本控制系统，到部署到生产的时间。
部署频率：在特定时间段的部署次数，或两次部署的间隔时间。
部署失败的恢复速度：从部署失败要求立即干预，，到完成恢复所需的时间。
不稳定性（Instability）
衡量软件部署的质量与可靠性。部署顺利时，团队能有信心将更多变更推入生产，用户也更少遇到因部署产生的问题。
变更失败率（Change fail rate）
部署后需要立即干预的比例，通常会导致回滚或快速修复。返工率（Rework rate）
因生产环境事件而被迫进行的非计划性部署比例。
综合来看，这两个软件交付效能因素能够为团队提供其交付能力的高层次认知。对其进行持续度量，可以洞察软件交付绩效的变化趋势。无论应用或服务所依赖的技术栈、部署流程的复杂性，还是终端用户的差异，这些因素都可以作为衡量标准。
超越指标
虽然这五个指标能提供重要的快照，但它们最终只是结果。它们能告诉你“发生了什么”，却不能告诉你“为什么”。
例如低部署频率可能源于技术债务、官僚流程，或者团队倦怠；单纯的指标无法区分这些成因。
为了将效能数据与其背后的人类体验联系起来，我们进行了聚类分析。这种方法超越了孤立的数字，揭示出七类常见的团队画像，每一种都更深入地展现了效能、幸福感与环境之间的相互作用。
寻找共性
我们的聚类分析揭示了驱动软件交付效能的人为因素和系统性因素，并识别其中的共性模式。主要考虑了如下因素
团队效能：团队协作与效能的感知水平
产品效能：产品/服务在帮助用户完成任务、安全性、性能（如延迟）等方面的成功度
有价值的工作：个体自我评估的、认为有价值且有意义的工作时间比例
摩擦（Friction）：工作中被阻碍的程度，越低越好
倦怠（Burnout）：因工作而产生的疲惫与愤世嫉俗感，越低越好
软件交付不稳定性：交付过程的质量与可靠性
个人效能：个人对自身效能与成就感的自评
软件交付吞吐量：交付的速度与效率
组织、团队与个人通常的目标是：
提升团队绩效、产品绩效、吞吐量、个体效能和有价值的工作；
降低不稳定性、摩擦与倦怠。
综上，我们总结了七种截然不同的团队原型，范围从在健康、可持续环境中表现卓越的 “和谐高成就者”，到受制于技术债务的 “遗留瓶颈型”，以及陷入低效流程的 “流程受限型”。
基础性挑战（Foundational challenges）
这些团队被困在“生存模式”中，在流程、环境和成果上存在根本性缺陷，因而面临重大挑战。
约 10% 的受访者属于此类。
效能指标：与团队产出、产品交付及价值创造相关的关键效能指标持续处于低水平。
团队幸福感：数据显示，成员普遍报告存在较高程度的倦怠感，并伴随显著的摩擦与阻碍。
系统稳定性：在软件及运行环境的稳定性方面存在显著挑战。
遗留瓶颈（The legacy bottleneck）
处于这一类群的团队始终处于被动应对状态，不稳定的系统支配着他们的工作，并不断削弱团队士气。
约 11% 的受访者属于此类。
效能指标：产品效能的关键指标偏低。虽然团队能够定期交付更新，但持续存在的质量问题削弱了实际创造的价值。
团队幸福感：数据表明工作环境要求苛刻。团队成员反馈存在较高程度的摩擦与倦怠感。
系统稳定性：软件及其运行环境的稳定性面临重大且频繁的挑战，导致大量非计划性、被动应对的工作。
流程受限（Constrained by process）
这些团队就像在“跑步机”上工作。尽管他们所依赖的系统相对稳定，但低效的流程消耗了大量精力，最终导致高倦怠感与低影响力。
- 约 17% 的受访者属于此类。
- 效能指标：关键效能指标显示效率较低，所创造的客户价值或业务价值十分有限。 - 团队幸福感：数据显示，团队成员普遍反映存在较高程度的倦怠与摩擦。这表明当前的工作流程和过程正在制造一种充满挑战且不可持续的工作环境。 - 系统稳定性：团队的软件和运行环境保持稳定且可靠。这表明技术层面的不稳定性并非导致效能与幸福感挑战的主要原因。高影响，低节奏（High impact, low cadence）
这些团队能够产出高影响力的工作，其成果体现在突出的产品效能和较高的个人效能。然而，他们的交付模式节奏较低，表现为软件交付吞吐量不足且不稳定性较高。
约 7% 的受访者属于此类。
效能指标：团队持续保持顶尖水平的生产力，无论是整体效率还是产品效能指标都表现优异。
团队幸福感：数据表明团队所处环境摩擦度低，这意味着团队流程高效且协作顺畅。
系统稳定性：运行环境表现出高度的不稳定性。这种波动性对服务可靠性和长期可持续性构成了重大风险。
稳定且有条理（Stable and methodical）
这些团队就像软件世界里的稳健工匠，以审慎且可持续的节奏交付高质量、有价值的工作。
约 15% 的受访者属于此类。
效能指标：在产品质量和价值创造方面的关键效能指标持续保持积极表现。然而，团队的软件交付吞吐量处于较低分位，显示其工作节奏更加审慎从容。
团队幸福感：数据显示，成员报告的倦怠感与摩擦程度较低，这表明团队环境健康且具备可持续性。
系统稳定性：团队的软件与运行环境具有高度的稳定性与可靠性。
务实执行者（Pragmatic performers）
这些团队能够持续以令人瞩目的速度和稳定性交付工作，即便其工作环境尚未达到最佳投入状态。
约 20% 的受访者属于此类。
效能指标：软件交付的关键效能指标表现强劲，吞吐量高于平均水平且不稳定性低。团队保持着稳定的节奏，持续输出有价值的成果，并能可靠地满足预期。
团队幸福感：这一类群与绝对顶尖团队的差异主要体现在团队幸福感上。数据显示，其成员报告的倦怠感与摩擦程度处于平均水平。这表明其工作环境虽具备功能性和可持续性，但可能缺乏强有力的投入驱动因素。
系统稳定性：团队的软件与运行环境稳定且可靠，为其实现高效能提供了坚实的基础。
和谐高成就者（Harmonious high-achievers）
这正是卓越的典范——一个良性循环：稳定、低摩擦的环境使团队能够持续交付高质量工作，同时避免倦怠。
约 20% 的受访者属于此类。
效能指标：团队在多个方面均展现出积极的指标表现，包括团队幸福感、产品成果以及软件交付。
团队幸福感：工作环境呈现出低倦怠感与低摩擦度的特征。
系统稳定性：团队运行在稳定的技术基础之上，这一基础同时支撑了其工作的速度与质量。
软件交付效能分级
图 10 为 DORA 研究的一条核心原则提供了有力证据：“速度与稳定性的权衡”是一种误区。最佳表现的团队（第 6 类与第 7 类）能够在这两个维度上同时取得成功。
与之相对地，光谱的另一端则充满困境。部分团队，例如面临根本性挑战的团队（第 1 类），在吞吐量与稳定性上都表现不佳；而一些高影响但低节奏的团队（第 4 类）则清楚地表明：速度若缺乏稳定性，将是一种危险且不可持续的状态。
卓越并非遥不可及。第 6 类与第 7 类团队占整个样本的近 40%。它们是各组织可以努力追求的标杆。虽然要达到这种状态显然十分困难，但这些团队强有力地证明了：高速、高质量的软件交付并非理论上的理想，而是切实可见的现实。
如何进行比较
你也许会想知道，你的团队与今年研究中的其他参与者相比处于什么水平。需要牢记的是，这些测量是以应用或服务为单位进行的。这样的方式能够促进跨职能的共同责任感，并推动改进的落实。
此外，最有价值、最具洞察力的比较，并不是与他人横向对比，而是同一应用或服务在不同时间的纵向比较。研究的目标是持续学习与改进，而非单纯追求达到顶尖的软件交付效能。
调查数据分布（2025 DORA 调查）
变更交付周期（Lead time for changes）
少于 1 小时：9.4%
少于 1 天：15%
1 天 ~ 1 周：31.9%
1 周 ~ 1 月：28.3%
1 月 ~ 6 月：13.2%
超过 6 月：2%
部署频率（Deployment frequency）
按需（每天多次）：16.2%
每小时 ~ 每天：6.5%
每天 ~ 每周：21.9%
每周 ~ 每月：31.5%
每月 ~ 半年：20.3%
半年以上：3.6%
失败恢复时间（Failed deployment recovery time）
少于 1 小时：21.3%
少于 1 天：35.3%
1 天 ~ 1 周：28%
1 周 ~ 1 月：9.4%
1 月 ~ 6 月：4.9%
超过 6 月：1%
变更失败率（Change failure rate）
0% ~ 2%：13.7%
2% ~ 4%：16.7%
4% ~ 8%：36.2%
8% ~ 16%：26%
16% ~ 32%：19.5%
32% ~ 64%：12.5%
超过 64%：8.5%
返工率（Rework rate）
0% ~ 2%：26.5%
2% ~ 4%：52.6%
4% ~ 8%：77.3%
8% ~ 16%：92.7%
16% ~ 32%：100%
超过 64%：7.3%
实践中的应用
软件交付效能指标能够为整个交付过程提供高层次视角。随着时间的推移，这些指标的变化可以揭示团队状况是在改善还是恶化。而要改变这些指标所需的干预措施，可能因具体应用而异；不过，也可能会出现一些共性模式，例如冗长的评审与审批周期。
让我们通过一个假设案例来说明：在一次常规回顾会议中，团队讨论了他们的软件交付效能。他们注意到，当前应用的变更交付前置时间开始变长。
他们可能是通过观察仪表板发现的这一趋势，但同样也可能只是凭借日常工作中的直观感受。对于这些指标而言，并不总是需要精确的量化，团队通常会对其随时间的变化有感知。
团队希望扭转这一趋势，但要做到这一点，他们需要理解背后的原因。这时，额外的数据可能会提供帮助。团队可能会查看开发系统中的数据——例如代码库或分析工具——并发现代码评审耗时变长。
团队一致认为这是需要改进的重点，并讨论了潜在的干预措施，包括：
将代码评审重新设为日常工作的优先事项；
引导提交更小的变更，提升评审效率。
在明确了这些具体改进步骤后，他们约定一个月后再次检查变更审批耗时以及其他软件交付效能指标，以检验改进进展。
无论你的团队属于“流程受限型”还是“稳健工匠型”，目标都是一致的：培育持续改进的思维方式，推动团队迈向更加和谐且高成就的状态。
AI 的落地和使用
我们持续关注软件开发行业中 AI 落地趋势，可以看到，AI 在软件开发中的版图正在日益扩张。在这一快速演进的领域，我们努力提供基于证据的指导，帮助软件开发社区更好地应对这些变化。今年的《AI 辅助软件开发现状》报告，正是迄今为止我们对 AI 辅助开发所做的最深入分析。
总体而言，我们的研究结果显示，软件开发者在广泛采用 AI 的同时，也在多样化任务中对其形成了深度依赖。这一趋势带来了显著的感知收益，既体现在个人生产力的提升，也体现在代码质量的改善上。
AI 的普及
今年 90% 的调查受访者在工作中使用 AI，比去年的数据增加了 14.1%；
这一惊人比例表明，AI 在软件开发中已经成为常态；
仅有 10% 的受访者表示他们不使用 AI。
“我认为在过去一年左右的时间里，人们逐渐意识到，生成式 AI 已经发展到真正能在许多方面发挥作用的阶段。既然这一点已经成为共识，那么几乎所有应用都能在某种程度上从生成式 AI 中获益。 因此，我觉得大家都有很强的动力去启用新的功能，以此在某些环节节省成本，减少创造内容所需的时间。没有人想被落下……我确实认为，随着时间的推移，生成式 AI 会越来越深入地融入到一切之中。如果你没有以某种方式使用生成式 AI，那么，是的，我觉得未来要跟上节奏会变得非常困难。”
使用经验
我们的受访者报告了各自使用 AI 工具的经验，中位数为 16 个月，平均值为 16.22 个月。作为参考，ChatGPT 于 2022 年 11 月发布，比本次调研早了大概 31 个月。
在我们的数据中，既包含了早期采用者，也包含了后期采用者。我们还观察到，在 2023 年底至 2024 年中期，AI 采用出现了一波明显的增长浪潮。
时间投入
在我们的样本中，AI 使用者在最近一个工作日中与 AI 交互的时长也存在差异。调研结果显示，受访者在最近一个工作日里与 AI 交互的中位数为 2 小时，大约占 8 小时工作日的四分之一。
下意识使用（Reflexive use）
尽管在我们的样本中，AI 使用已接近普及，但“下意识使用”——即在遇到问题时默认依赖 AI——却并不常见。
在所有 AI 使用者中，仅有 7% 表示在面对问题或任务时“总是”使用 AI，而 39% 表示只会“有时”求助于 AI。
不过，仍有 60% 的 AI 使用者在遇到问题或任务时，会在“约一半时间或更多”情况下使用 AI。这表明，AI 已经成为软件开发过程中的高频使用工具。
在过去的 18 个月里，Sabre 通过使用分析与满意度调查，积极跟踪了生成式 AI 助手的采用情况。采用率已飙升至 74%，覆盖了不同资历和经验层次的开发者，且在核心开发任务中使用 AI 的比例显著增加。 这种使用率的提升与更高的用户满意度呈正相关。值得注意的是，86% 的用户表示生产力有所提升。满意度与节省时间的持续上升趋势表明，随着用户熟练度的提高，生成式 AI 工具带来的效益也在不断增长。 我们的分析还发现，对于最新的生成式 AI 功能（例如 Agent 模式）的采用较为缓慢，只有 25% 的用户在使用。对此，Sabre 正在加强培训项目，并推动同伴间的知识分享，以提升使用积极性，并确保团队能够熟练掌握 AI 工具。 —— Jacek Ostrowski，Sabre 平台工程副总裁
依赖情况
除了高频使用之外，我们还发现，开发专业人士在工作中对 AI 工具的依赖程度也非常高。在我们的样本中，仅有 5% 的 AI 使用者表示在工作中“完全不依赖”AI，而有 65% 的人表示依赖程度达到 “中等程度”（37%）、“高度依赖”（20%）或“极度依赖”（8%）。
任务
与我们在 2024 年 DORA 报告中的发现一致，今年调研的受访者在 AI 工具的首要使用场景仍然是编写新代码，其中 71% 的代码编写者会借助 AI 来完成这项工作。
在工作内容涉及相关任务的受访者中，大多数人也会使用 AI 来进行：
文献综述（68%）
修改现有代码（66%）
校对（66%）
图像创建或编辑（66%）
相对较少的使用场景包括：
需求分析（49%）
内部沟通（48%）
日程管理（25%）
定制化如何吸引开发者
研究内容
随着 AI 助手在开发工作中越来越普及，加州大学伯克利分校的一支研究生团队研究了学生开发者在实践中如何使用 AI 驱动的集成开发环境（IDE）。研究团队利用眼动追踪数据和访谈，观察了具有 1 到 5 年经验的 Python 开发者如何完成两项短任务：其一涉及一个陌生的库，其二需要解释一个晦涩难懂的函数。
通过应用这项研究的洞见，不同经验水平的开发者都可以探索出更符合自身需求的 AI 编程助手使用方式。
定制化解决方案
为了减少摩擦并更好地支持专注工作，开发者和团队可以对 AI 工具进行定制化。
目前，大多数 IDE 都提供以下功能：
切换行内建议的开关；
启用“仅按需”模式；
调整建议的风格和结构。
此外，代码库级的配置文件与关联文档也能帮助 AI 助手遵循既定规范。通过尝试这些设置，团队可以让 AI 的行为更契合不同任务的认知需求，从而减少干扰，提升 AI 助手的实际价值。
当 AI 成为障碍
虽然 AI 编程助手的设计初衷是节省时间、减少工作量，但加州大学伯克利分校的一项研究发现，它们在某些任务中也可能带来麻烦。
例如，在处理编写样板代码或安装依赖包等机械性任务时，学生开发者非常乐于使用 AI；但在需要更深层次理解的任务中（如解释复杂代码），他们则大多忽略了 AI 的建议。
眼动追踪数据显示，在解释性任务中，开发者对 AI 聊天的视觉关注度不足 1%，而在机械性任务中，这一比例接近 19%。研究中的学生开发者往往选择手动完成任务，以保持对过程的控制和理解，甚至会忽略掉那些准确且能够节省时间的 AI 建议。
启示
要最大化 AI 编程助手的价值，开发者和团队应当投入精力进行定制化。研究表明，AI 在解释性任务中可能会增加认知负担，从而造成干扰，尤其是在开发者需要理解不熟悉代码的时候。
关键在于：让 AI 的支持方式与任务性质以及开发者的偏好相匹配。通过调整配置，你可以把 AI 从一个可能带来摩擦的因素，转变为提升效率、改善体验的有力工具。
交互界面
最常见的 AI 交互方式是对话式聊天机器人，其次是嵌入在 IDE 中的 AI。
受访者报告称，他们与集成在自动化工具链及其他开发工具和平台中的 AI 交互频率相对较低，但这可能是由于这些 AI 工具对用户来说不够直观和可见所导致的。
AI 使用模式
除了询问受访者在何处与 AI 交互、以及出于何种目的外，我们还调查了他们在以下几种“模式”下与 AI 交互的频率：
对话模式（chat）：任何逐轮的文本交互形式；
预测文本模式（predictive text）：如 Tab 补全代码建议；
协作模式（collaborative）：使用 AI 对整个代码库进行更广泛的修改；
代理模式（agent）：允许 AI 在相对无人监督的情况下操作，并在没有直接人工审查的前提下进行修改。
与受访者最常使用聊天机器人和 IDE 内嵌 AI 的情况相对应，文本对话模式与预测文本模式是最常见的交互方式。
而 AI 代理模式的使用最少，超过 61% 的受访者表示他们“从未”以代理模式与 AI 工具交互。这一使用模式反映了不同 AI 模式的成熟度差异：代理型 AI 的采用率较低，与其相较于更成熟的对话模式和预测文本功能出现时间更晚相一致。
个人生产力
今年的调查中，超过 80% 的受访者表示他们感受到 AI 提升了生产力。尽管有超过 40% 的人认为生产力仅“略有提升”，但不到 10% 的受访者认为 AI 对他们的生产力造成了负面影响。
代码质量
除了在生产力方面感受到积极影响外，大多数（59%）受访者也认为 AI 对他们的代码质量产生了正向作用。其中 31% 认为提升仅为“轻微”，另有 30% 认为既没有正面也没有负面影响。相比之下，仅 10% 的受访者认为 AI 使用对代码质量带来了负面影响。
“我觉得在某些方面，AI 写出的代码有时比我自己写得更好，主要原因是我感觉它的训练确实非常到位。正如我之前提到的：代码是很二元的，要么能跑，要么不能跑。而 AI 写出的代码通常已经足够满足我的需求。 而且它经常会遵循一些我可能一时忘记、或者懒得回头去重构的代码规范。所以我觉得它能让代码整体上更连贯一致。”
信任问题
与 2024 年 DORA 报告相似，今年的研究结果揭示了开发者在面对 AI 生成结果的信任度时呈现出一种更为细腻的分布格局。大多数受访者（70%）在某种程度上对其质量表示信任，其中近四分之一（24%）表示“非常信任”或“高度信任”。与此同时，30% 的受访者态度更为谨慎，其中 23% 表示“略微信任”，还有 7% 表示“完全不信任”。
这些数据突显了一个关键洞见：高水平的 AI 采用率与感知收益，可以与一种审慎而细致的信任态度并存。我们的研究表明，AI 输出的实用性并不以“绝对信任”为前提。
这种模式与既有行为一致：在访谈中，开发者将其类比为他们对 Stack Overflow 等常用资源所抱有的理性怀疑——信息会被使用，但并非始终被完全信任。
AI 在软件开发中的可信度仍然是一个重要的讨论与研究议题。我们此前已提出五种策略来帮助培养开发者对 AI 的信任。然而，数据同时也表明，开发者可能已经在工作中主动考虑并应对了 AI 的这一局限性。
70% 的开发者对 AI 生成的输出表示某种程度的信任；
24% 的人表示“非常信任”或“比较信任”；
30% 的人仅表示“一点点信任”或“完全不信任”。
研究表明：
高采纳率和积极反馈可以与“有限信任”并存；
开发者往往像使用 Stack Overflow 一样使用 AI：会参考，但不会盲目信任；
信任不是前提，AI 的产出仍然可以被有效利用。
我们此前提出了五种策略来增强开发者对 AI 的信任（见 DORA 专题研究），但本次调查显示，开发者已经在实践中自然适应了这一限制。
总结
综合来看，这些研究结果表明，AI 在软件开发中的使用已几乎无处不在。AI 被广泛应用于各类开发任务，成为受访者工作流程的一部分，并在遇到问题时被频繁求助。
尽管受访者仍然对 AI 生成代码的可信度存在担忧，但他们普遍认可 AI 在 个人生产力和代码质量方面带来的积极影响。因此，尽管 AI 并不完美，但它已迅速成为大多数软件开发组织的标准实践。
在去年的研究中，我们发现竞争压力是推动 AI 在软件开发中被采用的关键因素之一。许多受访者将其描述为一种“害怕错过”或“被同行与竞争对手甩开”的心态。然而，将这种社会压力视为采纳新技术的合理动机，本身仍具争议。
虽然我们的数据展示了 AI 采用的诸多积极成果，但我们同样记录了明显的负面影响。因此，我们提醒读者：不要将 AI 的普及简单解读为“所有组织都应当立刻全面采用 AI，而不考虑自身具体需求”。相反，我们认为，这些发现传递的强烈信号是：所有参与软件开发的人——无论是个人开发者、团队管理者，还是高管领导——都应当认真思考 AI 是否、在何处以及如何应用于他们的工作。
采取保守还是开放的路径，取决于具体情境。但 AI 的广泛普及已经表明，组织再也无法忽视其使用所带来的影响。
我们理解，关于 AI 应在多大程度上融入软件开发的决策十分艰难，而最佳决策应基于数据驱动。因此，在本报告关于 DORA 新 AI 能力模型的章节中，我们深入探讨了组织内部的文化能力与技术能力如何影响 AI 采用的成效，并提供了见解，帮助那些选择将 AI 融入流程的组织实现成功落地。
探索 AI 与关键成果的关系
AI 是软件开发中的新常态
仅仅三年时间，AI 的采用与使用就经历了显著的转变。在 2022 年，开发者使用 AI 还会令人惊讶，但如今已有 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%。或许没有什么能比人才市场的需求更清晰地反映这一新现实：美国涉及生成式 AI 技能的招聘信息仅在 2023 年就增长了 323%。
AI 的影响
在这股快速普及的浪潮下，组织必须理解：是否也出现了同样迅速的收益增长。广泛采用并不自动等同于广泛价值。我们需要承认，AI 的采用可能充满混乱，驱动力既可能来自炒作和害怕错过（FOMO），也可能来自深思熟虑的战略。
正如我们在 2024 年 DORA 报告中得出的结论，AI 的应用同样可能受到组织系统的制约和限制。报告发现，AI 确实带来了许多有前景的结果，但同时也增加了软件交付的不稳定性，并降低了交付吞吐量。同一份研究估算：AI 采用率每增加 25%，软件交付吞吐量下降约 1.5%，而交付不稳定性上升约 7.2%。
我们并非唯一注意到这些复杂性的研究。例如，Model Evaluation & Threat Research (METR) 的一项研究显示了感知与现实之间的鲜明错位：那些因 AI 工具导致效率降低 19% 的开发者，却仍然相信这些工具让他们的效率提高了 20%。类似地，其他第三方研究也开始指出，AI 可能对认知与幸福感产生影响，进一步强调了作为一个行业，我们仍处在理解 AI 采用真实效应的早期阶段。
然而，当开发者被要求从 SPACE 框架的各个维度来评价 AI 时，他们报告的多为积极影响，负面影响相对较少。而在本报告关于 AI 采用与使用的章节中，大多数受访者也表示，AI 对他们的代码质量和生产力产生了正面作用。
这些相互矛盾的信号告诉我们：还需要更多基于证据的研究来评估 AI 对产品开发的真实影响，特别是在当前 AI 投资与采用规模空前扩大的背景下。我们认为，开发者社区和雇主应当设定切合实际的期望，而清晰认识 AI 的真实影响，是负责任地管理这些期望的第一步。
AI 采用的度量
为了理解AI 采用汇兑关键结果产生什么影响，我们首先需要能够对 AI 的采用情况进行度量
在今年的研究中，我们设计了 AI 采用度的测量方法，并遵循了一些简单的原则：
包容性（Inclusive）：衡量方法不应偏向任何特定角色（也不应系统性地为非 AI 采用因素生成更高或更低的分数）。例如，软件开发者不应仅仅因为使用 AI 编写代码就自动获得更高分数。该指标需要能够捕捉一种对 AI 的总体取向，而不依赖于个人的具体岗位职能，除了对 AI 的有意义使用之外不受其他因素影响。
数据驱动（Data-informed）：一如既往，我们让数据先行，即使我们有强烈的假设。这个过程的一部分包括进行探索性因子分析（exploratory factor analysis），以减少受到既有信念的约束。
理论驱动（Theory-driven）：我们对 AI 采用的概念化与衡量方式，应当与业界普遍接受的 AI 使用理解以及我们的定性研究成果相一致。
最终结果由三个高度相关的变量构成：
依赖度（Reliance）：在过去三个月中，你在工作中对 AI 的依赖程度有多高？
信任度（Trust）：在过去三个月中，你在工作中对 AI 生成结果的质量有多大的信任？
下意识使用（Reflexive use）：在过去三个月中，当你在工作中遇到问题或需要完成任务时，你有多频繁会使用 AI？
分析发现，这三个调研项目的回答方式高度相似，这证明了其中可能性：存在一个单一的潜在因素，同时在驱动这三个变量的共同变化。
我们认为，这一因子反映了三个在概念上紧密交织的维度：
行为维度（use）：实际使用情况；
依赖维度（reliance）：AI 融入个人工作流程的深度；
态度维度（trust）：对 AI 的信任程度。
这一结论与现有文献及我们的定性研究结果高度一致。
这种关系可能是由一个反馈回路支撑的：信任是使用的前提，但使用又是建立信任的机制。这就形成了一个强有力的反馈循环：当用户开始对一个系统产生足够的信任并愿意使用时，更多的使用会进一步增强依赖与信任，从而形成一个持续的采用循环。
事实上，这种循环性使得将这些变量结合起来成为构建因子的理想选择，尤其是考虑到我们的调查只是一个静态快照，而不是一个动态过程的连续记录。AI 的采用本质上是一个涉及态度、意图与行动的心理过程。
连接度量和结果
在建立了 AI 采用度的衡量方式之后，我们便能够判断：当比较不同水平的 AI 采用时，研究结果是否会有所差异。
其基本形式为：当比较两个在特征、环境和流程上相同的人时，AI 采用程度更高的那个人，在平均水平上会在某个结果上多出或少出 {数值}。
当然，几乎没有任何一个个体、团队或组织是“平均值”的代表。但通过探索这些平均效应，我们能够挖掘出一些普遍模式。这些模式还能为更细致的分析提供背景，特别是在 DORA AI 能力模型章节中，我们进一步探讨了在哪些条件下 AI 采用最有益（或最无益）。
每年，我们都会尽力挑选和构建那些最能代表本报告读者目标的结果指标。简而言之，我们希望用技术专业人士最关心的方式来评估实践。
以下是我们今年研究的结果指标：
组织效能：这是一个高层次的衡量指标，用于评估组织的整体成功程度，考量的特征包括：盈利能力、市场份额以及客户满意度。
团队效能：该因素用于衡量个体所在直属团队的感知有效性与协作能力。
产品效能：该因素用于衡量团队所构建产品或服务的成功度与质量，评估维度包括：是否能帮助用户完成重要任务、是否保障信息安全，以及诸如延迟等性能指标。
软件交付吞吐量：该指标代表软件交付过程的速度与效率。更多细节可参见《理解软件交付效能》章节。
软件交付不稳定性：该指标用于衡量软件交付过程的质量与可靠性。更多细节可参见《理解软件交付效能》章节。
代码质量：该指标反映个体对其主要负责的应用或服务中底层代码质量的主观评价。
个人效能：该因素反映个体对自身在工作中的有效性及成就感的自我评估。
有价值的工作：该指标衡量个体自我评估中，自己在工作中投入于有价值且值得的任务所占用的时间比例。
摩擦感：该指标衡量妨碍个体完成工作的阻碍程度。通常而言，摩擦越少被视为越积极的结果。
倦怠感：该指标用于衡量个体在工作中感受到的精疲力竭与玩世不恭（消极态度）程度。通常来说，较低的倦怠感被视为积极结果。
年度结果
我们估算：在特征、环境和流程相同的两个人之间，AI 采用程度更高的人通常会报告如下结果：
更高水平的个人效能
更高水平的软件交付不稳定性
更高水平的组织效能
更高比例的时间用于有价值的工作
更高水平的代码质量
更高水平的产品效能
更高水平的软件交付吞吐量
更高水平的团队效能
相似水平的倦怠感
相似水平的摩擦感
本章节接下来的部分将尝试对这一结果模式进行解读，并假设其背后的成因。
在构建这些假设时，我们将参考既有文献、我们的定性研究、领域专家意见，以及我们从 DORA 社区中获得的洞见。更多细节可参见《方法论》章节。
自 2024 年以来持续保持的正向关联
自去年的报告以来，有若干成果继续与 AI 采用保持正向关联。具体包括：
更高水平的个人效能
更高水平的代码质量
更高水平的团队效能
更高水平的组织效能
这些持续的正向关系已经成为一种“熟悉的叙事”。在这里，我们将其视作基线而非新发现的亮点，因为它们与去年的结论保持一致，并与许多从业者的实际体验相符。其背后可能存在无数潜在机制，其中许多机制可能是特定于某个组织、团队、情境或环境的。
AI 能够以多种方式帮助个人：处理样板代码与重复性脚手架工作、快速提供可行选项、输出与问题高度相关的结果、总结与综合大量分散的信息，甚至完成诸如设计、规划与分析等高阶任务。
这些个人层面的提升往往能够累积并叠加——当小的胜利在多人、多轮迭代中不断放大时，最终会惠及整个团队与组织。
AI 始终嵌套在更大的系统之中
有几个结果依然呈现出不太理想的模式：
与 摩擦感没有显著关系
与 倦怠感没有显著关系
AI 与软件交付不稳定性的增加相关联
我们认为，这些顽固效应更多与个体所处的系统、流程和文化有关。目前，AI 的使用主要集中在“键盘端”，这可以解释为什么代码质量与生产力受益，但摩擦感、倦怠感与不稳定性却没有改善。这些因素超出了个体的掌控范围，更直接地与组织结构与运作方式相连。
我们把这些结果视为社会技术系统（sociotechnical system）的属性与后果（涵盖流程与文化）。尽管 AI 带来了种种好处，但 摩擦依旧未受影响，倦怠感保持不变，而交付不稳定性反而上升——除非周边系统与文化也随之发生改变。
摩擦感
尽管自动化重复性任务的工具似乎能带来更顺畅的工作流程，但我们的数据表明，职场摩擦远比完成机械化任务复杂得多。正如我们指出的，一些研究表明，摩擦往往是来自个体之外的流程产物。
例如，2019 年微软就识别了阻碍“拥有美好工作日”的流程问题：
基础设施问题，如“系统和工具不稳定、运行缓慢”；
文档过时；
行政性工作负担；
时间压力；
重复性任务。
他们的结论之一是，管理者应当“优先考虑并着力改进流程与工具”。
因此，即便 AI 在个人工作层面减少了摩擦（例如编写代码），低效的流程仍可能抵消这些益处，尤其是在组织尚未准备好应对更大变更量以及人们尝试新型工作方式的情况下。
举例来说，如果变更量增加，而相应的防护机制、角色分工与黄金路径没有同步演进，就会导致验证与协调成本上升。
不过，我们并不认为摩擦的故事完全是系统性问题。对于个体而言，摩擦并不会真正消失，而是发生了转移：从手动劳动转向了决策与验证，表现形式可能包括提示迭代、结果审查，以及对“看似正确”的代码进行评估。
最终的结果是：即便 AI 能够让输出更有影响力、自动化掉某些重复任务，但总体摩擦量可能并未明显减少。
Exabeam “我们发现，AI 在增强优秀工程师技能时最为高效。通过自动化繁琐、重复的任务，AI 让我们的开发者能够把精力集中在战略性问题解决与创新上。”
倦怠感
可能有人会认为，提升生产力的工具会减轻倦怠，但我们的研究发现，单纯的技术解决方案无法减少倦怠感。倦怠更可能受到个体所处工作文化的深刻影响。
多年来，我们在自己的数据中也注意到这一点。倦怠与领导力、优先级稳定性以及生成型文化有着密切联系。2017 年的一项元分析发现了倦怠的一些常见前因：工作支持不足、缺乏职场公正、回报偏低以及工作不安全感。即便 AI 能在某种程度上减少倦怠，这种效果也可能会被文化的巨大影响所掩盖。
此外，我们的定性研究中出现了一些清晰信号，与有关工作强化（work intensification）的文献相吻合：AI 辅助开发工具带来的产能提升感知，在某些组织中反而引发了对更高产出的期待。在这些情况下，即使 AI 提升了个体效能，需求与资源之间的平衡依旧没有改变。
“AI 确实改变了软件开发，我从今年开始就明显感受到了这种变化。去年其实还没有这种感觉。但我认为，随着 MCP（模型上下文协议服务器） 的创新出现，以及能够直接与模型进行协作式编程，这确实在很多方面带来了改变——包括功能发布的方式、功能上线的时间表，以及在一定时间内可以完成的工作量。 现在，相关方期待产品中能更快完成更多工作。因此，截止日期与项目周期被进一步压缩，这确实改变了我的工作方式。这让我有些担忧，因为我觉得领导层——尤其是产品领导层——在交付产品方面给出了相当苛刻的期限。”
软件交付不稳定性
如果说 11 年的 DORA 研究教会了我们什么，那就是：一个组织的技术实践与流程与软件交付效能息息相关。缺乏这些基础能力，AI 带来的任何收益都可能被彻底抵消。
例如，一个已经采用 AI 的团队，如果没有建立起稳健的软件交付流水线，并且过度依赖其他团队完成交付，那么它的交付过程还是可能不稳定的。我们的数据甚至显示：采用 AI 不仅未能解决不稳定性，反而目前与不稳定性增加相关联。
这也许意味着，这些基础技术能力比以往更为关键，要求更严格地遵循相关原则。然而，也可能证据正指向一个更具颠覆性的结论：这些技术能力和度量标准已经不再足够，它们必须为 AI 时代而演进、被替代或被补充。
有人可能会辩称：不稳定性是可以接受的权衡，因为 AI 辅助开发带来的吞吐量提升足以弥补损失。其逻辑是，AI 辅助交付的速度与规模能够削弱不稳定带来的危害——例如通过极快的缺陷修复与更新，将对终端用户的负面影响降到最低。
然而，当我们超越单纯的软件交付指标来观察时，这一论点并不成立。为了验证这种说法，我们尝试用 AI 来解决历史上曾经发生的因为交付不稳定而造成的问题。
结果发现，并没有这种调节作用。相反，不稳定性依然对关键结果造成严重损害，例如产品效能与倦怠感，这最终可能抵消吞吐量提升所带来的任何收益。
一些变化
相较于 2024 年，已经有了一些变化
AI 与“有价值工作时间”的关系 已从负面转为正面
AI 与软件交付吞吐量的关系 已从负面转为正面
AI 与产品效能的关系 已从中性转为正面
这些变化表明：个人、团队与工具都在发生适应。个体有了更多时间去学习如何使用 AI，组织和团队也有了一年的时间去调整配置，而 AI 公司则又经历了一年的迭代，开发出更好的模型与用户体验。
从工具本身开始来看：在众多基准测试中，AI 工具正在变得更强大。过去，对预训练模型进行基于自身数据的微调是一个复杂任务，需要深厚的机器学习专业知识；而如今，许多平台已经构建了简化的工作流来完成这一过程。
云服务商也开发出了更加健壮的工具，使得用户能够将自己的私有数据源（如客户数据库、内部文档、代码库）安全地接入微调过程，这些数据也不会暴露在公共互联网上或提供给基础模型供应商。
与此同时，组织对 AI 的使用方式也在不断演进，这可能为 AI 在一些关键任务中提供了额外的能力与护栏，例如代码评审、测试生成、调试、代码重构、文档撰写以及错误修复。
个体与团队也可能逐渐明白了 AI 在何处、何时、以及如何最有用。例如，人们可能正在学习如何将枯燥、重复、机械的任务交给 AI，从而把更多时间投入到问题解决、设计和创造性工作中。这也解释了为什么今年的研究发现中，AI 采用开始与更高比例的有价值工作时间相关联，而这与去年的结论形成了反转。
确实，如果 AI 处理了编码过程中的一些基础性工作（如脚手架、样板代码、常规转换），开发者就能腾出更多时间专注于代码部署，从而提升软件交付吞吐量，并最终改善产品效能。
我们也可能正在观察到：组织正在逐渐适应，为 AI 创造出更有利的环境，这不仅能让个人与团队从 AI 中获得更大收益，还能让这些收益扩展到团队、产品和整个组织。
在《DORA AI 能力模型》与《AI 镜像》章节中，我们探讨了一些可能的系统性约束，它们或许可以帮助解释这一现象。
当然，一个合理的问题是：为什么有些结果受适应性影响而改善了，而另一些却没有（例如软件交付不稳定性）？ 我们的调查数据并不能直接回答这个问题。更可能的解释是：不同团队在努力的侧重点、某些约束条件的显著性以及问题本身的挑战程度上存在差异。这些差异很可能导致了不同的学习曲线。
如果 AI 能帮我完成一件原本要花两小时以上的事情，而且只需要 30 分钟，那它就是好的。因为现在我多出了那些时间，可以去做别的事情，可以去尝试不同的事情，可以完成更多的工作。 而且，它也能帮助你在职业上更快成长，对吧？因为你也在以更快的速度学习新东西。
结论
在不同层面上，AI 正在对大多数结果产生积极影响，但也存在一些明显的例外：它与倦怠感和摩擦感没有直接关系，并且依然与软件交付稳定性下降相关。
对比 2025 年与去年的研究结果，可以看出：语言模型、工具与工作流正在不断演进，同时与它们交互的人和组织系统也在适应变化。人们已经找到方法，将精力转向他们认为更有价值的工作；而我们也开始看到，AI 的采用逐步推动了更高的交付吞吐量和更好的产品效能。
然而需要注意的是，AI 并没有让技术从业者的一切都变得更好。一些问题还是亟待解决——包括不稳定性、摩擦和倦怠——并不完全是工具本身的失败，而更像是系统应变不足。这些结果的持续存在，与其说是 AI 的失败，不如说是组织系统的负担，以及部分系统未能及时适应新范式的体现。
我们相信，AI 的价值不会单靠技术本身被释放，而是通过重新构想它所处的工作系统才能实现。对此，我们在《DORA AI 能力模型》与《AI 镜像》章节中有进一步的探讨。
AI 对职业开发者的社会认知影响
DORA 的核心关注点始终是从事软件开发的人。开发者所处的工作环境对他们的工作体验有着至关重要的影响。随着组织重新调整优先事项、领导者寻找新的创新方式，以及 AI 越来越深入地融入工作流，AI 正在重塑这种环境。它不仅有潜力改变开发者所从事的工作类型，还能改变他们的工作重点。
历史经验表明，技术进步会带来人们心理模型的重大变化。在 Uber 出现之前，付钱给陌生人搭乘他们的私家车几乎是难以想象的。但如今，仅在美国和加拿大，就有大约 3100 万人每月至少使用一次该服务。
职业开发者正处在这场 AI 驱动转型的前沿，我们的目标是捕捉他们在这一过程中发工作体验转变。
我们选择研究六个社会认知构念，以探讨开发者如何看待自己与工作的关系：
真实的自豪感（Authentic pride）
工作的意义（Meaning of work）
认知需求（Need for cognition）
存在感连接（Existential connection）
心理所有权（Psychological ownership）
技能优先级重排（Skill reprioritization）
真实的自豪感（Authentic pride）
自豪是一种基本情绪。人们在把某项成就归因于自身可控的行为时，会感到自豪。比如，一个人在跑完马拉松后所体验到的自豪感，源于他们知道自己为此投入了多少训练里程。我们在掌握新技能或完成艰难任务时，会对自己感到良好。
那么，为什么要在 AI 的语境下测量自豪感？因为存在两种相反的假设，而且都具有重要意义：
一种可能是，人们过度依赖 AI，把工作自动化，从而几乎没有机会通过自身努力去取得成就；
另一种可能是，AI 释放了人们的时间，让他们能够从事更有价值的工作，从而获得自豪感。
我们的研究发现支持后者：更高水平的 AI 采用与更高水平的真实自豪感相关联（见图 29）。
数据还揭示了一个清晰的机制：
更高水平的 AI 应用 → 更多时间投入到有价值的工作 → 从事有价值工作的比例更高的人 → 报告的自豪感水平更高。
这些发现表明，当开发者学会将琐碎任务交给 AI 时，他们可能会获得一系列积极的后续效益。他们重新掌控了最宝贵的资产——时间，从而能够自由投身于对自己真正重要的项目与想法之中。
有意义的工作（Meaningful work）
“有意义的工作”指的是人们希望将自己的工作生活投入到真正重要的事情中。研究显示，从工作中获得意义感的人往往具有更高水平的幸福感与工作满意度。
我们希望探究：AI 的采用是否会影响职业开发者对工作意义的感知。我们提出了两种可能的假设：
积极假设：AI 通过自动化繁琐任务，使开发者能够将更多时间用于有价值的工作，从而提升他们对工作的意义感；
消极假设：AI 干扰了开发者从事其核心角色任务的能力，从而降低了他们对工作的意义感。
研究结果显示：AI 对开发者感知工作是否更有意义没有显著影响。这再次提示我们：或许我们仍处在这场转型的早期阶段，尚未能够清晰地捕捉到这种变化。
认知需求（Need for cognition）
AI 的出现为人们提供了一种快速、简便的方式来减轻心理负担。一些学术研究的数据表明，学生开发者在想“关掉大脑”时会选择使用 AI。
当然，也有人非常享受投入于思考活动。但 AI 提供了几乎无门槛的答案获取方式，这可能会削弱这种乐趣。复杂问题如今可以被瞬间解决，这或许会让一部分人减少对脑力投入的享受。
然而，我们的研究发现：AI 的采用并未导致开发者在认知需求上的变化，即他们对参与思维活动的需求依旧保持稳定。
存在感连接（Existential connection）
“存在感连接”指的是弥合自我内心世界与他人之间鸿沟的感受。哲学家威廉·詹姆斯曾指出，这种鸿沟让我们难以真正理解他人的体验。这个概念体现了我们与他人建立深层次人性化联系的能力，让我们在看待世界时不再感到孤立。
我们之所以研究开发者的存在感连接，是因为 AI 的崛起可能改变工作中的互动方式。AI 提供即时、个性化的答案，这可能减少开发者向同事寻求帮助的需求。虽然效率更高，但也可能导致更少的对话与协同解决问题的机会。我们曾担心，随着更多依赖 AI、而更少依赖同事，职场关系会被削弱，进而让人感到更孤立。
然而，我们的研究发现：AI 采用与开发者的存在感连接之间没有显著关系。
这可能意味着：要么我们还处在一个初级阶段，尚未看到这种新技术带来的影响；要么也可能是，AI 在取代部分人际互动的同时，也创造了新的连接机会，通过帮助我们分享与构建更广泛的集体知识基础，反而为合作与交流提供了新的途径。
心理所有权（Psychological ownership）
心理所有权指的是人们对某件事物产生“这是我的”感觉，即便它实际上并不真正属于自己。我们既可能对有形的物品产生这种情感，也可能对无形的概念（如我们的想法）产生类似的归属感。许多开发者对自己编写的代码就有这种所有权感，因此我们想要探究：在 AI 辅助下编写代码，是否会削弱开发者对代码的个人所有感。
研究结果显示：在 78% 的置信水平下，AI 采用与开发者感知到的个人所有权减弱之间没有关联。换句话说，开发者在 AI 辅助下编写的代码，并不会让他们觉得这些代码“不属于自己”。
这支持了这样一种解释：当下的 AI 工具被视为高级助手，而不是一个与人类共享成果的自主合作者。
由于 AI 被看作是可被使用的工具，而非一个会“分走功劳”的伙伴，开发者已经在心理上将其整合进了工作流，就像编译器或代码检查器一样。
不过，仍然剩余的 21%，表明 AI 可能会削弱部分开发者的所有感（见图 30）。当开发者不借助 AI 独立写代码时，写作者身份非常清晰；但当 AI 介入代码编写过程时，谁在真正写代码的界限可能变得模糊。这会削弱他们的投入感与个人控制感——而这两者正是心理所有权的重要来源。
技能优先级重排（Skill reprioritization）
随着开发者越来越多地与 AI 协作，人们越来越关注这种合作可能会如何改变不同技能的相对重要性。我们希望探究：AI 的采用是否会影响开发者心目中的技能优先级。
我们的假设是：AI 相关技能与以人为中心的技能可能会被视为比代码编写相关技能更重要。
我们请受访者对以下八项技能的重要性进行排序（从最重要到最不重要）：
编写技术文档（Creating technical documentation）
问题解决能力（Problem-solving skills）
提示工程（Prompt engineering）
编程语言语法记忆（Programming language syntax memorization）
代码阅读与审查（Reading and reviewing code）
团队合作与协作（Teamwork and collaboration）
理解团队代码库（Understanding your team’s codebase）
代码编写（Writing code）
不足为奇的是，AI 的采用提升了“提示工程（Prompt engineering）”的感知重要性。 更有意思的是，AI 采用还提高了对编程语言语法记忆重要性的认知。这一结果颇值得深入研究，因为人们原本可能会认为，在 AI 时代，语法记忆会是最先被视为过时的开发技能之一。
最令人意外的发现是：AI 采用并未影响其他任何技能的重要性认知。
目前我们还不能基于这些数据下定论，因为这些结果可能有多种解释。例如：
这可能意味着开发者仍处在适应 AI 驱动新工作流的过渡期；
也可能仅仅反映了开发者相信他们的独特专业知识依旧不可或缺。
要点总结（Takeaways）
这些研究结果表明：AI 的采用尚未对开发者的工作体验产生实质性的影响。我们将继续积极跟踪这一领域，观察潜在的变化。
在此期间，我们建议组织：
给予开发者更多自主权，让他们专注于自己认为有价值的工作；
持续创造学习机会，帮助开发者掌握如何更好地利用 AI，将繁琐任务交给 AI，从而在日常工作中腾出时间，去做更重要、更有意义的事情。
为了避免心理所有权可能下降，我们建议开发者：
始终将 AI 视为为他们所用的工具。
即便这项技术逐渐具备更多自主性，开发者也要始终把自己看作是驾驶者，而不是旁观者。
DORA AI 能力模型
DORA 一直以来的目标，不仅是描述软件交付的现状，更是帮助组织在瞬息万变的开发工具、方法与技术环境中，做出基于数据的决策。AI 正在显著改变软件开发。虽然快速的进步带来了许多令人兴奋的可能性，但同时也提出了新的问题：软件开发应如何演进，才能真正把握住这一时刻？
因此，今年我们不仅关注谁在采用 AI、如何使用 AI，更深入探究了在什么条件下，AI 加持的开发者能够获得最佳成果。
我们首次提出了 DORA AI 能力模型（DORA AI Capabilities Model）。研究表明，这一首版模型中的七大 AI 能力，能够放大 AI 采用所带来的效益。它既涵盖了组织的技术维度，也涵盖了文化维度。我们的研究显示，投资建设这些能力领域，能够帮助组织真正释放 AI 工具的潜力。
与 DORA 核心模型（DORA Core Model）一样，我们将持续通过进一步研究来验证、修订与完善 DORA AI 能力模型，并期待在未来与 DORA 社区分享更多的迭代成果。
AI （相关）能力
为了开发这一模型，我们基于以下研究基础提出了可能影响 AI 辅助开发团队成果的广泛能力假设：
78 场深度访谈，
领域领先专家的专业意见，
以及以往的 DORA 研究。
在此基础上，我们经历了一次广泛的讨论与优先级排序过程，最终选出了今年调查中要纳入的 15 个候选能力。
在这些候选能力中，7 个 能力脱颖而出。当团队将这些能力与 AI 采用相结合时，AI 在重要结果上的积极影响会被进一步放大。
这七大能力构成了我们新模型的核心：
这七大核心 AI 能力包括：
清晰且有效传达的 AI 立场（Clear and communicated AI stance）
小批量工作方式（Working in small batches）
可供 AI 访问的内部数据（AI-accessible internal data）
高质量的内部平台（Quality internal platforms）
健康的数据生态系统（Healthy data ecosystems）
以用户为中心（User-centric focus）
健全的版本控制实践（Strong version control practices）
清晰且有效传达的 AI 立场（Clear and communicated AI stance）
“清晰且有效传达的 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 来处理一些更加琐碎的任务。”
健康的数据生态系统（Healthy data ecosystems）
“健康的数据生态系统”指的是一个组织内部数据系统的整体质量。在我们的分析中，数据生态系统的健康度被视为一个单一因子，由以下三个指标共同衡量，反映受访者的感知：
内部数据源的整体质量；
内部数据源的可访问性；
内部数据源之间是否存在孤岛或割裂现象的程度。
因此，一个拥有健康数据生态系统的组织，其内部数据应当具备以下特征：
高质量；
易获取；
统一而非割裂。
研究发现
我们以高度确定性发现：AI 的积极效益取决于组织是否具备健康的数据生态系统。当组织的数据生态系统健康时，AI 对组织效能的正向影响会被显著放大。
人们常说：AI 模型的效果取决于它所训练的数据。在这里，这条经验法则在组织本地层面同样成立。
实践意义
当组织在构建和维护高质量、可访问、统一的数据生态系统上进行投入时，即使不采用 AI，也能为组织效能带来更高的收益。
AI 可访问的内部数据（AI-accessible internal data）
“AI 可访问的内部数据”指的是 AI 工具与组织内部数据源和系统的连接程度。在我们的研究中，它被定义为一个单一因子，由以下四个指标衡量，反映受访者的感知：
AI 工具是否能够访问公司内部信息；
AI 工具的回答是否使用了公司内部信息作为上下文；
在提示中输入公司内部信息的频率；
使用 AI 工具检索公司内部信息的频率。
健康状态下的表现
在一个具备 AI 可访问的内部数据 的组织中，员工会观察到：
内部数据对 AI 系统是可用的；
并且他们可以通过 AI 工具直接访问和处理这些数据。
研究发现
我们以高度确定性发现：AI 的正向效益取决于组织是否具备 AI 可访问的内部数据。当组织实现了这一点时：
AI 对个人效能的积极影响被放大；
AI 对代码质量的积极影响被放大。
换句话说，尽管基于通用知识训练的 AI 工具已经能够帮助开发者提高效能与代码质量，但如果 AI 能够访问组织的内部数据，并结合公司特定的上下文，那么这些正向效果会被显著增强。
实践意义
这表明：组织若投入精力将 AI 工具与内部系统深度集成，其收获的成果可能会远超仅依赖通用大模型的组织。
换言之，要最大化 AI 在个人效能与代码质量上的收益，仅仅采购 AI 授权是不够的，还需要进行更深层次的投资。
从某种角度看，这一发现并不令人意外——如果 AI 无法访问公司内部数据，那它又能真正有多大用处呢？
“我觉得我目前的很多客户其实还远没有到能够有效使用任何 AI 系统的阶段……他们甚至连数据的规范化管理都没做到……数据散落在公司各个角落，没有统一的存储系统，也没有标准化的格式。 然后，如果他们想用 AI，就必须先进行大量的数据工程工作，把数据处理成能够被生成式 AI 系统真正消费的形式。 我感觉很多公司甚至还没有到达能真正有效使用 AI 的那一步。”
健全的版本控制实践（Strong version control practices）
健全的版本控制实践长期以来都是高效能软件开发团队的基石。版本控制工具为管理代码及其他数字资产随时间的变更提供了一种系统化方式。
在生成式 AI 时代，代码生成的规模和速度显著提升，使得版本控制的重要性被进一步放大。我们的研究表明：成熟的版本控制习惯与 AI 采用之间存在强大的协同作用，这些实践不仅是放大 AI 效益的关键，同时也是降低其风险的必备条件。
研究发现
我们以高度确定性发现：AI 的正向效益依赖于开发者在版本控制中的提交频率。
- 当提交频率更高时，AI 对个人效能的积极影响被放大。
此外，我们还发现：AI 的正向效益依赖于开发者使用版本控制系统“回滚”功能的频率。
- 当回滚更频繁时，AI 对团队效能的积极影响被放大。
心理安全网
成熟版本控制的一个关键方面在于它充当了心理安全网（psychological safety net）。
这种安全网让开发团队可以更有信心地进行试验与创新，因为他们知道：一旦出现问题，可以轻松回退到稳定状态。
最直观的例子就是对“回滚/撤销”功能的依赖。快速、无障碍地撤销更改，不仅仅是一种便利，更是实现速度与韧性的关键支撑。
与 AI 的关系
AI 的高产出速率让开发者更容易感受到“高效能”。但正如我们在 《探索 AI 与关键结果的关系》 章节中讨论的，AI 的使用也与更高程度的软件不稳定性相关。
我们推测这部分原因在于：大批量代码更难以审查。
因此，虽然频繁使用回滚功能并不会直接减少不稳定性，但我们认为它对 AI 辅助团队的团队效能产生正面作用，可能是因为：在处理大批量代码以及其潜在的不稳定性时，能够快速撤销变更的重要性更高。
小批量工作（Working in small batches）
“小批量工作”是 DORA 的长期能力之一，指团队将变更拆分为可管理的小单元，以便能够快速测试和评估。
衡量方式
小批量工作的健康度被定义为一个单一因子，由以下三个指标衡量：
受访者在其主要应用或服务中最近一次提交的代码行数；
通常合并到一次发布或部署中的变更数量；
开发者完成一个任务所需的平均时间长度。
一个小批量工作评分更高的团队，通常表现为：
每次提交的代码行数更少；
每次发布合并的变更数量更少；
每个任务能够在更短时间内完成。
研究发现
我们以高度确定性发现：AI 的积极效益取决于团队是否采用小批量工作方式。当团队实践小批量工作时：
AI 对产品效能的正向影响被放大；
AI 对摩擦感的中性影响被转化为积极效应，显著降低摩擦。
相反，我们也发现：在小批量工作团队中，AI 对个体效能的提升略有减弱。
解读与意义
尽管结果存在分化，但我们认为整体而言，小批量工作对 AI 辅助团队的影响是净正向的。
观察到的“个体效能提升减弱”与我们的理论一致：AI 提升个体效能的主要方式在于帮助开发者快速生成大量代码。而对于优先采用小批量工作的团队来说，个体效能的提升幅度自然会有所收敛。
更重要的是，我们强调：个体效能本身不应被视为终极目标。它应当是实现更高层级的组织效能、团队效能、产品效能以及开发者福祉的手段。
在这一背景下，小批量工作既能提高产品效能，又能降低摩擦感。我们认为，这些益处远远超过其可能带来的个体效能减弱。更不用说，小批量工作作为 DORA 核心模型（DORA Core Model）的一部分，已经被长期验证为软件交付高效能的重要驱动因素。
以用户为中心（User-centric focus）
“以用户为中心”是我们年度调查中长期纳入的一项指标，指团队在多大程度上关注其主要应用或服务的最终用户体验。
衡量方式
受访者的用户关注度被定义为一个单一因子，由三个七点量表指标组成，衡量他们对以下陈述的认同程度：
创造用户价值是我的焦点；
用户体验是我的首要任务；
关注用户是业务成功的关键。
因此，一个以用户为中心的团队，通常表现为：他们将用户体验放在首位，并理解用户体验与业务成功之间的紧密联系。
研究发现
我们以高度确定性发现：AI 的效应依赖于团队是否以用户为中心。
当团队以用户为中心时，AI 对团队效能的正向影响被放大；
反之，AI 采用反而会对团队效能产生负面影响。
换言之，以用户为中心不仅能让 AI 辅助团队获得更大收益，缺乏这种关注甚至会让 AI 采用拖累团队表现。
启示与意义
长期以来，我们认为以用户为中心能帮助团队明确目标，并围绕共享战略开展工作，把用户体验作为指引。
在 AI 辅助开发团队中，这一点表现得尤为明显：
当团队聚焦用户时，AI 的价值被进一步放大；
当团队忽视用户时，AI 的采用会带来负面影响。
这些发现提示：组织在推动 AI 采用时，必须将对用户的深入理解（包括用户目标和反馈）纳入产品路线图和战略。
同时，这也是一个重要的警告：如果缺乏对用户的关注，忽视满足最终用户的需求，AI 的采用可能损害团队效能。
没错，这正是我在这里待了五年的原因——我觉得自己在做一件有意义的事，能够帮助到普通人。哪怕只是帮助一个人，对我来说也是件了不起的事。但在这里，我能帮助的是数以百万计的用户…… 当有些糟糕的日子里，我心情不佳时，只要想到我所做的一切都是为了这个目标，这种念头就会让我感觉好很多，并激励我继续工作。比如说，我今年只要开发一个小功能，就能帮助十万名用户，这让我充满动力。
一个关键的顿悟时刻是意识到：临床医生并不需要更多的工具——他们需要的是更少的干扰。我们最初的假设是，通过提供更先进的功能来创造价值。但我们发现，事实恰恰相反：技术的简洁性与隐形性才是真正的创新。 相比于完全自动化，AI–人类的混合模式在准确性、共情能力与信任度方面表现得更出色。”
高质量的内部平台（Quality internal platforms）
理解高质量内部平台的价值，一直是我们调研中的重要部分。在这里，“平台”指的是：一组可以在多个应用或服务中共享的能力，其目标是让这些能力能够在整个组织范围内广泛可用。
衡量方式
平台的质量通过一个综合评分来衡量，该评分反映了受访者认为其内部平台具备的 12 个特征（详见附录中的完整定义）。
研究发现
我们以高度确定性发现：AI 的效益取决于组织是否具备高质量的内部平台。
在拥有高质量内部平台的组织中，AI 对组织效能的积极影响被放大；
但同时，AI 在摩擦上的中性效应被转化为负面，即：在拥有高质量内部平台的组织里，开发者报告的摩擦感有所增加。
解释与意义
尽管结果存在分化，我们仍认为总体上 高质量内部平台对 AI 辅助团队的影响是净正向的。
正面作用：高质量的内部平台通过提供统一的能力集，让开发团队能够更轻松地进行构建，从而提升个体效能。
潜在负面作用：平台标准也会在一定程度上限制开发工具的使用方式，例如：定义仅限内部使用的 API，并要求比外部接口更严格的安全控制。
由此，高质量内部平台的作用既包括：
提升对期望能力的可访问性；
限制对不期望能力的使用。
由于我们尚未形成一套针对 AI 辅助开发工具的标准化最佳实践，我们推测目前高质量内部平台在这方面的作用主要偏向后者——防止不当使用。这也可能解释了为什么在大量采用 AI 的情况下，摩擦感有所增加。但这种摩擦增加，对组织来说未必是坏事。
总结
正因如此，加上其对组织效能的积极作用，我们认为：设计和维护高质量的内部开发平台，是组织在 AI 辅助环境下成功开展软件开发的一项关键能力。
将 DORA AI 能力模型付诸实践
本章的研究结果表明：在软件开发中成功发挥 AI 的价值，并不是简单地引入新工具就能实现的。相反，组织必须营造出特定的技术与文化环境，才能获得最大的回报。
以下是基于 DORA 七大 AI 能力 提出的若干实践性建议：
制定明确的 AI 政策并广而告之
围绕 AI 的模糊性会抑制采用并带来风险。组织应当建立并推广一份清晰的政策，明确哪些工具和使用方式是被允许的，从而建立开发者的信任。
这种清晰度能提供开展有效实验所需的心理安全感，既能减少摩擦，也能放大 AI 在个人效能和组织效能上的积极影响。
缩小工作项规模
虽然 AI 能通过生成大量代码来提升个体效能，但我们的研究表明，这并不是最重要的衡量指标。真正应该关注的是成果。坚持并强化小批量工作的纪律，不仅能提升产品效能，还能为 AI 辅助团队减少摩擦。
将数据视为战略资产
AI 对组织效能的积极作用，会因健康的数据生态系统而被显著放大。
组织应当投资于提升内部数据源的质量、可访问性与统一性。当 AI 工具能够基于高质量的内部数据进行学习时，它们的价值将大幅提升。
将 AI 融入你的内部环境
把 AI 工具与组织的内部系统连接起来，从而突破通用辅助的局限，真正提升个人效能与代码质量。
这意味着不能只停留在采购 AI 授权上，而是要投入必要的工程资源，让 AI 工具能够安全访问内部文档、代码库和其他数据源。只有这样，AI 工具才能获得公司特有的上下文信息，并发挥出最大的效用。
拥抱并强化你的安全网
AI 辅助编程会显著提升变更的数量与速度，但同时也可能带来更多不稳定性。在这种环境下，版本控制系统就是关键的安全网。
组织应当鼓励团队熟练掌握 回滚（rollback）与撤销（revert）功能的使用，因为这一实践在 AI 辅助环境下与更高的团队效能显著相关。
在产品战略中以用户需求为核心
开发者在采用 AI 后，个人效能可能会显著提升。 但如果团队未能关注用户需求，可能会更快地背离客户。
我们的研究发现：缺乏用户中心化关注的团队，在采用 AI 辅助开发工具时，效能反而可能受到损害。相反，把用户需求作为产品焦点，能够引导 AI 辅助开发者朝着正确目标前进，并对团队效能产生极为强大的正向作用。
投资于内部平台
高质量的内部平台是放大 AI 对组织效能积极作用的关键支撑。
它们能够提供必要的防护栏与共享能力，使 AI 的收益能够在组织范围内高效且安全地规模化落地。
平台工程
我们的 2024 年报告首次探讨了内部平台对软件交付效能的影响。我们发现：平台确实对组织效能和生产力有积极作用，但这种收益伴随着权衡——软件交付不稳定性增加，以及吞吐量下降。
今年的研究不仅进一步验证了平台工程的价值，还深入探讨了成功的平台是如何运作并创造价值的。数据表明：平台并不仅仅是工具的集合，而是一种整体性体验，它会直接影响效能、员工福祉，以及组织利用变革性技术的能力。
我们发现，用户往往将平台视为一个整体，其整体效能远比平台中任何单一功能的质量更为重要。
本章将进一步解析平台工程的关键模式——从其几乎全面普及的采用情况、团队结构设计，到它作为创新与风险管理战略基础所扮演的关键角色。
关键发现
平台采用率几乎已成普遍现象：达到 90%。
专职平台团队是主流的组织模式，占比高达 76%。这意味着领导力的挑战已经从“推动采用”转向了如何有效治理多团队格局。
高质量平台能放大 AI 对组织效能的积极作用。当平台质量较高时，AI 对组织效能的正面影响更为显著。
高质量平台是倍增器：它能提升组织效能、生产力，并改善团队福祉。
平台应被视为一个整体性实体，核心目标是创造卓越的开发者体验。、
平台还充当了风险管理引擎，在带来速度与试验能力的同时，也会带来小幅但真实的软件交付不稳定性。但这是一种可控的权衡，换来的是整体更高的效能。
普及、复杂化、团队驱动
如今，大多数组织已经拥有了内部平台，这表明讨论的重心已经从“是否需要平台”转向了“平台该如何构建”。
我们的数据表明：
90% 的组织至少采用了一种平台；
29% 的组织已经进入多平台环境；
76% 的组织至少拥有一支专职平台团队；
超过 29% 的受访者所在的组织有多个专职平台团队。
多平台和多团队的普及，并不是工具冗余的迹象，而是说明组织已经超越了“一刀切”的模式，转向构建联合化、专业化的平台与团队，以服务于不同的领域和技术栈。
因此，领导者面临的挑战已经从“有没有平台”转向了“如何治理一个复杂的平台生态”。
和应用一样，平台也能从 DORA 的能力——松耦合团队（loosely coupled teams）中获益，以更好地应对复杂性。
实现这一点，需要为各平台团队建立清晰的职责范围（charters）与接口（interfaces），从而确保整个平台生态系统真正改善开发者体验，而不是制造新的组织孤岛。
整体体验才是关键
我们请受访者对其平台进行评分，评价其在不同能力上的表现。例如：“该平台是否帮助我构建和运行安全的应用和服务。”
研究发现存在明显的体验差距：
在核心技术能力方面（如“平台是否有助于可靠性和安全性”），开发者普遍认为支持良好；
而在用户体验相关特性上（如“是否能基于反馈进行改进”、“任务自动化的程度”），则相对滞后。
开发者对平台的整体印象——是有益的伙伴，还是摩擦的来源——会极大影响他们对每一个具体功能的评价。能力之间评分的相对紧密分布也表明，开发者并不把平台视为一份“离散功能清单”，而是将其体验为一个整体性实体。
这种体验差距很可能源于平台建设过程中，组织往往先着力于技术基础设施，而用户体验被推后处理。但数据显示，如果不解决用户体验问题，平台的全部价值就无法真正释放。
因此，需要转变思维：把平台当作产品来运营，将内部开发工具视作产品，把开发者当作客户。这样才能确保用户始终是关注焦点——这是 2024 年报告中的一个关键发现。
以用户为中心，是避免在构建内部开发者平台时常见陷阱的关键。以下是几种典型的误区及原因：
酒香不怕巷子深
表现：平台团队基于自己想象的开发者需求来构建平台，没有做用户调研、访谈或验证。他们只关注技术和工程本身，假设平台的价值是不言自明的。
失败原因：平台最终成为“鬼城”，因为它既没有解决开发者真正痛点，也无法融入他们现有的工作流。
用户中心化替代方案：采取产品思维，从开发者共情和需求探索开始，平台团队要持续与用户互动，理解他们面临的最大挑战，确保构建的东西是开发者真正想用、愿意用的。
工单运维陷阱（Ticket-ops trap）
表现：平台团队像“基础设施自动售货机”，完全被动响应开发者工单（如“帮我建个数据库”“帮我建个 CI/CD 流水线”），没有愿景，也没有路线图。
失败原因：造成瓶颈，加重了平台团队和开发者双方的工作负担。团队耗尽时间处理一次性请求，却无力构建统一的自助化能力。
用户中心化替代方案：构建一个自助式平台，并制定清晰的路线图。目标是通过自动化、可复用的工具和黄金路径（Golden Paths），让开发者能自主申请和配置资源，从而消除工单队列。
象牙塔平台
表现：中心化的团队居高临下地制定平台架构与工具，强制推行僵化的标准，没有协作和反馈机制。团队更像是“技术守门人”而非开发者赋能者。
失败原因：让开发者感到被剥夺权力，最终催生影子 IT 或非官方替代方案绕过平台约束，违背平台初衷。
用户中心化替代方案：引入产品经理角色，积极收集开发者反馈，把开发者视为客户。平台的设计目标是赋能而非限制，提供“铺好的路”（易用且令人愿意使用的标准路径），但不必强制唯一。
在考虑各项能力及其相互关系时，所有能力或多或少都呈现出均衡的相关性。然而，有两项能力在其中显得尤为突出。
首先，与积极用户体验最强相关的能力是为任务提供清晰的反馈
当平台在任务成功或失败时提供清晰反馈，用户会感到有能力采取行动、排查问题并进行下一步操作，而不是不得不自己翻找信息并摸索解决方法。
其次，“界面直观且简洁”的相关性较低：尽管简洁的界面可能会提升感知，但它并不必然转化为平台的高效性。
即便清晰反馈和简洁界面与其他能力高度相关，它们在感知层面上的评分仍然位居较低。 这意味着，仅仅专注于提升某一项能力的做法是有缺陷的策略。
若要提升平台的感知质量，团队必须将其视为一个整体性的内部产品，并着力改善整个开发者旅程。 如果一个平台在技术上非常优秀，但不以用户为中心（参见 2024 年 DORA 报告），它就不能被视为成功。
效能、幸福感和风险的倍增器
根据我们的能力定义，高质量的平台在整体上具有广泛且统计上显著的正面影响。它与更高的组织绩效、产品绩效以及生产力相关联。
与以往研究一致，我们发现更好的平台会带来一个小但可信的副作用，即软件交付的不稳定性有所增加，这意味着更高的变更失败率以及更多的返工。
总体来说，就是尽可能地去做持续交付，如果把代码合并到主干，就立即发布，尽量加上一些测试，用来发现问题，但核心就是直接部署。在大多数情况下，这样做没什么问题，因为即使在部署过程中出现了故障，也有许多小机制可以保证站点不会宕机。所以，部署可能会失败，我们可能需要迅速修复，但网站依然能够正常运行。
一个优秀的平台如同倍增器，能够直接转化为更好的效能和生产力。相应增加的不稳定性可能恰恰代表着一个健康的高速运转系统，只要这种额外的不稳定性不影响产品性能，它就是可以接受的。
尽管稳定性有所下降，但效能依然提升，这暗示了一种风险补偿的形式：平台让从失败中恢复变得快速且低成本，从而赋能团队进行更多实验，并在追求速度的过程中接受更高比例的小规模失败。
这种轻微的不稳定性应被视为一种可控的权衡，因为平台所带来的绩效显著提升远远超过了交付吞吐量的小幅增长以及交付稳定性的下降。
投资于高质量平台是一种强有力的战略杠杆，能够带来广泛而深远的回报。
战略要务：你的平台是释放 AI 能力的关键
AI 采纳对组织效能的积极作用取决于内部平台的质量。
当平台质量较低时，AI 的采纳对组织效能几乎没有影响；但当平台质量较高时，其作用则显著且积极。 这是任何投资 AI 的领导者都必须关注的关键发现。
Wayfair 发现，最大的收益不仅来自于更快地发现故障，而是来自于降低修复所需的工作量。 将 AI 嵌入 CI/CD 流程中表明，当针对性强、可解释的建议和自动生成的修复能够无缝集成到开发者已经使用的工具中时，开发者的参与度最高。
高质量的平台在放大 AI 对组织绩效的影响时发挥着两个作用。
首先，它充当分发与治理层，将 AI 带来的个人生产力提升扩展为系统性的组织改进。 缺乏这一基础，采纳 AI 也只会带来一系列分散的局部优化。
平台提供了集中化的上下文，并抽象掉了让 AI 在大规模下可用和高效所需的复杂或繁琐部分。
不过，AI 正在快速演进，因此要谨慎，不要过度标准化 AI 的实践、工具和方法，否则很可能会限制其积极影响以及在 AI 变化时的适应能力。
其次，正如平台在未涉及 AI 时充当风险缓解器一样，它对 AI 的风险缓解作用同样有用。
平台应当被用来创造一个安全空间，让个体能够学习和实验。
这种实验的安全空间有助于平台和平台团队不断成长和适应，从而更好地支持新的模型、交互模式以及应用开发方式。
此外，无论代码是由人类还是 AI 创建，都会应用同样的自动化测试与部署流程，本质上确保引入应用和服务的变更是安全的。
如果在 AI 上进行投资，却没有在高质量平台上进行相应投入，那么在组织层面几乎不可能获得显著回报。 要真正利用 AI 获得竞争优势，领导者必须将平台工程视为一项基础性的战略推动力。
平台时代的三大要务
提升整体体验
你无法通过改进某一个功能来修复一个糟糕的平台。 要将平台视为一个完整的产品，关注整个开发者旅程，从反馈循环到自动化。
让平台成为 AI 的基石
平台是释放 AI 组织价值的战略前提。 它是将你的 AI 投资转化为真正竞争优势的引擎。
利用平台校准风险偏好
一个优秀的平台会改变组织与风险的关系，让失败变得低成本且易于恢复。 理解并管理由此带来的速度与不稳定性之间的权衡，同时要认识到平台并不能消除风险在局部层面的影响。
价值流管理
每一个组织都面临着加快创新速度的压力。我们都在采纳 AI、自动化流程、构建平台，并以极快的速度交付功能。但我们真的在变得更好吗？还是只是更快地开发出无法创造价值的功能，更快地让团队精疲力竭，更快地制造复杂性？
当下最大的风险不是被落下，而是把大量投资投入到混乱的活动中，却无法真正带来进展。
十多年来，DORA 的研究一直遵循一个核心信念：表现最出色的组织不仅仅是采纳新工具，而是精于价值交付体系。他们具备“在变得更好方面不断精进”的成熟能力。他们能够理解自身的工作流，识别真正的约束点，并有意图且专注地分配资源。
今年，我们确认，识别和管理价值流的能力，才是真正区分混乱活动与聚焦改进的关键。在 2025 年的研究中，我们发现那些专注于理解自身价值流的团队，会显著更多地把时间投入在有价值的工作上。
更重要的是，我们发现价值流管理（VSM）是让 AI 投资成为竞争优势的倍增器，确保这项强大的新技术解决正确的问题，而不是制造更多混乱。
如何实现聚焦改进：价值流管理的原则
价值流管理（VSM）是一种实践，目的是用可视化的方式、分析并改进从想法到客户的工作流。
它不是一种笨重的流程，而是一组由四条原则构成的方法，用于获得清晰视野，从而能聚焦在最关键的环节进行改进。
如需了解如何逐步开展价值流映射练习的详细指南，请参阅 DORA 价值流管理指南。
从脑海混乱到共享地图
试图在脑海中理清一个复杂系统是非常困难的。记住所有繁杂的细节会给任何人带来巨大的精神负担，并妨碍对整体全貌的理解。
当团队共同绘制系统地图时，就能把这些细节从个人脑海中释放出来，放到一个共享空间中。系统的结构——以及隐藏的模式——便会一目了然。这种可见性让团队更容易就“哪些有效、哪些无效”展开真正的讨论。 从本质上讲，这正是价值流管理（VSM）的核心。
其实践就是绘制整个软件交付生命周期的流程，从最初的概念一直到最终交付给客户。
这张地图涵盖了一切：产品探索、设计、开发、测试、部署和运维。创建这种共享的表示方式能让团队形成对工作流的集体理解，从而更容易发现真正的瓶颈和阻碍进展的低效之处。
将整个系统从概念到客户完整映射是目标，但不必一次性完成。关键在于从能产生最大影响的地方入手。
在深入绘制之前，先从高层次审视你的工作流，识别主要的约束点，避免去优化那些并非真正瓶颈的环节。例如，如果团队的最大挑战在产品探索阶段，那么从那里开始可能会更有效。
不过，一个经过验证且非常有力的起点，也是 DORA 多年来一直采用的范围，就是从代码提交到投产。之所以从这里入手，是因为这部分流程最容易标准化，并且能够针对效率进行优化。更重要的是，这是团队通常拥有最大自主权的阶段，因此他们可以立刻做出有影响的改进。这与探索阶段形成对比，后者的主要目标是优化有效性。
成功完成这一核心流程能带来快速成果，建立推动更广泛系统（如产品探索和客户反馈）改进所需的动力和公信力。
关注流动，而不仅仅是速度
一旦绘制了价值流，真正的目标就是让工作顺畅且可预测地流动。要做到这一点，需要从关注局部效率转向优化整个系统。
你应该从衡量真正重要的指标开始。追踪关键指标，例如交付周期（lead time）、处理时间（process time）、以及增值时间与等待时间的比率。这些数字能为你揭示真正的约束点，并提供清晰的基线，从而帮助你判断改进是否真的有效。
这种系统层面的视角对于识别应用新方案或新技术的最佳位置至关重要。例如，通过映射，团队可能会发现代码审查是一个显著的瓶颈。有了这一洞察，他们就可以决定将 AI 应用于改进代码审查流程，而不是仅仅用 AI 生成更多代码，从而加剧瓶颈。
真正的胜利在于利用 AI 来改进代码审查流程本身，清除系统中的实际堵点。这正是关注流动的意义所在：你需要解决整个系统中最大的难题，而不是仅仅加快某一个步骤。
打造持续改进的文化
价值流管理（VSM）不是一次性的练习，而是一个持续改进的循环。要定期回顾团队创建的价值流图，并将其作为每一次改进讨论的起点。
关键在于培育一种文化，使团队有权力去尝试、学习和适应。这意味着要设定清晰的目标，同时也要给予团队自主权，让他们自己探索如何实现这些目标。他们需要拥有在没有惩罚恐惧的情况下进行实验、学习和调整的自由。同样重要的是，要鼓励团队将他们的学习成果分享给整个组织。
通过这种方式来践行 VSM，并记录每一次迭代改进，你就能创造一段关于进步的“活的历史”。随着时间的推移，你可以回顾并建立一条清晰的故事线，展示每一次变革是如何不断提升你向客户交付价值的能力。
“还有一种复杂性，比如，‘这需要多少工作量？’ ‘最终要花多长时间？’ ‘你该怎么估算呢？’ 这总是充满不确定性，同时还伴随着缺乏掌控感。我们能否在需要时即时做出变更并完成任务？ 还是说，每次想做点事，比如修改一条防火墙规则，都得经历两三周的流程？类似的事情有很多。
这个流程会以各种不同的方式拖慢我们的工作。 我觉得，尤其是更资深的人对此特别熟悉，因为他们在其他大公司里早就经历过这种情况了。”
以卓越技术为根基
如果没有技术卓越作为基础，就不可能实现快速而顺畅的流动，而这种基础通常来自于一个设计良好的内部平台。通过为测试和交付等能力提供“铺好的道路”，一个强大的平台能够抽象复杂性，使高绩效的工作具备可扩展性。
强大的技术基础与组织能效之间的关系，在《平台工程》章节中有详细探讨。
2025 年的研究结果如何
多年来，DORA 一直倡导使用价值流管理（VSM）等实践来创造快速的工作流。但随着 AI 的广泛应用，这一建议是否依然有效？
今年，我们希望验证长期以来关于 VSM 好处的假设。研究结果证实，拥抱 VSM 原则的组织能够获得显著且可衡量的收益。
首先，我们的研究确认了 VSM 实践对绩效有直接而强大的影响。我们发现了以下强有力的证据：
VSM 推动团队能效：持续审视和改进价值流的团队报告的绩效显著更高。
VSM 带来更有价值的工作：这些团队在组织及其客户真正关心的工作上投入的时间明显更多。
VSM 改善产品能效：最终，对价值流的关注转化为更好的产品成果，而这可以说是最重要的结果。
这些数据传递了一个简单而人性化的故事：
那些共同努力去理解价值流的团队，会把更多的时间花在真正重要的工作上。当团队对整个价值流有清晰且共享的理解时，他们能够将精力集中在最重要的事情上，把这种清晰转化为有意义的影响。
这种清晰正是释放 AI 等新技术能量的关键。它使团队能够采取战略性行动，而不是盲目地把工具扔向问题。团队不再只是优化某一个小步骤，而是去消除系统中最大的约束。
基于这一点，我们为今年的研究提出了一个关键假设：
VSM 将 AI 转化为组织优势：我们假设 VSM 调节了 AI 采纳与组织绩效之间的关系。具备成熟 VSM 实践的团队能够把 AI 带来的生产力提升引导至解决系统层面的问题，从而确保个体改进能够转化为更广泛的组织成功。而如果缺乏 VSM，AI 的作用就可能仅限于局部效率的提升，而这些提升最终会被下游的瓶颈所吞噬，从而无法为整个组织带来真正的价值。
结论
我们的分析验证了这一假设。单纯的 AI 采纳本身仅表现出有限的影响，但在具备强大 VSM 实践的组织中，这种效果被显著放大。这进一步确认了 VSM 是充分释放 AI 投资价值的关键使能因素。通过确保团队和个人层面的生产力提升集中于最重要的系统性约束，VSM 帮助将局部改进转化为真正有意义的组织影响。
这项研究不仅仅是一种观察，更是一种挑战。摆脱混乱活动循环的第一步很简单，却并不容易：问问你的团队——“我们能不能在白板上画出我们的软件交付价值流？”如果答案是否定的，或者这幅图暴露出的问题多于答案，那么你就找到了起点。那场对话，正是“在变得更好方面不断精进”的开端。
AI 镜像：AI 如何反映并放大你组织的真实能力
去年的 DORA 报告发现，使用 AI 的团队在软件交付中报告了更低的吞吐量和更高的不稳定性。这个出乎意料的发现引发了热烈的讨论——一项旨在加速工作的技术，怎么会与更慢、更不稳定的结果联系在一起？
今年的情况有所变化。AI 的采用如今已经推动吞吐量略有上升，但不稳定性仍然存在。这种进步与摩擦并存的局面促使我们更深入地探究，超越对 AI 的简单二元比较，去理解真正决定其影响的因素。
我们的发现指向了一个比工具和技能更重要的因素：AI 的应用环境，才是塑造其影响的关键。
超越工具
今年研究中最令人振奋的成果之一是 DORA AI 能力模型。AI 在吞吐量、代码质量、团队与组织绩效等结果上的作用，始终会被七项能力所放大：
清晰且已传达的 AI 立场
健康的数据生态系统
可供 AI 使用的内部数据
强有力的版本控制实践
小批量工作方式
以用户为中心的关注点
高质量的内部平台
这些系统性条件反映了一个组织如何构建其工作、支持其团队，以及如何让环境与现代开发实践保持一致。这些能力决定了使用 AI 工具能否真正转化为有意义的成果，因此它们是 放大器。更重要的是，它们全部属于团队与组织层面，这强化了一个关键转变：我们需要重新思考 AI 在软件交付中的角色。
组织是有机整体，而非个体总和
要想理解如何把 AI 的影响从个人生产力的提升扩展到组织层面的收益，我们必须从系统的角度来思考。组织并不像是个体和工具的集合，而更像是由相互依赖的部分组成的网络。工作在团队、流程、政策、基础设施以及共享规范之间流动。虽然个体能力对结果有着重要作用，但整体绩效源自于所有这些部分的互动方式。
这一理念是系统思维的核心，也是高绩效组织演进的关键视角。现代质量管理的奠基人之一 W. Edwards Deming 曾指出，大多数绩效问题不是源于人，而是源于系统。正如他那句著名的话：“一个糟糕的系统，每次都会打败一个优秀的人。”
在一个系统中，仅仅改善某一部分，并不能保证整体结果更好。事实上，如果系统的其他部分无法适应，这些局部改进可能会被阻断、削弱，甚至产生反作用。这也是约束理论（Theory of Constraints）的核心洞察：每个系统都有一个限制因素——一个约束——决定了它能交付多少价值。把注意力放在约束之外的地方，可能看似高效，但不会真正改善价值流动。
这一点对 AI 采纳也有重要启示。即便开发者借助 AI 工具写代码更快，这些代码仍需要经过测试与审查队列，接着是集成和部署流程。除非围绕开发者新工具和加速节奏的工作流得到更新，否则整体交付速度不太可能发生显著变化。系统本身并没有设计好去承载这些提升，更别说放大它们了。
我们以前已经见过类似的情况。在向云转型的过程中，那些仅仅迁移基础设施，而不重新思考架构和交付实践的公司，回报有限。相反，那些为云原生工作流重构了应用、团队和运营的组织，才真正释放了价值。敏捷（Agile）和 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 可以通过更早发现威胁、识别异常行为，甚至自动化部分事件响应流程，来扩展安全团队的能力。对于经常资源不足的安全团队来说，AI 的作用在于缓解压力，同时改善响应时间。
AI 原生协作模式：新兴实践如 agentic 工作流 与 swarming（蜂拥式协作）正在重塑人类与 AI 的协作方式。前者将任务分配给自主的 AI 智能体，后者则使团队与 AI 能够动态聚合来解决复杂问题。尽管仍处于早期阶段，但这些模式已预示着新的、更具适应性的协作方式。
新兴趋势如持续 AI（Continuous AI） 展示了如何在长期内维持 AI 原生的工作流。持续 AI 将 AI 系统视为开发流水线的有机组成部分，以及团队流程中的参与者。它能够持续感知项目环境中发生的事件，并通过自主而协作的方式，促进团队互动，并随团队一起调整方向。关键在于，AI 系统或智能体需要不断更新相关上下文，并持续衡量其准确性、实用性与成本。
这样一来，AI 就能与组织不断演进的架构、实践和优先事项保持一致，确保其输出在环境变化中依然相关且高质量。
无论是强化还是进化，共同的核心都是有意图的设计。单纯部署 AI 工具本身并不会带来转型，但如果与务实且富有远见的系统层级变革相结合，AI 的采纳就能成为重塑软件构建、交付与安全方式的催化剂。
如何开始：AI 转型的实用步骤
一个组织越早将 AI 采纳视为一项转型工作，就越能掌控这场转型的展开方式。技术正在快速演进，但真正的差异化在于组织的应对能力。在旧流程围绕新工具固化之前着手，意味着组织能够主动塑造其系统的未来，而不是被动接受。
自然而然的第一步，是审视工作当下的实际流动方式。在实践中，这意味着要建立共享的可见性，展示从创意产生到最终交付的全过程。这一过程通常被称为价值流管理（VSM），它能帮助团队可视化交付的每一个阶段，从编码、代码审查到测试、部署与上线。
如果执行得当，工作流映射能够揭示协调成本的消耗过程、延误和返工频发的环节，以及系统吸收或阻滞 AI 工具带来加速效应的位置。它能帮助聚焦于那些约束理论（Theory of Constraints）所指出的、最能释放价值的因素。
为了开始绘制工作流，组织可以组建由日常软件交付中的一线实践者组成的小型跨职能工作组，其中包括工程师、产品经理、数据工程师、运维和安全人员。这些小组最有条件从内部出发，绘制系统，揭示协调失效与瓶颈，并识别 AI 可以发挥变革性作用的地方。
这些努力在获得高层支持时最为有效。高层的背书能够传达战略重要性，确保资源投入，并为从探索到行动提供清晰路径。这些工作组的使命是提出战略性建议：系统应在哪些地方适应以容纳 AI？AI 能在哪些流程或角色中发挥增强作用？需要发展哪些能力才能释放长期价值？
在某些情况下，外部的引导者或顾问可以帮助推动流程，提供基准，并让讨论聚焦于能够释放更广泛改进的系统性机会。
要让变革真正扎根，洞察必须来自系统内部。当实践者推动探索，而领导层承诺支持结果时，有意义的转型条件就会逐渐成形。
关键在于，这项工作必须以系统思维来开展。正如前文所述，组织是复杂系统，仅仅改善某一个节点（例如加速代码生成）并不能提升整体绩效，除非相邻的组件也能同步演进。DORA AI 能力模型为哪些组织层面的干预能够放大 AI 的收益提供了洞见。
例如，一个工作组可能发现，尽管 AI 工具能够提供有价值的建议，但它们经常会生成缺乏关键上下文的回应，比如团队约定、架构历史或以往的事故。对许多组织来说，这或许并不意外，因为这些信息通常散落在不同系统和非正式的知识渠道中。
作为应对，工作组可能会建议以结构化且安全的方式，将内部文档、决策记录和历史工单暴露给 AI 模型。他们还可能提议构建自动化工作流，用于自动标记并呈现这些信息。
在开发或评审期间呈现这些上下，可减少开发者用于搜索的时间，并提升 AI 输出的质量。或者，工作组也可以探索如何利用 AI 识别过时文档、总结冗长的项目讨论，以及检测系统实际行为与文档宣称之间的不一致。
这样做有助于将碎片化的知识转化为结构化、可执行的资产。除了流程层面的变更，这些工作组还可以揭示对新技能和新角色的需求。随着开发者将更多工作委派给 AI 工具，验证、编排与工作流设计等任务将变得更加核心。组织需要界定这些角色的职责形态，如何给予支持，并相应地对齐激励机制。
这包括提供超越“工具使用”的定向培训，帮助理解 AI 如何改变开发工作的本质。上述变化既不会自动发生，也不会一蹴而就，它们需要清晰的意图、明确的所有权以及持续的支持。不过，它们并不要求一开始就做到完美。当组织从小处着手、带着明确目的进行投入，并在各角色之间建立共同的责任机制时，就能形成推动力。一步一步、能力叠加，转型便会生根落地。
文化转型与工具同样关键。成功不仅需要引入自动化和度量，还需要让团队围绕共同的目标与责任达成一致。
AI 是镜子，也是放大器
AI 有潜力重塑软件的构建方式，但它本身并不会改变组织系统。它往往做的事情——而且通常发生得很快——是反映这些系统实际的运作方式。在高度一致的组织中，AI 会放大流动；而在支离破碎的组织中，AI 会暴露痛点。具备强大实践、灵活工作流和共享上下文的团队，往往能立刻看到收益。依赖脆弱流程和隐性知识的团队，则可能发现这些缺口比以往更加明显。
这就是为什么 AI 同时扮演 镜子 和 倍增器 的角色。它能照亮正在发挥作用的部分，加速已有的动能，同时也会显现出需要改变的地方。对于愿意直面这种映射的组织来说，AI 提供的反射可以成为一份路线图。正如我们在过去的其他转型中所见，那些愿意将 AI 采纳视为改进工作方式契机的组织，才会收获最大收益——既来自工具本身，也来自工具所促成的转型。
AI：技能发展的威胁与机遇
在技能发展的层面，软件行业与其他职业类似。专业知识理应自高级员工向初级员工传递，而新鲜的视角和技能则理想地能够自下而上涌现。高级开发者不仅仅是审查拉取请求（pull requests），他们还在教导初级开发者如何进行架构性思考。结对编程不仅仅是发现缺陷，它更是传递那些难以文档化的隐性知识。最理想的情况下，初级—中级—高级的“三代模式”能让开发者通过联合解决问题来获得技能，而不仅仅依赖正式培训。
我们需要深入研究 AI 部署对这一“理所当然”的过程所带来的影响。我的职业生涯一直在研究智能自动化与技能问题，覆盖 31 个以上的职业，结果表明：智能自动化的默认使用改变了传统的学徒制模式，使得新手缺乏参与那些对成长至关重要的实际工作机会。专家们可以自给自足，于是他们就这么做了。少数初级员工尽管存在这种参与障碍，仍能学到东西，但大多数却举步维艰。自 2023 年以来，我专注研究 AI 在复杂任务执行中的应用，最近聚焦于软件工程，早期发现同样呈现出这一模式。
但也存在一些有趣的例外，而且我们还需要更多的理解。与以往的革命性技术类似，从印刷术、个人计算机到互联网，AI 正以前所未有的速度被开发与部署。而我们尚不清楚人类能力将如何适应这些变化。
相反，许多人只专注于衡量与 AI 相关的生产力。我们追踪采纳率、生成的代码行数、合并的拉取请求数量——而不是衡量技能发展的指标，例如语言风格或表达多样性随时间的演变。
最优秀的组织会同时优化员工的生产力和技能发展。事实上，在我一些研究中，只有在坚持同步进行技能发展的前提下，才实现了卓越的生产力。同时衡量并推动生产力与技能发展，才是实现可持续绩效的道路。
AI 已经成为软件开发未来的重要组成部分——这也包括技能发展。例如，我们可以利用 AI 分析开发者与 AI 的交互，将其与版本控制的交互关联，再进一步与技能和关键工作成果挂钩。过去这在成本上不可行，但如今 API 的标注成本正在迅速下降。有了 AI，我们可以获得所需的洞察，重构工作，并为开发者提供指导，帮助他们保持学习优势，同时帮助他人做到同样的事。
默认的 AI 使用模式正在带来突破性的生产力，同时却阻碍了大多数开发者的技能发展。为了保持我们的创新优势——无论是个人还是集体——我们需要利用 AI 本身来同时衡量技能发展与生产力。
度量框架
选择与组织目标匹配的度量框架
衡量软件开发可以帮助推动有影响的变革。然而，这是一项复杂的任务，起步时可能令人望而生畏，因为它涉及理解应该测量什么，以及能够测量什么。
最重要的一点是，你希望通过度量来推动组织的变革。为此，我们建议使用框架来指导你的度量策略。
一个框架会将一个宽泛的主题（例如开发者体验）拆解为可以测量的具体概念（如速度或满意度）。在业界和学术界谈及软件开发的度量时，常常会引用一些框架，例如 SPACE、DevEx、HEART，以及 DORA 的软件交付指标。选择一个框架来衡量软件开发可能是一个困难且令人困惑的步骤，但并非必须如此。
第一步是要明确度量将为哪些目标和决策提供参考，因为不同框架在总体目标上各有侧重。 例如，软件开发中的常见框架分别聚焦于衡量：
开发者体验
产品卓越性
组织效能
这些总体目标对理解软件开发都有所不同的视角。
要确定哪种框架最适合你们组织的目标，把框架视对背后的“原因”进行度量会有所帮助。它们帮助你明确为什么要进行度量，并指导你根据目标，选择行动。框架提供了使你能够观察数据的视角，确保你的投入与组织目标保持一致。要决定采用哪种框架，可以考虑以下问题：为什么是现在？是否有某些变化要求进行度量？你将如何利用这些洞察？是否有决策或改进可以通过度量来实现？
接下来，“度量什么”指的就是具体的指标——那些支撑整体框架的关键概念，例如速度指标或采纳率指标。通常，你可以采取两种不同的数据收集方式。这就是数据收集的“如何”，它将帮助你得到相应的指标。
自报告数据涉及直接从开发人员那里收集他们的经验信息。这可以通过以下方式实现：
调查问卷：通过提问收集意见、满意度以及对工作的各种感受。
访谈与焦点小组：通过一对一或小组讨论，更深入地探讨具体的经验和主题。
日志研究：在实际环境中收集关于活动、想法和体验的数据。
自报告数据的优势在于，它能够捕捉通过自动化手段难以量化的主观体验和概念，例如满意度、幸福感或感知到的有效性。其一个关键优点是通常不需要大量的工具埋点或对开发者工具链的深度可观测性。然而这种数据也存在挑战，比如在标准化、跨团队可比性以及在大型组织中的可扩展性方面的困难。其固有的主观性意味着差异化，并且更容易受到偏差的影响（包括回忆偏差和社会期许偏差）。
基于日志的度量是自动从开发人员使用的工具和系统中收集的。这些可以包括以下类型的指标：
数量型：用于统计特定产出。例如，提交次数或用户数量。
基于时间型：用于记录在某项活动上花费的时间。例如，编码或代码审查的时间。
频率型：用于衡量特定时间窗口内的发生率。例如，每月的部署次数，或每位开发者每周提交的 PR 数量。
基于日志的度量的主要好处是，它们能够在大规模场景中提供持续测量和标准化的数据，并且能呈现活动和产出的详细视图。但它们需要对开发者工具链有足够的可观测性，也就是说，必须具备必要的集成与数据收集机制，这可能会形成较高的使用门槛。此外，一个常见的误区是认为基于日志的指标是客观的。事实上，埋点方式各不相同，错误可能导致不准确，而解释也容易受到偏差影响。
框架会为你提供需要衡量的概念，但最终实施什么，取决于你们的资源以及可获取的数据。你是否具备对工具链的可视性来支持基于日志的方法？是否有研究团队来支持自我报告数据的收集？重要的是要认识到，并非所有组织都拥有相同的资源和能力去按照某个特定框架推荐的方式来实施指标。
即使存在组织层面的限制，框架依然是一种指引，是帮助你更好理解复杂行为的透镜——但它们无法完全捕捉这种行为。它们的目的是让你更接近事实，但不应期望能够测量一切。
在考虑框架和指标之间的关系时，把指标看作食材，把框架看作利用这些食材做出的食谱会很有帮助。一些核心食材可以通过不同方式组合，形成不同的食谱（即框架），而另一些食材则是某个特定食谱所独有的。
做出的菜肴味道各不相同，但其中一些底层食材是共享的。在很多情况下，即使没有所有的食材，也能做出味道不错的菜。
框架的差异在于它们旨在推动不同的结果，但它们的一些底层指标是重叠的。下图展示了一些组成框架的指标，以及它们常见的重叠。例如，生产力指标（如代码提交或拉取请求）可能会被三个框架同时度量。
一个组织可能会利用这些指标来衡量新的团队结构的影响（组织效能）、评估某个开发工具的有效性（产品卓越），以及理解开发者的工作负荷（开发者体验）。
相对而言，有些指标更具专属性。开发者幸福感，往往是开发者体验框架中的关键组成部分，但通常并不是组织效能或产品卓越框架中的主要指标。
选择使用单一框架有助于聚焦你所采取的行动，也是一个良好的起点。然而，也不必局限于只使用一个框架。随着目标和衡量能力的变化，使用多个框架能够帮助形成互补的分析结果，从而使整体强于部分之和。重要的是，你要将衡量作为让自己和组织对目标负责的一种方式，并确保能够基于所衡量的结果采取行动。
在 AI 时代使用度量框架
你可能会想，AI 引入到开发流程中是否会改变一切？现有的框架是否仍然适用，还是我们需要新的框架？当出现技术性颠覆时，似乎有必要彻底推翻现有的指标收集策略。我们建议仔细思考实际需要改变的是什么，尤其是在考虑 AI 的影响时。为了更好地理解 AI 如何影响开发者体验，可能只需要更新少量指标，就可以保持整体衡量的一致性。你无需抛弃整个框架，而是可以利用现有的度量作为基线，来帮助识别范式转变如何改变开发者体验。例如，你可能需要增加关于 AI 建议接受率、模型质量或信任度的指标，同时保留现有的开发者体验度量，如感知生产力和代码审查所花费的时间。
随着 AI 的进一步发展，谁在执行开发任务，以及这些任务是什么，都会发生变化。因此，度量方法可能需要适应不同的用户角色，并捕捉变化中的工作流，但衡量开发者体验背后的核心目标很可能并未改变。关键在于，如果你的总体目标保持不变，就不需要更换框架；通过扩展指标也能适应技术上的变化。即使你的目标发生变化，也不一定意味着要从零开始一个新的度量计划。由于指标可以服务于不同的框架，你通常可以快速应对，并重新组合这些指标，以支持新的或额外的框架。例如，理解 AI 驱动的开发工具对代码产出的影响，可能是组织以前未曾面对的新目标。这尤其具有挑战性，因为我们要在变化发生的同时进行度量。
组织普遍面临的一个问题是 AI 对代码质量的影响。随着 AI 被用于提升开发者速度，人们特别担心是否在以牺牲质量换取速度。这种短期的速度提升看起来是积极的；然而，如果质量较低，长期来看可能会对速度产生负面影响。为了解决这些担忧，你的目标可能是确保在推动 AI 工具采纳的同时，组织的代码质量依然保持高水准。这个目标涉及前面讨论过的各类框架的要素，并且可能包含你已经在采集的指标（如代码质量、工具采纳率或感知速度）。因此，你可以继续使用现有的指标，同时引入新的指标。例如，将 DORA 的软件交付指标与 HEART 这样注重产品卓越的框架结合起来，可以有效理解开发者在使用新的 AI 工具时的体验，以及其对软件交付的影响。
软件开发的度量是一个复杂且持续的过程。虽然有许多框架和度量方法可供选择，但你必须能够基于所衡量的结果采取行动。确保行动有效的关键环节之一，是与组织目标保持一致，并获得领导层对度量工作的支持。
在选择框架和指标时保持有意图性，有助于为长期成功奠定基础。秉持采用框架以满足特定目标的精神，可以考虑如何根据 PDCA 框架来行动：
Plan（计划）：明确目标，选择框架，并获得领导支持
Do（执行）：收集一些基线指标，尝试不同做法
Check（检查）：再次测量，看看你朝目标前进的程度
Adjust（调整）：利用你的发现来改进后续的方法
我们并不是在推荐某一个框架优于其他框架。根据你的目标来确定合适的框架，可以帮助指导你衡量什么，以及如何采取行动。选择与组织契合的框架。如果它能打动你，并促使组织采取行动，那就是当下合适的框架。
虽然框架提供了指导性的结构，但许多底层的度量是相同的。这意味着你今天实施的度量，往往可以在未来根据需求和目标的演变进行调整和再利用。
最后的思考：从洞察到行动
十多年来，DORA 一直是软件开发社区值得信赖的合作伙伴，提供研究与洞察以帮助团队改进。随着行业因 AI 和平台工程等新技术的采用而快速发展，我们的承诺始终如一：研究并分享能够促进高绩效团队的实践。
DORA AI 能力模型
今年，我们推出了首个 DORA AI 能力模型，这是我们研究的重要演进。随着各组织在 AI 采用过程中应对复杂性，该模型提供了一个数据支持的框架来指导他们的旅程。它突出了七项关键能力，这些能力在得到培养时，可以增强 AI 对重要组织成果的积极影响。
这些能力包括：
清晰且已传达的 AI 立场
健康的数据生态系统
可供 AI 访问的内部数据
强有力的版本控制实践
小批量的工作方式
以用户为中心的关注点
高质量的内部平台
该模型是我们的首次迭代，我们将其视为与 DORA 社区以及采用 AI 辅助软件开发的组织持续对话的起点。我们渴望从你们在应用这些洞察时的经验中学习，并期待在未来的研究中对该模型进行验证和完善。
关注用户
今年的研究揭示了一个关键洞察：我们仍处于 AI 辅助软件开发的初期阶段，这是一个技术和实践快速演进的时期，过早进行标准化并不合适。我们的研究发现，仅仅部署 AI 工具并不是转型的万能药。事实上，AI 对团队能效的影响高度依赖于一个关键因素：以用户为中心的关注点。
我们以高度的确定性发现，当团队采取以用户为中心的关注点时，AI 对其绩效的积极影响会被放大。相反，如果缺乏以用户为中心的关注点，AI 的采用可能会对团队绩效产生负面影响。
这一发现传达了对所有组织都至关重要的信息：对终端用户的深入理解进行投入和培养，不仅仅是有益的，而是成功应用 AI 的前提条件。如果你的战略中没有将用户置于核心，AI 的采用不仅不太可能带来帮助，甚至可能降低团队能效。
将研究付诸实践：轮到你来试验了
今年报告中的发现是复杂的，有时甚至看起来相互矛盾。这反映了一个不断变化领域的现实。我们鼓励你将这些发现视为你自己实验的假设，而不是僵化的规定。
以下是一些将研究付诸实践的方法：
在组织中运行实验：利用 DORA 的发现来制定假设，并在你的团队中进行测试。这将帮助你更深入地了解你们特定的运营环境，并识别出最具影响力的改进领域。
开展内部调研：从今年调研中使用的问题中获取灵感，设计你自己的问卷。结合更细致的问题，使其与团队和项目直接相关。
拥抱整体体验：记住，仅仅改进单个功能无法修复一个存在缺陷的平台。要把内部平台当作产品来看待，关注整个开发者旅程，从反馈循环到自动化。
分享你的学习成果：在你开展自己的实验并收集洞察时，把这些知识在组织内部传播开来。这可以通过正式的报告、非正式的实践社区，或是日常交流来实现。目标是培育一种持续学习的文化。
在这个不断发展的环境中，最大的风险并不是落后，而是大量投入于混乱的活动却无法带来有意义的成果。请选择与你们组织契合、并能促使你们采取行动的框架和方法。