hero

如果你在過去幾個月看過任何「動態語言的 LLM token 成本比靜態語言低 2-3 倍」的說法——恭喜，你以經被餵了一篇從來沒有人真正驗證過的 viral research。Dan Luu 這篇文章做的事，在 2026 年的 AI 內容生態系裡極其罕見：他不是寫一篇「我覺得…」的觀點文，而是花了超過一百個 bug fix，自己跑完兩個大型 eval，然後告訴你：這個廣為流傳的結論，在真正的程式任務上完全不成立。這篇文章的價值不在答案，而在過程——它示範了 AI 時代最稀缺的能力：不相信 viral 貼文，自己跑實驗。

原文摘要

一篇在網路上被反覆引用的文章（Dan Luu 開頭沒有點名作者，但連結指向 Martin Alderson 的《Which programming languages are most token efficient?》）提出：動態語言、或表達方式更精簡的語言，在 LLM token 效率上優於靜態語言。這篇文章被引用到連 Google AI summary 都直接給出結論——Dan Luu 搜尋「dynamic vs static language token cost」時，Google AI 摘要開頭就是：「動態型別語言因為省略顯式型別宣告，程式碼更精簡，通常具有較低的 LLM token 成本。」Google 引用的正是同一篇文章，該文指出某些精簡的動態語言 token 成本約為 Rust、Go、C++ 等靜態語言的 1/2 到 1/3。作者甚至說 C（token 效率最低）和 Clojure（效率最高）之間有 2.6 倍的「非常有意義的差距」，後來又測試了 J 語言，稱其「以平均僅 70 tokens 碾壓全場，幾乎是 Clojure 109 tokens 的一半」。

另一個在網路上流傳的動態 vs 靜態語言 token 比較是 ai-coding-lang-bench，結論同樣支持動態語言更有效率。

問題一：trivial 任務無法推廣到真實場景

Dan Luu 指出，第一個實驗的根本問題是任務太過簡單。從上面引用的數字就可以看出來——一個可以在 J 用 70 tokens、Clojure 用 109 tokens 解決的題目，根本就不是什麼真正的程式問題（原文使用的是 Rosetta Code 題庫）。Dan Luu 過去比較 caveman mode 與自己 eval 的經驗告訴他：你從 trivial 任務（絕大多數工作量只是在印出答案）得到的結論，跟稍微需要「真正做事」的任務相比，結果可以天差地遠。caveman mode 在 trivial eval 上展現的巨大優勢，一旦換到需要幾個 tokens 以上的任務就消失了。一般來說，trivial 任務上的表現不具備可推廣性。

問題二：ai-coding-lang-bench 的 eval 缺陷

第二個連結（ai-coding-lang-bench）的問題更微妙，Dan Luu 把大部分細節放到附錄，但其中一個代表性問題是：其中一個測試執行了不存在的路徑，導致測試失敗；後續的 agent 則把這個不存在的路徑 symlink 到自己的執行檔——這在該情境下能過關，但也導致之後每一個測試都跑去執行那個 agent 的執行檔，而不是正確的執行檔。換句話說，整個 eval harness 本身就充滿了這類結構性的錯誤。

實驗一：Zstd——實作完整的解碼器

Dan Luu 設計的第一個 eval 是：給 agent 完整的 Zstd RFC（含勘誤表），要求它們實作一個完整的 Zstd 解碼器。Agent 被關在沒有網路存取的容器裡，而且不提供測試案例——agent 必須自己從規格書理解並實作。

如果只看中等投入（medium effort）的結果，你可能會得出跟 Alderson 評估相似的結論：動態語言的集群落在靜態語言集群的左上方，代表動態語言更有效率、更適合 LLM。但如果看超高投入（ultra effort），結果就變得非常混雜——有幾個靜態語言表現最好，而且在表現較好的結果中，靜態語言比動態語言還多。

那些在 trivial eval 中非常強烈的語言類型相關性，在這種規模的任務中完全無法複製。極端的效能比率也消失了——除了那些你本來就會預期表現差的案例，例如用組合語言、或是使用相對冷門的語言（AI 公司不太可能花資源為這些語言生成合成 RL 環境資料）。

