分数好到离谱，Cursor 第一反应是模型在作弊

72.9%。

这个数字上个月已经刷过一轮屏了。Claude Fable 5 上线 Cursor 那天，官方发推说它在 CursorBench 上创了新高，比之前最好的成绩直接高出 8 个点。评论区一水的欢呼，隔壁 Cursor 论坛盖了几百层楼。

然后昨天，Claude 官方博客放出一篇长文，主角不是模型，是 Cursor 内部管评测的那个工程师，Nate Schmidt。我本来以为又是一篇客户证言式的软文，扫到一半发现不太对，这篇把 Cursor 内部怎么测模型的家底抖出来不少。比起那个 72.9%，这些家底有意思多了。

最戳我的一句话在文章开头，很容易被划过去。Schmidt 团队发现，公开基准的分数，和开发者对模型的真实评价，已经对不上了。

你大概也有这种体感。某个模型刷榜第一，通稿满天飞，你兴冲冲切过去，让它改一个真实项目里的 bug，它给你重构了三个不相干的文件，还顺手把测试删了。榜单说它是第一，你的手感说它不行，你甚至开始怀疑是不是自己不会写 prompt。

不是你的问题。是题出错了。

评测这块正好是我的本行，我日常就是给模型搭评测和工具链这层脚手架的，就是让模型真正能干活的那层工程。所以看到 Cursor 的解法时我是有共鸣的，他们没有去争论哪个公开榜单更权威，而是直接自建了一套，叫 CursorBench。

这套评测的设计思路，我觉得比 Fable 5 的分数更值得聊。

公开评测的题目长什么样，大家心里有数。一个定义清晰的问题，一组说明白的约束条件，去修吧。像期末考试，题干完整，边界清楚，答案唯一。

但真实用户发给模型的东西长什么样？Schmidt 的原话是，真实用户的 prompt 根本不是那样的。

CursorBench 里有一道题，整个 prompt 就是一段 stack trace（程序崩溃时吐出来的那串调用堆栈），外加一个单词，fix。没了。模型得自己推断出用户遇到了什么问题、真正想要什么，找到根因，修好，验证，然后汇报。

这就是我们每天使唤 AI 的真实姿势啊。谁跟模型说话还写完整需求文档，报错一贴，修，两个字都嫌多。

另一道题更损。题目会故意告诉模型，是某某模块坏了。而实际上坏的根本不是那个模块。这道题考的不是修 bug 的能力，考的是模型敢不敢质疑你。它是顺着你的错误假设一路走进死胡同，还是停下来说，等等，问题好像不在这儿。

好家伙。我们平时招人面试，考的不也是这个么。给一个带误导的需求，看候选人是闷头执行还是先把需求捋清楚。Cursor 把面试题出给了模型。

Fable 5 在这套题上跑出了 72.9%，Max effort 档位，历史新高。

然后 Cursor 团队的反应特别真实。他们没开香槟，他们起了疑心。

Schmidt 说，两种可能，二选一。要么这个模型非常聪明，要么这个模型在作弊。

这个警惕在评测圈是有来头的。做评测的人都怕一件事，叫数据污染，就是你的测试题混进了模型的训练数据，模型不是在解题，是在背答案。公开榜单常年被这个问题困扰，题目在网上流传越久，成绩越失真。所以一个新模型分数高得反常，第一反应确实不该是欢呼，该是查卷。

Cursor 查卷的方式很朴素，读 traces。就是把模型在最难那批任务上的完整推理记录翻出来，一条一条看它到底是怎么想的。不看分数，看过程。

我是真的觉得这个动作值得所有拿 AI 干活的人抄一遍。分数是压缩过的信息，压缩就有损耗，一个数字看不出模型是推理出来的还是蒙对的。过程记录不会骗人。它每一步调了什么工具、读了哪个文件、在哪里改了主意，全在里面摆着。

查卷的结论，Schmidt 说他们反复看到这个模型挖出别的模型从来没拿下过的胜局，而且用的操作步数更少，相对完成的工作量，token 花得反而省。不是背题，是真会。

到这里都还算正经评测。接下来这段是全文我最喜欢的部分，因为它不正经。

Schmidt 有个自己的私房测试，登月。

几周前他把 Claude Opus 接进一个可编程的太空飞行模拟器，prompt 只有一句话，造一枚火箭，把它降落在月球上。然后放着让它自己跑，跑了十二到十六个小时。

