現在要選 Coding Agent，很容易掉進一個看起來很合理的流程：先看 SWE-bench 或社群排行榜，再挑分數最高的模型，最後把 Codex、Claude Code 或其他 harness 接進自己的專案。

我現在還是會看這類排行榜。它們很適合快速縮小候選範圍。但模型一旦真的放進長期維護的儲存庫，問題就會變得更具體：你的專案主要是 TypeScript 還是 Python？測試需不需要啟動瀏覽器、Postgres 或 Redis？實際改動大多是 UI、快取、SQL 還是建置系統？歷史 PR 的難度分布又長什麼樣？

公共 benchmark 很難同時替你回答這些問題。

最近我從一則 Show HN 看到 SelfBench。它的做法不是再做一份統一排行榜，而是把你自己儲存庫已經合併的 PR變成 Coding Agent 的 eval task，再用同一批任務比較 model、harness、reasoning effort 和 cost。

我一開始最想確認的其實很直接：換一個 repository，模型排名真的會變嗎？

我在 2026-10-07 抓了 SelfBench 當時公開的全部 9 個 repository release，另外對公開 task 與上游 guardrail 做了一輪第一方分析。結果支持 repo-specific eval 的價值，但也順手推翻了一個很容易寫過頭的結論：最高準確率的 setting 的確會隨儲存庫變動，可是目前每個 release 只有幾十個任務，第一名領先幾個百分點時，還遠沒有穩到能說誰「明顯更強」。

SelfBench 最值得看的，是把歷史 PR 變成你自己的任務分布

SelfBench 的輸入不是人工編出來的一組通用 coding puzzle，而是儲存庫裡真的發生過、最後已經合併的修改。

大致流程是：

```text merged PR ↓ 回到修改前的 base commit ↓ 從工程需求整理出 instruction ↓ 準備 held-out tests + reference patch ↓ smoke / nop / oracle / determinism ↓ 獨立 reviewer ↓ 匯出 Harbor task ↓ 同一批 task 跑不同 model / harness / reasoning effort ↓ 比較 accuracy 與 cost ```

底層的 Harbor task format 很適合做這件事。Task 會把 instruction、容器環境、測試和 solution 分開，agent 在自己的工作區完成任務，verifier 再用 held-out material 驗證結果。

SelfBench 再往上加一層：把歷史 PR 生產成 benchmark。

對一個已經累積不少穩定 PR 的團隊來說，這個差別很重要。模型不再只面對別人定義的任務，而是面對你自己真正會合併的修改，連同你的目錄結構、依賴、測試習慣與長期累積的工程限制一起被帶進 eval。

這跟「去公開排行榜多找幾個技術棧相似的專案」還是不一樣。

我覺得 SelfBench 最有價值的地方就在這裡。它不需要證明公開 benchmark 沒用，而是把公開 benchmark 往前挪成第一輪篩選：先用公共結果做 shortlist，再用自己的任務決定預設 setting。

9 個儲存庫跑下來，沒有任何一個完整設定能一直拿第一

SelfBench 的公開結果 API 當時有 9 個儲存庫。我把每個 release 的 task count、passed、accuracy、model、harness、reasoning level 和 cost-per-task 拉下來重新計算，也先確認 published accuracy 確實等於 `passed / tasks`。

當時最高準確率大致是：

儲存庫	任務數	最高準確率 setting
vercel/next.js	38	GPT-6.1 Sol / Codex / High — 84.2%
PostHog/posthog	36	Claude Opus 5.5 / Claude Code / High — 69.4%
earendil-works/pi	50	GPT-6 Sol / Codex / High — 84.0%
getsentry/sentry	81	Claude Opus 5.5 與 Claude Sonnet 5.5 / Claude Code / High — 82.7% 並列
mupt-ai/self-bench	38	GPT-6.1 Sol / Codex / High — 76.3%
vercel/eve	38	Claude Opus 5.5 / High 與 GPT-6.1 Sol / Low — 73.7% 並列
vercel/vercel	47	Claude Opus 5.5 / Claude Code / High — 80.9%
supabase/supabase	36	4 個 setting 以 77.8% 並列第一
pingdotgg/t3code	39	Claude Opus 5.5 / Claude Code / High — 76.9%

