DAY 04 · CLAUDE CODE ROADMAP · 20 DAYS

管理 Claude 的有限记忆

Claude 的上下文窗口就像一块白板——空间有限，写满了旧内容就没地方放新信息。今天你将学习如何用 /compact 主动"擦白板"、理解自动压缩的触发机制、掌握 /clear 的重置策略，以及在长时间工作中用 --continue 和 --resume 维持最佳工作状态。

DURATION 40–50 min THEORY 20 min HANDS-ON 15 min REVIEW 10 min COMMANDS /compact · /clear · --continue · --resume

M ·

思维导图

OVERVIEW

FIG · Day 04 全景: 上下文窗口 → /compact 压缩 → /clear 重置 → 对话策略

01 ·

上下文窗口 — 理解"有限记忆"

8 MIN

Claude 不会真正"记住"你们之前聊了什么——它只是把所有对话内容放进一个固定大小的窗口里，每次回答时从头到尾读一遍。窗口满了，旧内容就必须被压缩或丢弃。理解这个机制是高效使用 Claude Code 的前提。

上下文窗口里装了什么

FIG · 上下文窗口 = 系统提示词 + 对话历史 + 输出空间，三者共享固定容量

Token 是什么

内容	大约 Token 数	说明
1 个英文单词	~1 token	"hello" = 1 token
1 个中文字	~1.5 token	"你好" ≈ 3 tokens
1 行代码	~10-15 tokens	取决于变量名长度和复杂度
一次 Read 工具结果	~500-5000 tokens	读大文件会迅速填满上下文
典型 CLAUDE.md	~300-800 tokens	每次对话都会消耗的固定开销

KEY INSIGHT

"越靠后越清晰"

Claude 对最近的消息注意力最强——如果对话很长，前面讨论过的细节可能被"遗忘"或混淆。这不是 Bug，而是 Transformer 架构的固有特性。对策：在长对话中重复关键信息，或用 /compact 把旧内容压缩为摘要。

WARNING

工具结果是隐形的大户

每次 Read 文件、grep 搜索、运行 Bash 命令，返回的结果都会被完整存入上下文。一次 Read 一个 500 行文件可能消耗 5000+ tokens。连续读几个文件后，你的对话空间可能已经用掉一半了——即使你只说了两句话。

你可以在 Claude Code 界面底部看到当前上下文使用量的进度条——养成瞥一眼的习惯。

02 ·

/compact — 主动压缩上下文

10 MIN

/compact 是你管理上下文的核心武器。它让 Claude 把当前对话中的旧消息压缩成一段精简摘要，然后用这段摘要替换原始内容——腾出大量空间给后续对话。

/compact 的用法

# 基础用法: 压缩当前对话
> /compact
# Claude 会把之前的对话历史压缩为一段摘要
# 你会看到: "Conversation compacted. Summary: ..."

# 带焦点的压缩: 告诉 Claude 重点保留什么
> /compact 保留关于数据库迁移的讨论细节
# 摘要会侧重数据库迁移的上下文

> /compact focus on the API endpoints we designed
# 摘要会侧重 API 设计细节

何时使用 /compact

场景	信号	操作
上下文快满了	底部进度条超过 70%	/compact — 立刻释放空间
任务阶段切换	调试完毕，准备写测试	/compact 保留修复方案的结论
大量文件读取后	连续 Read 了多个文件	/compact — 文件内容已理解，不需要原文
Claude 开始"忘事"	重复问你已经回答的问题	/compact 重点保留关键决策
主动预防	预感接下来的操作会很长	先 /compact，再开始大任务

自动压缩

即使你不手动调用 /compact，Claude Code 也会在上下文接近极限时 自动触发压缩。

FIG · 自动压缩: 检测上下文接近上限 → 压缩旧消息为摘要 → 释放空间继续工作

KEY INSIGHT

主动优于被动

自动压缩是安全网，但不是最优方案。它在紧急时刻触发，没有焦点参数——Claude 只能猜测哪些信息重要。手动 /compact 让你控制保留哪些细节，压缩质量更高。养成在任务阶段切换时主动 compact 的习惯。

DETAIL

压缩后发生了什么

压缩后，Claude 看到的不是原始对话，而是一段压缩摘要 + 未被压缩的最近消息。摘要保留了关键事实和决策，但具体的代码片段和工具输出会丢失。如果压缩后需要某个文件的内容，你需要让 Claude 重新读取。

/compact 不是"删除历史"——它是"把厚厚的笔记整理成提纲"。信息在，但细节减少了。

03 ·

/clear — 清空与重置

5 MIN

/clear 是最彻底的上下文管理手段—— 它完全清空当前对话历史，回到"刚打开 Claude"的状态。但注意：CLAUDE.md 和 Memory 仍然生效，因为它们不是对话的一部分。

