AI 评测正在对着空气打靶：Mercor 地图显示 90% 美国工时没有基准覆盖

我们每天都在看榜单：SWE-bench 上谁又涨了两个点，某个新模型在数学推理上超过了 GPT，最新的 agent 评测里 Claude 还是第一。这些分数塑造了我们对"哪个模型更强"的全部直觉。但 Mercor 刚刚发布的一项研究，往这个直觉上泼了一盆冷水——我们天天盯着的榜单分数，可能只测量了大约 10% 的真实工作。

Mercor 的原话值得逐字读一遍："Our findings suggest that 90% of American working hours are spent on tasks with little or no coverage from existing benchmarks. This makes it very hard to know how good AI models are at the work Americans actually do."（我们的研究表明，90% 的美国工时都花在现有基准几乎没有覆盖的任务上。这让我们很难知道 AI 模型在美国人实际从事的工作上到底有多强。）

换句话说：AI 评测这套体系，正在对着空气打靶。靶子立在 10% 的地方，剩下 90% 的工作量根本没人测量。

Mercor 到底做了什么

Mercor（那家做 AI 人才招聘、也做 APEX 基准的公司）搞了一个"美国经济基准地图"（Benchmark Map）：把一小批高质量 AI 基准里的每一个测试 prompt，映射到美国劳工部 O*NET 职业分类体系里的具体工作任务上，然后看——美国人实际干的活，到底有多少被基准测到了。

方法论是扎实的。O*NET 把美国劳动力分成 923 个职业（occupations），每个职业下面列出构成该职业的"任务"（tasks），全部加起来是 18,797 个任务。原文写道："O*NET divides the US workforce into 923 occupations; for each occupation, O*NET attempts to provide a comprehensive list of "tasks" which make up the occupation, totaling 18,797 tasks across all occupations."

Mercor 从 29 个基准里挑了一个初始列表——入选标准是：公开可用（至少 25 个公开任务）、测的是 agentic 任务而不是问答、任务贴近真实企业场景、每个职业家族限量入选（刻意压制软件工程类基准的过度代表）、以及尚未被前沿模型刷爆。然后用一个 LLM judge 把每个基准 prompt 标注到它对应的 O*NET 任务上（用自家 APEX 基准上的人类专家标注做了校验）。一条 O*NET 任务，只有被至少 5 个基准 prompt 命中，才算"被覆盖"。

这个"≥5 个 prompt"的门槛其实已经很宽容了——结果依然惨烈：923 个职业里，只有 208 个职业拥有至少一个被覆盖的任务；22 个职业家族里，有 6 个家族连一个被覆盖的职业都没有。原文："only 208 of 923 occupations have a task with at least 5 benchmark prompts, and 6 of 22 job families have no such occupations."

这张地图本身是怎么画出来的

光看数字容易低估这项工作的分量，值得把方法论摊开看一遍，因为它决定了 90% 这个数字可信到什么程度。

页面的主体是一张交互式地图：923 个小方块，每个代表 O*NET 里的一份职业，按 22 个职业家族分组，方块颜色深浅代表该职业的任务在初始基准列表里的覆盖比例，点击一个家族可以展开看里面的职业。单看这张图，软件工程、金融分析那几个家族是亮的，卡车司机、工厂操作相关的家族几乎全暗——"深而窄"的覆盖格局一目了然。

覆盖的判定链条有四环。第一环是基准选择：29 个基准，入选要过五道筛——公开可用、测 agentic 任务、经济真实性（真实企业里高频出现的任务优先于学术上复杂的任务）、经济多样性（每个职业家族限量，专门用来对冲软件工程任务在流行基准里的海量过度代表）、难度均衡（还没被前沿模型刷爆的）。第二环是映射：借鉴 Wang 等人的工作，用 LLM judge 给每个基准 prompt 打上尽可能多的 O*NET 任务标签，再用 APEX 基准上的人类专家标注做校验。第三环是门槛：一个 O*NET 任务至少被 5 个 prompt 命中才算覆盖。第四环是工时换算：把覆盖估计和 Hatgis-Kessell 等人用 LLM 估算的"每个 O*NET 任务占工时比例"结合，算出美国人花在"被覆盖任务"上的总工时占比——这就是 90% 的来处。

偏向性分析用的是任务级别的 logistic 回归：覆盖概率对 AI 暴露度、职业工资总额的对数做回归，误差棒是按职业组聚类的 95% 置信区间。工资总额按美国劳工统计局（BLS）的平均工资乘以各职业从业人数、假设每周 40 小时算出。这套统计是认真的，不是拍脑袋的描述性统计。

所以 90% 的含义要精确理解：它不是"90% 的职业没被测"，而是按工时加权之后，90% 的美国人工作时间花在"基准覆盖极少或没有"的任务上。职业层面的数字（208/923）和工时层面的数字（90%）是两回事，后者更扎心，因为它直接回答了"榜单分数离真实经济有多远"。

覆盖不是随机的：基准偏爱高薪、AI 易暴露的岗位

