上下文窗口怎么管：压缩之后什么还在

2026-07-24 更新·markdown 原文

我把官方那份上下文时间线和「压缩后什么活下来」的表接到了一起。最值钱的是那张表——它解释了一类很难查的现象：你写过的规则，在长会话里会自己消失，而且不报错。

会话开始时已经占掉的

一个新会话不是从零开始。启动就装进去的东西大致是（官方给的示意值，不是你的真实数）：

加上你的 CLAUDE.md、rules、以及第一次读的几个文件。默认窗口 200K——Fable 5、Sonnet 5、Opus 4.6 及之后、Sonnet 4.6 支持 100 万 token 的窗口（部分要选 [1m] 变体，Sonnet 5 直接就是 1M）。

看自己的实况：`/context`，它按类别给实时占用，还会指出哪些能优化，包括加载了哪些 CLAUDE.md 和 auto memory 文件。

上下文接近上限时会自动压缩，也可以手动 /compact。压缩就是把对话历史总结掉——你的指令能不能活下来，取决于它当初是怎么加载进来的：

机制	压缩之后
system prompt、output style	不变（本来就不在消息历史里）
项目根 CLAUDE.md、无 scope 的 rules	从磁盘重新注入
auto memory	从磁盘重新注入
带 `paths:` frontmatter 的 rules	丢，直到再读到匹配的文件
子目录里的嵌套 CLAUDE.md	丢，直到再读那个目录里的文件
调用过的 skill 正文	重新注入，但每个 skill 上限 5,000 token、总计 25,000，超了先丢最老的
hooks	不适用——hook 是代码，不占上下文

三个直接的推论：

一、只在对话里说过的话，压缩之后就没了。 「以后都用 pnpm 别用 npm」这种，说一次是活不过压缩的。要它长期有效就得落到 CLAUDE.md 或 auto memory 里。

二、`paths:` 是省 context 的手段，代价是它活不过压缩。 一条规则如果必须在整个会话里一直有效，就别给它加 `paths:`，或者干脆搬到项目根 CLAUDE.md。省 context 和抗压缩，这里只能选一个。

三、SKILL.md 最重要的话写在最前面。 超出 5,000 token 的部分会被截断，而截断保留的是开头。把关键指令压在文件末尾的 skill，压缩之后就剩个开头的介绍。

两个动作差别比看起来大：

压缩一个大上下文，这个动作本身就是一次大请求。 所以别养成「快满了就 compact」的习惯——如果下一个任务跟前面无关，/clear 又快又免费。

想回头找，/clear 之前先 /rename，之后用 /resume 回去。

`/compact` 可以带指示，让它按你要的留：

/compact 重点保留那个鉴权 bug 的排查过程和最后的修法

自动压缩猜什么重要，带指示的压缩由你定。也可以把默认指示写进 CLAUDE.md：

# Compact instructions

压缩时重点保留测试输出和代码改动。

三个动作，成本从低到高：

把大块阅读交给子代理。 抓文档、跑测试、翻日志——让几万 token 的原始输出留在子代理的上下文里，主对话只收一份摘要。这是唯一一个能「读了但不占地方」的办法。

用 hook 在数据进来之前过滤。 一万行日志 grep 完再给它，几万 token 变几百。

切任务就 `/clear`。 陈旧上下文在之后每条消息上都收一次费。

压缩这件事跟账单是连着的：每条消息都带着整个对话发出去。所以上下文越长，之后每一条消息越贵——不是压缩那一下贵，是压缩之前的每一条都在为那段历史付钱。

外加缓存那一层：休息时间超过缓存寿命（订阅 1 小时、API key 5 分钟），回来第一条消息就是把整段上下文按全价重新过一遍。上下文越长，这一下越疼。

三件事连起来看才对：上下文长度 → 每条消息的价 → 缓存过期时的重算成本。省钱三件套那篇把这条线讲全了。