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，接近上限時主動管理，不要等到截斷發生。
你一定有過這種經驗：和 Claude 聊了好一段時間，突然它開始「忘記」你在對話初期說過的事情。你以為 AI 應該記得所有東西，但它的回應開始出現矛盾，甚至像是從頭來過。
這不是 bug，也不是 Claude 變笨了。這是 Context Window 的物理限制在發作。
Context Window（上下文視窗）是 Claude 在每次對話中能「看見」的文字總量上限。你可以把它想像成 Claude 的工作桌面：桌面有固定大小，你放在上面的東西愈多，最早放上去的東西就會從邊緣掉落。
更準確地說，Context Window 是以 Token 計量的。Token 不完全等於字，英文大約每 0.75 個單詞是一個 Token，中文每個字大約是 1-2 個 Token。Claude Sonnet 4.6 支援最多 20 萬個 Token 的 Context Window，聽起來很多，但一個完整的技術文件、幾十輪對話、一段程式碼，很快就能把這個空間填滿。
許多人以為 AI 有某種隱藏的長期記憶。實際上，Claude 每次對話都從零開始。上一段對話的內容、上週你說過的事、你的偏好設定——這些全部不在 Claude 的「記憶」裡，除非你在當前對話中明確告訴它。
Context Window 是 Claude 唯一能參考的資訊來源，它包含三個部分：
這三者加總，不能超過 Context Window 的 Token 上限。
不同的系統有不同的處理方式，但最常見的兩種：
截斷（Truncation）：最早的對話內容被丟棄，只保留最近的訊息。這就是「Claude 開始忘事」的原因——它不是真的忘了，是那些內容已經不在它的視窗裡了。你還在看整個對話，Claude 只能看最後幾千個 Token。
摘要壓縮（Summarization）：部分系統會在超出前自動把舊對話壓縮成摘要，塞回 Context 的開頭。這樣能延長有效記憶，但摘要過程本身有資訊損耗，細節會流失。
Context Window 裡，並不是每個位置的 Token 權重都一樣。研究顯示，LLM 對 Context 開頭和結尾的內容注意力最高，中間部分相對容易被「忽視」——這個現象被稱為「Lost in the Middle」。
實際含義：如果你有一份重要的文件要 Claude 參考，不要把它放在一長串對話的中間。要放開頭，或者在問問題前重新提示它：「請根據我在對話開頭貼入的文件回答以下問題。」這個小技巧能顯著提升 Claude 對重要資訊的注意力。
理解 Context Window 之後，你會開始用不一樣的方式跟 Claude 互動：
長任務拆段：如果你要分析一份長報告，不要一次全丟進去，而是分段處理，每次附上前一段的摘要結論，讓 Claude 能在有限的視窗裡保留最重要的脈絡。
重要資訊放在開頭：你的角色背景、專案說明、輸出格式要求——放在每次對話的最前面。Claude 不會記得，你要每次告訴它，而且要放在最顯眼的位置。
善用 System Prompt（如果你是開發者）：把不變的設定、角色定義、格式要求放進 System Prompt，讓它固定佔據 Context 的前段，減少對話歷史的空間佔用，也確保每次都被 Claude 看到。
監控 Token 用量：Claude API 使用者可以在每次請求的回應中看到 Token 計數（prompt_tokens + completion_tokens）。接近上限時，主動整理對話或開新 Session，避免突然的截斷造成輸出品質下降。
GPT-3 當年的 Context Window 只有 4,096 Token。現在頂級模型已普遍達到 10-20 萬 Token，研究中的模型甚至達到 100 萬 Token。這個成長代表 Claude 能處理的任務複雜度在快速提升——從分析一篇文章，到現在可以處理一整本書的內容。
但 Context Window 再大，也有邊界。理解這個邊界，才能真正有效地使用 Claude：知道什麼時候要拆任務、什麼時候要重新提示、什麼時候要開新對話，是每個 Claude 重度使用者必須掌握的基本功。