Claude Code Slash Commands 实战：更长会话、更稳改动、更可控成本

Claude Code 真正进入日常开发之后，问题很快就不再是“能不能生成代码”，而是：

• 会话一长，模型开始忘事
• 改动跨多个文件后，很难确认它到底改了什么
• 一次试错走偏，想撤回却不干净
• 简单任务也在用高成本模型和高推理强度
• 同样的提示词反复敲，效率很低

这些问题本质上都不是“写代码”问题，而是会话管理、上下文管理、变更控制和成本控制问题。Claude Code 的 slash commands，就是这层操作接口。

斜杠命令到底解决什么问题？

结论很直接：当 Claude Code 会话超过几轮、开始涉及多文件修改时，斜杠命令就不是可选项，而是基本操作。

它们大致分成五类：

1. 上下文管理

   • /compact
   • /clear
   • /context

2. 规划与审查

   • /plan
   • /diff

3. 保持任务聚焦

   • /goal
   • /btw

4. 会话导航与回退

   • /resume
   • /branch
   • /rewind

5. 成本与性能控制

   • /cost
   • /model
   • /effort

另外还有一类常被低估但实际很有价值的能力：自定义命令。把反复输入的提示模板做成命令文件后，一行就能触发。

先看一张总表。

哪些命令最值得先掌握？

适合优先掌握的是下面这 13 个命令。

有两个兼容性细节需要记住：

• /cost 现在是 /usage 的别名
• /fork 是 /branch 的别名

如果一时记不住，直接在 Claude 会话中输入 /，就能看到可用命令列表。

斜杠命令、CLI flags、快捷键分别该在什么时候用？

结论：三者作用在不同时间点，不互相替代。

• CLI flags：启动前配置会话
• 快捷键：会话中断、切换模式、快速回退
• 斜杠命令：会话内部的精细控制

例如：

claude --model claude-opus-4-6
claude --continue

这类是 CLI flags，决定会话怎么启动。

而下面这些属于会话内操作：

• Esc：中断当前响应
• Esc Esc：打开 rewind 菜单
• Shift+Tab：在 plan mode、accept edits、auto mode 间切换

slash commands 则是工作流主体，比如：

/compact
/plan
/clear

实际使用时的判断标准很简单：

• 会话还没开始：优先用 CLI flags
• 要打断或快速切模式：用快捷键
• 要管理当前会话状态：用 slash commands

为什么上下文窗口管理比很多人想象得更重要？

结论：上下文窗口不是到 100% 才出问题，质量通常会先下降。

Claude Code 的上下文窗口承载的内容很多，包括：

• 对话历史
• 文件内容
• 命令输出
• CLAUDE.md 指令
• MCP 上下文
• 系统提示词

一旦会话变长，模型往往会先出现“局部遗忘”：

• 忘记你一开始说过的目录结构
• 忘记先前定下的限制条件
• 把前后两个问题混在一起
• 对已讨论过的架构点反复偏航

所以真正有效的策略，不是“等满了再处理”，而是在上下文开始拥挤之前主动整理。

什么时候该用 /compact？

结论：同一任务要继续做，但上下文开始变重时，用 /compact。

/compact 会把较早的对话压缩成摘要，释放 token 空间，同时尽量保留先前发生过的关键内容。

最基本的用法：

/compact

更推荐的用法是明确告诉它保留什么：

/compact focus on the auth module
/compact retain the error handling patterns we discussed
/compact focus on the schema decisions and the pipeline DAG

这样生成的摘要会优先保留这些重点，而不是平均压缩所有内容。

一个比较实用的经验规则是：

• 上下文占用超过 80% 之前就做 compact

原因很现实：等窗口几乎满了再压缩，模型本身已经处在退化状态，摘要质量也会更差。

还有一个容易忽略的点：

• CLAUDE.md
• 已加载的 skills
• memory files

这些内容在 compact 时会自动保留，不需要额外强调。

什么时候该用 /clear？

结论：任务边界一变，就该 clear。

/clear 会彻底清空当前对话历史，启动一个干净的新会话。

例如：

/clear
/clear payment-refactor

