Claude Code 上下文管理完全指南：让每一个 Token 都物尽其用

前言

在进阶指南里，我用大约 40 行篇幅介绍了上下文管理的基本命令。但实际使用下来，我发现上下文管理是 Claude Code 中最被低估、也最影响输出质量的技能。

配好了 CLAUDE.md，配好了 Hooks，如果上下文管理不到位，Claude 照样会给你离谱的回答。

这篇文章把上下文管理讲透。

一、为什么上下文管理重要

Claude Code 的上下文窗口是有限的。你可以把它想象成一张工作台：

• 工作台面积有限（上下文窗口大小）
• 你堆的东西越多，找东西越慢（质量下降）
• 堆满了就放不下新东西了（截断或自动压缩）

具体来说，上下文管理不当会导致：

一句话：上下文窗口不是越满越好，而是越精准越好。

二、上下文的组成

了解上下文里装了什么，才能有效管理它。一个典型的 Claude Code 会话，上下文大致由以下部分组成：

几个关键认知：

1. 工具调用结果是大头 — Claude 每读一个文件、每执行一条命令，结果都会占上下文。读一个 500 行的文件，就是 500 行的上下文消耗
2. 对话来回越多，消耗越快 — 每一轮对话（你的输入 + Claude 的输出）都在累积
3. CLAUDE.md 始终在 — 它在每次对话开始时就被加载，所以写得精简很重要（参考 CLAUDE.md 指南）

三、核心命令详解

进阶指南里列了四个命令，这里展开讲每个命令的使用场景和最佳时机。

3.1 /clear — 清空重来

/clear

做了什么： 完全清空当前对话上下文，回到初始状态（系统提示词 + CLAUDE.md）。

什么时候用：

• 切换到完全不同的任务（从修 bug 转到写新功能）
• 上下文被"污染"了（Claude 坚持错误的假设，怎么纠正都不听）
• 一个任务完成了，准备开始下一个

注意： /clear 是不可逆的。清空前确认当前任务已经完成或者不需要保留上下文。

3.2 /compact — 压缩保留

/compact                    # 使用默认压缩策略
/compact 只保留架构决策和待办事项  # 自定义压缩提示

做了什么： 让 Claude 总结当前对话，用精简的摘要替换完整的对话历史。

什么时候用：

• 任务进行到一半，但上下文快满了
• 想保留关键决策和进度，丢掉中间的试错过程
• 长时间调试后，想保留结论但丢掉调试细节

自定义压缩提示是关键。 默认压缩可能丢掉你觉得重要的信息。告诉 Claude 你想保留什么：

/compact 保留：1. 当前的文件修改清单 2. 已确认的 bug 原因 3. 下一步计划

3.3 /context — 查看用量

/context

做了什么： 显示当前上下文窗口的使用情况，包括已用 token 数和剩余空间。

什么时候用：

• 感觉响应变慢了，想确认是不是上下文快满了
• 在决定是 /clear 还是 /compact 之前，先看看用了多少
• 养成习惯：每完成一个子任务就看一眼

3.4 /resume — 恢复会话

/resume                     # 交互式选择要恢复的会话
claude --resume             # 启动时直接恢复上一次会话
claude --resume SESSION_ID  # 恢复指定会话

做了什么： 恢复之前的会话上下文，继续未完成的工作。

什么时候用：

• 昨天下班前的任务今天继续
• 不小心关了终端，想恢复之前的进度
• 在多个任务之间切换（A 任务暂停，做 B，再回到 A）

注意： 恢复的会话会占用上下文空间。如果之前的会话已经很长，恢复后可能很快就需要 /compact。

四、喂上下文的技巧

除了管理上下文，怎么高效地把信息喂给 Claude 同样重要。

4.1 管道输入

# 喂文件内容
cat src/lib/api.ts | claude "分析这个文件的错误处理"
 
# 喂 git diff 做 code review
git diff main | claude "review 这些改动，关注安全问题"
 
# 喂构建错误
npm run build 2>&1 | claude "分析构建错误并给出修复方案"
 
# 喂测试结果
npm test 2>&1 | claude "分析失败的测试用例"
 
# 喂多个文件（用 cat 拼接）
cat src/models/user.ts src/routes/auth.ts | claude "分析这两个文件的数据流"

管道输入的好处是精准 — 你只给 Claude 它需要的信息，不多不少。

4.2 @-mentions

在对话中用 @ 引用文件：

你：@src/components/Navigation.tsx 这个组件的移动端菜单有 bug，点击后不会关闭

Claude 会自动读取文件内容。比起让 Claude 自己去找文件，@ 引用更快、更精准。

4.3 图片输入

# 喂截图
claude "这个 UI 有什么问题？" -i screenshot.png
 
# 喂设计稿
claude "按照这个设计稿实现组件" -i design.png

4.4 结构化提示

减少来回对话是节省上下文的最有效方式。一次性把需求说清楚：

