跟 AI 對話久一點，很多人都遇過同一個怪現象：前面十分鐘才講清楚的預算、時間、需求，聊到後面，它像完全沒聽過一樣，又問了一次一模一樣的問題，甚至忘記自己剛剛才答應過的事。第一反應大多覺得「AI 是不是變笨了」，但真正的原因跟智力沒有關係，而是每一個 AI 模型腦子裡都有一塊看不見的白板，能寫的字數是固定的，寫滿之後還想繼續寫，就得先擦掉前面寫過的東西。這塊白板的容量，就是 context window（上下文窗口），決定 AI 一次能「看到」多少內容、又能記住多久。
白板越小，對話一拉長就越容易忘東忘西，搞懂它怎麼運作，你才知道 AI 有時候答得準、有時候卻像失憶是為什麼，也才能反過來調整跟它溝通的方式，讓答案的準確度明顯提升。先從白板本身裝了什麼講起，再拆它寫滿之後怎麼取捨、現在主流 AI 的白板實際有多大，最後回到一個更實際的問題，也就是知道這些之後，你可以怎麼調整自己下指令的方式。
上下文窗口是什麼？
白板的比喻不是隨口說著玩的。IBM 官方對 context window 的解釋，就是把它類比成 AI 模型的「working memory（工作記憶）」；Google 針對 Gemini 系列的官方文件，也用「短期記憶」形容同一件事。用白板來看，三個對應關係其實很直白：白板的大小，就是這個模型能塞進去的容量上限，這個數字是固定的，依模型不同而不同；白板上正在寫的字，則是這場對話目前累積的所有內容，不只是你打的每一句話，還包括系統背後預先設定給模型的指令、AI 自己先前已經回覆過的內容、你上傳的檔案或貼上的長文字，全部都要擠進同一塊白板，沒有誰的內容比較不占空間；白板寫滿之後，能做的只剩下擦掉舊的、騰出位置寫新的。
之所以會有這個上限，是模型架構本身的限制，牽涉到底層計算資源怎麼分配，這篇不深入拆這段技術細節，你只要記得，白板一定有邊界，不是想塞多少就塞多少。
上下文窗口用什麼單位計算？
白板的容量不是用「字數」算，而是用 token（詞元）當單位。IBM 官方文件估算，一個 token 大約對應四分之三個英文單字，也就是說，一段一百個英文字的內容，實際占用的 token 數通常比一百還多一些。中文的換算比例又不太一樣，中文字在斷詞上更破碎，同樣的內容，中文版本往往比英文版本更快吃掉白板的空間，這也是為什麼有些人會覺得中文對話感覺比較快撞到上限。
Token 實際上怎麼切、規則是什麼，牽涉到分詞演算法的細節，值得另外寫一篇專門拆解，這裡只需要記住一件事，token 是白板計算容量的單位，不是你肉眼數的字數。
Context window 跟「AI 真的記得你」是同一件事嗎？
搞懂 token 這個單位之後，還有一個更常見的誤解值得先釐清——很多人以為 AI 之所以「記得」自己，是因為它跟人一樣，把「你」這個人存進了腦袋裡。但多數情況下，這種「記得」只是因為前面講過的內容，還留在同一塊白板，也就是同一個 context window 裡。一旦你開一個新對話，或是舊內容被擠出白板，AI 對你就真的一無所知了。
這跟部分產品另外做的「長期記憶」功能，是完全不同的兩套機制。Anthropic 官方文件說明，一次對話裡的 context window 涵蓋系統提示、每一則對話訊息、工具呼叫的結果、模型自己生成的輸出，這些全部算進同一塊容量裡，用完就是用完。至於某些 AI 助理另外做的「記住你的偏好」功能，做法不一樣，那是把資訊存進白板以外的地方，等下次需要時再撈回來用，IBM 官方也把這種做法歸類在跟 context window 不同的檢索機制底下。
換句話說，白板本身不會累積記憶，白板旁邊有沒有另外一個「檔案櫃」，才是決定 AI 有沒有長期記憶的關鍵。
白板寫滿之後，AI 怎麼取捨留下的內容？
白板寫滿之後，系統不會就這樣當機，而是會用幾套不同的方式決定「留誰、丟誰」。Google 官方針對 Gemini 系列的文件，把常見做法歸納成三種：動態捨棄舊訊息、把內容摘要壓縮、或是改用 RAG（檢索增強生成）去外部資料庫抓資料。Redis 官方技術部落格則對這幾套策略做了更完整的拆解，連同語意快取、agent 記憶系統一起討論。以下把最常見的三種，對應到白板比喻上各自展開。
第一種是截斷，也就是先進先出（sliding window）。白板快滿的時候，系統直接把最早期寫上去的內容擦掉，騰出空間繼續往下寫，對話因此能一直進行下去。代價是，對話最初講定的設定、你一開始交代的前提，可能就這樣被擠出白板，這也是多數聊天介面預設採用的做法。
第二種是摘要壓縮。與其整段擦掉，系統改成把快被擠出去的內容濃縮成幾句重點，寫在白板角落當備忘，原本的細節就不在了，只留下大意。Anthropic 官方文件描述了自家的伺服器端做法，也就是當對話持續變長、逼近容量上限時，系統會自動把較早的對話內容摘要壓縮，讓對話可以繼續進行，不用你自己手動整理重講一次。
第三種是檢索式補充，也就是 RAG。超出白板容量的內容，不會硬塞回白板，而是先存進白板以外的「檔案櫃」，需要用到的時候，才抓一小段放回白板裡。這種做法的好處是，白板本身不用塞滿全部資料，只在真正需要時才撈取相關的一小塊。
這三種做法各有取捨，但有一個共同的限制，模型本身不真的懂「這段話重不重要」，機械式的截斷或摘要，並不保證留下來的剛好是關鍵資訊，除非系統額外設計了判斷這件事的機制。
為什麼 AI 常常忘記中間內容，卻記得開頭和結尾？
白板「滿了才會忘記」只是故事的一半。學者 Liu 等人 2024 年發表在《計算語言學會會刊》（TACL）的一篇研究〈Lost in the Middle: How Language Models Use Long Contexts〉發現，就算白板還沒真正寫滿，資訊都還留在容量範圍內，模型對放在輸入開頭或結尾的內容表現最好，一旦相關資訊落在長輸入的中段，準確率就會明顯下滑。換句話說，這些內容確實還寫在白板上，但模型並沒有認真看完每一個角落。
Anthropic 官方文件把類似的現象稱為 context rot（上下文腐化），原文寫得很直接：「隨著 token 數量增加，準確率與回憶能力會下降，這個現象稱為 context rot。」也就是說，不用等到白板真的爆滿，塞進去的內容越多，答案品質就可能悄悄開始下滑，IBM 官方文件也引用了同一份研究來說明這個現象。
這帶出一個你可以馬上用的心法，真正重要的指令或設定，放在對話最前面或最後面，會比埋在一大段中間更容易被模型認真對待。
現在主流 AI 的白板有多大？
拆完白板寫滿之後的取捨機制，再看一個更直接的問題，就是這塊白板現在能裝多大。各家目前主力模型的規格，其實都已經跳到百萬級別。以撰稿當下查證到的官方資料為準：Anthropic 最新旗艦模型系列的 context window 已經來到 100 萬 tokens；OpenAI 最新旗艦模型的規格也在 100 萬出頭的 tokens 上下；Google 官方針對 Gemini 主力模型的說法則是，主力機型提供 100 萬 tokens 起跳的容量，部分機型甚至能到 200 萬 tokens。
100 萬 tokens 裝得下多少東西，光看數字沒有量感。Google 官方文件給過一個具體的換算：100 萬 tokens 大約等於 8 本一般長度的英文小說、或是 5 萬行程式碼、又或是 200 多集一般長度 podcast 節目的逐字稿。換句話說，現在一支主力模型的白板，理論上足以一次塞進一整套書籍或一個中型專案的程式碼庫，不用像過去那樣把長文件切成好幾段分批餵給它。
只是這個數字代表的是容量上限，不代表 AI 在整塊白板範圍內都看得一樣仔細。前面提到的 context rot 與 Lost in the Middle 的發現，一樣適用在這裡，白板做得再大，塞進去的東西一旦太多，中段內容被認真看待的機率還是會下降。白板數字持續變大是事實，但單看這個數字，不足以判斷一次對話實際能撐多穩。
重要資訊放最前或最後，AI 才比較不會漏看
前面拆的這些機制，最後都要落回你實際能用的做法上。以下三個做法，都能直接用在你平常跟 AI 對話的習慣上。
- 重要指令放在對話開頭，或當下這句話的最後面。Google 官方針對 Gemini 系列的 FAQ 就建議，尤其當整段提示很長時，把你真正要問的問題放在提示的最後面，效果通常比塞在提示中段更好。這正好呼應前面 Lost in the Middle 的發現，重要的東西放頭尾，比埋在一堆背景資訊中間更容易被認真處理。
- 一次講太多、太長的資訊時，分段給，不要一口氣塞成一大段。與其把所有背景、要求、限制條件擠進同一段長文字，不如拆開來講，或是先講最重要的結論，再視需要補細節。
- 明顯感覺到 AI 開始答非所問、忘東忘西時，重新開一個對話，通常比繼續在同一串硬凹更有效率。Anthropic 官方文件也提到，當對話持續變長、逼近容量上限時，與其硬撐，搭配伺服器端的自動壓縮機制、或是主動重新講一次關鍵背景，都是常見的因應做法。
這三件事做起來都不難，而且都在講同一件事，也就是白板容量有限，是目前所有 AI 模型共同的限制，理解它、順著它的邏輯去溝通，會比一味追求「這家白板比較大」的數字更實用。
AI 不是真的失憶，也沒有變笨，只是白板的容量本來就有限，再加上模型天生對中段內容的關注力比較弱，這兩件事加在一起，才會變成你感受到的忘東忘西。搞懂這塊白板怎麼運作，比只盯著「哪一家白板比較大」這個數字更有幫助，畢竟數字會持續往上跳，但寫滿了要取捨、塞得越多越容易恍神，這個本質短時間內不會改變。懂得怎麼跟白板配合著溝通，永遠比追逐更大的容量數字划算。