/compact 深度拆解:上下文管理的正确打开方式

/compact 深度拆解:上下文管理的正确打开方式

上下文窗口膨胀是 Claude Code 工作质量下滑的主要原因之一。本文完整拆解 /compact、/clear、/context 三个命令的机制差异:/compact 压缩历史并重新注入 CLAUDE.md,/clear 干净切换任务,/context 诊断膨胀来源。附带带引导指令的压缩模板、任务切换决策表和配合日常节奏的维护节奏建议。

Claude Code 高级用法精读
2026/5/24 · 8:09
購読 1 件 · コンテンツ 5 件
上下文窗口是 Claude Code 里最真实的生产资源。它的大小直接决定模型能看到多少代码、多少对话历史、多少指令,进而决定每一步输出的质量。很多开发者在用 Claude Code 一段时间后都遇到同一个现象:工作越来越久,回复质量却在悄悄下降,有时还会冒出"context too long"的提示,被迫中断工作。
这篇文章完整拆解 Claude Code 的上下文管理机制,重点说清 /compact/clear/context 三个命令各自做什么、什么时候用哪一个,以及怎么配合日常工作节奏形成一套可持续的维护习惯。

上下文里装着什么

在讨论如何管理之前,先搞清楚上下文里到底有什么——这是判断"该清还是该压"的前提。
启动一个 Claude Code 会话后,还没输入任何内容,上下文就已经装了很多东西:CLAUDE.md 文件(所有层级的)、auto memory、MCP 工具名称列表、Skills 的描述文本。这些是「静态负载」,每轮对话都要携带 1
随着工作推进,每次 Claude 读取一个文件、执行一条命令、生成一次回复,相关内容就累积进去。到会话中段,上下文里通常混合了:
  • 你写的提示词
  • Claude 的所有回复
  • 被读取文件的完整内容
  • 命令执行结果
  • 路径相关规则(paths: frontmatter 触发后加载的)
这些内容不会自动消失。即便一个文件读取后已经用完,它的全文还留在历史里,继续占据 token 配额。
リンクプレビューを読み込んでいます…

/context:先看再动

在执行任何清理操作之前,有一个命令值得养成习惯先跑一遍:/context
它会把当前上下文占用以可视化方格的形式呈现出来,并按类别(CLAUDE.md、对话历史、文件读取、工具输出等)给出各部分的 token 占比,还会标出优化建议——比如"某个 MCP 工具一直在消耗配额但本会话没用到它"。
这个命令的价值在于避免盲目优化。很多时候上下文膨胀的真正原因不是对话太长,而是一个被反复引用的大文件,或者一个已经用不到的 MCP 服务一直挂着。定期看一眼 /context 比等到撑满才反应要经济很多 2
/cost/usage 的别名)可以配合 /context 一起用——前者看当前会话的 token 消耗和费用,后者看上下文在哪儿膨胀。

/compact:压缩而不是清空

リンクプレビューを読み込んでいます…
/compact 的工作机制是把当前会话的对话历史概括成一份结构化摘要,替换原有的历史内容,然后继续同一个会话 3
压缩后什么还在:
机制/compact 之后
系统提示词和 Output Style不变,不属于消息历史
项目根目录的 CLAUDE.md 和无 paths 前置的规则从磁盘重新注入
Auto memory从磁盘重新注入
已调用的 Skill 正文重新注入,单个 Skill 上限 5000 token,总上限 25000 token
paths: 的条件规则丢失,下次读到匹配文件时才重新加载
子目录里的嵌套 CLAUDE.md丢失,下次读到该子目录文件时重新加载
关键点是:主 CLAUDE.md 和 auto memory 都能在压缩后自动恢复,但只存在于对话历史里的内容(临时给出的指令、中途的设计决策)如果没有落进文件,就会随着压缩消失 1

什么时候用 /compact

不要等到上下文撑满才压。60% 占用时主动压缩,比等 Claude 自动触发要好得多。原因有两个:一是 60% 占用时模型输出质量已经开始下滑,提前压缩可以拿到更干净的上下文;二是主动压缩时可以添加引导指令,控制保留什么,被动触发时就只能靠模型自己判断 4
以 1M token 窗口为例:60% 时主动压缩,压缩后可降至 8% 左右,剩余 920K token 继续工作,相当于整个 Sonnet 窗口的两倍。

带引导指令压缩

