Vibe Coding 各語言 Token 使用量比較：為什麼 Ruby 特別省
Vibe coding 時代，語言的 token footprint 直接決定成本、速度與可行性。一份跨 19 種主流語言、用 RosettaCode 相同任務以 GPT-4 tokenizer 測量的研究顯示：最省與最耗 token 的語言差約 2.6 倍，Ruby 在主流語言中排第二（僅次 Clojure）。Ruby 省 token 來自無型別註記、語意密度高、Rails 慣例。但最省 token 不等於整體最省力——靜態語言用編譯回饋換回一層免費驗證；Haskell/F# 是折衷。
Vibe Coding 各語言 Token 使用量比較：為什麼 Ruby 特別省
主題整理｜分類：tech｜日期：2026-06-13
核心資料來源：Martin Alderson 以 RosettaCode（約上千道題、19 種主流語言、GPT-4 tokenizer）做的 token 效率分析
摘要
在 vibe coding（讓 AI agent 主導寫程式）的時代，語言的 token footprint 直接決定成本、速度與可行性——每多花在樣板與冗長語法上的 token，就少了給商業邏輯、測試、文件的空間。一份跨 19 種主流語言、用 RosettaCode 相同任務測量的研究顯示：最省與最耗 token 的語言之間有約 2.6 倍差距，而 Ruby 在主流語言中排第二（僅次於 Clojure）。但「最省 token」不等於「整體最省力」：靜態語言（Go/Java/C#/TypeScript）雖然 verbose、吃更多 token，卻用編譯期回饋換回了一層免費的驗證迴圈。本文整理數據、Ruby 省 token 的原因，以及 token 效率 vs 編譯回饋的關鍵權衡。
一、為什麼 token 效率在 vibe coding 裡很重要
- 直接成本：API 按 token 計費，等量功能多燒 2–3 倍 token 就是多 2–3 倍的錢。
- 速度：token 越多、生成越久，迭代越慢。
- context window 可行性：冗長語法擠壓掉可用於商業邏輯、測試、文件的空間；語言越省，越能把更多有效內容塞進同一個 context。
二、各語言平均 token 數（同一批 RosettaCode 任務，GPT-4 tokenizer）
| 語言 | 平均 token | 類型 | 備註 |
|---|---|---|---|
| J | 70 | 陣列語言 | 整體最省，但極小眾 |
| Clojure | 109 | 函數式（JVM Lisp） | 主流中最省 |
| APL | 110 | 陣列語言 | 小眾 |
| Haskell | 115 | 函數式 | 型別推斷 + 簡潔 |
| F# | 118 | 函數式 | 同上 |
| Ruby | 主流第二（約 110–120 量級；原始研究未公開精確值） | 動態 | 本文主角 |
| Python | 130 | 動態 | |
| JavaScript | 148 | 動態 | |
| C | 182 | 程序式 | 此批中最耗 token |
| Java / Go / C# / TypeScript | 未列入該表，屬「verbose」高 token 端 | 靜態 | 見第四節權衡 |
誠實標注：可查到的資料明確指出 Ruby「主流第二、僅次 Clojure」，但未公開 Ruby 的精確 token 數字，上表 Ruby 欄為推估區間，不杜撰確切值。整體「最省 vs 最耗」差距約 2.6 倍。
flowchart LR
subgraph 省["省 token（左）"]
J["J ~70"] --> CLJ["Clojure 109"] --> APL["APL 110"] --> HS["Haskell 115"] --> FS["F# 118"]
end
FS --> RB["Ruby（主流第二, ~110-120）"]
RB --> PY["Python 130"] --> JS["JavaScript 148"] --> C["C 182"]
C --> VERB["Java / Go / C# / TypeScript\nverbose 高 token 端"]
三、為什麼 Ruby 特別省 token
- 沒有型別註記、分號、大括號——這些在 Java/TypeScript/Go 全都要吃 token，Ruby 一律免除。
- 語意密度高：
users.select(&:active?).map(&:email)一行表達完，symbol-to-proc + block 把語意壓進極少字元。 - 慣例優於設定（Rails）：
has_many :posts、attr_accessor用極短語法承載複雜功能；模型對 Rails 模式內化很深，產出更乾淨、更接近 production。 - 社群觀察（廠商部落格，數字當參考非嚴謹論文）：
- Ruby 產出等量功能的 token 約是 TypeScript 的 1/3。
- Rails 達成同功能比 Java/Go 少 30–50% 行數。
四、關鍵權衡：省 token ≠ 一定最適合 vibe coding
省 token 的代價是少了編譯期回饋：
- 約 94% 的 LLM 程式錯誤是型別相關。TypeScript / Go / Java / C# 能在編譯期當場攔下，等於一層免費的驗證迴圈；Ruby 的動態特性把這些推遲到 runtime。
- 因此有觀點主張 Haskell / F#（型別推斷 + 簡潔）是中間最佳解：又省 token、又有靜態型別保護。
- 反向觀點（DHH）：Rails 的既定慣例本身就是 guardrail，加上 agent 會自動跑測試與 linter，能補上動態語言缺的那層驗證——「幻覺進不了 PR，因為程式碼跑過測試才送出」。
該怎麼選
| 你的情境 | 建議 |
|---|---|
| 成本／速度敏感、低臨界性原型、團隊熟 Rails | Ruby/Rails：省 token + 強慣例 + agent 跑測試三者並用 |
| 高臨界性、需要型別保護的大型系統 | 靜態語言（TS/Go/Java/C#），用編譯回饋換審核成本 |
| 想兼顧兩者 | Haskell / F#：型別推斷 + 簡潔，token 與安全的折衷 |
五、一句話總結
Token 效率排序：Ruby（極省，主流第二）> Python > JavaScript > Go/Java/C#/TypeScript（verbose 高 token）。但 token 最省的不一定整體最省力——靜態語言用「編譯回饋」換回了部分審核成本。Ruby 的最佳解是「省 token + 強慣例 + agent 自動跑測試」三者並用。
延伸閱讀（站內）
- 〈DHH 談 Basecamp 5、Vibe Coding 與 Rails 的未來〉——DHH 對 Rails 慣例作為 agent guardrail、agent「最少 token 取悅」傾向的第一手觀點
- 〈為什麼 Anthropic 工程師改用 HTML 跟 AI 工作？〉——同樣談「產出變便宜後，審核／理解成本才是瓶頸」
來源連結
- Martin Alderson 的 token 效率分析（RosettaCode × 19 語言 × GPT-4 tokenizer）
- https://ubos.tech/news/programming-languages-ranked-by-token-efficiency-for-ai-assisted-development/
- https://www.ivanturkovic.com/2026/01/17/ruby-token-efficiency-llm-ai-friendly-language/
- https://rorwizards.org/why-ruby-on-rails-dominates-vibe-coding/
- https://jetrockets.com/blog/why-ruby-on-rails-is-the-best-stack-for-vibe-coding-in-the-age-of-ai
分類：tech｜標籤：vibe-coding, token-efficiency, ruby, rails, llm, 程式語言比較