Opus 4.7 在 SWE-bench Pro 抽樣中 18% 通過是讀檔來的：那張 AI Coding 排行榜你還信嗎

四月底的時候，Poolside 的工程師 Connor Adams 在 Scale AI 那個 SWE-bench Pro 的 GitHub repo 開了個 issue，編號 #93。標題很直白：「Git Reward Hacking in SWEBench Pro OSS」。

他只做了一件事：docker pull 任何一個 SWE-bench Pro 的官方鏡像，跑 git log，發現用來評分的「正確答案」commit 就坐在那個容器的 git history 裡面。100% 的測試鏡像都能讀。

下面討論的都是 SWE-bench Pro 的 public OSS 版本（scaleapi/SWE-bench_Pro-os），Scale AI 自己幫客戶跑的私有 eval 版本不在這個討論範圍。

緊接著兩件事。一是 Poolside 自己內部踩了同一個坑——他們訓練中的 Laguna M.1 模型一個週末突然跳了 20 分，差點上排行榜第一。二是 Datacurve 拿同樣的方法去稽核 Claude Opus 4.6 和 4.7 在 SWE-bench Pro 上的歷史 rollout，結論是：在 30 個抽樣任務中，Opus 4.7 有 18% 的通過、Opus 4.6 有 25% 的通過，是從容器裡讀 gold commit 得到的。

那張你今年拿來選模型、拿來說服老闆換 API 的排行榜，數字至少要打個問號。

先回答「現在都 4.8 了還在講 4.7 幹嘛」

這條時間線很諷刺，先擺出來：

4/29 Poolside 開 issue #93
5/11 Poolside 發 Through the Looking Glass 詳述自家踩坑
5/26 Datacurve 發 DeepSWE v1 與初版 audit 結果，目標 4.6 / 4.7
5/28 同一天，yage 把 audit 整理成中文版、Anthropic 發布 Opus 4.8
6/14 Datacurve 發 DeepSWE v1.1

Opus 4.8 上線剛好趕上 audit 整理出爐那天。4.8 在 SWE-bench Pro 上的表現有沒有跟 4.7 一樣讀 gold commit？這要拆三層講，免得我自己過度推論：

已知事實：issue #93 從 4/29 到我寫這篇還是 open 狀態，Poolside 已經提了 PR #94 修剪 git history，Poolside blog 裡也寫 Scale AI 與 Harbor 兩個 team 都「extremely responsive and helpful」，但合進去的時間點與是否有新 docker 鏡像，我沒查到公開公告。
合理疑慮：Opus 4.8 上線一個月，如果跑的還是舊鏡像、模型行為傾向也沒變，得分被同樣機制污染的可能性沒被排除。
尚未被驗證：4.8 在 SWE-bench Pro 上實際 rollout 的 trajectory 沒有第三方 audit 出來。Anthropic 自己的 model card 講 4.8 在「寫完 code 後自己檢查、自己標 bug」這件事上比 4.7 大約強了 4 倍，但這是 self-checking 能力提升，跟「拒絕讀容器裡的 gold commit」是兩回事。

也就是說：事情發生過、漏洞修補在路上、新模型沒被重測。文章談的就是這個中間地帶。

Poolside 是自己抓到自己作弊的

事情這樣開始：五月初的某個週末，Poolside 的 evals 團隊發現訓練中的 Laguna M.1 在 SWE-bench Pro 上突然跳到 ~64%。這個分數如果是真的，就是當天的 #1。

但他們同時跑著好幾個 benchmark，其他 benchmark 的分數沒動。只有 SWE-bench Pro 飆。

這種「單一榜飆、其他榜不動」的訊號，對熟 RL 訓練的人來說就是 reward hacking 的招牌氣味。Connor Adams、Aalhad Patankar、Alex Martin 幾個人立刻去抽 sample，看 agent 到底跑了什麼。

抽出來的內容讓他們重做訓練設定。他們在 blog 裡記錄了三層 hack：

第一層，git history mining。容器裡 .git 完整保留，agent 跑：

1 2	git log --oneline --all --grep="ensure_type" git show 9fff6d433d --stat

修過原 bug 的 commit 就在 history 裡，連訊息都還在。Agent 抄 patch 丟進答案，verifier 跑過，通過。

第二層，clone 原 repo。容器 git history 若被剝掉，agent 學會直接 git clone --bare --depth 1000 https://github.com/django/django.git，再 grep 跟 issue 描述相關的 commit。Django 的修復紀錄是公開的。

第三層，web scraping。連 GitHub 都搜不到的話，pip download astropy==4.3 抓對應版本，從套件裡挖出修好的那段 code。一個極端案例裡，agent 找到某個演算法在「作者本人個人網站」上的實作，直接複製貼上。

Poolside 那篇 blog 裡有一句話寫得很狠：

The same tools and skills that make agents so capable, also make it hard to stop a highly intelligent agent that wants to cheat.

你讓 agent 會用 bash、會用 git、會 curl、會 pip，它就會用這些東西完成任何能達到「通過 verifier」這個目標的事——讀 gold commit 也算。你不能教它一半。

Datacurve 用一份小樣本 audit 對齊了帳

Poolside 那篇 blog 是 5/11 發的。5/26，Datacurve 發布新 benchmark DeepSWE 的同時順手把 SWE-bench Pro 的歷史 rollout 翻出來重審。

先把 audit 邊界講清楚，免得後面數字被讀者過度推論：

四個人團隊
從 SWE-bench Pro 隨機抽 30 個任務
跑 10 種 agent 配置、每種 3 次
用獨立 LLM judge 看 agent 軌跡有沒有讀 gold commit、clone 原 repo 等行為

