Claude Code 最常见的问题之一：上下文越来越长，Claude 开始"忘事"，性能下降，额度消耗加速。这篇文章系统梳理 7 个上下文管理策略，帮你在长时间工作中保持 Claude Code 的高水准表现。
为什么上下文管理这么重要？
LLM 的上下文窗口是有限资源。当上下文过长时：
- 较早的信息会被"推远"，注意力下降
- Token 消耗加速（每次请求都要发送完整上下文）
- 性能下降（Claude 在非常长的上下文里会遗漏细节）
- 缓存命中率下降（长上下文变化频繁，缓存失效）
Opus 4.7 有 1M Token 上下文，但不代表可以无限堆积——即使在 1M 窗口内，长上下文也会影响推理质量。
策略 1：主动用 /compact，而不是被动等
错误做法：等到 Claude 开始表现变差了才想起来处理
正确做法：每 30-40 条消息主动运行一次
> /compact
/compact 把对话历史压缩成摘要，保留最重要的上下文，释放 Token 空间。压缩后的摘要比原始对话历史小得多，但保留了关键决策和状态。
何时特别需要 /compact：
- 开始了一个新的子任务
- 已经解决了一个问题，开始下一个
- 发现 Claude 开始重复之前做过的分析
策略 2：任务边界用 /clear
/compact 和 /clear 的区别：
/compact：压缩历史，保留摘要，继续在当前任务上下文里工作/clear：清除全部上下文，完全重新开始
适合用 /clear 的场景：
- 完全切换到不相关的任务
- 上一个任务已经完成，准备开始全新的工作
- 当前上下文里有太多"噪音"干扰新任务
# 完成了 auth 模块的重构
> /clear
# 重新开始，处理完全不同的 UI 组件
策略 3：用 @ 精确指定上下文，而非让 Claude 搜索
低效（Claude 需要搜索整个代码库）：
> 帮我优化用户登录的错误处理
高效（精确指定）：
> @src/api/auth.ts 优化第 142-180 行的错误处理逻辑，
参考 @src/types/errors.ts 里定义的错误类型
精确指定文件路径：
- 减少搜索时间
- 减少无关文件进入上下文
- Claude 的注意力更集中
策略 4：分离探索会话和执行会话
# 第一个 Terminal：只读探索
claude --allowedTools Read,Grep,Glob
# 在这里分析代码库，理解架构，制定计划
# 不做任何修改，上下文保持干净
# 第二个 Terminal：执行
claude
# 基于探索阶段的结论，执行具体任务探索阶段往往会产生大量"观察"和"思考"内容，这些内容在执行阶段不再需要。分离两个会话可以让执行阶段保持干净的上下文。
策略 5：用 CLAUDE.md 替代重复指令
每次都要重复（浪费上下文）：
> 记住要用 TypeScript strict 模式，用 Zod 验证输入，
不要直接暴露数据库 ID，用 UUID 替代...
[重复 20 次同样的内容]
一次配置，永久生效：
# CLAUDE.md
## 代码规范（每次都必须遵守）
- 使用 TypeScript strict 模式
- 所有 API 输入用 Zod 验证
- 对外 ID 统一用 UUID，不暴露数据库自增 ID
- SQL 查询必须使用参数化查询CLAUDE.md 的内容在每次会话开始时自动加载，不占用对话历史 Token，且可以用 Prompt Cache 缓存（大幅降低成本）。
策略 6：用 Session 分组管理任务
按任务类型开不同 Terminal：
Terminal 1：长期功能开发（保持持续 Session）
Terminal 2：Bug 修复（每个 Bug 用 /clear 重置）
Terminal 3：代码审查（只读，经常 /clear）
Terminal 4：实验性探索（随意，不担心污染其他 Session）
不同性质的任务有不同的上下文需求：
- 长期功能开发需要记住架构决策 → 保持 Session，定期 /compact
- Bug 修复通常是独立的 → 每次用 /clear 开始
- 代码审查不需要修改状态 → 只读工具，经常 /clear
策略 7：用 /usage 监控，找到消耗热点
> /usage
新的 /usage 命令（v2.1.105）显示用量细分：
- 并行 Session 占比
- Subagent 调用占比
- 缓存未命中占比（重点关注）
- 长上下文占比
缓存未命中率高：说明上下文变化频繁，考虑稳定 CLAUDE.md 内容，减少每次会话的变量部分。
Subagent 调用多：检查是否可以把任务设计得更集中，减少子任务切换。
长上下文占比高：提醒自己用 /compact 更频繁。
Prompt Cache 优化（API 用户）
对于使用 Claude API 的用户，开启 1 小时缓存 TTL：
export ENABLE_PROMPT_CACHING_1H=1什么会被缓存：
- CLAUDE.md 内容（稳定，高缓存命中率）
- System Prompt
- 较早的对话历史（稳定部分）
什么会缓存失效：
- 每次新的用户消息
- 每次工具调用结果
策略：把稳定的内容（规范、架构文档）放到 CLAUDE.md，通过 @ 引入，而不是在对话里重复发送。
各场景推荐配置
| 场景 | 策略 |
|---|---|
| 长时间功能开发（>2小时） | 每 40 条消息 /compact，任务切换 /clear |
| 大型代码库探索 | 先只读 Session 探索，再开新 Session 执行 |
| 多任务并行 | 每个任务独立 Terminal，互不干扰 |
| Bug 修复 | 每个 Bug 用 /clear 开新 Session |
| 团队共享工作流 | 把所有规范放 CLAUDE.md（提交到 git） |
Opus 4.7 的 1M 上下文的正确使用方式
Opus 4.7 的真正 1M 上下文（v2.1.119 修复了显示不准确的问题）适合：
- 分析超大型代码库（一次性加载整个项目）
- 长时间的 Agent 任务（不需要频繁 /compact）
- 复杂的跨文件重构
即使有 1M 上下文，以上策略仍然有价值：减少不必要的 Token 消耗，降低成本，让 Claude 的注意力更集中在当前任务相关的内容上。
来源：Claude Code 官方文档 - Interactive Mode | Anthropic API 缓存文档 | 整理：ClaudeEagle