你：重构 Navigation 组件，要求：
1. 把内联样式改成 Tailwind 类
2. 移动端菜单用 Dialog 替代当前的 div
3. 添加键盘导航支持（Escape 关闭、Tab 循环）
4. 保持现有的 i18n 支持不变
参考文件：@src/components/Navigation.tsx

对比低效的方式：

你：看看 Navigation 组件
Claude：（读取文件，输出分析）
你：帮我重构一下
Claude：你想重构哪些方面？
你：样式改成 Tailwind
Claude：（修改样式）
你：还要加键盘导航
...

第二种方式消耗的上下文是第一种的 3-4 倍。

五、上下文污染与修复

"上下文污染"是指上下文中混入了错误信息、过时假设或矛盾指令，导致 Claude 的输出质量下降。

5.1 常见污染场景

5.2 如何判断上下文被污染了

几个信号：

1. Claude 开始"固执" — 你纠正了它，它下一轮又犯同样的错
2. 回答变得模糊 — 之前很精准的回答开始变得含糊
3. 忽略 CLAUDE.md 规则 — 之前遵守的规则突然不遵守了
4. 产生幻觉 — 引用不存在的函数、文件或 API

5.3 修复策略

轻度污染 → /compact + 自定义提示：

/compact 忽略之前所有关于方案 A 的讨论，只保留方案 B 的决策和当前进度

中度污染 → /clear + 重新提供关键上下文：

/clear
# 然后重新开始，一次性给出正确的上下文

重度污染 → 新会话：

直接关掉终端，开一个新的 Claude Code 会话。有时候这是最快的方式。

六、会话策略

6.1 长会话 vs 短会话

经验法则： 一个任务如果超过 20 轮对话，考虑 /compact 或拆分成多个短会话。

6.2 任务型会话规划

推荐的工作流：

会话 1：规划阶段
  → 分析需求，确定方案，输出任务清单
  → /clear

会话 2：实现阶段
  → 按任务清单逐个实现
  → 每完成一个子任务，/context 检查用量
  → 上下文超过 60% 时 /compact
  → /clear

会话 3：测试和修复
  → 跑测试，修 bug
  → /clear

会话 4：Review 和收尾
  → Code review，文档更新，提交

6.3 多终端并行

对于大型任务，可以开多个终端并行处理：

# 终端 1：前端组件
claude "重构 Navigation 组件"
 
# 终端 2：后端逻辑
claude "优化 getPostsByLocale 性能"
 
# 终端 3：测试
claude "给 posts.ts 补充边界测试"

每个终端有独立的上下文，互不干扰。这是最干净的并行方式。

七、实战示例一：通用开发

场景：给博客添加全文搜索功能。

第一阶段：规划（新会话）

claude

你：我要给 Next.js 博客添加 Pagefind 全文搜索。
当前搜索是 URL query 过滤，参考 @src/components/SearchBar.tsx
要求：
1. 构建时生成搜索索引
2. 客户端搜索组件替换现有 SearchBar
3. 支持中英文
4. 保持现有的 URL query 兼容

先帮我做技术方案，不要写代码。

Claude 输出方案后：

/clear    # 规划完成，清空上下文

第二阶段：实现（新会话）

claude

你：实现 Pagefind 搜索，方案如下：
1. 安装 pagefind，在 next.config.ts 添加 postbuild 脚本
2. 新建 SearchBar 组件用 @pagefind/default-ui
3. 中文支持用 pagefind 的 CJK 分词
开始第 1 步。

每完成一步：

/context   # 检查上下文用量

如果超过 60%：

/compact 保留：已完成的步骤、当前文件修改清单、下一步计划

第三阶段：测试（新会话）

npm run build 2>&1 | claude "构建报错了，帮我分析"

用管道直接喂错误日志，精准高效。

八、实战示例二：Flutter 开发

场景：Flutter 应用中，一个复杂的状态管理 bug — 用户在 ProfileScreen 修改头像后，HomeScreen 的头像没有更新。

第一阶段：定位问题（新会话）

claude

你：Flutter 应用有个状态同步 bug：
- 用户在 ProfileScreen 修改头像后，HomeScreen 的头像没更新
- 状态管理用的 Riverpod
- 相关文件：
  @lib/providers/user_provider.dart
  @lib/screens/profile_screen.dart
  @lib/screens/home_screen.dart
  @lib/widgets/avatar_widget.dart

先分析可能的原因，不要改代码。

Claude 分析后，确认是 userProvider 的状态没有正确通知监听者。

/compact 保留：bug 原因是 userProvider 在更新头像时创建了新的 state 对象但没有触发 notifyListeners，需要修改 user_provider.dart 的 updateAvatar 方法

第二阶段：修复（继续当前会话）

你：确认了，修复 user_provider.dart 的 updateAvatar 方法，确保状态变更能通知到所有监听者。

修复完成后：

/context   # 检查用量

第三阶段：验证（看情况决定是否新会话）

如果上下文还充裕（< 50%），继续当前会话：

你：修复看起来对了。现在帮我检查其他地方有没有类似的问题 — 搜索所有 provider 中直接修改 state 属性而没有用 copyWith 的地方。

