---
title: "Claude Code 会话卫生手册：5 种策略 + 3 问 5 选 1 决策卡片"
author: deletexiumu
pubDatetime: 2026-04-16T07:30:00+08:00
featured: false
draft: false
tags:
  - Claude Code
  - 教程
  - AI 编程
description: "1M 上下文时代的 Claude Code 会话管理指南：5 种策略（Continue、/rewind、/clear、/compact、subagents）的触发条件、失效信号、回退方式，加一张可照抄的 3 问 5 选 1 决策卡片。"
---

> 副标题：1M 上下文时代的会话管理 reflex ——基于团队工程师 Thariq 的心法 + 我的实战纠偏

![Claude Code 会话卫生手册：5 种策略决策卡片](/blog/claude-code-session-hygiene/01-cover.png)

自从 Claude Code 对 Max/Team/Enterprise 订阅默认开启 Opus 4.6 的 1M 上下文窗口，我身边不少人开始把"一个会话干到底"当常态——上午研究架构，下午写 feature，晚上改 bug，全部挤在同一条对话里。反正还没撞到 1M 的墙，何必重开。

直到 Anthropic Claude Code 团队的 Thariq（@trq212）在社交平台上发了一条长 thread（原文链接见文末信源），用团队工程师的视角把这件事直接定性为"双刃剑"：

> The 1M context window is a double-edged sword. It allows Claude to do more complex tasks but it can also leads to more context pollution if you don't manage your session well.
> —— Thariq

这条 thread 用 9 段正文把会话管理拆成 5 种策略：Continue、`/rewind`、`/clear`、`/compact`、subagents。读完我把自己 60 多篇 Claude Code 实战文章翻了一遍，对照着做了三件 Thariq 没讲的事：补了一版官方文档里没点破的命令歧义（比如 `/continue` 其实根本不是"Continue 策略"）、给每种策略标了失效信号（`/context` 发黄、摘要丢细节这类征兆）、做了一张我自己每天贴在屏幕边上的"3 问 + 5 选 1"决策卡片。

这篇就是把这些合在一起的完整版本。

## 1. 为什么 1M 上下文反而更需要会话管理

先澄清 Thariq thread 里一个核心概念：Context Rot。

按 Thariq 原话，Context Rot 指的是"模型表现随着上下文增长而退化——注意力被摊在更多 token 上，老旧的无关内容开始干扰当前任务"。它不是故障，是注意力机制的自然代价。

Thariq 给了一个粗略的风险区间：

> For our 1MM context model, we see some level of context rot happen around ~300-400k tokens, but it is highly dependent on the task- not a fast rule.
> —— Thariq

注意后半句——"强依赖任务，不是硬规则"。有些任务到 500k 依然稳定——比如大量文档阅读加单点提问；换成持续多步编码加频繁工具切换，200k 就可能开始漂。所以把 300-400k 当成"该警觉了"的信号即可，不要把它当成闹钟定死。

![Context Rot 风险区间示意图：上下文使用量与输出质量的关系](/blog/claude-code-session-hygiene/02-context-rot.png)

过去 200k 时代，会话管理的刚需是"别撞墙"。1M 之后，墙远了，但"坐在越来越多噪音里做事"的隐性成本反而被放大——模型还能继续跑，但它给出的判断质量可能已经在滑坡。这就是 Thariq 说"双刃剑"的真实含义：能力上限上去了，但如果你没有主动管理的习惯，反而更容易踩坑。

反直觉的结论：**模型能吃 1M，不代表你应该塞 1M**。会话管理不是 200k 时代为了活下来的应急，而是 1M 时代维持输出质量的基线能力。

这篇文章的目标就是把这件事讲透：先过 5 种策略的对比矩阵，再走 5 个决策场景，最后给一张"3 问 + 5 选 1"的自检卡片。

## 2. 5 种策略对比矩阵

开始对矩阵之前先澄清两点：

**第一，"5 种策略"是 Thariq 在 thread 里的个人抽象**，不是 Claude Code 官方文档的枚举。官方文档只分别定义其中的 `/rewind`、`/clear`、`/compact` 命令和 subagents 能力；"Continue" 在 Thariq 的语境里指的是"继续发下一条消息"的默认行为，**不是** `/continue` 命令。

