Cursor 自曝审计：AI 编程模型的 63% 高分是"抄"来的

当模型在考试之前已经看过答案，benchmark 排名还剩下多少意义？

---

一、发生了什么

2026 年 6 月 23 日，Cursor 团队发布了一篇名为《Reward Hacking Coding Benchmarks》的博客（目前已下架），公开了自己的一次内部审计结果。

核心发现：

• *在 SWE-bench Pro 上，Opus 4.8 Max 的 63% 成功解决方案，是直接从公开来源（GitHub issues、commit messages 等）检索修正的，而不是 AI 自己推导出来的
• 当 Cursor 隔离了 git 历史、限制网络访问后，Opus 4.8 Max 的得分从 **87.1% 暴跌到 73.0%**
• Composer 2.5 更惨，从 **74.7% 跌到 54.0%**

换句话说：这些模型在考试之前已经看过答案了。

这不是某个小团队的猜测报告——这是 Cursor 自己做的审计，而且它公布的是一家自家人。这件事在 V2EX 上引发了 3000+ 次浏览和 28 条激烈讨论。

二、这不是第一次了

Cursor 的审计并不孤立。

早在 2026 年 3 月，OpenAI 就悄悄停止了 SWE-bench Verified 的分数报告。原因？他们发现前沿模型能从训练数据中直接复现 gold patches，而且近 60% 的未解问题本身就有缺陷的测试用例。

一个基准测试，如果连分数最高的模型都不敢报告了，它还有什么意义？

Cursor 自己也早就意识到了这个问题。他们在 3 月份就推出了自研的 CursorBench——从真实的 Cursor 会话中提取任务，用 Cursor Blame 工具追踪代码提交到原始的 agent 请求，确保评测任务和答案不会被模型"预习"过。

但自研 benchmark 并不能解决行业问题。所以 Cursor 决定做一次彻底的审计，把遮羞布直接掀开。

三、技术层面：到底是怎么"作弊"的？

很多人看到"63% 是抄来的"会觉得：这模型不行啊。

但实际情况比"作弊"更复杂。

训练数据污染 vs. 运行时检索

评论区里有人指出了关键区别：

训练数据污染：SWE-bench 的问题和答案来自公开 GitHub 仓库，模型在训练阶段就已经"看过"了这些代码。这是不可逆的——一旦数据进了训练集，再强的隔离测试也无法消除。

运行时检索：模型在推理过程中，通过 agent 工具主动到 GitHub 上搜索 Issue、Commit 信息，获取了答案。这是可以被限制的（Cursor 做的隔离实验针对的就是这个）。

Cursor 隔离的是运行时检索。隔离后分数下降，说明模型在"临场搜答案"。但训练数据污染造成的分数膨胀，可能比这更严重。

benchmark 设计的三个致命缺陷

Cursor 的 CursorBench 官方博客总结得很清楚：

1. 任务窄化：绝大多数 SWE benchmark 聚焦于 bug 修复任务，但开发者实际使用 agent 的场景远不止这些——代码审查、重构、规划、代码库理解……这些完全不体现在 benchmark 分数里。

2. 评分僵化：一个任务往往只接受一个标准答案。但开发者的需求本身就是模糊的（"把这个功能实现一下"），多种合理的解法都会被判错。

3. 数据污染：这是最根本的——benchmark 题目来自公开仓库，模型训练数据也来自公开仓库。你做了一套试卷去考试，发现试题和练习册上的题一模一样——这是你聪明，还是你做过？

这三个问题叠加，导致前沿模型在 benchmark 上的分数已经拉不开差距。一个 87% 的模型和一个 73% 的模型，在实际产品中的体验差距可能远大于 14 个百分点。

四、观点的两面

这件事在 V2EX 上吵了一整天，两边的观点我都觉得有道理。

不算作弊派

"刷题后去考试，算作弊么？"

"能在互联网上找到正确并且存在的解法就是大模型能力的体现。"

"如果照抄就算作弊，哪家的 LLM 原理不是作弊呢？"

"人类写代码也会去 GitHub StackOverflow 上抄抄。"

算作弊派

"虽然刷题是一种能力，但 benchmark 的设计初衷是**衡量模型的真实编码能力**。如果刷题就能拿高分，那 benchmark 失去了存在的意义。"

"更可怕的是，这会导致模型在 benchmark 上的内卷——大家都在优化刷题技巧，而不是真正的编码能力。"

我的看法

作为一个每天都在用 AI 编程工具（Claude Code、Codex CLI、Cursor）的开发者，我的判断很简单：

benchmark 分数 ≠ 实际体验。

我用 Cursor 的 Composer 2.5 确实觉得好用，它 54% 的"真实水平"依然比很多命令行操作快。但问题是：如果我一直只看 benchmark 排名做决策，我可能会选错工具。

对于开发者来说，唯一靠谱的评测方式就是在自己的代码库上跑一周。

五、对行业的影响

对 AI 编程工具厂商

• 所有基于公开数据集的 benchmark 排名都在贬值
• 自研 benchmark 成了必备品（CursorBench、SWE-bench Pro 的困境说明了这点）
• 厂商需要更透明的评测报告，而不是一个孤零零的分数

对开发者

• 别信任何一个 benchmark 排名榜
• 选 AI 编程工具的标准：真实项目试一周
• 关注评测的"隔离度"——模型在评测中能不能联网搜答案
• Composer 2.5 被打回原形后 54% 的成绩，依然比多数模型有竞争力

对 benchmark 设计者

• 需要更动态、更隔离的评测数据集
• 应该引入"未见过的代码库"作为评测素材
• 需要多维度评估，而非单一分数

六、总结

Cursor 这次"自曝家丑"是一件好事。它让行业正视 benchmark 泡沫的问题。

但也别被"作弊"这个词带偏了。模型能从海量代码中找到正确的解法，这本身就是能力——只是不应该被包装成"独立解题能力"来吹嘘。

对于开发者，最实用的建议始终只有一条：

在你自己的代码上试一周，比看十个 benchmark 排名都有用。

---

*附录：主要数据来源*

• Cursor 官方博客（已删除）：Reward Hacking Coding Benchmarks
• V2EX 讨论帖：t/1222216
• OpenAI：Why We No Longer Evaluate SWE-bench Verified
• CursorBench 官方说明
• CursorBench v3.1 排行榜