AI 提效怎么衡量：大厂看的 6 个维度，和一套落地评估法

公司给全员开了 AI 编程工具，又自建了一个 AI 平台。年底老板问：到底提效了多少？多数团队能拿出来的只有「周活 80%」「AI 写了 40% 的代码」这类数字。这篇把 Google、微软/GitHub、Meta、Atlassian、DORA、DX、METR、麦肯锡等公开的衡量方法和研究结果放在一起，拆成 6 个维度，再给一套你在自己公司就能照着做的评估方案。

先说结论：没有一个数字能回答「提效了吗」

把各家的公开资料读下来，共识只有一条：单一指标一定会骗人。微软研究院和 GitHub 在 2021 年提出的 SPACE 框架，开篇就把「一个指标就能说明一切」列为误区，建议至少从三个维度各取指标、并且至少有一项是问卷类的感受数据。DX 的 Core 4 把速度、有效性、质量、业务影响四个维度放在一起看，理由也是速度指标单独使用会让人刷数。

到了 AI 时代，这个问题被放大了。DORA 在 2026 年 3 月的文章里直说：AI 很容易把代码量吹大，所以不能再拿「接受了多少行代码」这类产出指标当生产力。

AI 让「写」变快了，但「审、测、修、上线」没跟上的话，省下的时间会在下游被吃掉。

同一个问题，研究结论能差出 70 个百分点

先看最常被引用的几项研究。它们都在问「用 AI 写代码快不快」，答案却差很多，差别主要来自任务、人群和测量方法。

放在一起看能得出三条实用结论：一是标准化小任务上的提速，搬不到复杂真实工作上；二是人对自己快没快的感觉很不准，METR 里高估了约 40 个百分点，Peng 的实验里参与者自估 35%、实测 55.8%，偏差两个方向都有；三是现在连做对照实验都变难了，愿意「一半时间不用 AI」的人越来越少，样本会自带偏差。

组织层面：个人觉得快，公司账上看不到

研究看的是个人做任务的速度，企业更关心交付和收入，这两层的数据经常对不上。

• DORA 2025（近 5,000 名技术从业者问卷）：90% 的人在工作中用 AI，超过 80% 认为自己效率提高了，但 30% 对 AI 生成的代码几乎不信任。AI 采用度越高，软件交付吞吐越高，交付不稳定性也越高。2024 年那版更直接：AI 采用度每提高 25%，文档质量 +7.5%、代码质量 +3.4%、评审速度 +3.1%，交付吞吐却估计 −1.5%、交付稳定性 −7.2%。
• Atlassian 2026 开发者体验报告（1,500 多名从业者）：87% 的开发者说 AI 让自己交付更快，只有 28% 说日常摩擦明显减少；49% 每周要花 4 小时以上审 AI 产出、改提示词。
• 麦肯锡 2026 年 AI 现状调查（1,719 人，2026 年 5–6 月）：80% 的受访者说 AI 提升了个人效率，但认为 AI 对公司 EBIT 有贡献的只有 37%，和上一年基本持平；约 20% 说 AI 运营成本（含 token）已经在限制使用。

DORA 给这种现象的解释是「AI 是放大器」：平台、测试、流程好的团队，AI 帮它更好；底子差的团队，AI 帮它更快地制造技术债。

大厂内部看什么：从「AI 写了多少」到「交付了多少」

几家公司公开过的内部指标，基本都从采用量起步：

• Google：2024 年 6 月的研究博客写到，代码补全的接受率 37%，AI 辅助完成了 50% 的代码字符（分母是手敲字符加接受的 AI 字符，不含复制粘贴）。2026 年 4 月 Cloud Next 上，皮查伊说 Google 75% 的新代码由 AI 生成、经工程师批准，去年秋天是 50%。这两个数字口径不同，不能直接连成一条曲线。
• Meta：内部补全工具 CodeCompose 的论文报告，1.6 万名工程师使用，接受率 22%，8% 的代码来自它。同一篇论文自己也写了：接受率高不代表开发者更高效，这个要单独测。
• Atlassian（2026 年 5 月，自家产品 Rovo Dev）：抽 2,500 家客户的 3,400 个代码仓库，用倾向得分匹配找对照组、比较采用前后变化，结果是采用的仓库每月多合并 19% 的 PR；问卷里取第 20 百分位作为保守的节省时间，约每人每周 2–3 小时。它还建议上线 2–3 个月后再测，等新鲜感过去。
• DX（开发者效率咨询公司）的 AI 衡量框架把指标分成使用、影响、成本三类，并提醒：即使是领先企业，AI 工具的活跃使用率也大约只有 60%；指标不能用于个人绩效考核，否则会被刷。

