【Claude】Claude Code 自定义斜杠命令完全指南把重复提示词变成一键命令前言每天用 Claude Code 写代码你有没有发现自己在不停重复同样的咒语每次做代码审查都要输入请审查这段代码检查安全漏洞、性能问题、代码风格...每次提交代码都要输入帮我生成一个规范的 commit message格式为 type(scope): description...每次开始新功能都要输入请遵循我们的 Service-Repository 模式先分析需求然后...这些重复的操作不仅浪费时间还因为每次措辞不完全一样导致 Claude 的响应质量参差不齐。自定义斜杠命令Custom Slash Commands就是解决这个问题的官方工具。你只需要写一个 Markdown 文件就能把任何复杂提示词变成一个简短命令。本文从零开始教你打造一套生产级的自定义命令库。一、问题现象重复工作的痛苦1.1 没有自定义命令的日常场景代码审查每次需要输入 150 字的提示词 请对上面的代码进行全面审查重点关注 1. 安全漏洞SQL注入、XSS、未授权访问等 2. 性能问题N1查询、内存泄漏、不必要的循环 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 会自动扫描以下目录路径作用域是否提交 git.claude/commands/项目级当前项目所有成员共享✅ 建议提交~/.claude/commands/全局级对所有项目生效❌ 个人私有两个目录的命令可以共存项目级优先级更高同名命令以项目级为准。2.3 参数传递$ARGUMENTS 占位符命令文件中可以用$ARGUMENTS接收调用时传入的参数!-- .claude/commands/explain.md -- 请详细解释以下概念面向初级开发者用具体例子说明 $ARGUMENTS调用/explain 什么是依赖注入 /explain React 的 useEffect 依赖数组$ARGUMENTS会被替换为命令后面的所有文字。三、第一个命令Hello World3.1 创建目录和文件mkdir -p .claude/commands touch .claude/commands/hello.md3.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 漏洞 - 未授权访问、越权操作 - 敏感信息泄露密钥、密码在日志/响应中 - 输入验证是否完整 ### ⚡ 性能优先级中 - N1 查询问题 - 不必要的循环或重复计算 - 内存泄漏风险 - 大数据量处理是否有分页/流式处理 ### 正确性优先级高 - 边界条件处理空值、空列表、极值 - 错误处理是否完整 - 并发安全问题 - 业务逻辑是否正确 ### 可维护性优先级中 - 命名是否清晰 - 函数复杂度是否过高建议 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添加 footerCloses #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 --statPR 描述模板 变更概述[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 -- 生成从 $ARGUMENTStag 或 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命令不出现在自动补全列表里解决确认文件在正确目录.claude/commands/或~/.claude/commands/文件扩展名必须是.md不能是.txt或无扩展名文件名不能含空格用-或_替代重启 Claude Code 会话或输入/然后等待列表刷新Q$ARGUMENTS 没有被替换解决确认是$ARGUMENTS全大写带$符号不是{ARGUMENTS}或[ARGUMENTS]参数紧跟在命令后面空格分隔/explain 什么是闭包Q命令文件太长效果变差解决每个命令文件控制在 50-100 行以内过于复杂的工作流拆分为多个命令使用文件路径引用详细规范而不是全部内嵌Q如何在命令中引用其他文件!-- .claude/commands/review.md -- 请按照我们的代码审查规范见 docs/code-review-standards.md审查以下代码 $ARGUMENTSQ项目级和全局命令同名时哪个生效项目级.claude/commands/优先会覆盖全局命令~/.claude/commands/。八、最佳实践总结命令名要动词化/review、/test、/debug而不是/review-tool、/testing一个命令做一件事不要试图用一个命令覆盖所有场景明确输出格式在命令文件中指定期望的输出结构结果更稳定提供示例在命令文件底部加一行注释说明典型用法定期迭代把不好用的命令改掉把常用的临时提示词提升为正式命令团队共享把命令文件提交到 git让团队所有人受益总结自定义斜杠命令是 Claude Code 效率倍增的核心工具。通过一个 Markdown 文件 一个命令的简单机制你可以把几十次重复的长提示词变成几秒钟的命令调用让团队共享标准化的 AI 工作流通过$ARGUMENTS占位符实现灵活的参数化从本文的 10 个模板开始根据你自己的工作流添加更多命令——三个月后你会拥有一套量身定制的 AI 命令库让 Claude Code 真正成为你项目的专属 AI 助手。