【Claude】Claude Code 自定义斜杠命令完全指南：把重复提示词变成一键命令

【Claude】Claude Code 自定义斜杠命令完全指南：把重复提示词变成一键命令

前言

每天用 Claude Code 写代码，你有没有发现自己在不停重复同样的咒语？

• 每次做代码审查，都要输入："请审查这段代码，检查安全漏洞、性能问题、代码风格..."
• 每次提交代码，都要输入："帮我生成一个规范的 commit message，格式为 type(scope): description..."
• 每次开始新功能，都要输入："请遵循我们的 Service-Repository 模式，先分析需求，然后..."

这些重复的操作不仅浪费时间，还因为每次措辞不完全一样导致 Claude 的响应质量参差不齐。

自定义斜杠命令（Custom Slash Commands）就是解决这个问题的官方工具。你只需要写一个 Markdown 文件，就能把任何复杂提示词变成一个简短命令。

本文从零开始，教你打造一套生产级的自定义命令库。

一、问题现象：重复工作的痛苦

1.1 没有自定义命令的日常

场景：代码审查

每次需要输入 150+ 字的提示词： "请对上面的代码进行全面审查，重点关注： 1. 安全漏洞（SQL注入、XSS、未授权访问等） 2. 性能问题（N+1查询、内存泄漏、不必要的循环） 3. 错误处理（是否覆盖了所有异常场景） 4. 代码可读性（命名、注释、复杂度） 5. 测试覆盖（是否需要补充测试） 输出格式：按严重程度分类，每个问题给出具体行号和修改建议"

场景：生成 Commit Message

"根据上面的代码变更，生成一个符合 Conventional Commits 规范的 commit message， 格式：type(scope): description 类型：feat/fix/docs/style/refactor/test/chore 简洁描述不超过 72 字符，如有必要附加 body 说明"

问题：

• 每次都要重新输入或粘贴，效率低
• 措辞不一致导致输出质量不稳定
• 无法在团队间共享标准化的提示词

1.2 有了自定义命令后

/review # 一键触发标准化代码审查 /commit # 一键生成规范 commit message /new-feature # 一键启动新功能开发流程 /debug # 一键启动调试模式

二、核心概念：自定义命令的工作原理

2.1 什么是自定义命令

自定义命令就是存储在特定目录的 Markdown 文件，文件名即命令名，文件内容即提示词模板。

文件路径：.claude/commands/review.md 调用方式：/review 效果：Claude 读取 review.md 的内容作为提示词执行

2.2 命令发现机制

Claude Code 会自动扫描以下目录：

两个目录的命令可以共存，项目级优先级更高（同名命令以项目级为准）。

2.3 参数传递：$ARGUMENTS 占位符

命令文件中可以用$ARGUMENTS接收调用时传入的参数：

<!-- .claude/commands/explain.md --> 请详细解释以下概念，面向初级开发者，用具体例子说明： $ARGUMENTS

调用：

/explain 什么是依赖注入 /explain React 的 useEffect 依赖数组

$ARGUMENTS会被替换为命令后面的所有文字。

三、第一个命令：Hello World

3.1 创建目录和文件

mkdir -p .claude/commands touch .claude/commands/hello.md

3.2 编写命令内容

<!-- .claude/commands/hello.md --> 你好！请用中文做一个简短的自我介绍，说明你是 Claude Code，以及你当前正在处理的项目（根据 CLAUDE.md 和当前目录判断）。 格式： 1. AI 简介（1句话） 2. 当前项目（1句话） 3. 今天能帮我做什么（3个建议）

3.3 验证命令可用

# 在 Claude Code 中 claude # 输入 /hello

如果正常工作，你会看到 Claude 按照模板生成回复。

注意：新创建的命令文件不需要重启 Claude Code，输入/时会自动列出所有可用命令。

四、10个生产级命令模板

命令 1：/review — 代码审查

<!-- .claude/commands/review.md --> 对以下代码（或上下文中最近修改的代码）进行全面审查。 ## 审查维度 ### 🔒 安全性（优先级：高） - SQL 注入、XSS、CSRF 漏洞 - 未授权访问、越权操作 - 敏感信息泄露（密钥、密码在日志/响应中） - 输入验证是否完整 ### ⚡ 性能（优先级：中） - N+1 查询问题 - 不必要的循环或重复计算 - 内存泄漏风险 - 大数据量处理是否有分页/流式处理 ### 🐛 正确性（优先级：高） - 边界条件处理（空值、空列表、极值） - 错误处理是否完整 - 并发安全问题 - 业务逻辑是否正确 ### 📖 可维护性（优先级：中） - 命名是否清晰 - 函数复杂度是否过高（建议 < 20 行） - 是否有重复代码需要提取 - 注释是否准确 ## 输出格式 按严重程度分类输出： **🚨 必须修复（P0）** - [文件:行号] 问题描述 → 修改建议 **⚠️ 建议修复（P1）** - [文件:行号] 问题描述 → 修改建议 **💡 可以优化（P2）** - [文件:行号] 问题描述 → 修改建议 如果代码质量良好，明确说明"本次审查未发现重大问题"。 $ARGUMENTS