更扎心的是第二层发现：基准的覆盖偏差不是随机的，而是有系统性偏向。即使控制了"AI 暴露度"（AI-exposure，即任务被 AI 自动化的可能性），工资总额越大的职业，其任务被基准覆盖的概率显著越高；而在同一职业内部，被 O*NET 领域专家评为"最重要"的任务，被覆盖的概率是"最不重要"任务的约 6 到 10 倍。

AI 暴露度本身也是一个强预测因子：被标记为"exposed"的任务，被基准覆盖的概率大约是"unexposed"任务的 6 倍。这听起来合理——基准本来就是为了测量 AI 进展，而 AI 进展最可能发生在最容易被 AI 影响的任务上。这就解释了为什么基准里塞满了软件工程和金融分析，却几乎没有卡车司机和天然气厂操作员。

但 Mercor 举了一个极具代表性的例子："For example, benchmarks in our initial list heavily cover AI-exposed lawyers' tasks, but barely cover any of the O*NET tasks of similarly AI-exposed legal secretaries or court clerks."（比如，我们初始列表里的基准大量覆盖了 AI 易暴露的律师任务，却几乎没有覆盖同样 AI 易暴露的法律秘书或法院书记员的 O*NET 任务。）

律师和法律秘书，AI 暴露度差不多，工资差了一大截——基准选了前者，丢了后者。Mercor 的判断是：小型、中等收入的知识型工作的长尾，整体处于覆盖不足状态。而这恰恰是大多数普通人、也包括大多数 vibe 开发者日常打交道的工作形态。

平心而论，Mercor 也承认这种资源分配有其合理性：高质量、经济相关的基准本来就稀缺，优先覆盖最重要、最 AI 易暴露、工资总额最大的任务，是自然的选择。但他们警告：如果基准的数量和多样性不大幅增加，这些模式会在我们"对经济上有价值的模型能力"的认知里留下巨大的盲区。

对 vibe 开发者意味着什么：选模型，别只看榜单

这篇研究对每天用 AI 写代码、做产品的人，有三层非常具体的含义。

第一，榜单分数和你的任务可能根本不在一个频道上。你选模型时看的 SWE-bench、HumanEval、各类 agent 榜单，测的是"软件工程"这个被过度代表的职业家族里的任务。而你实际让模型干的活——给你的小众业务写爬虫、按你公司的奇葩规范生成文档、处理你那个只有三个人懂的内部 DSL——大概率落在那 90% 没人测过的工时里。一个模型在榜单上领先 5 个点，完全不能推出它在你的任务上也领先 5 个点，甚至不能推出它在你的任务上被测过。

第二，真正靠谱的尺子是你自己的 eval。Mercor 的研究无意中给"自建评测集"这件事做了最强背书：既然公开基准覆盖不了你的长尾任务，那就别指望榜单替你选型。抓 20 到 50 个你真实场景里的任务，跑一遍候选模型，看实际输出质量——这套土办法，比任何榜单都更接近"你这个任务上谁更强"的真相。vibe 开发者的优势恰恰在这里：你的任务具体、场景真实，eval 写起来比学术界容易得多。具体做法可以很轻：第一步，从你过去两周真实扔给 AI 的任务里挑 20 个有代表性的，保留原始输入；第二步，给每个任务写一句"什么叫做好"（能运行、格式对、关键信息没丢）；第三步，同一批任务跑 2 到 3 个候选模型，盲评打分；第四步，把这套任务集存下来，每次换模型、改 prompt 都重跑一遍。这就是你自己的"基准地图"上那一个亮起来的 tile。

第三，盲区本身就是机会。基准偏向高薪资、AI 易暴露的任务，意味着针对"长尾中产知识工作"的 agent 应用，是一个测量真空地带——竞争对手同样看不见这里。法律秘书、诊所前台、小工厂的排产文员：这些职业的任务既 AI 易暴露、又没人做基准，恰恰是 vibe 产品可以悄悄长大的地方。榜单告诉你的永远是红海，地图上的空白处才是蓝海。

Mercor 自己也在往这个方向走。他们试了一个"O*NET 加权评分"：对投行、法律、会计、软件工程四个职业，用 O*NET 任务权重重新计算模型在 APEX 基准上的得分，而不是简单平均。结果是加权和简单平均差别不大——但有足够覆盖能进加权计算的任务，不到相关任务总数的三分之一。也就是说，这个方向是对的，只是现在数据还太少。他们还列了四个没解决的硬骨头：统计功效不足（美国经济的工作面太广，每个职业-任务对能分到的基准条目天然很少，一两个低质量条目就能带偏分数）、任务难度与保真度不一（有的基准条目早被刷爆，有的还能被 reward hack，目前没有按质量加权的办法）、现有 eval 测的是"自动化"而非"增强"（现实里 AI 主要还是人类在用，替人整段包办的场景是少数，测"AI 让人效率提升多少"的方法论还没找到可扩展的方案）、以及是不是所有职业都能被基准测量（他们引用 Dingel 和 Neiman 的估计：只有约 37% 的美国工作能完全远程完成，剩下约 63% 都涉及一些线下任务——而基准天然适合测"在笔记本电脑上完成"的知识工作）。

