上下文管理
官方 best-practices 里有一句话被反复强调：
Context is the most important resource.
不是模型、不是订阅档位，是上下文。上下文窗口就像 Claude 的短期记忆——塞满了它就开始忘事、丢细节、重复探索。会管理上下文的人，Claude 越用越顺手；不会管的，越用越笨。
这一篇讲透怎么压缩、怎么清空、怎么用 /stats 反向优化、怎么靠子代理隔离。
/compact：压缩，可以指定聚焦点
Section titled “/compact：压缩，可以指定聚焦点”/compact 是最常用的上下文管理命令。它把当前对话压缩成一份摘要，保留关键信息、丢掉过程噪音，腾出空间继续干。
裸用就是这样：
/compact但裸用是「让 Claude 自己决定留什么」。更高阶的用法是指定聚焦点：
/compact 保留 test 输出和已改动的代码细节，丢掉探索过程的中间讨论加一句 instructions，压缩就有的放矢——你告诉它「这些必须留，那些可以丢」，而不是赌它自己猜对。
官方 best-practices 给的建议是，把这种聚焦提示写进 CLAUDE.md，让每次 compact 都自动带上：
# Summary descriptionsWhen using compact, focus on test output and code changes.这样每次 auto-compact 触发时，它都会默认保留测试输出和代码改动——你最在乎的两类信息。
/clear：任务结束彻底清空
Section titled “/clear：任务结束彻底清空”/compact 是压缩，/clear 是彻底清空——把上下文归零，从白纸开始。
什么时候用 /clear？
- 一个任务做完了，要开下一个不相关的活，别让上一个任务的细节赖在上下文里。
- 上下文已经被污染——聊歪了、信息乱了，与其费力整理不如清空重来。
- 想换方向——同一个会话里换完全不同的任务，清空比 compact 更干净。
/clear/clear 和 /compact 的区别：compact 是「浓缩保留」，clear 是「推倒重来」。任务之间用 clear，任务之内用 compact。
/stats：高手的反向优化工具
Section titled “/stats：高手的反向优化工具”/stats 不直接管理上下文，但它给你决策依据。它显示当前会话的 token 使用情况——消耗了多少、还剩多少、auto-compact 触发过几次。
高手用 /stats 做的是反向优化策略：
- 看到某类操作特别烧 token？下次少做。
- 看到 auto-compact 频繁触发？说明任务太大该拆。
- 看到上下文消耗速度异常？检查是不是有冗余信息在反复传。
/stats定期看一眼 /stats，能发现很多「原来这一步这么贵」的盲点。这是从「凭感觉用」走向「数据驱动用」的关键一步。
auto-compact：95% 自动触发
Section titled “auto-compact：95% 自动触发”Claude Code 有个保护机制：上下文用到 95% 时，auto-compact 自动触发，避免直接撞墙。
这个机制可以在 /config 里切换：
/config一般保持开启就好——它是你的安全网，避免你忘了 compact 导致上下文溢出。但如果你在做一些需要完整保留上下文的精细工作（比如长链推理），可以临时关掉，手动控制 compact 时机。
注意：auto-compact 触发时用的是 CLAUDE.md 里的聚焦提示。所以前面说的「写 compact 聚焦提示进 CLAUDE.md」不是可选项——它直接决定自动压缩留什么、丢什么。
子代理：隔离上下文
Section titled “子代理：隔离上下文”上下文管理的另一条大腿是子代理。重活脏活丢给子代理，它在独立上下文里干完，只把摘要交回来，主会话保持干净。
> 派 Explore 子代理通读 src/ 目录，给我一份模块依赖图。（子代理读了一万行代码，主会话只多了一份摘要）这就是 9 步循环 第 1 步和第 7 步的设计——探索和审查都甩给子代理，主会话只装「决策」不装「过程」。等于把上下文压力分流出去。
经验上，凡是「读很多、跑很久、但结论很简单」的活，都适合甩给子代理：通读代码库、跑全套测试并总结、审查一大片 diff。
拆分任务：避免单次会话过载
Section titled “拆分任务：避免单次会话过载”最后一个、也是最朴素的一条：任务太大就拆。
一个会话塞不下的大重构，拆成多个会话——每个会话一个子目标，做完 compact 或 clear，再开下一个。这比硬塞进一个会话、靠 auto-compact 反复救场要稳得多。
参考 会话管理 那篇的「一个功能一个会话」——本质就是把上下文压力分摊到多个会话里，每个会话的上下文都留有余量。
背景 token 用量
Section titled “背景 token 用量”会担心这些 compact、命令处理额外烧钱？官方和社区都测算过：背景 token（conversation summarization、command processing）通常每会话不到 $0.04。
也就是说，compact 一次、清空一次、跑几个斜杠命令，这点开销相对于写代码本身几乎可以忽略。别为了省这点 token 而不去管理上下文——不管理导致上下文退化造成的损失，是这点 token 的几十倍。
上下文是最重要的资源。/compact 压缩（带 instructions 指定聚焦点）、/clear 任务间清空、/stats 反向优化策略、auto-compact 95% 自动触发（聚焦提示写进 CLAUDE.md）、重活甩给子代理隔离。背景 token 每会话不到 $0.04，别为省这个不管理。
下一步，去看 /rewind 安全绳——会话里走错了怎么低成本回退。🚀