命令 2：/commit — 生成 Commit Message

<!-- .claude/commands/commit.md --> 根据当前 git diff（或最近的代码变更），生成一个符合 Conventional Commits 规范的 commit message。 ## 规范要求 格式：`type(scope): description` 类型（type）： - feat：新功能 - fix：修复 bug - docs：文档更新 - style：格式调整（不影响功能） - refactor：重构（不是新功能也不是修 bug） - test：添加或修改测试 - chore：构建工具、依赖更新等 规则： - 标题行不超过 72 字符 - 使用祈使句，如 "add feature" 而不是 "added feature" - 如果变更复杂，附加 body 说明（空行分隔） - 如果关联 issue，添加 footer：`Closes #123` ## 输出 直接给出 commit message，不要解释，格式如下：

type(scope): description

[可选 body]

[可选 footer]

先运行 `git diff --staged` 查看当前暂存的变更，再生成 message。 如果没有暂存内容，运行 `git diff HEAD~1` 查看最近一次提交的变更。

命令 3：/test — 生成测试

<!-- .claude/commands/test.md --> 为以下代码（或 $ARGUMENTS 指定的函数/模块）生成完整的单元测试。 ## 测试要求 ### 覆盖场景 1. **正常路径**：典型输入，验证正确输出 2. **边界条件**：空值、空列表、最大值、最小值 3. **异常路径**：无效输入、权限不足、外部服务异常 4. **并发场景**（如果函数涉及状态修改） ### 测试质量 - 每个测试只验证一件事 - 测试名称格式：`test_[功能]_[输入条件]_[期望结果]` - 使用 Mock 隔离外部依赖（数据库、HTTP 请求、文件系统） - 确保测试可重复运行（不依赖外部状态） ### 技术栈适配 - Python：使用 pytest + pytest-mock，异步用 pytest-asyncio - TypeScript/JavaScript：使用 Jest/Vitest + @testing-library（前端） - Go：使用标准 testing 包 + testify ## 输出 先列出测试计划（要覆盖哪些场景），然后给出完整的测试代码。 $ARGUMENTS

命令 4：/debug — 系统化调试

<!-- .claude/commands/debug.md --> 帮我系统化地调试以下问题： $ARGUMENTS ## 调试流程 ### 第一步：理解问题 - 确认预期行为 vs 实际行为 - 收集错误信息（完整的错误消息、堆栈跟踪） - 确认复现步骤 ### 第二步：缩小范围 - 读取相关代码文件 - 识别最近的代码变更 - 检查环境变量和配置 ### 第三步：假设与验证 - 列出可能的根本原因（从最可能的开始） - 为每个假设提供验证方法 - 建议添加临时调试日志的位置 ### 第四步：修复方案 - 给出最可能的修复方案 - 解释为什么这样修复 - 说明潜在的副作用 如果需要更多信息，明确说明需要看哪些文件或执行哪些命令。

命令 5：/doc — 生成文档

<!-- .claude/commands/doc.md --> 为 $ARGUMENTS 生成完整的文档。 ## 文档类型判断 根据目标自动选择文档类型： - 函数/类 → API 文档（docstring 风格） - 模块/包 → README 风格文档 - 接口/端点 → OpenAPI/Swagger 描述 - 配置文件 → 配置说明文档 ## 文档内容要求 ### 函数/类文档

[简洁的功能描述，一句话]

参数： param1 (type): 说明，默认值（如有） param2 (type): 说明

返回： type: 说明（包括可能返回的特殊值）

异常： ExceptionType: 什么情况下抛出

示例：

[具体的调用示例] [输出结果]

注意： [重要的边界条件或使用注意事项]

### README 文档 包含：功能概述、快速开始、详细配置、常见问题 ## 输出要求 直接输出文档内容，可以直接插入代码中或保存为文件。

命令 6：/refactor — 代码重构

