何时使用 /clear

/clear 做了什么

/clear 是 Claude Code 的会话重置命令。执行它后，Claude 的对话上下文会被完全清除——就像你关闭了当前对话窗口，重新开始了一段全新的对话。

> /clear

执行后的效果：

• 所有对话历史被清除
• Claude “忘记”之前讨论的所有内容
• CLAUDE.md 会被重新加载（因为它是在每次会话开始时自动读取的）
• 之前对文件做出的修改不受影响（它们已经保存到了文件系统中）
• 上下文窗口恢复为初始状态，拥有完整的可用空间

应该使用 /clear 的场景

以下是一些明确需要 /clear 的信号。

场景一：Claude 开始频繁犯错

当 Claude 的回复质量明显下降时，通常是上下文被污染的信号：

# 这些现象说明你该 /clear 了：
- Claude 修改了你明确说过不要改的文件
- Claude 混淆了两个不同模块的逻辑
- Claude 引用了不存在的函数或变量名
- Claude 给出了与之前讨论矛盾的方案

长时间的对话会导致上下文中积累大量信息，Claude 可能在其中迷失方向。/clear 可以让它”重新来过”。

场景二：上下文被不相关的信息充满

如果之前的对话涉及了很多你当前任务不需要的内容：

# 比如你之前花了 20 轮对话在调试一个 CSS 问题，
# 现在要开始写后端 API。之前的 CSS 讨论对后端任务毫无帮助，
# 反而占据了大量上下文空间。
> /clear

# 在全新的上下文中开始后端任务
> 在 src/routes/ 中添加一个用户注册的 API 端点...

场景三：完全切换到不同的任务

当你要开始一个与之前完全无关的新任务时：

# 之前的任务：重构数据库层
# 新的任务：配置 CI/CD 流水线

# 两个任务之间没有关联，前者的上下文对后者没有帮助
> /clear

# 开始新任务
> 帮我配置 GitHub Actions 的 CI 流水线...

场景四：长时间调试后

调试过程通常会在上下文中留下大量”噪音”——失败的尝试、错误日志、被否定的方案：

# 经过长时间调试，问题已经解决
# 上下文中充满了错误日志和各种失败的尝试
> /clear

# 在干净的上下文中继续项目其他工作
> 接下来我们开始实现用户通知功能...

场景五：Claude 开始”重复自己”

当你注意到 Claude 反复给出相似的回答，或者循环在相同的思路上时：

# Claude 反复建议同一个解决方案，即使你告诉它那个方案不可行
# 这说明上下文中的信息让它"锁定"在了错误的方向上
> /clear

# 重新描述问题，提供必要的约束条件
> 我需要解决 X 问题。之前尝试了 Y 方案但不可行，因为 Z 原因。
> 请提供其他方案。

不应该使用 /clear 的场景

/clear 不是万能的，有些时候使用它反而会降低效率。

场景一：任务进行到一半

如果你正在一个多步骤任务的中间，Claude 已经积累了大量有价值的上下文：

# 你已经花了 10 轮对话和 Claude 讨论了重构方案，
# Claude 对你的代码结构、修改计划都有了深入理解。
# 这时候 /clear 会让一切从头开始。

# 应该使用 /compact 而不是 /clear
> /compact 保留重构方案的设计决策和已完成的修改清单

场景二：Claude 已经了解了项目特有的模式

在对话中，Claude 可能通过阅读代码学到了项目的特定模式（比如自定义的错误处理方式、独特的架构约定）。这些”学到的知识”在 /clear 后会丢失。

# 如果 Claude 花了几轮对话理解了你的自定义 ORM 的用法，
# /clear 后它就要重新学习。
# 考虑把这些重要模式写入 CLAUDE.md，这样 /clear 后也不会丢失。

场景三：需要引用之前的决策

如果后续任务需要参考之前的讨论结果：

# 之前你和 Claude 一起确定了数据库表结构设计，
# 接下来要基于这个设计编写代码。
# /clear 会让 Claude 忘记表结构设计的讨论。

