为什么你用 AI 写代码感觉快得像飞，身体却诚实得像驴
- 作者：Bougie
- 创建于：2026-06-18
- 更新于：2026-06-18
上周五晚上十一点,我对着屏幕发呆。
三小时前我信心满满地打开 Cursor,让 Claude 帮我重构一个我写了两年多的内部工具。代码我熟,逻辑我熟,连当时为什么用那个蹩脚的命名我都记得。结果呢?AI 生成了一堆「看起来对」的代码,我合并进去,第二天早上打开 PR review,发现三个人给我留了一屏幕的 comment。
这事儿我憋了好几天没跟人说,直到看见 METR 那个实验报告——然后我释然了,甚至有点想笑。
原来不止我一个。
# 那个让你慢 19% 还觉得快 20% 的实验
METR 2025 年做了个挺有意思的实验:找了 16 位平均 5 年经验的资深开发者,让他们用 Cursor Pro 配 Claude 3.5/3.7 Sonnet,去处理自己熟悉的大型开源项目里的真实任务。一共 246 个任务,每个任务平均耗时两小时。
实验开始前,这些开发者普遍预期 AI 能让自己快 24%。
实验结束后呢?
客观数据显示,他们慢了 19%。
主观感受呢?
他们仍然坚信自己快了 20%。
差了多少?39 个百分点。
这就是我想聊的事。不是 AI 有没有用,而是:我们的大脑是怎么做到把自己被降速的事实解读成提速的?
# 「顺滑感」是个骗子
我先承认一件事:我用 AI 写代码的时候,感觉特别好。
那种感觉怎么形容呢,就像有人帮你把积木搭好了,你只需要说「这里再加一块」「那块颜色不对」。手指几乎不用动,屏幕上的代码哗哗地往外冒。你看着进度条往前走,看着文件一个一个被创建,觉得自己在掌控一切。
问题是——你在掌控的,是打字这件事。
不是解决问题。不是理解需求。不是思考边界条件。
你把最累的脑力活外包出去了,然后把剩下的「执行快感」当成了「效率提升」。
这就像你以为自己在健身,其实只是在跑步机上追剧。汗出了,腿没练。
这种顺滑感会骗人,而且骗得很彻底。因为它满足了我们对「生产力」最肤浅的想象——屏幕上有产出,手指不用动。
但代码这东西,产出不等于价值。能跑不等于能维护,能上线不等于能 debug,能写不等于该写。
# 任务升级:你以为在做同一件事
我回想自己用 AI 的那些晚上,有一个很微妙的转变。
一开始我想的是「让它帮我写这段代码」,结果它写完之后,代码结构变了,依赖关系变了,甚至有些需求被它「理解」成了另一个样子。我本来想修一个 bug,结果它帮我重写了一整个模块,然后告诉我这样「更优雅」。
我盯着那个 diff 看了半天,发现我得先花两小时理解它写的,然后花两小时决定要不要接受它,最后花三小时把它不符合规范的地方改掉。
这中间有大量工作是我本来不需要做的。
METR 的实验里有个细节我觉得很关键:这些开发者用的是自己熟悉的项目。理论上,熟悉的代码库应该让 AI 发挥更好,因为上下文清晰嘛。
但实际上呢?
反而慢了。
原因之一就是:AI 在熟悉的代码库里更容易「自作主张」。它看见了那些我故意没重构的代码片段,它读出了那些「这地方先这样,以后再改」的注释,然后它决定「帮你一把」,把那些我有意保持原样的地方全部翻新了。
你以为你在做 A 任务,AI 把它升级成了 A+ 任务,然后再加个 B 和 C。你看着完成的任务列表很长,实际上你原来的那个活根本没干完。
# 产出变多不等于交付变多
CodeRabbit、GitClear、Faros AI、Jellyfish、SonarSource 这些机构 2025 到 2026 年的数据都指向同一个方向:
AI 让代码产出变多了。
PR 数变多了。代码行数变多了。commit 频率变高了。
但是——返工变多了。代码审查积压了。安全漏洞变多了。上线后发现问题的比例也变高了。
这就好比你开了一家快餐店,装了个自动出餐机器,出餐速度是原来的三倍。结果呢?顾客抱怨越来越难吃,退单率飙升,你还得雇更多人来处理投诉和重做订单。
产出和交付是两回事。
我一直觉得「代码行数」是个特别骗人的 KPI,但现在大家好像又找到了新的骗人 KPI:「AI 生成代码的行数」。这个数字会让人上瘾,因为它一直在涨,你看着它涨就觉得自己在进步。
直到有一天你打开技术债务账单,发现上面写着:这季度新增代码 12 万行,其中 8 万行是我们三个月前 AI 生成现在要重构的。
# 那个金融公司的朋友
上周跟一个朋友吃饭,他在一家金融公司做技术管理。我们聊到他团队去年上的 AI 工具。
他原话是这么说的:
代码产出涨得猛,但代码审查开始积压,安全问题也变多。
他们用了一整套 AI 编程工具,PR 数量翻倍了,code review 团队直接原地爆炸。以前每个人提的 PR 都能当天 review 完,现在积压了三天才有人看。安全扫描报警次数比之前多了 40%,其中一半是 AI 生成的代码里用了有漏洞的依赖。
但你猜他老板怎么说?
「产出翻倍了啊,很好,继续用。」
他没有跟老板提审查积压的事,因为那些东西没法量化,而代码行数就在那摆着。
# 为什么会差这么多?
我琢磨这事琢磨了好几天,总结了几个我认为的原因,不一定对,但都是我真实想过的:
第一,我们倾向于把「顺」当成「快」。 AI 写代码的过程很顺,没有卡壳,没有搜索,没有反复试错。这种流畅的体验会让我们低估背后的认知成本——理解 AI 写的代码、验证它是否符合预期、修复那些「看起来对但实际错」的部分。
第二,锚定效应。 实验前开发者预期自己会快 24%,这个预期会像一个锚一样钉在那里。哪怕实际结果是负的,你也会倾向于往锚的方向解释数据——「虽然慢了一点点,但我确实没有像原来那样卡壳嘛」。
第三,任务边界模糊了。 用 AI 之后,你做的任务往往比原来的范围更大。AI 帮你扩展了需求,帮你加了功能,帮你「顺手」优化了隔壁模块。你觉得效率高了,但其实你做的已经不是原来那个任务了。
第四,确认偏误。 你花了钱,开了工具,花了时间学习怎么用它——这些成本都会让你倾向于相信它有用。承认 AI 让我变慢了,等于承认我之前的投入是错的。大脑不干这种事。
第五,记忆的滤镜。 我们更容易记住那些「AI 帮了大忙」的瞬间,忘记那些「AI 挖了一堆坑我来填」的时刻。事后回想,全是 AI 神助攻的故事。
这五条原因,前两条几乎是我们大脑的默认设置,后三条更是被「用 AI 写代码」这件事放大了无数倍。
# 不是 AI 的错,但也不只是人的问题
写到这里我想说清楚一件事:我不在否定 AI 写代码这件事。
AI 确实能帮你写 boilerplate,确实能帮你查文档,确实能在你想不出某个 API 怎么用的时候给你一个方向。这些我都用,而且觉得有用。
问题在于——我们把它当成了一个可以测量「效率」的变量,但效率这东西从来没这么简单过。
软件开发不是打字比赛。代码是手段,交付是手段,解决问题是手段,最终的价值是手段之上的东西。把工具层面的顺滑当成整个系统的效率提升,这是个很常见的误区。
METR 的那个实验最让我震撼的,不是 19% 和 20% 的数字本身,而是那个 39 个百分点的差距。
我们的大脑就是这样工作的。它会把自己干的蠢事包装成合理的决策,把自己挖的坑描述成「虽然有代价但是值得」。这种自我辩护机制在进化上可能有用,但在评估工具效果这件事上,它让我们彻底瞎了。
# 我看到的几条「歪路」
我观察周围用 AI 写代码的同事,发现大家普遍在走几条歪路,可能你也正在走:
用行数代替价值。 「我今天用 AI 写了一千行代码」是句自豪的话吗?以前我们说「我今天写了两千行 bug」是在自嘲,现在我们说同样的话,是在汇报成绩。
用 PR 频率代替交付节奏。 以前一个 PR 代表一个完整的、可评审的改动;现在一个 PR 可能是一段「AI 生成的草稿等我有空再改」的东西。PR 数翻倍了,改动质量呢?
用 AI 调试率代替真实能力。 你用 AI 帮你 debug 出一段代码的 bug,跟你自己 debug 出来,价值完全不一样。前者让你下次遇到类似问题还是不会,后者让你下次能自己解决。
用「我能用 AI」代替「我能写代码」。 简历上写「熟练使用 Cursor + Claude 辅助开发」,跟「能独立完成核心模块的设计和实现」,在面试的时候差别有多大,谁心里都清楚。
# 我的建议
写到这里好像应该给几条建议了,但说实话我也不知道什么是对的。
我能说的是:如果你用 AI 写代码感觉效率飞起,找个时间停一停,看看自己真正在交付的东西是什么。
review 积压了吗?bug 率变了吗?代码在往更复杂走还是在变简单?技术债务是多了还是少了?
这些指标没有 AI 帮你生成,但它才是真正重要的东西。
还有就是,别太相信自己的感觉。
我们都不太相信。
写完这篇文章的时候我看了一眼时间,凌晨一点二十三分。Cursor 的建议栏弹出来:「要不要帮你写结尾?」我点了拒绝,然后手动敲完了最后几行。
不知道这算不算一种反抗。但至少这段是我自己写的,这个感觉还挺踏实的。