# 为什么 AI 让开发者变慢了 19%（但 69% 的人依然选择它）


你是否有过这样的感觉：调试到第三个小时，大脑像陷在糖浆里一样迟钝？你盯着同一行代码看了五遍，明知道有问题，却怎么也找不到？

现在想象一下，有人在旁边拿着秒表计时，只因为这个 bug 花了你四个小时而不是两个小时，就得出你“不够高效”的结论。

这正是目前关于 AI 与开发者生产力最严谨的研究中发生的事——而它令人震惊的结果，可能完全测量错了方向。

## 那个让所有人困惑的研究

最近，METR 的研究者们进行了一项本应成为 AI 对开发者生产力影响的权威研究。他们招募了 16 位经验丰富的开源开发者——这些人平均有 5 年经验、1500 次提交。他们不是刚接触 ChatGPT 的新手，而是用着 Cursor Pro、Claude 3.5/3.7 Sonnet 等最先进工具的老手。

结果呢？AI 工具让开发者变慢了 19%。

所有人都惊呆了。开发者原本预测自己会快 24%。经济学专家预测快 39%。机器学习专家预测快 38%。甚至在实验结束后，开发者们依然*觉得*自己快了 20%——尽管秒表显示相反。

问题来了：如果开发者感觉更快但实际更慢，究竟是谁错了？是开发者，还是秒表？

## 那个没人讨论的生产力悖论

研究忽略了一个关键点：**开发者的瓶颈不是时间，而是认知耐力**。

把你的大脑想象成一台高性能引擎。你当然可以让它满负荷运转八小时。但实际会发生什么？几个小时高强度专注后，你就会撞墙。找 bug 的能力下降，创造力枯竭，开始犯错，反而给明天制造更多麻烦。

就像我一个修车的朋友说的：“自己造一台引擎和买一台现成的完全是两种体验。自己造的有满足感，买的就……无所谓。”

研究者把开发者当成了流水线工人——生产力等于每小时产出多少“零件”。但软件开发更像是在造引擎。不是比拼装配某个零件的速度，而是要贯穿全程地保持愿景和工匠精神。

## “变慢”到底意味着什么

在研究中，开发者使用 AI 时，时间分布是这样的：

- 编码时间减少
- 查找资料时间减少
- 花更多时间写提示词
- 花更多时间等待 AI 响应
- 花更多时间审查 AI 输出
- 花更多时间……发呆

最后这一点尤其有趣。用 AI 时，开发者的“空闲”时间*增加了*。研究者认为这是低效。但如果这些“空闲”其实是微型恢复期呢？

### AI“低效”背后的隐藏好处

想想这些看似“浪费”的时刻发生了什么：

**等待 AI 生成代码时**，你不用主动思考问题。大脑可以休息 20-30 秒——就像拳击手每回合间喝口水。

这些等待彻底改变了我的日常节奏。以前，调试是最消耗脑力的活，累的时候我会尽量避免。现在？累了反而*先*去调试，因为这成了最轻松的部分。

这和过去完全相反。以前我一直用调试器，但在大型代码库里，调试器运行很慢。你要一遍遍地单步执行、反复运行、苦苦找 bug。

现在我只要找到线索、确定起点，告诉 AI 关注什么——它通常能帮我找到 bug。找不到的话，它会生成临时测试代码来定位问题。

这其实很重要——以前调试时我总是懒得一开始写测试代码，因为太费时间。现在 AI 会自动生成一些“垃圾”测试代码，我根本不用看也不用维护。跑一下，定位到问题就删掉，修好 bug 就结束了。这些琐碎的活根本不该浪费人脑。

**写提示词时**，你被迫把意图表达清楚。这不是额外负担，而是一种自发的设计训练。和 AI 协作久了，写提示词成了习惯，反而帮我梳理思路、记录计划。你会更多地思考架构和方案，而不是陷在语法细节里。

**审查 AI 建议时**，你处于批判者而非创造者的状态。这两种认知模式不同，切换之间能带来心理上的变化，让专注力持续更久。

## 意想不到的学习革命

好处还不止于认知休息。AI 彻底改变了我们学习和理解代码的方式。

以前，学习就像搭积木——先学会每个零件，再慢慢拼出复杂结构。像修车工学造引擎：先学轮子，再学发动机，再学变速箱，一步步从零开始。