# 解决方案 1：使用 /compact 而非 /clear
# 解决方案 2：把关键决策记录到 CLAUDE.md 或单独的文档中

/clear vs /compact：选择正确的工具

这两个命令都用于管理上下文，但适用场景不同。

/compact 适用于

• 同一个任务还在继续，但对话太长了
• 需要保留核心讨论结果，只是压缩细节
• 任务有多个阶段，阶段之间有依赖关系
• 想要释放一些上下文空间，但不想从头开始

/clear 适用于

• 任务已完成，要开始新任务
• 上下文严重被污染，/compact 也无法挽回
• 完全切换工作方向
• Claude 陷入了错误的推理循环

决策流程

面对”该用 /clear 还是 /compact”的抉择时，可以问自己以下问题：

1. 当前任务完成了吗？ 如果是 — 使用 /clear
2. 新任务和旧任务有关联吗？ 如果没有 — 使用 /clear
3. Claude 是否在重复犯错？ 如果是，且 /compact 后仍然犯错 — 使用 /clear
4. 之前的上下文还有用吗？ 如果有 — 使用 /compact

建立高效的会话节奏

成熟的 Claude Code 用户通常会建立一种自然的”会话节奏”，知道什么时候该继续、什么时候该压缩、什么时候该重置。

典型的工作会话流程

1. 开启新会话（/clear 或新启动 Claude Code）
   ↓
2. 执行第一个任务（5-10 轮对话）
   ↓
3. 任务完成，检查 /cost
   ↓
4. 决策点：
   - 下一个任务相关？→ /compact，然后继续
   - 下一个任务无关？→ /clear，然后开始
   ↓
5. 执行下一个任务
   ↓
6. 重复步骤 3-5

按时间的会话管理

按任务类型的会话管理

• 快速修复（修一个小 bug、改个配置）：一个干净的会话，完成后 /clear
• 功能开发（实现一个新功能）：可能需要 1-2 次 /compact，完成后 /clear
• 大规模重构：按模块拆分为多个会话，每个模块一个 /clear
• 代码审查：通常一个干净的会话就够了

高效重启的技巧

当你决定使用 /clear 时，如何快速恢复工作状态很重要。

技巧一：在 CLAUDE.md 中记录长期上下文

把不想丢失的信息写入 CLAUDE.md，这样每次 /clear 后都能自动恢复：

# 当前重构计划
- [x] Phase 1: 提取数据库层
- [x] Phase 2: 统一错误处理
- [ ] Phase 3: 添加缓存层
- [ ] Phase 4: 性能优化

技巧二：用简洁的开场白恢复上下文

/clear 后，用一段简短的说明快速将 Claude 带回工作状态：

> 我正在对用户模块进行重构。Phase 1 和 Phase 2 已经完成（提取数据库层
> 和统一错误处理）。现在开始 Phase 3：在 src/services/ 的服务层添加
> Redis 缓存。请先阅读 src/services/userService.ts 了解现有结构。

技巧三：保存关键信息到文件

在 /clear 之前，让 Claude 把重要信息保存到文件中：

> 把我们讨论确定的 API 接口设计方案保存到 docs/api-design.md
> /clear
> 阅读 docs/api-design.md，我们要根据这个方案开始编码

小结

/clear 是一个简单但强大的工具。关键在于把握使用时机：

应该 /clear：

• 任务完成，开始新任务
• 上下文被严重污染
• Claude 陷入错误循环
• 完全切换工作方向

不应该 /clear：

• 任务进行到一半
• Claude 已经积累了有价值的上下文
• 后续工作需要引用之前的讨论

核心原则：

• /compact 是”整理房间”，/clear 是”搬到新房间”
• 在 /clear 前，把重要信息存入 CLAUDE.md 或文档文件
• 建立适合自己的会话节奏，让每次 /clear 都是一个有意识的决策
• 用简洁的开场白快速恢复工作状态