03 · Token：它眼裡的世界，也是你的帳單
Token（令牌）是大模型處理文本的最小單位。它眼裡沒有"字"也沒有"詞"，只有 Token。你的費用、上下文上限、速率限制，全部按 Token 算。
一個 Token 大概是多少
沒有精確換算，只有經驗值。不同模型的切分方式還不一樣，所以下面這張表是用來"估"的，不是用來"算"的：
| 內容 | 大概幾個 Token |
|---|---|
| 一個漢字 | 1 ～ 2 個 |
| 一個常見英文單詞 | 1 個左右 |
| 一個生僻英文單詞 | 2 ～ 3 個 |
| 一個標點、一個空格 | 通常算 1 個 |
| 一頁 A4 中文文件（約 800 字） | 1000 ～ 1600 個 |
| 一份 30 頁的 PDF | 三四萬個 |
粗略記法：中文按字數 × 1.5，英文按單詞數 × 1.3，估個數量級夠用了。
為什麼英文更"便宜"
主流模型的切詞表是以英文為主訓練出來的，常見英文單詞往往一個詞就是一個 Token，而中文經常一個字就要一到兩個。同樣一段意思，中文版通常比英文版貴一截。真要壓成本的場景（比如要塞很長的資料），有人會把提示詞寫成英文——但可讀性和團隊協作的代價你自己權衡。
為什麼你必須知道這個詞
一、你的錢按這個收
按 API 計費的話，帳單長這樣：輸入 Token 一個價，輸出 Token 另一個價（輸出通常貴好幾倍）。所以：
- 你把一份 50 頁的合同整個貼進去問一句話——貴的是那 50 頁，不是你那句話。
- 讓它"把這份文件重寫一遍"比"把這份文件總結成五條"貴得多，因為輸出長。
- 多輪對話越聊越貴：每一輪都要把前面所有內容重新發一遍（見 04 · 上下文視窗）。
包月訂閱的聊天產品不直接按 Token 收你錢，但背後的額度限制還是這個邏輯。
二、它一次能裝多少，按這個算
模型的「上下文窗口」大小是用 Token 數說的。"20 萬 Token 的視窗"意思是：System Prompt + 全部對話歷史 + 你貼進去的資料 + 它這次的輸出，加起來不能超過 20 萬。裝不下會怎麼樣，下一章講。
三、它數不清字數，也是因為這個
讓它"寫一段 500 字的介紹"，你多半會拿到 430 字或者 620 字。不是它偷懶，是它眼裡根本沒有"字"這個單位——它在按 Token 往下預測，中途沒有一個準確的計數器。
別用字數當硬指標。要控制長度，改成它能感知的結構約束：
- ❌ "寫 500 字" → ✅ "寫三段，每段三到四句話"
- ❌ "簡短一點" → ✅ "總共不超過五個要點，每點一行"
- ❌ "詳細展開" → ✅ "每個要點下面各給一個具體例子"
字數只能當"大概的鬆散提示"用，當硬性驗收標準一定翻車。
順帶說清楚三個連帶的概念
| 詞 | 意思 | 你什麼時候會撞上 |
|---|---|---|
| 速率限制（Rate limit） | 每分鐘 / 每天最多能用多少 Token 或請求數 | 批次處理時突然被限流 |
| max_tokens | 你給這次輸出設的上限，到了就硬截斷 | 輸出到一半戛然而止，通常是這個設小了 |
| Temperature | 挑下一個 Token 時的隨機程度，低=穩定保守，高=發散 | 要穩定格式調低，要創意發散調高 |
這三個在聊天框裡通常看不見，一旦你開始用 API 或者帶參數的工具就會遇上。詳細解釋在術語表。
一個能立刻用上的估算習慣
派活之前先掃一眼你要貼進去的東西有多長：
- 幾百字 — 隨便貼，不用想。
- 幾千字（一份紀要、一篇文章） — 沒問題，常規操作。
- 幾萬字（一份長報告、幾十頁 PDF） — 能塞進大視窗模型，但注意兩件事：貴，而且中間的內容它容易讀漏。
- 十幾萬字以上（一整個知識庫、幾百份文件） — 別硬塞。這是 RAG 要解決的問題：只把相關的那幾段挑出來給它。
下一步
04 · 上下文視窗：它為什麼會忘 —— 知道了單位，接下來看這個容器有多大、裝滿了會怎樣。