写给小白的 Claude Code 进阶指南 - 巧用 /compact 命令

发表于 更新于 分类于 阅读次数： 本文字数： 3.5k 阅读时长 ≈ 3 分钟

cover

上个月有一次调试会话，前半小时还挺顺，越到后面越离谱。明明刚说过的要求，Claude 转头就忘了。明明已经修好的 Bug，它又给改回去了。

不是 AI 在跟我对着干。它只是”记不住”了。

Claude Code 有一个 20 万 Token 的上下文窗口。听起来很大，但一个调试会话读几十个文件、跑几次命令，Token 消耗的速度远超想象。当上下文接近满载时，Claude 的表现会明显下降——像一个桌子上堆满了文件的人，翻来翻去找不到重点。

/compact 命令，就是帮你收拾这张桌子的。

/compact 到底做了什么？

一句话：**/compact 把你的整个对话历史压缩成一份精简摘要，然后用这份摘要替换原来的对话，作为新的起点继续工作。**

你可以把它想象成”做笔记”。

假设你和 Claude 聊了 100 轮。前 30 轮在探索代码结构，中间 40 轮在调试一个 Bug，最后 30 轮在重构。这 100 轮对话里，真正有价值的信息可能只有：

  • 决定用 JWT 做认证
  • auth 模块拆成了两个文件
  • 数据库用了 cursor-based 分页
  • 有一个边界条件需要注意

/compact 做的事情就是：把这些关键信息提取出来，扔掉中间的试错过程、调试输出、反复讨论。

效果有多明显？一个 15 万 Token 的对话，compact 后通常只剩 3 万到 5 万 Token。压缩率在 60% 到 80% 之间。

为什么不能等自动压缩？

有人会说：Claude Code 不是有自动压缩吗？为什么还要手动跑 /compact？

确实，当上下文窗口达到 75% 到 95% 满载时，Claude Code 会自动触发压缩。但问题在于：

1. 自动压缩来得太晚了。

等到 95% 才压缩，Claude 的表现已经下降了。根据社区的经验：

上下文使用率 Claude 的表现
0% - 50% 正常水平
50% - 70% 开始出现细节遗漏
70% - 85% 明显忘记早期指令
85% 以上 频繁出错，方向偏离

2. 自动压缩没有针对性。

自动压缩不知道你觉得什么重要。它按照默认算法压缩，可能会丢掉你在乎的决策细节，却保留了一堆你不需要的调试输出。

3. 自动压缩会打断工作流。

压缩过程需要时间。如果 Claude 正在执行一个任务，中途被自动压缩打断，可能会丢失任务进度。

高手的做法是：在上下文使用到 50% 到 60% 时，主动跑一次 /compact。 就像开车不等油灯亮了才去加油，而是看到剩半箱就加。

/compact 的基本用法

最简单的用法：直接跑

1
/compact

Claude 会自动总结整个对话历史，保留关键信息，扔掉冗余内容。大多数情况下，这就够了。

进阶用法：带指令压缩

这是 /compact 最强大的地方。你可以告诉 Claude，压缩时重点保留什么。

1
/compact 只保留关于 auth 模块的修改和测试结果
1
/compact 保留所有架构决策和待办事项
1
/compact 重点保留 API 接口定义和数据库 Schema 变更

为什么这很重要？因为默认压缩是”通用”的，它不知道你接下来要做什么。但你知道。

比如，你刚花了一个小时调试完一个 Bug，接下来要开始一个新功能。调试的过程不需要了，但调试中发现的一些架构问题需要保留。这时候：

1
/compact 丢掉调试过程的细节，保留发现的架构问题和最终的修复方案

带指令压缩 vs 默认压缩，区别就像”帮我收拾桌子”和”帮我把桌子上的文件按项目分类，测试报告扔掉，设计文档留着”。

/compact vs /clear：别搞混了

很多人分不清 /compact 和 /clear 的区别。一张表说清楚：

特性 /compact /clear
做了什么 压缩对话为摘要 彻底删除所有对话
保留信息 关键决策、文件路径、函数名 什么都不保留
CLAUDE.md 保留 保留（自动加载）
Token 消耗 约 2K（需要读取历史来总结） 0（免费操作）
适合场景 任务进行中，需要释放空间 任务彻底结束，准备开始新任务
风险 可能丢失细节 丢失所有上下文

一个简单的判断标准：

1
2
3
如果之前的对话完全不需要了 → /clear
如果之前的对话大部分还有用 → /compact
如果只有部分有用 → /compact <指定保留什么>

