聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

Day 2 我們拆過帳單的結構：單價 × 每次用量 × 呼叫次數。今天要往回退一步，處理一個更基本的問題——「每次用量」裡的那個單位，token，到底是什麼？

我猜你跟我一樣，一開始都用「一個字大概等於一個 token」這種心算法在估帳單。英文這樣估還算堪用。但如果你主要用中文跟 Claude 對話，這個心算法會一路錯下去，而且錯的方向很一致——你以為的便宜，永遠比實際貴。

我自己第一次被嚇到，是把一份 3000 字的中文會議記錄丟給 Claude 摘要，事後翻 usage.input_tokens，發現數字比我心算的多了快一倍。不是 API 算錯，是我對「token」這個字的理解本來就是錯的。

今天要把這件事講清楚：token 到底是怎麼切出來的、為什麼中文特別吃虧、以及你怎麼用官方工具親自量出答案，而不是繼續憑感覺猜。

本篇關於 token counting API 的規格，於 2026 年 8 月 14 日對照 Token counting 官方文件 查證。

目錄

一、Token 不是字，也不是字元

先破除最常見的誤解：token 既不是「一個字」，也不是「一個字元」，它是模型內部的一種切字單位。

模型不會直接讀懂人類的文字，它需要先把文字切成一串固定詞彙表裡的片段，再轉成數字向量去運算。這個切字的過程叫 tokenization，切出來的每一小塊就是一個 token。

英文的切法你可能感覺得出來一點規律：

"tokenization" → "token" + "ization"
"unbelievable" → "un" + "believ" + "able"

常見的英文單字往往整個是一個 token，罕見或複合的單字會被拆成好幾段。這種切法叫子詞切分（subword tokenization）——它不是照字典切，是照「這段字元組合在訓練語料裡出現得夠不夠頻繁」切的。

這裡我要提醒一下： 子詞切分的原理是現代大型語言模型（不只 Claude）的通用做法，屬於業界公開的技術背景知識，Anthropic 官方文件並沒有針對 Claude 的 tokenizer 演算法細節做逐步說明。以下對切字行為的描述，是基於這套通用原理的推論。

二、為什麼中文特別容易「越切越碎」

子詞切分的詞彙表是從訓練語料裡「學」出來的，而訓練語料的組成以英文為主。這件事本身沒有官方明講的具體比例，但它會造成一個容易理解的後果：

詞彙表裡英文的常用片段又多又完整，非英文語言（尤其中文這種沒有空格分詞、字元資訊密度又高的語言）能對應到的完整片段相對少，容易被切得更碎。

用比喻理解：詞彙表就像一本片語字典，這本字典大部分是英文片語。你拿英文句子去查，常常一整個詞就查得到；你拿中文句子去查，很多時候得一個字一個字查，甚至一個字還要拆成好幾個子單位才查得到。查得越碎，token 數就越多。

這是為什麼「一個中文字」不能簡單類比成「一個 token」——實務上，同樣語意份量的內容，中文使用者能吃到的 token 數，往往比對應的英文更多。至於精確的倍率，沒有官方公版數字，而且會因為內容類型（純文字、程式碼、含專有名詞的文件）大幅波動——這正是你不該用網路上的通用換算表，而該自己實測的原因，見第三節。

提醒：本節的「中文比英文容易被切碎」是業界對子詞切分機制的普遍理解與合理推論，並非 Anthropic 官方文件的逐字說明。官方唯一明確承諾的量化數字，是 Day 11 要講的「新舊 tokenizer 之間差約 30%」——那個是同語言、跨模型世代的比較，跟本節「跨語言」的比較是兩件不同的事，不要混著用。

三、自己動手量，比查任何換算表都準

與其套用不精確的通用換算表，官方直接給了一支免費的端點：token counting API。它讓你在真正送出訊息之前，先知道這個請求會被算成幾個 token。

import anthropic

client = anthropic.Anthropic()

response = client.messages.count_tokens(
    model="claude-opus-5",
    system="You are a scientist",
    messages=[{"role": "user", "content": "Hello, Claude"}],
)

print(response.json())
# {"input_tokens": 14}

這支 API 有幾個實用細節值得記住：

• 免費使用，但有獨立的 RPM（每分鐘請求數）限制，依你的用量層級（usage tier）而定：Start 層級 2,000、Build 層級 4,000、Scale 層級 8,000。這個額度跟你平常發訊息的額度分開計算，用它不會侵蝕你的主要配額。
• 回傳的是估計值。實際建立訊息時用掉的 input token 數可能有小幅差異。
• 計算範圍涵蓋 system、messages、tools、圖片、PDF——你平常會送出的東西它都算得到，跟真正建立訊息時算的是同一套邏輯。
• 不會套用快取邏輯：就算你在請求裡帶了 cache_control，token counting 端點也只給你估計值，不會真的建立或命中快取（快取只在真正的訊息建立時發生）。

拿它幫自己的內容建一份對照表，比套用任何網路上的「中文換算英文」公式都準——因為它量的是你的模型、你的內容、你的語言：

samples = {
    "英文簡短提問": "What's the weather like in Taipei today?",
    "中文簡短提問": "今天台北天氣如何？",
    "中文技術文件": open("meeting_notes.txt", encoding="utf-8").read(),
}

for label, text in samples.items():
    r = client.messages.count_tokens(
        model="claude-opus-5",
        messages=[{"role": "user", "content": text}],
    )
    print(f"{label}: {len(text)} 字元 → {r.input_tokens} tokens")

跑過一次之後，你會拿到屬於自己內容的「字元 / token 比」，之後估算帳單、設 max_tokens、甚至決定要不要先做摘要，都可以用這份實測數字，而不是憑印象。

