内容来源：Kelvin Mai。https://kelvinmai.io/blog/custom-claude-code-slash-commands
原题：Building Custom Slash Commands in Claude Code
原发布时间：2026-03-09
使用代码审查插件作为完整示例，实战构建 Claude Code 自定义斜杠命令，涵盖分支分析、Markdown 报告和反馈实施工作流。
兼容性与准确性说明（核对日期：2026-07-20）：原文使用旧版
.claude/commands/路径，该路径仍然受支持，不过当前 Claude Code 命令文档建议新的可复用工作流使用 Skills。allowed-tools会预先批准列出的工具，无需提示；它不会把命令限制在这些工具中。自定义/code-review会遮蔽 Claude Code 的同名内置 Skill。可以在一条消息中点名多项 Skills，但这并非 Shell 管道，也不能保证前一项的输出会成为后一项的输入；参见斜杠命令参考。最后，示例中的独立命令文件只是自定义配置，不是按照当前插件格式封装的插件。下文完整保留来源正文。
路径注意：原文多次把报告写入绝对路径
/dev/...，并称/dev是位于本地且被 Git 忽略的目录。在 Unix 中，/dev是操作系统设备目录，并不位于仓库中。应改用仓库相对路径dev/、.dev/或其他被 Git 忽略的项目目录。下文仍按原样保留/dev示例。
我已经使用 Claude Code 作为日常主力工具一段时间了，其中最被低估的功能之一，就是可以定义自己的斜杠命令。这些命令不只是快捷入口，而是完整的多步骤智能体工作流：理解你的项目、运行 Shell 命令、读取文件并写出结果，只需输入 /code-review 之类的内容即可触发。
本文将从零开始构建一个代码审查插件。完成后，你会拥有两条命令：/code-review 读取分支 Diff、查找问题并把报告写入磁盘；/implement-feedback 读取这份报告并真正修复问题。
自定义斜杠命令如何工作
Claude Code 会在两个位置查找斜杠命令：
• 项目级：仓库根目录中的 .claude/commands/（提交到 Git，与团队共享）
• 全局：~/.claude/commands/（可以用于所有项目的个人命令）
每条命令都是一个 Markdown 文件。文件名就是命令名，因此，.claude/commands/code-review.md 会注册 /code-review。文件内容是调用时 Claude 收到的提示词，而 $ARGUMENTS 则是命令名后所有输入的占位符。
命令还支持用于元数据的 YAML Frontmatter：
---
description: 命令列表中显示的简短说明
argument-hint: [自动补全中显示的可选提示]
allowed-tools: [Bash, Read, Write, Edit, Glob]
---
原文称，allowed-tools 字段会限制命令能使用的工具。这对于希望保持只读的命令，或者与团队共享并希望严格限定范围的命令很有用。
构建 /code-review
创建 .claude/commands/code-review.md：
---
description: 审查当前分支的变更，并把报告写入 /dev
allowed-tools: [Bash, Read, Write, Glob]
---
# 代码审查
对照 main 审查当前分支上的变更。
## 步骤
1. 运行 `git rev-parse --abbrev-ref HEAD` 获取当前分支名称
2. 运行 `git log origin/main..HEAD --oneline` 列出这个分支中的提交
3. 运行 `git diff origin/main..HEAD` 获取完整 Diff
4. 分析变更，查找：
- 逻辑错误或 Bug
- 安全隐患（注入、身份验证缺口、密钥泄漏）
- 系统边界上缺失的错误处理
- 性能问题（N+1 查询、不必要的重复渲染、阻塞调用）
- 与现有代码库风格不一致的地方
5. 使用下方结构，把详细报告写入 `/dev/code-review-{branch-name}.md`
6. 对发现的每个问题，另写一节专业、建设性的 PR 审查评论，
可以直接粘贴到 GitHub
## 报告结构
输出文件使用以下结构：
```markdown
# 代码审查：{branch-name}
## 摘要
简短的整体评价。
## 发现的问题
### 严重
• ……<br>
### 警告
• ……<br>
### 建议
• ……<br>
## PR 审查评论
针对每个问题编写专业、可直接复制粘贴的评论，语气如同
在 GitHub 上进行审查。表述直接，但要有建设性。
```
现在，当我在仓库中运行 /code-review 时，Claude 会：
1、调用 Git Shell 命令获取分支名称与完整 Diff
2、按需读取已变更文件，以掌握完整上下文
3、把结构化 Markdown 文件写入 /dev/code-review-{branch}.md
原文称，/dev 目录很适合这项用途：它位于本地、不提交，而且容易找到。作者将其加入 .gitignore，让报告留在自己的机器上。
PR 评论智能体
PR 审查评论章节才是这套方案真正有用的地方。我要求它像在 GitHub 上进行审查一样编写评论，而输出效果出乎意料地好：它会指出准确的行上下文、解释问题，并以不居高临下的语气建议修复方案。
下面是一条针对缺失 Null 检查生成的评论：
## PR 审查评论
**`src/lib/utils/parse.ts`——`parseConfig` 函数**
`JSON.parse()` 的返回值类型为 `any`，随后未经验证就立即展开。
如果配置文件包含意外字段，或者解析静默失败，格式错误的状态就会
传播到应用其余部分。
建议在展开之前使用 Zod 或手动守卫进行验证：
```ts
const raw = JSON.parse(content);
if (!isValidConfig(raw)) throw new Error('Invalid config shape');
```
粘贴，完成。它无法取代真正的代码审查，却可以成为扎实的第一轮检查——尤其适合在创建 PR 之前审查自己的工作，需要一个全新视角时使用。
构建 /implement-feedback
报告生成后，我还需要第二条命令读取报告并开始修复。创建 .claude/commands/implement-feedback.md：
---
description: 根据 /dev 中最新的代码审查报告实施修复
allowed-tools: [Bash, Read, Write, Edit, Glob]
---
# 实施反馈
读取最近的代码审查报告，并实施其中建议的修复。
## 步骤
1. 使用 Glob 查找所有匹配 `/dev/code-review-*.md` 的文件
2. 按修改时间排序，并读取最新文件
3. 首先处理**严重**问题，然后处理**警告**
4. 对每个问题：
- 读取相关文件，理解完整上下文
- 应用修复
- 继续下一个问题——除非变更具有破坏性或存在歧义，否则不要在每次修复之间请求确认
5. 跳过**建议**章节，除非 $ARGUMENTS 包含 "all"
6. 完成后汇总所作变更
## 说明
- 优先进行最小化、有针对性的编辑——只修复问题，不要重构周围代码
- 如果问题不清楚，或者修复需要大规模结构变更，则留下 TODO 注释，
并在摘要中说明
运行 /implement-feedback 后，它会找到最新报告，处理其中的严重问题和警告，再汇总所作变更。运行 /implement-feedback all 则还会处理建议章节。
编写优质命令的建议
下面是我在构建这些命令时学到的几点：
明确输出格式。 要求的结构越具体，输出就越稳定，也越容易解析。“写一份报告”这样的模糊指令，只会产生模糊报告。
使用 $ARGUMENTS 提供变化。 它只是简单的字符串替换，却能提供很大灵活性。我用它传递 all 之类的标志、覆盖分支名称，或者传入指定文件路径。
严格控制 allowed-tools。 如果命令只需要读取，就不要给予写权限。这样运行更安全，行为也更容易理解。
项目级与全局。 项目专用命令（例如了解 /dev 目录约定的命令）应放在 .claude/commands/；希望在所有地方使用的命令（例如通用提交消息助手）则放在 ~/.claude/commands/。
手动串联命令。 没有内置命令管道，但可以依次运行 /code-review 和 /implement-feedback。共享的 /dev 目录就是两者之间的交接点。
总结
自定义斜杠命令能把 Claude Code 从通用助手变成适应真实工作流的工具。本文的代码审查示例可能只花了 20 分钟配置，此后几乎每次创建 PR 之前，我都会使用。
这个模式的泛化能力很强——凡是可以描述为“读取一些上下文，进行一些推理，再写出一些结果”的事情，都很适合做成斜杠命令。数据库迁移审查、生成 Changelog、依赖审计报告——掌握模式之后，构建这些命令都很快。
