2026 开发者生产力真相核查：AI 工具究竟交付了什么

2026 年最有用的开发者生产力数据，也是最好看的那一份。METR 在 2026 年 2 月 24 日发布的 uplift 实验更新显示：10 位回归参与的老手开发者使用 AI 工具后快 18%，置信区间从「快 38%」一直跨到「慢 9%」；而 47 位新开发者则慢 4%。更早的 2025 年初研究曾发现 AI 使用让任务耗时增加 19%，置信区间为 +2% 到 +39%。METR 相当坦诚，自称这些数据「对于效应大小只是非常弱的证据」。信号不是「AI 没用」，而是「体感与秒表对不上，而只有其中一个替你付账单」。

比秒表，不比感觉

一、METR 究竟发现了什么

2026 年 2 月 24 日的更新报告：10 位回归的老手开发者提速 18%，置信区间从快 38% 跨到慢 9%；47 位新开发者慢 4%，区间从慢 15% 到快 9%。两个区间都跨过零点。METR 明确表示，这些数据对于效应大小「只是非常弱的证据」，并描述了在发现选择偏差后如何调整实验设计。仔细读，这不是对 AI 的判决，而是一堂关于「生产力有多难测」的课。

# instrument.py - four timestamps that actually matter
TASK_TIMESTAMPS = {
    "started_at":    "when the human opened the task",
    "first_output_at": "when the tool produced its first usable output",
    "review_start":  "when review began",
    "done_at":       "when tests passed and a human signed off",
}

def elapsed(task):
    return {
        "ai_seconds":   task["first_output_at"] - task["started_at"],
        "review_seconds": task["done_at"] - task["review_start"],
        "total_seconds":  task["done_at"] - task["started_at"],
    }

二、为何体感与秒表对不上

自报提速捕捉的是体感努力与心流。开发者八秒拿到一个看似合理的函数，会觉得自己很快。而秒表仍在走：它会跑到代码评审、调试，以及 AI 生成代码常常引入的返工上。独立分析把 METR 的结论解读为「体感与秒表之间的落差」，而不是「AI 很慢」的证据。两者都是真的，只是量的是不同东西，而只有后者会出现在你的交付数字里。

-- uplift_query.sql - weekly, against a pre-AI baseline
SELECT
  date_trunc('week', started_at)                      AS week,
  COUNT(*)                                            AS tasks,
  PERCENTILE_CONT(0.5) WITHIN GROUP
    (ORDER BY total_seconds)                          AS median_total_s,
  PERCENTILE_CONT(0.5) WITHIN GROUP
    (ORDER BY review_seconds)                         AS median_review_s
FROM tasks
WHERE repo = 'payments-api'
GROUP BY 1
ORDER BY 1;
-- Compare each week to the same repo's pre-adoption median.
-- A drop in total_seconds with a flat review_seconds is real speedup.
-- Total down but review up means the model moved the work, not removed it.

三、度量你自己的提效

唯一重要的基准，是你自己的代码库与团队。给任务开始与结束打点，并把评审时间与返工时间作为独立字段跟踪——生成式代码到底赚了还是亏了，就在这两个字段里。代码示例 1 展示值得采集的四个时间戳；代码示例 2 把它们变成一个每周可跑的提效查询。要和同一个仓库的「AI 之前」基线比，而不是和厂商的宣传数字比。

# triage.py - route before anyone starts typing
def mode_for(task):
    touches = task["estimated_files"]
    familiar = task["author_has_edited_before"]
    if touches <= 1 and familiar:
        return "ai_first"          # boilerplate, tests, small fixes
    if touches >= 4 or not familiar:
        return "human_first"       # architecture, unfamiliar codebases
    return "pair"                  # uncertain: work together, watch review time

评审时间才是隐性成本

四、今天 AI 在哪最管用

稳定受益的场景都窄且不性感：写测试、生成样板、解释陌生代码、做范围明确的单文件修改。稳定亏本的场景集中在大型架构改动与陌生代码库上——模型的自信超过它的能力，人最后不是在写代码，而是在审计。代码示例 3 是一个粗糙的估算器，在有人动手之前就把任务分流到合适的模式，这比事后评审便宜得多。

# review_time.py - the hidden cost that decides the case
def review_ledger(events):
    totals = {}
    for e in events:
        if e["kind"] != "review":
            continue
        key = e["task_id"]
        totals[key] = totals.get(key, 0) + e["minutes"]
    return totals

# If median review minutes rise faster than coding minutes fall,
# the tool has not saved time, it has relocated it. Track both, always.

五、工具卫生与上下文边界

报告出来的提效差异，很大一部分来自「给了工具多少上下文」。有全仓库上下文的智能体，与只看单个文件的智能体表现不同；同一段提示词，在整洁代码库和缠成一团的代码库上，结果也不同。把上下文当成预算：量提示词大小，让检索片段少而相关；当智能体输出「看起来合理但其实是错的」时，重跑一次任务，而不是在混乱之上继续编辑。

# definition_of_done.py - keep 'agent finished' and 'work done' separate
DOD = {
    "tests_pass": True,          # never optional
    "human_read_diff": True,     # the author of the change is accountable
    "no_new_lint_errors": True,
    "review_minutes_logged": True,
    "rollback_plan": "for high-risk changes only",
}

def is_done(task, dod=DOD):
    return all(task.get(k) == v for k, v in dod.items() if v is True)

六、每周度量闭环

选一个指标、一个节奏、一个负责人。每周记录：启动任务数、完成任务数、评审分钟数、返工分钟数。代码示例 4 专门跟踪评审时间，因为正是这个隐性成本决定了 AI 工具的账算不算得过来。代码示例 5 把「完成」的定义写成规范，包含测试通过与人工通读，从而让「智能体跑完了」与「活儿干完了」保持可区分。分不开的东西，就无法改进。

七、评审税

生成式代码不只是来得更快，它还以评审负担的形式抵达，而这个负担落在团队里经验最丰富的人身上。模型八秒产出的 diff，资深工程师可能需要十二分钟才敢相信，而这十二分钟在工具自己的面板里是完全看不见的。这正是「体感与秒表落差」的机制。解法不是弃用工具，而是让评审变便宜：更小的 diff、能证明改动的生成式测试，以及把人工通读写进「完成」的定义。代码示例 4 专门跟踪评审分钟数，让这笔税出现在账本上，而不是悄悄吃掉你的交付速度。

八、提效确实为真的三个信号

信号一：任务总时长下降而评审时长持平，说明时间是「省掉了」而不是「挪走了」。信号二：同一仓库的返工与重开工单呈下降趋势，说明一次通过的质量变好了，而不只是变快了。信号三：改进在「新工具新鲜感」褪去后依然存在，并且是一个季度的跨度而非一个冲刺。如果只有总时长动了、评审时长同步上升，那你是把活儿挪了位置，而不是消灭了它。代码示例 5 之所以把「智能体跑完了」与「活儿干完了」分开，正是因为这两个数字一旦分道扬镳，就是「胜利只是表面功夫」最早的警报。

每周度量你自己的代码库