為什麼程式碼基準測試終於開始說實話

LiveCodeBench 和 SWE-bench Pro 已經能更準確分出真正能寫程式的模型與只會刷榜的模型。

我認為，程式碼模型的選型標準已經變了，現在再拿 HumanEval 當主要依據，是在做錯產品決策。BenchLM 2026 年 3 月的排行榜把這件事講得很直接：Claude Mythos Preview 以 100.0 的加權分數居首，Gemini 3.1 Pro 以 93.9 緊追，GPT-5.3 Codex 在 SWE-bench Pro 上衝到 77.3，成為頁面上最高的開源權重相關結果。這些差距不是裝飾性的數字，而是能不能在真實倉庫裡修 bug、接 test、過 CI 的差別。

第一個論點：真實程式工作不是玩具題

BenchLM 把 SWE-bench Pro 和 LiveCodeBench 等權重看待，這個設計是對的。SWE-bench Pro 來自真實 GitHub issue，測的是模型能不能在混亂的 repository 裡把問題修掉；LiveCodeBench 則持續出新題，降低資料污染的風險。這兩者合在一起，才接近工程團隊真正需要的能力：能不能處理多檔案、能不能理解上下文、能不能在沒看過的題型上維持推理品質。

HumanEval 已經明顯失去區分力。BenchLM 指出，前沿模型在這個基準上幾乎都超過 95%，也就是說它早就無法幫你分辨「夠用」和「真的能上線」。當一個測試大家都能過，它就不再是選型工具，只剩熟悉舊題庫的獎勵機制。若你的評估流程還把 HumanEval 放在核心位置，你其實是在優化過去的模型，而不是現在的產品。

第二個論點：排行榜開始反映品質、成本與部署的真實取捨

這份排行榜有價值的地方，在於它沒有假裝準確率是唯一指標。Claude Mythos Preview 雖然名列第一，但頁面也把更務實的選項攤開來：重視自架的團隊可以看 GPT-5.3 Codex，追求平衡的可以看 GPT-5.4，預算優先的則有像 Qwen3.6-27B 這類較便宜的開源模型。這才是正確的選型方式，因為團隊買的不是分數本身，而是能否在延遲、成本與可靠性之間守住門檻。

數據也把這個取捨具體化了。Gemini 3.1 Pro 標示的價格是每百萬 input token 2 美元、output token 12 美元，吞吐量 109 tokens/s，TTFT 為 29.71 秒；GPT-5.3 Codex 雖然在某些成本維度上不一定最便宜，但 88.7 的加權分數與 SWE-bench Verified 的 85 分，已經把它和入門級模型拉開層級差距。BenchLM 也明講，5 分差距通常就足以區分一個能修複雜多檔案 bug 的模型，和一個會卡住的模型。在程式碼場景裡，這種差距不是四捨五入的誤差，而是一次失敗的 patch。

反方可能怎麼說

最強的反對意見其實很合理：別太相信任何排行榜。基準測試天生不完整，而程式碼尤其難測。模型可以在公開題庫上拿高分，卻在你的私有 monorepo 裡翻車，原因可能只是 build tool 很怪、測試很脆、或團隊慣例太特殊。批評者會說，leaderboard 很容易變成 benchmark tuning 的戰場，而不是產品價值的證明。

這個批評成立，但它否定的不是 BenchLM，而是「只看單一分數」的做法。BenchLM 自己其實已經承認限制：HumanEval 已經飽和，SWE-bench Verified 只是參考點，LiveCodeBench 才是更能抵抗污染的訊號。這才是對 benchmark 懷疑論最好的回應，不是崇拜排行榜，而是把它當篩選器，再回到自己的 repo 做驗證。你該拒絕的不是所有程式碼基準，而是把過時基準當成決策核心的習慣。

所以我的結論很明確：不是基準測試沒用，而是只有少數基準還有用。LiveCodeBench 與 SWE-bench Pro 仍然能告訴你很多事，尤其是模型是否真的能處理真實工程工作；HumanEval 則已經太容易被刷高，不適合再主導選型。

你能做什麼

如果你是工程師，先用 SWE-bench Pro 和 LiveCodeBench 把候選模型縮到少數幾個，再拿你自己的 bug-fix、code review、測試修補流程去跑；如果你是 PM，不要再問「哪個 coding model 最強」，而要問哪個模型在你的延遲、成本、部署條件下還能守住可靠性門檻；如果你是創辦人，把產品評估建立在真實 repo 工作上，而不是能討好簡報的舊題庫。最後你真正該追的，不是最好看的分數，而是最能在真實程式碼裡活下來的模型。