目录

Claude Code 的 /compact 不是那种要像定时器一样定期按下的东西。该按的时刻是工作的节点——一个任务刚结束，下一个任务即将开始的那一刻。官方文档就是这么写的：「在工作的自然断点处运行 /compact，例如在任务与任务之间，而不是等自动压缩在任务中途触发」（Claude Code 官方文档「Prompt caching」）。

「每 30 分钟按一次」「上下文超过 70% 就按」这类以时钟或百分比为准的用法，瞄错了目标。理由本文会逐条说明，先给结论：一次压缩的费用与损失，不取决于「你什么时候按的」，而取决于「你丢掉了什么」以及「缓存是不是热的」。

📌 本文的事实来源：文中的规格、版本号与设置名，均在2026 年 8 月 8 日依据 Claude Code 官方文档与发布说明核对（当时最新版为 v2.1.226／2026-08-08）。Claude Code 更新很快，压缩相关的行为即使在最近几版里也还在增加（/autocompact 需要 v2.1.221 及以上）。请用 claude --version 确认自己手上的版本。

1. 结论——不是「定期按」，而是「在节点按」

先把判断标准列成表。它的用途是让你按情境而不是按时钟来决定按或不按。

✅ 该按的时候

刚做完一个任务，马上要进入一段长活儿。此时上下文还有富余也没关系。目的是把自动触发的时机主动提前，让接下来的工作不被中途打断。

🟡 用 /clear 更好的时候

下一件事和上一件毫无关系。既然连摘要都不需要，就没必要为生成摘要付费。官方说得很直白：「如果你想要的是重新开始而不是延续，/clear 是免费的」。

🔵 用 /rewind 更好的时候

你想把整个走过的方向都丢掉。回退是截断回到一个已经被缓存的位置，所以比要重建全新前缀的压缩更便宜。

❌ 不该按的时候

任务的中途。接下来还要用的细节会被摘要压平。每一次「以防万一」的压缩，换来的都是紧接着把同样的文件再读一遍。

区分这四种情况的只有一个问题：你正准备丢掉的东西，后面还用得上吗？借用官方文档的说法，「只有当你丢掉的上下文确实已经不再需要时，压缩才是划算的」。定期执行等于放弃了这个判断，所以有时蒙对、有时蒙错——而蒙错时的损失，比蒙对时的收益更大。

2. 压缩分三层——官方文档究竟写了什么

在考虑「要不要手动按」之前，得先了解你什么都不按也在运转的机制。上下文快满的时候，Claude Code 并不会一上来就摘要整段会话。官方文档是这样说明的。

「Claude Code 在接近上限时会自动管理上下文：先丢弃旧的工具输出，必要时再摘要会话。你的请求和重要的代码片段会被保留，但会话早期的详细指示可能会丢失。持久性的规则要放进 CLAUDE.md，而不要指望会话历史。」（How Claude Code works）

也就是说这里是分层的：①丢弃旧的工具输出 → ②自动摘要会话 → ③你按下的 /compact，一共三层。

① 丢弃工具输出

会话本身毫发无损，只有旧的工具结果被剥掉。你什么都不用做。这一层在轮到摘要之前就先干活了。

② 自动压缩

当第①层不够用时，会话本身被摘要替换。这与手动 /compact 是同一套处理，唯一的区别是「什么时候跑」。

③ 手动 /compact

它唯一也是最大的作用，就是把第②层提前到你方便的时刻。除此之外，你还能指定保留什么——这是它与第②层的另一处不同。

这就是「该不该定期执行」这个问题的核心。手动 /compact 只是把放着不管也会发生的事提前，它并不是一根「拉得越勤、省下的上下文越多」的杠杆。它值得按下，只有在「自己挑时机」这件事本身有价值的时候。

⚠️ 关于术语。有好几篇文章把第①层叫作「微压缩（micro-compaction）」，但截至 2026 年 8 月 8 日核对的范围，官方文档并没有使用这个名称。官方给出的只是对行为的描述——先丢弃旧的工具输出。如果你按这个名字去搜却找不到官方资料，原因就在这里。

3. 什么会留下，什么会消失

压缩过程中你的规则会怎么样，完全取决于它是以什么方式被载入的。官方文档按机制列了一份清单，这里照着整理一遍。

