聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

1M token。一百萬。

聽到這個數字，大部分人的第一反應是：「太好了，那我把整個專案都丟進去。」

我也是。我第一次用 1M context 的時候，興高采烈地把一整個 repo 塞進 prompt，然後問了一個很具體的問題——結果拿到一個很籠統的答案，而且它引用的是一個跟問題無關的檔案。

我以為是我 prompt 寫得不好，改了三次。後來才發現，問題出在我給它的東西太多了。

這件事不是我的錯覺。Claude 官方文件在講 context window 時，寫了一句很直白的話：

A larger context window allows the model to handle more complex and lengthy prompts, but more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot.

（更大的 context window 讓模型能處理更複雜、更長的提示，但更多的脈絡不會自動更好。隨著 token 數量增長，準確度與召回率會下降，這個現象稱為「脈絡腐化」。）

官方不只承認這件事，還給它取了名字。

今天我們要弄清楚：context window 裡到底裝了什麼（比你以為的多）、1M 實際上是多少東西、以及為什麼「塞好塞滿」是錯的策略。

最後那句官方原話值得先記住：「curating what's in context is just as important as how much space is available」——篩選放什麼，跟有多少空間一樣重要。

本篇規格與官方引文皆於 2026 年 8 月 8 日對照 Context windows 官方文件 查證。

目錄

一、Context window 是「工作桌面」，不是「硬碟」

先把定義講清楚，因為這裡最容易搞混。

官方的說法是：context window 指的是模型生成回應時能參照的所有文字，包括回應本身。它跟模型訓練用的那個龐大語料庫是兩回事——它是模型的「工作記憶」。

我用一個比喻。

Context window 是你的辦公桌桌面，不是你的檔案櫃。

檔案櫃（訓練資料）裡有幾萬份文件，但你現在手邊能直接翻閱的，只有攤在桌上的那幾份。桌子越大，能同時攤開的文件越多——這是好事。

但你有沒有過這種經驗：桌上堆了三十份文件，你要找其中一份的某一頁，反而找了老半天？桌子大不代表效率高。攤太多，反而看不見要看的那份。

這就是 context rot 的直覺版本。

二、桌上其實比你以為的擠

第二個容易誤會的地方：什麼東西會佔用 context window？

官方列得很清楚——請求裡的每一樣東西都算：

最後兩項是重點。

工具定義會一直佔著位子。 Day 2 算過，十個工具的 schema 輕鬆破千 token，而且每一次請求都在那裡。它不只是錢的問題，它同時在吃你的桌面空間。

輸出本身也算。 這一點違反直覺——很多人以為 context window 是「輸入的上限」。不是，它是輸入加輸出的總和上限。模型思考的 thinking token 也在裡面。

還有一個進階細節值得知道：上一輪的 thinking 區塊會不會留在 context 裡，各模型行為不同。 官方明載，Opus 4.5 之後的 Opus、Sonnet 4.6 之後的 Sonnet、Fable 5、Mythos 5 會保留先前的 thinking 區塊，它們會像一般輸入一樣持續佔用空間並計費；而較早的 Opus / Sonnet 以及所有 Haiku 模型則會自動剝除。

三、1M 到底是多少東西？

官方給的換算是這樣：

55 萬英文單字大概是什麼概念？一本《哈利波特：鳳凰會的密令》大約 25 萬字——所以 1M context 大概是兩本厚小說。

但這裡有個中文使用者一定要知道的但書：

上面那組換算是以英文為基準的。中文的 token 效率跟英文差很多，同樣的字數會吃掉更多 token。而且更麻煩的是，Claude 4.7 世代換了新的 tokenizer，官方明載同樣的文字會產生大約多 30% 的 token。

所以請不要直接拿「555,000 字」去估算你的中文文件。這個坑我用兩整天來講——Day 7 講 tokenizer 原理，Day 11 講換代之後對中文的實際衝擊。今天你只要記住：中文的實際容量比這張表看起來的少。

另外兩個實用上限：

• 1M context 的模型，單次請求最多 600 張圖片或 PDF 頁面；200k 的模型是 100 張。
• 1M 是預設值，不需要 beta header，而且照標準價計費——沒有長文本溢價。90 萬 token 的請求跟 9 千 token 的請求，每個 token 一樣價錢。

四、一個殘酷的事實：快取不會幫你省空間

