Claude Code 100萬上下文時代，你的會話管理可能全錯了

Anthropic 官方發了一篇博客，專門講 Claude Code 的會話管理和上下文管理策略

看完之后我覺得，這篇值得給每一個 Claude Code 用戶看

因為很多人用 Claude Code，就是開一個終端窗口，從頭擼到尾，從來沒想過"上下文"這個東西還能精細化管理

為什么上下文管理這么重要？

先說一個很多人忽略的事實：Claude Code 現在有 100 萬 token 的上下文窗口了

100 萬 token 是什么概念？大概等于一整本《哈利波特》的文字量

理論上，你可以在一個會話里完成一個完整的全棧應用開發——從需求分析到代碼實現到測試部署

但問題來了

上下文窗口就像你的工作臺，模型每次生成回復的時候，它能"看到"的東西包括：系統提示詞、整個對話歷史、每一次工具調用和輸出、讀取過的每一個文件

窗口越大，擺在桌上的東西越多

上下文窗口包含了模型能"看到"的所有內容

這里就有一個關鍵概念：上下文腐爛（Context Rot）

這不是我編的詞，是 Anthropic 官方用的術語

意思是：隨著上下文越來越長，模型的注意力被分散到越來越多的 token 上，早期那些已經不相關的內容開始"干擾"當前任務

說人話就是——你聊得越久，模型越容易犯迷糊

人類也一樣

所以 100 萬 token 的窗口是把雙刃劍：你能干更大的活了，但如果不管理好上下文，效果反而可能變差

上下文腐爛概念圖：越聊越長，注意力越分散 什么是 Compaction（壓縮）？

上下文窗口有硬性上限

當你快要撐爆窗口的時候，Claude Code 會自動觸發壓縮——把之前的對話歷史總結成一段更短的描述，然后在新的上下文窗口里繼續工作

壓縮機制：總結歷史對話，在新窗口中繼續

你也可以手動觸發壓縮，用 /compact 命令

聽起來很美好對吧？但壓縮是有損的——總結必然丟失細節

后面我會講，什么時候壓縮會出問題

每一輪對話后，你其實有 5 個選擇

這是這篇文章最核心的部分

大多數人在 Claude Code 里的操作模式是：發消息 → 等回復 → 發下一條消息

永遠在"繼續"

但實際上，每一輪對話結束后，你有 5 條路可以走：

每輪對話后的 5 個選擇

選項

操作方式

干了什么

繼續

直接發消息

在當前會話接著干

回退

雙擊 Esc 或 /rewind

跳回之前某條消息，從那里重新開始

清空 /clear

開一個全新的會話

壓縮 /compact

總結當前會話，清理上下文后繼續

子代理

委派給子代理

把一塊工作丟給獨立的代理去做，只拿結果

大部分人只用第一個

但后面四個才是真正拉開效率差距的關鍵

什么時候該開新會話？

Anthropic 給出的建議簡單粗暴：新任務，新會話

雖然 100 萬 token 讓你可以在一個會話里干很久，但上下文腐爛是真實存在的

你之前調試了半天的 bug 的上下文，對你接下來要寫的新功能來說就是噪音

但也有例外——如果新任務和之前的任務高度相關，比如你剛實現了一個功能，接著要給它寫文檔

這時候開新會話反而浪費，因為 Claude 得重新讀一遍你剛寫完的那些文件，又慢又費錢

我的經驗：任務切換的時候，想一下"之前的上下文對新任務有沒有用"，如果答案是"大部分沒用"，果斷 /clear

Rewind：比糾正更好的選擇

這個功能我覺得被嚴重低估了

場景是這樣的：Claude 讀了五個文件，試了一種方案，結果不行

你的本能反應是什么？大概率是打一句"那個不行，換 X 方案試試"

但 Anthropic 的建議是：別糾正，直接回退

Rewind 操作示意：回到讀文件之后、錯誤嘗試之前

操作很簡單：雙擊 Esc，跳回到"讀完文件"那個時間點，然后重新下指令："不要用 A 方案，foo 模塊沒暴露那個接口，直接用 B 方案。"

為什么回退比糾正好？因為糾正的時候，錯誤嘗試的那些工具調用和輸出還在上下文里

模型看著失敗的方案，可能還會被它影響