直接跑 /compact 不带任何参数,模型会自行决定保留什么——长会话里这很容易丢掉你之后还需要的关键决策。在 /compact 后面加一两句说明,指定要保留的架构决策、文件路径或设计选择,效果明显更好:
/compact Preserve the auth refactor decisions: we chose JWT with
rotating refresh tokens, token service is in src/lib/auth/tokens.ts,
migration adds a refresh_tokens table.
/compact We're moving to phase 2. Preserve the route structure decisions
(REST for CRUD, webhooks for async events) and the middleware chain order.
Drop the TypeScript config debugging.
引导指令不需要写完整细节,只需要点出「这轮后续工作依赖哪些判断」就够了 4

/clear:换任务,不带包袱

/clear 的行为跟 /compact 本质不同。它不是压缩,而是开启一个全新的对话,对话历史完全清空,原有会话保留在 /resume 列表里,随时可以回去 3
用 /clear 的信号:
  • 下一个任务和当前任务毫无关联(比如刚做完 auth 模块,现在要去搞 UI)
  • 模型开始重复输出同样的内容,或者开始"乱"——通常是上下文里有冲突信息
  • 同一会话已经压缩过多次,每次都更稀薄
  • 当前会话的计划已经写进文件(TODO、CLAUDE.md、外部任务系统),不再需要通过上下文传递
/clear 不是放弃——跑 claude -c 随时可以回到最近一个会话,claude --resume 加名字或 ID 可以回到任意历史会话。可以把 /clear 理解成「下班打卡」,而不是「删档」。

对比:用哪个?

场景用法
任务进行中,上下文低于 60%,工作还在继续不操作,继续
到了一个阶段性节点,需要保留架构决策但不需要逐步实现细节/compact + 引导指令
切换到完全不相关的任务/clear
模型开始重复或出错,会话已多次压缩/clear
需要换 MCP 服务器、换分支或开 git worktree开新会话
这个决策框架来自社区实践,也对应官方文档的命令设计意图 3 4

/btw:旁白不进历史

有个容易被忽略的命令:/btw。它允许你在不把内容写进对话历史的情况下问一个问题——用于临时查一个无关的事,不想让这次对话污染当前会话的上下文。
配合 /compact 的场景:某个大型重构进行到一半,需要确认一个 API 的用法,但不想让这次查询进入压缩摘要,就用 /btw 提问 3

配合日常节奏的维护习惯

独立工具组合成一套节奏,才能真正控制上下文成本:
开始一个新任务前,把将要涉及的关键约束和决策写进 CLAUDE.md 或 auto memory。不要只在对话里口头说——对话历史会消失,文件不会。
工作进行中,每隔一段时间跑一次 /context,确认上下文占用在合理范围内。如果发现有某个 MCP 工具或大文件在持续占用但没在用,及时清理。
到达阶段节点,用 /compact + 引导指令压缩,把当前阶段的关键决策点名列出。类似做一次会议纪要——不是写进文件,而是告诉 Claude 摘要时要保留什么。
切换任务前,考虑要不要用 /clear。如果两个任务有上下文关联(比如先做了 schema 设计,现在要按设计实现),保留会话更好;如果完全独立,/clear 后重新开始通常更干净。
社区里有个经验值得参考:在 /clear 前先让 Claude 生成一份「handoff 文档」——用一段提示让它把当前状态、未完成的事项和关键决策汇总一遍,输出到文件,然后再 /clear。这样新会话开始时把这份文档 @ 进来,连贯性不会断 5

CLAUDE.md 与 /compact 的关系

リンクプレビューを読み込んでいます…
最后一个值得单独说的细节:压缩之后 CLAUDE.md 会被重新注入。这意味着写进 CLAUDE.md 的内容对 /compact 是免疫的——即便把对话历史压缩掉,项目规则、架构约定、常用命令都还在 1
这个机制的实践意义是:如果某个决策或规则在接下来很长一段时间都需要 Claude 遵守,把它写进 CLAUDE.md 而不只是在对话里说。对话历史会消失,CLAUDE.md 的内容永远跟着项目走。
反过来说,如果某个指令只适用于当前会话(比如「这次只改前端,不动后端」),就不要写进 CLAUDE.md。下次开新会话时这个指令还在,可能造成干扰。对话历史的短暂性在这里反而是优势 6

このコンテンツについて、さらに観点や背景を補足しましょう。

  • ログインするとコメントできます。