当 AI 让你觉得自己变快了，但数据说你慢了
- 作者：Bougie
- 创建于：2026-06-21
上周我在一个技术群里看到有人转发一条推文，说的是 2025 年 7 月有个实验，让真正的开源开发者用 AI 编程工具来完成任务，结果发现——他们变慢了。不是慢了一点点，是慢了将近五分之一。
我当时的第一反应是：扯淡吧。
毕竟我自己也在用 GitHub Copilot，每天写代码的时候那个补全弹出来，感觉流畅得很，键盘敲得噼里啪啦响，整个人都沉浸在一种「效率爆表」的自我感动里。怎么会慢呢？
但这条推文的数据来源是 METR——一家正经做 AI 安全研究的非营利机构，不是那种靠标题党博眼球的科技自媒体。他们做了随机对照实验，把开发者分成两组，一组用 AI 辅助，一组不用，然后测量实际产出。结果那些自信满满估计自己会快 20% 的开发者们，实测反而慢了 19%。
这个帖子在 X 上疯传，三百万阅读。
我仔细想了想这件事，发现它有意思的地方不在于「AI 工具没用的」这个结论，而在于那种认知和现实的撕裂。
开发者们并不傻。他们都是经验丰富的老手，写过的代码比很多人读过的书都多。他们说「感觉快了」，那多半是真的感觉快了——补全确实让打字少了，样板代码确实不用自己写了，文档确实能快速生成。可最后的结果却是慢了。
这里面的落差让我着迷。
有人说原因是 AI 生成的代码质量参差不齐，你得花大量时间去审查、debug、甚至重写。说白了，你以为自己在写代码，其实你在当代码的校对员。一开始你以为省了时间，后来发现省的那点时间全贴在纠错上了。
这个解释我接受，但我不想把它当成全部。
还有一种说法更让我在意——AI 打断了熟悉旧 codebase 的人的工作流。什么意思？你在一个大型项目里泡了两年，哪些地方是坑、哪些模块是祖传代码、哪些命名是历史遗留问题，你心里门清。突然来了个 AI，它不知道这些，它给你生成的代码可能是「看起来对」但「跑起来炸」的那种。你得先理解它在干什么，再判断能不能用，这个判断过程本身就增加了认知负担。
有时候无知是福。你不知道某个地方有坑，你可能就不会踩。但 AI 知道，它会提示你，于是你开始小心翼翼，开始怀疑自己原本顺畅的思路，开始停下来思考那些本来不会被想到的问题。
这算好事还是坏事？
不好说。但如果你的目标是「快点完成任务」，那这种打扰确实会让你变慢。
我见过一个更扎心的解释：「生成」便宜，「验证」昂贵。
软件工程的瓶颈从来不在于你能不能写出代码，而在于你写出来的代码能不能用、会不会破坏已有的东西、有没有你没考虑到的边界情况。这些验证工作，人做起来慢，AI 做起来也慢。你让 AI 生成一段代码很快，十分钟。你验证它能不能集成到现有系统里，三小时。
这不是工具的问题，这是任务结构的问题。
我们衡量一个编程工具的效率时，往往看的是「生成速度」——它能多快地给你一段可用的代码。但真正的工程瓶颈从来不在生成，而在整合、测试、调试、达成共识。代码写出来只是第一步，它要跑起来、要被人维护、要和其他模块和平相处，这些才是花时间的大头。
AI 压缩了生成环节的成本，却把压力转移到了验证环节。
你省了写的时间，但花在「这玩意儿到底能不能用」上的时间变多了。这笔账怎么算，每个人的体验不一样——新手可能觉得赚了，因为验证对他们来说本来就要花很多时间；熟手可能觉得亏了，因为验证对他来说是自动化的，而生成反而是消耗精力的部分。
但这篇文章我最想聊的，不是技术层面的分析，而是一个更虚的问题：
当一个工具让你感觉自己变快了，但实际数据说你慢了，会发生什么？
我的判断是：你会越来越依赖这个工具。
这不是什么阴谋论，这是人之常情。人类的自我认知本身就极度依赖主观体验。你感觉高效，你就会觉得自己应该继续用这个方法。你不会去查数据——或者即便查了，你也会倾向于认为那次数据有问题、那个实验设计不严谨、我的情况不一样。
这种感觉和现实的脱节，其实是个心理学问题，叫「可得性启发」——你记住的是 AI 帮你快速搞定一个小任务的爽感，而不是后面花了两天 debug 的糟心经历。前者 vivid，后者模糊，前者主导了你的判断。
这意味着什么？
意味着工具设计者有巨大的道德责任。他们展示的往往是「使用前 vs 使用后」的对比图，那个「使用后」的截图总是漂亮的、流畅的、让人心动的。但他们不会展示「这段代码从生成到通过 code review 一共花了多少时间」，因为这个数据不好看，因为这个数据会让人犹豫。
我们正处在一个 AI 工具狂飙突进的时代，每个人都在推你「快用啊」「用了就起飞了」。但飞没起飞，其实只有你自己知道。
写这篇文章的时候，我自己也卸载不了一些 AI 插件。原因很简单：即便它让我慢了，我用它的感觉很好。好感觉是有价值的，情绪价值也是价值。但如果我把它当成「效率工具」来用，那我可能需要重新校准一下自己的预期。
这个实验给我的最大启示，不是「AI 编程不行」，而是我们可能从一开始就搞错了问题。
我们在问「AI 能不能帮我写代码更快」，但真正的问题是「什么是软件工程的快」。如果你的答案是「代码产出得快」，那 AI 确实能帮上忙。如果你的答案是「软件能更快地可靠交付」，那 AI 能帮多少忙还真不好说。
这两个问题看起来很像，其实是两码事。
就像你问「开车能不能让我更快到达目的地」，答案是「取决于你往哪开、路上堵不堵、你的车会不会抛锚」。工具永远只是工具，它不会自动等于效率。
三百万人在看那个实验，有人震惊，有人反驳，有人开始自查。但真正重要的也许是：下次你在键盘上敲得飞快、感觉良好的时候，问自己一句——我到底是在「变快」，还是在「感觉变快」？
这个问题没有标准答案。但它值得问。