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

现在想象一下, 有人在旁边拿着秒表计时, 只因为这个 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 不只是让我们成为更好的开发者。它让我们有机会成为更有思考力的开发者。