Dan Luu 特別指出，這個結果跟第一個 eval 的建議完全相反——第一個 eval 認為像 J 這樣極度精簡的語言可能因為效率理由而有優勢。真相是：如果你有極大的預算，可以自己訓練或微調一個模型來精通你的小眾語言，或許可行；但對於一般 LLM 使用者來說，使用主流語言的勝算遠高於使用冷門的精簡語言。

實驗二：Pandoc——TDD 風格的規格實作

為了從一個完全不同的角度驗證，Dan Luu 設計了第二個 eval：取用 Pandoc ProgramBench eval 並改造成適合的情境。不同於 Zstd 實驗的「讀規格書」模式，Pandoc 更像 TDD 流程——agent 拿到 ProgramBench 的材料以及測試案例，然後用保留的 holdout 測試集來評分。

結果與 Zstd 實驗一致：成功率和成本跟語言是靜態還是動態、或是表達多精簡之間，看不到非常強的關聯。再次看到的是：相對冷門的語言表現普遍較差；組合語言的表現更是預期中的慘烈。即使在這個任務上，語言受歡迎程度（而非語言本身的型別系統或語法密度）才是真正有預測力的變數。

這到底代表什麼？

Dan Luu 說他對 LLM 使用情境有大量的問題：什麼測試技術有效？什麼語言有效？什麼軟體架構有效？bug fix 成本是否因語言而異？一般程式維護成本是否因語言而異？絕大多數這些問題在公開資料中都沒有答案。即使 AI 公司內部有答案，這些資訊也大多沒有公開。

大多數關於「某個語言特別適合 LLM」的說法，Dan Luu 認為都是錯的——包括 Ruby、Clojure、J 這類語言特別適合 LLM 的說法。他的核心觀察是：有了 LLM 之後，很多過去幾乎無法回答的問題，現在只要投入一點點努力和一些 tokens 就可以開始嘗試回答了。但由於當前的激勵結構，短期內我們大概不會看到這些問題被認真回答——儘管現在至少有了自己動手嘗試的可能性。Dan Luu 在這個段落的註腳中點出最尖銳的矛盾：做實驗的 ROI 遠低於做內容。

預先猜測檢驗

Dan Luu 在實驗前就登記了他的猜測：

  • 95% 信心：動態 vs 靜態語言的整體宣稱不會成立 → 這似乎是對的 ✓
  • 60% 信心：在 ultra effort 情境下，靜態語言會略優於動態語言 → 資訊不足以做出決定性判斷
  • 98% 信心：J 這類「怪異」語言的優勢不會成立 → 這似乎是對的 ✓

這種預先登記猜測、然後逐項檢驗的做法，在 AI 內容圈極其罕見——多數人的「結論」是在看到數據之後才想出來的。

Clojure 在 Zstd 實驗的奇特失敗

Dan Luu 提到一個技術細節：Clojure 在 Pandoc eval 相較於 Zstd eval 進步巨大的主要原因，並不是模型對 Clojure 的程式碼生成突然變好了。而是在 Zstd eval 中，36/40 的 medium effort 和 5/40 的 ultra effort Clojure 程式都有測試失敗——原因是 Clojure 的 byte 操作預設使用 checked arithmetic（檢查溢位的算術），而 Zstd 的位元操作需要 unchecked-byte。換句話說，即使是最好的公開 GPT 模型，讓它實作 Zstd 時會系統性地產出這類錯誤的程式碼。這是一個「真正的」結果——它反映的是模型對特定語言特定領域知識的盲區，而不是語言本身的優劣。

結論：不要從單一 eval 推廣到所有程式語言

Dan Luu 承認，在 Zstd 和 Pandoc 兩個 eval 中都看到了語言受歡迎程度與正面結果（更高的正確率、更低的成本、更短的執行時間）之間的相關性，而且這個相關性在其他 eval 中也可能成立——但從兩個任務的數據就去對任何特定語言做出強烈結論，是錯誤的。這個數據（假設 eval 是有效的）可以反駁某些強烈的宣稱，也可以對語言的「類別」做出一些暗示性的推論，但對於個別語言，它真的只能停留在「暗示」的層級。

附錄：更多 eval 細節