趋势很清楚：采用率、接受率、AI 代码占比只能说明「有人在用」，说明不了「交付变好了」。讲究的做法都会配上对照组和质量指标。

6 个维度一张表

实操：你在公司搭了个 AI 平台，怎么判断有没有提效

下面这套做法综合了上面各家的方法。原则是：团队为单位、有对照组、速度和质量一起看、上线前就写好判断规则。

第 1 步：上线前先留基线

至少回溯 8–12 周的历史数据（这是我们的建议，季节性强的业务要更长），覆盖下面第 3 步里的全部指标。基线期内别同时搞别的大改动，比如换 CI、重组团队，不然以后分不清是谁的功劳。DX 也建议：系统数据一时接不全，就先用问卷把基线立起来。

第 2 步：该埋的数据

• AI 平台日志：匿名用户 ID、所属团队、工具/模型、会话和 Agent 任务数、token 用量与费用、建议接受/拒绝、由 Agent 发起的 PR（打标签）。
• Git：PR 创建、首次评审、合并时间，改动行数，评审轮次，revert 记录。
• CI/CD：构建成功率、构建时长、每次部署记录。
• 事故/工单：哪次部署引发回滚、热修或事故，恢复用时；需求从「开始」到「上线」的时间。

Agent 发起的 PR 要算进它所服务的团队，DX 的建议是把 Agent 当作团队的延伸，而不是单独的「员工」。

第 3 步：指标和公式

第 4 步：对照设计，别只比「上线前 vs 上线后」

只比前后，季节、业务节奏、换人都会混进来。可选的设计，从强到弱：

1. 分批随机上线：把团队随机分成几批，每隔几周开一批。还没开的批次就是天然对照组，最后所有人都能用上，阻力小。微软、埃森哲那几场现场实验就是随机给权限。
2. 双重差分（DiD）：做不到随机，就找条件相近、暂时不上线的团队当对照组，比较「试点组的前后变化」减去「对照组的前后变化」。
3. 匹配对照：用规模、历史吞吐、技术栈等给每个试点团队配一个相似团队，Atlassian 用的倾向得分匹配就属于这类。

以团队而不是个人为单位分组。同一团队里有人用、有人不用，评审和协作会互相影响，个人层面的对比会失真。

第 5 步：问卷只要 5 题

1. 上周 AI 工具大约帮你节省了多少时间？（0 / 不到 1 小时 / 1–2 / 2–4 / 4–8 / 8 小时以上）
2. 上周你花在核对、修改 AI 产出上的时间大约多少？（同上档位）
3. 你对 AI 生成内容的信任程度？（1–5 分）
4. 如果明天收回这个工具，对你的工作影响多大？（1–5 分）
5. 上周最有用和最没用的一个使用场景各是什么？（开放题）

注意三点：问「上周」这种具体时间段，别问「平均」；结果只按团队汇总，不看个人；第 1 题要减去第 2 题再用，并且取保守分位数。别把问卷数字当成实测，METR 已经证明感觉可以和实际方向相反。

第 6 步：样本量和时长

样本太少，看到的提升可能只是噪声。我们用一组示例数据在本机跑了下面的脚本：试点组和对照组各 120 个 PR 时，试点组中位周期从 27.0 小时降到 21.4 小时（−21%），双重差分估计 −6.2 小时，但 95% 区间是 [−12.1, +2.8]，跨过 0，还不能下结论；每组加到 480 个 PR，估计 −3.8 小时，区间 [−6.8, −0.3]，才不跨 0。

时长上，DORA ROI 计算器默认按「效率下降 15%、持续 3 个月」来估 J 曲线，Atlassian 建议上线 2–3 个月后再测。实操上建议观察期至少一个季度，第一个月的数据单独标出来，不进最终结论。

第 7 步：看板分四块

第 8 步：上线前写好判断规则

• 扩大：速度指标的双重差分改善、区间不跨 0；质量护栏不恶化（比如变更失败率上升不超过 1 个百分点、返工率不升）；每节省 1 小时的成本低于人力时薪。
• 先修流程再扩大：速度变快但质量变差。把钱投到自动化测试、小批量提交、给作者端加 AI 自检，DORA 给的方向也是这几项。
• 换工具或换场景：过了 J 曲线窗口（比如一个季度）速度仍无改善，问卷信任度低、「收回影响」得分低。