<!-- .claude/commands/refactor.md --> 重构以下代码（或 $ARGUMENTS 指定的模块），遵循以下原则： ## 重构原则 ### 保持行为不变 - 重构前后功能完全相同 - 如果有测试，重构后所有测试必须通过 - 如果没有测试，先写测试再重构 ### 重构目标（按优先级） 1. **提升可读性**：有意义的命名、清晰的逻辑流 2. **消除重复**：DRY 原则，提取公共逻辑 3. **降低复杂度**：拆分长函数，减少嵌套层级 4. **改善扩展性**：遵循开闭原则，便于未来修改 ### 不做的事 - 不改变公共 API（除非明确要求） - 不做性能优化（除非有明显的反模式） - 不引入新的第三方依赖 ## 输出格式 1. 先说明发现的问题（列表形式） 2. 给出重构后的完整代码 3. 说明主要变更点和理由 $ARGUMENTS

命令 7：/explain — 代码解释

<!-- .claude/commands/explain.md --> 请解释以下内容：$ARGUMENTS ## 解释要求 - **受众**：中级开发者（有编程基础，但对这个特定技术不熟悉） - **风格**：先给结论，再讲原理，最后举例 - **长度**：根据复杂度决定，不要过度解释简单概念 ## 结构 1. **一句话总结**：这是什么？用来干什么？ 2. **核心概念**：理解它需要知道的 2-3 个关键点 3. **代码示例**：一个最小可运行的示例（如果适用） 4. **常见误区**：新手容易犯的错误（如果有的话） 5. **延伸阅读**：如果想深入了解，应该看什么（书/文档/RFC） 如果解释的是一段代码，按行/块逐步解释，特别指出非显而易见的部分。

命令 8：/pr-desc — 生成 PR 描述

<!-- .claude/commands/pr-desc.md --> 根据当前分支与主分支的差异，生成一份规范的 Pull Request 描述。 先运行以下命令获取上下文： ```bash git log main..HEAD --oneline git diff main...HEAD --stat

PR 描述模板

📌 变更概述

[2-3句话描述这个PR做了什么，解决了什么问题]

🔄 主要变更

• [变更项1]
• [变更项2]
• ...

🧪 测试说明

• 单元测试（已添加/已更新/不适用，说明原因）
• 集成测试（已添加/已更新/不适用）
• 手动测试（描述测试场景）

📸 截图（UI变更时必填）

[截图或录屏]

⚠️ 注意事项

[需要审查者特别注意的地方、潜在风险、部署注意事项]

🔗 关联

• Closes #[issue号]
• 依赖 PR：#[PR号]（如有）

$ARGUMENTS

### 命令 9：/security — 安全审计 ```markdown <!-- .claude/commands/security.md --> 对当前项目（或 $ARGUMENTS 指定的模块）进行安全审计。 ## 审计清单 ### 输入验证 - [ ] 所有用户输入是否都有验证和清理 - [ ] SQL 查询是否使用参数化查询（防 SQL 注入） - [ ] 文件上传是否验证类型、大小、内容 - [ ] URL/路径参数是否防止路径遍历攻击 ### 认证与授权 - [ ] 所有需要认证的接口是否都有身份验证 - [ ] 权限检查是否在服务层而不仅在前端 - [ ] JWT/Session 过期时间是否合理 - [ ] 是否防止暴力破解（限流、账号锁定） ### 数据安全 - [ ] 密码是否使用强哈希（bcrypt/argon2，不是 MD5/SHA1） - [ ] 敏感数据是否在日志中被掩码 - [ ] HTTPS 是否全程启用 - [ ] 是否有 CORS 策略 ### 依赖安全 - 检查 package.json/requirements.txt 中是否有已知漏洞的依赖 - 建议运行：`npm audit` 或 `pip-audit` ## 输出格式 给出风险评级（高/中/低）和具体修复建议，优先处理高风险项。

命令 10：/changelog — 生成变更日志

<!-- .claude/commands/changelog.md --> 生成从 $ARGUMENTS（tag 或 commit hash）到 HEAD 的 CHANGELOG 条目。 ## 步骤 1. 运行 `git log [参数]..HEAD --oneline --no-merges` 获取提交列表 2. 按类型分类整理 3. 过滤掉纯内部变更（chore、style 等） ## 输出格式（Keep a Changelog 规范） ```markdown ## [版本号] - YYYY-MM-DD ### Added（新增） - 功能1描述 ### Changed（变更） - 功能2描述 ### Fixed（修复） - Bug1描述 ### Security（安全） - 安全修复描述

注意

• 描述面向最终用户，不要包含内部技术细节
• 合并相关的多个提交为一条描述
• 如果某类变更为空，该类别不输出

