名詞解析 · Core Concepts

Token

Q: Token 如何實際應用？

Token 計數影響你的三個關鍵決策： 費用估算：建 API 應用前，先估算你的 prompt 有多少 token，Claude 的預期回答有多少 token，乘以 API 單價算出每次呼叫的費用。不要用字數估算——中文字數 × 1.5-2 才接近 token 數。 Context Window 分配：System Prompt 的每個 token 在每次呼叫都要重新計費。2000 token 的 System Prompt，每天 10,000 次呼叫，光 System Prompt 就貢獻 2000 萬 input token/天。精簡 System Prompt 是最直接的費用優化手段。 語言選擇：如果你的應用是雙語的，同樣的內容用英文比用中文節省 20-50% 的 token。許多開發者選擇用英文寫 System Prompt，即使產品面向中文用戶，這是基於費用效率的合理決策。

Core Concepts 新手

30 秒版 · 給沒耐心的人

AI 處理文字的基本單位，大約是 3/4 個英文單字，中文每個字通常是 1-2 個 token。

完整解說 +

01 · 這是什麼？

Token 是語言模型處理文字的最小單位，不等於字、不等於詞、更不等於句子。英文的 token 切分邏輯大致是：常見詞是一個 token（「cat」= 1 token），不常見詞被切開（「tokenization」= 4 tokens）。中文每個字通常是 1-2 個 token，因為中文字的組合方式和英文不同，tokenizer 對 CJK 字符的效率本來就較低。理解 token 的最直接動機是費用：Anthropic API 的計費單位是 token，不是字數、不是訊息數。你的 prompt 有多少 token，Claude 的回答有多少 token，兩個加起來就是這次呼叫的費用。一個 1000 字的中文文章大約是 1500-2000 token，同樣資訊量的英文約是 1300 token——中文比英文多花 20-50% 的費用，在大規模 API 應用中這個差距會直接轉化為每月帳單的顯著差異。

02 · 為什麼存在？

語言模型在底層操作的是向量（embedding），向量的輸入單位是 token，不是字元。如果用字元作為單位，詞彙表（vocabulary）會爆炸性增長，模型無法有效學習。Tokenization 是一個工程上的平衡：把足夠常見的子詞單元作為基本單位，既能處理所有語言，又能保持詞彙表在合理大小（通常 50,000-100,000 個 token）。英文是訓練資料最多的語言，tokenizer 對英文的效率最高；中文、日文等 CJK 語言的 token 效率較低，這直接反映在 API 費用上。

03 · 如何影響你的決策？

Token 計數影響你的三個關鍵決策：費用估算：建 API 應用前，先估算你的 prompt 有多少 token，Claude 的預期回答有多少 token，乘以 API 單價算出每次呼叫的費用。不要用字數估算——中文字數 × 1.5-2 才接近 token 數。 Context Window 分配：System Prompt 的每個 token 在每次呼叫都要重新計費。2000 token 的 System Prompt，每天 10,000 次呼叫，光 System Prompt 就貢獻 2000 萬 input token/天。精簡 System Prompt 是最直接的費用優化手段。語言選擇：如果你的應用是雙語的，同樣的內容用英文比用中文節省 20-50% 的 token。許多開發者選擇用英文寫 System Prompt，即使產品面向中文用戶，這是基於費用效率的合理決策。

04 · 你該怎麼辦？

三個立刻可執行的動作：使用 Anthropic 的 token 計算工具：在 Console 的 Workbench 裡，輸入你的 prompt 可以直接看到 token 數量。在正式部署前先算清楚費用結構，不要在上線後才發現費用超出預期。壓縮 System Prompt：刪除冗餘的說明和例子，把描述性文字換成指令性文字。「請用繁體中文回答」比「你需要注意使用正確的繁體中文，不要用簡體字，要確保用戶能看懂」省了一倍以上的 token。追蹤 token 用量：在 API 回應的 usage 欄位裡記錄每次呼叫的 input/output token 數。當對話的 input token 開始超過你預設的閾值，觸發提示讓用戶開新對話，或自動壓縮對話歷史。

實際例子 +

場景：你在建一個 AI 客服機器人，每天要處理 10,000 次對話。初始設定：System Prompt 3,000 token，平均對話 5 輪（每輪用戶 50 token + Claude 200 token），使用 claude-sonnet-4-5 模型。費用計算： - 每次對話的 input token：System Prompt（3,000）+ 5 輪對話歷史（1,250）= 4,250 token - 每次對話的 output token：5 輪回答（1,000）= 1,000 token - 每次對話費用：約 $0.028 - 每天 10,000 次：$280，每月費用：約 $8,400 System Prompt 優化後（從 3,000 token 壓縮到 800 token，刪除冗餘說明）： - 每次對話 input token：800 + 1,250 = 2,050 token - 每次對話費用：約 $0.021 - 每月費用：約 $6,300 - 每月節省：$2,100（節省約 25%）關鍵洞察：System Prompt 是費用的放大器——它在每次呼叫中都被重新計費。壓縮 System Prompt 是最直接的費用優化，不需要改架構，只需要精簡措辭。

圖解

歡迎截圖分享，轉載請註明來源

常見誤解 +

✕ 誤解1

× 誤解一：「token 就是字數，可以用字數估算費用」。英文 100 個字 ≈ 75 個 token，中文 100 個字 ≈ 100-200 個 token。如果你用字數估算中文 API 費用，可能低估 50-100%。正確做法：用 Anthropic 的 tokenizer 工具直接計算，或在 Console Workbench 輸入實際 prompt 確認 token 數。

✕ 誤解2

× 誤解二：「input token 比 output token 便宜，所以 System Prompt 長一點沒關係」。System Prompt 的每一個 token 在每次 API 呼叫時都要重新計費。3,000 token 的 System Prompt，每天 10,000 次呼叫，光 System Prompt 就貢獻 3,000 萬 input token/天。不能因為「input 比較便宜」就忽視它。

這件事跟你有什麼關係 +

直接影響

Token 效率 vs 表達完整性：壓縮 prompt 省費用，但可能損失重要上下文，導致 Claude 行為不符預期。每次壓縮後都需要測試，確認輸出品質沒有下降。不是越短越好，而是在最少 token 下達到所需行為。中文 vs 英文 prompt：英文費用更低，但中文 System Prompt 讓 Claude 更自然地以中文回應，輸出品質通常更好。費用和品質之間的取捨需要根據你的具體場景評估。

← 上一個詞條

Temperature

提問

參照詞條

實用資源

Claude API 狀態 → 模型定價 → Prompt 試驗場 → Token 計算器 → MCP 伺服器目錄 → LLM 評測排行 → 模型比較 →