如果传入名称，旧会话会在 /resume 选择器里带着这个标签保存下来，之后可以继续回来。

/compact 和 /clear 的区别非常关键：

比如刚刚还在排查数据加载器，接下来要去做一个完全无关的可视化模块。这种情况下继续带着旧上下文，通常弊大于利。模型会继承旧约束、混入旧术语、误判当前目标。

/context 有什么实际价值？

结论：在决定 compact 还是 clear 之前，先看 /context。

/context 会把当前上下文窗口使用情况可视化展示出来，并按类别拆分 token 消耗，例如：

• Conversation history
• File contents
• Memory files
• Loaded skills

基本用法：

/context

展开更细的逐项信息：

/context all

这个命令的价值在于，它不只是告诉你“用了多少”，还会提示哪些项目占用了异常多的空间。

适合养成的习惯是：

• 在开始大型任务前先跑一次 /context
• 如果发现窗口已经被之前的对话占了 60% 以上，不要直接开一个多文件重构

很多“Claude 怎么突然变笨了”的问题，本质上都能在 /context 里提前看出来。

为什么多文件修改前应该先规划，再审查？

结论：一旦任务跨多个文件，先 /plan，完成后看 /diff，这是最省返工的做法。

让模型在需求不够清晰时直接开始改文件，最容易造成两个后果：

1. 改动范围失控
2. 前几轮的错误被后几轮不断放大

/plan 适合哪些任务？

结论：不熟悉代码库、改动范围大、描述本身含糊时，先用 /plan。

/plan 会让 Claude 进入只读模式。它会先分析代码库、提出执行计划，等你确认后再真正改文件。

例如：

/plan refactor the feature engineering pipeline to support lazy evaluation

适合它的典型情况有三类：

• 不熟悉当前代码库
• 改动涉及多个文件
• 任务本身有歧义，需要先明确路径

像下面这些任务都很适合先规划：

• 迁移 feature store
• 重构 ETL 逻辑
• 调整积累多年 patch 的训练脚本
• 大范围重命名和依赖替换

如果已经在会话中途，想快速切到 plan mode，也可以直接用快捷键：

Shift+Tab

/diff 为什么比看 git diff 更适合会话审查？

结论：/diff 不是替代 git diff，而是更适合审查“这个会话到底做了什么”。

运行：

/diff

会打开交互式 diff viewer，展示当前会话造成的全部文件修改。

导航方式：

• 左右方向键：在累计 git diff 和逐轮 diff 之间切换
• 上下方向键：在文件之间浏览

它的核心价值是把变更和会话过程绑定起来。这样可以快速确认几件事：

• 有没有改到不该改的文件
• 有没有出现范围蔓延
• 某一轮到底引入了什么修改
• 提交前是否清楚自己要提交什么

如果把 /plan 看成“先设计”，那 /diff 就是“最后验收”。

如何避免长会话里跑题？

结论：要让 Claude 在长任务里持续朝一个目标推进，用 /goal；要处理中途冒出的旁路问题，用 /btw。

/goal 什么时候最有用？

结论：任务会跑很多轮，而且完成条件明确时，用 /goal。

/goal 会设置一个持续生效的高层目标。目标设定后，Claude 会持续工作，直到满足你定义的条件。

例如：

/goal All tests in the data pipeline are passing with no deprecation warnings

这种能力特别适合：

• 大型迁移
• 修复整套测试
• 需要多轮连续推进的清理工作

状态栏里会出现一个实时进度信息，显示：

• 已用时间
• 轮次数
• token 使用量

如果中途想取消目标：

/goal clear

需要注意的是，这个命令要求目标描述足够明确。模糊目标只会把不确定性放大。好的目标通常具备清晰终态，例如“所有测试通过且没有 deprecation warning”，而不是“把这块整理一下”。

/btw 为什么能减少上下文污染？

结论：主任务进行中突然想到一个小问题，不要直接插到主线程里，改用 /btw。

例如：

/btw what was that config option for SQLAlchemy connection pooling called again?

Claude 会在一个 overlay 里回答这个问题，但不会把这个旁路问题并入主会话线程。

这解决的是一个很常见的问题：

