Claude Code 上下文管理 - 宝玉的 6 條實戰經驗¶

核心論述¶

宝玉針對 Claude Code「上下文壓縮後必須等待」的痛點，提出以操作系統架構思維管理上下文的方法論。他將 AI Agent 比做操作系統，上下文窗口是「內存」（快但有限），文件系統是「硬盤」（慢但容量大），Git 是「時光機」（隨時回溯）。透過 6 條實戰經驗，讓使用者主動控制上下文流動，而非被動等待壓縮。

WHY（為什麼需要）： 自動壓縮會把關鍵細節當噪音裁掉，上下文用滿後什麼都幹不了，必須等待 2 分鐘。
WHAT（核心方法）： 將短期記憶（聊天）、長期記憶（文件）、歷史快照（Git）分層管理，主動卸載上下文壓力。
SO WHAT（影響）： 新會話可直接復用中間產物，避免重複敘述，提升工作流韌性，卡住時能快速回滾重來。

核心原則：三層記憶架構（操作系統比喻）¶

宝玉將 Claude Code 的工作流比做電腦的記憶體層次：

聊天 = 內存（快但有限）¶

特性： 快速、順手、即時互動
限制： 容量有限（上下文窗口）
用途： 當前任務的即時討論、決策過程

文件 = 硬盤（慢但容量大）¶

特性： 容量大、持久儲存
限制： 讀取相對慢（需要載入）
用途： 中間結果、設計文檔、提示詞模板

Git = 時光機（隨時回溯）¶

特性： 可追溯歷史、回滾快照
限制： 需要養成 commit 習慣
用途： 版本控制、實驗分支、失敗後重來

設計哲學：
不要讓所有資訊都擠在「內存」（聊天窗口）裡，該存硬盤的存硬盤（文件），該用時光機的用時光機（Git）。這樣「內存」永遠保持清爽，專注當前任務。

6 條具體實戰做法¶

1. 關掉自動壓縮，自己控制上下文¶

問題： 自動壓縮會把你最在意的細節當噪音裁掉。

做法： 手動決定什麼該留、什麼該丟。

洞察： 你比 AI 更清楚哪些細節是「關鍵約束」，哪些是「過程噪音」。自動壓縮是黑盒，容易誤殺重要資訊。

代價： 需要更主動地管理上下文（但換來精準控制）。

2. 中間結果存文件（新會話可直接復用）¶

問題： 每次新會話都要把所有歷史聊天搬進來，重複敘述需求。

做法： 保留中間文件，新會話直接載入。

具體範例（來自宝玉的 Skills 設計）： - 寫作： outline.md（大綱）、draft.md（草稿） - 寫代碼： 原始 prompt.md、design.md（設計模式討論）

優勢： - 新會話不用重述背景 → 直接說「參考 design.md 繼續實作」 - 中間文件成為「知識快照」→ 可跨會話復用 - 減少聊天窗口負擔 → 更多空間討論當前問題

設計思維： 把「過程中產生的有價值資訊」沉澱成文件，讓它們變成硬盤上的「長期記憶」，而非只存在聊天歷史的「短期記憶」。

3. 一個會話只做一件事（別順手塞太多）¶

問題： 上下文用滿，不是任務複雜，是順手塞了太多「順便問一下」。

做法： 嚴格遵守「一個會話 = 一個任務」原則。

反例： - 正在寫功能 A - 順便問一下功能 B 的邏輯 - 再順便討論一下架構重構 - 結果上下文爆炸，三件事都沒做好

正例： - 會話 1：實作功能 A（完成後 commit） - 會話 2：討論功能 B（完成後 commit） - 會話 3：架構重構討論（產出 refactor-plan.md）

心法： 不要把 Claude Code 當「萬能助手」，而是當「專注的協作者」— 每次只專心做一件事，做完再開下一個會話。

4. 長任務用總結接力（別壓縮會話）¶

問題： 任務很長，會話快滿了，但任務還沒完成。

傳統做法： 壓縮會話繼續 → 容易丟失關鍵細節。

宝玉的做法： 讓 Claude 總結關鍵資訊，手動調整後新開會話。

總結模板（5 個關鍵要素）： 1. 目標： 這個任務要達成什麼？ 2. 進度： 目前完成到哪裡？ 3. 卡點： 遇到什麼問題或挑戰？ 4. 下一步： 接下來要做什麼？ 5. 關鍵約束： 有哪些不能改的前提條件？

操作流程： 1. 會話快滿時：「請總結目標、進度、卡點、下一步、關鍵約束」 2. 手動檢視總結，修正關鍵地方 3. 存成 task-summary.md 4. 新開會話：「參考 task-summary.md 繼續」

優勢： 總結是「壓縮後的精華」，而非「自動裁剪的殘骸」。你手動調整確保關鍵資訊不丟。

5. 一定要用 Git（會話結束馬上 commit）¶

問題： 沒有版本控制，修改無法回溯，卡住後只能硬扛。

做法： 無論寫代碼還是寫作，一個會話結束馬上 commit。

具體實踐： - 每個會話結束 → git commit -m "feat: 實作功能 A" - 提示詞存進 prompts/ 目錄 → 下次直接復用 - 設計討論存成 docs/design.md → 新會話可參考

提示詞復用範例：

prompts/
├── feature-implementation.md  # 功能實作通用提示詞
├── bug-fix.md                 # Bug 修復流程
└── refactor.md                # 重構設計討論

Git 的三大價值： 1. 安全網： 隨時可回滾到上一個穩定狀態 2. 知識庫： commit message 成為工作日誌 3. 實驗自由： 敢於嘗試激進方案（大不了回滾）

