視窗一百萬字、快取變便宜，為什麼還要精簡

「別一次全塞給它」那篇寫的時候，視窗還是要省著用的東西。2026 年下半年，兩個數字變了。

視窗變大，而且不加價。Claude 4.6 之後的模型全系列一百萬 token，一個 90 萬 token 的請求跟 9 千 token 的請求，每個字同價。快取也變便宜了，Fable 5.1 的快取讀取是原價的 0.025 倍，也就是你重複送同一段開頭，第二次起只付 2.5%。

看到這兩個數字，很自然會想：那就把整個專案、整份手冊、整年的會議紀錄全塞進去，它不就什麼都知道了。我覺得還是要精簡，理由不在錢，在下面這份研究。

研究說的：退化從幾萬字就開始

Chroma 在 2025 年 7 月發了一份叫 Context Rot 的研究，測了 18 個模型（Anthropic、OpenAI、Google、阿里的都有）。結論的第一句是「模型表現隨輸入長度顯著變化，即使在簡單任務上也是」。幾個具體的發現：

問題跟答案的用字越不像，退化越快。同樣一段資料，你問的方式跟資料裡的寫法很接近，長輸入還撐得住；問法換個說法，一拉長就掉。

一個干擾項就有影響。資料裡混進一段看起來相關、其實不相關的東西，準確度就降，而且有些干擾比別的更毒。Claude 系列在不確定時比較會說不知道，GPT 系列比較會自信地答錯。

連照抄都會出錯。叫模型複製一段重複的字，只在中間插一個不一樣的詞，序列越長，它越常漏掉或放錯位置。

他們的結論只有一句：「重要的不是資訊有沒有在那裡，是它怎麼被呈現。」

這跟三層載入那篇講的是同一回事，只是現在多了 18 個模型的數據。視窗變大只是讓東西裝得下，裝進去之後它能不能每一條都看到，還是一樣有問題。

快取便宜改變了什麼

快取便宜確實讓常駐的東西每輪重付的代價變小了。以前建議常駐檔控制在 200 行，有一半是為了錢，這個理由現在弱很多了，但塞越多它越容易漏看，這點沒變。

快取也有它的規則。Claude Code 的 /usage 現在會顯示快取命中率、miss 幾次、原因是什麼；改了工具定義、換了系統提示、對話被壓縮，快取就重建。訂閱方案的快取活一小時，用到額度外的時候降到五分鐘。便宜是有條件的，你的開頭要穩定不變，中間也不能離開太久。

這樣算下來，要精簡的理由還有兩條。一條是上面講的漏看，視窗多大都一樣。另一條是穩定，常駐的東西越少、越不常改，快取越省。

我的做法大致沒變：常駐檔只留原則和地圖，細節要用到再載入，長對話換題目就 /clear，常駐檔也沒有因為視窗變大就多寫。

動手做

想知道自己一場對話塞了多少，在 Claude Code 打 /context，看常駐檔、工具定義、對話歷史各佔多少。打 /usage 看快取命中率，miss 多的話它會告訴你可能的原因。

有一份很長的東西非給 AI 不可，就用擺法補救。貼這段：

我要給你一份很長的資料，但我知道長輸入會讓你漏看。請照這個順序處理：
1. 先只讀我的問題（在最後），用一句話複述你理解的問題。
2. 再讀資料，把跟問題直接相關的段落摘出來，附段落位置。
3. 只根據摘出來的段落回答；資料裡有看起來相關但其實不是的部分，列出來說明為什麼排除。
4. 不確定的地方說不確定，不要用資料以外的知識補。
資料：（貼上）
問題：（寫在最後）

一場對話開很久之後，我會打 /context 看一眼。對話歷史那一格如果已經佔了大半，就用 /rewind 的「從這裡摘要」把前半段壓掉，不等它自己塞爆。

站內延伸

• 三層載入的原理 → 三層載入
• 常駐與按需的取捨 → 常駐與按需的取捨
• 長文件怎麼讓它讀得完 → 找方法AI 長文摘要

來源： Chroma：Context Rot: How Increasing Input Tokens Impacts LLM Performance（18 個模型、問答相似度、干擾項、重複字實驗、「怎麼呈現比有沒有重要」）；Anthropic：Pricing（1M 視窗同價、Fable 5.1 快取讀取 0.025 倍）；Claude Code：Manage costs（/usage 快取統計、快取失效原因、訂閱一小時／額度外五分鐘）。