机制 压缩之后 实际意味着什么
system prompt 与输出风格 不变 因为它们并不属于会话历史
项目根目录的 CLAUDE.md与不带作用域的规则 从磁盘重新注入 最安全的存放处。你的编辑也是在这里最终生效的（见第 8 节）
自动记忆 从磁盘重新注入 它本来就是跨会话保留的机制，活过一次压缩是最起码的
带 paths: 的规则 丢失（直到再次读取匹配的文件） 想保留就去掉 paths:，或把规则搬进根目录的 CLAUDE.md
子目录里的 CLAUDE.md 丢失（直到再次读取该目录下的文件） 同上，而且是最容易被忽略的缺失
你调用过的技能正文 会重新注入，但有上限 每个技能 5,000 token、合计 25,000 token，超出部分从旧到新丢弃
钩子（hooks） 不受影响 因为它们是作为代码运行的，不是上下文

从这张表能得出三条实用结论。

第一，只要你预期会被压缩，就把丢不起的规则放进项目根目录的 CLAUDE.md。这是官方反复强调的一点。带 paths: 的规则和子目录里的 CLAUDE.md，是拿每次压缩都会掉出去换来的便利——而且掉了之后屏幕上不会有任何提示。

第二，技能文件的开头才是命门。重新注入时的截断规则是保留文件开头，所以 SKILL.md 里重要的指示必须写在上面。另外，按官方关于上下文的说明，会话开始时载入的技能列表在 /compact 之后不会重新注入，只有你真正调用过的技能才会保留。

第三，「丢了什么」不会有人来告诉你。正因如此，那条原则才成立：丢了会疼的东西，要放在文件里，而不是放在会话里。

4. 费用不由上下文的大小决定

「上下文越大，/compact 就越贵」这个想法很自然，但只对了一半。真正起作用的是提示词缓存（prompt cache）是不是热的。官方是这么解释的。

「为了生成摘要，Claude Code 会发出一次单独的请求，带上同样的 system prompt、工具和历史，并在末尾追加一条摘要指示。只要缓存还是热的，这次请求就会从缓存里读取你的前缀，因此比按上下文大小想象出来的便宜得多，绝大部分时间花在生成摘要上。（中略）在超过缓存存活时间的休息之后，已经没有缓存可读，摘要请求会把整段历史当作未缓存的输入重新处理一遍。这就是为什么恢复一个旧会话时 /compact 最贵。」（Prompt caching）

这一段，就是反对「定期执行」这种做法最有力的依据。

工作中途按（缓存热）

前缀从缓存里读。你感受到的只有「写摘要的那段时间」。这里按一次是便宜的。

休息之后按（缓存冷）

要先把整段历史重新读一遍，才轮到摘要。同一条命令最贵的瞬间。「早上先来整理一下」有可能是最糟的一步棋。

按下之后的那一轮

缓存是用一段简短的摘要重建的，所以这一段并不重。「压缩之后就变慢了」的印象，多数来自上面两种情况，而不是这里。

缓存的存活时间取决于你的认证方式。使用 Claude 订阅时会自动请求 1 小时的 TTL；通过 API 密钥或云服务商则默认是 5 分钟（ENABLE_PROMPT_CACHING_1H=1 可以改成 1 小时）。换句话说，「午饭回来先按一下 /compact」在 API 密钥的用法下几乎必定是一次冷缓存执行。

另外，/compact 自身就是一次大请求这一点，官方的成本文档也特意强调过：「/compact 要读取它所摘要的会话，因此压缩一个庞大的上下文本身就是一次庞大的请求。如果你想要的是重新开始而不是延续，/clear 是免费的。」（Manage costs effectively）。从节省 token 的角度看也一样，很多场合下，/clear 比出于惯性按下的 /compact 更正确。

5. /compact、/clear、/rewind、/recap 怎么选

给上下文减负的手段不止 /compact 一个。把目的不同的命令搞混，结果就是花钱买了贵的那个。

命令 会话历史 缓存 什么时候选它
/compact [指示] 被摘要替换 会话层被失效 还要继续做，但历史的细节已经不需要了
/clear [名称] 清空 重建（完全没有摘要费用） 下一件事毫无关联。起个名字就能用 /resume 找回来
/rewind 截断回到更早的位置 命中旧的缓存 想把整个方向都丢掉。代码也能一起回退
/recap 不动（只是显示一份摘要） 原样保留 只是想读一读「到目前为止的梳理」
/context [all] 不动 保留 按下任何键之前先测量。用配色显示是什么在占地方

