感觉快了 20%，其实慢了 19%：AI 写代码这笔账，大多数人算错了

2026 年的 Hacker News 和一年前不一样了。一年前满屏是「AI 写代码要取代程序员」，今年的高赞讨论开始算另一笔账：当你把隐性成本——审查、返工、维护、出错后的排查——都算进去，AI 编程到底有没有让团队更快交付？热闹退场，账本上场。这是好事。

让我先把一个最该被记住的数字摆出来。2025 年，一家叫 METR 的独立研究机构做了一场随机对照试验（randomized controlled trial——把任务随机分两组、一组允许用 AI 一组不许，再比结果，是医学里验药那套最硬的方法）。他们找了 16 位资深开源开发者，在自己维护多年、上百万行代码的大项目里，处理 246 个真实任务。开工前，这些人预测 AI 能帮他们省下 24% 的时间。干完之后，他们的体感是「AI 让我快了大概 20%」。而实测结果是：他们慢了 19%。

注意这三个数字之间的鬼打墙：预测快 24%，干完觉得快 20%，实际慢 19%。最危险的不是那 19% 的拖慢，是那道将近 40 个百分点的认知落差——人在变慢，却真心觉得自己在变快。

很多人看到这个标题就想喊「看吧 AI 没用」。这是误读，而且是会让你做错决策的误读。这场试验的设计里藏着关键限定：受试者是对自己的代码烂熟于心的资深人，在自己维护多年的成熟项目里干活。这恰恰是 AI 最不该被指望提速的场景。

因为在你熟到闭着眼都能写的代码里，你的瓶颈从来不是打字速度，是脑子里那张地图。解法早就在你脑子里成型了，敲出来只是手速问题。这时候让 AI 先写一版，你得读它、懂它、挑它的错、把它改回你本来就想要的样子——这一整套审查和返工，是凭空加上去的税。AI 没帮你跳过思考，它让你多做了一道校对题。

那 AI 到底什么时候真能提速？答案藏在同一个机制的反面：**你和代码之间的知识落差越大，AI 的价值越高。**陌生的技术栈、没碰过的框架、从零起步的原型、那种谁都不想手写的样板代码——这些场景里你本来就要边查边试边踩坑，AI 把「查文档、试错、写胶水代码」这段最磨人的路压短了。落差越大，省得越多；落差越小，越是帮倒忙。

把这个判断翻成一句给老板和投资人听的话：**AI 编程的回报，不取决于模型多强，取决于你把它放在了知识落差的哪一头。**你要是让最资深、最懂这套系统的人，在他们最熟的模块上全员上 AI，然后纳闷为什么没提速——你押错了地方。真正该上 AI 的，是新人接手陌生模块、是探索没人做过的方向、是一次性的快速验证。同一个工具，放对地方是加速器，放错地方是认知税。

但这篇文章真正想让你带走的，不是「AI 该放哪」，是那道近 40 个百分点的落差本身。

它告诉你一件事：**关于自己有没有变快，人的体感是不可信的。**这些受试者不是新手、不是外行，是各自项目里最懂行的那个人，结果集体把方向判反了。你团队里的人也一样——他们会真诚地告诉你 AI 让他们快了不少，而那句话可能和事实差了快 40 个百分点。如果你的 AI 战略建立在「大家都说快多了」这种体感上，你是在用一个测不准的仪器做重大投资决策。

我自己每天靠 AI 出货，但我从不信「感觉快了」这句话。我盯的是周期时间（cycle time——从开工到交付实际花了多久），不是爽不爽。这不是不信任 AI，恰恰是因为我太依赖它，才更不敢用体感替代度量。METR 自己也清楚这事没完——2026 年初他们还在公开调整这个实验的设计，继续往下测。一个连研究机构都还在反复校准的问题，企业却常常凭一句「感觉快多了」就拍板，这本身就是答案。

AI 写代码到底快不快，是个真问题。但比它更要紧的问题是：你有没有在量？你不量，就只能赌体感；而这场试验已经告诉你，体感会骗人，连专家的体感都骗人。