--- ## 五、命令文件高级技巧 ### 5.1 条件化输出 ```markdown <!-- .claude/commands/analyze.md --> 分析 $ARGUMENTS 如果没有提供参数（$ARGUMENTS 为空），则分析当前工作目录中最近修改的文件（运行 `git diff --name-only HEAD~1` 查看）。 如果提供了文件路径，则读取并分析该文件。 如果提供了函数名，则在代码库中搜索该函数并分析。

5.2 嵌入 Bash 命令

命令文件中可以指示 Claude 先执行命令收集信息：

<!-- .claude/commands/health.md --> 项目健康检查。请按顺序执行以下步骤： 1. 运行 `git status` 检查工作区状态 2. 运行测试命令并记录结果 3. 运行 lint 检查 4. 检查 package.json/requirements.txt 是否有过期依赖 最后给出健康评分（A/B/C/D）和改进建议。

5.3 多步骤工作流命令

<!-- .claude/commands/new-feature.md --> 开始开发新功能：$ARGUMENTS ## 步骤一：需求分析（不执行任何操作） 分析需求，识别： - 需要修改的文件（列表） - 需要新建的文件（列表） - 潜在风险和依赖 ## 步骤二：等待确认 展示分析结果，等待用户确认后再继续。 在继续前，询问："以上分析是否准确？可以开始实现吗？" ## 步骤三：实现（用户确认后） 按照约定的架构模式实现功能，包括： 1. 数据模型（如果需要） 2. Service 层逻辑 3. API 端点 4. 基础测试 ## 步骤四：完成确认 列出所有已创建/修改的文件，询问是否需要生成 commit message。

六、完整目录结构推荐

.claude/ ├── commands/ │ ├── review.md # /review 代码审查 │ ├── commit.md # /commit 生成提交信息 │ ├── test.md # /test 生成测试 │ ├── debug.md # /debug 系统调试 │ ├── doc.md # /doc 生成文档 │ ├── refactor.md # /refactor 代码重构 │ ├── explain.md # /explain 解释代码 │ ├── pr-desc.md # /pr-desc 生成PR描述 │ ├── security.md # /security 安全审计 │ ├── changelog.md # /changelog 生成变更日志 │ └── new-feature.md # /new-feature 新功能开发 ├── CLAUDE.md # 项目记忆 └── settings.json # 配置文件

七、常见问题

Q：命令不出现在自动补全列表里

解决：

1. 确认文件在正确目录：.claude/commands/或~/.claude/commands/
2. 文件扩展名必须是.md（不能是.txt或无扩展名）
3. 文件名不能含空格（用-或_替代）
4. 重启 Claude Code 会话，或输入/然后等待列表刷新

Q：$ARGUMENTS 没有被替换

解决：

• 确认是$ARGUMENTS（全大写，带$符号）
• 不是{ARGUMENTS}或[ARGUMENTS]
• 参数紧跟在命令后面，空格分隔：/explain 什么是闭包

Q：命令文件太长，效果变差

解决：

• 每个命令文件控制在 50-100 行以内
• 过于复杂的工作流拆分为多个命令
• 使用@文件路径引用详细规范，而不是全部内嵌

Q：如何在命令中引用其他文件

<!-- .claude/commands/review.md --> 请按照我们的代码审查规范（见 @docs/code-review-standards.md）审查以下代码： $ARGUMENTS

Q：项目级和全局命令同名时哪个生效

项目级（.claude/commands/）优先，会覆盖全局命令（~/.claude/commands/）。

八、最佳实践总结

1. 命令名要动词化：/review、/test、/debug而不是/review-tool、/testing

2. 一个命令做一件事：不要试图用一个命令覆盖所有场景

3. 明确输出格式：在命令文件中指定期望的输出结构，结果更稳定

4. 提供示例：在命令文件底部加一行注释说明典型用法

5. 定期迭代：把不好用的命令改掉，把常用的临时提示词提升为正式命令

6. 团队共享：把命令文件提交到 git，让团队所有人受益

总结

自定义斜杠命令是 Claude Code 效率倍增的核心工具。通过一个 Markdown 文件 = 一个命令的简单机制，你可以：

• 把几十次重复的长提示词变成几秒钟的命令调用
• 让团队共享标准化的 AI 工作流
• 通过$ARGUMENTS占位符实现灵活的参数化

从本文的 10 个模板开始，根据你自己的工作流添加更多命令——三个月后，你会拥有一套量身定制的 AI 命令库，让 Claude Code 真正成为你项目的专属 AI 助手。