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）

誠實標注：可查到的資料明確指出 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

1. 沒有型別註記、分號、大括號——這些在 Java/TypeScript/Go 全都要吃 token，Ruby 一律免除。
2. 語意密度高：users.select(&:active?).map(&:email) 一行表達完，symbol-to-proc + block 把語意壓進極少字元。
3. 慣例優於設定（Rails）：has_many :posts、attr_accessor 用極短語法承載複雜功能；模型對 Rails 模式內化很深，產出更乾淨、更接近 production。
4. 社群觀察（廠商部落格，數字當參考非嚴謹論文）：
   • 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，因為程式碼跑過測試才送出」。

該怎麼選

五、一句話總結

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, 程式語言比較