Claude Code 常用命令与快捷键：上下文管理、回退、审查与远程控制

Claude Code 是运行在终端里的 AI（人工智能）编程 Agent。它不只是一个“问一句、答一句”的聊天工具，更像一个能读代码、改文件、跑命令、理解项目结构的开发助手。

很多人使用 Claude Code 时只会做一件事：输入需求，然后一步步确认。这样当然能用，但会遇到几个很典型的问题：

• 长任务执行到一半，临时想问一个无关问题，容易污染上下文。
• 让 Claude Code 试了一个方案，结果代码改乱了，不知道怎么回退。
• 同一个需求想尝试两种实现方式，只能开新会话重新解释。
• AI 写完代码后有冗余逻辑、重复实现、低效写法，但人工审查成本高。
• 有些任务需要每隔几分钟检查一次状态，手动盯着很麻烦。
• 出门后还想看终端里的 Claude Code 进度。

这些问题都可以用 Claude Code 的命令和快捷键解决。掌握这些能力之后，Claude Code 会更像一个可控的开发环境，而不是一个只能被动等待的聊天窗口。

快速索引：这些命令分别解决什么问题

/btw：临时提问但不污染上下文

Claude Code 处理长任务时，经常会连续读文件、修改代码、跑测试。如果这时突然插入一个无关问题，比如“测试文件在哪个目录”“当前抓取流程是什么”，普通提问会产生两个副作用：

1. Claude Code 会中断当前工作来回答问题。
2. 这个临时问题会进入对话历史，后续推理可能被无关内容影响。

这就是上下文污染。AI 编程 Agent 对上下文非常敏感，越长的会话越容易因为无关信息跑偏。

/btw 适合处理这种临时问题。它会在当前任务旁边开一个“顺手问一下”的支线问题，回答不会写入主对话历史，也不会打断正在执行的任务。

/btw 当前项目的测试文件放在哪个目录？

也可以在输入 /btw 后按空格，再继续写问题：

/btw 这个项目的抓取流程大概是什么？

它的行为可以理解成这样：

sequenceDiagram
    participant U as 用户
    participant C as Claude Code
    participant M as 主任务上下文
    participant B as 临时 btw 问题

    U->>C: 发起重构模块任务
    C->>M: 读取代码、修改文件、运行检查
    U->>C: /btw 问一个临时问题
    C->>B: 单独回答临时问题
    B-->>U: 返回答案
    C->>M: 主任务继续执行

/btw 的关键点不是“能问问题”，而是“问完不留下上下文痕迹”。如果临时答案只是当场确认一下，直接清掉即可；如果这个答案后面确实会影响实现，就应该把它重新组织成明确要求，再发回主会话。

适合使用 /btw 的问题：

/btw 这个仓库的入口文件在哪里？
/btw 当前分支最近一次提交是什么？
/btw 这个错误码在哪些文件里出现过？
/btw 现在任务执行到哪一步了？

不适合用 /btw 的问题：

/btw 接下来请把架构改成事件驱动

这种会改变主任务方向的内容，应该直接进入主对话，而不是作为临时问题处理。

/rewind：代码和对话可以分开回退

/rewind 可以理解为 Claude Code 里的回退机制，快捷键是连续按两次 Esc。

它解决的是 AI 编程里最常见的风险：Claude Code 按你的要求试了一种方案，但结果不理想。如果没有回退能力，只能手动用 Git 恢复，或者让 Claude Code 自己再改回来。后者很容易越改越乱。

/rewind 的优势在于它不是简单地“撤销上一条消息”，而是可以分别处理代码和对话。

常见选项可以理解为四类：

最有用的是“只回退代码，保留对话”。例如你让 Claude Code 尝试一种缓存实现，代码写出来后发现方案不合适。这时回退代码，但保留讨论过程，Claude Code 仍然知道刚才为什么失败，可以继续换方向，而不用重新解释需求。

flowchart TD
    A[Claude Code 尝试方案 A] --> B{结果是否可接受}
    B -->|可接受| C[继续开发]
    B -->|不可接受| D[/rewind]
    D --> E{希望保留讨论过程吗}
    E -->|保留| F[只回退代码]
    E -->|不保留| G[代码和对话一起回退]
    F --> H[基于失败原因尝试方案 B]
    G --> I[回到更早节点重新开始]

