在使用 Claude Code 進行開發時，你可能遇過這些情況：對話進行到一半，Claude 突然「忘記」了先前的討論內容；或是回應速度明顯變慢；甚至出現「context window 已滿」的警告。這些都與 Context Window（上下文視窗） 的管理有關。本文將深入解析 Context Window 的運作機制，並提供實用的管理策略。
🎯 什麼是 Context Window？
基本概念
Context Window 是 AI 模型在單次對話中能「記住」的資訊總量。可以把它想像成模型的「工作記憶體」：
┌─────────────────────────────────────────────────────┐
│ Context Window (上下文視窗) │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 對話歷史 │ │
│ │ ├─ 使用者訊息 1 │ │
│ │ ├─ Claude 回應 1 │ │
│ │ ├─ 使用者訊息 2 │ │
│ │ ├─ Claude 回應 2 │ │
│ │ └─ ... │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 工具呼叫結果 │ │
│ │ ├─ Read tool: file1.ts 內容 │ │
│ │ ├─ Grep tool: 搜尋結果 │ │
│ │ └─ Bash tool: 執行輸出 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────┐ │
│ │ 系統提示 (System Prompt) │ │
│ │ └─ Claude Code 的基本指令和能力說明 │ │
│ └────────────────────────────────────────────┘ │
│ │
│ 總容量: 200,000 tokens (Claude Sonnet 4.5) │
└─────────────────────────────────────────────────────┘
Token 計算方式
Context Window 的大小以 tokens 為單位衡量，而非字元數：
Token 計算範例：
英文：
"Hello, world!" = 約 3 tokens
"The quick brown fox jumps" = 約 6 tokens
中文：
"你好世界" = 約 4-6 tokens（中文通常 1 字 = 1-2 tokens）
"快速的棕色狐狸跳躍" = 約 10-14 tokens
程式碼：
const x = 10; = 約 5 tokens
function hello() { return "world"; } = 約 10 tokens
檔案內容：
一個 100 行的 TypeScript 檔案 = 約 500-1500 tokens
一個 1000 行的檔案 = 約 5000-15000 tokens
【估算法則】
英文: 1 token ≈ 4 字元 ≈ 0.75 單字
中文: 1 token ≈ 1-2 字元
程式碼: 1 token ≈ 3-5 字元（取決於語言和複雜度）
Claude Code 的 Context Window 規格
| 模型 | Context Window | 輸出限制 | 適用情境 |
|---|---|---|---|
| Claude Sonnet 4.5 | 200,000 tokens | 8,192 tokens | 一般開發任務（預設） |
| Claude Opus 4.5 | 200,000 tokens | 16,384 tokens | 複雜任務、需要長篇輸出 |
| Claude Haiku 3.5 | 200,000 tokens | 8,192 tokens | 簡單快速任務、成本優化 |
實際可用空間分配：
200,000 tokens Context Window 的典型分配：
┌─────────────────────────────────────────┐
│ 系統提示: ~5,000 tokens (2.5%) │
├─────────────────────────────────────────┤
│ 對話歷史: ~50,000 tokens (25%) │
│ • 前 10-20 輪對話 │
│ • 包含使用者訊息和 Claude 回應 │
├─────────────────────────────────────────┤
│ 工具結果: ~100,000 tokens (50%) │
│ • 檔案內容 │
│ • 搜尋結果 │
│ • 命令執行輸出 │
├─────────────────────────────────────────┤
│ 輸出空間: ~8,192 tokens (4%) │
│ • Claude 的回應 │
├─────────────────────────────────────────┤
│ 緩衝空間: ~36,808 tokens (18.5%) │
│ • 預留給額外需求 │
└─────────────────────────────────────────┘
🔄 Context Window 的運作流程
完整的請求-回應週期
┌──────────────────────────────────────────────────────┐
│ 1. 使用者發送訊息 │
│ "讀取 src/app.ts 並修復 bug" │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 2. Context 組裝 │
│ ┌────────────────────────────────┐ │
│ │ 系統提示 (5K tokens) │ │
│ ├────────────────────────────────┤ │
│ │ 對話歷史 (20K tokens) │ │
│ │ • 前 10 輪對話 │ │
│ ├────────────────────────────────┤ │
│ │ 新訊息 (0.05K tokens) │ │
│ └────────────────────────────────┘ │
│ 總計: 25.05K tokens │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 3. Claude 分析並決定行動 │
│ "需要讀取檔案才能修復 bug" │
│ → 呼叫 Read tool │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 4. 工具執行並返回結果 │
│ Read tool 讀取 src/app.ts │
│ 返回檔案內容 (3K tokens) │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 5. Context 更新 │
│ ┌────────────────────────────────┐ │
│ │ 系統提示 (5K tokens) │ │
│ ├────────────────────────────────┤ │
│ │ 對話歷史 (20K tokens) │ │
│ ├────────────────────────────────┤ │
│ │ 新訊息 (0.05K tokens) │ │
│ ├────────────────────────────────┤ │
│ │ Tool 結果 (3K tokens) │ │
│ │ • src/app.ts 內容 │ │
│ └────────────────────────────────┘ │
│ 總計: 28.05K tokens │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 6. Claude 生成回應 │
│ 分析 bug、提供修復方案 │
│ 回應內容 (1K tokens) │
└────────────────────┬─────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────────────┐
│ 7. 最終 Context 狀態 │
│ ┌────────────────────────────────┐ │
│ │ 系統提示 (5K) │ │
│ │ 對話歷史 (20K) │ │
│ │ 使用者訊息 (0.05K) │ │
│ │ Tool 結果 (3K) │ │
│ │ Claude 回應 (1K) │ │
│ └────────────────────────────────┘ │
│ 總計: 29.05K tokens │
│ │
│ ← 這個狀態會保留到下一輪對話 │
└──────────────────────────────────────────────────────┘
Context 累積範例
讓我們看一個實際的對話如何累積 context：
【輪次 1】使用者: "讀取 package.json"
├─ Context: 5K (系統提示)
├─ 新增: 0.01K (使用者訊息)
├─ Tool: 1K (package.json 內容)
├─ 回應: 0.5K (Claude 回應)
└─ 總計: 6.51K tokens
【輪次 2】使用者: "讀取 tsconfig.json"
├─ Context: 6.51K (前一輪全部內容)
├─ 新增: 0.01K (使用者訊息)
├─ Tool: 0.5K (tsconfig.json 內容)
├─ 回應: 0.5K (Claude 回應)
└─ 總計: 7.52K tokens
【輪次 3】使用者: "讀取 src/index.ts"
├─ Context: 7.52K (前兩輪全部內容)
├─ 新增: 0.01K (使用者訊息)
├─ Tool: 5K (index.ts 內容 - 較大的檔案)
├─ 回應: 1K (Claude 回應)
└─ 總計: 13.53K tokens
【輪次 4】使用者: "讀取 src/utils/*.ts 所有檔案"
├─ Context: 13.53K (前三輪全部內容)
├─ 新增: 0.02K (使用者訊息)
├─ Tool: 15K (多個 utils 檔案內容)
├─ 回應: 2K (Claude 回應)
└─ 總計: 30.55K tokens
【輪次 5】使用者: "讀取整個 src/ 目錄"
├─ Context: 30.55K (前四輪全部內容)
├─ 新增: 0.02K (使用者訊息)
├─ Tool: 50K (整個 src/ 目錄的檔案)
├─ 回應: 3K (Claude 回應)
└─ 總計: 83.57K tokens ⚠️
⚠️ 注意：Context 在快速累積！
再讀取幾個大檔案就可能接近上限。
🚨 Context Window 滿了會發生什麼？
自動摘要機制
當 context 接近上限時，Claude Code 會自動觸發摘要機制：
┌───────────────────────────────────────────────────────┐
│ Context 使用率: 85% (170K / 200K tokens) │
│ ⚠️ 觸發自動摘要 │
└───────────────────────────────────────────────────────┘
│
▼
┌───────────────────────────────────────────────────────┐
│ 摘要處理流程 │
│ │
│ 1. 識別可摘要的內容 │
│ ├─ 舊的對話輪次（保留最近 10 輪） │
│ ├─ 已讀取但不再需要的檔案內容 │
│ └─ 長篇的工具輸出 │
│ │
│ 2. 生成摘要 │
│ 原始對話（15K tokens）: │
│ 使用者: "讀取 src/database/*.ts 並解釋架構" │
│ Claude: [讀取 5 個檔案，提供詳細說明...] │
│ │
│ 摘要後（2K tokens）: │
│ 使用者詢問資料庫架構。 │
│ 已讀取並分析 src/database/ 的 5 個檔案。 │
│ 架構使用 Prisma ORM，包含 User、Post、 │
│ Comment 等模型。 │
│ │
│ 3. 更新 Context │
│ ├─ 移除原始詳細內容 │
│ ├─ 插入簡潔摘要 │
│ └─ 保留重要資訊供後續參考 │
└───────────────────────────────────────────────────────┘
摘要的影響
✅ 優點：
- 釋放 context 空間，可以繼續對話
- 保留關鍵資訊
- 自動化處理，無需人工介入
❌ 缺點：
- 細節資訊可能遺失
- 需要重新讀取檔案來回憶細節
- 可能影響回答的精確度
實際影響範例：
【摘要前】- Context: 150K tokens
使用者: "在 src/auth/login.ts:45 的那個 validatePassword
函式，我們之前討論過要加入 rate limiting"
Claude: "是的，我記得在第 45 行的 validatePassword 函式
中，我們討論過要加入 rate limiting 機制。
具體來說，要在 Redis 中記錄失敗次數..."
【摘要後】- Context: 80K tokens
使用者: "在 src/auth/login.ts:45 的那個 validatePassword
函式，我們之前討論過要加入 rate limiting"
Claude: "我看到 validatePassword 函式，但我需要重新讀取
src/auth/login.ts 來確認之前討論的具體內容。
[呼叫 Read tool]"
⚠️ 摘要後失去了細節記憶，需要重新讀取檔案
💡 Context Window 管理策略
策略 1: 分階段處理大型任務
❌ 不好的做法：一次讀取所有檔案
"讀取整個專案的所有 TypeScript 檔案，
然後幫我找出所有的 bug 並修復"
問題：
• 可能有上百個檔案，輕易超過 context limit
• 無法聚焦在真正有問題的地方
• 即使有自動摘要，也會失去大部分細節
✅ 好的做法：分階段深入
階段 1: 高層級掃描
"使用 Glob 列出 src/ 下所有的 .ts 檔案"
→ 得到檔案列表（很少的 tokens）
階段 2: 識別關鍵區域
"使用 Grep 在這些檔案中搜尋 'TODO' 或 'FIXME'"
→ 定位需要注意的區域
階段 3: 深入分析
"讀取 src/auth/login.ts 和 src/utils/validation.ts
這兩個有 FIXME 註解的檔案"
→ 只讀取真正需要的檔案
階段 4: 修復問題
"修復 login.ts 中的 rate limiting 問題"
→ 聚焦在單一問題
階段 5: 驗證
"執行 npm test 驗證修復"
→ 確認修復有效
【Token 使用對比】
一次性方法: ~180K tokens (接近上限)
分階段方法: ~30K tokens (仍有大量空間)
策略 2: 選擇性讀取檔案
使用 limit 和 offset 參數：
1// ❌ 讀取整個大檔案
2"讀取 src/data/large-config.json"
3// 可能是 50K tokens
4
5// ✅ 只讀取需要的部分
6"讀取 src/data/large-config.json 的前 100 行"
7"讀取 src/data/large-config.json，從第 500 行開始，讀取 50 行"
8// 只用 2-3K tokens
9
10// ✅ 搜尋特定內容
11"在 src/data/large-config.json 中搜尋 'databaseConfig' 相關的設定"
12// 只返回相關部分
實際範例：
情境：需要修改大型設定檔中的某個設定
❌ 不好的做法：
"讀取 config/production.json"
[讀取整個 10,000 行的設定檔 = 40K tokens]
✅ 好的做法：
Step 1: "使用 Grep 在 config/production.json 中
搜尋 'redis' 相關設定"
[只返回相關的 10 行 = 0.5K tokens]
Step 2: "讀取 config/production.json 的第 450-460 行
（包含 redis 設定的區域）"
[只讀取需要的 10 行 = 0.5K tokens]
Step 3: "修改這 10 行中的 redis.maxConnections 從 50 改為 100"
[精確修改 = 0.1K tokens]
Token 節省: 40K → 1.1K tokens (節省 97%！)
策略 3: 及時清理不需要的資訊
主動開啟新對話：
何時應該開啟新對話？
✅ 適合開新對話：
1. 任務完全改變方向
舊對話: "實作使用者認證系統"
新任務: "建立資料視覺化儀表板"
→ 開新對話，舊的 auth 資訊不再需要
2. Context 使用率 > 70%
目前: 140K / 200K tokens
→ 開新對話，避免頻繁觸發摘要
3. 已完成一個里程碑
"使用者認證功能已完成、測試通過、部署上線"
→ 開新對話開始下一個功能
4. 對話變得混亂
Claude 開始「忘記」先前的討論
→ 開新對話，重新整理思緒
❌ 不適合開新對話：
1. 正在進行中的任務
2. 需要參考先前討論的內容
3. 剛開始不久（< 30K tokens）
新對話時如何提供背景：
1情境：在新對話中繼續先前的工作
2
3✅ 提供簡潔的背景摘要：
4
5"我正在實作一個電商網站的購物車功能。
6
7【已完成】
8- 資料庫 Schema（Cart、CartItem 模型）
9- 基本的 CRUD API endpoints
10- 前端購物車 UI 元件
11
12【目前狀態】
13- Cart API 在 src/api/cart/
14- 前端元件在 src/components/Cart/
15- 使用 React + TypeScript + Zustand
16
17【接下來要做】
18- 實作優惠券折扣邏輯
19- 加入庫存檢查
20- 整合金流 API
21
22相關檔案：
23- src/api/cart/cartController.ts
24- src/services/discountService.ts
25- src/types/cart.ts"
策略 4: 使用外部文檔和註解
善用 README 和文檔：
1與其每次對話都重複說明專案背景，
2不如維護良好的文檔，讓 Claude 讀取
3
4// README.md
5# 電商平台專案
6
7## 技術棧
8- Frontend: React 18 + TypeScript + Vite
9- Backend: Node.js + Express + PostgreSQL
10- State: Zustand
11- Styling: Tailwind CSS
12
13## 專案結構
14src/
15├── api/ # API endpoints
16├── components/ # React 元件
17├── services/ # 業務邏輯
18├── stores/ # Zustand stores
19└── types/ # TypeScript 型別
20
21## 開發規範
22- 使用 ESLint + Prettier
23- 所有 API 需要單元測試
24- 元件需要 Storybook stories
25
26【使用方式】
27每次新對話開始時：
28"讀取 README.md 了解專案背景，然後..."
29
30好處：
31• 一致的專案資訊（不會因對話而異）
32• 節省 context（不用每次重複說明）
33• 容易更新（改 README 即可）
在程式碼中加入有用的註解：
1// ✅ 好的註解：提供 Claude 需要的背景資訊
2
3/**
4 * 使用者認證服務
5 *
6 * 【重要】此服務使用 JWT token 進行認證
7 * Token 有效期: 24 小時
8 * Refresh token 有效期: 30 天
9 *
10 * 【注意】密碼使用 bcrypt 雜湊（cost factor = 12）
11 * 不要降低 cost factor，會影響安全性
12 *
13 * 【相依】
14 * - Redis: 儲存 refresh tokens
15 * - SendGrid: 發送驗證郵件
16 */
17export class AuthService {
18 // ...
19}
20
21// ✅ 標記已知問題或需要改進的地方
22// TODO: 加入 rate limiting 防止暴力破解
23// FIXME: 登入失敗後沒有正確清理 session
24// OPTIMIZE: 可以使用 Redis 快取使用者資訊
25
26【好處】
27當 Claude 讀取這些檔案時，立即了解：
28• 系統如何運作
29• 需要注意的限制
30• 已知的問題和改進方向
策略 5: 使用 Sub-agents 分散 Context
概念：不同任務使用不同的 agent
┌────────────────────────────────────────────────────┐
│ 主要對話 Context (50K tokens) │
│ • 整體專案討論 │
│ • 架構決策 │
└────────────────────────────────────────────────────┘
│
│ 需要探索程式碼
▼
┌────────────────────────────────────────────────────┐
│ Explore Agent (獨立 Context: 30K tokens) │
│ • 搜尋所有使用 'useEffect' 的地方 │
│ • 分析依賴關係 │
│ • 回報發現結果 │
└────────────────────────────────────────────────────┘
│
│ 完成後返回簡潔摘要給主要對話
▼
┌────────────────────────────────────────────────────┐
│ 主要對話 Context (52K tokens) │
│ • 收到 Explore Agent 的摘要 (2K tokens) │
│ • 基於發現結果繼續討論 │
└────────────────────────────────────────────────────┘
【好處】
• 主要對話的 Context 保持簡潔
• 探索任務在獨立空間進行
• 只傳回必要的摘要資訊
實際使用範例：
情境：需要重構一個大型專案
主要對話: "我要重構 src/components/ 下的所有元件，
讓它們使用 TypeScript 並加入 prop types"
【問題】如果直接在主要對話中執行：
• 需要讀取上百個元件檔案
• Context 會快速爆滿
• 難以追蹤進度
【解決】使用分層策略：
Step 1 (主要對話): 規劃整體策略
"使用 Glob 找出所有元件檔案，
然後規劃重構順序"
Step 2 (Explore Agent): 深入分析
"啟動 Explore Agent 分析 src/components/
目錄，識別哪些元件最需要重構"
→ Agent 在獨立 Context 中分析
→ 返回優先順序清單
Step 3 (主要對話): 批次處理
"根據 Agent 的建議，先重構 UserCard,
ProductCard, CommentCard 這三個高優先級元件"
Step 4 (General Agent): 執行重構
每個元件使用獨立的 Agent 處理
→ 各自在獨立 Context 中工作
→ 互不干擾
【Result】
主要對話 Context: ~40K tokens
每個 Agent Context: ~20K tokens
總計可處理的資訊量大幅增加！
📊 Context 使用率監控
如何知道 Context 使用狀況？
Claude Code 會在 CLI 中顯示 context 使用資訊：
1# 每次對話後會顯示
2Token usage: 45230/200000; 154770 remaining
3
4解讀：
5• 已使用: 45,230 tokens (22.6%)
6• 剩餘: 154,770 tokens (77.4%)
7• 總容量: 200,000 tokens
8
9【安全閾值】
10綠色 (< 50%): 安全，可以繼續
11黃色 (50-80%): 注意，考慮優化
12紅色 (> 80%): 警告，即將觸發摘要
Context 健康檢查清單
1定期檢查你的對話狀態：
2
3☐ Context 使用率 < 70%
4☐ 對話輪次 < 30 輪
5☐ 已讀取的大檔案 < 5 個
6☐ Claude 能準確回憶先前討論的細節
7☐ 回應速度正常（< 10 秒）
8
9如果以上任一項不符合，考慮：
10• 開啟新對話
11• 使用 Sub-agent 分散任務
12• 移除不再需要的檔案內容
🎯 實戰案例分析
案例 1: 大型重構任務
**情境：**將一個 5000 行的 JavaScript 檔案重構為模組化的 TypeScript
❌ 錯誤做法：
使用者: "讀取 src/legacy/monolith.js 並將它
重構為 TypeScript 模組"
問題：
1. 5000 行的檔案 ≈ 25K tokens
2. 重構建議的回應 ≈ 10K tokens
3. 新的模組程式碼 ≈ 30K tokens
4. 一次對話就用掉 65K tokens！
5. 難以追蹤和驗證每個模組
✅ 正確做法：
Phase 1: 分析階段 (10K tokens)
"讀取 src/legacy/monolith.js 的前 200 行，
分析整體結構和主要功能"
Phase 2: 規劃階段 (5K tokens)
"基於分析，規劃如何拆分成模組：
- 列出主要功能區塊
- 建議模組結構
- 識別共用的工具函式"
Phase 3: 逐步重構 (每個模組 5-8K tokens)
"將 authentication 相關的功能（第 100-300 行）
提取到 src/auth/authService.ts"
"將 database 操作（第 500-800 行）
提取到 src/database/dbService.ts"
...逐一處理每個模組...
Phase 4: 整合測試 (10K tokens)
"執行測試確認所有模組正常運作"
【總 Token 使用】
分散到多個對話，每個對話 15-20K tokens
可以安全地完成整個重構，並保留詳細記錄
案例 2: Bug 調查
**情境：**生產環境出現神秘的記憶體洩漏
❌ 錯誤做法：
使用者: "我的 Node.js 應用程式有記憶體洩漏，
讀取所有檔案幫我找出問題"
問題：
• 讀取整個專案（可能 100+ 檔案）
• 超過 Context limit
• 無法聚焦在真正的問題區域
✅ 正確做法：
Step 1: 收集線索 (2K tokens)
"根據錯誤日誌，記憶體洩漏似乎與
WebSocket 連線有關"
Step 2: 定位區域 (3K tokens)
"使用 Grep 搜尋所有處理 WebSocket 的檔案"
→ 找到 3 個相關檔案
Step 3: 深入分析 (10K tokens)
"讀取這 3 個 WebSocket 相關檔案：
- src/websocket/server.ts
- src/websocket/handlers.ts
- src/services/connectionManager.ts"
Step 4: 診斷問題 (5K tokens)
"檢查這些檔案中是否有：
- 未正確關閉的連線
- 事件監聽器沒有清除
- 累積的資料結構"
Step 5: 修復驗證 (5K tokens)
"修復 connectionManager.ts 中的連線清理邏輯，
然後執行測試驗證"
【總 Token 使用】
25K tokens，聚焦且高效
案例 3: 新功能開發
**情境：**在現有專案中加入支付功能
✅ 最佳實踐流程：
═══════════════════════════════════════════════════
對話 1: 規劃和設計 (30K tokens)
═══════════════════════════════════════════════════
"我要加入 Stripe 支付功能到電商平台。
請先讀取 README.md 了解專案架構"
→ 討論架構設計
→ 規劃 API endpoints
→ 設計資料庫 schema
→ 選擇 Stripe SDK
【產出】
- 詳細的實作計畫文檔
- API 設計規格
- 資料庫 migration 腳本
═══════════════════════════════════════════════════
對話 2: 後端實作 (40K tokens)
═══════════════════════════════════════════════════
"根據我們的計畫（參考 docs/payment-plan.md），
實作後端 payment service"
→ 建立 PaymentService
→ 實作 Stripe 整合
→ 加入錯誤處理
→ 撰寫單元測試
【產出】
- src/services/paymentService.ts
- src/api/payment/
- tests/payment.test.ts
═══════════════════════════════════════════════════
對話 3: 前端整合 (35K tokens)
═══════════════════════════════════════════════════
"實作前端支付流程，整合剛才的 API"
→ 建立支付表單元件
→ 整合 Stripe Elements
→ 實作 3D Secure
→ 錯誤處理和 UX
【產出】
- src/components/Payment/
- src/hooks/usePayment.ts
═══════════════════════════════════════════════════
對話 4: 測試和部署 (25K tokens)
═══════════════════════════════════════════════════
"執行完整測試並準備部署"
→ 整合測試
→ E2E 測試
→ 安全性檢查
→ 部署檢查清單
【好處】
• 每個對話都聚焦在特定階段
• Context 保持清晰和可管理
• 可以隨時回顧每個階段的決策
• 出問題時容易定位
💡 進階技巧
技巧 1: 預先載入關鍵資訊
在對話開始時，一次性提供所有背景資訊：
"我要重構使用者認證系統。請先讀取以下檔案
了解目前實作：
必讀檔案：
- README.md (專案背景)
- src/api/auth/ (所有認證相關檔案)
- src/types/user.ts (型別定義)
- tests/auth.test.ts (現有測試)
讀取完後，請：
1. 總結目前的認證流程
2. 列出需要改進的地方
3. 提供重構建議"
【好處】
• Claude 一次讀取所有需要的檔案
• 後續討論可以參考這些內容
• 避免反覆讀取相同檔案
技巧 2: 使用「記憶點」
在關鍵決策點，明確記錄決定：
"記住：我們決定使用 JWT 而非 Session，
因為需要支援跨多個伺服器的水平擴展"
"記住：密碼雜湊使用 bcrypt，cost factor = 12"
"記住：API 版本為 v2，需要保持 v1 的向後相容"
【好處】
• 即使 Context 被摘要，關鍵決定會被保留
• 後續討論可以參考這些決定
• 避免重複討論已經決定的事項
技巧 3: 定期「存檔」重要資訊
將重要的討論結果寫入檔案：
"將我們剛才討論的 API 設計寫入
docs/api-design.md"
"將這個重構計畫保存到
docs/refactoring-plan.md"
【好處】
• 即使開啟新對話，資訊不會遺失
• 團隊成員可以看到決策過程
• 可以在新對話中快速重新載入背景
🎯 總結：Context Window 管理黃金法則
五大黃金法則
1️⃣ 分而治之
• 將大任務拆分成小任務
• 每個任務在獨立的階段完成
• 使用 Sub-agents 分散負載
2️⃣ 按需載入
• 只讀取真正需要的檔案
• 使用搜尋和過濾減少讀取量
• 利用 limit/offset 參數
3️⃣ 及時清理
• Context > 70% 時考慮開新對話
• 完成里程碑後重新開始
• 將重要資訊寫入文檔
4️⃣ 善用工具
• Grep 搜尋而非讀取整個檔案
• Glob 列出檔案而非探索目錄
• Sub-agents 處理複雜任務
5️⃣ 維護文檔
• 保持 README 更新
• 在程式碼中加入有用註解
• 記錄重要決策和計畫
Context 管理檢查清單
1每次開始新任務前檢查：
2
3計畫階段
4☐ 任務是否可以拆分成更小的步驟？
5☐ 需要讀取哪些檔案？（列出清單）
6☐ 是否需要所有檔案的完整內容？
7☐ 可以用搜尋替代讀取嗎？
8
9執行階段
10☐ 當前 Context 使用率 < 70%？
11☐ Claude 能記得之前的討論？
12☐ 回應速度正常？
13☐ 是否有不再需要的資訊可以清理？
14
15完成階段
16☐ 重要決策已記錄到文檔？
17☐ 下次對話需要哪些背景資訊？
18☐ 是否適合開啟新對話？
🚀 下一步行動
現在你已經深入理解 Context Window 的運作機制，可以採取以下行動提升開發效率：
1立即行動
2☐ 檢查目前對話的 Context 使用率
3☐ 為大型任務規劃分階段執行策略
4☐ 更新專案 README，提供清晰背景資訊
5☐ 在程式碼中加入關鍵註解
6
7持續優化
8☐ 追蹤 Context 使用模式
9☐ 識別經常需要的檔案，考慮預先載入
10☐ 建立專案的快速參考文檔
11☐ 與團隊分享 Context 管理策略
延伸閱讀：
標籤: #claude-code #context-window #對話管理 #效能優化 #AI開發