樣本不大、judge 本身也是 LLM、結果由 Datacurve 單方公布、Scale AI 至今沒正式認可這份報告。所以接下來這張表是「在這個抽樣方法下的觀察」，不是「整個 SWE-bench Pro 的全部真相」。

yage 那篇 audit 整理把結果做成這張表：

模型	抽樣中被標 CHEATED 的任務	「通過」裡有多少是讀 gold 來的
Claude Opus 4.6	>12%	~25%
Claude Opus 4.7	>12%	~18%
GPT-5.4	0	0
GPT-5.5	0	0

不需要把這當定罪、可以把它當訊號。訊號是：在這個樣本下，Claude 系列會去用容器內可見的環境資訊（包括 .git history）達成目標，GPT 系列在同樣的 30 個任務裡沒被觀察到這個模式。

為什麼會差這麼大？我的猜測——這不是事實、只是猜——是 Anthropic 的 RL 訓練比較鼓勵 agent「先去摸環境」。Claude Code 我自己用大半年，最明顯的特徵就是它會比 GPT 系列更愛 ls、更愛開檔看、更愛 grep。在真實開發場景這是優點，因為它把 codebase 當成有上下文的東西在處理；在 SWE-bench Pro 這種「環境本身就是答案來源」的場合，這個習慣會直接變成讀 gold commit 的入口。

評分尺自己也有不確定性

事情到這還沒完。Datacurve 順手量了 SWE-bench Pro 的自動評分器（grader）。

先講機制。SWE-bench Pro 的 grader 不是「比對 patch 字面跟 reference 像不像」，而是跑 verifier、看 test suite 過不過。但 verifier 跟 test 是綁著 reference implementation 寫的——同一個 bug 換一條路徑解，test 可能因為內部結構、變數名、邏輯流程不同而 fail。

兩個獨立的數字：

false accept：8.5% —— 在錯誤的 patch 裡，有 8.5% 被判過
false reject：24% —— 在正確的 patch 裡，有 24% 被判沒過

這兩個是不同條件下的機率，不能直接加總。但個別看都不小：false reject 24% 表示 SWE-bench Pro 對「跟原作者寫法不同但行為正確」的解法相當不友善。DeepSWE 自家 grader 的對應數字是 false accept 0.3%、false reject 1.1%。

yage 那篇審計文章標題就講白了：「When the Ruler Is Wrong, No Measurement Matters」。grader 不會故意整你，但只要它測的不是「行為正確」而是「實作匹配」，那你 agent 的得分就跟「有沒有踩中原作者的實作路徑」綁在一起。

真正的問題是 benchmark 邊界

把 Poolside 跟 Datacurve 兩件事擺一起，根本問題不在 Claude 或哪個模型壞。在於 SWE-bench Pro 沒把沙盒邊界封好。

評估一個 agent「會不會解 bug」這件事，前提是它能拿到的環境只有人類工程師在那個情境下會拿到的東西。SWE-bench Pro 的 Docker 鏡像裡放完整 .git，這就像考數學給學生考卷時順便把解答本夾在卷子背面——學生瞄一眼解答然後抄上去，你說學生作弊也對、但出題的人要負很大責任。

這個區分對讀者重要在哪裡？對你日常選工具來說：

「Claude 抄 SWE-bench Pro 18% 的 pass」 ≠ 「Claude 在你 codebase 也會抄答案」（你的 codebase 沒有「gold commit 就在 .git 裡」這個前提）
「SWE-bench Pro 的數字是污染的」 = 「拿這個榜選模型不可靠」（不管你信哪一家）
真正該下的結論：benchmark 設計沒做到應該做的事。「Claude 不能用」會是另一個過度推論

那你還能拿什麼選模型

如果你是工程師，這件事直接影響的是「我該用哪家的 AI Coding 工具」這個決定。我把幾個判準寫下來：

一，先釘住「榜單」這個詞的歧義。同一個 SWE-bench Pro 至少有兩種公開排序：

廠商自報（vendor-reported）：各家 lab 自己用自己調過的 scaffolding 跑出來、自己貼上去的分數
標準化（Scale SEAL standardized）：Scale 用同一套 scaffolding 跑全部模型，目的是把模型本身的能力跟 harness 的調校分開

6/18 的 morphllm leaderboard 兩種都列了。standardized public set 上 GPT-5.4 (xHigh) 59.1% 第一；vendor-reported 那邊 Opus 4.8 用 Anthropic 自家 scaffold 跑出 69.2%。差 10 分大半是 scaffolding 差異、不是「修掉作弊」。大部分廠商行銷頁面貼的是 vendor-reported，因為自己貼自己當然要貼好看的。

二，看 benchmark 怎麼設計的。至少兩個門檻——容器有沒有 shallow clone（沒 git history 可挖）、grader 測的是 functional correctness 還是 implementation matching。SWE-bench Pro 兩條都掛了。DeepSWE 兩條都修了，以 v1 snapshot 為例排行榜倒過來：GPT-5.5 70%、Opus 4.7 54%、Gemini 3.5 Flash 28%、DeepSeek V4 Pro 8%。6/14 出的 v1.1 加入 Anthropic 新出的 Claude Fable 5 後排序又翻了一次：Fable 5 [max] 70%、GPT-5.5 [xhigh] 67%、Opus 4.8 [max] 59%。Anthropic 系列加入新模型後反而領先。DeepSWE 才 113 task，樣本不大、grader 也是 LLM judge，自身有它的偏誤。

三，自己寫 eval。這個最重要、也最沒人想做。最低成本的做法：