上下文視窗管理：50次開發實戰教會我的AI開發心法

我測量了50次Claude Code開發工作階段的token消耗量。模式非常一致：輸出品質大約在上下文使用率達60%時開始下降，遠在硬性限制觸發壓縮之前。¹

TL;DR

上下文視窗耗盡會無聲地降低AI程式碼撰寫品質。在追蹤50次建構我的Claude Code基礎設施和部落格品質系統的工作階段後，我發現了三種能在數小時工作階段中維持輸出品質的模式：每完成一個子任務就主動壓縮、使用檔案系統記憶來跨越上下文邊界持久化資訊，以及透過子代理委派保持主要上下文精簡。關鍵洞察：將上下文視窗視為稀缺資源，而非無底洞的對話串。

品質下降的真實樣貌

每次檔案讀取、工具輸出和對話回合都會消耗token。單次大型檔案讀取（2,000行）可消耗15,000至20,000個token。在讀取10個檔案並執行數個指令後，上下文視窗中的工具輸出已遠多於實際指令。²

這種下降是微妙的。Claude不會宣布「我的上下文已使用80%」。取而代之的是，模型開始： - 遺忘20分鐘前建立的指令 - 重複三輪前已被拒絕的建議 - 忽略對話早期建立的模式 - 產出連貫性較低的多檔案變更

我在建構審議系統時注意到這個模式。一個工作階段一開始能精確地跨8個Python模組進行多檔案編輯，到了90分鐘時卻退化成只關注單一檔案的隧道視野。代理不再參照它先前讀取的架構，因為那些上下文已被壓縮掉了。

策略1：主動壓縮

Claude Code的/compact指令會摘要對話並釋放上下文空間。系統會保留關鍵決策、檔案內容和任務狀態，同時丟棄冗長的工具輸出。³

何時壓縮： - 完成一個明確的子任務後（功能實作完成、錯誤修復完成） - 開始處理程式碼庫的新區域之前 - 當Claude開始重複或遺忘先前的上下文時

在密集工作階段中，我大約每25至30分鐘壓縮一次。在審議基礎設施建構期間（9份PRD、3,455行Python），我在每份PRD完成後進行壓縮。每次壓縮都保留了架構決策，同時為下一個實作階段釋放上下文。

策略2：檔案系統即記憶

跨上下文邊界最可靠的記憶存在於檔案系統中。Claude Code在每次工作階段開始時和每次壓縮後都會讀取CLAUDE.md和記憶檔案。⁴

我的.claude/目錄作為結構化的記憶宮殿：

~/.claude/
├── configs/           # 14 JSON configs (thresholds, rules, budgets)
│   ├── deliberation-config.json
│   ├── recursion-limits.json
│   └── consensus-profiles.json
├── hooks/             # 95 lifecycle event handlers
├── skills/            # 44 reusable knowledge modules
├── state/             # Runtime state (recursion depth, agent lineage)
├── handoffs/          # 49 multi-session context documents
├── docs/              # 40+ system documentation files
└── projects/          # Per-project memory directories
    └── {project}/memory/
        └── MEMORY.md  # Always loaded into context

MEMORY.md檔案捕捉跨工作階段的錯誤、決策和模式。目前它記錄了54個有跨領域學習模式的失敗案例。當我發現((VAR++))在bash中搭配set -e使用且VAR為0時會失敗，我會記錄下來。三個工作階段後，當我在Python中遇到類似的整數邊界情況時，MEMORY.md的條目會浮現這個模式。⁵

跨領域的複合效應： 一個來自hook開發的bash跳脫錯誤，啟發了我Python部落格檢查器的正則表達式改進。一個CSS token缺口（--spacing-2xs不存在）觸發了對所有自訂屬性參照的系統性審查。每個條目都連結了原本會各自孤立在個別工作階段上下文中的領域。

策略3：工作階段交接

對於跨越多個工作階段的任務，我會建立交接文件來捕捉完整狀態：

## Handoff: Deliberation Infrastructure PRD-7
**Status:** Hook wiring complete, 81 Python unit tests passing
**Files changed:** hooks/post-deliberation.sh, hooks/deliberation-pride-check.sh
**Decision:** Placed post-deliberation in PostToolUse:Task, pride-check in Stop
**Blocked:** Spawn budget model needs inheritance instead of depth increment
**Next:** PRD-8 integration tests in tests/test_deliberation_lib.py

我的~/.claude/handoffs/目錄保存了49份來自多工作階段任務的交接文件。使用claude -c（繼續）啟動新工作階段或讀取交接文件，能以最少的token成本為後續工作階段提供完整的上下文。⁶

交接模式在審議系統建構期間救了我一命。PRD-4（遞迴防護擴充）需要理解PRD 1-3的決策。沒有交接文件，新的工作階段需要重新讀取所有修改過的檔案。有了交接文件，工作階段一開始就具備架構上下文，直接進入實作。

策略4：子代理委派

子代理在獨立的上下文視窗中運行。將研究或審查任務委派給子代理，可以為實作工作保留主工作階段的上下文。⁷

我的遞迴防護系統自動管理這一切：

# From recursion-guard.sh - spawn budget enforcement
MAX_DEPTH=2
MAX_CHILDREN=5
DELIB_SPAWN_BUDGET=2
DELIB_MAX_AGENTS=12

