AI 让个人更快，为什么团队不一定更快？——2026 年重读 DORA 2025

最近，我第一次完整读到 Google DORA 团队发布的《2025 年 AI 辅助软件开发现状》。

它发布于 2025 年 9 月。等我在 2026 年 7 月看到时，第一反应是：有点晚了。过去十个月，AI 编程已经从代码补全、对话问答，走到可以连续读取代码库、修改文件、运行测试和提交结果的智能体工作流。报告中不少采用率数据，显然不能直接代表今天。

但读完 142 页英文完整版，我改变了判断。

DORA 2025 最值得看的，不是“多少人在用 AI”，而是它抓住了一个到今天仍未解决的矛盾：

AI 可以让个人更快，却不保证团队更快，更不保证软件交付更稳。

模型能力继续提高，这个矛盾没有消失。它只是从“AI 会不会写代码”，转移到了“组织能不能接住更快产生的代码”。

一组已经过时的数据，留下了一个没有过时的问题

DORA 的调研发生在 2025 年 6 月 13 日至 7 月 21 日，共有 4,867 名技术从业者参与。

报告给出了几组很醒目的数字：

• 90% 的受访者已经在工作中使用 AI；
• 超过 80% 的人认为 AI 提高了自己的生产力；
• 59% 的人认为 AI 对代码质量有正面影响；
• 30% 的人对 AI 生成内容只有很少信任，或者完全不信任。

来源：Google DORA《AI 辅助软件开发现状 2025》中文精编版，第 12 页，图 24—25。

这些数字描述的是 2025 年中期。尤其是报告中“61% 的受访者从不使用智能体模式”这一项，放到 2026 年已经只能当作历史快照。

不过，报告同时发现，AI 采用与个人效能、代码质量、团队绩效、产品表现和软件交付吞吐量呈正向关系，却仍然伴随着更高的软件交付不稳定性。

来源：Google DORA《AI 辅助软件开发现状 2025》中文精编版，第 20 页，图 28。橙色指标上升并非期望结果。

这比采用率更有意思。

代码写得更快了，交付为什么还会变得不稳定？

因为软件开发从来不只有写代码。需求要澄清，变更要审核，测试要执行，系统要集成，版本要发布，故障要恢复。AI 加速了其中一个环节，新增的工作量会继续向后流动。

如果下游没有同步变化，个人节省的时间就会变成别人的审核压力、测试等待和返工。

写代码变快，不等于价值流动得更快

这份报告有一个很准确的表述：AI 会制造“局部生产力口袋”。

一个开发者一天可以生成更多代码，不等于团队一天可以安全交付更多价值。局部速度只有穿过完整工作流，才会成为产品结果。

把效率拆成四层，问题就清楚了：

| 层级 | 看起来变快了什么 | 还需要回答什么 | | --- | --- | --- | | 个人 | 起草、编码、解释、检索更快 | 结果是否正确，是否值得保留 | | 团队 | 任务和变更数量增加 | 审核、测试、协作能否跟上 | | 交付 | 部署更频繁 | 失败率、返工和恢复成本是否上升 | | 组织 | AI 使用率和工具投入增加 | 用户价值和经营结果是否改善 |

过去谈研发效率，很容易盯着完成了多少任务、提交了多少代码。AI 让这种衡量方式变得更危险。

代码现在可以低成本生成。更多代码不再天然代表更多工作成果，有时只代表更多需要阅读、验证和维护的东西。

因此，DORA 在 2026 年 6 月专门讨论了“tokenmaxxing”：一些组织用 token 消耗量和排行榜推动 AI 使用，看上去很积极，实际奖励的是输入规模，而不是交付结果。token、对话次数、生成行数都可以帮助观察采用情况，却不能单独证明生产力。

判断生产力，仍要看变更交付时间、返工率、故障恢复、产品质量和用户结果。

AI 更像一面镜子，也是一台放大器

DORA 2025 的核心判断是：AI 不会自动修复团队，它会放大团队原有的状态。

边界清楚、测试充分、文档可用的团队，会从 AI 获得更大收益。流程松散、知识分散、系统脆弱的团队，则会更快积累技术债。

这和我们使用 AI 推进工程软件的经验很接近。

当接口明确、输入完整、验收标准可执行时，AI 可以快速完成实现、补测试和检查遗漏。只要任务边界含糊，它也会很快生成另一套状态、另一条兼容分支和另一份“差不多”的事实。

问题通常不是某一段代码写错了。更麻烦的是每一段局部代码都能运行，系统整体却越来越难解释。

我们此前在《AI Agent 越能替你做事，你的资料为什么越不能乱？》一文中讨论过这个问题。同样，一次生成结果看起来再完整，也不能让同一个模型同时承担产出和独立复核。这个边界，在《为什么不该让同一个 AI 模型既参与设计，又参与独立复核》中有更具体的说明。

AI 把原来需要几周才暴露的问题压缩到了几天。这未必是坏事。至少它让组织更早看到自己的真实能力。

七项能力，比模型排行榜更值得保留

DORA 从 78 次深度访谈和 15 项候选能力中，识别出七项能够影响 AI 使用效果的组织能力：

来源：Google DORA《AI 辅助软件开发现状 2025》中文精编版，第 38 页，图 45。连线表示相应能力会放大 AI 采用对该结果指标的影响。

