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

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

因?yàn)楹芏嗳擞?Claude Code，就是開一個(gè)終端窗口，從頭擼到尾，從來沒想過"上下文"這個(gè)東西還能精細(xì)化管理

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

先說一個(gè)很多人忽略的事實(shí)：Claude Code 現(xiàn)在有 100 萬 token 的上下文窗口了

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

理論上，你可以在一個(gè)會(huì)話里完成一個(gè)完整的全棧應(yīng)用開發(fā)——從需求分析到代碼實(shí)現(xiàn)到測試部署

但問題來了

上下文窗口就像你的工作臺(tái)，模型每次生成回復(fù)的時(shí)候，它能"看到"的東西包括：系統(tǒng)提示詞、整個(gè)對話歷史、每一次工具調(diào)用和輸出、讀取過的每一個(gè)文件

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

上下文窗口包含了模型能"看到"的所有內(nèi)容

這里就有一個(gè)關(guān)鍵概念：上下文腐爛（Context Rot）

這不是我編的詞，是 Anthropic 官方用的術(shù)語

意思是：隨著上下文越來越長，模型的注意力被分散到越來越多的 token 上，早期那些已經(jīng)不相關(guān)的內(nèi)容開始"干擾"當(dāng)前任務(wù)

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

人類也一樣

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

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

上下文窗口有硬性上限

當(dāng)你快要撐爆窗口的時(shí)候，Claude Code 會(huì)自動(dòng)觸發(fā)壓縮——把之前的對話歷史總結(jié)成一段更短的描述，然后在新的上下文窗口里繼續(xù)工作

壓縮機(jī)制：總結(jié)歷史對話，在新窗口中繼續(xù)

你也可以手動(dòng)觸發(fā)壓縮，用 /compact 命令

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

后面我會(huì)講，什么時(shí)候壓縮會(huì)出問題

每一輪對話后，你其實(shí)有 5 個(gè)選擇

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

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

永遠(yuǎn)在"繼續(xù)"

但實(shí)際上，每一輪對話結(jié)束后，你有 5 條路可以走：

每輪對話后的 5 個(gè)選擇

選項(xiàng)

操作方式

干了什么

繼續(xù)

直接發(fā)消息

在當(dāng)前會(huì)話接著干

回退

雙擊 Esc 或 /rewind

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

清空 /clear

開一個(gè)全新的會(huì)話

壓縮 /compact

總結(jié)當(dāng)前會(huì)話，清理上下文后繼續(xù)

子代理

委派給子代理

把一塊工作丟給獨(dú)立的代理去做，只拿結(jié)果

大部分人只用第一個(gè)

但后面四個(gè)才是真正拉開效率差距的關(guān)鍵

什么時(shí)候該開新會(huì)話？

Anthropic 給出的建議簡單粗暴：新任務(wù)，新會(huì)話

雖然 100 萬 token 讓你可以在一個(gè)會(huì)話里干很久，但上下文腐爛是真實(shí)存在的

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

但也有例外——如果新任務(wù)和之前的任務(wù)高度相關(guān)，比如你剛實(shí)現(xiàn)了一個(gè)功能，接著要給它寫文檔

這時(shí)候開新會(huì)話反而浪費(fèi)，因?yàn)?Claude 得重新讀一遍你剛寫完的那些文件，又慢又費(fèi)錢

我的經(jīng)驗(yàn)：任務(wù)切換的時(shí)候，想一下"之前的上下文對新任務(wù)有沒有用"，如果答案是"大部分沒用"，果斷 /clear

Rewind：比糾正更好的選擇

這個(gè)功能我覺得被嚴(yán)重低估了

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

你的本能反應(yīng)是什么？大概率是打一句"那個(gè)不行，換 X 方案試試"

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

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

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

為什么回退比糾正好？因?yàn)榧m正的時(shí)候，錯(cuò)誤嘗試的那些工具調(diào)用和輸出還在上下文里

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

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

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

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