這是我覺得最多人誤會、而且代價最大的一點。

很多人的心智模型是：「把大文件放進快取，它就不佔位子了。」

官方文件用一句話直接打掉這個想法：

Cached prompt prefixes still occupy the context window: prompt caching changes what you pay for those tokens, not whether they count.

（被快取的前綴仍然佔用 context window：提示快取改變的是你為這些 token 付多少錢，而不是它們算不算數。）

請把這句話讀兩遍。

快取解決的是「錢」的問題，不是「空間」的問題。

你把一份 500k token 的文件放進快取，第二次呼叫時你只付 0.1× 的價格——很棒。但那 500k 依然佔著 context window 的一半，而且依然參與 context rot。

這也是為什麼 Day 2 的「省錢地圖」跟今天的「空間管理」必須分開看。它們是兩個獨立的維度：

• 錢：快取、批次、換模型 → 降低單價
• 空間：篩選、壓縮、清理 → 降低數量

一個 token 可以很便宜，同時很佔位子。優化其中一個不會自動優化另一個。

五、塞爆的時候會發生什麼？

兩種情況，行為不一樣：

情況一：光是輸入就超過上限

所有模型都一樣——回一個 400 錯誤：

prompt is too long

情況二：輸入沒超過，但輸入 + max_tokens 超過

Claude 4.5 之後的模型會接受這個請求，讓它跑。如果生成過程真的撞到上限，才停下來並回報：

{ "stop_reason": "model_context_window_exceeded" }

這個設計比直接拒絕好——你至少拿得到已經生成的部分。但代價是你必須自己檢查 stop_reason。如果你的程式碼只讀 content 不看 stop_reason，你會拿到一個被截斷的答案，而且完全不知道它被截斷了。

（這又是 Day 4 講的「靜默失敗」的一種。Day 26 講錯誤處理時會回到這裡。）

想事先避免？官方提供 token counting API，可以在送出前先估算這個請求會用掉多少。

六、實務上該怎麼做

❌ Before：能塞就塞，讓模型自己找

# 把整個 repo 讀進來
all_files = "\n\n".join(read_file(p) for p in glob("src/**/*.py"))

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    messages=[{
        "role": "user",
        "content": f"{all_files}\n\n請問使用者登入失敗時的錯誤處理在哪裡？"
    }],
)

✅ After：先篩選，只給相關的

# 先用便宜的方式縮小範圍（grep、檔名規則，甚至用 Haiku 4.5 做前置篩選）
candidates = [p for p in glob("src/**/*.py") if "auth" in p or "login" in p]
relevant = "\n\n".join(f"# {p}\n{read_file(p)}" for p in candidates)

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    messages=[{
        "role": "user",
        "content": f"{relevant}\n\n請問使用者登入失敗時的錯誤處理在哪裡？"
    }],
)

Before 版本的問題不是「會爆掉」——1M 塞得下，它不會報錯。它的問題是會安靜地變笨。

模型要在幾百個檔案裡找出跟登入有關的那幾行，這件事本身就消耗了它的注意力。而 context rot 的意思正是：東西越多，該被找到的東西越可能被漏掉。你會拿到一個看起來合理、但引用錯檔案的答案——就像我開頭遇到的那樣。

After 版本多做的事只有一件：在送進模型之前，先用便宜的方法篩一輪。grep 不用錢，檔名規則不用錢，就算用 Haiku 4.5 做前置篩選也只要 1× 的成本。

這是 Day 4 「路由前置判斷」的另一種形態——用便宜的東西保護貴的東西。

如果你的對話真的會長到逼近上限（例如長時間的代理任務），官方也提供了工具：

• Compaction（伺服器端壓縮，beta）：自動在伺服器端摘要較早的對話，讓對話能越過 context 上限繼續。支援 Claude 4.6 之後的模型。
• Context editing：更細緻的控制，包含清除舊的工具結果、清除 thinking 區塊。

（長對話的成本累積是 Day 12 的完整主題。）

七、送出前先量一下：token counting API

上面講了這麼多「不要塞太多」，但你怎麼知道自己塞了多少？

用眼睛估是不準的，尤其中文。官方提供了一支專門的端點，可以在真正送出之前先算這個請求會用掉多少 input token——而且官方明載它 free to use（不收費）。