回退直接把那些垃圾上下文丟掉了，干干凈凈

還有一個騷操作：你可以用 /rewind 命令讓 Claude 先總結它從失敗嘗試中學到了什么，生成一個"交接信息"——相當于未來的 Claude 給過去的 Claude 寫了一封信："別走 A 方案，我試過了，走不通"

Compact vs Clear：兩種完全不同的瘦身方式

會話變長之后，你有兩種方式給上下文減負：

/compact（壓縮）

讓模型自己總結對話歷史，把冗長的上下文壓縮成一段摘要

好處是你不用動手，Claude 可能比你更細致地保留了關鍵信息

你還可以給它加引導：

/compact 重點保留 auth 重構的部分，調試過程可以丟掉

/clear（清空）

你自己寫一段簡報，然后開一個全新的會話

比如："我們在重構 auth 中間件，約束條件是 X，關鍵文件是 A 和 B，Y 方案已經排除了。"

這種方式更費勁，但上下文完全由你決定什么該留

Compact vs Clear 對比圖

我的建議：

• 日常推進 用 /compact ，省事

• 重要節點切換 用 /clear ，精確控制

這是一個很實際的問題

如果你跑過長會話，大概率遇到過壓縮之后 Claude 突然"失憶"的情況

Anthropic 說了原因：模型沒法預測你接下來要干什么

舉個例子：你花了很長時間在調試一個 bug，期間順帶掃到了 bar.ts 里有一個 warning。自動壓縮觸發了，它總結的重點當然是調試過程。然后你說"去把 bar.ts 那個 warning 修了"——但那個 warning 的信息已經被壓縮掉了

更扎心的是：自動壓縮觸發的時機，恰恰是上下文最長、模型注意力最分散、最不聰明的時候

所以 Anthropic 的建議是：有了 100 萬 token 的窗口，你有更多余裕**在模型狀態還好的時候主動 /compact**，別等到快爆了才被動觸發

子代理：給上下文減負的終極武器

子代理（Subagent）的核心思路：把一塊工作丟給一個全新的、獨立的上下文窗口去做，只把最終結論拿回來

子代理在獨立上下文中工作，只返回結論給父會話

Anthropic 內部用的判斷標準很簡單：**"我需要的是這些工具輸出本身，還是只需要結論？"**

如果只需要結論，那就用子代理

典型場景：

• "開個子代理，根據這個 spec 文件驗證我剛才的實現結果"

• "開個子代理，去讀一下另一個代碼庫的 auth 實現方式，總結完告訴我，我來照著實現"

• "開個子代理，根據我的 git changes 寫文檔"

這些任務的共同特點：中間過程產生大量輸出，但你只需要最終結果

如果這些中間輸出全堆在主會話里，就是純粹的上下文污染

決策速查表

最后，Anthropic 官方給了一張決策表，我翻譯整理了一下，建議收藏：

上下文管理決策地圖

場景

該用什么

為什么

同一個任務還在推進，上下文都有用

繼續

上下文都是有用的，別浪費

Claude 走歪了，方向不對

Rewind（雙擊 Esc）

保留有用的文件讀取，丟掉錯誤嘗試，帶著經驗重新來

任務進行中，但大量過時的調試/探索占著上下文

/compact + 引導

省力；Claude 來決定什么重要，你用指令微調方向

要開始一個全新的任務

/clear

零腐爛；你完全控制帶什么進新會話

下一步會產生大量中間輸出，你只需要結論

子代理

中間噪音留在子上下文里，只有結果回來

總結

說實話，這篇博客讓我意識到，很多人（包括我自己）在用 Claude Code 的時候，對上下文管理太粗放了

我們天天聊"提示詞工程"，但"上下文工程"可能更重要——因為再好的提示詞，如果淹沒在一堆無關的上下文里，效果也會打折扣

核心要點三條：

1. 100 萬 token 不是讓你無腦堆的 ——上下文越長，模型越容易走神

2. **每輪對話后，想一想該"繼續"還是"瘦身"**——Rewind、Compact、Clear、Subagent 四個工具組合使用

3. 主動管理比被動觸發好得多 ——別等自動壓縮翻車了才后悔

原文鏈接：claude.com/blog/using-claude-code-session-management-and-1m-context

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！