會(huì)話變長之后，你有兩種方式給上下文減負(fù)：

/compact（壓縮）

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

好處是你不用動(dòng)手，Claude 可能比你更細(xì)致地保留了關(guān)鍵信息

你還可以給它加引導(dǎo)：

/compact 重點(diǎn)保留 auth 重構(gòu)的部分，調(diào)試過程可以丟掉

/clear（清空）

你自己寫一段簡報(bào)，然后開一個(gè)全新的會(huì)話

比如："我們在重構(gòu) auth 中間件，約束條件是 X，關(guān)鍵文件是 A 和 B，Y 方案已經(jīng)排除了。"

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

Compact vs Clear 對比圖

我的建議：

• 日常推進(jìn) 用 /compact ，省事

• 重要節(jié)點(diǎn)切換 用 /clear ，精確控制

這是一個(gè)很實(shí)際的問題

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

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

舉個(gè)例子：你花了很長時(shí)間在調(diào)試一個(gè) bug，期間順帶掃到了 bar.ts 里有一個(gè) warning。自動(dòng)壓縮觸發(fā)了，它總結(jié)的重點(diǎn)當(dāng)然是調(diào)試過程。然后你說"去把 bar.ts 那個(gè) warning 修了"——但那個(gè) warning 的信息已經(jīng)被壓縮掉了

更扎心的是：自動(dòng)壓縮觸發(fā)的時(shí)機(jī)，恰恰是上下文最長、模型注意力最分散、最不聰明的時(shí)候

所以 Anthropic 的建議是：有了 100 萬 token 的窗口，你有更多余裕**在模型狀態(tài)還好的時(shí)候主動(dòng) /compact**，別等到快爆了才被動(dòng)觸發(fā)

子代理：給上下文減負(fù)的終極武器

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

子代理在獨(dú)立上下文中工作，只返回結(jié)論給父會(huì)話

Anthropic 內(nèi)部用的判斷標(biāo)準(zhǔn)很簡單：**"我需要的是這些工具輸出本身，還是只需要結(jié)論？"**

如果只需要結(jié)論，那就用子代理

典型場景：

• "開個(gè)子代理，根據(jù)這個(gè) spec 文件驗(yàn)證我剛才的實(shí)現(xiàn)結(jié)果"

• "開個(gè)子代理，去讀一下另一個(gè)代碼庫的 auth 實(shí)現(xiàn)方式，總結(jié)完告訴我，我來照著實(shí)現(xiàn)"

• "開個(gè)子代理，根據(jù)我的 git changes 寫文檔"

這些任務(wù)的共同特點(diǎn)：中間過程產(chǎn)生大量輸出，但你只需要最終結(jié)果

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

決策速查表

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

上下文管理決策地圖

場景

該用什么

為什么

同一個(gè)任務(wù)還在推進(jìn)，上下文都有用

繼續(xù)

上下文都是有用的，別浪費(fèi)

Claude 走歪了，方向不對

Rewind（雙擊 Esc）

保留有用的文件讀取，丟掉錯(cuò)誤嘗試，帶著經(jīng)驗(yàn)重新來

任務(wù)進(jìn)行中，但大量過時(shí)的調(diào)試/探索占著上下文

/compact + 引導(dǎo)

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

要開始一個(gè)全新的任務(wù)

/clear

零腐爛；你完全控制帶什么進(jìn)新會(huì)話

下一步會(huì)產(chǎn)生大量中間輸出，你只需要結(jié)論

子代理

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

總結(jié)

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

我們天天聊"提示詞工程"，但"上下文工程"可能更重要——因?yàn)樵俸玫奶崾驹~，如果淹沒在一堆無關(guān)的上下文里，效果也會(huì)打折扣

核心要點(diǎn)三條：

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

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

3. 主動(dòng)管理比被動(dòng)觸發(fā)好得多 ——?jiǎng)e等自動(dòng)壓縮翻車了才后悔

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

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