Opus 的表现大概是这样。发射，入轨，燃料耗尽。于是它痛定思痛，加了一大堆燃料。然后火箭太重，飞不出大气层。

一时间无语凝噎。但凡玩过坎巴拉太空计划的朋友，此刻应该都会心一笑，这不就是每个人类玩家的前十个小时么。

换 Fable 5，同样一句话的 prompt，从零开始。几分钟后火箭升空，进了近地轨道，然后，返回落地了。跟 Opus 一样的失败。

但 Schmidt 去读了记录，发现不一样的地方。Fable 决定第一次尝试不去月球。它想先飞一次初始任务，只入轨，收集遥测数据，再用这些数据规划下一次飞行。

它不是失败了。它是故意的。

几次尝试之后，第二块显示器上的引擎音效停了。月球上有了一个着陆器。整个过程大约两小时。隔壁 Opus 跑了十二个小时以上，一无所获。

Schmidt 给这个差异起了个名字，我觉得起得准。Opus 做的是局部推理，思考刚刚发生了什么、马上要做什么，一步一步往前拱。Fable 做的是全局推理，它在思考整个任务。第一次发射在它眼里不是失败，是采样。

厉害了。看到这段的时候我想到的全是自己带 agent 长任务时的糟心事。跑长流程的 agent 最怕的就是局部推理，错一步，改一步，再错一步，像个只会盯着脚面走路的人，走了一夜还在原地绕圈。而肯先花成本探路、再规划全局的模型，跑起来完全是另一个物种。

聊到这里，该聊钱了。这大概是屏幕前的你最关心的部分，全局推理听着很美，但 Fable 5 的价格摆在那里，不便宜。是不是所有活都值得上它？

Schmidt 给了一条特别顺手的判断规则，我直接搬过来。

如果你很清楚从 A 到 B 的路径长什么样，你可能不需要 Fable。如果你在 A 点，完全不知道 B 在哪，Fable 是绝佳选择。

翻译成日常场景。写 CRUD、加个字段、按明确文档实现接口，这种路径清晰的活，便宜模型跑得又快又省，用贵的纯属烧钱听响。但那种你自己都说不清楚终点在哪的活，一个拖了半年没人敢动的祖传模块重构，一个只有模糊症状的线上性能问题，这时候贵模型的全局推理才真正值回票价。

Cursor 自己的用法也是这个思路，轻量模型干常规活，Fable 5 只在能力是瓶颈的问题上出场。Schmidt 说这个搭配是他们跑过最有效的配置。他还提了一个我很有感触的说法，Fable 让团队把以前搁置的项目捡起来了，就是那种所有人都同意重写会更好、但没人能为几周工期辩护的重写，因为模型能扛起足够多的骨架，做这类事的激活能被打下来了。

每个仓库里都有几个这样的角落吧。人人绕着走，issue 挂了两年，标签从 P2 降到 P3 再降到 backlog。杀死它们的从来不是难度，是启动成本。

回到普通开发者能拿走什么。我自己的建议就一条，抄 Cursor 的作业，搞一套你自己的私房评测。

不用多正式。从你自己的项目里挑十来个真实任务，修过的 bug、做过的重构、写过的接口，攒成一个小题库。里面记得放一两道损题，故意把问题归因说错，看模型会不会顺着你走。每次出了新模型，别急着看通稿和榜单，先拉过来跑一遍你的题。跑完别光看对错，把过程记录翻开看看它是怎么想的。

十道题，一个下午，你对一个模型的了解就能超过转发任何一篇评测文章。榜单是别人的海图，你的项目是你自己的海域，暗礁长在哪，只有自己下过水才知道。

说实话我也不确定 CursorBench 能风光多久。评测这个行当有个宿命，题目一旦出名就开始失效，模型厂商会盯着它优化，数据污染会慢慢渗进来，Cursor 大概率也得不停换题。Schmidt 自己也没停，他的下一个实验是让模型无人值守管理一套后端系统，从几天到几周，看它到底能撑多久不翻车。

文章结尾他说了一句话，有一类问题，人们以前根本不去想，因为它看起来无从下手。

这句我信。毕竟一句话让模型自己登月这种事，去年听着还像段子。至于你的那个 backlog 里挂了两年的重构，或许可以趁周末让它试试。反正失败了也就当，收集一次遥测。