METR研究失灵：开发者不愿离开AI，速度测量失效

METR曾做过一个罕见的随机对照试验来测量AI对编程效率的真实影响，结果出人意料。当他们试图重复这项研究时，却发现实验本身已经无法进行——太多开发者拒绝在没有AI的条件下工作。这背后揭示的问题，比"AI是否让你更快"更值得深思。

第一次试验：感觉快了20%，实际慢了19%

2025年初，METR以每小时150美元的价格招募了16位经验丰富的开源开发者，让他们在熟悉多年的大型开源仓库中处理246个真实issue。每个issue被随机分配为允许或禁止使用AI。

结果：允许使用AI时，任务耗时反而增加了19%。但开发者们在开始前预测AI能提速24%，完成之后仍然相信自己被AI加速了20%。据METR 2025年7月发布的报告，这种主观感受与客观测量之间高达约40个百分点的偏差，成为后续讨论的核心。

这个试验的设计本身是严谨的——随机化、真实任务、经验丰富的开发者。问题出在人的感知上。

随机对照试验（RCT） 是因果推断的黄金标准，通过随机分配干预（此处为是否允许使用AI）来消除选择偏差和混杂因素。在软件工程研究中，RCT之所以罕见，是因为难以在真实开发场景中实现随机化、控制变量并保证生态效度。METR的试验将每个issue随机分配为允许或禁止使用AI，使得两组在开发者经验、任务难度等维度上统计可比，从而能隔离AI工具的因果效应。但RCT也有局限：它测量的是特定工具、特定任务、特定人群下的平均效应，外推需谨慎。

第二次试验：控制组消失了

2025年8月，METR启动了规模更大的后续实验：57位开发者、143个仓库、超过800个任务。2026年2月公布的结果却让研究者自己都感到棘手。

METR在报告中直言，这批数据"无法为我们提供关于AI工具当前生产力效应的可靠信号"。

核心问题出在招募环节。METR观察到，"选择不参与研究的开发者数量急剧上升，原因是不愿意在没有AI的情况下工作"。即便参与了的人也在自我筛选：30%到50%的开发者表示，他们会主动不提交某些任务，因为不想在没有AI的条件下完成它们。METR认为这两种效应都会让数据低估AI的提速效果。

另外两个问题叠加：报酬从每小时150美元降到50美元，带来了额外的选择偏差；而对于同时运行多个AI agent的开发者，METR承认其任务耗时测量本身不可靠——你启动一个agent后转去做别的事，这个任务到底花了多长时间？

METR拿到的数据是：回归开发者群体显示"-18%的提速，置信区间在-38%到+9%之间"；新招募开发者显示"-4%的提速，置信区间-15%到+9%"。注意这里的负号表示任务用时更短——方向与2025年的结果相反。但两个置信区间都跨越了零，意味着结论并不显著。METR自己的解读是：开发者现在可能确实比2025年初更快了，但这批数据能提供的证据非常微弱。

一个为测量AI编程速度而设计的随机对照试验，失去了它的控制条件。

置信区间 是频率派统计中用于表达估计不确定性的区间，通常与95%置信水平搭配。若区间跨越零（如-38%到+9%），则意味着在零假设（无效应）下，观测到当前数据或更极端情况的概率不低于5%，因此不能拒绝“无效应”的假设。区间宽度反映精度：样本越小、方差越大，区间越宽。METR两次试验的置信区间均跨越零，说明即便点估计显示提速，证据也不足以得出显著结论。

自报数据有多不可靠

METR还做了一项问卷调查，2026年2月至4月间覆盖349名技术工作者，其中87名软件工程师。受访者自报的速度提升中位数是3倍，工作价值提升中位数是1.4到2倍。受访者还表示愿意放弃29%的薪水来保留AI工具一个月——METR自己标注这一项证据力较弱。

METR在公布这些数字时附上了明确警告："调查结果不一定基于现实。"同一篇文章回顾了2025年的试验——"人们平均高估了AI对其任务耗时影响的40个百分点"。

这不是在论证AI让你变慢了。2025年的试验用的是早期工具（主要是Cursor Pro搭配Claude 3.5和3.7 Sonnet），在开发者非常熟悉的大型成熟仓库上操作。METR自己也认为情况已经变化。真正值得关注的是：大家最依赖的测量工具——"感觉有多快"——曾被秒表校验过一次，偏差约40个百分点。而秒表现在很难跑起来了，因为被计时的人不愿意放下工具。剩下的只有感觉。而感觉恰恰是唯一一个有已知误差棒的测量方式，且误差棒巨大。

选择偏差 指样本并非随机抽取，导致估计值系统性偏离总体真值。在METR的后续试验中，拒绝参与或主动不提交某些任务的开发者，可能恰恰是那些认为AI帮助不大或使用方式特殊的人，从而扭曲了测量结果。类似地，报酬下降可能吸引不同动机的参与者。选择偏差无法通过增大样本量消除，只能通过改进招募设计或使用工具变量等方法缓解。

"启动了几个agent"是一种新的感觉指标