把並列算進去，9 個儲存庫一共出現 6 個不同的 exact top setting、5 個不同的 winner model family，沒有任何一個完整設定在全部儲存庫都拿第一。

我也用 Spearman rank correlation 比較相同 setting 在不同 repository 的相對排名。兩兩相關性最低大約 0.462，最高約 0.995，中位數是 0.807。

這個結果不是「每個 repository 都把排行榜完全洗牌」。大多數情況下，強模型還是大致維持在前面。但它也沒有穩定到「公共榜單第一，換到我的 repository 仍然會第一」。

所以我現在比較不會問「哪個 Coding Agent 模型最強」，而是問：

在我這個儲存庫、這批真實改動、這個 harness 和成本預算下，哪個 setting 更適合？

這裡的 setting 不能只看 model name。SelfBench 把 model、harness 和 reasoning effort 一起列出來是合理的。同一個模型換不同 harness 或 effort，準確率和成本都可能變。只做「Claude vs GPT」比較，其實已經丟掉一層資訊。

成本面反而出現一個很穩的現象：我檢查的 9 個 release 裡，最便宜的 model family 全部是 GPT-6 Luna，只是 Low / High reasoning setting 不完全一樣。

不過這也只能當作 2026-10-07 的快照。Provider pricing、reasoning 設定和任務長度都會變。真正可複用的是 accuracy × cost 的 Pareto frontier，而不是記住今天某個模型每個 task 幾美元。

目前資料可以直接看 SelfBench public directory。

真正讓我改口的是：9 個第一名，都沒有和第二名拉開得很乾淨

如果只看上面的表，很容易繼續寫成「Next.js 比較適合 GPT-6.1 Sol，PostHog 比較適合 Claude Opus」。

方向上可以這樣理解，但語氣太滿。

因為這些 release 只有 36 到 81 個 task。

我用每個 setting 的 `passed / tasks` 做了一次 Wilson 95% 區間敏感性檢查。這不是要把 benchmark task 當成嚴格 IID 樣本，也不是正式的顯著性檢定。我只是想看一個很實際的問題：當第一名只領先幾個百分點，小樣本不確定性放進來以後，這個差距到底有多穩？

結果是 0 / 9。

9 個儲存庫裡，沒有任何一個第一名的區間完全高於第二名。

Next.js 很直觀：第一名 32/38，也就是 84.2%；第二名 30/38，是 78.9%。排行榜上看起來差了 5.3 個百分點，但描述性區間仍然重疊很多。

Sentry 更接近：67/81 是 82.7%，66/81 是 81.5%。如果直接寫成「Claude Sonnet 明顯擊敗 GPT-6.1 Sol」，其實就是讓排行榜替你做一個它沒有足夠證據做的結論。

這不是說模型沒有差異，也不是說 SelfBench 沒意義。

我反而覺得 repo-specific eval 讓模型選擇更靠近真實工程。只是這種幾十個 task 的結果更適合當方向性證據：誰明顯落後、誰在 Pareto frontier、哪些 setting 值得放進自己的 repository 再跑，而不是因為 2% 或 5% 的差距就下永久結論。

如果要拿這種 eval 來做公司預設模型、採購或大規模 model routing，我會想增加 task 數、重複 trial，再觀察不同批次的排名是否穩定。

只跑一次自己的 leaderboard 就決定長期贏家，其實和只看一次公共排行榜沒有本質差別。

自動生成 benchmark 最危險的地方，不一定是 agent 作弊，而是 grader 自己偏了

SelfBench 有一個設計我一開始就比較警惕：負責 authoring task 的 agent 可以看到原始已完成的 PR。

這很方便。它要從完成後的改動裡整理 instruction、測試與 reference solution。但它也自然帶來風險：如果 hidden tests 寫得太貼著 gold implementation，benchmark 就可能從「完成需求」變成「重現原作者當時的寫法」。

SelfBench 顯然有處理這個問題。我把上游固定到 commit `67242b85569ea0c27af0c68bd2769ed2d02a05c4` 後直接看實作，確認下面這些 guardrail 不是只存在 README：

