Claude Code 上下文管理指南：什么时候用 /compact，什么时候用 /clear？
很多同学刚开始使用 Claude Code 时，都会遇到一个问题：聊着聊着 AI 开始跑偏、忘记前面的约定，或者上下文越来越臃肿。这个时候到底应该用
/compact，还是直接/clear？本文结合实际项目经验，聊聊 Claude Code 中上下文管理的最佳实践。
前言
AI 编程工具最强的地方，不只是“能写代码”，而是它能在一段连续对话中逐渐理解你的项目：
- 项目技术栈是什么
- 目录结构怎么组织
- 团队有哪些编码规范
- 之前讨论过哪些方案
- 哪些坑已经踩过，哪些方案被否决过
但上下文不是无限的。
当然，今天很多主流模型的上下文窗口已经来到 200K 级别，正常开发时不需要像早期小上下文模型那样频繁“清内存”。大上下文的好处是非常明显的：它能容纳更多代码、更多需求讨论、更多历史决策，也让 AI 更容易保持对项目的连续理解。
但 200K 并不等于可以无限堆上下文。
当对话越来越长时，Claude Code 会携带越来越多历史消息，这些信息既可能是有效记忆，也可能是噪音：中间试错、被否决的方案、临时日志、错误猜测、重复解释……
所以现在使用 /compact 的重点，不再是“省 token”，而是“提升上下文质量”。
这时候，合理使用 /compact 和 /clear 就非常重要。
一、什么是 /compact？
/compact 可以理解为一次“上下文压缩”。
它不是简单清空聊天记录，而是把之前的对话做一次智能总结：
- 保留核心结论
- 保留关键决策
- 保留项目约定
- 清理冗余过程
- 丢掉中间弯路和无效试错
简单说：
/compact的目标不是让 AI 忘记，而是让 AI 只记住真正重要的东西。
例如你和 Claude Code 讨论了 30 轮登录架构，最后决定：
- 使用 HttpOnly Cookie
- 不把 Token 存到 localStorage
- 刷新 Token 由后端自动处理
- 前端只负责
withCredentials: true
中间可能讨论过 JWT 放 localStorage、Authorization Header、sessionStorage 等方案，但这些都被否决了。
这时执行 /compact，理想效果就是：AI 记住最终方案，忘掉中间那些已经被否决的路线。
二、/compact 和 /clear 的本质区别
很多人会把这两个命令混用，但它们适合的场景完全不同。
| 维度 | /compact | /clear |
|---|---|---|
| 是否保留项目上下文 | 保留 | 不保留 |
| 是否保留已确认决策 | 保留 | 不保留 |
| 是否清理中间噪音 | 清理 | 清理 |
| 是否适合同项目继续开发 | 适合 | 不一定适合 |
| 是否适合彻底重开 | 不适合 | 适合 |
一句话区分：
聊成了，用
/compact；聊崩了，用/clear。
/compact 是“提炼价值后继续”；/clear 是“全部清空重新来过”。
三、什么时候应该使用 /compact？
1. 方案已经讨论清楚，准备开始编码
这是最适合使用 /compact 的场景。
比如你和 AI 已经讨论完：
- 页面怎么拆分
- 状态放在哪一层
- 接口怎么设计
- 异常怎么处理
- 哪些方案不采用
接下来准备真正写代码。
这时如果直接继续写，历史对话里可能还残留大量被否定的想法。AI 在生成代码时，可能会受到这些噪音干扰。
执行一次 /compact，可以让 AI 带着“最终共识”进入编码阶段。
推荐流程：
# 1. 先充分讨论方案
# 2. 明确最终技术决策
# 3. 执行上下文压缩
/compact
# 4. 开始编码
2. 一个功能完成，下一个功能仍然属于同一个项目
例如你刚完成了登录功能，接下来要做文章发布功能。
这两个功能不同，但它们共享同一套项目约定：
- 同一个技术栈
- 同一套目录结构
- 同一套 API 规范
- 同一套状态管理方式
- 同一套安全策略
这时不建议 /clear，因为清空后 AI 需要重新理解项目背景。
更适合执行 /compact：保留项目规则，清理刚才登录功能的细节。
3. 调试过程绕了很多弯路，但最终找到了正确根因
调 Bug 时经常会这样：
- 第一次猜是类型问题
- 第二次猜是接口问题
- 第三次猜是缓存问题
- 最后发现是 MobX 方法里的
this绑定问题
如果继续带着完整调试上下文，AI 可能后面又被前几个错误猜测影响。
这时候执行 /compact，只保留最终结论：
根因是
useLocalObservable中使用箭头函数导致this指向错误，应该使用方法语法。
这样后续再遇到类似问题，AI 更容易直接命中正确方向。
4. 上下文使用率已经比较高
当 Context Usage 超过 70% 左右时，就可以考虑 /compact。
上下文过长后，问题不只是“占用 token”，还包括：
- AI 容易遗漏早期约定
- 回复速度可能变慢
- 历史噪音越来越多
- 被旧方案干扰的概率变高
如果当前对话已经沉淀出有价值结论，并且后续还要继续同项目开发，/compact 通常是更好的选择。
四、什么时候不要使用 /compact？
1. 对话刚开始，信息量很少
如果才聊了几轮，Token 使用率也很低，完全没必要压缩。
尤其是在 200K 上下文窗口已经比较常见的情况下，早期对话的那点内容通常远远达不到需要压缩的程度。这个阶段更应该让 AI 多保留一些原始信息，而不是急着总结。
压缩本质上也是一次总结，总结就可能损失细节。内容太少时，收益很低，反而可能丢掉一些还没稳定下来的信息。
2. 正在调试复杂问题
调试过程中，很多看似无关的信息可能都是线索。
例如：
- 报错堆栈
- 复现路径
- 之前尝试过的方案
- 某个命令的输出
- 某个文件的局部改动
如果问题还没定位清楚，不建议中途 /compact。因为压缩可能把关键线索当作噪音清掉。
更好的做法是：等根因明确、修复方案确认之后，再执行 /compact。
3. 方案还没有达成共识
如果你和 AI 还在多个方案之间摇摆，比如：
- 该用 Zustand 还是 MobX？
- 该用 WebSocket 还是 SSE？
- 该把逻辑放前端还是后端？
此时不要急着 /compact。
因为最终决策还没形成，压缩后可能会把某个临时倾向误当成结论。
五、什么时候应该直接使用 /clear？
/clear 更适合“重置现场”。
1. 对话已经明显跑偏
如果你发现 AI 已经开始持续误解你的需求，或者不断沿着错误方向输出，这种上下文已经被污染了。
这时候继续 /compact，可能只是把错误理解压缩成“错误但更坚定的结论”。
更好的选择是 /clear，重新开始。
2. 下一个任务和当前项目完全无关
例如你刚才在聊 React 项目，接下来要问一个 Linux 运维问题。
这种场景保留项目上下文没有意义，反而可能干扰回答。
直接 /clear 更干净。
3. 当前对话没有产生有价值结论
如果这轮对话只是随便试了几个方案，都没成功，也没有明确结论，那就没什么值得保留。
压缩垃圾，得到的还是垃圾。
这时 /clear 更合适。
六、我的个人决策树
可以用下面这个简单决策树判断：
当前对话是否有价值结论？
├─ 没有：/clear
└─ 有：继续判断
└─ 下一个任务是否还和当前项目相关？
├─ 无关：/clear
└─ 相关：/compact
如果还在继续当前任务：
├─ 上下文使用率 < 60%：不用处理，200K 上下文足够承载大多数常规开发
├─ 上下文使用率 60% - 70%：观察是否出现噪音堆积，不必急着处理
└─ 上下文使用率 > 70%：如果已有明确阶段性结论，可以考虑 /compact
更口语化一点：
没聊明白就清空，聊明白了就压缩，聊得好好的就别动。
七、推荐搭配：/compact + 项目记忆
如果某个结论非常重要，不只是当前对话有用，而是以后长期都会用到，建议不要只依赖 /compact。
更好的方式是把它沉淀到项目记忆或项目规范里。
例如：
# 记录长期有效的踩坑教训
/memory add "MobX useLocalObservable 中修改 this 的方法不要用箭头函数"
# 再压缩当前上下文
/compact
这样可以形成两层记忆：
- 项目记忆：长期稳定规则
/compact：当前阶段上下文总结
这对于长期维护一个项目非常有帮助。
八、几个真实使用建议
1. 不要把 /compact 当成万能药
如果前面的对话方向本来就是错的，压缩不会让它变对。
它只适合提炼“已经形成的正确共识”。
2. 压缩前最好明确说出最终结论
在执行 /compact 前，可以先让 AI 总结一次：
请先总结本轮最终确认的技术方案、被否决的方案和后续编码注意事项。
确认总结没问题后再 /compact，效果会更稳定。
3. 长任务分阶段压缩，但不要机械化压缩
做一个大功能时，不建议从头到尾一个上下文硬撑到底。
不过在 200K 上下文模型下，也不需要每完成一个小步骤就 /compact 一次。更合理的做法是：只有当一个阶段真的形成了稳定结论，或者历史过程已经明显变成噪音时，再压缩。
可以按阶段处理：
- 需求分析完成，并确认范围后
/compact - 技术方案确认，并排除其他方案后
/compact - 核心代码完成，并通过基本验证后
/compact - 测试和修复完成，并明确最终根因后
/compact
这样 AI 始终带着“高质量上下文”继续工作，而不是为了压缩而压缩。
4. 对于错误尝试很多的调试任务，修复后一定要压缩
调试任务最容易污染上下文。
如果中间出现了 5 个错误猜测，最终只验证了 1 个真正原因，修复后最好压缩一次，避免后续又被旧猜测带偏。
总结
Claude Code 的上下文管理，本质上是在管理 AI 的“短期记忆质量”。
/compact 和 /clear 的选择，可以记住这句话：
聊崩了就
/clear，聊成了就/compact，聊得好好的就什么都不用做。
更具体一点：
/compact适合保留价值、清理噪音/clear适合彻底重置、重新开始- 项目长期规则应该沉淀到记忆或规范文件中
- 复杂任务应该分阶段压缩，而不是一口气撑到底
用好这两个命令，Claude Code 会更像一个稳定协作的工程搭档，而不是一个越聊越迷糊的聊天机器人。