如果上下文已经很满（> 70%），开新会话：

/clear

你：刚修了一个 Riverpod 状态同步 bug（provider 更新时没有正确创建新 state）。
帮我检查项目中其他 provider 有没有类似问题。
重点看 @lib/providers/ 目录下所有文件。

Flutter 特有的上下文技巧

# 喂 Widget 树结构
flutter analyze 2>&1 | claude "分析这些 lint 警告"
 
# 喂构建错误
flutter build apk 2>&1 | claude "分析构建错误"
 
# 喂测试结果
flutter test test/unit/providers/ 2>&1 | claude "分析失败的测试"
 
# 喂特定的 Widget 测试
flutter test test/widget/home_screen_test.dart 2>&1 | claude "这个 Widget 测试为什么失败"

Flutter 项目的上下文管理要点：

1. Widget 树很深 — 不要让 Claude 一次读太多嵌套的 Widget 文件，聚焦于相关的 2-3 个文件
2. State 流向要说清楚 — 在提示中明确说明数据从哪里来、到哪里去
3. 平台差异要提前说 — 如果 bug 只在 iOS/Android 某一端出现，提前告知
4. pubspec.yaml 很有用 — 让 Claude 先看 pubspec.yaml 了解依赖版本，避免给出不兼容的建议

九、进阶技巧

9.1 自动压缩设置

Claude Code 支持在上下文接近上限时自动压缩。在 settings.json 中配置：

{
  "autoCompact": true
}

开启后，当上下文使用超过阈值时，Claude 会自动执行压缩。

你也可以设置自定义的压缩提示，让自动压缩保留你关心的信息：

{
  "autoCompact": true,
  "compactPrompt": "保留：文件修改清单、架构决策、待办事项。丢弃：中间调试过程、已解决的错误。"
}

9.2 CLAUDE.md 与上下文效率

CLAUDE.md 在每次对话开始时都会被加载到上下文中。所以：

• 写得精简 — 每多一行 CLAUDE.md，就少一行给实际工作的空间
• 用层级结构 — 全局 CLAUDE.md 放通用规则，项目级放项目特定规则，子目录级放模块规则
• 避免重复 — 不要在 CLAUDE.md 中重复写框架文档里已有的内容

详细的 CLAUDE.md 写法参考 CLAUDE.md 完全指南。

9.3 Memory 文件

Claude Code 支持持久化记忆文件（~/.claude/ 目录下）。把跨会话需要记住的信息写入 memory 文件，而不是每次都在对话中重复：

# Claude 会自动读取 memory 文件
# 适合存放：项目架构概览、常用命令、个人偏好

Memory 文件和 CLAUDE.md 的区别：

9.4 结合 Hooks 优化上下文

用 Hooks 自动处理重复性工作，减少对话来回：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "command": "npx prettier --write \"$CLAUDE_FILE_PATH\""
      }
    ]
  }
}

有了这个 Hook，你不需要在对话中说"帮我格式化一下"，自动完成。每省一轮对话，就省一份上下文。

十、常见问题

Q: /compact 和 /clear 怎么选？ A: 任务没完成用 /compact（保留进度），任务完成或要换任务用 /clear（干净重来）。

Q: 上下文满了会怎样？ A: Claude Code 会自动压缩早期对话。但自动压缩不如你手动 /compact 精准，因为它不知道你觉得什么重要。

Q: 管道输入和 @ 引用哪个好？ A: 管道输入适合动态内容（命令输出、错误日志），@ 引用适合静态文件。两者可以混用。

Q: 多长的会话算"太长"？ A: 没有绝对标准。但如果你发现 Claude 开始忘记之前的约定，或者响应明显变慢，就该 /compact 或 /clear 了。一般 20-30 轮对话后建议检查一次。

Q: /resume 恢复的会话会不会很快就满？ A: 会。恢复的会话带着之前的完整上下文。如果之前的会话已经很长，恢复后建议立即 /compact，只保留需要继续的部分。

Q: 怎么减少 Claude 读取不必要的文件？ A: 在提示中明确指定相关文件（用 @ 引用），Claude 就不需要自己去探索。另外，CLAUDE.md 中写清楚项目结构，Claude 能更快定位到正确的文件。

总结

上下文管理的核心就三件事：

1. 知道上下文里有什么 — 用 /context 监控，理解每个操作的上下文成本
2. 保持上下文干净 — 及时 /compact 或 /clear，不要让无用信息堆积
3. 精准喂上下文 — 用管道、@ 引用、结构化提示，一次到位

把上下文管理当成一个习惯，而不是出了问题才想起来的补救措施。

推荐阅读

• Claude Code 进阶指南 — 上下文管理最初的介绍在这里
• CLAUDE.md 完全指南 — 写好 CLAUDE.md 是上下文效率的基础
• Claude Code Hooks 完全指南 — 用 Hooks 减少重复对话
• Claude Code 官方文档 — 官方的完整说明