• 不问，会忘
• 直接问，会打断主线并污染上下文

/btw 本质上是一个“旁注通道”。很适合查：

• 某个配置名
• 某个命令参数
• 某段术语解释
• 与当前大任务无关但临时需要确认的小点

长项目怎么恢复、分叉和回滚？

结论：跨天工作靠 /resume，探索不同方案靠 /branch，出错回退靠 /rewind。

长项目不可能都塞进一个会话里。真正可用的工作流，必须支持接着做、试岔路、再撤回。

/resume 怎么和 CLI 的 continue 配合？

结论：启动前恢复最近会话，用 CLI；会话中切回旧项目，用 /resume。

基本用法：

/resume
/resume payment-refactor

不带参数时，会弹出一个按日期排序的会话选择器，并带有最后一条提示的大致信息。传入会话名称或 ID 则直接跳转。

对应的 CLI 方式是：

claude --continue
claude -c
claude --resume <id>

这两类方式做的是同一件事，只是入口不同：

• 还没进入会话：CLI 更顺手
• 已经在会话中：slash command 更方便

Claude Code 会把每个会话以 JSONL 格式保存在本地：

~/.claude/projects/

其中会记录：

• 每条消息
• 每次工具调用
• 每次工具结果

这也是 /resume、/rewind、/branch 能工作的基础。

/branch 和 /fork 有什么区别？

结论：没有区别，当前规范名是 /branch。

例如：

/branch try-polars-instead-of-pandas

它会在当前状态复制出一个新分支，并自动切换过去，原始会话保持不变。

适合它的场景：

• 想试另一种实现方案，但不想破坏当前结果
• 同一个上下文下有两条可能路径
• 当前会话积累了很多背景信息，不想从头再讲一遍

这和 git branch 的直觉基本一致：先分叉，再实验，成功就继续，失败就回原线。

兼容名：

/fork

很多旧资料会写 /fork，现在更标准的名字是 /branch，但两者都能用。

/rewind 能回退哪些东西，不能回退哪些东西？

结论：/rewind 是会话级撤销工具，但只对 Claude 通过官方工具做出的文件操作有效。

运行：

/rewind

会打开交互式菜单，用方向键选择要回滚到哪一轮。

可选的回滚范围有三种：

• Both（默认）

  • 文件恢复到该轮状态
  • 之后的对话消息全部删除
  • 适合整段工作都走偏的情况

• Conversation only

  • 删除之后的对话
  • 保留文件修改
  • 适合代码没问题，但后续讨论质量差的情况

• Code only

  • 恢复文件
  • 保留对话
  • 适合想保留分析过程，但撤掉代码落地结果的情况

快捷方式是：

Esc Esc

但有一个明确限制：

• 只有 Claude 通过官方工具执行的文件操作，才会被追踪并可回滚
• 你在外部编辑器里手动改的内容，不在 /rewind 的回滚范围内

这点很关键。不要把 /rewind 当成完整的 IDE undo。它更像是受控会话操作的撤销机制。

成本和性能该怎么调，而不是一路开满？

结论：不要把最强模型和最高 effort 当默认值。根据任务类型切换 /model 和 /effort，再用 /cost 持续监控。

如果走 API 计费，token 花费是真成本；如果是 Pro 或 Max 套餐，消耗的是额度。两种情况下都不应该让每个任务都跑最贵配置。

/cost 该看什么？

结论：重任务开始前看一次，长会话中间再看几次。

/cost 是 /usage 的别名。

/cost

它显示的内容取决于账户类型：

• API 用户

  • token 数
  • cache 使用
  • 按模型拆分的美元成本

• Pro / Max 订阅用户

  • 当前账期内的使用量与配额关系

比较稳妥的做法：

1. 开始重会话前看一次，建立基线
2. 中途定期看
3. 如果消耗爬升过快，再调整 model 或 effort

/model 什么时候值得中途切换？

结论：同一个会话里，任务性质变了，就该切模型。

基本用法：

/model
/model claude-haiku-4-5

不带参数时会打开交互式选择器，可用方向键切换。

一个实用策略是：