/rewind 很适合和 Git 配合使用，但不应该完全替代 Git。更稳妥的方式是：

git status
git diff

确认改动范围后，再决定使用 /rewind、手动修改，还是提交一个稳定检查点。

/insights：让 Claude Code 分析你的使用习惯

/insights 会根据过去一段时间的 Claude Code 使用记录生成一份本地 HTML（HyperText Markup Language，超文本标记语言）报告。报告通常会包含这些内容：

• 常用命令统计
• 高频任务类型
• 重复出现的操作模式
• 容易失败或反复修改的环节
• 可以沉淀成自定义命令的工作流
• 可以封装成 Skills 的常见任务

使用方式很简单：

/insights

它的价值在于把“无意识的重复操作”找出来。比如你每次都让 Claude Code 做同一套检查：

检查最近改动有没有重复逻辑
确认有没有多余 import
跑一遍测试
总结潜在风险

如果这种模式反复出现，就适合做成自定义命令或 Skill，而不是每次手写一遍。

可以把 /insights 当作 Claude Code 使用方式的诊断工具：

如果团队内部多人都用 Claude Code，定期查看这类报告也有助于统一工作方式：哪些检查应该自动化，哪些提示词应该标准化，哪些任务不适合交给 Agent 独立完成。

/model opusplan：把高级模型额度用在规划阶段

Claude Code 常见模型组合里，Opus 更适合复杂推理，Sonnet 更适合日常编码执行。规划阶段和写代码阶段对模型能力的要求并不一样：

/model opusplan 的作用是：在需要复杂推理时自动以 plan mode 使用 Claude Opus 4.6，把高级模型更多用于“想清楚怎么做”，而不是全程消耗在具体编码上。

/model opusplan

这种模式适合：

• 订阅额度有限，但又希望关键规划阶段用更强模型。
• 项目结构复杂，需要先做方案分析。
• 需求不明确，需要 Claude Code 先拆解任务。
• 不想让 Opus 全程参与每一次小改动。

一个比较稳的用法是先让 Claude Code 做计划，再让它执行：

/model opusplan

请先分析这个项目的认证流程，给出改造方案，不要修改代码。
确认方案后，再按步骤实现。

这样可以减少“边想边改”带来的风险。复杂项目里，先规划再动手通常比直接让 AI 改代码更可靠。

/simplify：让多个 Agent 并行审查代码

AI 生成代码很容易出现几类问题：

• 相同逻辑在多个地方重复实现。
• import、变量、辅助函数没有清理干净。
• 为了满足需求写了过度复杂的结构。
• 可以复用项目已有工具函数，却重新写了一套。
• 性能热点里使用了低效循环或不必要的 IO（Input/Output，输入/输出）。

/simplify 是一个内置 Skill，核心思路是并行启动多个 Agent，从不同角度审查改动。通常可以理解成三个方向：

flowchart LR
    A[当前代码改动] --> B[代码复用 Agent]
    A --> C[代码质量 Agent]
    A --> D[运行效率 Agent]

    B --> E[发现重复逻辑、可复用模块]
    C --> F[发现复杂写法、命名、结构问题]
    D --> G[发现性能和资源使用问题]

    E --> H[汇总优化建议]
    F --> H
    G --> H

使用方式：

/simplify

它适合放在一个开发小周期的末尾，例如：

请实现用户登录失败次数限制，并补充测试。

Claude Code 完成后，再执行：

/simplify

simplify 不只是找 bug，更偏向“把代码变简单”。它可能会指出：

使用 /simplify 时，不建议无脑接受所有修改。更好的做法是让 Claude Code 先列出建议，再选择执行：

/simplify

只列出建议，不要直接修改代码。按风险从高到低排序。

确认建议后，再让它逐项修改。

/branch：从当前会话分叉出新方向

/branch 用来从当前对话状态创建一个新会话，原来的会话不受影响。旧命令 /fork 仍然可能可用，但推荐使用 /branch。

/branch

它适合处理“当前上下文有价值，但想试另一条路”的场景。

例如 Claude Code 已经理解了项目结构，也分析完了需求，现在有两个实现方向：