/recap 值得记住。不少人按 /compact 的动机其实是「聊得太长了，想让它梳理一下」——可这个目的根本不需要毁掉历史。按官方说明，/recap 只是把摘要作为命令输出追加到末尾，被缓存的前缀原封不动。

/rewind 的性质同样重要。官方的说明是，回退会让你回到「当时被缓存的那份内容」，所以下一次请求会命中旧的缓存。走错方向时的正确答案是 /rewind，不是 /compact——因为压缩要造一个新的前缀，而回退只是退回到一个已经存在的前缀。检查点与回退有专门的一篇文章。

6. 自动压缩的触发点可以自己定

在纠结「要不要手动按」之前，值得先知道一件事：自动执行的触发位置本身是可以挪的。从 v2.1.221 起，/autocompact 命令可以指定「上下文填到多满才触发自动压缩」。

把窗口设为 500K token（会保存到用户设置，之后的会话同样生效）

/autocompact 500k

恢复为与模型匹配的默认值

/autocompact auto

接受的范围是 100K 到 1M token。可以写 200000 这样的纯数字，也可以写 500k / 1M 这样带后缀的值，还可以写 200 这种 100 到 1000 之间的裸数字（按千计）。设置可以来自四个地方，而且优先级是固定的。

① 环境变量（最高）

CLAUDE_CODE_AUTO_COMPACT_WINDOW。只要它被设置，就会覆盖命令、启动参数和设置文件

② 启动参数

claude --autocompact 500k。只对这一次启动生效，不改动已保存的设置

③ 命令

/autocompact。会写入用户设置里的 autoCompactWindow

④ 设置文件

autoCompactWindow。如果组织的托管设置压在上面，那一份会赢

⚠️ 只有环境变量的写法不一样。官方文档明确写道，CLAUDE_CODE_AUTO_COMPACT_WINDOW 只接受纯整数，像 500k 这样的值会被读成 500，并被钳到 100K 的最小值。照着命令的写法去写，等于只申请了你本意的千分之一，然后被钳上去，反而压缩得更频繁。

同一处还有第二个提醒。状态栏的 used_percentage 始终是相对模型完整上下文窗口的百分比，所以一旦设置了这个环境变量，那个百分比就不再代表压缩何时触发了。「盯着百分比手动按」这套用法，正是在这里失效的。

完全不设置窗口时的默认行为，官方也写明了。什么都不配置时，压缩会在触及模型上下文上限时发生，但有例外——云端会话会在接近上限时提早压缩，未启用扩展上下文的 Sonnet 4.6 / Opus 4.6 在 200K 的边界上压缩，在 Amazon Bedrock、Google Cloud 的 Agent Platform 或 Microsoft Foundry 上以 200K 上下文运行的 Opus 4.8 / Opus 5 同理，而 Sonnet 5 则按该模型自身的默认阈值触发。

自动压缩本身也可以关掉：把设置 autoCompactEnabled（默认 true，在 /config 里显示为「Auto-compact」）设为 false，或者使用环境变量 DISABLE_AUTO_COMPACT。但不推荐这么做。关掉它并不会让上下文变少，只是让它撞上天花板，把压缩换成 「Prompt is too long」错误而已。自动压缩是在保护你的功能，不是在碍事的功能。

7. 定期执行会适得其反的三种场景

把上面这些规格摆在一起，「反正定期按一下」在哪些地方亏钱就很清楚了。

① 在任务中途按

接下来还要用的细节被摘要压平。而且带 paths: 的规则和子目录的 CLAUDE.md 会掉出去，于是紧接着的工作开始悄悄地偏离你的规则。这是一种很难看出原因的劣化。

② 休息回来第一下就按

缓存已经过期，所以要先把整段历史重新处理一遍再摘要。这是同一个 /compact 最贵的瞬间——偏偏「先整理一下再开工」这份好意最容易撞上它。

③ 在很短的会话里按

没有值得摘要的历史时，只会返回 Not enough messages to compact. 一次巨大的粘贴就把上下文填满时同样会发生——这时正确答案是 /clear，而不是摘要。

反过来说，规律就是：手动压缩价值最高的那一次，是即将开始一段长活儿之前的那一次。在那里按下，能降低长活儿进行到一半被自动压缩打断的概率。有意义的是时机，不是次数。

8. 实战——按下之前做的事更重要

