Claude Code 通关手册（四）：3 个自定义命令，让你的 Claude Code 快到飞起

┌──────────────────────────────────────────────────────────┐
│          Slash 命令工作原理                                 │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  你创建的文件：                                            │
│  .claude/commands/review.md                              │
│                                                          │
│  文件内容：                                                │
│  "审查以下文件，关注类型安全和性能... $ARGUMENTS"           │
│                                                          │
│  你输入：                                                  │
│  /review @src/components/ArticleCard.tsx                 │
│                                                          │
│  Claude 实际收到的提示词：                                  │
│  "审查以下文件，关注类型安全和性能...                       │
│   @src/components/ArticleCard.tsx"                        │
│                                                          │
│  $ARGUMENTS 被替换为命令后面的所有文字                      │
│                                                          │
└──────────────────────────────────────────────────────────┘

mkdir -p .claude/commands

---
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

# 审查单个文件
/review @src/components/ArticleCard.tsx

# 审查整个目录
/review @src/app/api/

# 审查多个文件
/review @src/app/page.tsx @src/app/layout.tsx

---
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', () => {
    // ...
  });
});

**使用方式**：

```bash
# 为单个组件生成测试
/test @src/components/ArticleCard.tsx

# 为工具函数生成测试
/test @src/lib/formatDate.ts

# 为 API 路由生成测试
/test @src/app/api/posts/route.ts

---
description: 为组件或模块生成文档
argument-hint: <文件或目录路径>
---

为以下代码生成清晰的技术文档：

## 文档内容

1. **概述**：一句话说明这个组件/模块的用途
2. **Props / 参数说明**（表格格式）：
   | 属性 | 类型 | 必填 | 默认值 | 说明 |
3. **使用示例**：至少给出 2 个场景的代码示例
   - 基础用法
   - 进阶用法（带完整 Props）
4. **注意事项**：常见的坑和最佳实践
5. **相关组件/函数**：列出与之配合使用的组件

## 输出格式

- 使用 Markdown 格式
- 代码示例使用 TypeScript
- 文件保存为 `docs/组件名.md`

## 文档目标

$ARGUMENTS

# 为单个组件生成文档
/doc @src/components/ArticleCard.tsx

# 为整个组件目录生成文档
/doc @src/components/

# 为 API 模块生成文档
/doc @src/app/api/posts/

---
description: 提交代码并生成规范的 commit message
argument-hint: [提交信息补充说明]
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
model: claude-3-5-haiku-20241022
---

┌──────────────────────────────────────────────────────────┐
│          frontmatter 常用字段                               │
├───────────────┬──────────────────────────────────────────┤
│ 字段           │ 作用                                      │
├───────────────┼──────────────────────────────────────────┤
│ description   │ 命令描述，/help 时显示                     │
│ argument-hint │ 参数提示，/help 时显示                     │
│ allowed-tools │ 这个命令可以用的工具白名单                  │
│ model         │ 强制用指定模型执行这个命令                  │
│ context: fork │ 在独立子代理中执行，不污染主对话             │
│ agent         │ 指定用哪个子代理执行                       │
└───────────────┴──────────────────────────────────────────┘

---
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

---
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）和改进建议。

┌──────────────────────────────────────────────────────────┐
│          推荐的命令目录结构                                  │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  .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 个随便写的命令                 │
│  只给真正高频的操作建命令                                   │
│                                                          │
└──────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────┐
│          三大模型定位对比                                    │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  ┌─────────────────────────────────────────┐             │
│  │  Opus 4.6（旗舰）                        │             │
│  │  🧠 推理能力最强，适合复杂任务            │             │
│  │  💰 Token 费用最高                       │             │
│  │  ⏱️ 响应速度最慢                         │             │
│  │                                         │             │
│  │  适合：架构设计、复杂 Bug 调试、          │             │
│  │       跨文件重构、技术方案评估            │             │
│  │  不适合：简单格式化、写 commit message    │             │
│  └─────────────────────────────────────────┘             │
│                    ↑ 最强                                 │
│                    │                                      │
│  ┌─────────────────────────────────────────┐             │
│  │  Sonnet 4.5（主力）⭐ 日常默认           │             │
│  │  🧠 性能和速度的最佳平衡                 │             │
│  │  💰 费用适中                             │             │
│  │  ⏱️ 响应速度快                           │             │
│  │                                         │             │
│  │  适合：代码审查、功能实现、Bug 修复、     │             │
│  │       测试编写、日常 90% 的任务           │             │
│  └─────────────────────────────────────────┘             │
│                    │                                      │
│                    ↓ 最快                                 │
│  ┌─────────────────────────────────────────┐             │
│  │  Haiku 4.5（轻量）                       │             │
│  │  🧠 基础推理能力                         │             │
│  │  💰 费用最低                             │             │
│  │  ⏱️ 响应速度最快                         │             │
│  │                                         │             │
│  │  适合：生成 commit message、简单格式化、  │             │
│  │       文件重命名、写注释                  │             │
│  │  不适合：复杂代码逻辑、架构分析           │             │
│  └─────────────────────────────────────────┘             │
│                                                          │
└──────────────────────────────────────────────────────────┘

/model

{
  "model": "sonnet"
}

---
description: 生成 commit message
model: claude-3-5-haiku-20241022
---

┌───────────────────────────────────────────────────────┐
│          模型选择速查表                                   │
├──────────────────┬────────────────────────────────────┤
│ 任务类型          │ 推荐模型                             │
├──────────────────┼────────────────────────────────────┤
│ 日常编码、功能开发 │ Sonnet（默认）                      │
│ 代码审查          │ Sonnet                              │
│ 测试编写          │ Sonnet                              │
│ Bug 修复          │ Sonnet，复杂问题切 Opus              │
│ 架构设计/评审     │ Opus                                │
│ 复杂多文件重构    │ Opus                                │
│ 生成 commit msg   │ Haiku                               │
│ 写注释/文档       │ Haiku 或 Sonnet                     │
│ 简单格式化        │ Haiku                               │
│ 解释代码逻辑      │ Sonnet                              │
│ 技术方案对比      │ Opus                                │
└──────────────────┴────────────────────────────────────┘

一句话总结：
Sonnet 是你的日常主力（80% 的任务）
Opus 是你的"大杀器"（复杂推理时启用）
Haiku 是你的"跑腿小弟"（简单重复任务）

┌──────────────────────────────────────────────────────────┐
│          内置命令速查（精选高频）                            │
├──────────────┬───────────────────────────────────────────┤
│ 命令          │ 作用                                       │
├──────────────┼───────────────────────────────────────────┤
│ /help        │ 查看所有可用命令（含你的自定义命令）          │
│ /model       │ 切换 AI 模型                                │
│ /compact     │ 压缩当前对话历史，释放上下文空间              │
│ /clear       │ 清空对话，从零开始                           │
│ /init        │ 自动分析项目并生成 CLAUDE.md                 │
│ /permissions │ 交互式管理权限规则                           │
│ /memory      │ 编辑 Auto Memory                           │
│ /config      │ 打开设置面板                                │
│ /context     │ 查看当前加载的上下文（哪些文件被读了）        │
│ /cost        │ 查看本次会话的 Token 消耗和费用              │
│ /bug         │ 向 Anthropic 报告 Bug                      │
└──────────────┴───────────────────────────────────────────┘