Claude Code 大多数问题的根源只有一个：上下文窗口装满了。装满后，性能下降、响应变慢、开始犯之前不会犯的错误。官方文档直接说："大多数最佳实践都围绕一个约束——上下文窗口填满得很快。"
这篇文章把所有上下文管理策略整理清楚。
上下文窗口里装了什么
每次 Claude Code Session，上下文包含：
- 所有对话历史（你的输入 + Claude 的回复）
- Claude 读取过的每一个文件的内容
- 每一条执行命令的输出
- CLAUDE.md 和所有规则文件
这些全都在同一个 Token 预算里。一个 Session 做的事越多、读的文件越多，留给实际任务的空间就越少。
策略 1：主动压缩，不要等到崩溃
错误做法：等到 Claude Code 开始表现异常再处理 正确做法：在 70% 时主动压缩
识别需要压缩的信号：
- 响应明显变慢
- Claude Code 开始重复之前说过的话
- 开始犯简单的错误（之前不会犯的）
/context命令显示使用率超过 70%
两种压缩命令：
# 通用压缩（保留关键信息，删除冗余历史）
/compact
# 定向压缩（明确保留什么）
/compact 保留：auth 模块的实现状态、当前未解决的 bug 列表、下一步计划
删除：之前的代码探索过程和已完成的任务记录定向压缩比通用压缩效果好得多。明确告诉 Claude Code 什么值得保留。
策略 2：一个 Session 只做一件事
违反直觉但非常有效。
即使你有 5 件事要做，也用 5 个 Session（或用 /clear 清空后开始下一个）。
原因：多任务 Session 的问题不只是上下文装满，而是不同任务的中间信息相互干扰，导致每个任务的质量都下降。
# 做完任务 1
/clear
# 开始任务 2（干净的上下文）例外：如果任务 2 依赖任务 1 的输出，用 /compact 而不是 /clear（保留任务 1 的结论，删除过程）。
策略 3：用 .claudeignore 在源头控制
上下文管理最有效的方式是在 Claude Code 读文件之前就排除掉不需要的文件。
.claudeignore 的关键作用：当 Claude Code 在分析代码库时，它不会尝试读取被忽略的文件。
# 必须排除（每个项目都要有）
node_modules/
dist/
build/
.next/
coverage/
# 锁文件（细节通常不需要）
package-lock.json
yarn.lock
pnpm-lock.yaml
# 日志和临时文件
*.log
*.tmp
*.map
效果：一个没有 .claudeignore 的 Next.js 项目，Claude Code 可能会尝试"看到" 50,000+ 个文件。有了正确配置的 .claudeignore，降到几百个。
策略 4：用临时 Markdown 文件传递上下文
对于复杂任务，不要把所有背景信息都在对话里解释，用文件传递：
# task-context.md（临时文件，任务完成后删除）
## 当前任务
重构用户认证模块，从 legacy-auth 迁移到新的 auth
## 已知问题
- legacy-auth/session.ts 有内存泄漏（issue #234）
- 新的 auth 还没有 OAuth 支持
## 不要动的文件
- src/lib/legacy-auth/oauth.ts（还在用）
- tests/auth/integration.test.ts（先不改测试）
## 完成标准
- 所有单元测试通过
- legacy-auth 除了 oauth.ts 全部停用
- 新增迁移文档 docs/auth-migration.md然后在 Session 开始时：
读取 task-context.md，然后按照里面的规划开始重构。
比在对话里解释效率高得多，而且 Claude Code 随时可以重读文件刷新记忆。
策略 5：Subagent 隔离上下文密集型任务
读大量文件的探索性任务，用 Subagent 隔离，不要在主 Session 里做：
主 Session（保持干净）
↓ 派发给 Subagent
Subagent：读取所有认证相关文件，分析现有实现，返回摘要
↓ 只有摘要回到主 Session，不是文件内容
主 Session：基于摘要制定实现计划
Subagent 的上下文在它自己那里消耗，不污染主线程。摘要通常是原始文件内容的 1/10 大小。
何时用 Subagent：
- 需要读 5 个以上文件来理解某个模块
- 探索性的"看看这个模块怎么实现的"类任务
- 并行研究多个独立的代码区域
策略 6：Plan Mode 减少上下文消耗
Plan Mode（Shift + Tab 两次切换，或 /plan）下，Claude Code 只分析不执行：
- 不读文件的完整内容（只看文件列表和摘要）
- 不执行命令（不产生命令输出）
- 只制定计划
一个复杂功能的规划阶段可能产生大量上下文。用 Plan Mode 做完规划，确认方向没问题，再切换到执行模式——这时上下文里没有规划阶段的探索过程，全是有用的实现内容。
策略 7：写高密度的 CLAUDE.md，不写啰嗦的
矛盾点：CLAUDE.md 每次 Session 都加载，会永久占用上下文。
解决方法：精准、高密度，删除所有"不写会让 Claude 犯错"以外的内容。
对比：
高密度写法（35 Token）：
数据库查询统一放 src/lib/db/，不要在 API 路由里内联
低密度写法（110 Token）：
为了保持代码的整洁性和可维护性，我们遵循关注点分离的原则，
所有与数据库相关的查询逻辑应该统一放在 src/lib/db/ 目录下，
而不是直接内联在 API 路由处理器里，这样做的好处是便于测试和复用。
两者传递的信息完全相同，但 Token 消耗差 3 倍。乘以 CLAUDE.md 里 50 条规范，差距非常可观。
上下文管理的优先级
按影响力排序，优先做影响最大的：
| 优先级 | 策略 | 一次性还是持续 | 影响 |
|---|---|---|---|
| P0 | 配置 .claudeignore | 一次性 | 极高 |
| P1 | 写精炼的 CLAUDE.md | 一次性 | 高 |
| P2 | 一 Session 一任务 | 持续习惯 | 高 |
| P3 | 70% 时主动 /compact | 持续习惯 | 中 |
| P4 | 用文件传递任务上下文 | 按需 | 中 |
| P5 | Subagent 隔离探索 | 按需 | 高（大项目） |
来源：code.claude.com 官方最佳实践 | morphllm.com 上下文管理 | 整理：ClaudeEagle