• 方案 A：在现有服务里加一个同步接口。
• 方案 B：引入异步任务队列。

如果直接在同一个会话里来回切换，Claude Code 很容易混淆。使用 /branch 可以把当前上下文复制出一份，让两个方向独立发展。

flowchart TD
    A[已完成需求分析的主会话] --> B[/branch]
    B --> C[分支会话 A：同步接口方案]
    B --> D[分支会话 B：异步队列方案]
    C --> E[比较实现复杂度、测试结果]
    D --> E
    E --> F[选择更合适的方案]

/branch 和 /rewind 很容易混淆，可以这样区分：

适合用 /branch 的情况：

当前方案可行，但我想试一个更简单的实现。

适合用 /rewind 的情况：

刚才的实现已经把代码改乱了，我想撤回。

/loop：让 Claude Code 定时执行任务

/loop 用来让 Claude Code 按固定间隔重复执行任务。基本格式是：

/loop 时间间隔 任务描述

例如每 5 分钟检查一次部署状态：

/loop 5m 检查一下部署状态，如果失败就读取日志并总结原因

如果不写时间间隔，默认间隔通常是 10 分钟。

它适合这些短期循环任务：

/loop 的特别之处是，结果会继续出现在 Claude Code 会话里。Claude 不只是机械重复命令，还能根据前几次结果判断下一步该做什么。

flowchart TD
    A[/loop 5m 检查部署状态] --> B[第 1 次检查]
    B --> C{是否完成}
    C -->|未完成| D[等待 5 分钟]
    D --> E[第 2 次检查]
    E --> F{是否失败}
    F -->|失败| G[读取日志并总结原因]
    F -->|未失败| D
    C -->|完成| H[停止关注并反馈结果]

需要注意，/loop 更适合短期任务，不适合当作永久定时任务系统。很多循环任务会在创建一段时间后自动过期，例如 3 天后最后触发一次并自我删除，这可以避免被遗忘的任务一直运行。

如果是长期任务，应该使用更明确的系统方案，比如 cron、CI 定时任务、监控平台，或者 Claude Code 桌面版提供的持续运行能力。

/remote-control：用手机遥控本地 Claude Code

/remote-control 可以生成一个 URL（Uniform Resource Locator，统一资源定位符），用手机打开后，就能远程控制当前 Claude Code 会话。短命令是：

/rc

完整命令是：

/remote-control

它的工作方式不是把代码搬到手机上运行，而是让手机成为本地 Claude Code 的遥控界面：

flowchart LR
    A[手机浏览器] <-->|同步输入和输出| B[Claude Code 远程控制会话]
    B <-->|实际执行| C[本地电脑终端]
    C --> D[本地项目文件]
    C --> E[MCP 服务器]
    C --> F[本地环境变量和配置]

MCP（Model Context Protocol，模型上下文协议）服务器、项目文件、环境变量仍然在本地电脑上，手机只是远程发送指令和查看结果。

这个能力适合：

• 离开工位后查看长任务进度。
• 在手机上确认 Claude Code 的下一步操作。
• 临时补一句指令，不必重新打开电脑。
• 通勤或会议间隙查看构建、测试、部署结果。

安全上要注意两点：

1. 远程控制链接相当于当前会话入口，不要公开发送。
2. 手机端能操作的是本地 Claude Code，所以本地终端权限仍然需要谨慎控制。

/export：把会话导出成 Markdown

Claude Code 的很多价值并不只在最终代码里，还在中间讨论过程里。比如：

• 为什么选择某个架构方案。
• 哪些实现路线被排除。
• 某个 bug 的定位过程。
• Claude Code 读过哪些文件。
• 哪些测试失败过，后来怎么修复。
• 某个模块的上下文解释。

这些内容如果只留在会话里，后续检索和复用都不方便。/export 可以把当前会话导出为 Markdown 文件。

/export

导出后可以用于：

一个比较实用的工作方式是：当会话里已经形成稳定结论时，立刻导出，并把文件放进项目文档目录。

/export

然后可以整理成类似这样的结构：

docs/
  ai-notes/
    auth-refactor-discussion.md
    cache-design-debugging.md
    payment-webhook-investigation.md