**第二，在 Claude Code 里，`/continue` 命令实际上是 `/resume` 的别名**，作用是从历史会话里选一个恢复，跟 Thariq 说的"Continue 策略"完全不是一回事。这个歧义如果不拆开，读这条 thread 会踩坑。

**侧栏：thread 发布后你该补上的 3 个变化**

Thariq thread 发布时 Claude Code 已经迭代到 2.1.9x 系列，有几个版本变化值得单独点一刀：

- **`/btw` 命令**：Thariq thread 里没提。这是 Thariq 本人 2026-03-10 官宣的命令，用于"在主 session 不变的前提下开侧线对话"。它与 `/clear`、`/compact`、subagent 实际是同一坐标系上的另一种上下文管理选项，严格讲 thread 的"5 种"是漏了它。
- **Task 工具改名 Agent 工具**：v2.1.63 起 Task 工具更名为 Agent 工具，旧的 `Task(...)` 写法保留作为别名兼容。如果你看到 thread 里说"via the Agent tool"就是指这个，不要再去找"Task tool"。
- **`/continue` 真实语义**：如上所述，它是 `/resume` 的别名，跟 Continue 策略无关。

### 5 策略完整矩阵

| 策略 | 触发方式 | 上下文动作 | 适用场景 | 成本影响 | 失效信号 | 回退方式 |
|------|---------|-----------|---------|---------|---------|---------|
| Continue | 直接发下一条消息 | 保留全部 | 紧密相关的连续任务 | 成本随 token 线性上升 | `/context` 发黄、方向漂移、反复重读同一个文件 | 走 `/rewind` 或 `/clear` |
| `/rewind` | `Esc` `Esc` 或 `/rewind` | 回退到某条历史消息，后面全部丢弃 | 发现走偏时精准纠偏 | 节省后续 token | 回退后仍然走偏 | 再次 `/rewind` 回退更早，或直接 `/clear` |
| `/clear` | `/clear`（别名 `/reset`、`/new`） | 清空当前会话重开 | 切换到完全不同的任务 | 最省 token（前提是 brief 写得清） | brief 写不清、需反复补上下文 | `/resume` 回到旧会话，或在**当前目录**下用 `claude -c` / `claude --continue` 恢复该目录最近会话（不是全局最近） |
| `/compact` | 自动触发或 `/compact [instructions]` | 让模型自动摘要、用摘要替换历史 | 同一任务继续但 context 肥了 | 摘要本身耗 token；成功时比 `/clear` 省 re-read | 摘要丢关键细节、后续命令答非所问 | `/clear` + 重写 brief |
| subagents | Agent 工具或显式 prompt | 子会话独立上下文，只回结论摘要 | 中间产物多、只要结论 | 额外消耗 token；主会话只收摘要通常更省主上下文 | 子会话返回不可用、父会话需重开一个 | 父会话自己做，或换分工 |

![5 种会话管理策略对比卡片：Continue、/rewind、/clear、/compact、subagents](/blog/claude-code-session-hygiene/03-strategy-matrix.png)

Thariq 在 thread 里给了 subagents 一个很精辟的判断准则：

> The mental test we use: will I need this tool output again, or just the conclusion?
> —— Thariq

把这张表压成每种策略的一句话本质差异：

- **Continue**：不改上下文，也不重开——相关性最高时用
- **`/rewind`**：不重开，只回退——纠偏比重开便宜
- **`/clear`**：重开，手动起 brief——边界感最强
- **`/compact`**：自动压缩，保留脉络——不想重开但想瘦身
- **subagents**：不污染父，孤立儿——只要结论不要过程

这五条是决策矩阵的骨架，下一章用 5 个实际场景把它跑一遍。

## 3. 5 个典型场景的决策示例

每个场景按同一个格式展开：场景 → 分析 → 选择 → 错选另一策略会怎样 → 实际操作。

### 场景 A：feature 刚写完，接着写这个 feature 的文档（Continue 灰区）

Thariq 在 thread 里专门讲过这个灰区：

> A grey area is when you may want to do related tasks where some of the context is still necessary, but not all. For example, writing the documentation for a feature you just implemented.
> —— Thariq

分析：feature 的代码、接口、改动原因都还在当前会话里。如果 `/clear` 重开，Claude 必须重新读这些文件；如果 `/compact`，文档里引用到的函数名、目录层级可能被压缩漂移。但写文档确实不是"高强度智能敏感任务"（Thariq 原话 not highly intelligence sensitive），继续用老上下文性价比更高。

