這個 coding benchmark 證明：harness 品質勝過模型光環

這篇主張：評估 coding 模型時，決定結果的不是模型品牌，而是 benchmark harness 的設計品質。

GitHub 的 llm-coding-benchmark repo 給出很直接的證據：如果你要判斷 coding 模型，harness 比模型卡上的名字更重要。它用同一個 Rails brief 比較開源與商業 LLM，並以標準化 metadata、原始 log、以及 0 到 100 的 rubric 評分，重點放在交付物、API 正確性、測試、錯誤處理、持續性、Hotwire、架構與 production readiness。這種設計讓一件事變得非常清楚：同一個模型在不同環境裡可以看起來很強，也可以直接失手；反過來，較便宜的模型只要流程更緊，反而能贏過名氣更大的對手。

第一個論點

這個 benchmark 最有力的地方，是它評估的是能不能真的上線，而不是 benchmark 表演。模型如果寫很多檔案，卻把 RubyLLM API 幻覺成不存在的介面，就會被扣分；模型如果測試數量較少，但用對正確的 signature、處理錯誤、驗證 boot 行為，反而會拿到更高分。repo 自己就點名過這種差異：Kimi K2.5 據稱寫了 37 個測試，卻沒有正確 mock RubyLLM；Gemini 3.1 Pro 只寫了 11 個測試，卻用了正確的 FakeChat 簽名，因此在測試品質上更高。

這代表一個很實際的結論：只看輸出量的 benchmark 很容易被騙，只看正確性的 benchmark 才能活得久。這個 rubric 把幻覺 API 視為失敗，即使測試全綠也不放過，因為建立在假介面上的綠燈根本沒有價值。對 coding agent 來說，錯一個 method call、寫錯一個 client class，問題不會出現在 markdown 摘要裡，而是出現在 app boot、compose 啟動，或第一個真實 request 打進來的時候。

第二個論點

這個 repo 更重要的發現不是某個模型永遠最好，而是同一個模型的品質會被 orchestration layer 大幅改寫。README 直接指出，同一個 Opus 4.7 在 opencode 裡產出 Tier A code，但在 Claude Code 裡只到 Tier 2 或 3，原因是後者環境中它幻覺出了 chat.complete。這不是小差異，而是說明周邊 agent loop 會保留或扭曲模型對任務的推理能力。

DeepSeek V4 Pro 的例子更有說服力。它在 opencode 裡一開始甚至無法衡量，因為有 reasoning_content 的 interop bug；改走 Claude Code，再透過 deepclaude env-swap shim 和 OpenRouter 的 Anthropic-compatible endpoint 後，才進到 Tier A，分數達 84 與 89。還是同一個模型，卻因為 harness 不同，結果差很多。這表示 benchmark operator 不是中立觀察者，而是實驗的一部分，他們的實作選擇會直接改變結果。

反方可能怎麼說

這套說法有一個合理的反駁：如果 benchmark 只圍繞一個 Rails app、一組 prompt family、以及一個 agent stack，那它很容易過度貼合評估者的偏好。0 到 100 的 rubric 雖然嚴謹，仍然是人為 rubric。不同團隊在意的東西不同，創業公司可能更重視速度與部分正確，平台團隊可能更重視可維護性，而 benchmark 未必能完整捕捉。

這個批評最強的地方，在於不要把 benchmark 誤當成產品評估的全部。它不是。它是一個受控壓力測試，而任何受控壓力測試都一定會簡化現實。

但這個反方觀點，並沒有推翻 repo 的核心主張。benchmark 不需要模擬所有 production 環境，也能揭露哪些模型會幻覺 API、哪些模型能撐過 boot validation、哪些模型能讓 persistence 和 tests 跟 brief 對齊。這些是通用失敗模式，不是小眾偏好。這個 repo 的價值，在於它把雜訊壓低到足以看見 correctness 的差異；一旦模型在真介面或真實 compose 檢查上失敗，再多 benchmark 懷疑論也救不了它進入嚴肅的 coding 工作。

你能做什麼

如果你是工程師，別再只看 leaderboard 名次，改成要求 harness 透明：檢查 prompt、驗證步驟、runtime checks、以及失敗模式。如果你是 PM 或創辦人，選模型與 agent 時，要看它在你自己的 stack 裡能不能端到端產出正確 code，而不是看通用 hype。真正該問的不是「哪個模型分數最高」，而是「哪個模型能在我的環境、用我的工具、以我能辯護的成本，交出正確的程式碼」。這個 repo 的答案很明確：決定因素不是模型名字，而是 benchmark 對它施加的紀律。