# 什麼是 Context Window（上下文窗口）？一針見血的大模型基礎科普
在大模型（LLM）的技術文件與 API 計費頁面上，開發者最常看見的規格指標除了「模型參數」之外，就是 Context Window (上下文窗口)。例如：*「本模型支援 128K 上下文」*、*「擁有 200 萬超長上下文窗口」*。
對於剛接觸 AI 開發或日常使用的讀者而言，這項參數到底代表什麼？它對 AI 的回答品質有何影響？本文將用最直白的方式，為您一針見血地科普上下文窗口的核心概念。
Context Window (上下文窗口) 是大語言模型在單次對答中能夠「記憶」的最大文本範圍，通常以 Token 為單位計量。2026 年大模型的上下文窗口已大幅提升，如 Google Gemini 與 Kimi K2 支援高達 200 萬 Token (約 150 萬字)，而 Claude 3.5 支援 20 萬 Token。上下文窗口越大，意味著能一次分析整本書籍或整個軟體專案；但開發者需注意，超出窗口限制會導致 AI 健忘，且超長文本還會面臨「大海撈針 (Lost in the Middle)」召回率下降與 API 成本飆升的挑戰。
---
什麼是上下文窗口？你可以把它當作 AI 的「工作記憶體」
要理解上下文窗口，最貼切的隱喻就是人類大腦的短期工作記憶（RAM）。
當你與 AI 聊天時，AI 並不是一個會記住你所有過去人生歷史的生命體。相反地，它在每次回答你新問題時，都必須把你之前發送的所有歷史對話、甚至你上傳的 PDF 檔案，重新裝進它的工作記憶體中讀一遍。
- 工作記憶體的大小：這個工作記憶體的最大容量上限，就是 Context Window。
- 計算單位：上下文窗口不以「字數」或「字元數」計算，而是以 Token（AI 的基本語意單位，一個中文字約等於 1.5~2 個 Token，一個英文單字約為 0.75 個 Token）來計量。
如果你的對話長度（歷史對話 + 新問題 + AI 已產生的回答）超出了這個 Context Window 的上限，AI 就會像電腦記憶體不足一樣，自動將最前面的對話抹除遺忘，這就是為什麼有時候聊到最後，AI 會忘記你在對話最開頭設定的角色或規則。
---
2026 主流 AI 模型 Context Window 大比拼
在 2026 年，大模型的上下文窗口經歷了爆炸性成長：
| 模型名稱 | 上下文窗口大小 (Token) | 約可容納的中文字數 | 典型應用場景 |
| Google Gemini Pro 2.0 | 2,000,000 (200萬) | 約 150 萬字 | 分析 2 小時影片、讀取整本會計年報 |
| Kimi K2 Thinking | 2,000,000 (200萬) | 約 150 萬字 | 長篇論文交叉審查、超長對話記錄 |
| Qwen 3.7 Max | 1,000,000 (100萬) | 約 75 萬字 | 全代碼庫 (Repository) 自動化 Debug |
| Claude 3.5 Sonnet | 200,000 (20萬) | 約 15 萬字 | 單個中型專案重構、長篇合約審核 |
| GPT-4o | 128,000 (12.8萬) | 約 9 萬字 | 日常事務諮詢、簡單多檔案分析 |
---
長上下文窗口的兩大潛在陷阱
雖然「百萬 Token 窗口」聽起來非常強大，但開發者與企業在實際調用 API 時，必須防範以下兩個硬傷：
1. 成本飆升 (The Token Cost Avalanche)
API 的計費方式是：每次請求都要重新計算所有輸入 Token 的價格。- 如果您上傳了 100 萬 Token 的代碼庫給 AI。
- 第一輪對話：輸入 100 萬 Token，API 收費一次。
- 第二輪對話：AI 需要把（100 萬 Token + 第一輪對話 + 第二輪問題）全部重新讀取一遍。這意味著第二輪對話你又要支付 100 萬以上的 Token 費用。
- 解決方案：企業級開發必須啟用 Prompt Cache（提示詞緩存） 策略，將靜態大文件快取在伺服器上，否則算力帳單會迅速破產。
2. 「大海撈針」失誤 (Lost in the Middle)
AI 雖然可以吃下 100 萬字的文檔，但不代表它對文檔中每一句話的記憶力都一樣好。 評測顯示，大模型對文檔的開頭 (Beginning) 和結尾 (End) 的記憶力最強，而藏在中間 (Middle) 的細節，召回率 (Recall) 往往會出現斷崖式下跌，甚至降至 70% 以下。- 建議：如果需要對大量歷史檔案進行高精度的資訊查詢，建議結合 RAG (檢索增強生成) 架構，先用向量資料庫過濾出最相關的段落，再塞給 AI，而不是一股腦把 100 萬字全部倒進上下文窗口中。