当我们谈论 AI 编程工具对开发者效率的影响时，最直观的衡量方式似乎是设置一个对照实验：让开发者完成若干任务，一组使用 AI 辅助，另一组不使用，然后比较两组的时间差。然而，模型评估与威胁研究组织 METR 在 2025 年初完成的这项实验，揭示了一个令业界意外的结论 —— 使用 AI 工具的开发者完成任务的时间平均比不使用 AI 的开发者慢 19%，而非许多开发者预期的速度提升。这一反直觉发现促使 METR 重新审视其实验设计，并着手构建更加稳健的开发者生产力测量体系。
早期实验设计与意外发现
METR 在 2025 年初开展的这项研究招募了 16 名经验丰富的开源开发者，覆盖约 246 个真实任务。实验采用任务级随机对照试验设计：开发者选择自己日常工作中的真实任务，然后由 METR 随机将每个任务分配到 “允许使用 AI” 或 “禁止使用 AI” 两种条件中，以任务完成时间作为主要结局指标。研究使用的 AI 工具包括 Cursor 和 Claude 3.5/3.7 等当时最先进的编程助手。
研究结果令人困惑：尽管开发者自己预测并报告了 20% 至 24% 的速度提升，但实际测量数据显示 AI 辅助组的任务完成时间反而延长了约 19%。这种主观预期与客观测量之间的巨大落差，揭示了开发者对 AI 工具效能的感知存在显著偏差。研究者推测，这可能源于 AI 工具在复杂任务上需要更多的上下文交互、调试和结果验证，而这些隐性成本在主观评估中往往被忽视。
重复实验与选择性偏差的浮现
随着时间推移，METR 在 2025 年 8 月后继续追踪同一批开发者，发现情况发生了微妙变化。重复参与者的估计速度提升达到 18%，置信区间约为负 38% 到正 9%；而新招募的开发者的估计速度提升仅为 4%，置信区间约为负 15% 到正 9%。这些数据表面上表明 AI 工具的效能随着用户熟练度提升而改善，但研究者敏锐地意识到，更根本的问题在于实验设计本身正在被现实所瓦解。
一个突出的现象是，许多开发者现在强烈偏好使用 AI 辅助，甚至拒绝完成被分配到 “无 AI” 条件的任务，尤其是那些他们预期 AI 能带来大幅提升的工作。更有甚者，一名参与者完成了零个 “无 AI” 条件的任务。这种高退出率和依从性缺失，使得实验数据的解释变得愈发困难。研究者开始意识到，早期实验设计所依赖的关键假设 —— 开发者会公平地对待两种条件下的任务 —— 已经不再成立。
任务级随机对照试验的结构性缺陷
METR 详细分析了原始设计失效的原因，指出任务级随机对照试验存在三个相互关联的结构性缺陷。首先是任务替代效应：当开发者预期能够使用 AI 时，他们倾向于选择不同类型的任务，例如那些更能发挥 AI 长处的任务。这导致即使在随机分配之前，治疗组和对照组的任务在难度和价值上已经存在系统性差异。换言之，开发者悄然改变了实验的输入分布，使得组间比较失去意义。
其次是产出质量差异。使用 AI 时，开发者往往会编写更多的测试用例、文档注释，或进行更大幅度的代码重构。这些额外产出虽然具有长期价值，却使得任务完成时间无法简单映射到实际交付价值。研究者发现，AI 辅助条件下开发者的工作范围发生了本质变化，不再是 “用更短时间完成同样工作”，而是 “以不同方式完成更多工作”。
第三个问题是依从性崩溃。当 AI 工具足够强大时，强制开发者 “假装不使用 AI” 变得不切实际。开发者会想方设法规避限制，或者在任务分配到 “无 AI” 条件时推迟、跳过甚至放弃。这种非依从现象严重削弱了随机化的因果解释力，使得传统的意向性分析方法难以成立。
方法论改进的多维路径
面对这些挑战，METR 提出了一系列实验设计的改进方向，而非简单放弃随机对照试验。第一个方向是缩短实验周期、提高依从性。研究团队建议运行更短周期、更高强度的实验，并通过更高报酬等方式激励参与者完全遵守随机分配方案。这种设计减少了参与者在长期实验中产生策略性行为的可能性，使得随机化的因果推断得以恢复。
第二个方向是固定任务实验。与其让开发者自行选择真实任务，不如为所有参与者分配相同的标准化任务，如修复特定 bug、实现某个功能模块或完成代码审查。这种方法消除了任务替代效应，使得组间比较更加干净，但代价是牺牲了外部有效性 —— 实验室任务可能无法完全反映真实工作场景的复杂性。
第三个方向是开发者级随机化。研究者考虑将随机化单元从任务提升到开发者级别，即让一部分开发者在整个实验期间始终使用 AI，另一部分始终不使用。这种设计避免了任务级的选择性偏差，但引入了新的开发者级选择问题 —— 不同开发者之间本身可能存在系统性差异，且样本量通常远小于任务级设计，导致统计效力下降。
第四个方向是观测性遥测研究。METR 计划利用真实世界的使用数据进行分析，例如 GitHub 上由 AI 工具协助提交的代码比例、详细的交互日志等。这种方法不依赖于实验条件下的强制行为，而是观察开发者在自然状态下的 AI 使用模式。虽然难以建立严格的因果关系，但可以提供更贴近实际的效能画像。
第五个方向是调查和时间使用研究。通过精心设计的问卷，询问开发者如何分配时间、AI 在哪些环节帮助最大或造成负担，然后与观测行为进行交叉验证。这种方法可以捕捉实验设计中难以测量的主观体验和隐性成本。
工程实践中的实验设计启示
METR 的经验为工程团队设计 AI 编程工具的生产力实验提供了若干关键启示。首先，不应允许参与者在治疗组和对照组之间自由选择不同类型的任务，这会引入严重的_selection bias_。如果必须使用真实任务，可以考虑设置任务选择的窗口期，或使用固定任务池来限制自由度。
其次，需要明确定义 “生产力” 的含义并选择相应的测量指标。时间只是最直接但最不完整的维度。代码质量、缺陷率、测试覆盖率以及长期可维护性等指标，在 AI 与非 AI 工作流之间可能存在显著差异。单一时间指标可能掩盖 AI 工具带来的真实价值变化。
第三，应该将自我报告的速度提升视为弱信号，而非决策依据。METR 的研究反复表明，开发者的主观预期与客观测量之间存在巨大鸿沟。优先采用随机化或准实验设计，并建立清晰的反事实对照。
最后，实验设计应考虑实际约束条件下的依从性问题。如果目标用户群体已经高度习惯于 AI 工具，强制其 “不用 AI” 可能引发强烈的行为扭曲。在这种情况下，观测性研究或基于自然实验的准设计可能比传统随机对照试验更为可行。
METR 的这次方法论反思，本质上揭示了一个更深层的挑战：当技术快速演进时，评估技术效能的实验方法本身也必须持续迭代。AI 编程工具已经从 “辅助建议” 演进为 “自主执行”，而我们的测量手段也需要从简单的 “时间差” 演进为能够捕捉多维度价值的多层次评估体系。这一转型不仅关乎学术研究的严谨性，也直接影响企业在实际项目中选择和部署 AI 工具的决策质量。
资料来源：METR Blog（2026 年 2 月 24 日发布的实验设计更新公告）