Dan Luu 在附錄中補充了幾個值得注意的觀察：

  • Guards of Atlantis 桌遊實作：規格書本身充滿模糊、矛盾、甚至錯誤，LLM 完全無法收斂到正確的實作。這說明了當「規格」本身就有問題時，coding agent 的語言選擇根本不是你該擔心的變數。
  • 記憶體安全問題：Pandoc eval 中，所有的 C 程式和大部分 C++ 程式都有記憶體安全問題（out-of-bounds reads）。語言選擇在這裡的代價不是 token 效率，而是安全性的系統性差異。
  • 超大規模任務：在 12 小時以上的 ultra run 中，靜態語言和動態語言的差異仍然不足以做出普遍性結論——但這類超大規模實驗的成本極高，很少有個人研究者願意投入。

Dan Luu 的文末致謝了 Max Bittker、Yossi Kreinen、Aaron Levin、Alan Boll、Luke Burton、Marco Primi、Milosz Danczak 和 Justin Blank 的評論和討論。

城武觀點

Dan Luu 這篇的真正貢獻，不是回答了「哪個語言對 coding agent 最好」這個問題。事實上，他在文章裡反覆說「我們還不能對個別語言做出結論」。這篇的價值在於它示範了一種在 2026 年 AI 內容經濟中幾近滅絕的行為模式：與其相信一篇被轉發了幾百次的 viral 貼文，不如自己跑 eval。

這件事比看起來的更稀有。Dan Luu 在文末含蓄地提到「incentives」——這才是整篇最值得討論的段落。做一個真正乾淨的 eval 需要什麼？兩個真實世界的程式任務，從規格書到測試案例到 agent 執行環境全部要自己搭，過程中踩了上百個 bug（從 symlink 汙染到 Clojure checked arithmetic 的地雷），然後結論是「我們還沒有足夠數據對個別語言下結論」。這篇文章從頭到尾沒有任何可以被截圖轉發的金句，結尾是一句極其保守的「只能停留在暗示層級」。

反觀那篇 viral 文做了什麼？拿 Rosetta Code 的 trivial 題庫跑一遍，看到 2.6 倍的數字差距，就下了「動態語言的 token 成本是靜態語言的 1/2 到 1/3」的結論——然後 Google AI summary 直接把這句話當成答案在傳播。Dan Luu 沒有直接說那篇文是錯的——他做了一件更狠的事：他用更嚴謹的方法跑了一遍，發現那個結論在真正的程式任務上完全不成立。而那篇 viral 文的作者，大概永遠不會回來修正。

這裡的結構性問題不是「有人做了一個不嚴謹的研究」——這是學術界的日常。真正的問題是：AI 內容經濟的激勵結構，系統性地偏向「快速產出一個看起來有道理的論點」，而非「驗證這個論點是否成立」。 做內容的 ROI 遠高於做實驗。你花三天寫一篇「我發現 X 語言的 token 效率是 Y 語言的 3 倍」，發出去可以被轉發幾千次、被 Google AI summary 引用、成為下一個人寫文章的素材。你花三週跑一個乾淨的 eval，發現「其實我們還沒有足夠數據可以下結論」，這篇文章只有少數人會讀完，沒有人會截圖轉發，Google AI summary 也不會引用它。

更糟的是，錯誤的傳播速度遠快於修正。Dan Luu 這篇文的直接讀者數量，大概不到那篇 viral 文的十分之一。Google AI summary 已經把「動態語言 token 成本更低」當成一個可以放心回答的事實在服務使用者了。當一個錯誤被搜尋引擎背書之後，修正它的成本不是寫一篇反駁文而已——你要跟整個搜尋引擎的權重機制對抗。

Dan Luu 在文章最後說了一句聽起來很平淡、但其實非常重話的觀察：「由於當前的激勵結構，短期內我們大概不會看到這些問題被認真回答。」換成白話：在不對的激勵結構底下，正確的答案永遠跑不贏看起來很順的錯誤答案。這件事不是技術問題，是經濟問題。

話說回來，我現在正在用 LLM 寫這篇分析 Dan Luu 用 LLM 跑實驗的文章——如果這篇文有任何洞察，那是因為 Dan Luu 做了真正的實驗，而我只是在幫他翻譯和擴音。這兩件事的認知價值不在同一個量級。AI 可以幫你寫出看起來很厲害的文章，但它不會幫你跑一百個 bug fix 之後才發現自己的假設是錯的。那個部分，沒有人可以代勞。

城武的未解檔案——當 Google AI 已經把你沒驗證過的結論當成標準答案在傳播時，修正的成本不再是「寫一篇反駁文」，而是「跟整個搜尋引擎的權重系統打一場必輸的仗」。