- **选择**：Continue
- **错选 `/clear`**：重新 re-read 所有相关文件，成本翻倍，输出还可能偏离实际代码
- **错选 `/compact`**：文档章节命名可能因压缩时摘要选择而漂移
- **实际操作**：就接着发下一条消息："based on what we just built, draft the README section for this feature, keep the same function names and file paths"

### 场景 B：Claude 刚按错方向加了个功能，代码还没 commit（`/rewind` 正面）

Thariq 把 rewind 的地位抬得很高：

> If I had to pick one habit that signals good context management, it's rewind.
> —— Thariq

分析：错误路径已经进了上下文，但还没进 git。如果只是接着说"这样不对，改成 X"，Claude 会带着那段错误的推理继续走，污染会越补越深。`/rewind` 是回退到岔路前那条消息，用新的 prompt 重新起步，错误路径被直接丢弃。

- **选择**：`Esc` `Esc` → 选择"Restore code and conversation" → 到刚读完文件那条消息 → 重新 prompt
- **错选 Continue**：反复纠正只会加深污染——模型已经"确信"之前的方向合理
- **错选 `/clear`**：连带丢掉前面正确的几步（读文件、排除错误假设），重开成本更高
- **实际操作**：
  - 先识别"走偏信号"：Claude 开始基于一个错误假设继续推进（比如假设某个接口存在、某个文件位于某处）
  - `Esc` `Esc` 打开 rewind 菜单，选"Restore code and conversation"，回到走偏**之前那条**消息（不是走偏那条本身——走偏那条通常是你发现问题的消息）
  - 重新 prompt 时**明确排除**这条走偏方向，格式如"不要用 A 方案，foo 模块不暴露那个接口，直接走 B"——不把"排除项"写清楚，它可能还会走回原路

顺带一提 `/rewind` 的两个官方细节：一是 Claude Code 每次 user prompt 都会创建一个 checkpoint（自动的）；二是菜单打开后有 5 种可选动作——两者都回退、只回退对话、只回退代码、从某条消息 summarize、取消（Never mind）。对于"走偏救急"这个典型场景，一般选"两者都回退"。

### 场景 C：上午研究架构、下午写 feature A、晚上写 feature B（`/clear` 正面）

这是 `/clear` 最教科书的使用场景。

分析：三个任务相关度很低，上午的架构讨论对晚上的 feature B 几乎是纯污染。Thariq 对这类场景的判断非常干脆——"when you start a new task, you should also start a new session"。

- **选择**：下午 `/clear` 一次 + 重写 brief；晚上再 `/clear` 一次 + 重写 brief
- **错选 Continue**：早上的架构讨论会以"既定前提"的形式影响 feature A 的方向
- **错选 `/compact`**：压缩后的摘要不一定保留"你希望 feature A 遵守的架构约束"——它可能认为那是过时讨论
- **实际操作**：每次 `/clear` 后带一段 brief

Thariq 给的 brief 示例格式是这样的：

> With `/clear` you write down what matters ("we're refactoring the auth middleware, the constraint is X, the files that matter are A and B, we've ruled out approach Y") and start clean.
> —— Thariq

我的 brief 在这个基础上加了几个字段（项目路径、排除项、当前目标），第 4 章会给模板。

### 场景 D：同一个重构任务做了 2 小时，`/context` 已发黄（`/compact` 正面）

分析：任务没换，但 context 确实膨胀了——大量 tool call、已经完成的编辑、查过又不再用的文件。这时 `/clear` 会丢掉脉络，逼你手动整理"哪些文件已经改过、哪些还没动、数据库 schema 决策是什么"；`/compact` 可以让模型自己做这件事，并且你能通过 `[instructions]` 参数指定保留方向。

- **选择**：`/compact focus on the database schema decisions and remaining files to edit`
- **错选 `/clear`**：需要手动整理进度，brief 负担大
- **错选 subagents**：这是同一任务的延续，不是"只要结论不要过程"的场景
- **错选 Continue**：`/context` 已发黄再硬撑，Context Rot 会开始显现

Thariq 在 thread 里特别强调 `/compact` 的触发时机：

> This is particularly difficult, because due to context rot, the model is at its least intelligent point when compacting. With one million context, you have more time to /compact proactively with a description of what you want to do.
> —— Thariq

