在长时间的 Claude Code 会话中，/compact 会自动把对话历史压缩成摘要，但并非所有你设置的规则和记忆都能在压缩后完好保留。本文基于官方 Context Window 文档，梳理一套确保关键规则「压不丢」的实战配置方法。
问题场景
假设你在项目中设置了一条针对特定目录的规则文件（带 paths: frontmatter），要求 Claude 在处理该目录下的代码时遵循某个特殊约定。会话跑了很久之后触发了 Compaction，你发现 Claude 似乎「忘记」了这条约定——这不是幻觉，而是符合官方文档描述的确定性行为。
官方文档给出的存活规则
根据 Compaction 后各类机制的存活情况：
| 机制 | 是否存活 |
|---|---|
| 系统提示词、Output Style | ✅ 始终不受影响 |
| 项目根目录 CLAUDE.md | ✅ 从磁盘重新注入 |
| 自动记忆 | ✅ 从磁盘重新注入 |
带 paths: 的规则 | ❌ 丢失，直到匹配文件被再次读取 |
| 子目录嵌套 CLAUDE.md | ❌ 丢失，直到该子目录文件被再次读取 |
| 已调用的 Skill 正文 | ⚠️ 重新注入但会被截断（单个上限 5000 Token，总计上限 25000 Token） |
实战配置一：区分「必须永久存在」和「按需加载」的规则
根据这张表，你需要重新审视项目中的规则文件组织方式：
判断标准：
这条规则是否「任何时候都必须遵守」，不管当前在处理哪个文件？
→ 放进项目根目录 CLAUDE.md（无 paths: 限定）
这条规则只在处理特定目录/文件类型时才相关？
→ 可以保留 paths: frontmatter，但要接受它会在 Compaction 后暂时消失
具体操作：如果你发现某条「路径限定规则」其实是团队核心约定（比如「所有 API 端点必须写测试」这种适用范围很广的规则），应该去掉 paths: frontmatter，把它移到项目根目录的 CLAUDE.md 中，确保它在任何 Compaction 后都不会丢失。
<!-- 修改前：仅在 src/api/ 目录相关文件加载 -->
<!-- .claude/rules/api-testing.md -->
---
paths: "src/api/**"
---
所有 API 端点必须编写对应的集成测试。
<!-- 修改后：移入项目根 CLAUDE.md，任何时候都存在 -->
<!-- CLAUDE.md -->
## 核心约定
所有 API 端点必须编写对应的集成测试（不限于 src/api 目录）。实战配置二：SKILL.md 的重点内容前置
Truncation keeps the start of the file, so put the most important instructions near the top of SKILL.md.
如果你在维护自定义 Skills，且 Skill 正文比较长，需要注意：Compaction 后重新注入 Skill 正文时，截断只保留文件开头部分。这意味着 SKILL.md 的写作顺序需要调整：
<!-- 不推荐的写法：重要指令放在文件末尾 -->
# 我的 Skill
（大段背景介绍、历史沿革、边缘情况说明...）
## 核心指令（最重要，但排在最后）
执行时必须先检查 X，再执行 Y
<!-- 推荐的写法：核心指令前置 -->
# 我的 Skill
## 核心指令（放在最前面）
执行时必须先检查 X，再执行 Y
（背景介绍、边缘情况说明放在后面，被截断也不影响核心逻辑）实战配置三：主动管理，而不是被动等待自动压缩
官方文档提供了三个可以在自动 Compaction 触发之前主动使用的手段：
带焦点的手动压缩
# 在开始一个新的长任务前，指定摘要应该保留什么
> /compact focus on the auth bug fix相比让自动压缩「猜测」哪些内容重要，显式指定焦点能让摘要更精准地保留你真正需要的上下文。
切换任务时主动清空
# 切换到不相关的新工作时
> /clear官方原文强调：旧对话会挤占你接下来需要的文件空间，并且每条消息都要为此消耗 Token——这是一个容易被忽视的隐性成本，很多人习惯让一个会话「一直开着」处理多个不相关任务，实际上每次都在为无关的历史付费。
把大量读取委托给 Subagent
> 帮我调研一下这个模块过去的几种实现方案，用 subagent 来处理，只给我结论大文件读取留在 Subagent 自己的上下文窗口里，只有摘要和少量元数据返回给主对话——这是控制主上下文体积最有效的手段之一。
实战配置四：需要更大窗口时选对模型
如果问题不是「对话太杂乱」而是「确实需要一次性处理海量内容」，可以选择支持 100 万 Token 上下文窗口的模型：Fable 5、Sonnet 5、Opus 4.6 及更新版本、Sonnet 4.6。其中 Sonnet 5 默认就以 1M 运行，无需额外选择 [1m] 变体；其他模型需要显式选择该变体，具体可用性和自动压缩阈值请查阅 Extended Context 文档。
检查清单
- 审查项目中所有带
paths:frontmatter 的规则，识别哪些其实是「全局适用」的核心约定 - 把识别出的核心约定移入项目根目录 CLAUDE.md
- 检查自定义 SKILL.md 文件，把最重要的指令调整到文件靠前的位置
- 长任务开始前主动使用
/compact focus on ...而不是等待自动压缩 - 切换不相关任务时养成主动
/clear的习惯，避免旧对话持续消耗 Token - 大量文件研究类任务优先考虑挪给 Subagent 处理
- 确实需要超大上下文时，确认当前模型是否支持 100 万 Token 窗口（如 Sonnet 5）
总结
Context Window 的管理本质上是一件需要提前规划的事情，而不是出问题后再临时补救。理解 Compaction 对不同机制的不同处理方式，并提前调整好 CLAUDE.md 结构、SKILL.md 写法、以及你自己使用 /compact、/clear、Subagent 的习惯，能让长会话中的 Claude 真正记住你在乎的那些约定，而不是在关键时刻“失忆”。
来源：Explore the context window — Claude Code 官方文档，Anthropic