"我同时跑五个agent"听起来像个数字，但它只是一个输入量。

METR的秒表之所以失灵，恰恰是因为开发者在同时运行多个agent并在其间切换做别的事——而这正是人们常用来证明效率提升的工作流。启动更多agent容易计数，也容易让人感觉良好，但它不告诉你最终有多少代码进入了主分支。

一个跑了四十分钟、最后交给你一个被丢弃的diff的agent，仍然消耗了你的审查时间。一个改动合入后两天被回滚的agent，成本更高。这两者在"启动agent数"里都看不出来。

有三个指标不需要秒表也不需要直觉就能计数：

• 落地（Landed）：改动合入了你发布所用的分支的任务数
• 丢弃（Dropped）：未合入就被关闭的PR数
• 回滚（Reverted）：合入后又被撤销的改动数

这些都不测量速度，它们统计的是经过审查后存活下来的产出——更接近团队真正为之付费的东西。粗糙、有滞后，但不依赖"这周感觉怎么样"。

每周花一分钟就能跑的计数脚本

如果你的agent工作最终以pull request形式收尾，GitHub CLI和git就能给出这三个数字。以下脚本统计当前仓库最近七天的情况：

#!/usr/bin/env bash

**GitHub CLI（gh）** 是GitHub官方命令行工具，支持通过`--search`参数使用GitHub搜索语法（如`created:>=2025-01-01`）过滤PR，并通过`--json`和`--jq`提取结构化字段。脚本中的`gh pr list`默认只返回开放PR，需显式指定`--state all`或`--state merged`/`--state closed`。`git log --grep='^Revert'`则利用git提交信息约定：默认的`git revert`会生成以`Revert "..."`开头的提交信息，因此可据此统计回滚次数。这些命令依赖本地仓库和远程API的及时同步。
# weekly-landed.sh: what landed in the last 7 days
since=$(date -d '7 days ago' +%F 2>/dev/null \
  || date -v-7d +%F)

opened=$(gh pr list --state all --limit 500 \
  --search "created:>=$since" \
  --json number --jq length)

landed=$(gh pr list --state merged --limit 500 \
  --search "merged:>=$since" \
  --json number --jq length)

dropped=$(gh pr list --state closed --limit 500 \
  --search "is:unmerged closed:>=$since" \
  --json number --jq length)

reverted=$(git log main --since="$since" \
  --oneline --grep='^Revert' | wc -l | tr -d ' ')

echo "since:    $since"
echo "opened:   $opened"
echo "landed:   $landed"
echo "dropped:  $dropped"
echo "reverted: $reverted"

date那一行同时兼容GNU（-d）和macOS（-v）。回滚计数只捕捉保留了git默认Revert "..."提交信息的记录，并假设你的主干分支叫main且本地副本已更新。没有开PR就放弃的分支不会出现在dropped里。PR计数包含仓库中所有人（或agent）提交的PR，这没问题：你跟踪的是团队产出。

每周五跑一次，把数字记下来。和上周比，不要和其他团队比。如果你加了一个agent后"opened"翻倍而"landed"持平，答案就很清楚了。

工具能帮什么，不能帮什么

本文作者是Hermes IDE的开发者，以下部分需带着这个背景来看。

当每个agent任务有清晰的开始和结束时，统计落地工作会更容易。在Hermes中，⌘N（Windows/Linux上为Ctrl+Shift+N）会在全新的hermes/<name>分支和工作树上启动每个任务，任务本身作为agent的第一个prompt。每个会话显示一个状态：工作中、需要批准、向你提问、完成、错误或空闲，且Hermes会标明状态何时是猜测的。

一个任务在你决定它的去向之前始终是一个任务。Hermes保存每一轮agent交互，可以diff或恢复任意单轮。Review Desk（⌘G）按轮次或按文件展示改动，带风险标记，行内评论可以直接发回给写这行代码的agent。

Land功能一步完成提交、开PR或本地合并，合入任务起始的分支，且可撤销。你的自定义检查可以决定任务何时算完成。当Land开的PR合入后，上面的脚本会统计到它。本地合并不出现在PR数字里，如果这是你的落地方式，需要从git log里数。

Hermes没有生产力仪表盘，也不测量你的速度。数字仍然来自git和GitHub。每个agent在真实终端里运行自己的界面，用你自己的登录凭证，Hermes只在外围增加了分支、状态、审查和Land步骤。如果你只用一家厂商，它自己的工具可能就够了：Claude Code默认将后台会话移到.claude/worktrees/下的工作树，Codex应用在$CODEX_HOME/worktrees下并行运行聊天。

Hermes在BSL 1.1下源码可用，支持macOS、Windows和Linux。

所以，你到底快了吗

对大多数人来说：不知道。METR有随机化、有秒表、有预算，今年都没能拿到一个可靠的数字。你也不会从某个周二的感觉里得到答案。

周五跑一次脚本，下周五再跑一次，然后再考虑加下一个agent。

你会接受METR的无AI任务吗，即使每小时150美元？如果你在团队里跟踪agent产出，你计数什么？