每個子代理回傳摘要而非原始輸出，保持主要上下文精簡。在部落格文章改寫期間，我將探索任務（蒐集CSS資料、讀取hook程式碼、調查目錄結構）委派給子代理。主要上下文專注於寫作，而子代理處理研究工作。

生成預算是用慘痛教訓換來的：一個早期沒有限制的工作階段產生了遞迴子代理，每個子代理又產生更多子代理。遞迴防護hook現在透過安全的整數驗證和設定驅動的預算來強制執行深度限制。⁸

我從反面教材中學到的

只需要10行卻讀取整個檔案。 在我使用Claude Code的早期，我會為了一個函式讀取整個2,000行的檔案。使用行偏移量：Read file.py offset=100 limit=20每次讀取可節省15,000+個token。

在上下文中保留冗長的錯誤輸出。 在除錯生成預算問題後，我的上下文中保留了40多個來自失敗迭代的堆疊追蹤。修復錯誤後的一次/compact就釋放了那些無用的負擔。

每次工作階段開始都讀取每個檔案。 我最初的工作階段會預載8到10個檔案「作為上下文」。現在我讓Claude Code的glob和grep工具按需尋找相關檔案，節省了100,000+個token的不必要預載。

關鍵要點

給個人開發者： - 在每個子任務完成後主動壓縮，而不是等到Claude強制壓縮；以25至30分鐘的間隔主動壓縮可維持輸出品質 - 隨著工作階段進展，將關鍵決策寫入檔案系統記憶檔案；我的MEMORY.md有54個條目，跨越數百個工作階段持續發揮作用 - 使用子代理處理會污染主要上下文的研究任務；一個5檔案的研究查詢在主要上下文中耗費75,000+個token，但透過子代理只需500個token的摘要

給團隊： - 為多工作階段任務標準化交接文件格式；我的49份交接文件都遵循相同的狀態/檔案/決策/阻礙/下一步結構 - 設定專案層級的CLAUDE.md檔案，讓架構上下文自動載入每個工作階段——從這些token管理原則演化而來的7層層級結構，請參閱上下文就是架構

常見問題

LLM上下文視窗被填滿後會發生什麼事？

當上下文視窗接近容量上限（使用率約95%）時，Claude Code會觸發自動壓縮：將對話記錄摘要化，騰出空間。不過輸出品質在壓縮觸發之前就已經開始下滑。在我對50次工作階段的測量中，品質下降大約從上下文使用率60%時開始：模型會忘記先前的指令、重複已被否決的建議，跨檔案的修改也變得不再連貫。而且每次壓縮都會丟棄可能含有重要決策的上下文，因此壓縮次數越少，工作階段就越連貫。

在長時間的工作階段中如何有效管理LLM上下文？

四種策略能在長達數小時的工作階段中維持輸出品質。每完成一個子任務就主動壓縮（每25~30分鐘一次），可以避免品質悄悄下滑。以檔案系統為基礎的記憶（CLAUDE.md、MEMORY.md、交接文件）讓關鍵狀態跨越上下文邊界保存下來。子代理委派把研究任務移到獨立的上下文視窗，只回傳摘要而非原始輸出。搭配行位移的精準讀取（Read file.py offset=100 limit=20），比起載入整份檔案，每次可省下15,000以上的token。三層壓縮框架請參閱上下文就是新的記憶。

Claude Code的上下文壓縮是什麼？

上下文壓縮是Claude Code內建的機制，會在上下文視窗接近容量上限時，將對話記錄摘要化。/compact指令可手動觸發，自動壓縮則在使用率約95%時啟動。壓縮會保留關鍵決策、檔案內容與任務狀態，同時捨棄冗長的工具輸出。連續3次壓縮失敗後，斷路器會中止流程，避免陷入無限重試的迴圈。在這道防護出現之前，有1,279個工作階段連續失敗50次以上，每天浪費約25萬次API呼叫，這一點記錄在原始碼外流分析中。

高生產力的AI開發需要多少token？

200K的上下文視窗只要管理得當就已足夠。我經過壓縮的設定讓視窗約78%（156,000 token）保持可用於推理，在觸及壓縮門檻前可進行40~60輪高效率的往返。未經壓縮的設定只留下26%（53,000 token）給推理，15~20輪之後就會觸發壓縮。視窗實際好不好用，取決於裝進去的內容更甚於它本身的大小：壓縮得宜的200K視窗，勝過塞滿未壓縮工具輸出的假想500K視窗。壓縮系統提示、以CLI為優先的工具架構，以及啟動全新的代理，是效益最高的幾項最佳化。

交接文件對跨工作階段的AI開發有什麼幫助？

交接文件為下一次工作階段記錄任務的完整狀態：目前進度、變更過的檔案、已做出的關鍵決策、阻礙項目與後續步驟。新的工作階段只要先讀交接文件，就能以極低的token成本（通常不到500 token）取得完整的架構上下文，不必讓代理重新讀過所有變更的檔案。我的49份交接文件都遵循相同的Status/Files/Decision/Blocked/Next結構。在建構審議系統的過程中，交接文件讓每個PRD的工作階段都能帶著先前的架構決策啟動，而不必背負更早PRD的對話記錄。

參考資料