04 · 上下文視窗：它為什麼會忘

上下文（Context）是模型這一次能同時"看見"的全部內容；上下文窗口（Context Window）是這個容器的上限，按 Token 計。視窗之外的東西，對它來說不存在。

一張桌面

這位新人的腦子像一張辦公桌：能同時攤開的資料就那麼多。你不停往上放，最早那幾張就被擠下去了——不是他不想記，是桌上沒地方了。

每次你發一條訊息，桌上其實擺著這麼幾摞東西：

上下文視窗：它一次能「看見」多少

上下文視窗

System Prompt入職時約法三章的那段設一次，之後每一輪都會被重新發一遍

你貼進來的資料文件、程式碼、表格最佔地方的一摞，也最容易把別的擠掉

檢索來的內容RAG 抓回來的片段整本手冊塞不進來，只能挑相關的幾段

工具返回的結果聯網搜尋、查資料庫Agent 每轉一圈就往上堆一層

對話歷史 + 你這一句前面所有輪的一問一答聊得越久越佔地方，最早的會被「擠出去」

溢位區：最早的內容被擠出去，它就「忘」了

還有第七樣：它這次的輸出，同樣佔地方

視窗滿了會怎樣

聊久了就跑偏最早那幾輪被擠出去，你開頭定的規矩等於沒說過

資料塞不下放不進去就只能先檢索，這就是 RAG 要解決的事

例子不能無限加示例越多越佔地方，留給對話的空間就越少

視窗越大越好嗎

視窗越大 → 越貴、越慢

超長上下文裡，中間的內容最容易被讀漏

關鍵不是視窗多大，是裡面放了什麼

七樣東西擠一個空間。你貼的資料越長，留給對話歷史的地方越小。

現在的視窗有多大

視窗大小這幾年一直在漲，具體數字隨時會變，寫死在書裡沒意義。你只要知道量級：

量級	大概能裝	典型用途
幾千到幾萬 Token	幾頁到幾十頁中文	早期模型、部分小模型、本地跑的模型
十幾萬到幾十萬 Token	一本書	當前主流模型的常規水平
上百萬 Token	一箇中型程式碼庫	少數主打長上下文的模型

大視窗不等於能放心塞滿

兩件事要分開：裝得下和讀得準。業界反覆觀察到一個現象——把關鍵資訊放在超長上下文的中間，模型讀漏的機率明顯比放在開頭或結尾高（這個現象有篇經典論文叫 Lost in the Middle）。俗稱"大海撈針"測得好，不代表實際用起來不漏。

所以視窗是 100 萬，不意味著你該一次塞 90 萬進去。

三個由此產生的現象

一、聊久了它就"變笨"

一個對話拉長到幾十輪，你會明顯感覺它開始跑偏、忘掉你開頭定的規矩、重複問已經說過的資訊。原因就是最早那幾輪被擠出去了。

有的產品會在擠出去之前自動做一次摘要塞回來，這能緩解，但摘要必然丟細節——你開頭強調的那個"必須用表格"，很可能就丟在摘要裡了。

二、它不記得上一個對話

新開一個會話，桌面是空的。上週你跟它掰扯了半天的專案背景，這次一個字都不在。

這不是設計缺陷，是它的工作方式。有些產品做了"記憶"功能，本質是把你之前說過的東西存起來，下次自動幫你重新貼一遍——還是塞進這張桌子，只是不用你手動貼了。

三、它"記得"其實是每次重讀

多輪對話的真相：你發第 10 條訊息的時候，系統是把前面 9 輪的全部內容 + 你這條打包重新發給模型的。它不是接著上次想，是每次從頭讀一遍。

這解釋了兩件事：為什麼越聊越慢、越聊越貴；以及為什麼中途改主意特別難——你前面說的話還都在桌上擺著，一直在影響它。

所以你該怎麼用

一事一會話。 換任務就開新對話。讓上一個任務的殘留繼續躺在桌上，只會汙染這一個。

重要的規矩，重複給。 長對話裡每隔一陣把關鍵約束重申一次："再提醒一次：只用我給的材料，不要編。"這不囉嗦，這是在把它重新放回桌面。

把最重要的放在開頭和結尾。 中間最容易被讀漏。長資料貼進去之後，在末尾再寫一遍你的要求。

長文件分段處理。 別指望一次丟 200 頁讓它通讀。拆成幾段分別處理，再讓它彙總——結果穩定得多。

發現它跑偏了，不要在原對話裡硬掰。 重開一個，把前面得到的好結果作為素材貼進去。掰扯的過程本身也在佔桌面。

常見的兩個誤解

"我把視窗用滿了就是充分利用" —— 恰恰相反。桌面越亂，它抓重點越難。給得準比給得多重要。

"它說它記得我上次說的" —— 它說的話不是證據。它可能只是在預測"這裡應該回答記得"。真要確認，讓它複述具體內容。

下一步

05 · 幻覺：它為什麼會編 —— 會忘只是不方便，會編才是真的會出事。