| 能力 | 它实际要求团队做到什么 | | --- | --- | | 清晰传达 AI 立场 | 明确哪些工具能用、哪些数据不能输入、哪些任务必须人工确认 | | 健康的数据生态 | 内部数据准确、可访问，不长期散落在彼此隔离的系统中 | | AI 可访问的内部数据 | 让 AI 安全读取代码、文档、决策记录和项目上下文 | | 健全的版本控制 | 小步提交，能够比较、撤销和恢复变更 | | 小批量工作 | 把任务拆成可审核、可测试、可独立交付的单元 | | 以用户为中心 | 用真实用户问题约束生成速度和功能数量 | | 高质量内部平台 | 给团队提供统一的测试、构建、发布、权限和可观测能力 |

这七项能力没有哪一项要求采购更强的模型。

它们讨论的是环境：AI 在什么样的组织里工作。

其中两个发现，值得研发团队认真对待。

第一，小批量工作可能会削弱开发者对“个人效率提升”的感受，却能改善产品表现并减少工作摩擦。原因不难理解：限制单次变更规模，会让 AI 少生成一些，也会让结果更容易审核、测试和撤销。

第二，在缺少用户导向的团队里，AI 采用甚至可能损害团队绩效。方向错了，速度越快，偏离得越远。

这两点都在提醒我们：个人产量不是最终目标。研发效率必须回到产品和交付。

2026 年的新材料，没有推翻这个判断

2026 年 3 月，DORA 又发布了一次后续分析。研究人员整理了 1,110 份 Google 软件工程师在 2025 年第三季度提交的开放反馈。

AI 在代码生成、信息检索、代码审核和测试中都能提高启动速度。但工程师也反复提到另一面：写代码省下来的时间，经常重新花在提示、等待、审核和验证上。

DORA 把它称为“验证税”。

METR 在 2025 年开展的一项随机对照实验也提供了一个值得警惕的参照。16 名熟悉自己开源项目的资深开发者完成了 246 个真实任务。使用当时的 AI 工具后，他们平均多花了 19% 的时间；实验结束后，他们仍然认为 AI 让自己快了约 20%。

这个小样本不能代表所有开发者，也不能代表 2026 年的模型能力。它真正提醒我们的是：主观上感觉更轻松、更流畅，不等于完整任务真的更快。

DORA 的方法也有边界。完整报告用了因果图、结构方程和贝叶斯模型，并报告 89% 可信区间。但数据主要来自观察性调研和自我报告。研究团队自己将结果称为“有原则的比较”，而不是已经证明的普遍因果关系。

所以，这份报告适合帮助团队提出假设，不适合拿几组平均值直接给自己的 AI 投资下结论。

企业现在可以先检查四件事

不必等 2026 年年度报告，也不必先建设一套庞大的 AI 管理平台。

研发团队可以从四个问题开始。

1. AI 生成的变更，能不能回到证据

每次修改要能看到输入、差异、测试结果和人工确认状态。重要任务不能只留下最终代码，更不能只留下模型的一句“已经完成”。

2. 单次任务是不是足够小

任务最好能被一个人理解，变更可以独立审核，失败以后可以撤销。Agent 能连续工作数小时，不代表团队应该接受一个无法分段检查的大提交。

3. 验证能力有没有跟着生成能力增长

如果 AI 让代码量增加了一倍，测试、静态分析、代码审核和真实运行验证仍然维持原样，风险只是被推迟了。

验证应尽量前移给变更作者。让 AI 在提交前运行测试、检查契约和解释风险，比把所有压力留给最终审核者更有效。

4. 衡量的是使用量，还是结果

AI 活跃用户数和 token 消耗可以观察推广情况。判断价值，还要看交付时间、返工、故障、成本、产品质量和用户反馈。

如果一项指标很容易通过“让 Agent 多跑几个任务”提高，它就不适合成为绩效目标。

等待 DORA 2026，我更想看这几个问题

截至本文写作时，DORA 还没有发布 2026 年度报告。与其猜测新的采用率，我更关心几件事：

• 智能体从辅助编码走向连续执行后，软件交付不稳定性有没有下降；
• 生成端与审核端之间的工作量是否出现更明显的转移；
• 小批量、回滚和自动化测试能否继续抵消 Agent 大规模修改的风险；
• 企业会不会从“推动所有人使用 AI”转向“让不同任务使用合适的 AI”；
• AI 投资回报能否从自我感知，走向可重复的交付和产品证据。

这些问题的答案可能会变。DORA 2025 的具体效应值也可能被后续研究修正。

但它留下的判断不会很快过时：

AI 提高的是可实现的速度，组织决定这些速度最后变成价值、返工，还是风险。

模型还会继续进步。团队真正需要建设的，是承接这种速度的能力。

如果你的团队正在评估 AI 编程

如果你的团队正在把 AI 或 Agent 接入真实研发流程，欢迎通过文末入口或平台私信，简单说明当前任务、代码和知识资料的组织方式，以及现有测试和发布条件。我们可以先判断，问题更适合从工具使用、上下文治理，还是交付验证入手，并评估是否值得做一次小范围流程检查。

参考资料

以下资料均可按英文标题检索：

1. Google DORA：《State of AI-assisted Software Development 2025》，2025。
2. Google Cloud：《Announcing the 2025 DORA Report》，2025-09-23。
3. Google DORA：《Balancing AI tensions: Moving from AI adoption to effective SDLC use》，2026-03-10。
4. Google DORA：《Finding balance in the era of tokenmaxxing》，2026-06-02。
5. METR：《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》，2025-07-10。

关注我们

欢迎搜索并关注 筑见实验室，获取更多建筑 AI、工程软件与数字化工作流实践：