一水 發自 凹非寺
量子位 | 公眾號 QbitAI
程式設計智能體時代，頂流 Cursor 舉旗發布新的評測基準——
CursorBench，專門評估 Cursor 中不同模型誰更有「智能體」的能力（即高效執行複雜任務）。
結果你猜怎麼著？曾在 SWE-Bench 上赫赫有名的 Claude Haiku 4.5 / Sonnet 4.5 全部陣亡了。
- Claude Haiku 4.5 的分數從 73.3 → 29.4；
- Claude Sonnet 4.5 的分數從 77.2 → 37.9。
而這，也恰好體現了 CursorBench 和其他程式設計基準之間的區別：
SWE-Bench 衡量的是程式能否解決問題，CursorBench 衡量的是程式能否高效率地解決問題。這種差距正是普通基準測試所無法彌補的——在真實的 token 限制下完成任務。
「智能體」當道，誰都知道現在評價 AI 要看重執行能力，而且還要是高效執行那種。
而 CursorBench 的出現，恰好填補了相關空白。
不過問題來了，CursorBench 具體是怎麼評的？
關於怎麼評的這個問題，Cursor 還專門撰寫了一篇部落格。
一上來，Cursor 就介紹了一個基本背景——
隨著 AI 程式設計助手越來越像「智能體」，目前很多公開的 benchmark 已經不夠用了。
問題呢主要有這三個：
一是任務類型不真實。
以大家比較熟知的 benchmark 為例，SWE-Bench 主要是修復 GitHub issue 的 bug，任務比較單一。
Terminal-Bench 雖然不再侷限於儲存庫，但更偏向各種「謎題式任務」，比如根據給定環境完成一系列挑戰，此時 AI 更像是在參加某種競賽而非進行日常開發。
所以 Cursor 就說了，「我們發現，這些任務與開發者要求智能體完成的程式設計工作並不契合」。
現實生活中更常見的是，開發者會要求 AI 修改多個檔案、分析生產環境日誌、執行實驗……總之比基準更複雜。
二是評分機制不合理。
很多公開基準通常都假設——一個問題只有一個正確答案。
但現實是，一個需求可能有多種實現方式，不同方案的程式碼風格、架構選擇都有可能不同。
這就往往會導致兩種情況：要麼直接給正確的方案打叉（出現誤判）、要麼直接為了可評估性而強行消除模糊性（人為施加限制）。
無論是哪一種，基準都無法反映真實情況。
三是公認的資料汙染問題。
這一點就不必多說了，一旦基準出現夠久，後來的模型很可能就會直接抓取這些基準資料進行訓練。
所以，在這種近乎「洩題」的情況下進行評分，其結果到底有多大價值就可想而知了。
而面對這些問題，Cursor 拿出了一套「線上 + 線下混合評」的全新方案。
線下就是我們說的 CursorBench，流程也相對簡單——
讓不同模型都去完成同一批標準任務，然後系統從正確性、程式碼品質、效率、互動行為等維度進行打分，最終每個模型都能拿到一個離線 benchmark 分數。
採用這種標準化流程的好處顯而易見，包括可以相對而言把模型拉到同一起跑點進行比較、可以重複測試、成本也相對可控。
不過有人可能就說了，這和其他基準好像沒差啊？
別急，CursorBench 的「制勝法寶」在這裡——選的任務不一樣。
其不一樣體現在三個維度：
一是任務真實。
以前的基準更像是「刻意找題」，找 GitHub issue、找各種謎題；而 CursorBench 的題都來自自家 Cursor 平台。
Cursor 有一個工具叫 Cursor Blame，它可以追蹤某一段程式碼是由哪個 AI 請求生成的。
於是就能拿到這樣一對對真實資料——開發者請求 + 某個模型最終提交的程式碼。
而這些，就構成了 CursorBench 絕佳的「出題範本」。而且 Cursor 補充道：
許多任務來自我們的內部程式庫和受控來源，從而降低了模型在訓練階段見過這些任務的風險。我們每隔幾個月就會更新一次這套基準，以追蹤開發者使用智能體方式的變化。
二是任務規模大。
如今用 Cursor 的人實在太多了，所以 CursorBench 的任務規模明顯更大。
比如在正確性評估中，無論從程式碼行數還是平均檔案數來看，其問題規模從初始版本到目前的 CursorBench-3 大致翻了一倍。Cursor 表示：
雖然程式碼行數並不是衡量難度的完美指標，但該指標上的增長反映了我們將更具挑戰性的任務納入 CursorBench 的方式，例如處理 monorepo 的多工作區環境、排查生產環境日誌，以及執行長時間執行的實驗。
三是任務描述刻意保持「模糊」。
這點也比較好理解。
很多公開基準裡的任務描述通常非常詳細，但現實中大家和 AI 說話時往往模稜兩可。
所以太精準反而與真實相悖。
至此，基於以上特殊設計，CursorBench 成了程式設計智能體時代真正以「真實開發場景」為原點設計的基準測試。
當然這還沒完，光做題怎麼夠呢？很多 AI 線下分數高，但用戶一上手就發現很拉垮。
對此，Cursor 還搞了一套線上評測——直接看真實用戶使用效果。
他們會使用 A/B Test 這種方式，觀察一部分用戶用模型 A、另一部分用戶用模型 B 之後的對比效果。
具體主要看開發者是否接受 AI 生成的程式碼、是否繼續追問、是否復原修改、任務是否真正完成等可追蹤的產品指標。
如此一來，線上和線下就可以形成完美互補，甚至形成良性循環——
線下 CursorBench 先快速篩選模型能力，然後線上驗證模型是否真的更好，發現偏差後再去調整 benchmark 或模型。
飛輪這不就起來了。
所以，結果呢？
那麼模型們在新基準 CursorBench 上的表現如何呢？
來看最終 performance（越靠近右上角越好，代表「以最低成本實現最高效能」）：
見此圖表，網友們一時討論連連：
嘖，沒想到 Claude Sonnet 4.5 的「性價比」有點低啊。
這個 Composer 模型（Cursor 自研編碼模型）又是哪裡冒出來的。
Anyway，從 Cursor 公布的結果來看，一個很明顯的結論是——
CursorBench 在前沿模型之間的區辨度明顯更高。
這個其實是自然而然的。基準一飽和，模型們往往拉開不了差距，大家分都高、都好。
但一遇到新的、難的，實力差距便自然顯露了。
尤其在 CursorBench 這種任務規模更大、環境更複雜的基準上，差距無疑將被進一步放大。
只需對比模型在 SWE-Bench 和 CursorBench 上的得分就能看出來了（左邊全擠在一起、右邊呈階梯式）：
以及 Cursor 還強調了一點——
CursorBench 的排名，與真實用戶體驗更加一致。
透過前面提到的線上實驗，他們發現 CursorBench 的模型排名，和這些線上指標變化基本是同方向的。
接下來，Cursor 還將著手開發下一代評測套件：
雖然 CursorBench-3 的任務比公開基準上的任務持續時間更長，但它們仍然可以在一次會話內完成。我們預計在未來一年裡，絕大多數開發工作將轉向由在各自電腦上獨立執行的長時間執行智能體來完成，因此我們也正規劃對 CursorBench 作出相應調整。
嗯，瞄準的還是智能體，只不過是執行時間更長的智能體。
參考連結：
https://x.com/cursor_ai/status/2032148125448610145