#模型时代# “我就是那个用了vibe coding，效率降低了38%的人”

METR之前进行一项随机对照试验，旨在探究 AI 编程工具能在多大程度上为经验丰富的开源开发者提速。

结果出乎研究者的意料：开发者们自认为在使用 AI 工具时速度提升了 20%，但实际上，当他们能使用 AI 时，比起不使用 AI 的情况，速度反而慢了 19%。

METR招募了 16 位经验丰富的开源开发者，在他们自己的代码仓库（平均拥有 22k+ 星标，100万+ 行代码）中处理 246 个真实任务。然后，将每个任务随机分配为两组：一组允许使用 AI（通常是搭载了 Claude 3.5/3.7 的 Cursor Pro），另一组则不允许 AI 辅助。

工程师Quentin Anthony是16明参与者之一，而且是降低效率最多的人之一，他写了一个长推文，解释了原因，信息量很大。

有不少感受和我用AI写作一样，不断抽卡其实没有自己写快，但大脑真的更喜欢写简短的提示词，而不是最终的一大串文字啊[揣手]

—
我就是参与这项研究的 16 名开发者之一。我想就开发效率下降的原因及其缓解策略谈谈我的看法。

为了让大家觉得我的观点值得一听，我想先抛出一个引子：在我处理被分配到的问题时，AI 带来的“速度提升”是 -38%。我认为保持透明对整个社区是有益的。

首先，我认为 AI 带来的速度提升与开发者自身能力的关联性非常弱。所有参与研究的开发者都非常出色。我认为，效率问题更多地源于陷入了“失败模式”——这既包括大语言模型（LLM）能力的局限，也包括人类工作流程的问题。我与许多优秀的预训练（pretraining）开发者共事，发现大家面临的许多问题是共通的。

我们喜欢说 LLM 是工具，但实际对待它们时却更像是期待一颗“万能灵丹”。

毫不夸张地说，任何开发者都能体会到最终解决一个棘手 bug 时的那种满足感。而 LLM 就像一个巨大的多巴胺快捷按钮，有可能一键解决你的问题。面对一个有 1% 几率能搞定一切的按钮，你会不会一直按下去？至少对我来说，这比费力去啃硬骨头的替代方案要愉悦得多。

其次，如今的 LLM，其能力分布极不均衡。我认为这主要与两点有关：
1) 哪些类型的编程任务拥有大量干净的训练数据；
2) LLM 实验室用以衡量成功的基准（benchmarks）和评估（evals）标准是什么。

举个例子，所有 LLM 在处理底层系统代码（如 GPU 内核、并行/通信等）时都表现糟糕。这是因为相关的代码数据相对稀少，而且评估模型在这些任务上的能力也很困难（关于这一点，我在 github.com/Quentin-Anthon… 中有更详细的讨论）。

由于这些任务是我作为一名预训练开发者的主要工作内容，我很清楚我工作中的哪些部分适合交给 LLM（例如编写测试、理解不熟悉的代码等），哪些则不适合（例如编写内核、理解通信同步语义等）。我只在确信 LLM 能够可靠处理任务时才使用它们。

在判断一个新任务是否适合用 LLM 解决时，我会尝试严格设定一个时间限制（time-box）来与 LLM 互动，以免自己钻进牛角尖。再一次强调，当感觉“就快成功了！”的时候，要让自己果断放弃使用 LLM 是非常困难的！

沿着这一点说下去，导致 LLM 失效的“长尾问题”还有很多：

一、 “上下文退化”（Context rot）：模型会因为过长且不相关的上下文（尤其是在长对话中）而分心。可以参考 x.com/simonw/status/…。你需要经常开启新的聊天窗口。如果用户为了追逐多巴胺，总觉得“模型马上就要答对了！”，就更不愿意开启新对话，从而加剧了这个问题。

二、训练数据分布：我不敢说自己了解 Claude/Gemini/ChatGPT/Grok/R1 中任何一个模型的数据分布，但不同模型确实在特定语言或任务上表现各异，我会利用它们的强项。不幸的是，我之所以知道哪个模型适合我个人工作流的哪个环节，是靠用一些我大致知道答案的问题去反复询问不同模型才总结出来的。

例如，我可能会用 Gemini-2.5 pro 进行初步的代码理解，用 o3来辅助核心实现，然后用 Claude 4 Sonnet来优化解决方案并检查 bug。像 Cursor 这样的工具通常不让我看到底什么内容被送入了上下文，所以我不用它们。因为这会破坏我对特定模型擅长什么、能容忍什么输入的心理模型。我通过我的 IDE 或本地聊天界面直接调用模型 API。这不代表这是“正确”的方式，只是它对我有用 :)

第三，在等待 LLM 生成回答的间歇期，人非常容易分心。社交媒体的“注意力经济”是残酷的。我认为很多人在“等待”30秒生成结果的时候，花了30分钟去刷手机。

关于这一点，我能说的是，我们应该了解自己的弱点，并尝试高效地利用 LLM 生成的这段时间：

四、如果任务需要高度专注，就把这段时间用来处理一个子任务，或者思考后续问题。即便模型一次性完美地回答了你的问题，你还可以想想：还有什么是我不理解的？

五、 如果任务仅需少量专注，就在此期间做些别的小事（回邮件/Slack，阅读或编辑另一段文字等）。

一如既往，一些简单的“数字卫生”（digital hygiene）习惯对此很有帮助（比如使用网站拦截器、手机开免打扰等）。很抱歉听起来有点倚老卖老，但这些方法对我确实有效 :)

LLM 是一种工具，我们需要开始学习它的缺陷，并保持一定的自我认知。大家之所以喜欢 karpathy 的演讲，一个重要原因是他是一位极具反思精神的 LLM 用户——他之所以能较早达到这种境界，是因为他亲自参与了其中一些模型的预训练工作。

如果我们想用好这个新工具，就必须理解它（以及我们自己！）的短板，并主动去适应。

最后的一些声明：
与 METR 合作是一次非常棒的经历，他们是严谨的科学家。我非常享受参与这项研究并阅读他们的研究成果。

我并非什么试图说教的 LLM 大师。请将这篇文章看作是我公开发表的一篇个人日记，希望我的反思能对他人有所裨益。