上下文窗口是 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 说“继续”，上一轮的内容都会被重新发送一次。此外，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