/compact 真正见效的地方，不是怎么按，而是按之前把什么落到了文件里。正如第 3 节的表所示，项目根目录的 CLAUDE.md 与自动记忆会从磁盘重新注入。写在那里的东西，压缩多少次都活得下来。

还有一个常被忽略的性质。会话进行中编辑 CLAUDE.md，当场并不会生效。官方文档的说法是「编辑不会让缓存失效，但编辑本身也不会生效。新内容会在下一次 /clear、/compact 或重启时载入」。反过来读，这意味着 /compact 同时也是「让工作中途定下的规则真正开始生效」的操作。

按下之前的检查清单

  • 这次会话里定下的规则与方针，写进文件了吗（只存在于会话里的东西会被摘要稀释）
  • 想保留的内容，写进指示了吗——像 /compact 保留认证相关的修改方针和测试结果 这样把焦点交给它
  • 接下来要做的事真的是上一件的延续吗。如果毫无关联，/clear 更便宜
  • 现在缓存还热吗（避开长时间休息刚结束的那一刻）
  • 拿不准就用 /context 实测到底是什么在占地方

接下来这一点，是打算手动压缩的人最容易漏掉的。「怕它背着我压缩、把话头压没了，所以我先下手为强自己按」——这种用法并不少见。可官方文档就在讲完自动压缩之后紧接着写道：要控制压缩过程中保留什么，就在 CLAUDE.md 里加一节「Compact Instructions」，或者运行带焦点的 /compact（How Claude Code works）。

换句话说，指定焦点并不是「自己按」才有的特权。写进 CLAUDE.md，它同样对你离开座位期间自动跑起来的那次压缩生效。如果你先下手为强的手动流程，目的是决定上下文怎么被裁剪，那么真正管用的是这一版——手动流程只在你盯着的时候才有效。

写法并不难。官方文档给出的示例是这样的。

放进 CLAUDE.md 的默认压缩指示（官方文档的示例）

# Compact instructions

When you are using compact, please focus on test output and code changes

顺带说说本站是怎么做的。这个博客仓库的 CLAUDE.md 里，很早就写着两条规则——「上下文变长时，要向用户建议 /compact」「执行 /compact 之前，要把应该固化成规则的内容（反馈、方针决定等）保存到记忆里」。这篇文章本身就是在一次经历过压缩的会话中写成的。就实际体感而言，起作用的不是前者，而是后者。比起费心去雕琢摘要里留下什么，事先把该留的东西落进文件，效果确定得多。

还要补充一点：减少上下文的手段不止 /compact。官方的成本指南建议把输出量大的活儿——跑测试、抓文档、处理日志——交给 subagent。subagent 拥有自己的上下文窗口，回来的只有一份摘要，所以主上下文根本不会膨胀。把局面做成不需要压缩，比压缩得漂亮更高明。

9. 出问题时会遇到的两条消息

实际按下去之后，有两条不太好懂的消息可能会出现。

消息 含义 对策
Not enough messages to compact. 没有值得摘要的会话。一次巨大的粘贴填满上下文时也会出现 用 /clear 重新开始
Autocompact is thrashing: the context refilled to the limit... 压缩成功了，但巨大的文件或工具输出紧接着又把上下文填满，如此反复了几轮。它为了避免死循环而停了下来 右侧的四步（官方推荐的顺序）

后者的恢复步骤，官方文档按顺序写得很清楚：①把巨大的文件按行范围或按函数拆开来读 ②压缩时指明想丢掉哪些输出（例如 /compact keep only the plan and the diff） ③把那件活儿挪到 subagent，让它在另一个上下文窗口里跑 ④如果之前的会话已经不需要了，就 /clear。关键在于第①步排在最前面——官方等于是在说，这不是「压缩的问题」，而是「读法的问题」。

总结

没有必要定期手动执行 /compact。自动压缩你不管它也会跑，而且是同一套处理。自己按下所能换来的，只有「时机由自己挑」和「可以指定保留什么」这两点，而这两点能起作用的地方，集中在任务与任务之间这一处。

从费用上看，定期执行同样吃亏。一次压缩的价格由缓存是否温热决定，所以休息之后那句「先整理一下再开工」正是它最贵的版本。如果重新开始就够用，/clear 是免费的；如果是转向，/rewind 因为退回到已有的缓存而更便宜；如果只是想读一份摘要，/recap 不会破坏历史。按目的从四者中挑对的那个，比把同一个按得更勤有用。

