Claude Code上下文窗口：监控与优化实战指南
上下文窗口是 Claude Code 最核心的性能瓶颈，没有之一。掌握它的工作机制，才能真正高效驾驭 Claude Code。
Claude Code 默认提供 200K token 的上下文窗口。如需更大的处理能力，可通过 opus[1m] 或 sonnet[1m] 扩展至 1M token。但无论容量多大，本质仍是有限的“工作内存”。
这个上下文具体包含哪些内容？简言之：用户对话历史 + CLAUDE.md + Skills + MCP工具定义 + 文件内容。这五部分叠加，才是 Claude 当前能够“感知”的全部信息。
一、上下文窗口的定义与核心价值
定义
上下文窗口是指 Claude 在单次会话中能够“关注”的最大文本量。一旦超出阈值，早期对话内容会被强制丢弃。
为什么关键
试想：你让它重构一个模块，它读取了 50 个文件后，你接着说“继续”，它却反问“我们刚才在做什么？”。这就是上下文溢出——它已经遗忘了之前的任务状态。
与普通聊天的差异
普通聊天和 Claude Code 的上下文消耗模式截然不同。普通对话仅涉及历史文本，增长缓慢，易于管理。但 Claude Code 需同时承载对话、文件、配置等多类信息，文件读取会迅速消耗大量额度。
二、上下文消耗的详细来源
主要来源
不同来源的消耗量级差异显著。对话历史随轮数增长，典型范围 1‑50K；CLAUDE.md 每次请求必带，约 1‑10K；Skills 按需加载，0.5‑5K；MCP 工具定义每项累积 1‑20K；文件读取是最大消耗源，单文件可达 1‑100K；子 Agent 返回的结果也会占用主会话上下文，约 1‑10K。
隐形消耗项
某些消耗不易察觉。例如每次说“继续”，上一轮完整内容会被重新发送。又如 CLAUDE.md 写得过长，每个请求都背负这个包袱。再如 Skills 的 reference 文件被加载、MCP 服务的工具列表、子 Agent 返回的详细报告——这些都在无形中蚕食宝贵上下文。
三、监控上下文使用状态
实时查看命令
输入 /context 可查看当前上下文的分类占比及优化建议。输入 /cost 可获取 token 用量与费用估算。
扩展上下文
若 200K 不满足需求，可扩展至 1M。启动时添加 claude --model opus[1m] 或 claude --model sonnet[1m]，或在对话中执行 /model opus[1m] 切换。此模式尤其适合大型代码库分析、长时间会话及批量文件读取场景。
分阶段使用策略
根据上下文占用百分比，采取差异化操作：
0‑50% 为充足状态，放心推进。50‑70% 进入警戒线，准备压缩。超过 70% 立刻执行 /compact。达到 90% 以上属高危区域，必须 /clear 清空重启。
上下文紧张的前兆
当 Claude 开始询问“我们之前在做什么？”、重复已确认的内容、忘记已做的决策，或 /context 显示接近上限，这些都是上下文即将耗尽的典型信号。
四、上下文压缩：/compact 命令
/compact 命令压缩对话历史，仅保留关键信息。例如压缩前 50 轮对话、80K token，压缩后变为摘要+关键决策，仅 15K token。
触发压缩的时机
上下文超过 70%、对话超过 30 轮、Claude 出现“失忆”现象，或切换新话题前，都是执行压缩的最佳节点。
压缩后的信息留存
压缩会保留：关键决策、重要结论、当前任务状态。但详细的讨论过程、失败的尝试、闲聊内容会被丢弃。这是必要的取舍。
五、上下文清空：/clear 命令
当上下文超过 90%、准备启动完全不相关的新任务、Claude 行为异常需重置，或压缩后仍不够用时，使用 /clear 彻底清空会话。
清空后的恢复步骤
清空后需依次完成：重新说明任务背景、重新加载必要的 CLAUDE.md、重新读取关键文件。虽然繁琐，但这是最彻底的解决方案。
六、减少上下文消耗的工程实践
精简 CLAUDE.md
一份 50 行的 CLAUDE.md 可能充满注释与示例，但你需要的是仅含核心规则、精简至 20 行的版本。每一点冗余都是对上下文的浪费。
利用子 Agent 隔离负载
与其让主会话直接分析整个项目架构，不如交给子 Agent 处理，仅返回关键发现。这样既完成任务，又不挤占主会话上下文。
Skills 延迟加载
在 Skills 配置中设置 disable-model-invocation: true，可实现延迟加载——Skills 仅在手动调用时激活，不会自动占用上下文。
分阶段任务切割
不要试图一次性完成所有工作。重构完认证模块后执行 /clear，再启动支付模块。每个独立任务结束后清空上下文，这是最干净的工作方式。
七、高级技巧
上下文预算分配
默认 200K 模式下，建议分配：CLAUDE.md 5K，Skills 5K，MCP 工具 10K，对话历史 30K，文件内容 150K。切换到 1M 扩展模式后，对话历史可增至 100K，文件内容可占用 880K，其余保持不变。
精准文件选择
避免读取整个 src/ 目录。例如只读 src/auth/*.ts。文件选择越精确，上下文消耗越可控。
对话简洁原则
与 AI 对话不要像写日记。“我昨天遇到一个问题，当时正在做……然后我发现……所以我想……”这种冗余表达应彻底避免。直接说“认证模块报错 401，排查原因”即可。
利用 Memory 节省上下文
Memory 不占用上下文窗口。项目关键决策、个人偏好、重要背景等都可以存入 Memory。
八、常见问题解答
Q: 为什么 /compact 后上下文仍然很高？
A: 文件内容不会被压缩。压缩仅针对对话历史。如果文件内容体积本身就大，压缩对话效果有限。
Q: 子 Agent 会消耗主会话上下文吗？
A: 不会。子 Agent 拥有独立上下文窗口。但子 Agent 返回的结果会占用主会话上下文。
Q: MCP 工具定义占用多少？
A: 每个 MCP 服务约占用 1‑5K token，具体取决于工具数量。
Q: 如何定位具体是哪些内容占用了上下文？
A: 目前没有官方细粒度排查工具。可用 /cost 查看总量，具体成分依赖经验判断。
Q: 200K 不够用怎么办？
A: 五种解决方案：一是通过 --model opus[1m] 或 --model sonnet[1m] 扩展到 1M token；二是更频繁执行 /compact；三是分阶段完成任务；四是使用子 Agent；五是精简 CLAUDE.md。
九、要点总结
核心操作闭环
上下文管理可归纳为四个动作：监控——定期用 /cost 检查使用情况；压缩——70% 时执行 /compact；清空——90% 时执行 /clear；预防——精简配置，分阶段工作。
最佳实践清单
CLAUDE.md 保持精简，最好在 200 行以内。大文件分析交给子 Agent。对话直接、不啰嗦。切换任务前主动 /clear。Skills 设置延迟加载。这些是经过实战验证的有效做法。
上下文管理检查清单
最后，对照以下项目自检：
□ CLAUDE.md 是否超过 200 行？
□ 是否有不必要的 Skills 自动加载？
□ 对话是否超过 30 轮？
□ 在读大文件前是否检查过上下文？
□ 切换任务前是否执行压缩或清空？
参考文档
• Claude Code 上下文窗口官方说明 — https://code.claude.com/docs/en/context-window
• Claude Code 模型配置指南 — https://code.claude.com/docs/en/model-config
• Claude Code 官方文档 — https://code.claude.com/docs