会话上下文窗口逼近上限时，Claude Code 提供了一对”看”与”治”的命令：/context 负责把当前窗口的 token 构成、占用大头、可优化点以可视化方式呈现出来，但不会动任何东西；/compact 负责把历史对话压缩成结构化摘要，让同一会话”瘦身续命”，但会丢掉部分中间过程。这一对职责的清晰分层，背后反映的是 Claude Code 把上下文窗口作为”一等资源”来治理的设计取向——把诊断与治疗分开，让用户能基于可视化的判断决定是否动手。
一、为什么需要把”诊断”和”压缩”分成两条命令
Claude Code 的会话窗口承载三类内容：系统提示词与 CLAUDE.md 指令、对话历史、工具调用结果。一段长会话下来，单是”读文件”和”跑测试输出”就能吃光大半窗口；模型不会主动告诉你”它已经忘了前 30 轮说过什么”，等到表现下滑再处理往往已经太晚。把诊断（/context）和压缩（/compact）拆成两条命令，是为了让”了解现状”和”动手治理”成为两个独立决策——前者永远零成本，后者可带提示。
二、两条命令的职责对照
| 维度 | /context |
/compact |
|---|---|---|
| 是否修改上下文 | 否，仅展示 | 是，替换历史为摘要 |
| 主要输出 | 彩色网格 + 各部分 token 占比 | 一段结构化摘要 + 续接会话 |
| 典型用途 | 诊断 token 都花到了哪里 | 释放空间，让同一会话继续推进 |
| 成本 | 零成本，只读本地会话元数据 | 触发一次模型调用生成摘要 |
| 与 CLAUDE.md 关系 | 在 Memory files 段列出已加载文件 | 摘要保留 CLAUDE.md 指令不被压缩 |
| 建议时机 | 上下文超过 50%、准备压缩前 | 上下文 70%–90%、任务阶段切换 |
一句话区分：/context 决定”该不该动手”，/compact 真的去动手。
三、/context：只看不动的诊断视图
/context 接收一个可选参数 all，输出包含四段：token 分布（系统提示词 / CLAUDE.md / 对话历史 / 工具结果各占多少）、Top 贡献者（哪些文件被读了多次、哪些工具输出特别大）、可执行建议（”建议删除某文件””建议执行 /compact”）、优化机会（路径限定、技能去重、MCP 缓存）。它会从本地 ~/.claude/projects/*.jsonl 读取会话元数据，不发起新的模型调用，是一个零成本的体检动作。
落地时按四步用：
- 在长会话任意节点执行
/context看基线； - 跑完一段大文件读取或测试套件后，再跑一次
/context看新增占用； - 看到某类文件被多次读取且无修改时，准备进入
/compact； - 准备压缩前再用一次
/context全量视图，确认要保留的”重点”。
下面是一次典型的输出形态（示意）：
⚠️ Top token consumers:
- src/legacy/old-api.ts (12.4k tokens, read 3 times)
- tests/fixtures/large-data.json (8.9k tokens)
💡 Suggestions:
- Remove src/legacy/ from context (not modified this session)
- Consider /compact (context at 73%)注意：这条命令不会真去删任何文件或清理上下文，它只告诉你”如果不处理会怎样”。
四、/compact：可携带保留指令的压缩动作
/compact 接收一段可选的提示词，作用是把此前的对话历史压成一段结构化摘要，并让会话从摘要处续接。它的工作方式有四个关键点：
- 调用模型生成摘要，原对话轮次被摘要替换；
- 最近约 10–15 条消息原样保留，避免”刚做的决策也被吃掉”；
- CLAUDE.md 指令、当前文件内容、工具状态原样保留；
- 典型能腾出 40%–60% 的可用空间，具体幅度取决于被压缩的轮次长度。
落地步骤按四步走最稳：
- 在自然的阶段边界（设计→实现、调试→修复）触发，不要等满了才压；
- 写明要保留的内容，例如
保留已确认的鉴权方案与未解决的边界 case； - 压完之后跑一次
/context复检，确认占比回落到安全区； - 在新阶段开始前再压一次，把上一阶段的试错过程丢掉。
下面给一个带提示词的压缩写法示例：
/compact 保留：
- 已确认的接口契约与命名
- 已修复的 Bug 与其根因
- 仍存在的边界 case 与下一步动作
丢弃：失败尝试、临时讨论、过期方案/compact 是”在同一会话内”延续工作的关键。释放空间的同时不丢”长期事实”，这是它与 /clear 的根本区别——后者会把对话清空、靠 CLAUDE.md 重新初始化，会话状态彻底换新。
五、这反映了 Claude Code 在哪一核心机制上的设计
两条命令的分层背后，是 Claude Code 把”上下文窗口当作一等资源来治理”的设计：会话从启动那一刻起，就同时存在”常驻成本”（系统提示词、CLAUDE.md、Skills 描述）和”会话成本”（历史、工具结果）两类占用。设计者没有把”什么时候压缩”完全交给模型自动决定，而是把它拆成”先看 /context，再做 /compact”的两步流程，把决策权留给用户。
具体表现为四个设计选择：
- 诊断零成本：
/context不发起模型调用，只读本地元数据，鼓励用户频繁用； - 压缩可带提示：
/compact接受自然语言提示词，把”什么值得保留”的判断权交还用户； - CLAUDE.md 永远在：被压缩的只是对话历史，常驻指令始终保留，因此压缩不丢”团队规则”；
- 自动压缩作安全网：当窗口逼近极限，会触发自动压缩，但生产实践中仍推荐在自然阶段边界手动压缩，让摘要抓住”干净状态”。
理解这一层之后，治理长会话就有了一条清晰的决策链：先 /context 体检 → 在阶段边界手动 /compact 并附上保留指令 → 跑完大段读取后再 /context 复查。
六、两个常见误区
第一个误区是”等到满了再压”。自动压缩虽然兜底，但它不知道哪条决策对你重要；满了才压意味着上一阶段的关键推理已经被挤掉。第二个误区是”频繁压”。过度压缩会丢”为什么”——决策理由被吃掉，Claude 在下一阶段就可能提出与早期结论冲突的建议，常见表现是”明明已经拒绝的方案又被翻出来”。
折中做法是：把”项目级”长期事实（架构、命名规范、不可妥协的约束）放进 CLAUDE.md，让它们永远不进入压缩；把”会话级”短期事实（这次会话的决策、未解决的 case）放在 /compact 的提示词里，让压缩只丢过程不丢结论。
常见问题（FAQ）
Q1：/context 会改变会话状态吗？
不会。它只读本地元数据、生成诊断视图，不修改任何上下文。
Q2：/compact 之后 CLAUDE.md 还在吗？
在。常驻指令永远保留，被压缩的只是此前的对话历史。
Q3：什么时候用 /clear 而不是 /compact？
任务目标彻底换新、与上一段对话无任何上下文重叠时，用 /clear 重置；否则用 /compact 续命。
