同事试用免费聊天机器人，觉得它连简单问题也会答错；另一边，开发者让智能体在代码库里连续工作，开始重新估算一个项目需要多少人天。两种体验都可能真实，却不是同一类测试。Andrej Karpathy 最近用“四层漏斗”描述这种认知差距。真正有价值的不是争论哪一层更懂 AI，而是弄清楚任务、模型、工具、验证方式与访问权限如何共同改变结果。
先把“5000 人”放回原意
Karpathy 在原帖中回顾自己四月关于 AI 认知差距的判断，给出一组“餐巾纸估算”：约 60 亿人几乎没接触过大语言模型；约 10 亿到 20 亿人偶尔用免费聊天产品；约 2000 万人能够在数学、编程等专业任务中体验前沿模型；约 5000 人可接触实验室内部的前沿系统。这是他用来解释所见能力不同的比喻，不是经过人口抽样和统一口径统计的四组精确人数。群体边界也未严格互斥，不能把百分比当成调查结果相加。
图 1：原帖的论点是“共同理解的差距扩大”，不是宣布一个经审计的全球用户统计。
图 2：60 亿、10 亿至 20 亿、2000 万、5000 人均为 Karpathy 的粗略估算；“5000 人知道真相”不是可验证的人口结论。
原文转述还提到实验室内部的多智能体协作、网络安全和科研任务。这些是 Karpathy 对内部前沿的描述；公开读者缺少独立任务记录，不能据此断言“系统已经普遍完成某种数年级科研任务”。尤其是“能发现漏洞”“会推动数学”等说法，应该追问具体任务、成功条件、人类审核和可复现记录。
漏斗其实混合了四个变量
把四层理解为“人越来越少、模型越来越强”太粗了。至少有四个变量同时改变：
| 变量 | 低接触场景 | 专业场景 | 容易误判的地方 |
|---|---|---|---|
| 任务 | 搜索、闲聊、短文改写 | 修复代码、证明步骤、数据分析 | 简单任务测不出长任务能力 |
| 产品与模型 | 免费入口、默认设置 | 可选模型、长上下文、工具调用 | 把一次旧版本体验当成所有模型水平 |
| 工具与反馈 | 只有对话框 | 仓库、终端、测试、文档、审阅 | 把“模型单独完成”与“系统协同完成”混淆 |
| 使用者 | 临时提问 | 能拆任务、写验收并查错 | 把高水平用户的成果全归因于模型 |
四月的早期帖子已经提醒：一个人若只试过一次免费聊天体验，和一个人每天用 Codex 或 Claude Code 做可验证的工程任务，谈论的对象不完全相同。不过，付费本身也不保证收益；不会定义问题和验收标准，买高档订阅照样可能只得到昂贵的聊天记录。
图 3：比较 AI 能力前，先说清使用的时间、档位、工具和任务，避免跨条件下结论。
为什么代码与数学更容易显出进步
Karpathy 强调“可验证”的重要性。代码能运行测试，数学答案在部分任务上有明确校验，系统就能得到更清晰的训练和评估反馈。这里不能简单推成“写作不赚钱所以没人训练”，也不能认为所有代码任务都有客观唯一答案。真实工程的需求是否被理解、架构是否可维护、隐私是否合规，仍然需要人来判断。
从评估角度看，SWE-bench这样的基准把软件问题、仓库环境与测试联系起来；METR 的任务时间跨度研究则尝试把“能完成多长的人类任务”转成可测指标。两者都比一句“我感觉它更聪明了”更可讨论，但它们也不等于你的业务工作流：基准上的成功率、实际成本、上线后的故障率和人类复查时间必须分别记录。
图 4：这部分解释了为何专业用户感受更强，但属于观点和经验描述，不能代替你的团队实验。
一个开发者让代理修好单元测试，可能几分钟就得到绿色结果；同一个代理修改计费规则时，即使测试全绿也可能漏掉退款、边界日期或已有客户的兼容性。可验证任务是提高反馈密度，不是把判断责任交给测试数字。
用七天测出自己的“能力差距”
与其定位自己属于哪层，不如找三项真实工作，把 AI 放到清楚的边界里试。下面是一个小团队能执行的七天安排：
- 第 1 天，选任务。 各挑一个标准化的小任务、一个中等复杂度任务、一个需要多文件或跨资料的任务。写下人手完成时的基线时间和质量要求。不要只选模型擅长的演示题。
- 第 2 天，固定环境。 同一仓库版本、测试集、可访问文档、权限和数据脱敏方案。记录产品、模型、订阅或 API 计费口径。若无法固定版本，就在记录里说明。
- 第 3～5 天，运行与复核。 每项任务至少重复三次；保存输入、工具轨迹、生成文件、失败日志、人工修改。让了解业务的人盲审结果，尽量不先告知用的是哪个模型。
- 第 6 天，算总成本。 除模型费用与耗时，还算人工提示、审核、修复和上线回归。一次成功但需要大量修补，与三次稳定交付不是同一个结果。
- 第 7 天，决定使用边界。 把任务分为可自动交付、需人工复核后交付、不适合当前使用三类。写好回退条件，而不是一口气把全部工作切到智能体。
给代理的任务书可以按这个最小格式写，代码、研究和内容生产都能改用：
目标：在已有项目中修复导出文件名重复的问题。
输入：当前仓库；复现步骤；三条失败样例；现有测试。
权限：可读取并修改 src/export；不得改数据库或调用外网。
验收：新增覆盖重复文件名和中文路径的测试；全部相关测试通过；
输出变更文件、影响范围、仍未验证的风险。
停止条件：需要新增权限或发现需求冲突时，先报告，不自行扩大范围。
目标：在已有项目中修复导出文件名重复的问题。
输入：当前仓库；复现步骤；三条失败样例；现有测试。
权限：可读取并修改 src/export；不得改数据库或调用外网。
验收：新增覆盖重复文件名和中文路径的测试；全部相关测试通过；
输出变更文件、影响范围、仍未验证的风险。
停止条件：需要新增权限或发现需求冲突时，先报告，不自行扩大范围。
这个模板的价值在于给出任务边界与可观察结果。对于写作类任务，可以把“测试通过”换成事实核对、引用可打开、用词准确和目标读者能否按步骤操作。两类任务的评分标准应不同，不能拿同一个“聪明程度”分数解释所有能力。
三张表，比“AI 很强/很弱”有用
任务表写清输入、难度、数据敏感性和成功标准。运行表逐次记录模型、工具、耗时、费用、通过率、人工修复分钟数。结果表记录可以交付的产物、错误类型、复查结论。每条失败至少标一个根因：任务描述含糊、上下文不足、工具权限、模型判断、测试缺口，或者人工误判。
一个最小指标组可以这样算：任务完成率 = 达到验收条件的运行次数 / 总运行次数；有效节省时间 = 人手基线时间 − (提示 + 等待 + 审核 + 修复时间)；每个可用结果的成本 = 总费用 / 可交付结果数。高难任务最好同时记成功率与失败损失，避免“平均很快”掩盖少数昂贵错误。
若通过 ClaudeAPI / Apito 调用模型，除上述三张表外，再逐次记录请求的模型名、实际响应 ID、用量和账单。先弄清平台别名与上游模型的映射关系，避免把“访问档位不同”误判成“模型能力差异”；限额与超额计费也应按账号实际页面核对。
图 5：四月的观点与这次“漏斗”是一条线索：体验差异有任务、时间、档位和工具背景。
这篇讨论该怎么用
Karpathy 的提醒是：大众感受到的聊天质量，与专业用户在可验证任务上感受到的进步，可能同时成立。他的具体人数只是粗略估算，内部系统能力也需要更多公开证据。对团队最实际的做法是把争论改写成可重复实验：同一任务、明确权限、公开验收、记录人工复核与总成本。这样，即便你并不处在所谓“5000 人”之内，也能知道哪些工作今天已值得交给 AI，哪些仍需要人负责。
资料来源：Karpathy 原帖、METR 任务时间跨度、SWE-bench 说明，以及引发讨论的微信文章。核查日期：2026 年 10 月 12 日。
常见问题（FAQ）
“全球只有 5000 人知道最强 AI”是统计结论吗？
不是。Karpathy 将约 5000 人称作接触实验室内部前沿系统的人群粗略估算，没有提供可审计的人口调查；转述时应写“他估计约 5000 人”，不要写成全球精确人数。
免费聊天机器人答错题，能说明前沿智能体没用吗？
不能。它只能说明该产品、版本、设置和题目下的表现。判断工作价值，要用目标任务、相同材料和真实验收标准测试。
开发者看到的生产力提升，也能直接推广到所有行业吗？
不能。代码和部分数学任务的结果更容易被测试，但医疗、管理、写作等领域有不同的正确性、责任与数据约束，需要单独试验。
只要给团队买高档订阅，就能进入“专业层”吗？
不一定。专业成果还依赖任务拆解、工具权限、上下文质量、复核与迭代习惯。先做七天小范围试验，再判断投入是否划算。
如何避免模型“看起来完成了”，实际留下隐患？
保留运行日志和差异文件，执行测试之外再审查业务边界、安全和回退方案；把人工复查时间计入总成本。
