別把 Claude 當聊天：你其實在管理 context window
長時間對話把 context window 塞滿，模型就會分心、漏指示、錯誤變多。把任務拆分、用 /compact 與 /clear 管理工作記憶，才是穩定輸出的關鍵。
最近看到一段很實用的筆記：同樣是在用 Claude Code，有些人越用越順，有些人越用越卡。差別往往不是模型變笨，而是你的對話把 context window 塞滿了。
當 context window 裝進太多「已經完成的任務」與「無關的對話碎片」，模型會開始分心，指示容易遺失、錯誤率上升。這不是玄學，是載入了太多雜訊。
我把這套做法整理成一個更像工程流程的版本：你要管理的不是聊天，而是工作記憶。
## 你需要把對話當成一個會滿的資源
長時間 session 最常見的症狀：
-
明明講過規則，它又忘了
-
你越補充，它越亂
-
同一題越辯越深，最後變成繞圈
這時候重點不是再多打一段說明，而是把系統拉回乾淨狀態。
## 1) 一個對話只做一個任務
把對話範圍限制在單一專案或單一功能，讓 context 維持相關。
任務完成就用 /clear 清掉 context，下一個任務就開新對話。
這個規則看起來很保守，但它是讓品質穩定的最短路。
## 2) 控制 context 使用量：別超過 60%
一個簡單的門檻：永遠不要讓 context 超過 60%。
如果你發現對話已經接近半滿，就該開始安排「結束這輪」了。
也可以把一個大任務切成四段：
-
Research
-
Plan
-
Implement
-
Validate
每一段做完就清一次 context，讓下一段在乾淨狀態開始。
## 3) 主動 /compact，不要等自動
很多人會等 auto-compact 自己觸發，但那很可能會打斷工作節奏。
比較成熟的做法是：你自己掌握節點、手動 /compact。
你在做的是同一件事：把「雜訊」壓縮掉，讓關鍵狀態留在 context 內。
## 4) 任務太大就拆分，並把計畫寫到檔案
如果你覺得某個專案或功能太大，不要硬塞進同一個 context window。
你可以請 Claude 先把它分解成專案計畫，存到 markdown 檔。
接著請它只先完成第一部分，剩下的用下一輪對話接續。
這個習慣的本質是「把記憶外部化」：能落地的東西寫進檔案，不要塞在對話裡賭運氣。
## 5) 用 /clear 做頻繁重置
在長時間的 session 裡，Claude 的 context window 會逐漸被無關對話、檔案內容與舊指令佔滿。
一旦你發現效能下滑，最有效的方法往往是直接重置 context window：
-
任務與任務之間頻繁使用
/clear -
不要期待一個 session 承載一整天的所有工作
## 6) 卡住時別爭論，直接重開
如果模型開始搞混或陷入迴圈，你跟它爭論通常只會增加雜訊。
更好的做法是：
-
用
/clear重置「工作記憶」 -
用一個乾淨的 prompt 重新開始
把它當成「休息一下，重新看這個問題」。
## 7) 把 skill 用在該用的地方
有一段我很認同：你提到的 skill 概念方向是對的。
可用的做法包括：
-
把常用的工作流程寫成 custom commands（放在
.claude/commands/） -
用 subagents 處理特定任務（它們有自己的 context window）
-
把重要的專案知識寫在
CLAUDE.md，讓每次新對話都能自動載入
這一套其實在做同一件事：把「容易膨脹的上下文」拆出去，留下必要的核心資訊。
## 一個簡單、可重複的工作節奏
我會把建議濃縮成這六步，當作每個任務的固定節奏：
- 開新對話
- 給 Claude 一個明確的單一任務
- 監控 context（用
/context） - 接近 50–60% 時主動
/compact - 任務完成後
/clear或關閉對話 - 下一個任務再開新對話
最後那句提醒很重要：不要試圖在同一個對話裡做太多事情。
當你把「任務管理」放進流程，模型才會穩定。
ClaudeCode、LLM、AgenticAI、工作流程
## 來源
