Context Window 是 Claude 在每次對話中能夠處理的文字總量上限，以 Token 為計量單位。Token 不等於字數——英文約每 0.75 個單詞對應一個 Token，中文每個字約 1-2 個 Token。Claude Sonnet 4.6 的上限是 20 萬個 Token，換算成純中文約相當於 10 萬個漢字，看起來很多，但一旦你把長文件、複雜的對話歷史、程式碼全部加起來，很快就會接近上限。
更關鍵的概念是：Claude 沒有跨對話的長期記憶。每次對話對 Claude 來說都是全新的開始，它唯一能參考的資訊就是當前對話的 Context Window 裡放了什麼。如果你沒有把背景資訊放進去，Claude 就不知道它存在。
Context Window 的存在是 LLM（大型語言模型）運作方式的根本決定。Transformer 架構在處理輸入時，需要對整個輸入序列計算「注意力（Attention）」——簡單說，就是判斷哪些部分跟哪些部分有關聯。這個計算量隨著輸入長度的平方增長，計算成本極高。Context Window 的上限是在計算能力、記憶體用量和模型推理速度之間的一個工程取捨結果，而不是任意設定的數字。
另一個原因是訓練資料的結構：模型在訓練時接觸的文字本身有長度限制，超過這個長度的推理能力需要特殊的技術（如 RoPE 位置編碼延伸）才能實現，不是天生就有。這就是為什麼不同模型的 Context Window 差距如此大——它反映了各家廠商在技術和成本上的不同投入。
理解 Context Window 直接影響你選擇如何拆解任務、如何組織提示詞。如果你習慣把大量資訊一次丟給 Claude，你會發現當 Token 用完時，Claude 的輸出品質悄悄下降——它開始遺漏細節、回答變得泛泛，但它不會主動告訴你「我的視窗快滿了」。
對開發者來說，Context Window 的大小直接影響 API 費用。輸入 Token 和輸出 Token 都計費，如果你每次請求都塞滿 Context，費用累積非常快。學會只放「當前任務真正需要的資訊」是控制成本的核心能力。
對一般用戶來說，最實際的影響是：長對話必然有品質衰退的時刻。不是 Claude 的問題，是工具的特性。提前知道這一點，你會在適當時機主動開新對話，而不是在困惑中一直追問為什麼 Claude 突然「不好用了」。
馬上可以用的調整：
重要資訊放對話開頭：每次開新對話，把角色設定、專案背景、格式要求放在第一條訊息裡。Claude 對開頭的注意力最高，不要讓重要資訊被埋在中間。
長文件分段處理：超過 5,000 字的文件，分段丟給 Claude，每段結束後先請它總結要點，再繼續下一段。
主動開新對話：如果一段對話已經很長，明顯感覺到 Claude 的回應品質在下滑，不要繼續在同一個對話裡追問，開新對話，把本次對話的關鍵結論帶過去就好。
開發者優先用 System Prompt：把固定指令移進 System Prompt，減少每輪對話的 Token 消耗，也確保模型每次都看得到這些設定。
用 API 時監控 Token 計數：在回應的 usage 欄位裡看 prompt_tokens，接近上限時主動管理，不要等到截斷發生。