上一篇我们讲了 Rule------给你的 AI 员工立规矩。
规矩立完了，下一步是什么？
是把常用的操作标准化。
公司有了规章制度，还需要什么？操作手册。遇到这种情况走哪个流程，遇到那种情况怎么处理，写清楚，不用每次口头交代。
这就是 Command。
先说一个让我烦透了的事
我之前让 Claude Code 帮我生成 commit message，都要输一段差不多的话：
diff
根据当前代码变更，生成一条 commit message。
要求：
- 使用约定式提交格式（feat/fix/refactor/docs/chore）
- 描述用中文
- 不超过 50 个字
- 不要加多余的解释每次，同样的要求，重复输入。
用了几天之后，我开始想：这件事能不能只做一次？
可以。这就是 Command。
什么是 Command
说白了，Command 就是把一段 Prompt 存成文件，用 /命令名 来触发。
你创建一个 .md 文件，把要说的话写进去，以后不用再重复输入。直接输 /命令名，Claude Code 就会用那段内容作为 Prompt 执行。
文件名就是命令名。
建一个 .claude/commands/commit.md，以后就输 /commit 触发。建一个 review.md，就输 /review。
就这样。
你可以把它理解成给 AI 员工的标准化操作手册------遇到标准场景，按流程走，不需要每次口头交代。
Command 分两层
和 Rule 一样，Command 也有两个层级：
个人全局命令
路径：~/.claude/commands/
放在这里的 Commands，在你电脑上所有项目都能用。
适合放个人习惯性操作，比如你个人的 commit 风格、你喜欢的代码审查标准。
项目级命令
路径：.claude/commands/（项目根目录下）
这层命令跟着代码仓库走，提交到 git 后全团队共享。
适合放团队统一流程，比如部署前检查清单、数据库迁移审查、统一的 PR 描述模板。
遇到同名命令，项目级优先。团队命令可以覆盖个人习惯。
5 个值得封装成 Command 的场景
① 生成规范的 commit message
这是最常见的场景，也是我用 Command 的起点。
.claude/commands/commit.md：
markdown
根据当前代码变更，生成一条符合约定式提交规范的 commit message。
要求：
- 类型：feat / fix / refactor / docs / chore / style / test
- 描述使用中文，不超过 50 个字
- 如有必要，在 body 里补充变更原因（可选）
- 不要加多余的解释，直接给结果
约定式提交格式：<type>(<scope>): <subject>以后每次写完代码，输 /commit 直接出结果。
② 代码 review
每次让 AI review 代码，你想要的维度其实是固定的------安全问题、错误处理、类型安全、性能......
不如写进 Command：
.claude/commands/review.md：
markdown
对当前的代码变更进行 review，检查以下维度：
1. **安全问题**：SQL 注入、XSS、暴露的敏感信息
2. **错误处理**：未捕获的异常、吞掉的错误
3. **类型安全**：any 的滥用、缺少返回类型
4. **性能问题**：不必要的重渲染、缺少缓存
5. **逻辑错误**：边界条件、空值处理
按严重程度分类：Critical / Warning / Suggestion。
每条问题注明文件路径和行号，并给出修改建议。
如果没有问题，直接说"未发现问题"。输 /review，得到结构一致的 review 结果。
③ 部署前检查
每次部署前要做的事，用 Command 跑一遍：
.claude/commands/pre-deploy.md：
markdown
执行部署前检查清单：
1. 运行测试套件，报告失败项
2. 运行类型检查，报告错误
3. 检查是否有未提交的文件
4. 检查当前分支是否落后于 origin
5. 列出本分支新增的 TODO / FIXME 注释
所有检查通过后，输出"部署就绪"。
任何检查失败，立即停下来报告详情。
**不要执行实际部署动作，只做检查。**④ 测试生成
.claude/commands/gen-tests.md：
markdown
为我指定的文件生成单元测试。
规则：
- 使用项目现有的测试框架
- 覆盖正常流程、异常情况、边界值
- 测试名称用中文描述预期行为
- Mock 外部依赖
- 参考项目里已有的测试文件风格
生成后运行测试，如果失败，自动修复后再报告结果。⑤ Figma 设计稿转组件
设计师给了个 Figma 链接，让你按设计稿实现。
以前的做法是：打开 Figma，盯着看，手写组件，再对比调。
现在可以用 Command + MCP 直接自动化这个流程。
先确保项目已接入 Figma MCP（这个后续讲 MCP 篇会细说），然后建一个：
.claude/commands/figma.md：
markdown
根据 Figma 设计稿链接，调用 Figma MCP Server 读取设计稿信息，生成对应的 Vue 组件。
设计稿链接：$ARGUMENTS
要求：
- 使用 Composition API + <script setup>
- 样式使用 Tailwind CSS（或项目现有的样式方案）
- 组件结构参考 src/components/ 下已有组件的风格
- 响应式处理参考设计稿中的断点
- 颜色、间距、字体严格按设计稿，不要自行发挥
- 生成后列出与设计稿可能存在的差异点，供人工核对
如果设计稿包含交互逻辑（hover/click 状态等），一并实现。调用方式：
bash
/figma https://www.figma.com/design/xxxx?node-id=xxx粘一个 Figma 链接，AI 自己去读设计稿，然后按你的组件规范生成代码。
这个 Command 把「看稿 → 写组件 → 对齐设计」的流程压缩到一次对话里完成。
怎么写一个 Command
基础版：直接写 Prompt
最简单的用法------在 .claude/commands/ 下建一个 .md 文件，把你要说的话写进去。
markdown
.claude/
└── commands/
└── commit.md打开 Claude Code，输 /commit，就触发了。
进阶一：传入参数（$ARGUMENTS）
Command 支持接收参数，用 $ARGUMENTS 占位。
比如一个「解释代码」的命令：
.claude/commands/explain.md：
markdown
用中文解释以下代码或概念，结合项目上下文：
$ARGUMENTS
解释格式：
1. **是什么** --- 用一句话说清楚
2. **怎么工作的** --- 拆解核心逻辑
3. **为什么这样设计** --- 架构上的考虑
4. **坑在哪里** --- 边界情况或容易误解的地方调用方式：
bash
/explain src/utils/auth.ts 里的 verifyToken 函数
/explain 项目里的缓存策略是怎么设计的每次输入不同内容，但格式和分析维度完全一致。
进阶二：注入动态上下文（``!`命令```）
这个功能我用得最多，也最有意思。
你可以在 Command 文件里用 ``!`bash命令``` 的语法，让 Claude Code 在执行前先跑一段 Shell，把结果注入进去。
比如一个 commit Command，自动把当前 diff 注入进来：
.claude/commands/commit.md：
markdown
根据以下代码变更，生成一条符合约定式提交规范的 commit message：
!`git diff --cached`
要求：
- 类型：feat / fix / refactor / docs / chore
- 描述用中文，不超过 50 个字
- 直接给结果，不要多余解释这样每次执行 /commit，Claude Code 先跑 git diff --cached 获取当前暂存区内容，再结合你的要求生成 commit。
不需要你手动复制粘贴 diff，AI 自己去取。
类似的用法还有很多：
markdown
!`git log main..HEAD --oneline` # 获取当前分支的提交记录
!`cat package.json` # 注入项目依赖信息
!`pnpm test 2>&1 | tail -20` # 注入最近的测试结果进阶：子目录分类
Command 多了之后，可以用子目录来分类管理：
markdown
.claude/
└── commands/
├── commit.md
├── review.md
├── db/
│ ├── migration-check.md
│ └── seed.md
└── docs/
├── pr.md
└── changelog.md调用时用冒号分隔：/db:migration-check、/docs:pr。
项目大了，命令多了，用子目录分类，不会乱。
注意事项
先搞定 Rule，再来写 Command。
Command 里的 Prompt 是在 Rule 的基础上工作的。比如你写了 /commit，但 CLAUDE.md 里没有约定提交规范，Command 只能靠 Prompt 自己承载。
更好的做法：Rule 定方向，Command 定动作。两者配合，才能发挥最大效果。
别让一个 Command 做太多事。
Command 粒度太大，执行起来容易跑偏。把「部署前检查 + 写 changelog + 发通知」塞进一个命令，不如拆成三个。
一个 Command，一件事。需要的时候顺序触发就行。
写清楚停止条件。
Command 默认会一路执行下去。如果有某些情况下不该继续，写明白：
markdown
如果测试失败，立即停下并报告，不要继续后续步骤。否则 AI 可能在测试挂掉的情况下继续往下走。
命令文件也是文档。
.claude/commands/deploy.md 写清楚了部署检查流程，新人看这个文件就能搞清楚团队规范。哪怕他不用 Claude Code。
好的 Command，顺带也是好的 SOP 文档。
去哪找好的 Command 模板
awesome-claude-code
github.com/hesreallyhim/awesome-claude-code
26,000+ Stars 的 Claude Code 资源集合，里面有专门的 Slash Commands 分类，覆盖 git、测试、代码分析、文档生成等常见场景。
localskills.sh
专注于 Agent Skills 和 Commands 分发的平台。可以搜索社区贡献的命令模板，也可以把自己的 Command 发布出去跨项目复用。
最后
Rule 解决的是「AI 应该怎么做」。
Command 解决的是「哪些事值得标准化，不用每次口头交代」。
有了 Rule，AI 知道规矩。有了 Command，AI 知道流程。两者配合，就踏出了 AI 编程工程化第一步。
能复用的操作，不该手打两次。
你每天重复输的那段 Prompt，花 10 分钟封装成 Command，之后一行 /命令名 搞定。
下一篇我们讲 Skill：社区里有哪些好用的 Skill，怎么安装，自己怎么创建。
欢迎感兴趣的朋友继续保持关注~