程式碼評測的第一性問題不是誰排第一，而是題目從哪裡來。只要 benchmark 由模型生成、翻譯、過濾，評測就不再只是「模型答題」，也是「模型出題系統」的產物。

[《AutoCodeBench》](/papers/2508.09101v1.pdf) 真正值得拆的地方，是自動生成多語言程式碼 benchmark 時，語言之間的「難」是否等價。Elixir 這一欄之所以值得看，不是因為它能證明大模型最擅長 Elixir，而是因為它暴露了評測生成流程裡的結構性變數。

## 先說這張排名表在講什麼

先看論文裡的原始表格：

![AutoCodeBench 論文 Table 4：不同模型在 20 種程式語言上的 Pass@1](/images/posts/autocodebench-table-4.webp)

在原文 Table 4 裡，每一行是一家參評大模型，每一列是一種程式語言。

交叉處那個數字表示：把這一語言的題交給這個模型，只看它第一次交出的答案，最後有多少題能一次通過測試。論文把這個指標記作 Pass@1。這裡的 `@1` 可以直接理解成「只給一次機會」。

最上面有一行特殊的，叫 Current Upper Bound。它不屬於任何一個模型，而是把所有模型解對的題目取聯集之後算出來的通過率。只要某道題被任意一個參評模型做對，它就進入這個上界。論文表注明確寫了這一點。

Elixir 共 198 道題，Current Upper Bound 是 97.5。粗略折算，約 193 道 Elixir 題至少被一個模型解對。同一行裡，Kotlin 是 89.5，C# 是 88.4，Racket 是 88.3，Python 是 63.3。

這裡有個很容易踩的坑：不能把 Elixir 97.5 和 Python 63.3 直接寫成「Elixir 比 Python 更適合大模型」。

這不是一個嚴謹結論。

因為不同語言的題目來源不同，生成方式不同，難度過濾效果也可能不同。直接拿語言欄的數字去推導語言本體優劣，會把 benchmark 結果解釋過頭。

真正值得追問的是另一個問題：

**同一批模型、同一套評測流程裡，為什麼 Elixir 這一語言欄會穩定處在高位？**

## 這不是單個模型的偶然

先排除一種解釋：也許只是 Current Upper Bound 的統計特性。多個模型取聯集，數字自然會變高。

那就看單個模型行。

Claude Opus 4 推理模式下，Elixir 是 80.3，C# 是 74.9，Kotlin 是 72.5。Claude Sonnet 4 非推理模式下，Elixir 是 74.2，C# 是 72.9，Kotlin 是 72.0。DeepSeek-R1-0528 推理模式下，Python 是 38.8，Elixir 是 77.3。

注意，這裡比較的不是「Claude 和 Elixir」。Claude 是模型，Elixir 是語言，兩者不在同一維度。

這裡比較的是：

**同一個模型，橫向看它在不同程式語言上的表現。**

從 Table 4 橫著看，Elixir 經常出現在高分位置。它不是某一個模型的單點波動，而是多行模型結果裡反覆出現的語言欄現象。

這把問題從總榜拉到了語言欄。

## 題目是怎麼來的

要理解這個現象，得回到 AutoCodeBench 的生成流程。

論文提出了一套叫 AutoCodeGen 的自動化流程：從 Stack-Edu 裡的真實程式碼片段抽取種子，讓模型把它演化成可獨立執行的完整解法；再生成公開和私有測試輸入；把解法和測試輸入丟進多語言沙箱執行，得到真實輸出；最後根據解法和測試函式反向生成題目描述。

這個設計的關鍵是：測試輸出不是模型憑空寫出來的，而是程式實際跑出來的。

這也是 AutoCodeBench 比「讓模型直接編題編測試」更可信的地方。模型可以負責生成候選，沙箱負責給出事實。

但 20 種語言並不是完全用同一種方式生成的。

論文寫得很清楚：Python、C++、Shell、Java、JavaScript、Go 這 6 種語言直接使用完整 AutoCodeGen 流程；其餘 14 種語言雖然理論上也可以走同樣流程，但由於資料資源有限、多樣性不足，論文採用了近似語言翻譯。Table 3 裡，Elixir 的翻譯路徑是 Python → Elixir。

這就埋下一個關鍵變數：

**Elixir 題目很可能不是 Elixir 生態裡的原生任務，而是從 Python 任務翻譯過去的 Elixir 任務。**

