把一篇兩千字的中文文章交給 AI，是否就等於送入兩千個 token？答案是：不能直接這樣換算。AI token 是模型處理內容的單位，不等於中文字數、英文單字數，也不等於檔案大小。 真正容易出錯的地方，不只是中文怎麼分詞，還包括用了哪個 Tokenizer，以及你數的是一段正文，還是包含系統指令、對話與工具定義的完整請求。這篇先說清楚 token 的概念，再整理實際計數時應注意的邊界。 AI token 是什麼？不是一個字，也不一定是一個詞 OpenAI 官方說明指出，token 可以代表一個字元、單字的一部分、整個單字或標點；空白也會影響文字如何被切分。因此，「一個中文字固定等於一個 token」或「一個英文單字就是一個 token」，都不是通用規則。 文字經過 Tokenizer，會被轉成模型可處理的 token 序列與對應編號。這個過程常稱為 tokenization，中文可稱詞元化或分詞，但它不一定依照人類閱讀時認為完整的詞義切分。 這也表示，看到 token 邊界很零碎，不代表模型只理解零碎的字；同樣地，某段文字剛好只用少數 token，也不能據此推論模型比較理解它。計數單位與理解品質，是不同的問題。 為何中文字數不等於 token 數？ 中文、英文、混合語言、數字與符號，會遇到不同的編碼情況。模型使用的編碼方式不同，同一段原文也可能得到不同的 token 數。 例如，「你好」與「你好！」不只是字數不同，實際如何切成 token，還要看指定的 Tokenizer。繁體字、專有名詞、網址、程式碼與特殊符號混在一起時，更不應只靠肉眼估算。 官方常見的「約四個字元是一個 token」等說法，是對英文文字的粗略估計，不是可以直接套用到所有中文文章、所有模型的換算公式。即使文章長度相同，只要內容與編碼不同，token 計算結果就可能不同。 因此，也不能一概認為把中文翻成英文就一定更省 token。翻譯會改變文字長度與表達方式；實際結果仍要用目標模型對應的計數方法檢查，還要確認原意沒有因此改變。 原創概念插圖，非實際分詞結果：不同 Tokenizer 對相同文字的切分與計數，可能不同。 同一段文字，換 Tokenizer 就可能換一個數字 OpenAI 的 tiktoken 教學提供固定編碼的比較示例：同一個英文單字 antidisestablishmentarianism，在 r50k_base 編碼中是 5 個 token，在 cl100k_base 中則是 6 個。 這個例子說明的是相同文字不保證在不同編碼下得到相同計數，而不是哪種編碼在所有內容上都比較好。該教學已標示為封存資料；這裡只引用其固定字串與編碼示例，不把舊模型對照表當成現行模型支援清單。 實際工作時，先確認目標模型與其支援的計數方式。不要拿某個網站預設的 Tokenizer 結果，當成所有平台通用的精確值；模型或編碼更新後，也應重新檢查。 只數正文，為何可能低估完整輸入？ 你貼進計數工具的文章，未必就是模型實際收到的全部輸入。完整請求還可能包含： 系統指令與其他角色的訊息。 本次一起送入的對話內容。 工具名稱、用途描述、參數結構與其他格式定義。 圖片、檔案或其他多模態內容，以及服務使用的請求格式開銷。 OpenAI 官方說明特別區分「純文字 token 計數」與完整請求的計數，指出訊息結構、工具、schema、圖片與檔案都可能影響輸入總數。純文字工具即使把那段文章數對了，也不代表它已涵蓋完整請求。 Claude 官方計數文件也提醒，計數結果屬於估算，實際輸入用量可能有小幅差異；其計數功能支援的請求組件亦有範圍限制。使用前要確認工具支援什麼，不要假設所有外部工具與附件都已自動算入。 圖片、音訊與影片，不能用可見字數推算 如果你交給 AI 的不是只有文字，單純計算中文字數就更不適用。Google Gemini 官方 token 文件說明，文字、圖片、音訊與影片等輸入都涉及 token 計數，不同媒體會依其處理方式計算。 一張看起來沒有文字的照片，也可能佔用輸入用量；影片也不是只把字幕拿來計數就完整。實際結果要依模型、媒體處理模式與官方支援的計數方法確認，不能靠「畫面上有幾個字」代替。 原創概念插圖，非用量圖表：完整輸入可能含訊息、工具與媒體，不只是使用者可見的一段正文。 輸入 token、輸出 token 與可見回答，要分開看 輸入 token是請求提供給模型的內容；輸出 token是模型生成的內容。輸入計數工具能協助檢查送入多少，卻不能預先精確知道模型最後會產生多少輸出。 OpenAI 官方文件也指出，推理模型可能使用不直接顯示為回答文字的內部推理 token。因此，可見回答很短，不一定代表整次生成只使用那段文字所對應的 token。 此外，上下文視窗、最大輸出與請求頻率限制，也不是同一種限制。這篇不把不同模型的上限混成一套公式；使用時要查看指定模型與端點的文件，並為需要的輸出保留空間。關於長文件的另一個問題，可延伸閱讀AI 上下文視窗：放得下為何仍可能漏重點。 實際做 token 計算，可以照這個順序 先確定你要量哪一種東西 如果只是想觀察一段文字怎麼被切分，可以用對應模型的 Tokenizer。若要判斷整個 API 請求的輸入大小，則應使用該服務支援的完整輸入計數功能，並確認它涵蓋哪些訊息、工具與媒體。 保留會真正送出的內容與格式 計數時用實際要送出的版本，包括標點、換行、網址與必要說明。不要為了讓數字好看，先把來源、欄位名稱或重要條件刪掉，卻用另一份內容正式執行。 如果需要把文字貼進外部網站，先確認服務來源與資料處理方式；敏感文件可改用不含私人資料的測試文字，避免為了估算而多一次不必要的資料分享。 最後對照實際請求的使用紀錄 有 API 使用紀錄時，對照該次請求回傳的 usage 等用量欄位，分清楚輸入、輸出及其他服務提供的分類。事前計數與事後紀錄用途不同，不能把一次正文估算當成後續所有請求都固定相同。 如果團隊會持續修改提示詞，也可以把模型、提示版本與計數結果一起保存；但驗收仍要看答案是否符合要求，而不是只選 token 最少的一版。提示詞版本的管理方法，可參考AI 提示詞管理與測試題的做法。 結論：先選對計數對象，再談數字大小 AI token 不是中文字數的另一種寫法。它取決於文字內容、Tokenizer 與模型，也可能受到完整請求中的訊息、工具與媒體影響。 下次看到「這段文字有多少 token」，先問兩件事：用哪個模型的計數方式？數的是純文字，還是完整輸入？把這兩點說清楚，數字才有比較意義，也比較不會把估算、上下文容量與實際使用量混在一起。
