METR 量出了 18% 的提速，然后亲口说这个数别信

2026 年 2 月 24 日，METR 发布了一篇更新，标题是《我们正在改变开发者生产力实验的设计》。标题很平淡，内容很少见：他们先报出一个提速数字，然后花了整篇文章解释为什么这个数字不可信。要知道 2025 年那篇被引用了几千次的论文，结论是「AI 让有经验的开源开发者做任务变慢了 20%」。这次他们算出来的是 −18%。一家研究机构在对自己不利的方向上得到结果时会谨慎，在对自己有利的方向上仍然谨慎，这件事本身值得读。

跨过零的置信区间不是结论，是能力边界

一、它到底说了什么，用原话里的数字

先说基线：METR 之前的研究发现，AI 工具让有经验的开源开发者完成任务的时间变长了 20%，数据来自 2025 年 2 月到 6 月。为了看这个效应随时间怎么变，他们在 2025 年 8 月启动了新实验，参与者是原研究里的 10 位开发者，加上从更多样化的开源项目里新招募的 47 位，一共 57 人，时薪 50 美元。方法沿用旧设计：开发者预先指定要做的任务，任务被随机分配到「允许用 AI」和「不允许用 AI」两种条件，然后记录耗时。结果是：对原始开发者那个子集，他们现在估计提速 −18%，置信区间 −38% 到 +9%；对新招募的开发者，估计 −4%，区间 −15% 到 +9%。两个区间都跨过了零。

# 1) The two estimates METR published, with their intervals.
#    Nothing here is rounded or reinterpreted.
rows = [
    # cohort,          point, ci_low, ci_high
    ("original 2025",   +19.0,  +2.0,  +39.0),   # tasks took LONGER
    ("returning devs",  -18.0, -38.0,  +9.0),    # speedup
    ("newly recruited",  -4.0, -15.0,  +9.0),    # speedup
]

for cohort, pt, lo, hi in rows:
    crosses = lo < 0 < hi
    print(f"{cohort:16} {pt:+.1f}%  [{lo:+.1f}, {hi:+.1f}]"
          f"{'  <- spans zero' if crosses else ''}")

二、为什么这个数字不可信：官方给了三条理由

第一条是参与率。2025 年全年，开源开发者里用 Claude Code、Codex 这类 agentic 工具的人变多了，直接后果是越来越多人不愿意参加这个研究，因为参加意味着有一半任务不能用 AI。这种拒绝对提速估计的偏置方向是明确的——把提速估小。第二条是报酬。他们把时薪从 150 美元降到 50 美元，这是另一种选择效应。第三条最技术，也最容易被忽略：对同时使用多个 AI agent 的开发者，他们测「任务耗时」的方法不可靠。三条里第一条是坏消息，第二条是可修复的失误，第三条则指向一个更深的问题。

# 2) An interval that spans zero does not mean "no effect".
#    It means this design cannot tell you the sign. Those are different
#    claims, and only one of them is supported by the data.
import math

def half_width(sd, n, z=1.96):
    return z * sd / math.sqrt(n)

# Rough check: what sample size would pin an effect of this size down?
sd_ratio = 1.0          # spread of per-task speed ratios, generous
for effect in (0.05, 0.10, 0.18):
    n = (1.96 * sd_ratio / effect) ** 2
    print(f"to detect {effect:.0%} at 95% confidence: ~{math.ceil(n)} paired tasks")

三、并发会毁掉你内部的基准测试

如果你在公司里量过「用了 AI 之后任务快了多少」，第三条理由应该让你停下来。假设一个人同时开三个 agent 跑三个任务，那么每个任务的墙钟时间都包含了另外两个任务的等待时间。你测出来的「任务耗时」不是这个任务的成本，而是一个队列的延迟。这个问题在 2025 年还不严重，因为大多数人是一个窗口一个对话；到 2026 年，多开 agent 已经是常态。于是所有基于墙钟时间的内部度量，都会系统性地高估成本、低估提速，而且偏误大小取决于这个人有多忙。这不是统计修正能救的，得改测量对象：从墙钟时间改成活跃时间，把并发数当成一个显式字段记下来。

当参与是自愿的，样本本身就是结论

# 3) METR's own list of why the follow-up is unreliable.
#    Read this as the honest part of the paper, not the appendix.
reasons = [
    "developers decline to enrol because they do not want to work without AI",
    "that refusal biases the speedup estimate downward",
    "pay was cut from $150/hr to $50/hr, adding a selection effect",
    "time-on-task is unreliable for developers running several agents at once",
]

# Point 4 is the one that quietly kills most internal benchmarks too:
# if one person drives three agents in parallel, wall-clock time is not
# the cost of a task, it is the cost of a queue.

四、如果还想量，就把设计做扎实

METR 的处理方式不是「算了」，而是改设计。对内部团队来说，可借鉴的做法是四件事。第一，单位定成任务，不是开发者也不是迭代，因为人和人之间的方差会吃掉一切。第二，随机化分配，同一个任务池里一半允许 AI 一半不允许，否则你测的是任务难度。第三，先把要做的任务列表和排除条件写下来再去跑，事先写和事后解释的区别，就是能不能被别人相信。第四，主指标用插桩出来的活跃分钟数，次指标加审查时间和 14 天内的回滚率——后者是很多团队忽略的，因为 AI 写出来的代码，成本往往不在写的时候，而在两周后。

# 4) If you still want an internal number, make the design defensible
#    before you run it. Pre-registration is cheap; re-litigating a
#    contaminated number for a quarter is not.
experiment:
  unit: task                    # not "developer", not "sprint"
  assignment: randomised        # AI allowed vs disallowed, per task
  pre_registered:
    tasks:
      - "drizzle: add cursor pagination to orders list"
      - "fix: flaky integration test in billing worker"
  excluded_up_front:
    - "tasks where the dev already knows the fix"
  primary_metric: active_minutes   # instrumented, not self-reported
  secondary:
    - review_minutes
    - revert_rate_within_14d
  stopping_rule: "80 paired tasks, then report whatever it says"

五、那么 2026 年的真实情况是什么

METR 自己的结论是：从和参与者的交流来看，2026 年初的开发者很可能比 2025 年初提速更多；但由于实验里的选择效应，他们的数据对这个增量只有非常弱的证据。注意这句话的结构——先给出方向性判断，再明确说明证据强度。这是研究机构的诚实写法，也恰好是我们读任何生产力报告时该用的滤镜。所以对「AI 到底提了多少速」这个问题，2026 年 10 月最诚实的回答是：方向为正，幅度未知，而且这个幅度高度依赖任务类型和开发者对工具的理解程度。任何给出精确百分比并且不带区间的说法，都在卖东西。

// 5) Instrumented timing beats a survey. Log the spans you already have.
//    active minutes, not calendar minutes - concurrency has to be explicit.
type TaskSpan = {
  taskId: string;
  startedAt: number;
  endedAt: number;
  agentsInFlight: number;   // >1 means wall clock overstates the cost
};

function activeMinutes(spans: TaskSpan[]): number {
  return spans.reduce((total, s) => {
    const wall = (s.endedAt - s.startedAt) / 60_000;
    return total + (s.agentsInFlight > 1 ? wall / s.agentsInFlight : wall);
  }, 0);
}

// Then publish it with the interval, not alone:
// "review time fell 12% (95% CI 4% to 19%, n=87 paired tasks)".