有了 AI，完全反过来了。你是通过拆解一辆现成的车来学习。

我可以在完全不了解代码的情况下生成一个完整的前端。只要给 AI API 接口，它就能生成整个结构。AI 生成结构的同时，我开始理解整体。

所以我是从上到下学习的。一开始看到的是整个应用——它长什么样？然后逐步重写组件、store、函数，细节慢慢清晰起来。

刚开始，整个应用都是谜。后来我学会了 store——store 是什么？它维护什么？再到组件、响应式、各种细节，甚至某些变量或库函数的特殊行为。

对造车来说，这就像你先有一辆完整的车，但不知道内部结构，然后逐步拆解，理解发动机、变速箱、刹车等每个部分的细节。

这不仅仅是学习方式的变化——其实更可持续。你始终保持大局观，让 AI 处理具体实现。我喜欢说：“你拥有愿景，却不用背负所有细节的负担。”

## 衡量方式出了问题

这项研究测量错了指标，因为它问错了问题。他们问的是：“完成一个任务要多久？”

真正该问的是：“一个开发者在可持续的工作日内，能高质量地完成多少任务？”

这就像只用切洋葱的速度来衡量厨师的生产力，却忽略了快切反而容易割伤手、午饭前就精疲力竭。或者像那些只会盯着开发者说“你一天该工作八小时，怎么只高效了三小时，怎么这么懒？”的管理者。他们根本不懂，限制生产力的不是时间，而是脑力负荷和倦怠。

### 我们真正该怎么衡量

如果我们真的想了解 AI 对开发者的影响，应该关注：

- **全天的认知疲劳评分**
- **达到收益递减前的总高效时间**
- **错误率和 bug 引入情况**
- **重构频率**（代码是否易于维护？）
- **开发者满意度和投入感**
- **以周为单位的可持续开发速度**

## 创造力的掌控革命

还有一点研究完全忽略了：AI 其实让编程*更有创造力*，而不是更机械。

和 AI 协作时，我对代码始终有 100% 的掌控权。最初可能让 AI 生成代码，但随着想法成型，我会大量重构。

我会先让 AI 生成一个最小可用产品（MVP），一个粗略草图。代码可能很烂，但这不是重点。重点不是用 AI 的代码，而是借此明确需要哪些变量、代码要实现什么、监控点在哪、潜在问题和要创建哪些类。

有了整体蓝图后，我切换到协作模式。有时甚至会从头重写，因为 AI 生成的代码并不理想。我会根据自己的想法描述任务，让 AI 生成。如果不满意某部分，就拒绝并告诉 AI 哪里不好、怎么改。如果还不满意，我就自己写。

我说 AI 只做无聊的部分，真的 99% 的时候就是这样。好玩的部分——代码风格、维护方式、质量高低——完全由我掌控。像质量检查、字符串校验这种 if-else 逻辑的琐事，我会让 AI 生成，因为没什么技术含量。但架构决策，抽象与否，都是我说了算。

AI 在处理时间相关逻辑、复杂条件分支、需要权衡不同场景时很吃力——这正是人类创造力的舞台。以前八小时的高效时间要分给创造和琐事，现在你可以选择：只做创造性的部分，或者两者都做（如果你喜欢重复劳动）。

作为后端开发者，我以前完全不碰前端。但现在可以让 AI 处理 CSS——Tailwind 类名、HTML 结构——不用我费劲找合适的类名。这样我能专注做喜欢的事，不用牺牲用户体验。HTML 和 CSS 还需要微调，但默认生成的已经很不错了，不用太担心。

区别在于选择。技术的本质，就是让我们有更多选择。

## 重构的复兴

最深刻的变化之一？重构变得有趣而不再可怕。

以前，重构意味着几天甚至几周的繁琐劳动。你看到糟糕的代码会想：“重写要花很久，客户下周还要新功能。”技术债越积越多。

基础打好后，推倒重来变得令人畏惧。写代码太慢，即使新代码也要大量调试和重构。很吓人。

但有了 AI，重构变得非常简单。尤其是你知道自己在做什么、了解大局和旧代码时。只要写清楚需求，贴上旧代码，让 AI 生成新代码。它会很好地遵循你的旧代码风格，所以你之前写得好，AI 也能产出高质量代码。