阈值数字按你们的业务定，但一定要在看数据之前定下来，事后再定就成了挑对自己有利的数。

两段示例计算

示例 1：成本账（示例数据）。100 人研发团队，每人每月许可加 token 300 元，平台运维摊销每月 2 万元，月总成本 5 万元。问卷保守值每人每周省 2 小时，按人力成本 150 元/小时算，月价值 100 × 2 × 4 × 150 = 12 万元，ROI =（12 − 5）÷ 5 = 140%。如果真实节省只有自报的一半（每周 1 小时），价值 6 万元，ROI 只剩 20%。这笔账对「节省时间」这个输入非常敏感，所以要和实测的吞吐变化互相印证。

示例 2：J 曲线有多要命。我们用 DORA 在 GitHub 上开源的 ROI 计算器公式复算了它的默认场景：500 名工程师、人均全成本 17.6 万美元、AI 让每人省 12.5% 时间，同时假设变更失败率从 5% 升到 6%。J 曲线按 15% 降幅、3 个月算，首年投入约 837 万美元、价值约 1,165 万美元，ROI 约 39%，回本约 8.6 个月；其中变更失败率上升带来约 34 万美元的停机损失。只把 J 曲线拉长到 12 个月，ROI 变成约 −36%。这些都是计算器的假设值，不是任何公司的真实数据。

本机实测：用 CSV 算试点组 vs 对照组

下面的脚本只用 Python 标准库。输入是一份 PR 明细（pr_id, group, period, opened_at, merged_at，group 取 pilot/control，period 取 before/after），输出两组的中位周期变化、双重差分估计和自助法 95% 区间。2026-10-21 在本机用 Python 3.13.5 跑过，数据是脚本随机生成的示例数据。

import csv, sys, random, statistics as st
from datetime import datetime

def load(path):
    data = {}
    for r in csv.DictReader(open(path, encoding="utf-8")):
        h = (datetime.fromisoformat(r["merged_at"])
             - datetime.fromisoformat(r["opened_at"])).total_seconds() / 3600
        data.setdefault((r["group"], r["period"]), []).append(h)
    return data

def did(d):
    m = {k: st.median(v) for k, v in d.items()}
    return ((m[("pilot", "after")] - m[("pilot", "before")])
            - (m[("control", "after")] - m[("control", "before")])), m

data = load(sys.argv[1])
effect, med = did(data)
print(f"DiD 估计：中位周期变化 ≈ {effect:+.1f} 小时")

random.seed(0); boots = []
for _ in range(2000):   # 自助法重抽样，看结论稳不稳
    s = {k: random.choices(v, k=len(v)) for k, v in data.items()}
    boots.append(did(s)[0])
boots.sort()
print("95% 区间：", round(boots[50], 1), "~", round(boots[1949], 1))

每组 120 个 PR 时的输出：

pilot    中位周期 前  27.0h → 后  21.4h  变化  -5.6h (-21%)  n=120
control  中位周期 前  25.7h → 后  26.3h  变化  +0.6h (+2%)  n=120
DiD 估计：AI 带来的中位周期变化 ≈ -6.2 小时
95% 区间：[-12.1, +2.8] 小时；区间跨 0，还不能下结论

换成你们自己的数据时，要先剔除机器人 PR 和依赖自动升级 PR，周期时间也可以换成需求前置时间。

五个最常见的坑

• 拿自报当实测：METR 里的人慢了 19% 还觉得快了 20%。问卷只能当一个维度。
• 盯着虚荣指标：代码行数、接受率、AI 代码占比只说明在用。Meta 的论文和 DORA 都提醒过这一点，各家的口径也不一样，没法横向比。
• 古德哈特定律：指标一旦变成考核目标，就不再可靠。Atlassian 的调查里 64% 的管理者认为 AI 用得越多结果越好，41% 的开发者承认因为「被期待」而多用。别把 AI 使用量写进个人 KPI。
• J 曲线期误判：上线头几个月学习成本、审查负担、流程适配会把效率往下拉。DORA 专门提醒：别在低谷期砍预算。
• 新鲜感和选择偏差：最早报名试点的往往本来就是高手，头几周热情也最高。随机分批、观察够一个季度，能挡掉大部分这类误差。

最后

如果只能做一件事：下周就把 AI 平台日志和 Git 数据按团队拉出来，留好基线，再挑两三个团队做分批上线。有了对照组，年底被问「提效了多少」时，你拿出的就是一个带置信区间的数字，而不是周活率。