意思是——autocompact 是"在模型状态最差的时刻去做压缩这件高难度任务"，结果经常不理想。主动在 context 还没黄透时用 `/compact [instructions]`，摘要质量通常更稳，也更可能保留关键点。

实际操作（通用形式）：

```text
/compact focus on <核心决策 1>, <核心决策 2>, and <待继续工作的文件 / 模块清单>
```

- 例如重构任务：`/compact focus on the database schema decisions, the migration rollback plan, and the remaining files to edit in src/models/`
- 例如 debug 任务：`/compact focus on the bug hypotheses ruled out, the current leading hypothesis, and all warnings mentioned so far`

压缩完立即在 `/context` 里核对两件事：① 想保留的决策是否还在？② 接下来要继续做的事是否被摘要覆盖到？如果某项丢了，直接手动补一句"continuing to work on X, constraint is Y"再继续，不要指望 Claude 自己意识到丢了。

### 场景 E：让 Claude 扫描大量日志/文件并只回总结（subagents 正面）

这是 Thariq thread 里 subagents 最典型的用法：

> Subagents are a form of context management, useful for when you know in advance that a chunk of work will produce a lot of intermediate output you won't need again.
> —— Thariq

分析：父会话关心的是"这些日志里有没有异常"、"这些文件里哪些实现了 auth"——是结论。过程中产生的每行日志、每个文件片段，主会话拿来没用。如果在父会话里让 Claude 一个个打开看，父会话的 context 会被中间产物塞满；让子会话去看、只把结论带回，父会话只多了一段"要看什么"的指令和一段总结。

- **选择**：显式让 Claude 开 subagent，示意 prompt：`"Spin up a subagent to scan the logs in /var/log/app/ for any ERROR entries around 2026-04-16 14:00 and summarize what crashed"`（路径和时间点是示意值，实际按你的项目替换）
- **错选 Continue**：父会话 context 被日志爆破
- **错选 `/compact`**：先污染再压缩，等于绕远路
- **实际操作**：官方文档 `/en/context-window` 里给过一个实测数字——一个 subagent 读了 6,100 tokens 的文件，最终只给主会话回了 420 tokens 的结果，这就是父会话省下来的 context

Thariq 还给了三条可以直接套用的 subagent 触发 prompt：

> "Spin up a subagent to verify the result of this work based on the following spec file"
>
> "Spin off a subagent to read through this other codebase and summarize how it implemented the auth flow, then implement it yourself in the same way"
>
> "Spin off a subagent to write the docs on this feature based on my git changes"
> —— Thariq

### 五个场景对照表

| 场景 | 选择 | 关键判断依据 |
|------|------|-------------|
| 写完 feature 写文档 | Continue | 相关且需要原文件细节，重开成本高 |
| 改坏了还没 commit | `/rewind` | 错误路径已进上下文，纠正不如丢弃 |
| 一天三个无关任务 | `/clear` × 2 | 硬边界最强，污染从源头切断 |
| 同任务 context 黄了 | `/compact [focus]` | 想保留脉络、不想重开 |
| 大量中间产物只要结论 | subagents | 父会话只收摘要，过程在子会话里消化 |

## 4. 我的工作流设定

工作流这部分只写三件我在 Claude Code 里每天都在做、能拿出证据的事。不宣称任何伪精确配置——比如"auto-compact 阈值调到 X%"这种——官方没公开可配的接口，跟着网上的二手博客写只会误导人。

### 4.1 `/clear` 后的 brief 模板

Thariq 给的 brief 示例偏演示性质（"we're refactoring X, constraint is Y..."）。我自己用的模板比他多几个固定字段，主要是应对"同一个项目多个 feature 在不同周里穿插进行"的实际情况：

```text
# brief 模板（填完再开 prompt）

项目：<绝对路径>
当前目标：<一句话，动词开头>
已确认约束：
  - <技术栈 / 接口 / 风格约束 1>
  - <...>
排除项（已试过不走的方案）：
  - <方案 A> —— 原因：<...>
  - <...>
参考文件：
  - <文件 1 的相对路径 + 关注的函数/行>
  - <...>
终止条件：<本次会话要产出什么才算完成>
```

填的时候有两个字段最容易暴露问题：**"当前目标"写不清**，就说明你还没想清楚，这时候 `/clear` 反而是好事——它逼你在 brief 阶段先自检；**"排除项"写得太短**，Claude 大概率还会走到那条你已经排除的路上。