四、Token 數怎麼變成帳單上的錢

回到 Day 2 那個框架：總成本 = 單價 × 每次用量 × 呼叫次數。

Token 就是「每次用量」的計量單位。它會從兩個方向影響帳單：

① Input token 直接影響單次成本，而且是累加的。 你送進去的每一段文字——包含 system prompt、對話歷史、工具定義——都以 input 單價計費。中文如果被切得比你想像的碎，你的「每次用量」就比心算的高，而且這個誤差在長文件、長對話裡會被放大。

② Token 數也決定你會不會撞到 context window 或 rate limit。 Day 5 提過，context window 是輸入加輸出的總和上限；今天你知道了，同樣的中文內容佔用的 token 可能比你以為的多，代表你的「安全空間」其實比想像中窄。Day 13 會講到的 ITPM（每分鐘輸入 token 限制）也是同樣道理——同一份中文文件，比你心算的更容易逼近限制。

❌ Before：用英文的經驗法則估中文成本

# 網路上常見的估算法：1 個英文單字 ≈ 1.3 個 token
# 有人直接套用「1 個中文字 ≈ 1 個 token」來估算
estimated_tokens = len(chinese_text)  # 用字元數當 token 數
budget = estimated_tokens * 5 / 1_000_000  # 隨口套 Opus 5 的 input 單價

✅ After：用 token counting API 量出真實數字再估

actual = client.messages.count_tokens(
    model="claude-opus-5",
    messages=[{"role": "user", "content": chinese_text}],
).input_tokens

budget = actual * 5 / 1_000_000
ratio = actual / len(chinese_text)   # 存下這個比例，之後同類型內容直接套用

Before 版本的問題不是「一定會低估」——有些短句甚至可能被高估。它的問題是你不知道自己錯了多少，也不知道錯的方向。 After 版本只多做一件事：花一次 API 呼叫換到一個屬於你自己內容的實測比例。這個比例你可以存起來，往後同類型的內容就不用每次都重新呼叫端點，等於用一次性的成本，換到長期可信的估算依據。

五、中文使用者容易踩的三個雷區

知道「中文容易被切碎」之後，實務上有三個地方特別容易讓帳單默默膨脹：

① 全形符號與半形符號混用。 中文輸入習慣常常夾雜全形標點（，。「」！？）與半形符號。這些符號本身不常見於英文語料的常用片段裡，切分效率通常不會比純文字內容好。如果你的 prompt 模板裡有大量裝飾性符號（例如用一整排「=」或「★」當分隔線），先用 count_tokens 量一次，你可能會發現這些「看起來不重要」的裝飾字元，貢獻了一筆不小的 token 數。

② 中英夾雜的技術文件。 前端工程師的日常——中文說明夾著英文變數名、API 名稱、程式碼片段。程式碼與英文專有名詞通常切得比較有效率（詞彙表對常見程式語法有較好的覆蓋），但夾在中文語境裡的說明文字仍然照中文的切法走。這代表同一份文件，程式碼區塊的「token 密度」跟中文說明區塊的「token 密度」是不一樣的，籠統估算容易失準，分開估更準。

③ 重複貼上同一份中文規格書或系統提示。 如果你的應用會把同一段中文的產品說明、公司規範、SOP 反覆放進每一次請求的 system prompt，中文的「切得更碎」效應會被呼叫次數放大——這正是 Day 9 要講的 Prompt Caching 特別值得中文使用者關注的原因：同一份會被切成更多 token 的中文內容，快取命中省下的絕對金額，通常比英文情境更可觀。

本篇自我挑戰

• 今日挑戰：挑一段你最近常送給 Claude 的中文內容（可以是 prompt 模板、常用的系統提示，或是一份要餵給它的文件），用上面的程式碼跑一次 count_tokens，算出「你自己的」字元 / token 比。然後拿這個比例，反推你上個月的 API 帳單裡，input 那一項的 token 數跟你原本心算的差多少。

• 反思：我們很容易用「一個字大概一個 token」這種簡化心算法過日子，直到帳單告訴我們不是這樣。你還有沒有其他「用簡化心算法在管理成本」的地方——不只是 token，也許是雲端儲存、也許是 API 呼叫次數？簡化心算法什麼時候該退場，換成實測？

總結

今天釐清了一件基礎但常被誤解的事：token 不是字，也不是字元，它是子詞切分後的產物，而這套切分規則以英文語料為主，中文因此更容易被切得比你想像的碎。

沒有一個放諸四海皆準的「中文轉 token」換算比例——這也是為什麼你該用官方免費的 token counting API 自己量，而不是套用網路上的通用公式。量出屬於你自己內容的比例，才是能實際拿來做決策的數字。

最後把它接回 Day 2 的框架：token 數就是「每次用量」的計量單位，它同時影響你的帳單金額和你離 context window / rate limit 還有多遠。低估它，你會同時在錢和空間兩個維度上錯估風險。

本日關鍵字回顧

• Token：模型切字後的最小處理單位，不等於一個字或一個字元。
• 子詞切分（Subword tokenization）：依訓練語料頻率切字的通用機制，業界普遍原理，非 Claude 專屬技術文件說明。
• Token counting API：/v1/messages/count_tokens，免費使用，回傳估計值，有獨立於訊息建立的 RPM 額度。
• 字元 / token 比：沒有官方通用換算表，建議用實測方式針對自己的內容建立。

明天把今天學到的「token 到底怎麼算」落地成五個馬上能用的省錢習慣——不用寫程式，一般使用者也能直接套用。

Day 8，五個實用的省 token 技巧。