過去幾個月，我一直在撰寫關於人工智能的文章，特別是關於邏輯層模型（LLM）的底層工作原理。讀者反響熱烈，一些讀者還提出了後續問題。其中一個反覆出現的主題是上下文窗口：它們是什麼，如何工作等等。
到處都能看到這些數字：10萬代幣的發行窗口、100萬代幣、1000萬代幣。數字不斷攀升，宣傳攻勢也愈演愈烈，但大多數人卻完全不明白這一切究竟意味著什麼。
所以今天，我們就來解決這個問題。
讀完這封信，您將瞭解什麼是上下文窗口，為什麼更大的數值並不總是意味著更好的模型，以及下次選擇使用哪種人工智能時應該如何考慮所有這些因素。我還會分享一些優化上下文窗口的技巧和竅門，無論您使用什麼模型。
簡易版
上下文窗口是模型的運行內存。
模型完成其工作所需的一切都必須包含在單個請求中。這包括您的提示、系統指令、您上傳的任何文檔或圖像、聊天記錄、模型可以訪問的工具以及它即將生成的響應。
所有內容共享同一個預算，預算以詞元（token）為單位。我在第108封信中介紹過詞元，但為了方便回顧，一個詞元大約是四分之三的單詞。因此，一個20萬詞元的上下文窗口可以同時容納大約15萬個單詞的內容。一百萬個詞元大約是75萬個單詞，作為參考，這相當於一部相當長的小說的長度。
我們是如何從 4000 個代幣增長到 1000 萬個代幣的？
ChatGPT 於 2022 年底推出時，採用的是 GPT-3.5 模型，其令牌窗口只有 4000 個。因此，用戶無法粘貼長篇文章，否則就會遇到瓶頸。
Meta 的 Llama 4 Scout 聲稱有 1000 萬，這在我看來有點過分了，因為隨著上下文窗口的擴展，輸出質量會顯著下降（稍後會詳細介紹）。
總體而言，從 ChatGPT 推出至今，其增長了 250 倍至 2500 倍。
近期取得的大部分進展都得益於圍繞注意力機制、即時緩存和高效內存管理等方面的巧妙工程設計。
越大越好嗎？
一般來說，我不是這方面的專家（儘管坊間傳言並非如此），但就人工智能上下文窗口而言，越大並不總是越好。
上下文窗口大小是模型技術上可以接受的最大值，但這不一定是模型能夠有效/最佳利用的大小。
Chroma 的一些研究人員去年發表了一項名為《上下文腐爛》（Context Rot）的研究。他們測試了 18 種不同的最先進模型，包括 Claude、GPT 和Gemini，用於執行不同輸入長度的簡單檢索任務。任務本身保持不變，只有輸入長度發生了變化。
隨著輸入數據長度的增加，所有模型的性能都下降了。一些在短輸入數據上得分接近100%的模型，在處理更長的輸入數據時，得分卻低於50%。
該研究的名稱被社區採納，“上下文腐爛”一詞也迅速成為人工智能領域的常用語。其要點很簡單：隨著提示信息量的增加，模型的可靠性會降低（即使這些額外內容本身無關緊要，也無法真正提供有用的上下文信息）。
導致這種上下文混亂的背後有幾個原因：
模型往往更關注提示的開頭和結尾，而不是中間部分。隱藏在冗長上下文中間的重要信息可能會被忽略。研究人員稱這種現象為“迷失在中間” （科學家們在命名慣例上並不以原創性著稱，例如：智利的甚大望遠鏡）。
當提示信息中存在看似與你提問的內容相似但又不完全匹配的信息時，模型就會感到困惑。即使只有一個干擾項，也足以讓它出錯。
信息在提示中的位置也會影響模型對其的使用效果。同一信息位於第 1000 位和位於第 50000 位時的表現截然不同。
當問題和答案用不同的詞語表達同一個概念時，隨著上下文的擴展，該模型會越來越難以處理。
關鍵在於，廣告宣傳的上下文窗口大小是一個上限，而不是目標，而且對於你使用 AI 執行的幾乎所有任務，你通常都應該在接近上限之前就清除上下文窗口並重新開始。
這對你的實際行動意味著什麼
如果你使用人工智能來處理需要同時處理大量信息的工作，那麼上下文窗口就很重要；但大多數人實際上並沒有這樣做。
大多數文檔比人們想象的要小。例如，一份 50 頁的 PDF 文件大約只有 25,000 個令牌。你可以粘貼這樣的文檔，與 AI 進行長時間的對話，而總共的令牌數遠低於 10 萬。
編寫代碼只會加劇這種情況。一旦涉及到子代理和並行工作，編寫代碼就會極大地消耗代幣。
這就是為什麼本地模式對某些工作來說極具吸引力的原因之一。使用本地模式沒有按代幣計費或使用限制。我在第 107 封信中詳細介紹了本地模式，如果您想了解更多信息，可以查閱該信。
如何真正管理上下文窗口
這是我最希望你記住的信中的這部分內容。以下是我使用的實用策略，以及一些實際構建這些模型的專家的指導。
這裡更宏觀的視角是Anthropic工程團隊稱之為“情境工程”的概念。他們在2025年9月發表了一篇深度分析文章，如果你想了解更多，這篇文章值得一讀。他們對該主題的總結是我見過的最好的：
“良好的上下文工程意味著找到儘可能少的高信號標記，從而最大限度地提高實現預期結果的可能性。”
這種思維方式實際上改變了我日常使用人工智能的方式。我現在不再問應該輸入什麼，而是問可以省略什麼（再次證明，“少即是多”的原則是正確的）。
以下是由此衍生出的策略。
1. 每次聊天只處理一個任務，並且經常從頭開始。
這是我養成的最有用的習慣。如果你正在研究一個主題，然後突然轉向另一個主題，那就新建一個聊天窗口。如果你完成了一篇草稿，想要進行潤色，那就新建一個聊天窗口。如果你花了一個小時調試一個問題，而下一個問題又與它無關，那就新建一個聊天窗口。
在 Product Talk 上撰寫人工智能產品工作的 Teresa Torres說得非常好：每一次長時間的聊天都會積累噪音，而這些噪音會使下一次回覆變得更糟。
2. 使用交接技術
當你需要延續上下文信息時，在重新開始之前，讓模型生成一份簡潔明瞭的要點總結。複製這份總結並粘貼到新的聊天窗口中作為開場白。
這正是 Claude Code 在達到上下文限制時自動執行的操作。Anthropic 將其稱為“壓縮” ，並在其上下文工程文章中將其描述為你應該首先採取的措施。他們會保留架構決策、未解決的錯誤和關鍵文件，同時丟棄冗餘的工具輸出和舊消息。你可以使用任何 AI 工具手動執行相同的操作。
3. 關注50%線
從事人工智能產品開發的 Arthur Clune 在最近的一篇文章中提出了一個非常精闢的觀點：當上下文窗口填充超過 50% 左右時，LLM 的準確率就會開始明顯下降。Anthropic 的壓縮功能會在填充 95% 時自動觸發，這意味著當你看到提示信息時，系統已經在降級模式下運行了一段時間。
因此，你不應該僅僅等待 Claude Code 自動壓縮，因為它只有在接近文件大小限制時才會發生。你可以隨時手動運行 `/compact` 命令來壓縮文件。
4. 在使用人工智能之前先進行內容整理
與其往上下文裡塞50份文件，指望AI能“自己搞清楚”，不如直接導入5份相關的文檔，這樣效果會更好。模型並不總是知道哪些信息重要（它當然也不知道哪些信息對你來說特別重要）。所以，趁現在還能利用自身優勢的時候，好好利用你作為人類的優勢吧。
5. 將重要內容放在開頭或結尾。
中間部分信息容易被忽略的研究結果在歷代模型中都適用。位於提示開頭和結尾的信息比隱藏在中間的信息更容易引起注意。如果你有一篇很長的文檔，其中某個段落非常重要，即使它已經在文檔中出現過幾次，也要在提示的結尾重新列出該段落。
6. 使用項目或自定義 GPT 來保持上下文的持久性
Claude 有“項目”功能，ChatGPT 有“自定義 GPT”功能。兩者都允許您設置持久的系統提示，並上傳參考文件，這些文件不會佔用每次聊天的上下文。如果您有重複的使用場景，請將說明和參考資料放在“項目”或“自定義 GPT”中，而不是在每次聊天中重複輸入。
7. 對大型知識庫使用 RAG（紅綠燈）
RAG 代表檢索增強生成（Retrieval Augmented Generation）。它並非將上千篇文檔直接輸入到提示框中，而是將它們索引到向量數據庫中，然後僅提取與每個問題最相關的部分。Perplexity、NotebookLM 和 ChatGPT 的深度研究功能等工具的底層原理正是如此。我會在以後的文章中詳細介紹 RAG，它值得專門撰寫一篇文章。
8. 選擇適合工作的型號
Gemini 3.1 Pro 價格實惠，適合處理大型文檔。Claude Opus 4.7 在處理文檔時，一旦掌握了上下文信息，就能進行強大的推理能力；如果預算有限，Sonnet 4.6 則是一個不錯的折中選擇。GPT-5.5 是 OpenAI 目前最先進的產品，價格介於兩者之間。如果您要處理一份 500 頁的 PDF 文件， Gemini可能是您的理想之選。如果您要解決一個複雜的多步驟問題，Opus 或 GPT 則可能是更合適的工具。
9. 對於智能體而言，將閱讀任務與思考任務分開。
如果你正在構建智能體（或者使用 Claude Code、Cowork、Cursor 等工具），Anthropic 對長時間運行智能體的研究絕對值得一看。其核心洞見在於，探索會迅速消耗上下文信息。因此，他們建議使用子智能體，這些子智能體專門用於處理特定的讀取密集型任務（例如跨文件搜索、代碼安全審查），並且只返回摘要信息。這樣，主智能體的上下文信息就能保持乾淨。
你也可以手動操作。如果你想讓克勞德深入研究某個問題並根據研究結果採取行動，可以在一次聊天中完成研究，得到一份簡潔明瞭的總結，然後以這份總結為起點，在新的聊天中展開行動工作。
10. 不要粘貼不需要的圖片
圖片在代幣方面價格不菲。一張高分辨率截圖可能就要消耗 1000 到 2000 個代幣。如果你在一段很長的聊天記錄裡上傳了 20 張截圖，光是圖片本身就要消耗 2 萬到 4 萬個代幣。我很喜歡截圖並把內容添加到聊天記錄裡，但有時候真的會失控，所以提醒大家不要過度使用截圖功能。
結語
希望這篇文章能幫助你更好地理解上下文窗口的概念和工作原理。大多數人看到標題吹噓更大的上下文窗口就以為越大越好，但實際上，我現在處理的任務很少超過 20 萬個標記。偶爾會達到 40 萬到 50 萬個標記，然後才會進行壓縮，但這種情況並不常見。
也許/希望有一天這個問題能夠得到解決，我們可以可靠地使用 100 萬甚至 1000 萬個令牌上下文窗口，而不會出現數據丟失的情況。
在此之前，請密切關注上下文。如有新任務，請定期創建新的聊天窗口；在不同的會話之間進行交接；如果您希望獲得更好的結果，請在提示的開頭和結尾重複重要信息。
感謝您一直以來的閱讀，我們下週再見！
免責聲明：本簡訊內容不構成投資建議。本人並非財務顧問，以上僅代表個人觀點和想法。在交易或投資任何加密貨幣相關產品之前，您務必諮詢專業/持牌財務顧問。文中部分鏈接可能為推薦鏈接。
