上下文視窗（Context Window）是 AI 模型一次可以處理的 Token 上限。也就是模型「看到的東西」的總量——包括你輸入的 Prompt、之前的對話歷史、跟模型自己生成的回覆。超過這個上限，模型就會「忘記」之前的內容。
簡單比喻：上下文視窗就像是 AI 的「短期記憶容量」。如果視窗是 128K，就是 AI 最多記得 128,000 個 Token 的東西——再多就會像人類一樣，記得開頭跟結尾，但中間的細節就模糊了。
一次對話中，上下文視窗的容量被以下幾部分瓜分：
所以「128K 上下文」不是你可以輸入 128K 字——而是所有東西加起來不可以超過 128K。
| 模型 | 上下文視窗 | 大約中文字數 | 大約頁數 |
|---|---|---|---|
| GPT-4o | 128K Token | 9-10 萬字 | ~300 頁 |
| GPT-4o mini | 128K Token | 9-10 萬字 | ~300 頁 |
| Claude Opus 4.x | 200K Token | 14-15 萬字 | ~450 頁 |
| Claude Sonnet 4.x | 200K Token | 14-15 萬字 | ~450 頁 |
| Gemini 1.5/2.0 Pro | 1M+ Token | 70-75 萬字 | ~2000 頁 |
| Gemini Flash | 1M Token | 70-75 萬字 | ~2000 頁 |
數據來源：OpenAI、Anthropic、Google 官方文件（2026 年核實）。實際可用視窗可能因 API 設定而異。
如果你用 GPT-4o（128K 視窗）分析一份 50 頁的合約：
但如果是一份 500 頁的書（≈ 250,000 Token），就超過 128K 視窗，需要分段處理或者用 Gemini 1M+。
三種常見情況：
模型會自動「忘記」最舊的對話內容。你可能發現 AI 突然不記得你之前說過什麼，或者答非所問。
API 呼叫會返回 context_length_exceeded 錯誤，告訴你輸入太長。
即使未超出視窗，當上下文很長時，模型對中間部分的記憶跟理解會明顯下降。研究顯示，模型對開頭跟結尾的資訊記得最牢，中間的細節容易被忽略。這個叫「Lost in the Middle」現象。
不一定。大視窗有好處，但也有代價：
| 維度 | 小視窗（32K） | 大視窗（200K+） |
|---|---|---|
| 處理長文件 | ❌ 要分段 | ✅ 一次過 |
| 成本 | ✅ 便宜 | ❌ 貴（按 Token 收費） |
| 速度 | ✅ 快 | ❌ 慢 |
| 準確度 | ✅ 高（短上下文更精準） | ⚠️ 中間內容容易遺忘 |
| 適合場景 | 日常對話、寫作、翻譯 | 長文件分析、合約審閱 |
結論：大部分日常任務 32K-128K 已經足夠。只有真的需要處理成百頁文件時，才需要 200K 或 1M+。
✅ 正確：上下文視窗是「輸入 + 輸出 + 對話歷史」的總和。你可以輸入的字數 = 視窗大小 - 預留輸出空間 - 已有對話。
✅ 正確：不一定。1M 視窗的模型處理短任務時可能反而慢跟貴，而且「迷失中間」問題更嚴重。視乎任務選擇。
✅ 正確：不是。即使在視窗內，模型對中間內容的注意力都會下降。重要的東西要反覆強調或者放在顯眼位置。
A：上下文視窗（Context Window）是 AI 模型一次可以處理的 Token 上限，也就是模型「看到的東西」的總量——包括你輸入的 Prompt、之前的對話、跟模型生成的回覆。超過這個上限，模型就會「忘記」之前的內容。
A：128K Token 大約等於 9-10 萬個中文字，或者 9.6 萬個英文單字。足夠處理大約 300 頁書的內容。
A：2026 年主流模型中，Gemini 1.5/2.0 Pro 支援 1M+ Token（大約 75 萬字），Claude Opus/Sonnet 是 200K，GPT-4o 是 128K。但上下文越大，成本越高、速度越慢。
A：三種可能：1) 模型自動截斷最舊的內容（你會「失去」之前的對話）；2) 報錯說 context length exceeded；3) 模型品質下降，因為中間內容被遺忘（「迷失中間」問題）。
A：不一定。大視窗可以處理長文件，但成本更高、回應更慢，而且模型容易「迷失中間」——忘記上下文中間的內容。大部分日常任務 32K-128K 已經足夠。
A：1) 重要資訊放開頭跟結尾（模型記得最牢）；2) 長文件先摘要再餵入；3) 用 RAG 技術只擷取相關片段；4) 定期總結對話，避免無限累積。