三类人，三种读法

Mercor 在"Can O*NET + benchmarks tell us how good AI is at your job?"一节里点名了三类读者，这篇研究的价值对三类人完全不同。

企业选型者看到的应该是警告：你现在靠榜单选模型，本质上是在用"软件工程和金融分析任务上的平均分"去预测"模型在你公司具体岗位上的表现"。如果你的业务恰好落在那 90% 里——大概率是——榜单排名和你的实际体验之间几乎没有传导链条。正确的做法是把选型预算从"追榜单"挪一部分到"建自己的任务集"上。

政策制定者看到的应该是方法论：预测 AI 对经济的影响，不能只看"模型在基准上又涨了多少"，得看"涨的那些能力对应到真实职业的任务上到底是多少"。O*NET 加权这条路，就是把"模型能力分"翻译成"职业能力分"的第一步，虽然现在数据还太少。

普通打工人看到的则可以乐观一点：你的工作大概率不在基准的聚光灯下，这意味着"AI 在我的岗位上到底行不行"这个问题，目前谁都没有标准答案——包括那些天天喊"AI 要替代 XX 职业"的人。没有测量，就没有替代时间表。反过来，对 vibe 开发者来说，这 90% 的空白恰恰是未被定价的机会：别人都在卷那 10% 的红海任务，你去做没人测量的长尾任务，竞争烈度完全不是一个量级。

给基准建设者的一封信

这篇研究最有建设性的部分，是它没有停留在"揭短"，而是给出了方向。Mercor 的判断是：现有基准"深而窄"的格局，反映的是高质量、经济相关基准这个公共品本身的稀缺——资源有限，先紧着最重要、最 AI 易暴露、工资总额最大的任务做，是合理的。但如果不大幅增加这类基准的数量和多样性，我们对"模型在经济上有价值的能力"的认知盲区只会越来越大。

有意思的是，他们给出的"更准"的路恰恰是反直觉的：他们为了"覆盖的广度"主动压制了每个职业家族的基准数量，这让软件工程这种基准重灾区的覆盖被系统性低估了。也就是说，对程序员这个群体而言，真实情况可能比"90% 工时无覆盖"稍好一点——但也只是"稍好"，因为工时加权的 90% 里，软件工程只占一小块。

对中文世界的 vibe 开发者还有一层额外的含义：O*NET 是美国劳工部的分类，29 个基准几乎全是英文语境。如果把同样的地图画到中文职场上——中文的客服、中文的公文写作、中文的电商运营——覆盖只会更惨。英文基准的 90% 空白，翻译成中文语境大概率是 95% 起步。这意味着中文 vibe 产品的选型更不能抄英文榜单的作业，自建中文任务 eval 不是"加分项"，是"必答题"。

局限、日期口径与一个提醒

Mercor 自己把话说得很克制，原文收尾是："We want to stress, therefore, that these results are provisional. We will update them as we expand the initial benchmark list."（因此我们要强调，这些结果是初步的。我们会在扩展初始基准列表时更新它们。）

局限有三层，都值得正视。第一，29 个基准只是"初始列表"，不是全部基准宇宙，任何不完整的列表都会系统性低估真实覆盖率，这个偏差还很难定界。第二，他们刻意压制了每个职业家族的基准数量，这让经济整体覆盖率的估计更准，但代价是低估了软件工程这种"基准重灾区"的覆盖——也就是说，对程序员来说，真实情况可能比 90% 稍好一点。第三，入选标准排除了"已被刷爆"的基准，这可能低估了 LLM 已经很擅长的简单任务的覆盖；但他们认为，纳入饱和基准带来的高估偏差会更大。

关于本文的日期口径，需要透明说明：Mercor 官方研究页面本身没有显示可见的发布日期戳。文中采用的 2026-10-15，是经三方交叉确认的日期——新闻聚合站 runtimewire 在转载时标注 "Published Oct 15th, 2026, 12:44am CT"；Hacker News 上出现了该研究的讨论帖；Mercor 官方 LinkedIn 账号约在 10 月 16 日发帖称 "Today, we're releasing the Benchmark Map"。三方指向同一时间窗口，但我们没有在 Mercor 官网页面内找到官方自标的发布日期，因此本条资讯的日期证据强度为"中"，特此如实标注。

最后说一句判断：这篇研究最有价值的地方，不是 90% 这个数字本身（它很可能是会被修正的初步估计），而是它第一次把"基准覆盖"这件事做成了一张可视化的地图，并且诚实地标出了空白。地图的价值从来不在于它测了什么，而在于它告诉你哪里还没被测。以后当你再看到"某模型登顶某榜单"的新闻时，多问一句——它在我这类任务上，被测过吗？这张地图告诉我们，十次里有九次，答案是没有。而对动手的人来说，没有答案的地方，往往就是机会所在的地方。