我真的很喜欢这一点。它让你可以随时优化代码库。你不用再想“旧设计不理想，但重写太费时，客户还催着要新功能，实在没法动。”技术债就这样越积越多。但有了 AI，你随时可以决定重写。几天高强度的工作，就能获得一个全新的、更好的代码库。

最难的部分——理解问题、构想方案——已经完成。你有了愿景，实现愿景的过程变得真正有趣。重构现在成了一种享受。

## 真正的生产力革命

最有说服力的发现？尽管“变慢”了，69% 的开发者在实验结束后依然继续使用 Cursor。他们不是迷糊，也不是沉没成本作祟。他们体验到了秒表无法衡量的东西：**可持续的生产力**。

这就像是冲刺到崩溃和为马拉松配速之间的区别。AI 工具也许让每一公里慢了一点，但能让你跑得更远、不至于精疲力竭。

想想看：当你进入心流时，根本感觉不到时间流逝。你真正感受到的是疲惫。真正的问题不是“我能多快写完这个功能？”，而是“今天我能完成多少事而不至于被榨干？”

开发者觉得用 AI 更快，是因为他们一天能做更多事而不容易倦怠。他们可以快速试验抽象想法——让 AI 先用具体代码“试水”，再决定要不要投入实现。他们可以在高强度架构设计和低强度调试之间切换，给大脑适时休息。

## 挫折是真实存在的（但可以应对）

别误会——AI 工具并不完美。确实有些令人抓狂的地方会拖慢进度。

最大的问题是，AI 对一些本该显而易见的事需要明确指令。比如 Python 现在都用小写 `list`、`set`、`dict`，对吧？但 AI——即便是 Claude——还总给我大写的 `List`，还要 `import typing`。那是老旧的写法。它甚至会把我写的小写 `list` 改回大写 `List` 并加上 `import typing`，不提醒还不行。你要么加注释“不要用大写，用小写”，要么在提示词里明确写“用现代 Python 语法，不要用大写 List，要用小写 list”。

注解也是一样——`Union` 和竖线，`Optional` 和 `| None`。确实烦人，但习惯后完全可以应对。你会形成自己的提示模板，建立一套 AI 指令小抄。这些小毛病和整体收益比起来微不足道。

## 重新思考我们的工作方式

这不仅仅是 AI 工具的问题，更是对知识型工作生产力的根本性再思考。

工业时代给我们带来了时间-动作研究，用每小时产出衡量效率。但创造性知识工作根本不适用。一段五分钟“发呆”时的灵感，可能省下几周重构。一个“只”专注六小时、但精力充沛的开发者，往往比苦熬十小时的人产出更多。

我们需要超越秒表思维。我把人生比作一棵树——我们始终可以选择。像树枝一样，不能一夜之间改变方向，但可以一点点调整。你此刻就像站在枝头，可以选择向左或向右生长。

教育让你有更多选择。受过教育的人可以往左、右、中间走。过去我们被传统教育和财富门槛限制。只有有钱人才有好教育，很多人因此失去了选择。但现在有了 AI，人人平等。任何人都可以成为软件工程师，无需正规学历。任何人都可以成为心理学家，想学什么都行。AI 让你没有学习的限制，想学什么都可以。

## 前进的道路

随着 AI 工具不断进化，我们也要与时俱进地理解生产力。问题不再是“怎么写得更快？”，而是“怎么更可持续地做出更好的软件？”

未来的改进很可能会解决技术上的“变慢”：

- **语音转文本**，让提示更快更自然
- **更快的 AI 推理速度**，减少等待
- **更好的上下文理解**，减少审查负担

但即使没有这些改进，现有工具也带来了巨大价值：用一点时间，换来大量认知负担的减轻。

## 新的生产力范式

也许，是时候让秒表退出开发者生产力的主舞台了。我们可以换个角度：

- 你能否在一整天内保持专注和创造力？
- 你结束一天时还有精力学习和成长吗？
- 你的代码是否有思想、有架构，而不仅仅是能跑？
- 你是在构建可持续系统，还是在制造明天的技术债？

METR 的研究用严谨的数据证明了 AI 让开发者变慢。但他们忽略了人性——我们真正的瓶颈是大脑，而不是时间——结果反而证明了他们结论的反面。

有时候，“变慢”正是我们走得更远所需要的。有时候，最好的效率秘诀不是更快，而是选择何时冲刺、何时慢行。

最终，AI 不只是让我们成为更好的开发者。它让我们有机会成为更有思考力的开发者。