上下文視窗對比：10 款 AI 程式設計工具實測（2026）

「Gemini 2.5 Pro 上下文 1M token，是 Claude Sonnet 200K 的 5 倍——所以它寫程式碼更強？」

這是新手最容易踩的坑。紙面上下文視窗 ≠ 實際可用上下文——AI 程式設計工具的真實工作體驗，是「模型上下文 × agent loop 的 compact 策略 × attention 衰減」三者的乘積。

這一篇用 10 款工具的真實工作場景對比上下文視窗，告訴你 1M 跟 200K 的差距實際有多大。

本章目標：你會按真實工作流的上下文需求選工具，不被紙面數字誤導。

1. 上下文視窗到底裝什麼

flowchart TB
  Window["上下文視窗（200K - 1M token）"] --> A["你的 prompt<br/>（幾百 token）"]
  Window --> B["專案記憶<br/>CLAUDE.md / AGENTS.md / rules<br/>（幾千 token）"]
  Window --> C["agent 讀進來的檔案<br/>（幾萬 - 幾十萬 token）"]
  Window --> D["agent 自己的思考 / 輸出<br/>（幾千 - 幾萬 token）"]
  Window --> E["歷史對話<br/>（每次問答累加）"]
  Window --> F["MCP / 工具呼叫結果<br/>（命令輸出、網頁抓取）"]

200K 上下文典型分配：

專案記憶：5K
目前 task 描述：1K
agent 讀進來的相關檔案：50-150K
agent 思考 + 輸出：20-50K
工具呼叫結果：累加

實際工程中，agent 跑長任務，上下文很快被填滿——這時候模型要麼開始忘前面的內容，要麼 agent loop 觸發 compact（自動摘要老的部分給新的騰空間）。

2. 10 款工具的預設上下文

工具	預設模型	標稱上下文	實際可用*	長任務 compact 策略
Claude Code	Claude Sonnet 4	200K	160-180K	自動 compact（`/compact` 觸發）
Codex CLI	GPT-5 / Codex	400K	320-360K	session 切換 + AGENTS.md 跨 session 持久化
Cursor	多家 router	200K-1M（視模型）	視模型	Composer 多步 + 檔案 indexing
GitHub Copilot	GPT-5 / Claude / Gemini	200K-1M（視模型）	視模型	session-level compact
Gemini CLI	Gemini 2.5 Pro	1M	900K-1M	大視窗 + 不需要頻繁 compact
Windsurf	SWE-1.5 / GPT / Claude 等	200K-1M（視模型）	視模型	Memories 跨 task 持久化
Antigravity	Gemini 系	1M	900K-1M	大視窗 + Artifacts
OpenCode	視你接的 LLM	視模型（最大 1M）	視模型	多 provider 切換
Hermes Agent	視你接的 LLM	視模型	視模型	記憶系統 + recall
OpenClaw	視你接的 LLM	視模型	視模型	多 agent 協作分擔上下文

*實際可用：扣除專案記憶、系統 prompt、工具呼叫開銷等之後，留給"讀程式碼 + 思考"的真實空間。

3. 1M 上下文 vs 200K 實際差異

舉三個具體任務看差距。

任務 A · 讀一箇中型專案全程式碼 + 全域 refactor

中型專案（約 50K 行程式碼 ≈ 250K-400K token）：

Gemini CLI / Antigravity（1M）：一次性吃下整個專案，agent 全域把握，refactor 不掉資訊
Claude Code / Cursor（200K）：必須分批讀 + 自動 compact，可能遺漏跨檔案依賴
Codex（400K）：夠裝大部分中型專案，少數巨大專案需要分批

這個任務上 Gemini CLI 真有優勢——但代價是 Google 生態繫結 + 模型口味不一定對你胃口。

任務 B · 修一個 bug

bug 修復任務（涉及 3-10 個檔案，約 5K-30K token）：

200K 上下文夠裝 10 倍冗餘——200K 跟 1M 在這個任務上沒有差距
決定性因素是 agent loop 工程質量（找檔案準不準、推理深不深）

任務 C · 跑 4 小時的長 refactor

長任務（agent 持續推進 4 小時，累加思考 + 工具呼叫約 300-500K token）：

200K 上下文：必須頻繁 compact，老的細節會丟
400K（Codex）：能裝更長，但仍需中途 compact
1M（Gemini / Antigravity）：幾乎不需要 compact，長任務連續性最好

實際工程經驗：短任務（< 30 分鐘）所有工具差距小；長任務（> 2 小時）1M 視窗優勢顯著。如果你每週跑 1-2 次長任務，上下文視窗是重要選型維度。

4. 為什麼上下文視窗不是唯一決定因素

flowchart LR
  A["紙面上下文"] --> B["實際可用"]
  B --> C["attention 衰減<br/>（視窗越大，遠處 token 關注度越弱）"]
  C --> D["agent loop 工程<br/>（compact 觸發時機、檔案優先順序）"]
  D --> E["模型自身能力<br/>（推理 / 程式設計 / 工具呼叫）"]
  E --> F["真實工作體驗"]

1M 上下文的代價：