AI编程提速24%？实测数据打了43个点的脸

开发者觉得AI让自己快了24%，计时器显示他们慢了19%。METR这项研究测出的43个百分点认知差，解释了为什么AI工具越用越多，信任却越来越低。

真实开发者的真实项目，不是实验室玩具

研究团队找的是有经验的开源开发者，在他们自己的代码仓库里做自选任务。没有预设的编程题，没有受控环境。这些人用AI辅助完成日常工作，然后被客观计时。

结果很一致：主观感受与客观数据背道而驰。开发者报告"更快、更自信、更高效"，实际耗时反而增加。

时间去哪了？审查AI建议、调试AI生成的代码、在输出不理想时重新提示、在自己的思路和AI建议之间来回切换。这些活动感觉像在推进工作，实际上在消耗时间。

Stack Overflow 2025年开发者调查给出了更大规模的印证：对AI准确性的信任从40%跌至29%，46%的开发者明确表示不信任AI工具的准确性。用得多，信得少，这种矛盾状态正在成为行业常态。

不是"AI没用"，是"熟悉的代码AI帮不上"

METR研究的结论被简化为"AI让你变慢"，但这会误导。核心发现是：开发者无法判断AI是否真的在帮自己。

研究限定了一个具体场景——经验丰富的开发者在熟悉的代码库上工作。这个场景下，AI平均省不了时间。换个场景，结论可能完全不同。

CodeRabbit分析了470个GitHub仓库，发现AI写的代码问题数量是人类写的1.7倍。但分布比平均值更重要：

AI在"广训练数据重要、本地项目上下文不重要"的任务上表现最好；在需要深度理解特定代码库的地方挣扎。

重构你自己写的、你完全了解的代码，恰恰是AI辅助的最差场景——因为你已经掌握了AI所缺乏的上下文。

这违反直觉。按常理，经验丰富的开发者更能评估和引导AI输出，应该获益更多。Google Chrome工程负责人Addy Osmani就持这个观点，而且部分正确：专家确实比新手更会使用AI。

但METR研究提示了一种"天花板效应"。当你对代码库足够熟悉，AI的贡献变得边缘化。你自己写代码的速度，约等于"提示-等待-阅读-评估-接受/拒绝-修正"这一整套协作流程的速度。人机协作的 overhead 吃掉了省下的打字时间。

新手和陌生代码库，才是AI的舒适区

对于初学者或不熟悉的代码库，计算方式变了。AI带来了开发者缺乏的知识，这时候引入外部上下文的收益，可能超过协作流程的成本。

研究没有测试这个群体，但逻辑上成立。这也是为什么AI编程工具在入门教程、技术问答、快速原型场景中大受欢迎——这些正是"广训练数据覆盖、本地上下文稀薄"的典型。

43个百分点的认知差，本质上是一个元认知问题：人类不擅长评估自己的生产力，尤其是当工具提供了持续的正反馈（代码生成、自动补全的即时视觉反馈）时。我们混淆了"活动感"和"进展感"。

这对产品经理有直接影响。如果你用"开发者觉得更快"作为采纳指标，可能会高估工具价值；如果你用"客观产出"作为指标，可能会低估当前AI的适用场景。两个指标都需要，但得知道各自测的是什么。

工具厂商的营销也在利用这个盲区。"提升X%效率"的宣称，通常基于主观调查而非客观测量。METR研究的价值在于提供了后者，尽管样本有限（几十名开发者），但方法论扎实。

一个值得追踪的信号：GitHub Copilot等工具的早期用户正在分化。一部分人深度整合进工作流，另一部分人逐渐退出，回到传统编码方式。这种分化本身说明工具还在寻找产品-市场契合的精确位置，而不是已经"解决"了编程辅助问题。

Google的Addy Osmani在回应这类研究时提到，专家使用AI的方式正在进化——从"让AI写代码我审查"转向"我让AI做特定子任务"。这种主动的任务分解，可能是突破天花板效应的路径。但这也要求开发者对AI的能力和边界有清醒认知，而43个百分点的认知差表明，这种清醒并不普遍。

研究最后留下一个开放问题：如果开发者持续高估AI收益，这种误判会如何影响长期工具设计？厂商会优化"感觉更快"还是"真的更快"？当这两个目标冲突时，市场会选择哪个？