Claude Code 斜杠命令（Slash Commands）使用入门

Claude Code ，我发现这个功能比 cursor 还香

写在前面

最近在使用 Claude Code，同事们问得最多的就是："跟 cursor比起来怎么样？"

老实说，刚开始我也觉得就那样。但用了几天后，有个功能让我彻底改变了想法 ------ 斜杠命令（Slash Commands）。

先说个真实场景：我们项目有个复杂的代码规范，每次 Code Review 都要检查一堆东西。以前我得这样跟 AI 说：

帮我检查这个文件：
1. 组件命名是否符合 PascalCase
2. 是否用了团队约定的 hooks
3. 错误处理是否完整
4. 类型定义是否准确
5. 性能优化点...
巴拉巴拉一大堆

现在？一个 /review src/Button.tsx 搞定。

这就是斜杠命令的魅力 ------ 把你的工作习惯「程序化」。

斜杠命令到底是啥？

简单说，就是把你经常用的那些复杂提示词，保存成文件，然后用 /命令名 快速调用。

比如我经常需要写单元测试，每次都要解释我们用的是 Jest + Testing Library，组件在 src/components，工具函数在 src/utils...

现在直接 /test UserCard.tsx，AI 就知道要：

• 用我们的测试套件
• 遵循我们的文件结构
• 按我们的规范写测试用例

这种感觉就像是，你终于有了个真正懂你项目的助手。

先看看内置的命令

Claude Code 本身就带了几个实用命令：

• /add-dir - 把某个目录加到对话上下文
• /agents - 调用专门的 AI 助手
• /bug - 报告问题
• /clear - 清空聊天记录
• /config - 改配置

这些基本够日常用了，但真正的威力在自定义命令。

两种命令范围

项目级命令 (.claude/commands/)

放在项目根目录，只在这个项目里能用。适合放项目特有的东西，比如：

• 我们团队的代码规范检查
• 这个项目的部署脚本生成
• 特定框架的模板（比如我们用的是 Next.js + Prisma）

全局命令 (~/.claude/commands/)

放在用户目录，所有项目都能用。我一般放通用的东西：

• 通用的代码 review 模板
• 常用的文档格式
• 我个人的编码习惯

这样设计挺合理的，团队的东西跟着项目走，个人习惯全局复用。

动手写个命令

文件结构很简单

每个命令就是一个 .md 文件，基本格式：

---
description: "做什么的"
argument-hint: "需要什么参数"  
allowed-tools: ["Read", "Edit"]
---

这里写具体的提示词，用 $ARGUMENTS 代表传入的参数

用法就是：/命令名 参数

前面那些配置的意思

字段	干啥的	举例
description	命令描述，打 / 时会提示	"检查代码规范"
argument-hint	参数提示	"文件名或目录"
allowed-tools	能用哪些工具	["Read", "Grep"]
model	用哪个模型	"sonnet-4"

这些都是可选的，但建议都写上，特别是 description。

几个实用技巧

1. 用 $ARGUMENTS 传参数

这个很好理解，就是占位符。比如我写了个生成 README 的命令：

---
description: "为项目生成 README"
argument-hint: "项目类型，比如 react, vue, node"
---

为这个 $ARGUMENTS 项目写个 README，包括：
- 项目介绍
- 安装方法
- 使用例子
- 贡献指南

要专业点，但别太正式，像给朋友介绍项目那样。

然后 /readme react 就能生成 React 项目的 README 模板。

2. 用 ! 执行命令

这个厉害了，可以先跑个 shell 命令，再让 AI 分析结果。

我有个检查测试覆盖率的命令：

---
description: "检查测试覆盖率"
---

!npm test -- --coverage

看看测试覆盖率怎么样，哪里还没测到，给点建议。
不用太严格，重要的业务逻辑覆盖到就行。

这样 AI 会先跑测试，然后分析报告给建议。比我手动截图发给 AI 方便多了。

3. 用 @ 读取文件

这个是我最爱的功能。以前要让 AI 看代码，得复制粘贴，现在直接：

---
description: "代码 review"
argument-hint: "文件路径"
---

帮我看看这个文件有啥问题：

@$ARGUMENTS

重点关注：
- 有没有明显的 bug
- 性能能不能优化
- 代码写得够不够清楚

别太吹毛求疵，主要问题指出来就行。

用法：/review src/hooks/useAuth.js，AI 就会自动读取文件内容分析。

4. 触发深度思考

有时候你希望 AI 想得更仔细点，可以在提示词里加上 "仔细想想"、"分析一下"、"规划一下" 这类词：

---
description: "新功能技术方案"
argument-hint: "功能描述"
---

仔细分析一下这个功能的技术方案：$ARGUMENTS

考虑这些方面：
- 数据库要改哪些表
- 需要新增哪些 API
- 前端页面怎么组织
- 可能有什么坑
- 大概要几天

给个靠谱的方案，别太理想化。

这样 AI 会更认真地思考，给出更全面的分析。

用目录整理命令

命令多了之后，可以按类别放到不同文件夹：

