AI 编程工具越来越强，写代码的速度也越来越快。
但有一个问题值得思考：如果每个人的工作效率都提高了，整个团队的效率是不是也会同步提高？
2025 年，Google 发布了《State of AI-assisted Software Development 2025》，试图回答这个问题。
报告有一个值得关注的结论：AI 是放大器，而不是修复工具。 它可以放大组织原有的优势，也可能让原本存在的问题更加明显。
一、DORA 是什么？为什么值得关注？
DORA，全称 DevOps Research and Assessment，中文通常译为「DevOps 研究与评估」。它从 2014 年开始研究软件交付与组织绩效，后来成为 Google Cloud 推动的重要研究项目。
DORA 最初关注的是：为什么有些研发团队既能快速交付，又能保持较高的软件质量？
为此，DORA 提出了四项经典的软件交付指标：
| 指标 | 衡量什么 |
|---|---|
| 部署频率 | 软件多久发布一次 |
| 变更前置时间 | 代码从提交到生产部署需要多久 |
| 变更失败率 | 有多少次部署导致生产故障 |
| 服务恢复时间 | 发生故障后多久恢复 |
前两项关注速度，后两项关注稳定性。这套指标背后的思路并不复杂：代码写得多，不代表交付得快；交付得快，也不代表质量好。
随着 AI 进入软件研发，DORA 的研究延伸到了一个新问题：AI 提高了开发者的效率，能否进一步提高团队和组织的绩效？
二、DORA 2025 发现了什么？
这份报告调查了全球近 5,000 名技术专业人士，并结合超过 100 小时的定性研究。
| 研究指标 | 主要发现 |
|---|---|
| AI 使用率 | 90% 的受访者在工作中使用 AI |
| 个人生产力 | 超过 80% 的受访者认为 AI 提高了生产力 |
| AI 代码信任度 | 约 30% 的受访者很少信任或完全不信任 AI 生成的代码 |
AI 已经成为常见的开发工具，但效率提升与信任问题同时存在。
过去需要两个小时编写的代码，现在 AI 可能几分钟就能生成初稿。但开发者仍然需要理解代码、检查逻辑、验证边界条件，并确保它能融入现有系统。代码生成时间减少了，不代表整个任务的完成时间同比例缩短。
更值得关注的是软件交付层面的变化：DORA 2024 发现，AI 使用与软件交付吞吐量、稳定性均存在不利关联；到了 2025 年，AI 使用与交付吞吐量转为正向关联，但与交付不稳定性仍存在正向关联。这些结果反映的是统计关联，不能直接证明因果关系。
为什么会这样？因为软件研发不只有编码，还包括需求、设计、测试和发布。
假设一个需求从提出到上线需要 20 天，其中实际编码只有 4 天，其余时间用于沟通、等待和验证。即使 AI 将编码时间缩短一半，整体周期也只是从 20 天降到 18 天。如果测试和审查又出现积压，收益还会缩小。（此处为假设示例，并非报告数据。）
个人效率的提升，不一定自动转化为组织效率。 AI 可能解决了原来的开发瓶颈，却让其他环节的问题更加突出。
三、AI 是放大器，企业真正需要什么能力？
DORA 2025 的重要观点是：AI is an amplifier, not a fix.
对于需求清晰、测试完善、交付流程成熟的团队，AI 的开发效率提升更容易转化为实际交付能力。对于需求反复变化、文档不完整、测试依赖人工的团队，AI 生成更多代码也未必能解决原有问题，甚至可能加重后续环节的压力。
同样的 AI 工具，放在不同的组织环境中，可能产生完全不同的效果。
DORA 2025 提出的 AI Capabilities Model（AI 能力模型） 识别了七项重要能力：
| 核心能力 | 主要作用 |
|---|---|
| 以用户为中心 | 确保开发的是有价值的功能 |
| 完善的版本控制 | 让代码变更可追踪、可管理 |
| AI 可访问的内部数据 | 为 AI 提供业务和技术上下文 |
| 小批量交付 | 降低变更风险，加快反馈 |
| 清晰的 AI 使用政策 | 明确使用边界和组织预期 |
| 高质量内部平台 | 提供标准化、自动化的研发交付能力 |
| 健康的数据生态 | 保障数据质量、可用性和一致性 |
其中三点尤其值得关注。
以用户为中心： AI 降低了开发成本，却不会自动提高需求价值。如果没想清楚为什么做，可能只是更快地做了无用功。
AI 可访问的内部数据： 通用模型不了解企业的业务规则、系统架构和历史决策。高质量的知识库、结构化文档和内部接口，能为 AI 提供可靠上下文。这并不意味着某一种具体技术方案最优。
高质量内部平台： AI 生成代码后，还需要测试、安全检查、构建、部署和监控。如果这些环节依赖大量人工协调，开发节省的时间可能被后续流程消耗。这里的内部平台主要指研发交付平台，并不完全等同于大模型或智能体平台。
AI 的实际价值，不只取决于工具本身，还取决于组织能否承接它带来的变化。
四、对 AI 产品经理和企业 AI 转型有什么启发？
首先，要重新思考如何衡量 AI 的真实价值。
很多企业推广 AI 工具时，主要关注开通账号数、活跃用户数、使用频次和培训场次。这些数据可以反映推广效果，却不能直接证明 AI 创造了多少价值。
结合 DORA 的研究思路，可以分三层评估：
| 层次 | 参考指标 | 关注的问题 |
|---|---|---|
| 工具采用 | 活跃率、使用频次 | 员工是否真正使用 AI？ |
| 工作效率 | 任务完成时间、交付周期、返工率 | AI 是否提高了实际效率？ |
| 组织价值 | 交付吞吐量、变更失败率、业务响应速度 | AI 是否改善了最终结果？ |
这是结合 DORA 思路提出的实践建议，并非全部为 DORA 官方指标。实际评估还应结合基线、对照和具体项目结果。
其次，AI 原生研发可能需要重新设计整个流程。
现在很多实践集中在代码生成、自动测试和任务执行。但软件研发不只有执行：之前需要理解问题、明确需求和设计方案，之后需要验证效果、处理反馈并持续迭代。
如果需求本身不清晰，AI 只是加快了执行速度；如果缺少质量验证，生成更多代码也可能增加维护成本。
真正值得探索的，可能不仅是让 AI 承担更多开发任务，而是围绕 AI 重新设计需求、设计、开发、测试和交付之间的协作方式。
这是基于 DORA 研究的延伸思考，并非报告已验证的结论。
写在最后
DORA 2025 的价值，不在于证明 AI 到底能让开发者快多少，而在于提醒我们：个人效率提高，不等于组织效率一定提高。
AI 可以让开发者更快完成任务，却无法自动解决需求不清晰、流程不合理、数据质量差和协作成本高等问题。报告中的不少结论来自调查和统计分析，不能直接视为因果证明，但它提供了一种值得借鉴的视角。
过去，我们经常问：AI 能帮员工节省多少时间？
未来，或许更值得问：这些节省下来的时间，最终为用户和组织创造了什么价值？