1. 用 Claude Opus 处理复杂架构推理
2. 切到 Claude Sonnet 执行主要实现任务
3. 再降到 Claude Haiku 做机械性工作，比如变量重命名、docstring 生成、样板代码填充

在大规模使用时，Opus 和 Haiku 的成本差距大约有 10 到 20 倍。这不是小差别。

另一个版本细节也值得注意：

• 从 v2.1.153 开始，使用 /model 选中的模型会被保存为新会话默认值
• 在交互式选择器中按 s，可以只应用到当前会话，不修改默认值

/effort 应该怎么配任务？

结论：推理深度直接影响质量和成本，低复杂度任务不要开高 effort。

基本用法：

/effort
/effort low
/effort auto

当前可用级别包括：

• low
• medium
• high
• xhigh（2026 年 4 月）
• max（2026 年 5 月）
• ultracode（2026 年 5 月）

其中：

• max
• ultracode

只能用于当前会话，不能保存为默认值。

重置到模型默认值：

/effort auto

实用选择标准如下：

ultracode 需要特别谨慎。它会把 xhigh 推理和自动工作流编排结合起来，在复杂任务上可能一次性拉起 100+ agents，token 消耗会非常快。

还有一个版本信息：

• Opus 4.6 在 Max 和 Team 计划上的默认 effort，到了 2026 年 6 月是 high

所以很多时候不是“默认不够强”，而是“任务根本不需要更强”。

自定义 slash commands 值不值得做？

结论：只要某个提示词重复输入超过三次，就值得做成命令。

内置命令解决的是通用操作问题，而自定义命令解决的是团队和项目自己的重复动作。

典型例子包括：

• PR 描述生成
• 代码审查清单
• 部署前检查
• issue 修复模板
• 测试生成模板

把这些写成命令后，Claude Code 才会真正有“为当前项目定制过”的感觉。

现在该用 commands 还是 skills？

结论：新项目优先用 skills，老项目的 .claude/commands/ 仍然可用。

当前做法已经把自定义 commands 和 agent skills 统一起来：

• 旧格式：.claude/commands/
• 新推荐格式：.claude/skills/<name>/SKILL.md

旧格式仍然支持，但已经属于 legacy。推荐优先使用 skills，原因有三个：

1. 仍然支持 /name 形式调用
2. Claude 可以根据描述自动匹配并自主调用
3. 可以把脚本、模板、参考文档等辅助文件一起打包

如果只是已有项目里已经大量使用 .claude/commands/，没必要立刻迁移；但新设计最好按 skills 来组织。

自定义命令文件应该放在哪？

结论：项目共享的放仓库里，个人习惯性的放家目录。

两种位置：

• 项目级

  • .claude/commands/
  • 位于项目根目录
  • 可提交到版本控制
  • 团队成员拉仓库后都能用

• 个人全局

  • ~/.claude/commands/
  • 当前机器所有项目可用
  • 只属于个人

例如：

• .claude/commands/fix-issue.md 对应命令 /fix-issue
• .claude/commands/frontend/component.md 对应命令 /component，并带一个 frontend 命名空间标识

如果使用 skills，则对应路径变成：

• 项目级：.claude/skills/<command-name>/SKILL.md
• 个人级：~/.claude/skills/<command-name>/SKILL.md

后面提到的 frontmatter 和 prompt body，用法是一致的。

自定义命令文件的最小格式是什么？

结论：本质上就是一个 Markdown prompt 模板。

最简单的例子，假设文件是：

.claude/commands/summarize-pr.md

内容可以直接写成：

Review the current git diff and write a concise pull request description.
Include: what changed, why it changed, and any important implementation notes.
Format as plain prose, not bullet points.

执行：

/summarize-pr

Claude 就会把文件内容当作提示词执行。

这种方式很适合先把重复 prompt 收敛起来，再逐步增加参数和约束。

YAML frontmatter 能控制哪些行为？

结论：至少应该掌握 description、allowed-tools 和 model。

例如：

---
description: Generate a PR description from the current diff
allowed-tools: Bash(git diff *), Read
model: claude-sonnet-4-6
---

这几个字段的作用分别是：

