2026 年 4 月 16 日，Anthropic 發佈 Opus 4.7。同一天，r/ClaudeAI 跟 HN 開始炸。
吵的是什麼？大部分的「regression 罵聲」其實都繞著同一件事打轉：新 tokenizer 把同一段英文 prompt 編碼成更多 token。Simon Willison 把自家 system prompt 丟進 token counter 實測——多 46%。同樣的 prompt、同樣的內容、同樣的 $5/$25 per million 標牌，OpenRouter cohort 統計算下來真實帳單漲 12–27% ，特定內容組合甚至更多。
但這篇我想講的不是那個故事。我想講的是：同一次變動，中文工程師反而是受益方。
如果你的 prompt、context、文件、code review 都是中文為主，4.7 的 tokenizer 換版對你來說根本沒漲價。如果你還在用 Claude Code 配上一堆中文 CLAUDE.md 跟中文 prompt，你跟英文圈的人在算同一條帳單，但用的 token 數比他們少。這是少數一次「中文工程師佔便宜的時刻」，而我相信大多數人還沒意識到。
先看數字：tokenizer 換版到底差多少
Claude Code Camp 拿 Anthropic 自己的 POST /v1/messages/count_tokens 端點對 12 種內容類型實測 ，這是目前最乾淨的對照數據：
| 內容類型 | 字元數 | 4.6 token | 4.7 token | 4.7 / 4.6 |
|---|---|---|---|---|
| English technical docs | 2,541 | 478 | 704 | 1.47× |
| Shell script | 2,632 | 1,033 | 1,436 | 1.39× |
| TypeScript code | 4,418 | 1,208 | 1,640 | 1.36× |
| Spanish prose | 2,529 | 733 | 986 | 1.35× |
| Markdown + code | 2,378 | 604 | 812 | 1.34× |
| Python code | 3,182 | 864 | 1,112 | 1.29× |
| English prose | 2,202 | 508 | 611 | 1.20× |
| JSON (dense) | 48,067 | 13,939 | 15,706 | 1.13× |
| Tool defs (JSON Schema) | 2,521 | 738 | 826 | 1.12× |
| CSV (numeric) | 9,546 | 5,044 | 5,414 | 1.07× |
| Japanese prose | 993 | 856 | 866 | 1.01× |
| Chinese prose | 750 | 779 | 789 | 1.01× |
看最後兩列。Chinese 跟 Japanese 是 1.01×——四捨五入等於沒漲。
這不是 measurement noise。Simon Willison 自己的 token counter 工具 也做了類似比對，結果一致：英文 + code 大幅漲，CJK 幾乎沒動。
對應到帳單：findskill.ai 引用 OpenRouter 對切版用戶的 1M+ request cohort 分析 ，英文為主的開發者「真實成本上升 12–27%」。中文工程師的對應 cohort 雖然沒被點名，但根據 1.01× 的編碼比例，帳單變化在 5% 以內——這個範圍正常使用波動就會吃掉。
為什麼 Anthropic 會做這個變動？
這不是 bug，這是 Anthropic 的策略選擇。
LLM tokenizer 用的是 BPE（Byte-Pair Encoding）這類演算法，把訓練語料裡常見的字串合併成單一 token。Tokenizer 的 vocab 是固定大小——通常是 10 萬到 20 萬個 token。每多塞一個英文常用合併（例如「technical」、「implementation」整個變一個 token），就少給其他語言一個位置。
舊的 Claude tokenizer 訓練語料英文比例極高，所以英文壓得很短、中文卻一個字一個 token（甚至更糟，常見漢字會被切成多個 byte）。中文用戶長期承受的就是「英文一句話 4 個 token、中文同義一句話 10 個 token」的不公平。
4.7 的新 tokenizer 把 vocab 重新分配：把一些英文長合併拿掉、塞入更多 CJK / 多語的常見字元組合。結果就是英文編碼變鬆、CJK 變緊——對 Anthropic 來說是拉平多語成本的合理決策，但對英文圈而言就是「同價漲 35%」的隱形稅。
claudecodecamp 的分析寫得很直接 ：「CJK content moved 1.005–1.07x. A wholesale new vocabulary would shift these more uniformly. That didn't happen. Consistent with the non-Latin portions of the vocabulary changing less than the Latin.」
韓國工程師的反彈：CJK 還是不夠便宜
事情沒這麼單純。CJK 對 4.6 → 4.7 的漲幅幾乎沒感，但整體絕對 token 數仍然遠高於英文。
GitHub Issue #26401 是一位韓國開發者開的 ，標題：「Non-English users (Korean/Japanese/CJK) face structural disadvantage due to tokenization inefficiency — Usage limits should be adjusted accordingly」。他列出同義句子的 token 比較：
| 句子 | 語言 | Token 數 |
|---|---|---|
| "Refactor this function" | English | ~4 |
| "이 함수를 리팩토링해줘" | Korean | ~10–14 |
| "Fix the bug in this file" | English | ~6 |
| "이 파일의 버그를 수정해줘" | Korean | ~14–18 |
| "Explain the architecture" | English | ~4 |
| "아키텍처를 설명해줘" | Korean | ~10–12 |
同樣意思，韓文用 2–3 倍 token。中文跟日文情況類似。
Claude Pro 的月 quota 是按 token 算的——你用韓文/中文/日文做 Claude Code，等於 2–3 倍的速度燒額度。Issue 提了 4 種可能解法：
- 按語言調整 quota
- 升級 tokenizer 讓 CJK 更貼近平衡
- 至少在訂閱頁清楚寫出「token 數隨語言而異」
- 改用「請求次數」或「compute time」而非 token 計費
Anthropic 對這個 issue 沒有提出政策性回應方案，CJK 工程師對 quota 不公平的呼聲至今未被正式處理。
所以實際定位是這樣：4.7 換 tokenizer 沒讓中文工程師付出英文圈的代價，但中文工程師本來就在付高於英文的代價。新 tokenizer 只是讓這個差距沒擴大，沒縮小。
但帳單算的是「漲幅」，不是「絕對值」。如果你 4.6 時跑得動，4.7 切過去帳單不會額外漲。這在 4.7 翻車的脈絡裡，就是中文工程師最該知道的紅利。
寫程式碼的台灣工程師怎麼算這筆帳
但工程師寫 prompt 不只是中文。實際 Claude Code 一個 session 的 prompt 是「中文需求說明 + 英文 code + 英文 framework 文件 + JSON tool defs」混排。我用 Claude Code Camp 那張表自己組了一個典型 session 的權重估算：
| 內容類型 | 佔比 | 4.7/4.6 比例 | 加權貢獻 |
|---|---|---|---|
| 中文需求說明 | 15% | 1.01× | +0.15% |
| TypeScript/Python code | 50% | 1.32× | +16% |
| 英文 framework 文件 | 15% | 1.47× | +7% |
| JSON tool defs | 10% | 1.12× | +1.2% |
| Markdown 混排 | 10% | 1.34× | +3.4% |
| 合計 | 100% | — | ~+28% |
啊就是——就算你需求說明全寫中文，只要 codebase 是英文寫的，整個 session 的真實 token 還是會漲 25-30%。
但這算法有兩個但書：
- 中文比例越高越省。如果你的工作流是「中文 prompt + 中文文件閱讀 + 中文 markdown 整理」，比如做研究、寫部落格、做翻譯、跑 RAG 在中文知識庫——那 4.7 對你而言真的接近持平。
- CLAUDE.md 系統提示也要算進去。我自己的 CLAUDE.md 90% 是中文敘述、10% 是 code fence，4.7 上幾乎不漲。但 Anthropic 自家 Claude Code 的內建 system prompt 是英文，這部分你跑不掉。
實際上對「以中文寫 prompt、但 code 為英文」的台灣工程師來說，4.7 是 「漲一點點」，不是 「持平」。比英文圈的 +28% 還是好很多。
給中文工程師的 5 條實戰建議
那實務上怎麼讓這個紅利落地？
1. CLAUDE.md 用中文寫滿，不要混英文
你的 CLAUDE.md 是每次 session 都要載入的，token 成本會放大很多倍。把它寫成中文，配合一點點 code fence 範例，能把整個 system prompt 的 token 數壓到很低。台灣鄉民版的 CLAUDE.md 大概長這樣：
# Memory
- 使用繁體中文回應
- Git commit：<type>: <description>（feat/fix/refactor/...）
- 偏好 zod 做 input validation
- 不要寫廢話 comment，只寫 why
短、中文、行動導向，token 效率拉到頂。
2. 中文需求說明配英文技術詞
需求用中文寫沒問題，但技術術語留英文：
✅ 「幫我把這個 fetch() 改成 axios，順便加 retry logic 跟 exponential backoff」
❌ 「請協助我將此處的網路請求函式更換為另一個套件，並添加錯誤重試與指數退避機制」
第二種寫法看似「全中文」其實 token 數更高（因為 BPE 對「網路請求函式」這類組合的合併比 fetch() 差很多），也讓 Claude 還要花心力把中文映射回英文 API 名。Code 圈裡 fetch / axios / retry 不需要翻譯。
3. 不要在 Claude Code 裡用「請」「謝謝」「麻煩你」
這不是禮貌問題，是 token 問題。實測「請幫我」「麻煩你」這類客套話一句就消耗數個額外 token，一天下 100 個 prompt 等於白扔幾百個 input token。
我不是叫你變沒禮貌，是把禮貌話留給跟人溝通的場景。跟 Claude Code 直接下指令就好。
4. 大型文件閱讀請走 1M context，不要切 chunk
2026-03-13 之後 Opus 4.6/4.7/4.8 的 1M context 全部變成標準價，不再有 200K 之上 2× 加價。中文文件 token 密度比英文高（同樣字元數，中文佔的 token 數量少但「單位資訊量」高），對中文 RAG 來說 1M context 是真實能用的。
過去要把一份 300 頁中文 PDF 切成 50 個 chunk 做向量檢索的場景，現在可以直接整本丟進去問。當然要付 input token 費，但比 chunk + retrieve + 重組的整體成本低很多。
5. 留 Opus 4.6 當 long-context 保底
根據 4.7 system card 232 頁細讀 ，4.7 / 4.8 在 MRCR v2 8-needle 長上下文檢索測試上掉得很慘（4.7 在 1M 從 78.3 砍到 32.2，4.8 雖然修復一些但還是輸 4.6）。如果你做的是「長文檢索 + 多 needle 提問」，4.6 還是中文 RAG 的隱藏王者。
API 模型 ID 隨時可切：
# 一般任務
model = "claude-opus-4-8"
# 大量長文檢索任務 → 切回 4.6
model = "claude-opus-4-6"
為什麼這件事值得寫一篇
英文圈的 4.7 翻車敘事已經寫到爛了——Simon Willison、The Zvi、findskill、claudecodecamp 全部都在罵英文 token 漲價。
但中文圈幾乎沒人在講「我們其實沒漲」這件事。原因可能是：
- 寫 LLM 觀察的中文部落格少
- 大家覺得「跟我無關」就跳過
- Reddit / HN 罵聲量太大，蓋過細節
但這是真實的差異，而且是對中文工程師有利的差異。如果你正在做 production 的 Claude API 整合、或經營靠 LLM 計價的產品，這個 tokenizer 偏移直接影響你的單位經濟。
當然，這只是「中文相對英文沒漲」的相對紅利。絕對來說 CJK 用戶單 token 攜帶的資訊量還是比英文低，韓國工程師開的 Issue #26401 仍然成立。Anthropic 對多語 fairness 的態度是「一步步拉平」，4.7 是這一步。下一步會不會把 CJK 編碼效率再拉一檔，我不知道。但短期內，你可以放心地寫中文 prompt、用中文 CLAUDE.md、配上英文 code——這個組合在 4.7/4.8 上是最划算的搭配。
夭壽，難得有一次 LLM 升級對中文使用者比較好，記得佔便宜。
延伸閱讀
- Claude Code Camp：I Measured Claude 4.7's New Tokenizer
- Simon Willison：Claude Token Counter with model comparisons
- findskill.ai：Claude Opus 4.7 Tokenizer Cost Math
- GitHub Issue #26401：CJK 用戶因 tokenizer 不公平的請願
- Anthropic 官方 Opus 4.7 公告
- Hacker News：Claude Opus 4.7's new tokenizer 1.47x on English 1.01x on Chinese
- Cursor 論壇：1M context GA at standard pricing 公告討論
沒有留言:
張貼留言