你有没有计算过，每天在 Claude Code 里重复输入同一段提示词要浪费多少时间？
我观察了自己的日常工作流，发现了一个尴尬的现实：为了进行一次全面的代码审查，我每天至少要手动输入三次那段长达 50 个字的提示词。一周下来，光打字就够写一篇小作文了。更糟糕的是，手动输入难免遗漏关键检查项，比如上周就因为忘了强调“安全问题”，让一个潜在的 XSS 漏洞溜了过去。
其实，解决方案简单得让人想拍大腿：把这些高频提示词固化为自定义的 Slash 命令。
今天，我们就来创建三个能显著提升日常效率的 Slash 命令：/review、/test 和 /doc，并配合正确的模型选择策略，让你的 Claude Code 真正快到飞起。
30 秒理解 Slash 命令
你可以把 Slash 命令理解为开发工作流中的“快捷指令”。就像你对手机说“打开工作模式”，它会自动帮你静音、打开办公软件一样，Claude Code 的 Slash 命令允许你将一段复杂的提示词模板化，以后只需输入 /命令名 即可触发执行。
从技术实现上看，非常简单：
- 文件位置：放在
.claude/commands/（项目级）或 ~/.claude/commands/（全局级）
- 文件格式：普通的 Markdown 文件，文件名即为命令名
- 调用方式：在交互模式中输入
/命令名 参数
- 参数传递：在命令文件中使用
$ARGUMENTS 变量来接收命令后的所有文字
一个 Markdown 文件就等于一个命令，无需编写任何额外代码。
┌──────────────────────────────────────────────────────────┐
│ Slash 命令工作原理 │
├──────────────────────────────────────────────────────────┤
│ │
│ 你创建的文件： │
│ .claude/commands/review.md │
│ │
│ 文件内容： │
│ "审查以下文件，关注类型安全和性能... $ARGUMENTS" │
│ │
│ 你输入： │
│ /review @src/components/ArticleCard.tsx │
│ │
│ Claude 实际收到的提示词： │
│ "审查以下文件，关注类型安全和性能... │
│ @src/components/ArticleCard.tsx" │
│ │
│ $ARGUMENTS 被替换为命令后面的所有文字 │
│ │
└──────────────────────────────────────────────────────────┘
命令一：/review —— 你的专职代码审查官（使用频率最高）
直接开始动手。在你的项目根目录下创建命令文件：
mkdir -p .claude/commands
然后创建 .claude/commands/review.md 文件，内容如下：
---
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
注意文件头部的 YAML frontmatter（--- 包裹的部分）。description 和 argument-hint 不是必需的，但加上后，当你输入 /help 查看所有可用命令时，会显示清晰的描述和参数提示，非常方便。
命令二：/test —— 自动化的测试生成器
创建 .claude/commands/test.md：
---
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
使用方式：
# 为单个组件生成测试
/test @src/components/ArticleCard.tsx
# 为工具函数生成测试
/test @src/lib/formatDate.ts
# 为 API 路由生成测试
/test @src/app/api/posts/route.ts
命令三：/doc —— 一键生成组件文档
创建 .claude/commands/doc.md：
---
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/
进阶技巧：Frontmatter 的高级用法
你可能已经注意到，命令文件开头的 YAML frontmatter 功能不止于此。除了 description 和 argument-hint，它还支持更多强大配置：
---
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 │ 指定用哪个子代理执行 │
└───────────────┴──────────────────────────────────────────┘
特别说一下 model 字段：这非常实用。对于像 /commit 这样的简单命令，完全没必要动用最强的 Opus 模型。在 frontmatter 中指定使用 Haiku，既能保证任务完成，又能节省成本和时间。
再看一个 allowed-tools 和动态上下文的例子：
---
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 改动的 /pr-review 命令：
---
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 将直接基于完整的代码差异进行分析。
模型选择策略：平衡成本与性能
命令创建好后，另一个影响效率和成本的关键因素是模型选择。Claude Code 主要提供三个模型，定位各不相同：
┌──────────────────────────────────────────────────────────┐
│ 三大模型定位对比 │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────┐ │
│ │ Opus 4.6（旗舰） │ │
│ │ 🧠 推理能力最强，适合复杂任务 │ │
│ │ 💰 Token 费用最高 │ │
│ │ ⏱️ 响应速度最慢 │ │
│ │ │ │
│ │ 适合：架构设计、复杂 Bug 调试、 │ │
│ │ 跨文件重构、技术方案评估 │ │
│ │ 不适合：简单格式化、写 commit message │ │
│ └─────────────────────────────────────────┘ │
│ ↑ 最强 │
│ │ │
│ ┌─────────────────────────────────────────┐ │
│ │ Sonnet 4.5（主力）⭐ 日常默认 │ │
│ │ 🧠 性能和速度的最佳平衡 │ │
│ │ 💰 费用适中 │ │
│ │ ⏱️ 响应速度快 │ │
│ │ │ │
│ │ 适合：代码审查、功能实现、Bug 修复、 │ │
│ │ 测试编写、日常 90% 的任务 │ │
│ └─────────────────────────────────────────┘ │
│ │ │
│ ↓ 最快 │
│ ┌─────────────────────────────────────────┐ │
│ │ Haiku 4.5（轻量） │ │
│ │ 🧠 基础推理能力 │ │
│ │ 💰 费用最低 │ │
│ │ ⏱️ 响应速度最快 │ │
│ │ │ │
│ │ 适合：生成 commit message、简单格式化、 │ │
│ │ 文件重命名、写注释 │ │
│ │ 不适合：复杂代码逻辑、架构分析 │ │
│ └─────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘
如何切换模型？
- 交互式切换：输入
/model，从弹出菜单中选择。
- 配置文件设置默认模型：在
settings.json 中设置 "model": "sonnet"。
- 在命令的 frontmatter 中指定（最推荐）：这是最精细的控制方式。你可以让
/commit 命令永远用快速的 Haiku，而让 /review 命令使用更准确的 Sonnet。
基于长期使用的经验，我的模型选择策略可以总结为以下速查表：
┌───────────────────────────────────────────────────────┐
│ 模型选择速查表 │
├──────────────────┬────────────────────────────────────┤
│ 任务类型 │ 推荐模型 │
├──────────────────┼────────────────────────────────────┤
│ 日常编码、功能开发 │ Sonnet（默认） │
│ 代码审查 │ Sonnet │
│ 测试编写 │ Sonnet │
│ Bug 修复 │ Sonnet，复杂问题切 Opus │
│ 架构设计/评审 │ Opus │
│ 复杂多文件重构 │ Opus │
│ 生成 commit msg │ Haiku │
│ 写注释/文档 │ Haiku 或 Sonnet │
│ 简单格式化 │ Haiku │
│ 解释代码逻辑 │ Sonnet │
│ 技术方案对比 │ Opus │
└──────────────────┴────────────────────────────────────┘
一句话总结：让 Sonnet 成为你的日常主力（处理80%的任务），在需要深度推理时启用 Opus 这把“大杀器”，而把 Haiku 当作处理简单重复任务的“跑腿小弟”。
实用内置命令速查
除了自定义命令，Claude Code 本身也内置了许多实用命令，值得你善加利用：
┌──────────────────────────────────────────────────────────┐
│ 内置命令速查（精选高频） │
├──────────────┬───────────────────────────────────────────┤
│ 命令 │ 作用 │
├──────────────┼───────────────────────────────────────────┤
│ /help │ 查看所有可用命令（含你的自定义命令） │
│ /model │ 切换 AI 模型 │
│ /compact │ 压缩当前对话历史，释放上下文空间 │
│ /clear │ 清空对话，从零开始 │
│ /init │ 自动分析项目并生成 CLAUDE.md │
│ /permissions │ 交互式管理权限规则 │
│ /memory │ 编辑 Auto Memory │
│ /config │ 打开设置面板 │
│ /context │ 查看当前加载的上下文（哪些文件被读了） │
│ /cost │ 查看本次会话的 Token 消耗和费用 │
│ /bug │ 向 Anthropic 报告 Bug │
└──────────────┴───────────────────────────────────────────┘
特别推荐其中两个：
/compact：当对话历史过长导致上下文窗口紧张时，使用此命令可以让 Claude 将之前的对话压缩成摘要，从而释放空间。注意这是不可逆操作，适合在一个阶段任务完成后使用。/cost：对于按量付费的用户，这是一个必用的监控命令，可以随时了解当前会话的费用消耗情况。
高效使用小贴士
最后，分享几个能显著提升日常体验的小技巧：
- 善用
/clear：开始一项新任务前，先清空上下文。残留的旧对话只会无谓消耗 Token 并可能干扰新任务的回答质量。养成“新任务 = 新会话”的好习惯。
Ctrl+R 搜索历史：在交互模式中按下 Ctrl+R，可以搜索之前输入过的提示词历史，方便快速复用优秀的 Prompt。- 用
/context 诊断问题：如果 Claude 的行为不符合预期（例如没有遵循 CLAUDE.md 的规范），先用 /context 命令检查它实际加载了哪些上下文文件，这有助于快速定位配置问题。
- 关注状态栏：Claude Code 的状态栏会实时显示当前模型、Token 用量等信息。养成瞥一眼状态栏的习惯，能帮你及时意识到“哦，我还在用 Opus 处理这个简单任务”，从而快速调整。
总结与行动清单
通过本文，你掌握了 Claude Code 提效的三个核心要点：
- Slash 命令是效率倍增器：将高频、复杂的提示词（如代码审查、生成测试、编写文档）固化为
/review、/test、/doc 等命令，通过一个简单的斜杠指令即可触发，彻底告别重复输入。
- Frontmatter 赋予命令强大能力：利用
allowed-tools、model 指定以及 ! 动态上下文注入，你可以将 Slash 命令从简单的“快捷方式”升级为完整的、智能的自动化工作流。
- 明智的模型选择是关键：根据任务复杂度，在 Sonnet（主力）、Opus（复杂推理）和 Haiku（简单任务）之间合理切换，在保证效果的同时，优化响应速度和使用成本。
为了巩固学习效果，你可以对照以下清单检查自己的掌握情况：
- [ ] 在项目中创建了
.claude/commands/ 目录
- [ ] 成功创建并测试了
/review、/test、/doc 三个核心命令
- [ ] 理解了 frontmatter 中
model、allowed-tools 等字段的作用
- [ ] 能根据任务类型（简单、常规、复杂）主动选择合适的模型（Haiku/Sonnet/Opus）
- [ ] 知道如何使用
/help 查看命令列表，以及用 /clear 管理对话上下文
当你完成以上步骤，就意味着你已经成功将 Claude Code 从一个“好用的工具”，配置成了一个高度个性化、真正懂你工作习惯的“效率引擎”。接下来，你就可以在 云栈社区 等开发者社区，探索更多关于 前端框架与工程化 的进阶技巧，或是学习如何编写高质量的 技术文档。
发表于 14 小时前
|
查看: 3|
回复: 0