五个实战场景

场景一：调试完 Bug，准备写新功能

你刚花了 50 轮对话定位并修复了一个 Bug。现在要开始写新功能，但上下文已经被调试信息塞满了。

1
/compact 保留 Bug 的根因分析和修复方案，丢掉调试过程的中间输出

场景二：做完代码探索，准备开始实施

你让 Claude 在 Plan Mode 里读了大量代码，现在切回正常模式准备写代码。但探索过程读取的文件内容占了太多上下文。

1
/compact 保留代码结构的总结和实施计划，丢掉具体的文件内容

场景三：长会话中途整理

你已经在一个会话里工作了两个小时，跑了 /cost 发现上下文已经用了 60%。主动整理一下。

1
/compact 保留当前任务的进度和所有未完成的待办事项

场景四：任务切换

同一个会话里，你先做了 A 功能，现在要转去做 B 功能。A 功能的上下文对 B 没什么用。

1
/compact 只保留项目架构的整体理解，丢掉 A 功能的具体实现细节

场景五：保护关键决策

你和 Claude 讨论了半天架构方案，做了几个重要决策。担心后续的对话冲淡这些决策。

1
/compact 重点保留以下决策：1) 用 Redis 做缓存 2) API 版本用 URL 前缀 3) 错误码用统一格式

搭配其他工具使用

/compact 不是孤立的。搭配其他工具使用，效果更好。

搭配 /context 查看上下文

在跑 /compact 之前，先看看上下文的使用情况：

1
/context

这会告诉你当前上下文用了多少 Token，哪些内容占用最多。心里有数了，再决定要不要 compact，以及 compact 时保留什么。

搭配 /cost 监控费用

1
/cost

长会话中定期跑 /cost，看看 Token 消耗趋势。如果发现消耗速度明显加快（通常意味着上下文快满了），赶紧 compact。

搭配 CLAUDE.md 做持久化

/compact 再怎么聪明，压缩时总会丢失一些信息。最重要的规则和约定，应该写进 CLAUDE.md。

因为 CLAUDE.md 不受 compact 影响。每次新会话、每次 compact 后，Claude 都会重新读取 CLAUDE.md。它是你的”永久记忆”，而 compact 只是管理”工作记忆”。

1
2
3
4
5
6
7
8
9
10
11
# CLAUDE.md 示例

## 项目规范
- 使用 TypeScript 严格模式
- API 响应统一用 { code, data, message } 格式
- 数据库查询必须用参数化查询

## 架构决策
- 认证用 JWT + Redis
- 文件上传用 S3
- 日志用 Winston

搭配 Subagent 减少上下文压力

如果你知道某个任务会消耗大量上下文（比如搜索整个代码库），让 Subagent 去做。Subagent 有自己的上下文窗口，不会占用主会话的空间。

1
用 subagent 去调查一下我们的认证系统是怎么处理 token 刷新的

Subagent 在自己的窗口里读了 20 个文件，最后只返回一段总结给主会话。省了 19 个文件的上下文空间。

一个容易踩的坑

有些生成的文件会吃掉大量上下文。比如：

  • package-lock.json：3 万到 8 万 Token
  • 编译后的 bundle.js：可能超过 10 万 Token
  • 大型 .map 文件：轻松几万 Token

一个 package-lock.json 就能吃掉你将近一半的上下文窗口。

解决办法：在项目根目录创建 .claudeignore 文件，把这些文件排除掉：

1
2
3
4
5
6
7
8
9
# .claudeignore
package-lock.json
yarn.lock
*.min.js
*.bundle.js
*.map
dist/
build/
node_modules/

这比 compact 更有效——从源头上减少不必要的上下文消耗。

写在最后

上下文管理是 Claude Code 新手和高手之间最大的技能差距。

很多人觉得”200K Token 够大了”，然后一顿操作猛如虎，上下文满了才发现 Claude 已经开始胡说八道。

/compact 不是一个出了问题才用的急救命令。它是一个应该融入日常工作流的习惯。

我现在的节奏是：每完成一个小任务 compact 一次，上下文超过 50% 主动 compact。开头那次调试翻车，就是因为没有在 60% 时主动整理，等到 Claude 开始乱说才意识到已经晚了。

.claudeignore 这个细节我觉得比 compact 本身更值得重视——一个 package-lock.json 就能吃掉将近一半上下文，从源头堵住比事后压缩省力多了。