不过最实用的结论，在「怎么按」之外。丢不起的东西，要放进文件，而不是放在会话里。项目根目录的 CLAUDE.md 与自动记忆会从磁盘重新注入，而带 paths: 的规则和子目录里的 CLAUDE.md 会悄无声息地掉出去。知不知道这份不对称，决定了一段长会话是撑得住还是慢慢变糟。

FAQ

Q1. 说到底，/compact 该每隔几分钟按一次？

不该用时间来定。唯一推荐的时机是一个任务刚做完、下一段长活儿即将开始之前。官方文档写的是「在工作的自然断点处，例如在任务与任务之间」，并没有给出时间或百分比的标准。

Q2. 完全交给自动压缩可以吗？

自动和手动是同一套处理，区别只在于什么时候跑。问题在于自动的那次可能在任务中途打断你。在一段长活儿之前手动按一次，能降低这种打断的概率。而且「保留什么」也可以对自动的那次下指示——在 CLAUDE.md 里用 # Compact instructions 这个标题写好，它对你离开座位期间跑起来的压缩同样生效（见第 8 节）。

Q2-2. 它自作主张压缩之后，我感觉指示不好使了

不是错觉。官方文档明确写着「会话早期的详细指示可能会丢失」。此外，带 paths: 的规则和子目录里的 CLAUDE.md 会一直缺席，直到匹配的文件被重新读取，而调用过的技能一旦合计超过 25,000 token，也会从旧到新被丢弃。与其说是内容消失了，不如说是被遵守的规则在悄悄变少，所以工作还在继续，只有准确度掉了下来。对策有三条——①把想长期生效的规则搬进根目录的 CLAUDE.md（会被重新注入） ②用 # Compact instructions 指定要保留的内容 ③用 /autocompact 把触发位置提前，别让压缩发生在贴着天花板的位置。

Q3. /compact 和 /clear 该用哪个？

下一件事是上一件的延续就用 /compact，毫无关联就用 /clear。官方的成本文档直接写明「如果你想要的是重新开始而不是延续，/clear 是免费的」。给 /clear 传一个名称，就能从 /resume 的列表里回到那个会话，也不用怕东西没了。

Q4. 压缩会把 CLAUDE.md 的规则也抹掉吗？

项目根目录的 CLAUDE.md 不会被抹掉——它会从磁盘重新注入。会消失的是带 paths: front matter 的规则和子目录里的 CLAUDE.md，它们要等匹配的文件被重新读取才会回来。想长期生效的规则，请去掉 paths: 或搬进根目录的 CLAUDE.md。

Q5. 能关掉自动压缩吗？

能（把设置 autoCompactEnabled 设为 false、/config 里的「Auto-compact」，或者环境变量 DISABLE_AUTO_COMPACT）。但不推荐。关掉它并不会让上下文变少，只会撞上天花板然后报错。如果你想要的是「让它早点跑」，正确的做法不是关掉它，而是用 /autocompact 把窗口收窄。

Q6. /compact 大概消耗多少 token？

取决于缓存是否温热，差别非常大。工作中途按，前缀会从缓存里读，用官方的表述说就是「比按上下文大小想象出来的便宜得多」。反过来，在超过缓存存活时间的休息之后按，会把整段历史当作未缓存的输入重新读一遍，同一条命令就变成了最贵的版本。缓存存活时间在订阅套餐下是 1 小时，通过 API 密钥或云服务商则默认 5 分钟。

Q7. 可以指定保留的内容吗？

可以。在 /compact 后面写上指示，摘要就会按那个焦点生成（例如 /compact 保留认证相关的修改方针和测试结果）。如果每次的指示都一样，就在 CLAUDE.md 里建一个 # Compact instructions 标题写进去，它会作为默认值生效。

Q8. 为什么压缩刚结束时响应感觉变慢了？

压缩之后的那一轮其实并不重。按官方说明，那一轮是用一段简短的摘要重建缓存，所以并不是慢的地方。你感觉到的慢，多半是正在生成摘要的压缩执行过程本身，或者是缓存已经冷掉时按下的那种情况。

Q9. 有一个叫「微压缩」的功能吗？

这个行为是存在的——官方文档说明「先丢弃旧的工具输出，必要时再摘要会话」，等于明确指出摘要之前还有另一道处理。但截至 2026 年 8 月 8 日核对的范围，官方文档并没有使用「微压缩（micro-compaction）」这个名称。这个叫法来自第三方文章，不是官方术语，请注意区分。

相关文章