Cursor 实战指南——Plan、Command、Rule 三大核心功能深度解析

一、Cursor 是什么？为什么值得学？

Cursor 是基于 VS Code 的 AI 开发环境，核心是让 AI 理解项目上下文并执行复杂任务。

与 ChatGPT/Copilot 的区别：

• ChatGPT：对话式，需要手动复制代码

• GitHub Copilot：代码补全，不执行命令

• Cursor：理解项目结构，可执行命令、修改文件、运行测试

适用场景：

• 快速理解遗留代码库

• 批量重构（如统一日志格式、添加错误处理）

• 跨文件功能开发（前后端联动）

• 技术债务清理（升级依赖、修复警告）

二、Plan、Command、Rule 是什么？

Plan（规划）

• 定义：让 Cursor 先生成任务分解/步骤清单，你确认后再让它按步骤执行，避免“一口气写完”带来的失控。

• 官方定位：用于复杂或多文件改动的“先计划后执行”模式，生成可审阅的分步计划。

• 关键点：

• 多步骤、可勾选/逐步执行。

• 适合跨文件改造、重构、大型功能开发。

• 计划可以被你修改或删减，再让 Cursor 按修改后的步骤执行。

• 失败/风险步骤可在计划里先标出，便于你把关。

Command（命令）

• 定义：在对话里用自然语言下达终端命令，Cursor 帮你转换并在内置终端执行。

• 官方定位：把“说明 → 命令 → 执行结果”串在一条对话链里，减少切窗口和手敲。

• 关键点：

• 支持串联命令、带参数、环境变量。

• 执行日志/错误会回到对话里，便于继续追问或修复。

• 高风险命令建议先让 Cursor 给出预览或 dry-run。

• 可与 Plan 结合：先计划，再让计划中的命令分步执行。

Rule（规则）

• 定义：给 Cursor 的上下文约束与风格/架构规范，让生成与修改遵守团队规则。

• 官方定位：把“开发规范、架构约束、代码风格、安全/合规要求”变成 AI 必须遵守的约束层。

• 关键点：

• 规则可放在 .cursor/rules/（官方支持加载规则文件）。

• 用清单式、可执行的约束（必须/禁止/示例），避免含糊表述。

• 可按场景分层：通用规则、领域规则、临时改造规则。

• 生成/改动时引用规则文件，让 Cursor 在回答中自检是否违反。

三、Plan、Command、Rule如何使用？

Plan的使用

首先你需要将Agent模式切换为Plan模式，然后在对话框描述你的需求，示例：

为订单模块添加“导出 CSV”功能，要求： - 后端：新增 GET /api/orders/export，校验日期区间，流式输出 - 前端：在订单列表页加“导出”按钮，调用新接口，提示成功/失败 - 测试：后端接口测试，前端交互测试 - 说明：列出涉及的文件路径，标注潜在风险点

AI的输出：

你可以自己调整或者让AI修改完善计划，确认无误后点击build执行，但是这个计划并没有本地持久化，因此当你需要和团队成员共享这个计划的时候你可以将这个计划持久化下来（比如一些共通性的工具之类的）

cursor会将文件保存在.cursor\plans下，项目中可以上传到git作为共享资源。

Command的使用

切换Agent模式，输入斜杠选择Create Command，cursor会在.cursor\commands下生成文件

在真实项目中，你可以让AI为你设计这些命名，尤其是经过反复多轮自然语言搞定一个问题的时候，你可以让AI将这个过程总结为一个Command，然后下次你可以直接艾特这个命令文件就不需要反反复复的去纠正AI了，同样可以跟你团队的成员共享这个命令。

Rule的使用

Rule 是项目约束，让 AI 生成代码时遵守规范，减少返工。

没有 Rule 的问题：

你：添加用户注册接口 AI：[生成了代码，但使用了项目禁止的库，命名不符合规范，缺少异常处理]

有 Rule 的效果：

你：添加用户注册接口 AI：[严格按照 Rule 生成：使用项目统一异常码、符合命名规范、包含完整测试]

Rule 文件结构

推荐在 .cursor/rules/ 目录下组织规则：

.cursor/ rules/ 开发规则.mdc # 总入口，说明如何获取规则 前端开发通用规则.mdc # 前端规范 后端开发通用规则.mdc # 后端规范 安全与合规.mdc # 安全要求 性能优化.mdc # 性能标准 代码评审清单.mdc # 提交前检查

Rule 编写实战

示例 1：后端开发规则

# 后端开发通用规则 ## 适用范围 - 项目：wikijs-mcp - 语言：Java 17 + Spring Boot 3.2 - 目录：server/** ## 必须遵守（违反将导致代码被拒绝） ### 1. 分层架构 - Controller 层：只做参数校验、调用 Service、返回统一响应 - ✅ 正确：`return Response.success(userService.createUser(dto));` - ❌ 错误：在 Controller 中写业务逻辑或直接操作数据库 - Service 层：处理业务逻辑，返回 DTO，不返回 Entity - ✅ 正确：`UserDTO createUser(UserCreateDTO dto)` - ❌ 错误：`User createUser(UserCreateDTO dto)` 或直接返回 Entity - Mapper 层：只做数据库操作，不写业务逻辑 - ✅ 正确：`List<User> selectByCondition(UserQuery query);` - ❌ 错误：在 Mapper 中做数据转换或业务判断 ### 2. 异常处理 - 使用项目统一异常码枚举，禁止硬编码字符串 - ✅ 正确：`throw new BusinessException(ErrorCode.USER_NOT_FOUND);` - ❌ 错误：`throw new RuntimeException("用户不存在");` - 所有 Service 方法必须声明可能抛出的异常 - ✅ 正确：`public UserDTO getUser(Long id) throws BusinessException` - ❌ 错误：不声明异常或使用通用 Exception ### 3. 日志规范 - INFO：记录核心业务节点（创建、更新、删除） - ✅ 正确：`log.info("创建用户成功, userId={}, userName={}", userId, userName);` - ❌ 错误：`log.info("进入方法");` 或 `System.out.println(...)` - ERROR：记录异常，必须包含 traceId 和上下文信息 - ✅ 正确：`log.error("创建用户失败, userId={}, error={}", userId, e.getMessage(), e);` - ❌ 错误：`log.error("错误", e);` 缺少上下文 ### 4. 数据库操作 - 只能通过 Mapper 访问数据库，禁止在 Service 中写 SQL - 批量操作使用 MyBatis Batch，禁止循环单条插入 - ✅ 正确：`userMapper.insertBatch(userList);` - ❌ 错误：`for (User user : userList) { userMapper.insert(user); }` ### 5. 事务管理 - Service 方法需要事务时使用 @Transactional - 只读操作使用 @Transactional(readOnly = true) ## 代码示例 ### Controller 示例ava @RestController @RequestMapping("/api/users") @RequiredArgsConstructor public class UserController { private final UserService userService; @PostMapping public Response<UserDTO> createUser(@Valid @RequestBody UserCreateDTO dto) { return Response.success(userService.createUser(dto)); } }### Service 示例 @Service @RequiredArgsConstructor @Transactional public class UserService { private final UserMapper userMapper; public UserDTO createUser(UserCreateDTO dto) throws BusinessException { // 业务逻辑 User user = convertToEntity(dto); userMapper.insert(user); return convertToDTO(user); } }

以上这些用法，可以参考我的开源项目，里面有很全面的模板。

https://gitee.com/huang_yang/ai-developed-scaffolding