Claude Code 的上下文窗口是你当前会话的工作内存。它保存了你的对话、所有读取过的文件、MCP 工具定义、自定义代理配置、记忆文件以及工具调用的完整历史记录，就像 Claude Code 上下文窗口文档所描述的那样。当它满了时，你有三个选项：/compact、/clear 或用结构化交接启动新会话。你选择哪个会改变后续所有工作的质量。
选择压缩、清空或新会话
三个命令，三种不同的结果。理解区别是整个关键。
`/compact` 用压缩摘要替换对话历史记录并保持会话运行。上下文缩小了，会话继续进行，Claude 保留一些历史意识。你可以引导它保留什么：/compact focus on the auth bug fix 会告诉模型什么重要，而不是让它猜测。官方上下文窗口参考文档确认你可以直接向压缩步骤传递指令。
`/clear` 是硬重置。整个对话被删除。没有历史记录，没有内存中的文件上下文，没有任何遗留。正如 Damian Galarza 的上下文窗口分解所说，不先保存你的计划就使用 /clear 意味着你从零开始。有时这是没问题的，有时甚至是有意为之。
用交接文档启动新会话可以给你一个干净的开始并保持连续性。更多关于如何构建交接文档的内容见下文。
粗略的决策树：
- 同样的任务，需要更多空间：使用
/compact并附带焦点指令。 - 切换到无关的工作：使用
/clear。 - 任务对一个会话来说太大或质量已经下降：创建交接文档并重新开始。
一点需要说明：/autocompact 在你接近限制时自动运行。你可以设置窗口在多满时触发它，比如 /autocompact 500k，但自动步骤会自己决定保留什么。对于短会话这没问题。对于任何架构性的工作，你需要在自动步骤接管前手动运行 /compact。
查看消耗的上下文
在管理上下文之前，你需要看到它。运行 /context 你会得到一个分解：总上下文大小、消耗最多令牌的类别，以及显示分布情况的可视化条形图。官方学院的 Claude Code 101 讲解了这个输出。主要类别是对话历史、加载到会话中的文件内容、工具调用历史以及任何记忆或代理配置文件。
大多数开发者对工具调用历史感到惊讶。长时间的调试往来会迅速堆积。十几次文件读取，每次都有完整输出，会快速叠加。这通常是第一个需要处理的地方。
紧凑传递中保留的内容
根据官方文档，启动内容在紧凑后会自动重新加载。你需要留意的是对话本身的细微差别：具体的架构决策、重构背后的原因、你为什么拒绝了某个特定方案。这些会在重点紧凑中保留下来。它们通常不会在自动传递中保留，因为自动传递不知道你关心什么。
限定存储库读取和工具输出范围
你如何将文件读入会话和何时进行紧凑一样重要。当你只需要一两个函数时，读取整个目录或大文件是最快速烧掉上下文的方式之一。
一些有帮助的习惯：
- 要求Claude只读取你需要的特定文件和行范围，而不是整个模块。
- 当你需要研究大型代码库区域时，委托给子代理。文件内容保留在子代理的上下文中，而不是你的上下文中。你只会获得结果。官方上下文窗口文档明确指出："委托大型读取：将研究发送给子代理，这样文件内容保留在其上下文窗口中，而不是你的。"
- 避免重新读取你已经讨论过的文件，除非有变化。Claude已经在对话中拥有该内容。
- 使用grep和搜索工具调用时要具体。广泛的搜索会返回广泛的输出。
对于在Claude Code之上构建多代理工作流的任何人，Claude Code子代理指南涵盖了如何构建这些委托。如果你在SDK级别工作，Claude代理SDK指南会深入介绍代理之间的上下文边界。
如果你花在与上下文斗争上的时间比编写代码的时间还多，可能值得与全职从事这项工作的人谈谈。Seahawk的Claude Code开发团队可以从一开始就帮助你设置正确的项目结构。
紧凑时保留决策
这是大多数开发者跳过的步骤。在你紧凑或清除之前，要求Claude提供总结：
"在紧凑之前，给我一份我们做出的关键决策、我们明确拒绝的任何内容及其原因，以及工作的当前状态的项目列表。"
将其复制到你的CLAUDE.md或便签中。当你恢复时，将其粘贴为初始上下文。MindStudio的`/compact`命令指南将此描述为受控压缩和混乱压缩之间的区别：当你手动运行/compact时，你选择保留什么；当自动传递启动时，模型决定，它通常会保留平凡的输出而不是架构推理。
另一个杠杆是你的CLAUDE.md本身。架构决策、非显而易见的组件关系、Claude在这个代码库中不应该做的事情：这些应该永久存在那里，而不仅仅是在对话中。每个新会话都会自动加载CLAUDE.md，所以它是真正的上下文跨会话持久化的唯一地方。
何时不进行紧凑
- 在调试过程中，当特定的错误消息和堆栈跟踪仍然相关时。
- 在重构期间，当文件级细节被积极使用时。
- 在集成工作之前，该工作依赖于你刚构建的组件的上下文。
Claudefast 的上下文管理指南很好地总结了这一点：在工作阶段之间的自然断点处压缩，而不是在阶段进行中压缩。
拆分大型任务而不丢失交接
某些任务确实太大，无法在一个会话中完成。这不是失败，只是大型代码库的工作方式。答案是在会话结束前创建一份结构化的交接文档，而不是在质量已经下降后才创建。
有用的交接文档应该包括：
- 已完成的内容（带有提交引用或文件路径）。
- 正在进行的工作及其当前状态。
- 做出的决定及其原因（尤其是任何不明显的地方）。
- 接下来要做什么，提供足够的细节，使新会话可以继续进行，而无需重新阅读所有内容。
- 任何未解决的问题或阻碍因素。
LinkedIn 上的一位从业者将其描述为会话交接系统的核心：在设定的上下文使用量级别，会话会创建一份交接文档，其中包含已完成的工作、提交引用和当前状态。新会话以该文档作为第一条消息打开。JD Fiscus 在 LinkedIn 上发布的关于紧凑与清晰的文章描述了一个"任务 > 提交 > 清除 > 总结 > 重新扫描"循环，用于保持任务专注，这对迭代功能工作很有效。
具体的工作流程：
- 完成一个逻辑工作单元并提交。
- 要求 Claude 生成涵盖上述五个要点的交接摘要。
- 将摘要复制到你的代码库中的文件或
CLAUDE.md。 - 运行
/clear或开始新会话。 - 使用交接文档作为上下文打开新会话。
这样你就永远不会从零开始，也不会把杂乱的会话历史拖入需要清晰思路的工作中。
模型特定限制和故障排除
上下文窗口大小因模型而异。Damian Galarza 的文章提到 Claude Sonnet 4.5 的上下文窗口约为 200,000 个令牌作为参考点。其他 Claude 模型有自己的限制；查阅官方模型文档了解当前数据，而不是依赖可能已过时的社区数据。
需要注意的事项：
- 重复。Claude 开始提出你已经回答过的问题，或与早期的决定相矛盾。这表明相关上下文已被删除或总结不当。
- 忽视的指令。如果Claude停止遵循之前正确处理的项目约定，CLAUDE.md的内容可能已被挤出。运行
/context检查。 - 响应缓慢且成本高。大型上下文在每条消息中都会消耗令牌。如果成本在上升，
/context会告诉你原因。
值得注意的一点：关于通用压缩阈值（质量总是在特定填充百分比处下降的说法）不受官方文档支持。正确的压缩时机取决于具体任务。多位实践者的粗略启发法是在自然阶段边界处采取行动，在你看到性能下降之前而非之后。但结果会因任务类型、模型以及你的上下文中有多少密集代码与对话而异。
FAQ
`/compact`会消耗令牌吗？
会。压缩过程本身是一次模型调用，会消耗令牌。在阶段边界处手动运行它通常成本更低，因为它生成的摘要更清晰，后续消息消耗的令牌更少。
`/clear`会影响我的`CLAUDE.md`吗？
不会。CLAUDE.md是磁盘上的一个文件。/clear只删除当前会话的对话和记忆。下次Claude Code读取你的项目目录时，CLAUDE.md会自动重新加载。
我可以只压缩部分对话吗？
可以。运行/rewind，选择一条消息，然后选择"从这里总结"或"总结到这里"。官方上下文窗口文档描述了各个选项保留的内容。这在特定调试线程使上下文混乱但早期对话仍然重要时很有用。
同一仓库中的worktree共享上下文吗？
根据官方记忆文档，它们共享机器本地自动记忆。它们不共享会话上下文。每个worktree会话有自己的上下文窗口。
压缩后MCP工具定义会怎样？
官方文档表明启动内容（包括MCP工具定义）在压缩过程后自动重新加载。你不应该需要手动重新注册工具，但在复杂会话上压缩后运行/context以确认细分情况看起来正确是值得的。
这一切中最尖锐的警告：当你注意到质量下降时，你的压缩摘要可能已经包含了混乱的输出和好的输出。在干净阶段的末尾压缩，而不是在混乱阶段的开始。