如果导出的内容要进入仓库，记得检查是否包含密钥、内部地址、用户数据、访问令牌等敏感信息。

常用快捷键：输入效率会明显提升

Claude Code 是终端工具，很多效率问题其实来自输入方式。几个快捷键可以解决高频小麻烦。

截图粘贴很适合调试界面问题。比如浏览器报错、终端异常、测试失败截图，不需要先保存文件再拖进去，直接截图后粘贴即可。

多行输入可以让需求更清楚：

请修改登录接口，要求：

1. 连续失败 5 次后锁定 10 分钟
2. 锁定状态返回明确错误码
3. 补充单元测试
4. 不要改动现有 token 生成逻辑

相比一长串自然语言，多行结构化提示更容易让 Claude Code 按约束执行。

一套更稳的 Claude Code 工作流

这些命令不是孤立使用的。更稳定的方式是把它们组合成一个开发流程：

flowchart TD
    A[输入需求] --> B[/model opusplan 做方案规划]
    B --> C{方案是否明确}
    C -->|不明确| D[继续追问和补充约束]
    C -->|明确| E[开始实现]
    E --> F{中途有临时问题}
    F -->|有| G[/btw 临时提问]
    F -->|没有| H[继续实现]
    G --> H
    H --> I[功能完成]
    I --> J[/simplify 审查代码]
    J --> K{审查结果是否需要修改}
    K -->|需要| L[按建议修改]
    K -->|不需要| M[运行测试]
    L --> M
    M --> N{结果是否满意}
    N -->|不满意| O[/rewind 回退或 /branch 尝试新方向]
    N -->|满意| P[/export 保存关键上下文]

一个实际命令顺序可以是：

/model opusplan

请先分析当前项目的订单创建流程，给出支持优惠券的改造方案。
不要修改代码，只输出涉及文件、数据结构变化和风险点。

确认方案后：

按方案实现优惠券校验逻辑，并补充测试。

中途临时确认：

/btw 当前项目的订单测试文件在哪个目录？

完成后审查：

/simplify

如果方案失败：

/rewind

如果想保留当前方向，同时尝试另一种设计：

/branch

形成稳定结论后：

/export

使用这些命令时的几个坑

1. /btw 的答案不会进入主上下文

这正是它的优点，但也意味着重要信息不能只停留在 /btw 里。如果临时答案会影响实现，需要重新把它写进主任务。

刚才确认测试目录是 tests/orders。请在这个目录下补充订单优惠券相关测试。

2. /rewind 前仍然要看 diff

AI 改动范围可能比你想象得大。回退前后都建议检查：

git status
git diff

如果已经进入稳定状态，可以先提交检查点：

git add .
git commit -m "checkpoint before coupon refactor"

3. /simplify 的建议需要筛选

它可能会提出风格偏好的修改，但不是所有修改都值得做。对生产代码来说，低风险清理可以接受，涉及架构和行为变化的建议要单独确认。

4. /loop 不要执行危险命令

周期任务不适合写破坏性操作，例如反复删除文件、自动重启生产服务、自动修改数据库。更安全的方式是让 Claude Code 只检查和报告，真正的操作由人确认。

/loop 5m 检查部署状态，只报告结果，不要执行重启、回滚或删除操作

5. /remote-control 链接不要外传

远程控制链接能操作当前会话，应当像临时凭证一样处理。尤其是本地 Claude Code 有文件系统、命令执行、MCP 服务器访问能力时，更要避免链接暴露。

6. 命令能力可能随版本变化

Claude Code 更新很快，部分命令名称、行为和可用范围可能会变化。遇到命令不可用，可以先查看内置帮助或更新记录：

/help

更新记录地址：

https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

一句话记住这些命令

• 临时问问题，用 /btw。
• 改坏了想撤，用 /rewind。
• 想复盘用法，用 /insights。
• 想把 Opus 用在刀刃上，用 /model opusplan。
• 写完代码想审查，用 /simplify。
• 想试另一条路，用 /branch。
• 想定时检查，用 /loop。
• 想手机遥控，用 /rc。
• 想保存会话，用 /export。
• 想提升输入效率，记住 Ctrl+V、Ctrl+J、Ctrl+R、Ctrl+U。