翻譯本身不是問題。

問題在於：翻譯之後，題目難度是否還能和其他語言保持等價？

## 難度過濾器的語言盲區

AutoCodeGen 有一個難度控制機制。

它用 DeepSeek-Coder-V2-Lite 對每道題採樣 10 次，並用沙箱驗證答案。10 次全對的題會被丟掉，因為論文認為這類題太簡單，沒有評測價值。

這個邏輯在熱門語言上更容易成立。

如果過濾模型熟悉 Python、Java、C++，那麼它能 10 次做對的題，大概率確實偏簡單；它做不對的題，也更可能有一定難度。

但到了 Elixir 這樣的低資源語言，情況會變複雜。

論文 Section 3.3 專門比較了熱門語言和低資源語言。熱門語言組選的是 Python、C++、Java、C#；低資源語言組選的是 Racket、Shell、Elixir、TypeScript。結果是，熱門語言組裡模型平均 Pass@1 差距較小，範圍是 50.4 到 53.8；低資源語言組裡模型差距更大，範圍是 45.3 到 62.0。

論文隨後給出了一個解釋線索：頂級模型在低資源語言上表現顯著更好，可能是因為 DeepSeek-Coder-V2-Lite 在低資源語言上的能力有限，難以過濾掉簡單題。

這句話非常關鍵。

它沒有直接說「Elixir 高分就是因為題簡單」，但它提供了一個很合理的機制解釋：

**用於過濾簡單題的模型，在低資源語言上可能不夠強。因此，一些對強模型來說並不難的題，沒有被同等強度地過濾掉。**

這比「大模型最擅長 Elixir」解釋得更穩。

Elixir 的高分，可能不是單純來自模型對 Elixir 的語言掌握，而是同時受到三件事影響：

第一，題目來自 Python → Elixir 的近似翻譯。

第二，難度過濾器在低資源語言上可能不如在熱門語言上可靠。

第三，頂級模型和過濾模型之間的能力差，在低資源語言上被放大了。

這三件事疊在一起，就能解釋為什麼 Elixir 這一欄會特別亮眼。

## Lite 版本裡還有一個側面證據

AutoCodeBench 還有一個精簡版，叫 AutoCodeBench-Lite。

Lite 的構造方式提供了一個側面證據：論文先收集所有模型的解題結果，再按每道題被多少模型解出來排序；通過模型少於 2 個的題先丟掉，然後從剩下的題裡按通過次數從低到高選擇約 1,500 道。論文這樣做，是為了保留那些「至少有模型能解，但仍有區分度」的題，讓模型之間的差距更清晰。

在完整 AutoCodeBench 裡，Elixir 有 198 道題。

到了 Lite 版本，Elixir 只剩 61 道。這個數量在 20 種語言裡屬於最低的一組，少於它的只有 JavaScript 的 57 和 PHP 的 60。

這個數字不能單獨證明「Elixir 題都簡單」。

因為題目沒有進入 Lite，可能有兩種原因：一種是太少模型能解，被第一步丟掉；另一種是太多模型能解，在按通過次數從低到高截取時排到了後面。

但結合 Elixir 的 Current Upper Bound 高達 97.5，以及很多單模型行裡 Elixir 得分靠前，這個 Lite 數量變化至少提供了一個側面訊號：

**完整 Elixir 題集的難度分布，很可能和其他語言不完全等價。**

這才是重點。

不是說 Elixir 題「有問題」，也不是說 AutoCodeBench「不可靠」。

而是說：當 benchmark 通過自動生成、近似翻譯和模型過濾構造時，不同語言之間的難度分布會被生成流程影響。

## 還有一層更隱蔽的偏差

論文 Section 4.2 還討論了模型偏差問題。

整個生成流程大量使用 DeepSeek 系列模型：DeepSeek-V3-0324 負責程式碼生成，DeepSeek-R1-0528 負責 Critic 品質審核。論文也承認，這可能對 DeepSeek 家族模型產生有利偏差。為了緩解這一點，作者在簡單題過濾階段使用 DeepSeek-Coder-V2-Lite，試圖形成一種「push-and-pull」的平衡機制。

更關鍵的是，論文的量化分析顯示，偏差並不是一句「誰出題誰佔便宜」就能解釋完。

