100万上下文是 Claude Code 的优势，但同时也是把双刃剑，使用不当就会导致 context rot（上下文腐烂）。

Claude Code 开发者 Thariq Shihipar 的这一篇《Using Claude Code: Session Management & 1M Context》详细讲解了如何管理 session，以及如何避免 context rot 的最佳实践。

上下文、压缩与上下文腐烂快速入门

上下文窗口是模型在生成下一个响应时一次能"看到"的所有内容。它包括：

• 系统提示词
• 对话历史
• 工具调用及其输出
• 已读取的文件

Claude Code 拥有 100 万令牌的上下文窗口。

上下文腐烂（Context Rot）

使用上下文是有轻微代价的，这通常被称为"上下文腐烂"。上下文腐烂是指模型性能随着上下文增长而下降，因为注意力被分散到更多令牌上，旧的、无关的内容开始干扰当前任务。

对于 Claude Code 的 1M 上下文模型，在约 300-400k 令牌时会出现某种程度的上下文腐烂。

压缩（Compaction）

上下文窗口是硬性截止的。当你接近窗口末尾时，需要将一直工作的任务总结成较短的描述，并在新的窗口中继续工作，称之为"压缩"。

你也可以自己触发压缩。

---

5 大会话管理指令

每一个轮次都是一个分支点。假设你刚让 Claude 做了某事且它已完成，接下来你有这些选择：

指令	用途	快捷键
Continue	在同一个会话中发送另一条消息	-
/rewind	跳回之前的某条消息，并从那里重新开始	esc esc
/clear	开启新会话，通常带着你刚学到的知识提炼出的简报	-
Compact	总结目前的会话，并在总结的基础上继续	-
Subagents	将下一块工作委派给拥有干净上下文的代理，仅取回结果	-

---

何时使用 /clear（开启新会话）

/clear 的核心用途是清除上下文中的噪音，专注于新任务。

适合 /clear 的场景

场景一：任务已完成，想继续下一个

当你完成一个任务后，如果直接继续下一个任务，Claude 的上下文里还残留着上一个任务的记忆。虽然这有时很有用，但更多时候这些"噪音"会干扰新任务。

场景二：上下文已膨胀但不需要它

如果你的上下文已经变得很长，而你接下来要做的事不需要之前会话中的任何内容，直接 /clear 是最干净的选择。

场景三：任务意外终止

如果你因为某种原因打断了 Claude，或者 Claude 做了错误的事情并且上下文已经变得混乱，可以选择：

• /rewind 回到出问题的地方重新开始
• /clear 清除一切重新开始

何时不用 /clear

如果你需要 Claude 记住你之前做了什么，那么不要用 /clear。

最佳实践

当你决定要 /clear 时，提前想好你需要保留什么。

# 在 /clear 之前，可以先让 Claude 总结关键信息
"请总结我们刚才完成的工作，包括关键决策和下一步要做的改动"

# 然后再 /clear，把总结作为新会话的开场白

---

何时使用 /compact（压缩会话）

/compact 的核心逻辑

/compact 的核心作用是让你在不丢失工作进度的情况下，缩减上下文长度。

它的工作流程：

1. 读取当前上下文中的所有内容
2. 将其压缩成一段更短但更密集的总结
3. 把这个总结作为新上下文的基础继续工作

/compact 的使用时机

场景	建议
上下文接近 300-400k 令牌	✅ 使用 /compact
任务进行中但上下文已经很长	✅ 使用 /compact
需要保留工作进度但要清理噪音	✅ 使用 /compact
任务刚开始或上下文很短	❌ 不需要

什么会导致糟糕的压缩

压缩质量取决于上下文的质量。好的压缩依赖于：

1. 上下文干净：无多余噪音
2. 任务明确：Claude 知道你在做什么
3. 关键信息完整：保留重要的决策、代码改动、待办事项

坏的压缩通常是因为上下文里有太多不相关的内容，或者任务不清晰。

---

何时使用 /rewind（回退）

/rewind 的核心逻辑

/rewind 让你回到之前的某个状态，从那里重新开始，而不影响当前的上下文。

这对于修复错误、尝试不同方法非常有价值。

常见使用场景

场景一：Claude 做了错误的事情

如果你意识到 Claude 走了错误的路线，可以 /rewind 回到之前的状态，选择不同的分支。

场景二：想尝试不同的提示

当你对某个提示不满意时，可以 /rewind 重新开始，尝试不同的表达方式。

场景三：恢复意外中断的工作

如果 Claude 的响应被意外中断，可以 /rewind 到那条消息，重新继续。

---

何时使用 Subagents（子代理）

Subagents 的核心逻辑

Subagents 让你将工作委派给拥有干净上下文的代理，仅取回结果。

这解决了两个问题：

1. 长任务分段：不需要在一个会话中处理所有内容
2. 隔离工作：子任务不会污染主会话的上下文

何时使用 Subagents

场景	建议
多文件重构	✅ 使用 subagent 处理不同文件
并行任务	✅ 多个 subagent 同时工作
独立测试任务	✅ 使用 subagent 避免干扰主会话
单个文件内的短期任务	❌ 直接在主会话处理

使用示例

# 委派一个子任务
/subagent 帮我重构 src/utils/ 目录下的所有文件

# 主会话继续其他工作
# 子任务完成后，结果会自动汇总到主会话

---

会话管理最佳实践总结

问题	解决方案
上下文太长导致性能下降	使用 /compact 压缩会话
需要专注新任务	使用 /clear 开启新会话
想修复错误或尝试不同路线	使用 /rewind 回退
长任务需要分段处理	使用 Subagents 委派
任务意外中断	/rewind 恢复或 /clear 重新开始

一句话原则

"保持上下文干净，只保留当前任务需要的内容。"

---

实战建议

1. 不要让上下文无限制增长：在 300-400k 令牌之前考虑压缩
2. 任务切换时优先 /clear：新任务不需要旧上下文
3. 善用 /rewind 修复错误：不要害怕重新开始
4. Subagents 是长任务的利器：分段处理，避免上下文污染
5. compaction 的质量取决于上下文质量：保持上下文干净，压缩效果更好