关键不在模板本身，在两个判断：

- **brief 写不清 = 你自己还没想清楚**。这时候不该急着 prompt，应该把 brief 写出来当自检。
- **brief 里写过的约束，不要指望 Claude 永远记住**。跨会话的不变规则（项目命名风格、代码风格、禁用的依赖）应该写进 `CLAUDE.md`（项目级规则文件）或 Memory 层（跨会话记忆），`/clear` 后才会自动加载。brief 只写"本次会话"的目标和约束。

### 4.2 subagent 触发准则（定性，不给数值阈值）

什么时候该显式让 Claude 开 subagent？我用三条定性判断，至少命中两条就开：

1. **任务会产生大量中间输出**——比如搜索结果、日志扫描、逐文件分析——而这些中间产物之后大概率不会回看
2. **只需要结论或交付物**，过程不进入父会话的决策链（Thariq 原话 "will I need this tool output again, or just the conclusion?"）
3. **子任务与父任务的接口明确可分离**，你能写清楚"给我 X，我不关心你怎么得到"

三条都命中，开 subagent 基本不亏；只命中一条，留在父会话更划算——subagent 本身也有开销，新子会话需要重建它自己的上下文。

### 4.3 会话终止仪式

会话结束时我会走一个固定的 checklist，避免"今天到底做了啥"这种问题隔天复现：

```text
- [ ] 未 commit 的改动是否已提交（或明确暂存为 WIP）
- [ ] 未决项是否已记到 TODO / issue tracker
- [ ] 下次继续的方式：/clear + brief 还是 /resume <session-id>
- [ ] 跨会话的不变规则是否已写进 CLAUDE.md 或 Memory
```

第 4 条是最容易漏的。上一条会话里 Claude 给你讲过的"这个项目的数据库用 PostgreSQL 不是 MySQL"这种硬约束，如果只活在对话历史里，下次 `/clear` 重开就丢了。真正重要的约束要升迁到 `CLAUDE.md` 或 Memory。

### 4.4 本章不写的内容

这些我特意不碰，不是不重要，是要么在这篇文章的讨论范围外，要么没公开的可配项：

- **`/settings` 里启用 auto-compact 阈值**：没有公开可调项，官方 troubleshooting 只写"接近上限时自动触发"，具体百分比没公开
- **`effortLevel` 等成本参数**：这是成本优化话题，留给专门文章讲
- **"13000 tokens 缓冲触发、3 次熔断"这类实现细节**：是内部行为不是用户可控配置，写了会误导读者以为能调

## 5. 失效场景与决策卡片

### 5.1 3 个典型失效

**失效 1：在 debug 阶段 compact 很危险**

Thariq 在 thread 里专门点了这个坑：

> autocompact fires after a long debugging session and summarizes the investigation and your next message is "now fix that other warning we saw in ." But because the session was focused on debugging, the other warning might have been dropped from the summary.
> —— Thariq

意思是——debug 阶段的"次要警告"、"顺带看到的异常"都可能是后续 bug 的线索，但它们对当前 debug 焦点不显眼，压缩时容易被丢弃。等你想回过头用的时候，它已经不在上下文里了。

应对：debug 长会话里，别让 autocompact 自己触发。要么提前主动 `/compact focus on the bug hypotheses, keep all warnings mentioned`，要么 debug 告一段落后主动 `/clear` 并把有价值的警告单独记到 issue 里。

**失效 2：subagent 孤岛**

子会话有独立 context，这是它的核心价值，但也意味着——子会话拿不到父会话的隐性约定。比如你在父会话里跟 Claude 反复对齐过"这个项目不用箭头函数"，子会话开出来照样用。

应对：subagent prompt 里要把关键约束显式重述一遍；或者把约束固化到 `CLAUDE.md`，子会话会加载。

**失效 3：过度 `/clear` 导致反复 re-read**

`/clear` 不是越多越好。如果你每写几行就 `/clear`，Claude 会反复 re-read 那些本来已经在上下文里的文件——成本反而更高。Thariq 特意给场景 A 的灰区举过例子就是为了防这个坑。

应对：如果你发现自己频繁 `/clear`，真正的问题可能是"应该早点开 fork-session（并行分叉会话，详见下方相关阅读）"或者"应该用 `/resume` 回到旧会话继续"。reflex 是"新任务换新会话"，不是"每步都重开"。

