文言文能不能減少 token 數?
前幾天 PO 了一個關於 Caveman 的討論，剛好留言區的回饋有稍微討論到。我當時有提到，好像看過有人用文言文的 skills 讓 Claude 輸出文言文，藉此來節省 Token。因為發現大家對這個話題蠻有興趣的，所以我去查了一下到底是哪一個 skill 這麼有趣。
結果我發現更有趣的地方在於，Caveman 本身就已經被集結在一個網路上的 Repository 裡面，其中就有一個指令是讓輸出的中文變成文言文，所以 Caveman 本身就具備這個功能。
https://github.com/JuliusBrussee/caveman
但我今天要討論的重點不是這個，而是我在搜尋過程中，發現了幾個關於「文言文加 AI」這個組合蠻有趣的話題：
1. 文言文是否真的能節省 Token？
延續 Caveman 的講法，大家直覺會認為文言文字數比現代中文少，應該能減少 Token 使用量。但我看到對岸有網站特別去測試，發現要節省 Token 最重要的不是「字數」，而是「Tokenizer」。
(a) 他們做了一個小實驗，例如這句話：「使用文言文聊天，看起來用了更少的字，但事實上真的能更節省嗎？」用 OpenAI 的 Tokenizer 測試，需要 21 個 Token。
(b) 如果改用文言文寫法：「以文言相語，官若用字更少，然其食果更省乎？」雖然字數看起來節省了將近一半，但實際測試下來還是需要 20 個 Token。
(c) 也就是說，字數雖然減少10個字，但 Token 實際上只節省了一個。
2. Tokenizer 的切分邏輯
這背後的原因是大型語言模型的 Token 切分是依照「語意」而非「字數」。
(a) 有一個有趣的例子：在 OpenAI 的 Tokenizer 中，「無恙」這個詞雖然在文言文中代表健康的意思，只有兩個字，但它其實佔了 3 個 Token。
(b) 相反地，像「無碼不卡高清免費」這種現代常見詞彙，反而可能只佔 1 個 Token。
(c) 因此，文言文雖然濃縮了字量，但它所帶的語意與白話文差不多，最終使用的 Token 數其實也相去不遠。
這篇報導的結論是：如果你真的想要節省 Token，那不如直接使用英文。
關於 Caveman 的詳細報導以及相關的測試資料，我會放在下面讓大家參考。如果大家有興趣的話，也可以自己去試試看。
https://news.qq.com/rain/a/20260409A034W900
https://github.com/JuliusBrussee/caveman
最後這個網站特別提到 10 個網友討論如何節省 Token 的方法，我看了看，把一些比較主要的方式講給大家聽：
1. 在已發送的消息上修改，而不要另發一條消息
例如當你期望 AI 回答 A，但它最後回答 B 的時候，你不要發一條說：「不對，我要你回答的是 A 方向。」而是直接編輯前面的消息重新發送。這樣它就不會累積聊天紀錄重新讀一遍，而是直接覆蓋過去，能節省不少 Token。
2. 每 15 到 20 條消息就重開一個新對話
對於 LLM（大型語言模型）來講，很大一部分的 Token 是用來閱讀聊天歷史資料的。所以當對話變長時，最好開啟新對話。或者使用 Claude 裡面一個叫「Compact」的功能，它會把你之前的對話濃縮起來。但我認真覺得，除非是完全不能切割的超大型專案，否則以我個人的經驗，最好在開發不同功能時就切換到不同的對話框，不要用同一個對話框處理所有事情。
然後順帶一提，我以前以為 NotebookLM 不會有這個問題，直到我大量使用之後才發現，其實給它的資訊越多，它越會胡說八道。它會亂標註一些內容，讓你誤以為它是照著你的文件去說的。
3. 把所有類似的問題集中在同一個消息中發送
例如我想要總結一篇文章、列出要點並給這篇文標題，這三個任務對 LLM 來說其實可以一次做完。如果你分三次發送，其實是在浪費 Token。你甚至可以把這三條直接合併成一個完整的提示詞。
不過這個訣竅雖然我常用，但也要提醒大家小心一點：當你把很多分歧的問題集中在同一條消息發送時，可能會有兩種狀況：
(a) 每個問題都回答得非常籠統。
(b) AI 覺得其中一兩個問題不重要，所以一句話帶過，只認真回答某一個問題。
如果發生後者的狀況，你可能會被它引導去解決 A 問題，而忽略了原本也要處理的 B 和 C 問題，感覺問題沒被徹底解決，反而被它糊弄過去了。
作者：CCL