Context Window

Context Window 到底有多大？我在日常工作中需要擔心嗎？

Claude 的 Context Window 目前超過 200,000 tokens，換算成日常可以理解的單位，大約相當於 15 萬個中文字，或一本 500 頁書的文字量。這對日常工作來說幾乎是用不完的——普通的辦公文件、Email 往返、會議紀錄整理，不太可能在單次對話中撞到這個上限。

但有幾個高風險情境需要注意：

第一，一次上傳多份大型 PDF。例如三份 100 頁的報告。PDF 轉成 token 的效率較低，一份 100 頁的密集文字 PDF 可能消耗 50,000-80,000 tokens，三份就接近上限了。

第二，同一個對話進行了非常多輪的深度討論，每輪都有大量輸入和輸出。如果你和 Claude 在一個對話裡討論了一整天，對話紀錄本身就會佔用相當大的空間。

第三，System Prompt 非常長（超過 5,000 字），加上大量文件，容量會消耗得更快。

判斷要領：如果 Claude 開始給出和之前討論不一致的回答，或忘記了你在對話早期說過的重要前提，這通常是 Context Window 接近上限的信號。這時最好的做法是開新對話，把最關鍵的結論或前提帶過去。

對話太長時，Claude 會怎麼處理超出的部分？

Context Window 的截斷機制採用先進先出（FIFO）的邏輯——最早加入對話的內容最先被移出 Claude 的可見範圍。

當對話的總 token 量接近上限時，系統會從對話紀錄的最早部分開始截斷，讓最近的對話和最新的輸入保持在 Claude 的視野內。

重要細節：System Prompt 通常被設計為優先保留，不會在一般情況下被截斷。被截斷的是用戶和助手之間的對話紀錄。

實際影響：Claude 不會告訴你「我忘記了你之前說的話」，它只是不知道那些內容存在過。所以你可能遇到它的回答和早期討論矛盾、或重複問你之前已經說清楚的事。這是辨識對話需要「重啟」的信號。

有什麼實用方法可以避免太快遇到 Context Window 上限？

以下是五個最有效的管理策略：

1. 上傳文件之前先做減量處理。需要分析 200 頁的報告，不要整份上傳。先把最相關的 10-20 頁節錄出來，或只貼相關段落和數據表。Token 消耗量可以減少 80% 以上，分析品質通常不會下降。

2. 長對話定期「存檔重啟」。每隔 15-20 輪對話，把這個階段最重要的結論整理起來（可以請 Claude 幫你做：「請把我們到目前為止討論的關鍵結論整理成 5 點」），然後開新對話，把這 5 點帶過去。

3. 把固定背景知識放在 System Prompt 或 Knowledge 欄位。不要在每次對話的開頭貼公司介紹或產品說明。這些固定資料放在 Claude Projects 的相應欄位，系統會更有效率地管理它們。

4. 一個任務，一個對話。週報整理是一個對話，客戶回信是另一個，內部文件是第三個。保持對話的任務焦點，避免無關內容佔用 Context Window。

5. 用純文字替代 PDF。複製文字貼入比上傳 PDF 更有效率。PDF 的格式本身（排版、圖片）會消耗 token，但對文字分析沒有幫助。

Context Window 和 Claude 的「記憶」有什麼關係？為什麼 Claude 不記得上次對話的內容？

簡單來說：Claude 沒有跨對話的記憶，每次開新對話都是從零開始。

Context Window 只是「當前這次對話」的資訊容量上限，它不是長期記憶。當你關閉一個對話視窗，再開一個新對話，Claude 對於上一次談過什麼完全沒有記憶。這不是 bug，而是設計——每次對話都是獨立的，沒有跨會話的狀態保留。

這和人類的記憶非常不同。人類可以在兩次會面之間記住上次說了什麼，但 Claude 每次對話都是一個全新的開始。

在職場上這意味著：如果你今天和 Claude 討論了一個客戶提案的結構，明天開新對話時，你需要把那個結構重新告訴它。不能假設它「知道」上次談過的事。

Claude Projects 的部分緩解：Projects 的 System Prompt 和 Knowledge 欄位是跨對話持續存在的，這些資料每次開新對話時都會被帶入。所以把「需要 Claude 一直知道的事」放進去，能減少每次重新說明的需要。但對話紀錄本身依然不會跨對話保留。