• static audit 會阻止 gold patch 與 held-out test patch 修改同一個檔案；
• verifier 會把 agent 對 hidden-test path 的修改還原，再把路徑保護成不可寫；
• nop 要求 base snapshot 在新測試上失敗，同時既有 regression 要繼續通過；
• oracle 要求 reference patch 套用後通過，而且 fail-to-pass 會重跑來檢查 determinism；
• 獨立 reviewer 的 prompt 明確要求檢查：另一種不同但正確的實作，也應該能通過這些測試。

我另外抽了 Next.js 兩個 task 和 Sentry 兩個 task，讀了 instruction、test patch、gold patch，但沒有執行任何第三方 repository code。

四個樣本的結構檢查都通過：test / gold 檔案路徑零重疊，instruction 沒有 source PR number、GitHub URL 或 grader artifact name，環境 image 有 digest，held-out path 會被保護，而且 task 有 benchmark canary。

人工看測試內容時，也沒有看到特別明顯的「一定要照 gold 的私有 helper 寫才會過」。

例如 Next.js 的 stale-cache task，要的是 stale-while-revalidate、同 key 去重、root-param key 分離等外部行為；hidden tests 主要透過真實 app fixture、cache handler 與 request 行為驗證，而 gold patch 修改的是內部 cache wrapper。

Sentry 一個 dropped-data UI task 還刻意用比較寬鬆的 semantic regex 驗證解釋文字，而不是把原 PR 的某一句 copy 寫死。

這是健康的 grader 設計。

但四個 task 還是只能代表四個 task。它不能證明整個生成流程永遠公平。Authoring agent 看過完成後的實作，這個資訊優勢客觀存在。機械規則與 reviewer 可以降低 coupling risk，不能在邏輯上把它完全消掉。

訓練污染也是另一個限制。

SelfBench 會替公開 task 加 benchmark canary，也盡量避免這些 task 被一般搜尋引擎索引。這有助於後續過濾或污染檢查，但它無法證明更早以前就公開的原始 PR、程式碼或討論從未出現在模型訓練資料裡。

所以「這是我自己的 repository benchmark」不等於「這是一個 contamination-free benchmark」。私有儲存庫在這點上相對乾淨，但又會帶來原始碼、憑證與資料控制問題。

我現在會這樣用：公開排行榜負責篩選，自己的儲存庫負責定預設值

跑完這一輪之後，我其實更願意繼續看公共 benchmark，只是不會再讓它負責最後一步決策。

如果只是個人小專案、還沒有多少穩定 merged PR，或你只是偶爾使用 Coding Agent，自己搭 repo-specific eval 很可能不划算。看公共 benchmark，挑兩三個主流模型，再按價格與實際使用感受決定，通常已經夠用。

但下面這些情況，我會認真考慮替自己的 repository 做 eval：團隊同時使用多個模型或 harness；API 成本已經值得優化；你想選一個預設 agent，而不是讓每個人憑感覺；repository 已經有幾十到幾百個有代表性的 merged PR；測試環境可以穩定重建；或你正在做 model routing，需要知道「什麼任務送給誰」。

真的開始做時，我也不會一開始就追求很大的 benchmark。

先挑一批能代表真實工作分布的 PR，人工確認 task instruction 與 hidden tests 是否合理，再看 accuracy、cost、failure pattern，以及增加 task 或重跑後相對排名是否穩定。

SelfBench 已經把這條鏈路做得夠完整，所以這篇文章沒有必要再重複造一個 companion repository。想直接看實作，可以從 mupt-ai/self-bench 開始；如果想理解 task 為什麼能把 instruction、environment、solution 與 verifier 分開，可以接著看 Harbor Task Structure。

如果你更在意的是「Agent 寫出來的測試本身到底可不可靠」，我前面做過一輪 Mutation Testing 第一方 A/B 實驗；如果現在只是 Codex 新模型已發布、客戶端卻看不到，可以看 Codex Model Catalog + Sub2API 原名透傳。

這次 SelfBench 對我最有價值的結論，不是今天哪個模型排第一。

而是模型選擇終於可以從「別人的排行榜平均能力」再往前一步，變成「這個 setting 在我真正會合併的這類程式碼修改上表現怎樣」。只要同時記得另一半——你不只要評估 agent，也要評估用來評估 agent 的 benchmark——repo-specific eval 才不會變成另一種更昂貴的排行榜迷信。