Claude Code 斜杠命令：内置命令与自定义命令

核验日期：2026-07-24

内容来源：Skills Playground。本文来自 Claude Code 中文译文归档，先作为 Claude Code 专区后台草稿入库；发布前需由内容人员复核原文链接、图片、版本时效、是否包含厂商宣传，以及是否需要补充本站实践说明。来源：https://skillsplayground.com/guides/claude-code-slash-commands/
原题：Claude Code Slash Commands: Built-In and Custom Commands

Claude Code 内置命令与自定义命令工作流指南，涵盖 TDD、组件生成、调试以及团队命令管理。

作者：Skills Playground（页面未显示个人署名）
更新日期：2026-02
阅读时间：10 分钟
来源：https://skillsplayground.com/guides/claude-code-slash-commands/

准确性说明（核对日期：2026-07-19）：下文原样保留了来源示例，但 .claude/skills/review.md、扁平 .md Skill 文件以及 command: 字段与当前文档规定的布局不符。当前 Claude Code 文档使用 .claude/skills/<skill-name>/SKILL.md，并以目录名决定斜杠命令名称。参见当前 Skills 文档。

来源立场说明：本指南在结尾附近推广了 Skills Playground；归档时保留了这项行动号召及相关阅读链接。

斜杠命令既是与 Claude Code 功能交互的方式，也是调用自定义工作流的入口。在 Claude Code CLI 中输入 /，就会看到可用命令列表。其中一部分内置于 Claude Code，另一部分则是由你以 Skills 形式定义的自定义命令。

本指南将介绍所有内置命令，并演示如何为自己的工作流创建强大的自定义命令。

内置命令

这些命令始终可以在 Claude Code 中使用，用于控制会话、管理上下文和访问核心功能。

会话管理

命令	说明
`/help`	显示可用命令和用法信息
`/clear`	清空对话历史，从头开始。适合上下文变得杂乱或者需要切换任务时使用。
`/compact`	总结并压缩对话，释放上下文窗口。Claude 会提炼关键内容，然后使用更短的历史继续工作。
`/quit`	退出 Claude Code 会话。

工作流命令

命令	说明
`/plan`	切换到规划模式。Claude 会先说明方法，再进行修改。适合希望先审查策略的复杂任务。
`/commit`	要求 Claude 根据已暂存或最近的变更创建 Git 提交，并自动生成提交消息。
`/review`	对最近的变更或指定文件触发代码审查。（在很多配置中以内置 Skill 提供。）
`/fast`	切换快速模式，使用同一模型更快地输出。适合速度比深度更重要的简单任务。

上下文命令

命令	说明
`/add-dir <path>`	把目录加入 Claude 的工作上下文。适合需要 Claude 访问当前项目根目录之外的文件时使用。
`/config`	查看或修改当前会话的 Claude Code 配置。
`/memory`	查看或编辑 Claude 的持久记忆——会在当前项目的不同对话之间保留的笔记。

在 / 后输入几个字符即可筛选命令。Claude Code 的自动补全会在输入时显示匹配的内置命令和自定义命令。

自定义斜杠命令（Skills）

自定义命令才是斜杠命令真正强大的地方。原文将其描述为存放在 .claude/skills/ 中的 Markdown 文件，用于定义可通过斜杠命令调用的可复用提示词。输入命令后，Claude 会加载 Skill 指令并照其执行。

创建第一条自定义命令

在 .claude/skills/review.md 创建文件：

---
name: 安全审查
description: 审查代码中的安全漏洞
command: /security-review
---

# 代码安全审查

审查给出的代码，查找安全漏洞。
重点检查 OWASP 十大风险：
1. 注入（SQL、NoSQL、操作系统命令、LDAP）
2. 身份验证失效
3. 敏感数据泄露
4. XML 外部实体（XXE）
5. 访问控制失效
6. 安全配置错误
7. 跨站脚本（XSS）
8. 不安全的反序列化
9. 使用包含已知漏洞的组件
10. 日志记录和监控不足

对每项发现给出：
- **严重程度**：严重 / 高 / 中 / 低
- **位置**：文件和行号
- **问题**：漏洞是什么
- **修复**：具体代码修复方案或建议

现在输入 /security-review apps/api/src/routes/auth.ts，就会对该文件运行聚焦的安全审计。

YAML Frontmatter

每个 Skill 文件顶部的 Frontmatter 用于定义元数据：

---
name: 命令列表中显示的易读名称
description: 自动补全中显示的简短说明
command: /your-command-name
---

