本章在全书的位置：第五部分 · 第 21 章 / 预估阅读+动手时长：主线 20-25 分钟 + 支线 8 分钟
前置章节：Ch 18（常用斜杠命令）+ Ch 20（Skills）
学完能做什么（主线）：理解自定义 slash 命令和 Skills 的分工；建出你第一个
/xxx命令（10 行以内）；知道什么时候做成命令、什么时候做成 Skill。
- 你会遇到什么问题：每次开启任务都要敲同样一长段 prompt——"请严格遵守：A、B、C，输出格式 D"。累。
- 不读这章会踩什么坑：明明可以一键触发的动作，还是每次手工复制粘贴 prompt。
- 读完你会多会什么事：把反复用的 prompt 变成
/xxx一个命令——敲命令名 = 自动展开完整 prompt。
---
config:
theme: forest
themeVariables:
fontFamily: "-apple-system, 'SF Pro Text', 'PingFang SC', 'Helvetica Neue', sans-serif"
fontSize: "17px"
lineColor: "#D9D9D9"
---
mindmap
root((第 21 章 · 自定义 Slash 命令))
命令是什么
你主动敲的快捷键
展开成完整 prompt
和 Skill 的区别
Skill 靠 Claude 判断
命令靠你主动触发
建第一个命令
mkdir commands 目录
写 daily.md
敲 /daily 测试
命令里能写什么
提示词文字
嵌 ! shell 命令
嵌 @ 引用
参数占位符
什么时候值得做
敲过 5 次以上
多步骤组合
团队标准化
三者统一
CLAUDE.md 项目规则
Skill 任务手册
命令 你的快捷键
🎯 【主线】—— 本章必读核心
Ch 18 讲的 /clear、/compact、/status 等是 Claude Code 内置命令。你也可以自己建——以 / 开头，以你的自定义名字结尾：
/daily— 自动生成一条今日开工清单/review— 启动代码审查模板/ship— 按你的发布流程一步步走/focus— 切换到"不打扰"模式（关掉某些提示）
🔑 自定义 Slash 命令 = 你给自己起的、以斜杠开头的、一敲就自动展开成完整 prompt（或触发特定动作）的快捷键。
| 维度 | Skill | Custom Slash Command |
|---|---|---|
| 触发方式 | Claude 自动判断（看到符合场景就加载） | 你主动敲命令 |
| 本质 | 给 Claude 的任务手册 | 给你的prompt 快捷键 |
| 存在形式 | SKILL.md + 相关文件 |
一个简短的 markdown |
| 负责"做什么决定"的是谁 | Claude | 你 |
最简单的类比：
- Skill = Claude 的工具箱（它自己决定啥时候拿工具）
- Custom command = 你的键盘宏（你按键就触发）
两者也可以配合——命令触发后 prompt 里引用 Skill，最佳实践。
我们建一个 /daily 命令——"今天开工自动列清单"。
全局命令（所有项目可用）：
mkdir -p ~/.claude/commands
项目命令（只在这个项目可用）：
mkdir -p .claude/commands
新手先用全局。
文件名 = 命令名。做一个 /daily 命令就建 daily.md：
open -e ~/.claude/commands/daily.md
（Windows：notepad %USERPROFILE%\.claude\commands\daily.md）
粘贴：
---
description: 今日开工清单——列出需要做的事、优先级、大概时间预算
---
现在帮我列今天的开工清单。按以下步骤：
1. 先跑 `!git log --since="24 hours ago" --oneline` 看我昨天做到哪了
2. 跑 `!ls ~/Desktop/` 看桌面上有没有未归档的文件
3. 基于上面两步，问我 2-3 个问题帮你搞清楚今日重点
4. 最后输出一份今日清单：
```markdown
# <日期> 清单
## 必须完成（P0）
- [ ] ...（30-60 分钟）
## 建议完成（P1）
- [ ] ...（15-30 分钟）
## 可以推迟（P2）
- [ ] ...原则：
- 每项带时间预算
- 不超过 5 项
- 严格按优先级排序
保存。
### 步骤 4：试一试
启动 Claude Code，在输入框敲：
/daily
**按回车**——命令里的内容会自动传给 Claude，它就开始执行。
**成功标志**：Claude 按步骤 1-4 做，最后出清单。
### 如果没识别
- 确认文件路径对：`~/.claude/commands/daily.md`
- 确认文件以 `.md` 结尾
- 重启一次 Claude Code（某些版本要重启才扫描新命令）
## 21.3 一个命令里能干什么
自定义命令**本质上是一段 prompt 模板**。里面可以：
### 能力 1：直接写文字提示词
```markdown
帮我把最后一条 commit 的变更摘要为 1 句话，用于 Slack 公告。
用 !command 让 Claude 跑命令（和 Ch 19 讲的一样）：
先跑 `!git status` 看当前状态，然后......读 @CLAUDE.md 和 @docs/release.md，按其中规则走下面步骤......命令支持占位符：
---
description: 给指定文件生成测试
---
为 `{{1}}` 生成一组单元测试。要求......使用时：
/gentests src/utils.py
{{1}} 会替换成 src/utils.py。
不同版本语法略有差异——打 /help 或官方文档看你这版具体语法。
用 meeting-notes Skill 整理我刚贴的会议记录，要求输出按 HR 格式。Claude 会自动加载你的 meeting-notes Skill + 接你的追加要求。
不是什么都该做成命令。值得做的信号：
- 你敲过这段 prompt 超过 5 次
- 组合了多个步骤（shell 命令 + @ 引用 + 说明）
- 团队里每个人都要用同一套流程（放项目级
.claude/commands/，进 git） - 为标准化工作流—— 比如
/ship保证每次发布都走同一流程
- 一次性 prompt——下次可能用不到
- 只写一两句话的提示词——直接敲比打命令名还快
- 参数变化很大的任务——每次都要改命令内容不如直接写 prompt
三个都是"让 Claude 行为可重用"的方式，分工如下：
| 维度 | CLAUDE.md | Skill | Custom Command |
|---|---|---|---|
| 触发 | 每次启动自动加载 | Claude 判断需要时加载 | 你主动敲 /xxx |
| 适合频率 | 每次对话都用得到 | 偶尔用，有标准流程 | 反复用同样 prompt |
| 内容本质 | 项目规则 + 上下文 | 任务手册 | Prompt 模板 |
| 典型例子 | "这个项目用 Python 3.11" | "做代码审查的完整流程" | "/daily 今日清单" |
| 维护频率 | 项目变化时改 | 流程优化时改 | 使用中发现需要调时改 |
用户：/daily
↓（Custom Command 展开成完整 prompt）
Claude：读 CLAUDE.md 知道项目背景
↓
Claude：识别出"需要生成清单"场景 → 加载 daily-planning Skill
↓
Claude：按 Skill 手册 + CLAUDE.md 规则 + Command 里的步骤执行
↓
输出：一份清单
三者各司其职，互不冲突。
- 自定义 Slash 命令 = 你主动敲的 prompt 快捷键
- 放在
~/.claude/commands/<名>.md（全局）或.claude/commands/<名>.md（项目） - 文件结构：frontmatter（description）+ 正文（prompt 模板，可带 ! shell / @ 引用 / {{参数}}）
- Skill vs Command：前者 Claude 自动调用、后者你主动触发
- 值得做的信号：敲过 5 次以上、组合多步骤、团队标准化
- 命令、Skill、CLAUDE.md 三者联合是最强组合
步骤：照 21.2 完整走一遍。改 prompt 内容适应你自己的工作习惯（例：不关心 git？就删掉那步；关心邮件？加一步 !mail 或提醒检查邮箱）。
成功标志：敲 /daily 能跑出一份对你真有用的今日清单。
步骤：
- 回顾过去一周你反复敲过的 prompt
- 选一个最频繁的（至少敲过 3 次）
- 做成一个命令——起个 3-7 字的名字（例
/email-reply、/review） - 试用一次，发现问题就改
成功标志：你有了第二个命令，真实减少敲字量。
写出你目前三层扩展的分工：
# 我的 Claude Code 扩展地图
## CLAUDE.md（当前项目每次都用）
- ...
## Skills（按需加载，我已安装的）
- ...
## Custom Commands（我自己的快捷键）
- /daily
- /...成功标志：看一眼这份地图，能说清楚每层分别干什么。
症状 A：敲 /daily 没反应或说"command not found"
- 原因：(a) 文件路径错了；(b) 文件名带空格 / 特殊字符；(c) 需要重启 Claude Code。
- 解决：重建文件确认路径；文件名只用英文小写 + 连字符；关掉 Claude Code 重开。
症状 B：命令展开了但 Claude 没按步骤做
- 原因：prompt 里的指令太软（"最好"、"可以"）。
- 解决：改成硬指令（"必须先跑 X"、"不得跳过步骤 Y"）。
症状 C：我想做带参数的命令但不会
- 原因：参数语法各版本略有不同。
- 解决：先跑
/help看你这版的参数语法；或先用无参数版本——prompt 里留一个 "..."，Claude 会追问你具体参数。
主线结束。下面支线讲"团队共享命令的最佳实践"。
🌿 【支线】—— 可选深入（学有余力再看）
这段讲什么：项目里放一组命令，所有人 pull 下来就能用。 什么时候回头读：团队有 3 人以上一起用 Claude Code 时。
团队命令进 git，每个人 clone 之后就有。
<项目根>/
├── .claude/
│ └── commands/
│ ├── ship.md # /ship: 发版流程
│ ├── review.md # /review: 代码审查
│ └── daily.md # /daily: 每日早会前汇总
├── CLAUDE.md
└── src/...
例：/ship — 发布流程
---
description: 标准发布流程——保证每次发版都走同一套步骤
---
按以下步骤走：
1. 跑 `!git status` 确认无未提交
2. 跑 `!npm test` 全绿
3. 跑 `!npm run build` 成功
4. 生成 CHANGELOG 更新
5. 创建 tag
6. 推到远程
7. 发布到 npm
每步等我确认再进下一步。价值：防止人手忘步骤——Claude 按清单推进。
例：/review — 代码审查启动
---
description: 审查当前改动（基于 main 分支对比）
---
对比 main 分支，审查当前所有改动：
1. 跑 `!git diff main`
2. 按这 5 个维度评估：
- 逻辑正确性
- 测试覆盖
- 边缘情况
- 命名和可读性
- 潜在性能问题
3. 输出报告例：/release-notes — 生成发版说明
---
description: 把上次 tag 到现在的改动生成 release notes
---
1. 跑 `!git log <上次tag>..HEAD`
2. 按以下格式生成：
- ...
- ...
- ...（如有）
3. 语言统一、用户视角、不要技术细节
- 命名一致：
/review,/ship,/release-notes这种动作化命名 - 每个命令有 description——队友看
/help能知道命令干啥 - 命令内容写在 markdown——便于 PR review
- 大改走 PR：改命令 = 改流程，要经过讨论
- 个人命令（
~/.claude/commands/）：你的私人快捷键（/daily这种关你自己事） - 团队命令（
.claude/commands/）：团队共同工作流（/ship/review这种影响多人）
分清楚——个人的别混进 git。
下一章：第 22 章"Subagents 入门"——让 Claude 派出"专业实习生"去干活。Skill 是手册、Command 是快捷键、Subagent 是有特定岗位的 Claude。下一章讲它和前面两者的本质区别。