当你衡量一个模型写代码的能力时，你到底在衡量什么？
CursorBench 有价值，但它测的是模型在 Cursor 脚手架里的产出，不是纯模型能力。 同一个模型换一套 harness，结果能差出几十个百分点。 真正决定 AI 编程效果的，往往是脚手架设计和人怎么用，而不是底座排名。
CursorBench 的出现把这个问题推到了前台。2026 年 3 月 11 日，Cursor 发布了一篇名为 How we compare model quality in Cursor 的博客，正式公开了他们的内部评估体系 CursorBench。这不是一个学术 benchmark，也不是一个公开 leaderboard，而是 Cursor 用来迭代自家产品的质量控制工具，被放到了产品营销的聚光灯下。
围绕它的争论，实质上是 2026 年 LLM 评估困境的一个缩影。
CursorBench 的数据来源是 Cursor Blame，一个追溯已提交代码到对应 agent 请求的工具。Cursor 的工程师在日常工作中向 agent 提问、生成代码、提交 PR，这些 query-solution pair 被采集和清洗后形成评测集。任务描述故意保持简短模糊，模拟真实开发者对 agent 说话的方式。评分使用 agentic grader，允许多种正确答案。评测集每两到三个月刷新一次。
Cursor 研究员 Sasha Rush 在 Hacker News 上的描述很简洁：我们让 Cursor 的工程师记录他们真实问模型的问题，然后记录他们提交的 PR 作为答案。清洗之后就是 benchmark。
这个方法论有几个值得注意的设计选择。第一，任务来自内部代码库而非公开仓库，降低训练数据污染风险。第二，评估不只看正确性，还看代码是否遵循了现有代码库的抽象和工程实践。第三，从 CursorBench v1 到 v3，任务的平均代码行数和文件数大约翻了一倍，开始包含 monorepo 操作、生产日志分析等更复杂的场景。
上图来自 Cursor 官方博客，直观展示了它想强调的两点：任务描述更短，但实际改动规模更大。也正因为这样，CursorBench 的支持者会说它更接近真实开发者与 agent 的交互方式。
从 Cursor 公开的对齐图表中可以读出一些具体数据。在 CursorBench 维度上（分数越高越好），GPT-5.4(high) 得分约 63.9，Opus 4.6(high) 约 58.2，GPT-5.2(high) 约 56.5，Gemini 3.1 约 50.7，Sonnet 4.5 约 51.2，GLM-5 约 49.3，Composer 1.5 约 48.0，Opus 4.5(high) 约 46.7，Haiku 4.5 约 55.3。在在线评估维度上（分数越低越好），GPT-5.4(high) 约 40.4，Opus 4.6(high) 约 43.1，Haiku 4.5 约 29.4，Sonnet 4.5 约 37.9。Cursor 用这张图论证 CursorBench 排名与在线用户体验指标更一致。
这张图就是之前追溯到来源的那张官方图。它是 Cursor 整篇文章里最重要的证据，因为它试图把“离线 benchmark 分数”直接和“线上开发者体验”连起来。
社区反应两极分化。用 Cursor 产品的开发者对 Composer 的速度印象深刻，4 倍于同级别模型的推理速度，这种体感不需要 benchmark 来证明。Reddit 上的早期测试者称赞并行 agent 和集成浏览器改善了工作流。
批评集中在三个逐层加重的层面。
第一层是透明度。HN 用户直接质问：这是发布文章中最核心的部分，但我完全看不懂它在说什么。有没有任何地方能找到 Cursor Bench 到底在测什么、怎么测？WinBuzzer 的报道更直接：他们只在自己的内部 benchmark 上发布结果，还把测试模型的分数做了聚合，掩盖了具体表现。
第二层是自证预言。Inkeep 的分析指出，缺少第三方验证，很难判断 Composer 的分数优势反映的是泛化能力还是高度定制的评测环境。Composio 的测评文章：所有这些声称都来自 Cursor 自己的 benchmark，信不信由你。
第三层是模型分组遮蔽真实差距。Cursor 把模型分成 Best Open、Fast Frontier、Frontier、Best Frontier 几个类别，只展示类别内最佳。这让外界无法判断 Composer 到底比某个具体模型好多少或差多少。
把视野拉开，你会发现不同 benchmark 之间的排名矛盾是系统性的，远不止 CursorBench 一家。
SWE-bench Verified 是被讨论最多的例子。OpenAI 在 2025 年停止报告 Verified 分数，因为发现 frontier 模型能从记忆中复现 gold patch，约 60% 的未解决问题存在测试缺陷。同一个 Opus 4.5 在 Verified 上得 80.9%，在 SWE-bench Pro 上只有 45.9%。同一个模型，换一个没有污染的测试集，分数直接砍半。
更有趣的是跨 benchmark 的排名倒置。Opus 4.5 在 SWE-bench 上排名第一，但在 Aider Polyglot 上被 GPT-5 反超。在 LiveBench 上甚至被 Haiku 4.5 接近。Failing Fast 的分析直接写道：Opus 4.5 在这里的表现令人惊讶地低，尽管它在 SWE-bench 上排名第一，不同的 benchmark 偏爱不同的能力。
这张图也说明了 CursorBench 的核心主张：公开 benchmark 已经开始饱和，无法有效拉开模型差距，而 CursorBench 还能区分出开发者实际能感受到的优劣。问题不在于这个主张毫无道理，而在于这个结论目前仍然主要建立在 Cursor 自己的体系里。
还有一个比排名矛盾更根本的发现。morphllm 的测试表明 Augment、Cursor、Claude Code 三个工具都使用 Opus 4.5 作为底层模型，但在 SWE-bench 上差了 17 个问题（731 总题目中）。同一个模型，不同的 agent 脚手架，差距可以大到这种程度。
这个发现在 2026 年初被更严格的研究反复印证。arXiv 论文 “Scalable Agent Scaffolding for Real-World Codebases” 的实验结果令人深思：Claude 4.5 Sonnet 搭配 CCA 脚手架在 SWE-Bench Pro 上得分 52.7%，而 Claude 4.5 Opus 搭配 Anthropic 自家脚手架得分 52.0%。一个更便宜、更小的模型，配上更好的脚手架，超过了更强大的模型。
HAL benchmark 的数据更夸张。Princeton 研究者 Sayash Kapoor 的实测显示，同一个 Opus 4.5 从 CORE-Agent 脚手架切换到 Claude Code，正确率从 42% 跳到 78%，36 个百分点的差距。HAL 团队因此开始”转向更好的脚手架”研究，因为他们发现”模型和脚手架之间松耦合”的基本假设正在崩塌。
这意味着我们面对的不是”模型 A 比模型 B 强”这样简单的问题。模型的表现高度依赖于它被嵌入的系统：prompt 工程、工具调用协议、上下文管理、错误恢复策略、搜索和检索管线。这些”脚手架”对最终表现的影响可以等于甚至超过模型本身的推理能力。选模型只是选了一部分能力，另一部分来自你围绕模型构建的系统。
这个结论有一个重要的推论。如果脚手架的质量可以让一个小模型超越大模型，那么”可靠性”就不是模型的固有属性，而是系统工程的产出。你不能把”模型不够可靠”当作模型的问题来看待，而应该当作你的系统设计问题来解决。重试策略、输出验证、fallback 机制、上下文窗口管理，这些工程决策的质量决定了系统的可靠性上限，与模型选型关系不大。
CursorBench 在这个层面上倒是诚实的：它从来不假装自己在测”纯模型能力”。它测的是”模型在 Cursor 环境下的表现”，包括了 Cursor 的 agent 架构贡献。问题只是它没有把这一点说得足够清楚。
所有 benchmark 讨论中最尖锐的反证来自 METR 在 2025 年发布的实地研究。他们招募了 16 个有经验的开源开发者，在大型开源仓库（22k+ stars, 1M+ 行代码）中修复 136 个真实 issue，以 150 美元/小时的报酬支付，全程录屏 146 小时。使用 Cursor Pro + Claude 3.5/3.7 的开发者比不用 AI 的人慢了 19%。
更反直觉的是感知与现实的脱节。开发者在实验前预期 AI 让他们快 24%，实验后觉得自己快了 20%。实际上他们慢了 19%。这个感知-现实之间将近 40 个百分点的差距，是整个 benchmark 生态最需要正视的数据。
这些开发者在编码环节确实花了更少的时间。但他们在 prompting、等待 AI 响应、审查 AI 输出、IDE 操作等环节花了更多时间，最终把编码节省的时间全部抵消还多。44% 的开发者之前从未用过 Cursor，大多数人使用经验不到 50 小时。
2026 年 2 月，METR 发布了实验的重要更新。他们扩大了第二轮实验规模：57 名开发者，800 多个任务。新的结果明显不同：AI 辅助组的速度差异收窄到 -4%（置信区间 -15% 到 +9%），统计上不再显著。同时他们发现初始实验存在 30-50% 的选择偏差，被试者中对 AI 持怀疑态度或缺乏经验的人可能被过度代表。
但更值得关注的是一个异常值。在初始实验中，唯一一个使用 Cursor 超过 50 小时的开发者 Quentin Anthony 快了 38%。他是一个训练 AI 模型的博士生和研究者，对工具的能力边界有清晰认知。他的原话是：LLMs are a tool, and we need to start learning its pitfalls。这不是”AI 让每个人都更快”的故事，而是”理解工具的人用工具才有效”的故事。
把 METR 的两轮数据放在一起看，结论并不是”AI 没用”或”AI 有用”，而是 AI 辅助编程的效果高度依赖于使用者对工具的理解深度。50 小时使用经验可能是一个分水岭。在此之前，开发者在学习如何与工具交互，交互成本吃掉了编码收益。在此之后，你开始知道什么任务该交给 AI、什么时候应该自己写，工具才真正变成杠杆。
这跟通常对”智能”的理解形成了有趣的张力。一个 frontier 模型在 benchmark 上的原始能力当然重要，但在实际工作中，使用者与工具之间的默契可能比模型的原始性能更重要。Quentin Anthony 用的不是最强的模型，但他知道什么时候用、怎么用、什么时候不用。
METR 的发现并非孤立数据。DX 在 2026 年初对 121,000 名开发者的调查显示，92.6% 的开发者每月使用 AI 编程工具。这个数字看起来令人振奋，但六项独立研究的结论却惊人一致：系统层面的生产力提升大约只有 10%，远低于行业预期。
这个”39 个百分点的感知差距”（开发者觉得自己快了约 50%，实际快了约 10%）是目前 AI 编程领域被复现次数最多的发现。它不是某一个实验的偶然结果，而是跨多个独立研究、多种方法论的一致信号。
93% 的采用率和约 10% 的实际提升之间的张力，提示了一个不太舒服的可能性：大多数开发者在使用 AI 工具时，并没有找到让工具真正发挥杠杆作用的方式。他们在用 AI 写代码，但可能用的方式抵消了 AI 带来的效率。过度依赖 AI 处理自己本来就擅长的任务，或者在不适合 AI 的任务上浪费时间 prompt 和审查。
回到 METR 的 Quentin Anthony：他的 38% 加速和群体的约 10% 提升之间的差距，恰好说明了”会用”和”在用”之间的距离。这个差距不是靠更强的模型能弥合的，它需要使用者改变自己与工具协作的方式。
CursorBench 的出现不是孤立事件，而是整个 benchmark 生态对 Goodhart’s Law 的集体反应。当一个度量变成目标，它就不再是好的度量。
学术论文 Line Goes Up? (arXiv 2502.14318) 系统论证了这个现象在 LLM 评估中的表现。LiveCodeBench 通过持续从竞赛平台采集新题目，证明了大量模型在旧 benchmark 上的高分来自 overfitting 而非真实能力。LMArena 也被发现存在模型厂商针对性优化的问题。2025 年的行业回顾（goodeyelabs）观察到：领先的 AI 组织做了一个根本性转变，他们停止依赖公开 benchmark，开始构建定制的内部评估基础设施。
Cursor 做的事情本质上是这个趋势的产物。OpenAI 有自己的 evals，Anthropic 有内部测试，Google 有 internal benchmarks。区别在于，Cursor 把内部工具当成了产品发布的核心论据。一个工程工具和一个营销素材之间的张力，才是争论的真正焦点。
把 CursorBench 放在更大的画面里，几个层次的结论逐渐清晰。
作为工程实践，CursorBench 的方法论值得肯定。用真实用户数据构建评估、关注代码质量而非只看正确性、定期刷新防止污染、结合线上 A/B 测试。如果你在做 AI coding tool 的产品迭代，这套方法可以直接借鉴。
作为模型评估依据，CursorBench 的可信度受限。你无法独立验证它的任何声称。它测的是模型与 Cursor 特定 agent 架构的兼容度，这是有价值的信息，但和模型的通用编码能力是两回事。
作为产品选择的参考，最实用的判断框架是看多个 benchmark 的共识。如果一个模型在 SWE-bench Pro、Aider Polyglot、LiveSWEBench、Terminal-Bench 上排名一致，那个信号相对可靠。如果只有某一个 benchmark 显示优势，需要追问优势来自模型本身还是来自评测环境的适配。
但这篇调研中反复出现的数据指向一个更根本的问题：我们可能过度关注了模型选择，而忽略了真正决定产出的因素。CCA 脚手架让 Sonnet 超过了 Opus。Claude Code 让同一个 Opus 的正确率翻倍。Quentin Anthony 的 50 小时使用经验让他的效率是新手的数倍。这些证据都在说同一件事：在 AI 辅助编程的实际产出中，“系统如何组装”和”人如何使用”的权重，可能远大于”底层模型有多强”。
Benchmark 测的永远是模型在受控环境下的潜力，而非嵌入人类工作流后的实际产出。METR 的数据提醒我们，这两者之间的 gap 不仅存在，而且可能是反向的。衡量 AI coding 效率的终极标准，既不是某个 benchmark 的分数，也不是模型参数量，而是使用者能否为自己的工作场景构建一个靠谱的系统，并投入足够的时间去理解它的边界。
https://ptht05hbb1ssoooe.public.blob.vercel-storage.com/assets/blog/cursorbench-tasks-r6.png、https://ptht05hbb1ssoooe.public.blob.vercel-storage.com/assets/blog/cursorbench-separation-r6.png、https://ptht05hbb1ssoooe.public.blob.vercel-storage.com/assets/blog/cursorbench-alignment-r5.png