你在 AI 漏斗的哪一层？

10 月 11 日，Andrej Karpathy 把自己 4 月的一篇旧帖重新翻了出来。他补了一句开场：人们关于大模型能力的认知差距，还在变大——已经不再是「两群人各说各话」，而是一座越来越陡的漏斗。

漏斗有四层。他给的是随手估算，自己也承认没查过出处：约 60 亿人（全球人口的七成半）几乎没碰过大语言模型；10 到 20 亿人偶尔用用免费的聊天产品；约 2000 万人在代码和数学里用前沿模型；能接触实验室内部系统的，只有约 5000 人。

数字是拍脑袋的，形状却对得上。ChatGPT 的周活跃用户，OpenAI 在今年 DevDay 上说的是 12 亿；Google 说 Gemini 应用月活超过 10 亿——两个数字有重叠，第二层的 10 到 20 亿是个合理的区间。微软财报说 GitHub Copilot 有 5000 万用户，看起来比 2000 万多了一倍多，但 Copilot 里很大一部分只是代码补全，Karpathy 自己说他早就不靠补全写代码了；OpenAI 说 Codex 每周有 500 万人在用，其中还有上百万是程序员以外的人。2000 万这个量级，站得住。

最顶上的 5000 人没有公开数字可以核对。但这一层最近漏出来过两次光。一次是 OpenAI 放出的 722 份数学手稿——全部由一个没有发布的模型生成，10 月 6 日挂上 GitHub，第二天就撤回了 3 份，原因是一个符号错误，另外还修订了 14 份。另一次是 OpenAI 在 Hugging Face 上的那次事故，几个月过去，外面的人还在拼它的全貌。Karpathy 对这两件事的评语只有一句：人类的审阅和理解，开始跟不上了。

一、你用的 AI，和工程师用的不是同一个东西

漏斗第 2 层的人看到的 AI 是什么？一个网页，一个对话框，一问一答。它很聪明，但你问完一句，它答完一句，你们的交互到此为止。

漏斗第 3 层的工程师看到的是另一个物种。Claude Code、Codex、Cursor 这类工具里，模型不是坐在对话框里等人提问——它拿到一个任务，自己去读代码库、改文件、跑测试、看报错、再改。一个几周的工作量，可能就是一句描述加一顿等。这一层的典型体验是：你下班前派了个活，第二天回来验收。

到了第 4 层，实验室内部跑的是成群的 agent，几周地做大型项目。外部的人只能从 722 份手稿这种「泄露的光」里猜那是什么样子。

同一个公司、同一个品牌名，三层产品背后是完全不同的系统。价格线也画得很清楚：免费、每月几十到几百美元、非卖品。分层不只是认知问题，它是物理的。

二、为什么偏偏是代码和数学先被攻陷

Karpathy 给漏斗的解释有三条：做大事需要大问题；能力的高峰出现在数字化、可验证、有价值的工作上；以及访问分层。中间那条是钥匙。

强化学习要能跑起来，得有个自动判分的裁判。代码恰好有：测试跑得过就是跑得过，报错就是报错，一行代码的对错不需要请示任何人。数学更极端：证明对了就是对了，形式化系统可以逐行检查。这两个领域，模型每做一步，机器立刻告诉它做对了没有——这才是强化学习如鱼得水的地方。

聊天产品面对的任务大多没有裁判。帮你写封道歉信，写得好不好？没有测试集可以跑。没有判分器，强化学习就转不起来，进步只能靠预训练慢慢攒。于是同一个行业里出现了时间流速差：代码和数学里的能力几个月上一个台阶，聊天场景里的体验变化慢得多。第 2 层的人觉得 AI 大概就这样了，第 3 层的人已经在跟会自己干活的工具共事——他们没有说谎，他们看到的就是两个物种。

三、慢 19% 的实验，说了什么

2025 年 7 月，评测机构 METR 做了个随机对照实验，结果让很多人意外。

实验找来 16 位资深开源开发者，处理的都是他们自己熟悉多年的开源仓库里的真实 issue，一共 246 个任务。一半任务允许用 AI 工具（当时最新的模型加 Cursor 这类产品），一半不许用，屏幕全程录像，逐秒计时。

开发者们事前预计 AI 能让他们快 20%。实测结果：允许用 AI 的那组，完成任务慢了 19%。

慢在哪？时间去了三个地方：写提示词、等模型生成、以及最贵的——审查 AI 给出的代码。这些开发者对自己维护的仓库熟到什么程度？很多改动他们闭着眼都知道该动哪个文件，AI 生成的方案反而要花时间核对。手感说快了，秒表说慢了。

这个实验常被读成「AI 编程没用」，读反了。它真正的教训有两个。第一，结论有边界：这些是资深开发者在自己最熟的仓库里干活，换成生疏的代码库、样板代码、全新的项目，AI 的收益是另一回事。第二，也是更重要的：手感不可信。连这批最专业的人，对自己效率的估计都错出了 39 个百分点。

四、算一算 AI 到底帮你省了多少

METR 的方法，你自己可以缩一小圈照着跑，一下午就够。

第一步，攒任务。从你真实的工作里挑 10 到 20 个同类任务，难度差不多，比如都是写一个小功能，或者都是修一类 bug。

第二步，交替分组。不要上午全用 AI、下午全不用——你会越做越熟练，下午本来就快。随机把任务分成两组，让顺序打乱。

第三步，秒表计时，从接任务到「我愿意为它负责为止」。这句是关键：AI 写完不算完，你读完、改完、测试通过才算完。METR 的 19% 大半就藏在「读完改完」里。

第四步，记下返工次数。AI 生成的代码你改了几处？跑挂了几次？

第五步，算比值：不用 AI 的总时间，除以用 AI 的总时间。大于 1，AI 在帮你；小于 1，你在帮 AI。按任务类型分着算——样板代码、调试、重构、生疏领域，各自的比值通常差别很大。

这套方法量不出论文级的结论，但量得出你自己的数字。比「感觉快多了」可靠得多——那批资深开发者也是这么感觉的。

漏斗的顶端正在漏出越来越多的光，而审阅它的人手不够用了。Karpathy 那座漏斗最陡的地方，不是 60 亿人和 5000 人之间，是每一层的人想象上一层时，脑子里那张图和实物之间的距离。

你在哪一层？评论区聊聊。