6. 卡住了別硬扛（借助 Git 從頭來）¶

問題： 卡住後繼續補上下文，只會越補越亂。

洞察： 卡住多半是思路不對，而非資訊不夠。

做法： 借助 Git 回滾到上一個靠譜快照，從頭來。

操作流程： 1. 意識到卡住了（方向錯了、越改越複雜） 2. git log 找到上一個靠譜的 commit 3. git reset --hard <commit-hash> 回滾 4. 找到原始提示詞（prompts/ 目錄） 5. 找到關鍵中間文件（design.md、outline.md） 6. 新開會話，從頭來（但有中間產物可復用）

為什麼不補上下文： - 補上下文 = 在錯誤的路徑上繼續走 - 從頭來 = 換一條路，但帶著之前的學習（中間文件）

心法： 承認失敗是效率的一部分。Git 讓「重來」變得很便宜，別執著於沉沒成本。

額外洞察（來自討論）¶

Token 多少不是關鍵，關鍵是資訊品質¶

問題（JM1912）： 文檔多了，讓它讀取歷史方案和記錄，也會耗不少 token。

宝玉回應：
Token 多少不是關鍵，關鍵是你提供的資訊是不是它需要的。

文檔如果不需要，正常不會加載（只是佔硬盤空間）
需要時加載，都是有用資訊，大一點也沒關係
擔心的應該是：提供了一堆無用資訊（噪音），而非資訊太多

設計思維： 不要為了省 token 刪掉有用資訊，而是確保每份文檔「在需要時才被載入」。這是資訊架構的問題，而非 token 優化的問題。

實踐建議（應用到工作流）¶

寫作場景¶

session-1: 討論主題和大綱 → 產出 outline.md → commit
session-2: 參考 outline.md 寫初稿 → 產出 draft.md → commit
session-3: 參考 draft.md 修改潤色 → 產出 final.md → commit

寫代碼場景¶

session-1: 討論設計模式 → 產出 design.md → commit
session-2: 參考 design.md 實作核心功能 → commit
session-3: 實作邊界情況處理 → commit
（卡住了）git reset --hard <上一個 commit>，新會話重新設計

提示詞管理¶

prompts/
├── feature-spec-template.md   # 功能規格討論模板
├── code-review-prompt.md      # Code review 提示詞
└── design-pattern-discussion.md  # 設計模式討論框架

為什麼這套方法有效¶

1. 符合人類工作記憶限制¶

人腦也是：短期記憶（7±2 項）+ 長期記憶（筆記、文檔）+ 外部記憶（Git、搜尋）
Claude Code 的上下文窗口 = 短期記憶 → 同樣需要「卸載」機制

2. 提升工作流韌性¶

沒有 Git：卡住後只能硬扛或放棄
有 Git：卡住後可回滾重來，損失很小

3. 知識可復用¶

沒有中間文件：每次新會話都要重述背景
有中間文件：新會話直接載入，站在巨人肩膀上

4. 主動控制 > 被動等待¶

自動壓縮：黑盒、不可控、可能誤殺關鍵資訊
手動管理：透明、可控、精準保留需要的內容

與其他最佳實踐的關聯¶

呼應 Anthropic 的 Constitutional AI 理念¶

宝玉的「總結接力」→ 類似 Anthropic 的「distillation」（蒸餾）
不是粗暴壓縮，而是有意識地提取精華

呼應軟體工程的「單一職責原則」¶

一個會話只做一件事 → 類似一個函數只做一件事
降低複雜度，提升可維護性

呼應敏捷開發的「小步快跑」¶

頻繁 commit → 類似敏捷的頻繁迭代
每個 commit 都是可回滾的里程碑

適用場景與限制¶

適用場景¶

複雜專案： 需要多輪對話、分階段推進
寫作任務： 大綱 → 草稿 → 修改潤色
代碼開發： 設計 → 實作 → 重構

可能不適用¶

簡單問答： 一次對話就能解決的任務（不需要這麼複雜）
探索性對話： 還不確定要做什麼（先探索，確定方向後再用這套方法）

學習曲線¶

需要養成「隨手 commit」的習慣
需要有意識地「拆分任務」
初期可能覺得麻煩，但習慣後會大幅提升效率

關鍵金句¶

「聊天當內存，文件當硬盤，Git 當時光機。」
— 宝玉的核心方法論

「卡住了多半是思路不對，別在原會話硬扛。」
— 關於「重來」的勇氣

「一個會話只做一件事，很多人上下文用滿不是任務複雜，是順手塞了太多『順便問一下』。」
— 關於專注的重要性

「Token 多少不是關鍵，關鍵是你提供的資訊是不是它需要的。」
— 關於資訊品質 > 資訊數量

延伸思考¶

如何應用到 Clawdbot 工作流？¶

AGENTS.md 的角色： 類似宝玉的「中間文件」— 存放持久化的知識和規則
memory/ 目錄： 類似「硬盤」— 長期記憶的儲存
Git commit： 每次重要更新後 commit AGENTS.md、TOOLS.md

如何與 Claude Code Planning 結合？¶

Planning 階段： 產出 task-plan.md（類似宝玉的 design.md）
Execution 階段： Claude Code 參考 task-plan.md 執行
Review 階段： 總結產出 findings.md、progress.md

未來可能的工具改進¶

自動 commit 觸發器： 會話結束時提示是否 commit
中間文件模板： 提供 outline.md、design.md 的標準格式
總結 prompt 庫： 預設的「目標-進度-卡點-下一步-約束」模板