在 Table 7 的階段性結果裡，Critic 過濾階段確實讓 DeepSeek-R1-0528 得到提升，但 o3 和 Gemini 2.5 Pro 的提升幅度反而比 DeepSeek-V3-0324 更大。論文最後的判斷也很克制：自動流程可能給 DeepSeek 家族帶來有利偏差，但影響較小。

這部分和 Elixir 不是同一個問題，但它們指向同一個核心：

**自動化 benchmark 不是中立機器。**

誰來生成題目，誰來審核題目，誰來過濾簡單題，哪些語言是原生生成，哪些語言是翻譯生成，都會在資料裡留下痕跡。

最後，這些痕跡會安靜地進入排行榜。

## Elixir 97.5 到底說明了什麼

它說明的不是「大模型最擅長 Elixir」。

也不應該被寫成「AutoCodeBench 有問題」。

更準確的說法是：

**AutoCodeBench 暴露了自動生成多語言 benchmark 的一個關鍵難題：語言之間的難度等價，遠比表面上更難。**

表面上看，20 種語言分布均衡，每種語言大約 200 道題。

但分布均衡不等於難度等價。

一道 Python 任務翻譯成 Elixir 後，是否仍然代表 Elixir 生態裡的真實任務？

過濾模型在 Python 上能篩掉簡單題，在 Elixir 上是否也能篩得同樣乾淨？

沙箱能驗證程式輸出，但題目描述、語言習慣、介面設計、標準庫使用方式，是否也同樣自然、同樣公平？

這些問題都不會直接出現在總分裡。

但 Elixir 這一欄讓它們浮了出來。

## 這篇論文真正值得寫的地方

AutoCodeBench 的價值不只是給模型排了個名。

它更重要的貢獻，是把 benchmark 生產方式往前推了一步：讓模型生成題目，讓沙箱驗證輸出，讓 Critic 檢查品質，再用採樣過濾控制難度。論文也明確說，AutoCodeBench 包含 3,920 道題、37,777 個測試用例，覆蓋 20 種程式語言，目標是構造更困難、更實用、更多語言覆蓋的程式碼生成評測集。

這條路肯定會繼續走下去。

因為程式碼評測有一個天然優勢：程式碼可以執行。只要任務定義得足夠清楚，就可以透過測試用例驗證答案。相比寫作、開放問答、複雜推理，程式碼任務更適合形成「生成—執行—驗證—過濾」的閉環。

但 Elixir 這一欄提醒我們：自動化不是免費的。

模型生成題目，會帶入模型熟悉的問題結構。

模型翻譯題目，會帶入源語言的任務形狀。

模型過濾難度，會受自己的語言能力限制。

沙箱可以驗證執行結果，卻不能保證題目在每種語言生態裡都一樣自然、一樣公平。

所以，未來的程式碼評測不只要問哪個模型得分最高，還要問：

- 這套題是怎麼來的？
- 哪些語言是原生生成，哪些語言是翻譯生成？
- 難度過濾器在不同語言上的能力是否一致？
- 人工驗證覆蓋了哪些語言，又沒有覆蓋哪些語言？

論文裡的人類驗證只覆蓋了 Python、C++、Java、JavaScript、Go、Shell 六種語言，準確率為 87.6%；Elixir 並不在這組人工驗證語言裡。這個細節也說明，對翻譯生成語言的品質和難度分布，還需要更細的後續驗證。

## 最後的結論

AutoCodeBench 的釘子句是：**自動生成 benchmark 的難點不是出題，而是讓不同語言裡的「難」保持等價。**

Elixir 在表裡顯眼，不能直接推出「大型模型最擅長 Elixir」。benchmark 的生成、翻譯、過濾、人類驗證覆蓋範圍都會影響分數。尤其當題目由 Python 擴展到其他語言時，語言欄的分數就混合了模型能力、翻譯路徑和難度篩選能力。

但正因為這些變數都擺在檯面上，Elixir 這一欄才值得繼續追。它提醒我們，程式碼評測不是中立容器。任務從哪裡來、怎樣被改寫、由誰過濾，都會進入最終分數。

下次看程式碼 benchmark，不要只問哪個模型 Pass@1 更高。先問題目供應鏈：原生生成還是翻譯生成，難度過濾器在哪些語言上可靠，人工驗證覆蓋了哪些語言。一個 benchmark 只有先解釋清楚題目如何存在，分數才有解釋權。