/clear 的用法

# 清空当前对话
> /clear
# 对话历史完全清空
# CLAUDE.md 和 Memory 仍然加载
# 就像刚打开一个新的 claude 会话

/compact vs /clear — 何时选哪个

维度	/compact	/clear
效果	压缩旧消息为摘要	完全删除所有对话历史
上下文保留	保留摘要 + 最近消息	零——全部清空
适用场景	同一任务需要继续	切换到完全不同的任务
CLAUDE.md	仍然生效	仍然生效
Memory	仍然生效	仍然生效
类比	把笔记整理成提纲	翻到全新的一页

WHEN TO CLEAR

适合 /clear 的场景

换任务：从写代码切换到写文档。陷入循环：Claude 在同一个 Bug 上打转，给的方案越来越差。污染的上下文：之前的讨论引入了错误假设，想重新开始。敏感信息：刚讨论了包含密码/密钥的内容，想清理。

TIP

/clear 不等于退出

/clear 在当前会话中原地重置，你不需要退出终端再重新启动 claude 命令。这比 Ctrl+C 退出再重开更快——而且保持了工作目录和环境不变。

/clear 之后 Memory 仍在——但如果你刚告诉 Claude "记住 XX"，确保在 /clear 之前它已经保存到 Memory。

04 ·

对话策略 — 会话的生命周期管理

12 MIN

/compact 和 /clear 是"会话内"的工具。但真正的效率来自于会话间的策略—— 什么时候该开新对话、什么时候该延续旧对话、什么时候该从历史中恢复。

--continue 和 --resume

# 继续上一次对话 (最常用)
$ claude --continue
# 或简写
$ claude -c
# 恢复上次退出时的完整上下文

# 带消息继续
$ claude -c "继续修那个 Bug，我发现还有一个边界情况"

# 从历史对话中选择 (交互式)
$ claude --resume
# 显示最近的对话列表，你选择要恢复哪个

# 直接恢复指定会话 ID
$ claude --resume SESSION_ID

"一任务一对话"原则

高效使用 Claude Code 的核心策略是：每个独立任务用一个独立对话。对话是廉价的资源，上下文是昂贵的资源。

场景	推荐做法	原因
修复 Bug A	新对话	干净的上下文 = 精准的理解
Bug A 修完，写测试	--continue	测试需要了解修复细节
测试完，做另一个功能 B	新对话	Bug A 的上下文对功能 B 是噪音
昨天的功能 B 发现问题	--resume 昨天的会话	恢复功能 B 的完整上下文
大规模重构（多文件）	新对话 + 勤用 /compact	重构读的文件多，上下文消耗快

识别上下文劣化的信号

SIGNAL 1

重复提问

Claude 开始问你已经回答过的问题——说明早期对话在它的注意力中已经淡化。此时应该 /compact（如果还在同一任务）或开新对话（如果已经是不同任务）。

SIGNAL 2

方案漂移

Claude 给出的方案跟之前讨论的不一致，或者忘记了你们达成的约定（比如用 A 方案不用 B 方案）。这是上下文过载的典型症状——旧的决策信息在长对话中被淹没了。

SIGNAL 3

回答变短变泛

原本给出详细方案的 Claude 开始回答变得笼统和简短——可能是因为输出空间被对话历史挤占了。/compact 可以释放输出空间，让 Claude 恢复详细的回答风格。

SIGNAL 4

编辑错误增多

Claude 的 Edit 操作开始失败——old_string 匹配不上，因为它记忆中的文件内容是早期版本。这说明上下文中的文件内容已经过时。/compact + 重新 Read 文件是最有效的修复。

经验法则: 如果你在一个对话中超过 20 分钟还没 compact 过，很可能已经该 compact 了。

05 ·

上下文管理决策流程

CHEAT SHEET

四个命令、一棵决策树——以后遇到"该怎么管理这个对话"时，按此流程判断。

FIG · 上下文管理决策树: 根据当前状态选择继续 / /compact / /clear / --continue

四大命令速查表

命令	作用	保留的内容	典型场景
/compact	压缩旧消息为摘要	摘要 + 最近消息 + CLAUDE.md + Memory	对话变长，同一任务还在继续
/clear	清空全部对话历史	CLAUDE.md + Memory	切换任务 / 陷入循环 / 重新开始
--continue	恢复上次退出的对话	完整的上次对话上下文	午饭回来继续工作
--resume	从历史中选择对话恢复	选中会话的完整上下文	回到昨天某个任务的讨论现场

这四个命令组合使用形成完整的"上下文生命周期管理"——从新建到延续到压缩到清空。

06 ·

动手练习

15 MIN

今天的练习重点是感受上下文管理—— 不只是知道命令怎么用，而是体会"什么时候该用"。