• name——显示在 Skill 列表与自动补全中
• description——作为副标题显示在自动补全提示中
• command——触发这项 Skill 的斜杠命令（必须以 / 开头）

编写 Skill 内容的最佳实践

• 使用指令语气，不要使用对话语气。 Skills 是指令，不是对话。使用祈使动词：“审查代码”“编写测试”“创建迁移”。
• 明确输出格式。 准确告诉 Claude 如何组织回答，例如项目符号、表格和代码块。
• 加入示例。 展示优秀输出是什么样的。Claude 会紧密模仿示例。
• 让 Skills 保持聚焦。 每项 Skill 对应一套工作流。“包办一切”的 Skill 不如三项聚焦的 Skills 有效。

自定义命令示例

/tdd——测试驱动开发

---
name: TDD 工作流
description: 严格的测试驱动开发循环
command: /tdd
---

每项变更都要遵循严格 TDD：

1. 首先编写一个失败的测试。运行并确认它确实失败。
2. 编写让测试通过所需的最少代码。
3. 运行测试，确认它已经通过。
4. 必要时重构，再次运行测试。

规则：
- 没有失败测试，绝不编写生产代码
- 每个测试只验证一种行为
- 使用描述性测试名称：“当[条件]成立时，应该[行为]”
- 保持紧凑的红—绿—重构循环

/component——React 组件生成器

---
name: React 组件
description: 创建带测试的新 React 组件
command: /component
---

按照项目约定创建新的 React 组件：

1. 组件文件：src/components/{Name}/{Name}.tsx
   - 使用 TypeScript 函数组件
   - Props 接口命名为 {Name}Props
   - 使用具名导出

2. 测试文件：src/components/{Name}/{Name}.test.tsx
   - 使用 React Testing Library
   - 测试渲染、交互和边界情况

3. Barrel 索引：src/components/{Name}/index.ts
   - 重新导出组件

4. 样式：src/components/{Name}/{Name}.module.css
   - CSS Modules，采用受 BEM 启发的命名方式

/debug——系统化调试

---
name: 调试
description: 系统化调试工作流
command: /debug
---

采用系统化调试方法：

1. 复现：理解并复现问题
   - 预期行为是什么？
   - 实际行为是什么？
   - 复现步骤是什么？

2. 隔离：缩小原因范围
   - 检查最近的变更（git log、git diff）
   - 添加日志或断点以追踪执行
   - 对代码路径进行二分查找

3. 识别：找到根本原因
   - 不要修补症状，要找到根本问题
   - 不只说明 Bug 在哪里，还要解释它为什么存在

4. 修复：进行有针对性的修复
   - 以最小改动修复根本原因
   - 不要重构无关代码

5. 验证：确认修复有效
   - 编写一个原本就能捕捉该 Bug 的测试
   - 运行完整测试套件
   - 手动验证最初的复现步骤

为团队组织命令

对于团队，应在仓库的 .claude/skills/ 目录中维护一套经过筛选的命令。典型配置如下：

.claude/
  skills/
    review.md           # /review - 代码审查
    tdd.md              # /tdd - 测试驱动开发
    api-endpoint.md     # /api - 新 API 端点骨架
    db-migrate.md       # /migrate - 数据库迁移工作流
    deploy-checklist.md # /deploy - 部署前检查清单
    debug.md            # /debug - 系统化调试

把这些文件提交到仓库。每位团队成员都会获得相同命令，而且这些命令会与代码库共同演进。有人发现了更好的工作流，只需更新 Skill 文件，所有人都能受益。

自定义命令与内置命令

一个常见问题是：如果自定义命令与内置命令同名，会发生什么？原文称，内置命令优先。如果定义了 command: /clear 的 Skill，运行的仍然是内置 /clear。因此，应为 Skills 选择独一无二的命令名称。

想在加入项目之前测试自定义命令？可以使用 Skills Playground 以交互方式尝试 Skill 提示词，查看 Claude 的响应，再决定是否提交到仓库。

编写有效命令的建议

• 使用描述性名称。 /security-review 优于 /sr，因为你会忘记缩写的含义。
• 在 CLAUDE.md 中列出命令。 添加一个章节，列出可用的自定义命令，让 Claude 和团队知道有哪些能力。
• 对 Skills 进行版本控制。 Skills 位于 Git 仓库中，因此会自动受到版本控制。使用 PR 审查团队 Skills 的变更。
• 与 Hooks 结合以强制执行。 Skill 告诉 Claude 做什么，Hook 则确保它真正发生。
• 把 Skills 控制在 500 字以内。 更长的 Skills 会消耗上下文窗口。内容要精确，并使用指令语气。