Claude Code 通关手册（四）：3 个自定义命令，让你的 Claude Code 快到飞起
这是「Claude Code 通关手册」系列的第 4 篇，共 10 篇。本篇是 Level 2（配置篇）的最后一篇。学完这篇，你的 Claude Code 配置就算"毕业"了。
我观察了一下自己每天用 Claude Code 的操作，发现了一个尴尬的事实——
我每天至少打三次这段话：
"帮我审查这个文件，重点关注 TypeScript 类型安全、Next.js 最佳实践、性能隐患和安全问题，给出具体的改进建议和修改后的代码。"
一次 50 个字，一天三次就是 150 个字。一周五天 750 个字。一个月 3000 个字。
你在用手指重复写一篇作文。
更要命的是，每次你还可能忘了某个检查项——上周审查的时候忘了加"安全问题"，导致一个 XSS 漏洞溜过去了。
解决方案简单到让人想拍大腿：把这段提示词做成一个命令，以后输入 /review 两个字就够了。
今天教你做三个命令——/review、/test、/doc——再配合正确的模型选择策略，你的 Claude Code 日常效率能再上一个台阶。
Slash 命令是什么？30 秒搞懂
打个比方：你手机上有没有设置"快捷指令"？比如对 Siri 说"打开工作模式"，它自动帮你静音+打开钉钉+关闭抖音。
Claude Code 的 Slash 命令就是同一个概念——你预先定义一段提示词模板，取个名字，以后输入 /名字 就自动展开执行。
技术上说：
- 文件位置：
.claude/commands/（项目级）或~/.claude/commands/（全局个人级） - 文件格式：Markdown 文件，文件名就是命令名
- 调用方式：在交互模式中输入
/命令名 参数 - 参数传递：文件里用
$ARGUMENTS接收命令后面的所有文字
就这么简单。一个 Markdown 文件 = 一个命令。没有代码要写，没有配置要学。
code┌──────────────────────────────────────────────────────────┐
│ Slash 命令工作原理 │
├──────────────────────────────────────────────────────────┤
│ │
│ 你创建的文件： │
│ .claude/commands/review.md │
│ │
│ 文件内容： │
│ "审查以下文件，关注类型安全和性能... $ARGUMENTS" │
│ │
│ 你输入： │
│ /review @src/components/ArticleCard.tsx │
│ │
│ Claude 实际收到的提示词： │
│ "审查以下文件，关注类型安全和性能... │
│ @src/components/ArticleCard.tsx" │
│ │
│ $ARGUMENTS 被替换为命令后面的所有文字 │
│ │
└──────────────────────────────────────────────────────────┘命令一：/review —— 代码审查（使用频率最高）
直接上手做。在 DevPulse 项目根目录下创建命令文件：
bashmkdir -p .claude/commands然后创建 .claude/commands/review.md：
markdown---
description: 审查代码质量，检查类型安全、性能、安全和规范
argument-hint: <文件或目录路径>
---
审查以下代码，按优先级从高到低关注这些方面：
## 审查清单
1. **TypeScript 类型安全**
- 是否存在 any 类型
- 类型断言（as）是否合理
- 函数参数和返回值是否有明确类型
2. **Next.js 14 最佳实践**
- Server/Client 组件划分是否正确
- 数据获取方式是否恰当（Server Component 内 fetch vs useEffect）
- 是否正确使用 next/image 和 next/link
3. **性能隐患**
- 是否有不必要的重渲染
- 列表渲染是否有稳定 key
- 是否缺少 React.memo / useMemo / useCallback
- 大型对象是否在渲染函数外部定义
4. **安全风险**
- 是否有 XSS 风险（dangerouslySetInnerHTML）
- 用户输入是否经过校验
- 敏感信息是否暴露在客户端
5. **代码风格**
- 是否符合项目 CLAUDE.md 中的编码规范
- 命名是否清晰、一致
- 是否有可读性问题
## 输出格式
按严重程度分类：
- 🔴 **必须修复**：类型错误、安全漏洞、逻辑Bug
- 🟡 **建议优化**：性能隐患、不规范的写法
- 🟢 **小贴士**：可选的改进点
每个问题给出：具体位置 → 问题描述 → 修改建议（附代码）
## 审查目标
$ARGUMENTS使用方式：
bash# 审查单个文件
/review @src/components/ArticleCard.tsx
# 审查整个目录
/review @src/app/api/
# 审查多个文件
/review @src/app/page.tsx @src/app/layout.tsx注意这个命令头部的 YAML frontmatter 部分——description 和 argument-hint 不是必须的，但加上它们之后，你输入 /help 查看所有可用命令时，会显示每个命令的描述和参数提示，非常方便。
命令二：/test —— 测试生成
创建 .claude/commands/test.md：
markdown---
description: 为组件或函数生成单元测试
argument-hint: <文件路径>
---
为以下代码生成完整的单元测试：
## 测试要求
- 测试框架：Vitest + React Testing Library
- 测试文件位置：与源文件同级的 `__tests__/` 目录下
- 文件命名：`ComponentName.test.tsx` 或 `functionName.test.ts`
## 测试覆盖范围
1. **正常路径**：组件正常渲染、函数正常返回
2. **边界情况**：空值、undefined、空数组、超长字符串
3. **错误处理**：网络请求失败、无效参数
4. **用户交互**：点击、输入、表单提交（如果是交互组件）
5. **Props 变化**：不同 Props 组合下的渲染结果
## 代码规范
- 每个测试用例用中文注释说明"测试什么场景"
- describe 用组件名 / 函数名
- it / test 的描述用英文（保持与团队一致）
- 使用 screen.getByRole 优先于 getByTestId
- Mock 外部依赖，不要发真实网络请求
## 示例格式
```typescript
import { render, screen } from '@testing-library/react';
import { ArticleCard } from '../ArticleCard';
describe('ArticleCard', () => {
// 正常渲染：传入完整的文章数据
it('should render article title and author', () => {
// ...
});
// 边界情况：文章摘要为空
it('should handle empty excerpt gracefully', () => {
// ...
});
});测试目标
$ARGUMENTS
code
**使用方式**：
```bash
# 为单个组件生成测试
/test @src/components/ArticleCard.tsx
# 为工具函数生成测试
/test @src/lib/formatDate.ts
# 为 API 路由生成测试
/test @src/app/api/posts/route.ts命令三：/doc —— 组件文档生成
创建 .claude/commands/doc.md：
markdown---
description: 为组件或模块生成文档
argument-hint: <文件或目录路径>
---
为以下代码生成清晰的技术文档：
## 文档内容
1. **概述**：一句话说明这个组件/模块的用途
2. **Props / 参数说明**（表格格式）：
| 属性 | 类型 | 必填 | 默认值 | 说明 |
3. **使用示例**：至少给出 2 个场景的代码示例
- 基础用法
- 进阶用法（带完整 Props）
4. **注意事项**：常见的坑和最佳实践
5. **相关组件/函数**：列出与之配合使用的组件
## 输出格式
- 使用 Markdown 格式
- 代码示例使用 TypeScript
- 文件保存为 `docs/组件名.md`
## 文档目标
$ARGUMENTS使用方式：
bash# 为单个组件生成文档
/doc @src/components/ArticleCard.tsx
# 为整个组件目录生成文档
/doc @src/components/
# 为 API 模块生成文档
/doc @src/app/api/posts/进阶：frontmatter 的高级用法
你可能注意到了命令文件开头有一段 --- 包裹的 YAML。除了 description 和 argument-hint，它还支持更多配置：
markdown---
description: 提交代码并生成规范的 commit message
argument-hint: [提交信息补充说明]
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
model: claude-3-5-haiku-20241022
---几个实用字段：
code┌──────────────────────────────────────────────────────────┐
│ frontmatter 常用字段 │
├───────────────┬──────────────────────────────────────────┤
│ 字段 │ 作用 │
├───────────────┼──────────────────────────────────────────┤
│ description │ 命令描述，/help 时显示 │
│ argument-hint │ 参数提示，/help 时显示 │
│ allowed-tools │ 这个命令可以用的工具白名单 │
│ model │ 强制用指定模型执行这个命令 │
│ context: fork │ 在独立子代理中执行，不污染主对话 │
│ agent │ 指定用哪个子代理执行 │
└───────────────┴──────────────────────────────────────────┘特别说一下 model 字段——这个非常实用。比如 /commit 这种简单的命令（生成 commit message），没必要用最强的 Opus，指定用 Haiku 就够了，又快又省钱：
markdown---
description: 自动 commit 当前改动
allowed-tools: Bash(git status:*), Bash(git diff:*), Bash(git add:*), Bash(git commit:*)
model: claude-3-5-haiku-20241022
---
## 上下文
- 当前 git 状态：!`git status`
- 当前改动详情：!`git diff HEAD`
## 任务
基于以上改动，生成一个规范的 commit message 并提交。
格式要求：type(scope): description
- type: feat / fix / docs / refactor / test / chore
- scope: 改动涉及的模块（如 blog、auth、api）
- description: 简短的英文描述
$ARGUMENTS注意那个 ! 前缀——!git status`` 会在命令加载时先执行 bash 命令，把输出嵌入提示词。这样 Claude 在收到提示词的时候，已经看到了当前的 Git 状态和改动详情，不需要再手动去查。
另一个进阶：动态上下文注入
你可以在命令模板里用 ! 执行任意 bash 命令，把输出作为上下文传给 Claude。这是一个非常强大的技巧。
举个例子——一个 /pr-review 命令，自动拉取当前 PR 的改动：
markdown---
description: 审查当前分支相对于 main 的所有改动
allowed-tools: Bash(git diff:*), Bash(git log:*)
---
## 当前分支信息
- 分支名：!`git branch --show-current`
- 相对 main 的改动文件：!`git diff --name-only main`
- 改动详情：!`git diff main`
## 审查要求
审查以上所有改动，按文件逐个分析：
1. 改动是否合理、完整
2. 是否引入了新的问题
3. 测试覆盖是否充分
给出整体评分（1-10）和改进建议。输入 /pr-review 后，Claude 直接看到完整的 diff 信息，不用你手动复制。
命令组织：当你的命令越来越多
刚开始 3 个命令就够了。但用着用着你会发现更多可以自动化的场景，命令慢慢变多。这时候需要一个清晰的组织结构。
code┌──────────────────────────────────────────────────────────┐
│ 推荐的命令目录结构 │
├──────────────────────────────────────────────────────────┤
│ │
│ .claude/commands/ ← 项目级（提交到 Git） │
│ ├── review.md # 代码审查 │
│ ├── test.md # 生成测试 │
│ ├── doc.md # 生成文档 │
│ ├── commit.md # Git 提交 │
│ └── pr-review.md # PR 审查 │
│ │
│ ~/.claude/commands/ ← 个人级（所有项目通用） │
│ ├── explain.md # 解释代码逻辑 │
│ ├── refactor.md # 重构建议 │
│ └── perf.md # 性能分析 │
│ │
│ 分工原则： │
│ 项目级 = 跟项目绑定的命令（用这个项目的规范和工具） │
│ 个人级 = 通用命令（任何项目都能用） │
│ │
│ 数量原则： │
│ 3 个精心设计的核心命令 > 20 个随便写的命令 │
│ 只给真正高频的操作建命令 │
│ │
└──────────────────────────────────────────────────────────┘有个实用技巧：输入 /help 查看所有可用命令，包括内置命令和你创建的自定义命令。它会显示每个命令的 description，帮你快速回忆每个命令是干嘛的。
命令文件放在子目录里也可以正常工作。比如 .claude/commands/git/commit.md，调用的时候还是用 /commit（文件名做命令名，子目录只是用来组织文件的）。
模型选择策略：杀鸡别用牛刀
命令做好了，还有一个影响效率和成本的关键因素——你用哪个模型来执行任务。
Claude Code 支持三个主力模型，各有各的长处：
code┌──────────────────────────────────────────────────────────┐
│ 三大模型定位对比 │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Opus 4.6（旗舰） │ │
│ │ 🧠 推理能力最强，适合复杂任务 │ │
│ │ 💰 Token 费用最高 │ │
│ │ ⏱️ 响应速度最慢 │ │
│ │ │ │
│ │ 适合：架构设计、复杂 Bug 调试、 │ │
│ │ 跨文件重构、技术方案评估 │ │
│ │ 不适合：简单格式化、写 commit message │ │
│ └─────────────────────────────────────────┘ │
│ ↑ 最强 │
│ │ │
│ ┌─────────────────────────────────────────┐ │
│ │ Sonnet 4.5（主力）⭐ 日常默认 │ │
│ │ 🧠 性能和速度的最佳平衡 │ │
│ │ 💰 费用适中 │ │
│ │ ⏱️ 响应速度快 │ │
│ │ │ │
│ │ 适合：代码审查、功能实现、Bug 修复、 │ │
│ │ 测试编写、日常 90% 的任务 │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ↓ 最快 │
│ ┌─────────────────────────────────────────┐ │
│ │ Haiku 4.5（轻量） │ │
│ │ 🧠 基础推理能力 │ │
│ │ 💰 费用最低 │ │
│ │ ⏱️ 响应速度最快 │ │
│ │ │ │
│ │ 适合：生成 commit message、简单格式化、 │ │
│ │ 文件重命名、写注释 │ │
│ │ 不适合：复杂代码逻辑、架构分析 │ │
│ └─────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘怎么切换模型？
方法一：交互模式中随时切换
code/model
输入 /model 后会弹出选择菜单，选一个就行。切换即时生效，当前会话后续的所有操作都用新模型。
方法二：在 settings.json 里设置默认模型
json{
"model": "sonnet"
}支持的简写：opus、sonnet、haiku。也可以用完整的模型名，比如 claude-sonnet-4-5-20250929。
方法三：在命令的 frontmatter 里指定（推荐）
这是最精细的控制方式——不同的命令用不同的模型：
markdown---
description: 生成 commit message
model: claude-3-5-haiku-20241022
---这样你的 /commit 命令永远用 Haiku（快速便宜），而 /review 命令可以保持用默认的 Sonnet（更准确）。需要深度分析的时候手动切 Opus。
我的模型使用策略
用了大半年总结出来的经验：
code┌───────────────────────────────────────────────────────┐
│ 模型选择速查表 │
├──────────────────┬────────────────────────────────────┤
│ 任务类型 │ 推荐模型 │
├──────────────────┼────────────────────────────────────┤
│ 日常编码、功能开发 │ Sonnet（默认） │
│ 代码审查 │ Sonnet │
│ 测试编写 │ Sonnet │
│ Bug 修复 │ Sonnet，复杂问题切 Opus │
│ 架构设计/评审 │ Opus │
│ 复杂多文件重构 │ Opus │
│ 生成 commit msg │ Haiku │
│ 写注释/文档 │ Haiku 或 Sonnet │
│ 简单格式化 │ Haiku │
│ 解释代码逻辑 │ Sonnet │
│ 技术方案对比 │ Opus │
└──────────────────┴────────────────────────────────────┘
一句话总结：
Sonnet 是你的日常主力（80% 的任务）
Opus 是你的"大杀器"（复杂推理时启用）
Haiku 是你的"跑腿小弟"（简单重复任务）还有一个隐藏技巧——opusplan 模式。在 settings.json 里设置 "model": "opusplan"，Claude 会用 Opus 做规划和思考，用 Sonnet 做执行。既保证了方案质量，又控制了执行成本。
实用内置命令速查
除了你自定义的命令，Claude Code 内置了不少实用命令。很多人用了几个月都不知道有这些：
code┌──────────────────────────────────────────────────────────┐ │ 内置命令速查（精选高频） │ ├──────────────┬───────────────────────────────────────────┤ │ 命令 │ 作用 │ ├──────────────┼───────────────────────────────────────────┤ │ /help │ 查看所有可用命令（含你的自定义命令） │ │ /model │ 切换 AI 模型 │ │ /compact │ 压缩当前对话历史，释放上下文空间 │ │ /clear │ 清空对话，从零开始 │ │ /init │ 自动分析项目并生成 CLAUDE.md │ │ /permissions │ 交互式管理权限规则 │ │ /memory │ 编辑 Auto Memory │ │ /config │ 打开设置面板 │ │ /context │ 查看当前加载的上下文（哪些文件被读了） │ │ /cost │ 查看本次会话的 Token 消耗和费用 │ │ /bug │ 向 Anthropic 报告 Bug │ └──────────────┴───────────────────────────────────────────┘
特别推荐两个：
/compact——当你的对话变得很长的时候，Claude 的上下文窗口会被填满，响应质量开始下降。这时候用 /compact，Claude 会把前面的对话压缩成摘要，释放空间。注意压缩是不可逆的，适合在完成一个阶段性任务后用。
/cost——按量付费的同学一定要常用这个命令，随时关注费用。如果一个会话的费用增长太快，考虑切到 Haiku 或者清空重新开始。
终端体验优化小技巧
最后给几个提升日常使用体验的小贴士。
技巧 1：/clear 是你最好的朋友
每开始一个新任务，先 /clear 清空上下文。上一个任务的对话残留在那里只会消耗 Token、干扰回答质量。开新任务 = 开新会话，养成这个习惯。
技巧 2：Ctrl+R 搜索历史提示词
你上周写过一段特别好的 prompt，这周想再用？在交互模式中按 Ctrl+R，输入关键词搜索你之前打过的提示词，找到后回车直接复用。
技巧 3：用 /context 排查"Claude 不听话"的问题
如果 Claude 的行为不符合你的预期——比如它没有遵循 CLAUDE.md 里的规范——先用 /context 看看它实际加载了哪些文件。可能是 CLAUDE.md 没被正确加载，或者被其他配置覆盖了。
技巧 4：状态栏信息
Claude Code 的状态栏会显示当前使用的模型、Token 消耗量等信息。养成看一眼状态栏的习惯，能帮你及时发现"哦，我现在用的还是 Opus，这个简单任务不需要"。
本篇小结
三个核心收获：
第一，Slash 命令是提效利器——把高频提示词模板化，/review、/test、/doc 三个命令覆盖日常 80% 的场景。一个 Markdown 文件就是一个命令，零学习成本。
第二，frontmatter 让命令更强大——allowed-tools 控制权限、model 指定模型、! 前缀注入动态上下文。掌握这些进阶用法，命令就不只是"快捷方式"，而是完整的自动化工作流。
第三，模型选择影响效率和成本——Sonnet 做主力（80%），Opus 做大杀器（复杂推理），Haiku 做跑腿小弟（简单任务）。别用 Opus 写 commit message，也别用 Haiku 做架构设计。
Level 2 通关检查清单
回顾一下 Level 2（配置篇）两篇文章的完整检查清单：
- 项目有完善的 CLAUDE.md（第 3 篇）
- 创建了全局 ~/.claude/CLAUDE.md（第 3 篇）
- 创建了至少 3 个 Slash 命令（/review、/test、/doc）
- 了解 frontmatter 的高级配置（allowed-tools、model）
- 了解三大模型的定位，能根据任务选择合适的模型
- 知道 /model 切换模型和 /compact 压缩上下文
- 知道 /help 查看所有可用命令
全部打勾？恭喜，Level 2 通关。你的 Claude Code 现在已经从"一个能用的工具"变成了"一个高度定制化的效率引擎"。
下篇预告
第 5 篇：Claude Code 通关手册（五）—— 子代理系统：给你的 AI 配一个"专家团队"
从下一篇开始进入 Level 3（扩展篇），这是整个系列最激动人心的部分。
想象一下：你不再是跟一个 AI 对话，而是有一个"AI 团队"——一个负责审查代码、一个负责写测试、一个负责查安全漏洞。你说一句"审查这个 PR"，三个 AI 各自出具报告汇总给你。
这不是未来，这是 Claude Code 的子代理系统现在就能做到的事情。下一篇，我带你搭建它。
今日话题
你最常重复输入的提示词是什么？如果做成 Slash 命令，你觉得每天能省多少时间？评论区聊聊，看看大家最想自动化的是哪些操作。
如果这篇文章帮你告别了"每天重复打同一段话"的痛苦，欢迎点赞、在看、转发三连——你的技术同事看到了一定会感谢你。
关注「前端达人」，Level 3 扩展篇马上开启，我们下篇见。
如果这篇对你有帮助，欢迎关注公众号「前端达人」，每周更新实用前端干货。