Lab 1 — 观察上下文增长

刻意制造一个长对话，观察上下文使用量的变化。

# 开始一个新对话
$ claude

# 让 Claude 读几个文件 (消耗上下文)
> 读一下 package.json
> 读一下 src/index.ts
> 读一下 README.md

# 观察: 底部的上下文进度条变化了多少？
# 每次 Read 后注意进度条的跳跃幅度

# 继续对话几轮
> 分析一下项目结构
> 帮我列出所有的 API 端点
# 再看看进度条——对话内容也在消耗空间

Lab 2 — 体验 /compact

在上一个 Lab 的基础上尝试 /compact，感受压缩前后的差异。

# 在上面那个已经有一些历史的对话中:
> /compact
# 观察: 进度条应该明显缩短了

# 验证摘要质量
> 总结一下我们之前讨论了什么
# Claude 应该能从摘要中回忆出要点

# 验证细节丢失
> package.json 里 React 的版本号是多少？
# Claude 可能答不上来——具体版本号在压缩中丢失了
# 这就是压缩的代价: 细节换空间

Lab 3 — 带焦点的 /compact

体验自定义焦点参数如何影响压缩质量。

# 先和 Claude 讨论两个话题
> 帮我分析 src/auth/ 目录的认证逻辑
# ... 讨论一番 ...
> 再看看 src/api/ 目录的路由设计
# ... 又讨论一番 ...

# 用带焦点的 compact
> /compact 保留认证逻辑的讨论，路由设计可以简略

# 验证
> 认证那块我们讨论出了什么结论？
# 应该能详细回忆
> 路由设计那块呢？
# 可能只有简略的摘要

Lab 4 — --continue 和 --resume

体验对话的跨会话延续。

# 对话 1: 正常工作
$ claude
> 帮我写一个 utility 函数: 把驼峰转蛇形
# Claude 写好了函数
# 按 Ctrl+C 退出

# 对话 2: 用 --continue 接上
$ claude -c "给刚才那个函数加上单元测试"
# Claude 知道你说的是驼峰转蛇形的函数
# 因为 -c 恢复了上次的完整上下文

# 对话 3: 用 --resume 选择历史
$ claude --resume
# 看到最近的对话列表，选择想恢复的

完成这四个 Lab 后，你应该对"上下文满了是什么感觉"有了直觉——这个直觉在后续每天的实操中都会用到。

Q ·

常见疑问

5 QUESTIONS

Q1 /compact 会丢失重要信息吗？如何确保关键决策不被压缩掉？ +

ANS

会丢失细节，但不会丢失关键决策——前提是你用了焦点参数。无参数的 /compact 让 Claude 自行判断什么重要，通常做得不错但不完美。带焦点的 /compact 保留关于 XX 的细节 让你明确控制保留什么。最关键的信息保护策略是：把它写进 CLAUDE.md 或让 Claude 保存到 Memory——这两者不受 /compact 影响。

Q2 自动压缩和手动 /compact 有什么区别？ +

ANS

本质上做的事一样——把旧消息替换为摘要。区别在于：(1) 时机：手动 /compact 你选择最佳时机（比如任务阶段切换时），自动压缩在不得不压的时候触发；(2) 焦点：手动 /compact 可以指定保留什么，自动压缩没有焦点参数；(3) 可预期性：手动 /compact 你知道什么时候发生，自动压缩可能在你不注意时悄悄发生。所以手动优于被动。

Q3 --continue 和 --resume 恢复的对话还能再 /compact 吗？ +

ANS

可以。--continue 和 --resume 只是恢复上下文，恢复后的对话和正常对话没有任何区别——你可以继续聊天、/compact、/clear，完全自由操作。一个常见的好习惯是：--continue 恢复对话后，先 /compact 一下再继续工作，因为恢复时上下文可能已经比较满了。

Q4 VS Code 扩展和 Desktop App 中的上下文管理有什么不同？ +

ANS

核心机制相同——都是 200K 上下文窗口，都支持 /compact 和 /clear。差异主要在 UI 表现：VS Code 扩展和 Desktop App 提供可视化的上下文进度条，CLI 需要你自己留意。--continue 和 --resume 是 CLI 特有的命令行参数——在 VS Code 中，你可以通过面板重新打开之前的对话来实现类似效果。

Q5 有没有办法查看当前上下文还剩多少空间？ +

ANS

CLI 界面底部有一个上下文使用量指示器，显示当前已使用的百分比。VS Code 扩展和 Desktop App 同样有可视化进度条。没有精确到 token 数的显示，但百分比足够你判断是否需要 /compact。一般来说，超过 70% 就应该考虑压缩了，超过 90% 自动压缩随时可能触发。

R ·

复盘问题