.claude/commands/
├── git/
│   ├── commit.md      # 智能提交信息
│   └── pr.md          # PR 描述生成
├── test/
│   ├── unit.md        # 单元测试
│   └── e2e.md         # E2E 测试
├── docs/
│   ├── api.md         # API 文档
│   └── readme.md      # README 生成
└── deploy/
    └── staging.md     # 预发布检查

然后用 /git/commit、/test/unit 这样调用。

我们团队现在有 30 多个命令，分类整理后找起来方便多了。

MCP 命令（高级玩法）

MCP 是个协议，可以让外部服务提供命令。格式是：

/mcp__服务名__命令名 参数

比如你接了个数据库服务，就能直接：

/mcp__database__query SELECT * FROM users LIMIT 10

这个功能还比较新，我还在摸索。不过想象空间很大，比如接个 Slack 服务，就能直接在 Claude Code 里发消息。

几个我常用的命令

代码 Review 命令

这是我用得最多的，结合了我们团队的规范：

---
description: "团队代码 review"
argument-hint: "文件路径"
allowed-tools: ["Read", "Bash"]
---

!git diff --name-only HEAD~1

Review 这个文件：$ARGUMENTS

按我们团队标准检查：
- 变量命名是不是清楚（别用 a、b、c 这种）
- 函数是不是太长了（超过 50 行要考虑拆分）
- 有没有处理错误情况
- TypeScript 类型定义对不对
- 有没有潜在的性能问题

@$ARGUMENTS

别太严格，重点问题指出来就行。实在有问题的地方给个修改建议。

这个命令会先看看最近改了哪些文件，然后针对具体文件做 review。

API 文档生成器

写文档是程序员的痛，这个命令能减轻不少负担：

---
description: "生成 API 文档"
argument-hint: "API 文件路径"
---

帮我为这个 API 文件写文档：$ARGUMENTS

格式要求：
- 每个接口写清楚干什么的
- 请求参数要有类型说明
- 响应格式要有例子
- 重要的错误码要说明

文档风格要友好点，像给同事写的，不要太正式。

@$ARGUMENTS

数据库迁移助手

这个是我们后端同学最爱的：

---
description: "创建数据库迁移"
argument-hint: "要做什么变更"
allowed-tools: ["Bash", "Read"]
---

!ls migrations/ | tail -3

为这个变更写个数据库迁移：$ARGUMENTS

参考现有的迁移文件格式，包括：
- UP 迁移（怎么改）
- DOWN 迁移（怎么回滚）
- 该加的索引别忘了
- 数据类型选择要合理

生成的 SQL 要能多次执行不出错。

这个命令会先看看现有的迁移文件是什么样的，然后生成符合我们项目风格的迁移脚本。

一些使用心得

1. 命名要直观

命令名要让人一看就知道干什么的。

✅ 好的命名：

• /review-security - 安全检查
• /test-unit - 单元测试
• /docs-api - API 文档

❌ 不好的命名：

• /cmd1 - 谁知道干啥的
• /helper - 太模糊了
• /stuff - 更不知道了

2. 描述写清楚点

别偷懒，description 和 argument-hint 都写上。你写命令的时候觉得很清楚，过两个月就忘了。

3. 善用文件引用

@ 这个功能真的很强大，能让 AI 看到完整的代码上下文。比复制粘贴方便多了。

4. 别什么都自动化

有些简单的东西就别写命令了，比如单纯的 git status。命令适合那些需要上下文和复杂逻辑的场景。

5. 定期清理

命令多了容易乱，过段时间清理下不用的，整理下分类。

6. 团队共享要注意

项目级命令放到 Git 里，但个人习惯的就别强加给别人了。

遇到问题怎么办

命令找不到

• 检查文件是不是放对地方了（.claude/commands/ 或 ~/.claude/commands/）
• 文件名要以 .md 结尾
• 命令名要和文件名一致

参数没用上

• 确认用的是 $ARGUMENTS，不是其他写法
• 检查 argument-hint 是不是写得太模糊

执行命令出错

• 先在终端里单独试试那个命令能不能跑
• 检查文件权限
• 复杂的命令用绝对路径

调试技巧：在命令里加上 !echo "当前目录: $(pwd)" 看看执行环境。

总结

用了半年 Claude Code 的斜杠命令，真的改变了我的工作方式。以前跟 AI 对话像在教小学生，现在感觉有了个懂行的同事。

最大的好处是：

• 省时间 - 不用重复解释背景
• 更一致 - 团队用同样的标准
• 能积累 - 好的实践固化下来
• 少出错 - 自动化减少手工操作

建议从简单的开始，比如代码 review 或文档生成。用着用着你就会发现更多可能性。

现在我们团队基本人手几十个自定义命令，新人入职第一天就能用上团队积累的最佳实践。这种感觉，真的比单纯的代码补全强太多了。

如果你还没试过 Claude Code 的斜杠命令，真的建议试试。可能会让你重新认识 AI 辅助编程这件事。

---

写这篇文章的时候，我也用了好几个自定义命令来检查语法和优化表达。真香。