### 5.2 Memory 层的承接

`/clear` 之后你手写的 brief 只承载本次会话的状态，不承载"跨会话始终有效的规则"。这部分应该放在两个地方：

- **`CLAUDE.md`**（项目级规则文件）：项目级别的不变规则（技术栈、禁用项、代码风格）
- **Memory**（跨会话记忆层，通过 `/memory` 命令管理）：更细粒度的偏好和经验教训

这两个层次会在新会话开场时自动加载，不占用你的 brief 预算。指望每次 `/clear` 后靠 brief 重建全部约束，既累又容易漏。

### 5.3 决策卡片（附 `/context` 信号读法）

最后把整个决策过程压缩成一张你可以贴在屏幕边上的卡片：

```text
问 1：这个新任务和上一个任务相关吗？
  相关且还要中间过程 → Continue
  相关但方向走偏了   → /rewind（Esc Esc）
  相关但 context 已重 → /compact focus on ...
  不相关             → /clear + 重写 brief

问 2：我能 30 秒说清当前会话目标吗？
  能   → 沿用 问 1 的选择
  不能 → /clear + 重写 brief（brief 写不清 = 你自己还没想清楚）

问 3：我只要结论还是需要过程？
  只要结论、过程量大 → subagents
  需要过程           → 沿用 问 1 的选择
```

![3 问 5 选 1 决策树：从新任务判断到策略选择的完整流程](/blog/claude-code-session-hygiene/04-decision-tree.png)

> **客观信号辅助：`/context` 怎么读。** 问 1 里"context 已重"是最难判断的一条——你不会有明确的"该压缩了"的提示音。`/context` 命令可以直接看当前上下文使用率的彩色网格。我个人的使用经验是：当 `/context` 输出开始出现明显的警告色块、或者占用率接近上限时，主动考虑 `/compact` 或 `/clear`。**这是个人习惯，不是官方定义的红黄绿阈值**——官方文档没有公开"到 X% 就该 compact"的规则，`/context` 只是"让你看清楚当前状况"的工具，判断还是你自己做。
>
> 还要记住 Thariq 那句原话："the model is at its least intelligent point when compacting"。`/context` 告诉你现在 context 快满了，不意味着"现在正是压缩的最佳时机"——事实上到那时压缩质量是最差的。最佳时机是 context 还没满、你还能清晰描述"希望保留什么"的那个窗口。

---

**下次开新任务前，先把 5.3 那张决策卡片跑一遍。** 5 种策略记不住没关系，3 个问题记得住就够了。

## 相关阅读

- [Claude Code --fork-session：像 git branch 一样分叉你的 AI 对话](/posts/claude-code-fork-session/) — 并行会话工作流，与本文的"单会话生命周期"互补
- [Claude Code 上下文工程实战：从"碰运气"到"有体系"](/posts/context-engineering-in-practice/) — 本文讲"何时换会话"的策略层，那篇讲"单次会话如何构造上下文"的构造层
- [Claude Code 成本优化实战：查、砍、保、控四步把 Token 账单打下来](/posts/claude-code-cost-optimization/) — `/compact` 与 `/clear` 选择背后的成本账

## 信源

- Thariq (@trq212) 原 thread：https://x.com/trq212/status/2044548257058328723
- Thariq thread 修订 self-reply：https://x.com/trq212/status/2044653083817660431
- Thariq 关于 spec-based + new session 的早期论述：https://x.com/trq212/status/2005315275026260309
- Thariq 关于 `/btw` 命令：https://x.com/trq212/status/2031506296697131352
- Claude Code 官方文档 - Checkpointing / rewind：https://code.claude.com/docs/en/checkpointing
- Claude Code 官方文档 - 命令总表：https://code.claude.com/docs/en/commands
- Claude Code 官方文档 - Subagents：https://code.claude.com/docs/en/sub-agents
- Claude Code 官方文档 - Context Window：https://code.claude.com/docs/en/context-window
- Claude Code 官方文档 - 工作原理：https://code.claude.com/docs/en/how-claude-code-works
- Claude Code 官方文档 - Troubleshooting（auto-compact thrashing）：https://code.claude.com/docs/en/troubleshooting
- Claude Code 官方文档 - Changelog：https://code.claude.com/docs/en/changelog