• description

  • 出现在 /help 列表中
  • 便于自己记住用途
  • 也便于 Claude 根据任务描述自动匹配调用

• allowed-tools

  • 限制执行这个命令时可用的工具
  • 有助于收缩范围，减少不必要的工具调用与上下文污染

• model

  • 将该命令固定到指定模型
  • 不受当前会话活动模型影响

如果命令本身是一个高度固定的工作流，比如“只读 staged diff 并生成 commit message”，把允许工具卡死通常是更安全的做法。

$ARGUMENTS 怎么让命令变得真正可复用？

结论：凡是需要传参的命令，都应该优先考虑 $ARGUMENTS。

下面是一个完整示例。创建文件：

.claude/commands/fix-issue.md

内容如下：

---
description: Find and fix a GitHub issue by number
allowed-tools: Read, Edit, Bash(git diff *)
argument-hint: [issue-number]
---

Find and fix issue #$ARGUMENTS in this repository.

Steps:
1. Read the relevant source files to understand the current behavior
2. Identify the root cause
3. Implement the fix with minimal scope — do not change unrelated code
4. Verify the fix does not break anything obvious
5. Write a brief explanation of what changed and why

调用方式：

/fix-issue 847

Claude 实际接收到的 prompt 中，$ARGUMENTS 会被替换成 847。

如果一个命令需要多个位置参数，也可以使用：

• $0
• $1
• …

这类位置参数适合结构更严格的输入场景。

如何把实时 shell 输出注入命令？

结论：需要基于当前仓库状态执行的命令，优先用 ! 注入实时命令输出。

示例：

---
allowed-tools: Read, Bash(git *)
description: Review staged changes before committing
---

Current staged diff:
!git diff --cached

Review these changes and suggest a clear, conventional commit message.
Flag any obvious bugs, missing tests, or incomplete logic before I commit.

这里的关键点是 !git diff --cached。

命令执行时，Claude 会先跑这条 shell 命令，把输出结果插入 prompt，再基于真实 diff 内容工作，而不是对一个占位符做猜测。

这一招很适合做：

• staged changes review
• PR 摘要
• 提交信息生成
• 当前分支状态检查
• 自动化部署前核对

把下面三种能力组合起来：

• frontmatter
• $ARGUMENTS
• ! shell 注入

基本就足够覆盖大部分团队里的重复提示工作流。

一套够用的起步组合该怎么选？

如果刚开始系统使用 Claude Code，不需要一次把所有命令都背下来。优先顺序建议如下：

1. 先掌握

   • /compact
   • /plan
   • /cost

2. 然后加入

   • /diff
   • /resume
   • /rewind

3. 任务更长后再加入

   • /goal
   • /btw
   • /branch

4. 工作流稳定后开始做

   • 自定义 commands / skills

这套顺序的好处是，每一步都直接对应一个真实痛点：

• 会话太长：/compact
• 改动太乱：/plan + /diff
• 花费失控：/cost
• 试错困难：/branch + /rewind
• 重复劳动太多：自定义命令

常见问题

/compact 和 /clear 的根本区别是什么？

/compact 是压缩历史并保留任务连续性，适合继续同一个任务；/clear 是清空上下文重新开始，适合切换到完全不同的任务。

/fork 和 /branch 是不是同一个命令？

是。当前版本里 /fork 是 /branch 的别名，规范名称是 /branch。

什么时候应该把 /effort 调到 high 以上？

当任务涉及复杂调试、多文件架构调整、推理深度明显影响结果时，才值得上 xhigh 或 max。普通代码生成、格式整理、简单重构，用 low 或 medium 更合适。

自定义命令能不能团队共享？

可以。放在项目目录下的 .claude/commands/ 中并提交到版本控制后，团队成员拉取仓库即可使用同样的命令。

/goal 和 /btw 分别从哪个版本开始支持？

• /goal 引入于 v2.1.139
• /btw 加入于 v2.1.72（2026 年 3 月）

如果当前版本没有这些命令，可以更新 Claude Code：

npm update -g @anthropic-ai/claude-code

关于

关注我获取更多资讯

📢 公众号

💬 个人号