浅析为什么要用Cursor Commands及在日常开发中如何使用的最佳实践
一句话总结：Cursor Commands = 把常用的 AI 提示词变成可复用、可分享、可管理的快捷命令。
核心价值：提效 + 标准化 + 团队协作。
官方文档：https://cursor.com/cn/docs/agent/chat/commands
一、Cursor Commands
1、是什么？
Cursor Commands = 可复用的提示词模板
用 / 前缀触发的自定义命令，本质是把你常用的提示词保存成 .md 文件，需要时一键调用。类比理解：就像微信的"快捷回复"，或者 IDE 里的"代码片段(Snippets)"，只不过这里存的是"给 AI 的指令"
2、为什么要用？
| 痛点 | Commands 解决方案 |
|---|---|
| 每次都要重复输入相同提示词 | 保存一次，/ 调用 |
| 团队成员用的提示词五花八门 | 统一标准命令 |
| 复杂工作流步骤记不住 | 写成清单，AI 按步骤执行 |
| 新人不知道该怎么让 AI 帮忙 | 现成命令直接用 |
Commands vs 直接输入提示词
| 对比项 | 直接输入 | 使用 Commands |
|---|---|---|
| 效率 | 每次手动输入 | 一键调用 |
| 一致性 | 每次可能不同 | 固定模板 |
| 复杂流程 | 容易遗漏步骤 | 清单式确保完整 |
| 团队协作 | 各自为战 | 统一标准 |
| 维护性 | 无法复用 | 集中管理 |
3、命令存放在哪？
即命令的工作方式，官方支持 3 个位置：
| 位置 | 路径 | 作用域 |
|---|---|---|
| 项目命令 | .cursor/commands/ | 仅当前项目 |
| 全局命令 | ~/.cursor/commands/ | 你所有项目通用 |
| 团队命令 | Cursor Dashboard 配置 | 团队所有成员共享 |
💡 输入 / 时，Cursor 会自动扫描这三个位置并合并显示
4、Cursor Commands vs Rules 对比
（1）核心区别
| 维度 | Commands（命令） | Rules（规则） |
|---|---|---|
| 触发方式 | 手动输入 /命令名 | 自动生效，无需触发 |
| 作用时机 | 执行特定任务时 | 每次对话都生效 |
| 本质 | 任务模板 | 行为约束 |
| 类比 | 菜谱（做特定菜时看） | 厨房规章（始终遵守） |
（2）形象比喻：
Commands = 工具箱里的工具：需要拧螺丝时，拿出螺丝刀；需要锤钉子时，拿出锤子。按需取用，用完放回。
Rules = 公司规章制度：不管你做什么工作，都要遵守上下班时间、着装规范、安全守则。始终生效，贯穿全程。
（3）选择指南：
用 Rules：（1）希望 AI 每次都遵守某些规范（2）约束 AI 的行为方式（3）团队基础规范
用 Command：（1）需要执行特定任务时（2）定义具体工作流程（3）团队常用操作
一句话总结：
Rules = "你应该始终这样做"
Commands = "当我说这个词时，帮我做这件事"
二、如何创建和使用？
1、步骤一：创建目录和文件
你的项目/
└── .cursor/
└── commands/
├── code-review.md
├── write-tests.md
└── create-pr.md
2、步骤二：编写命令内容（纯 Markdown）- 示例： code-review.md
# 代码审查
请对当前代码进行审查，检查以下方面：
## 功能性
- [ ] 代码按预期运行
- [ ] 边界情况已处理
- [ ] 错误处理适当
## 代码质量
- [ ] 函数小而专注
- [ ] 变量命名清晰
- [ ] 无重复代码
## 安全性
- [ ] 无硬编码密钥
- [ ] 输入已验证
3、步骤三：使用命令
在聊天框输入 /，选择命令即可：
/code-review
三、带参数的命令
1、什么是"参数"？
参数 = 你在命令后面追加的额外文字。命令本身是一个固定模板，参数让你每次调用时可以传入不同的上下文信息。
2、工作原理
组合公式：最终发给 AI 的内容 = 命令模板内容 + 你输入的参数
图解：
┌─────────────────────────────────────────────────┐
│ 你输入：/commit 修复登录验证bug，关联 #123 │
└─────────────────────────────────────────────────┘
↓ 拆解
┌───────────┴───────────┐
↓ ↓
┌─────────┐ ┌─────────────────────┐
│ /commit │ │ 修复登录验证bug， │
│ (命令) │ │ 关联 #123 (参数) │
└────┬────┘ └──────────┬──────────┘
↓ ↓
┌─────────────────────────────────────────────┐
│ commit.md 模板内容： │
│ "请为当前更改生成规范的 commit message， │
│ 遵循 Conventional Commits 格式..." │
└─────────────────────────────────────────────┘
↓ 合并
┌─────────────────────────────────────────────┐
│ 最终发给 AI： │
│ "请为当前更改生成规范的 commit message， │
│ 遵循 Conventional Commits 格式... │
│ │
│ 用户补充说明：修复登录验证bug，关联 #123" │
└─────────────────────────────────────────────┘
3、具体示例
创建组件，命令文件： .cursor/commands/component.md
请创建一个 Vue3 组件：
- 使用 <script setup> + TypeScript
- 包含 props 和 emits 类型定义
- 添加基础样式
不同参数，不同结果：
| 输入 | AI 创建的组件 |
|---|---|
| /component 用户头像 | 用户头像组件 |
| /component 分页器 | 分页器组件 |
| /component 带搜索的下拉框 | 带搜索功能的下拉框组件 |
4、类比理解
| 类比 | 命令 | 参数 |
|---|---|---|
| 点外卖 | 选择"麻辣烫" | 备注：不要香菜，微辣 |
| 导航 | 选择"开始导航" | 输入目的地：北京西站 |
| Excel 函数 | SUM() | (A1:A10) |
5、参数最佳实践
（1）设计命令时预留参数位置
# 代码审查
请审查以下方面的代码：
- 功能正确性
- 代码规范
- 性能问题
**审查重点（如用户有指定）：** 请特别关注用户提供的额外说明。
使用时：
/code-review 重点检查 SQL 注入风险
（2）参数可以很长
/debug 用户反馈在 Chrome 浏览器上点击提交按钮后页面卡死，控制台报错 "Cannot read property 'map' of undefined"，
复现步骤：1.打开表单页 2.不填任何内容 3.点击提交
（3）参数可以包含文件路径、代码片段等
/refactor 请重构 src/utils/validate.ts 中的 checkEmail 函数，改用正则表达式实现
6、一句话总结：参数 = 命令的"个性化补充"，让固定模板能应对不同场景。
这里有一份我准备在日常开发需求中不断调试更新保存的命令模板，可以参考
# 需求变更代码审查
请对当前需求产生的代码变更进行全面审查。
## 审查维度
### 1. 功能正确性
- [ ] 代码逻辑是否符合需求描述
- [ ] 边界情况是否已处理
- [ ] 错误处理是否完善
### 2. 代码质量
- [ ] 命名是否清晰（变量、函数、组件）
- [ ] 函数是否职责单一、长度适中
- [ ] 是否存在重复代码可抽取
- [ ] 注释是否必要且准确
### 3. Vue 规范
- [ ] 组件拆分是否合理
- [ ] props/emits 定义是否完整
- [ ] 响应式数据使用是否正确
- [ ] 生命周期钩子使用是否恰当
### 4. 性能考量
- [ ] 是否有不必要的重复渲染
- [ ] 大列表是否考虑虚拟滚动
- [ ] 接口调用是否有防抖/节流
- [ ] 是否存在竞态条件（如连续搜索时，旧请求晚返回覆盖新数据）
- [ ] 是否有内存泄漏风险（定时器、事件监听未清理）
- [ ] 组件销毁时是否清理 DOM 引用和大对象
### 5. 安全检查
- [ ] 用户输入是否已校验
- [ ] 敏感数据是否妥善处理
## 输出要求
请按以下格式输出审查结果：
1. **问题列表**：按严重程度排序（🔴 严重 / 🟡 一般 / 🟢 建议）
2. **修改建议**：给出具体的改进方案
3. **优点总结**：肯定代码中的亮点
---
**请根据用户补充的需求说明，重点关注相关变更内容。**
浙公网安备 33010602011771号