（它有獨立的每分鐘請求數上限，依帳號用量層級而定，從 2,000 RPM 起跳。這個額度跟你正常發訊息的額度是分開計算的，用它不會吃掉你的主要額度。）

count = client.messages.count_tokens(
    model="claude-opus-5",
    system=SYSTEM_PROMPT,
    tools=MY_TOOLS,                    # 工具定義也算，記得帶進來
    messages=[{"role": "user", "content": long_document}],
)
print(count.input_tokens)              # 送出前就知道

這支 API 最實用的兩個場景：

① 建立你自己的換算基準。 拿你實際會處理的文件跑一次，你就有了「我的資料，每 1000 字大約幾個 token」這個數字。這比任何通用換算表都準——因為它算的是你的內容、你的語言、你的模型。

② 設一道閘門。 在送出之前檢查，超過門檻就先做篩選或摘要：

if count.input_tokens > 150_000:
    context = summarize_or_filter(context)   # 先瘦身，別直接硬送

為什麼門檻要設在遠低於上限的地方？因為你要防的不是 400 錯誤，是 context rot。

撞到 1M 上限會報錯，那反而是好事——至少你知道出事了。真正麻煩的是塞到 60 萬 token、沒有任何錯誤、模型安靜地開始漏東西。沒有警報的那一段，才是危險區。

門檻設多少沒有標準答案，取決於你的任務。但有一個實用的做法：拿 Day 3 那份測試案例，在不同 context 長度下各跑一次，看品質從哪裡開始掉——那個轉折點就是你的門檻。

本篇自我挑戰

• 今日挑戰：找一個你最近餵給 Claude 的長 prompt，做一件事——刪掉一半，然後重問一次同樣的問題。

  刪的原則是：只留下「回答這個問題絕對必要」的部分。刪完之後比對兩次的答案。

  我自己做這個實驗時的結果是：有一半的情況答案品質一樣（那代表我原本浪費了一半的錢），有三成的情況變好了（那就是 context rot），只有兩成真的變差（那才是我真正需要的資訊）。你的比例是多少？

• 反思：為什麼「塞好塞滿」這麼有吸引力？我的答案是——因為篩選需要我先理解問題，而全部丟進去不用。 把整個 repo 丟進去，等於把「找出哪些檔案相關」這個工作外包給模型。但這件事恰恰是我們自己做比較快、比較準、也比較便宜的。你有沒有其他「把本來該自己想的事外包給工具」的習慣？

總結

Context window 是工作桌面，不是硬碟——它是模型的工作記憶，而不是它的知識庫。

桌上的東西比你以為的多：system prompt、所有訊息、工具結果、圖片文件、工具定義，以及模型自己這一輪的輸出與 thinking。它是輸入加輸出的總和上限，不只是輸入。

1M 大約是 55 萬英文單字，但中文使用者不能直接套用這個數字——中文的 token 效率不同，而且 4.7 世代換了 tokenizer 之後同樣文字約多 30% token。

最重要的一件事：快取不會幫你省空間。 官方明講，它改變的是你為那些 token 付多少錢，而不是它們算不算數。錢和空間是兩個獨立的維度。

而官方自己的結論是最好的收尾：篩選放什麼，跟有多少空間一樣重要。 1M 不是讓你不用思考的許可證，它只是把「該放什麼進去」這個問題的重要性放大了。

本日關鍵字回顧

• Context window：模型生成回應時能參照的全部文字，包含輸入與輸出，是「工作記憶」而非知識庫。
• Context rot（脈絡腐化）：官方用詞。隨 token 數量增長，模型的準確度與召回率會下降。
• 快取與空間無關：Prompt caching 改變 token 的計價，不改變它們是否佔用 context window。
• model_context_window_exceeded：4.5 之後模型在生成中撞到上限時的 stop_reason，需主動檢查，否則會拿到靜默截斷的結果。
• Compaction（壓縮）：伺服器端自動摘要早期對話的 beta 功能，讓對話能越過 context 上限延續。
• Token counting API：送出前預估 input token 數的免費端點，可用來建立自己的換算基準並設置閘門。

明天是第一階段的收尾。我們把前五天的判斷依據——四階模型的規格、計價的 1:5 結構、由上往下的選型流程、Haiku 的四道判準、context 的取捨——全部收斂成一張可以貼在螢幕旁邊的決策表。

Day 6，一張圖判斷你該用哪一個模型。