跳到主要内容

Cursor 中的 Plan 与 Act 双模式代理工作流

Cursor Plan vs Act Modes

AI 编码代理最大的挑战之一是防止它们进行未经授权的更改。Plan 与 Act 双模式工作流通过在"计划模式"中要求代理提出更改建议，然后在"执行模式"中执行这些更改，从而解决了这个问题。本指南向您展示如何在 Cursor 中实现这一强大的安全模式。

什么是 Plan 与 Act？​

计划模式（只读）​

在计划模式中，代理可以：

  • 读取和分析代码
  • 以结构化格式提出更改建议
  • 不能修改任何文件
  • 为用户审查提供详细计划

执行模式（读写）​

在执行模式中，代理可以：

  • 仅执行已批准的更改
  • 具有完全读写访问权限
  • 遵循提供的确切计划
  • 报告已完成的工作

为什么要使用此模式？​

不使用 Plan/Act使用 Plan/Act
AI 意外更改文件所有更改都需要批准
难以审查更改内容首先呈现清晰的计划
回滚困难更改可追踪且可撤销
长时间会话中的上下文漂移每个任务专注执行

实现方法 1：Cursor 规则​

创建 .cursor/rules/plan-act-workflow.mdc：

---
description: 'Plan 与 Act 双模式工作流'
globs: ['**/*']
alwaysApply: true
---

# Plan 与 Act 工作流

## 关键规则
未经用户明确批准，您不得修改任何文件。

## 计划模式（默认）
当接到任务时：
1. 读取并分析相关文件
2. 创建包含具体更改的详细计划
3. 以以下格式呈现计划：

### 计划：[任务名称]

#### 要修改的文件
- `file/path/one.ts` - 更改内容
- `file/path/two.ts` - 更改内容

#### 更改摘要
1. 更改 1 描述
2. 更改 2 描述

#### 新文件（如有）
- `new/file/path.ts` - 用途

#### 测试计划
- 如何验证更改是否有效

4. 等待用户输入 "PROCEED" 或 "ACT"

## 执行模式（批准后）
仅在用户说 "PROCEED" 之后：
1. 按计划实施更改
2. 仅进行批准的更改
3. 报告完成情况及文件列表
4. 建议测试步骤

## 禁止事项
- 跳过计划阶段
- 添加计划外的更改
- 在计划模式中修改文件
- 每个计划要求批准超过一次

实现方法 2：自定义模式​

在 Cursor 设置中创建自定义模式：

  1. 打开 Cursor 设置（Cmd/Ctrl + ,）
  2. 导航到 "Modes" 或 "AI Features"
  3. 点击 "Add Custom Mode"
  4. 配置：
{
  "name": "Planner",
  "description": "计划模式 - 只读分析",
  "systemPrompt": "您处于计划模式。您可以读取文件但绝不能修改它们。分析代码库，理解需求，并提出详细计划。在做出任何更改之前等待用户批准。",
  "tools": ["read", "grep", "search"],
  "fileWrite": false
}
{
  "name": "Executor",
  "description": "执行模式 - 实施已批准的更改",
  "systemPrompt": "您处于执行模式。仅实施计划中已批准的更改。不要偏离批准的范围。在执行每个更改时进行报告。",
  "tools": ["read", "write", "edit"],
  "fileWrite": true
}

实现方法 3：基于聊天的工作流​

步骤 1：以计划模式开始​

[计划模式] 我需要为此应用添加用户认证。
请分析代码库并创建一个计划。
请勿进行任何更改。

步骤 2：代理呈现计划​

## 计划：添加用户认证

### 要修改的文件
1. `src/app.ts` - 添加认证中间件
2. `src/routes/users.ts` - 添加登录/注册端点
3. `src/models/user.ts` - 添加密码哈希

### 新文件
1. `src/middleware/auth.ts` - JWT 验证
2. `src/services/auth.ts` - 认证逻辑
3. `tests/auth.test.ts` - 单元测试

### 实施细节
- 使用 bcrypt 进行密码哈希
- 15 分钟有效期的 JWT 令牌
- 刷新令牌轮换

### 测试
- 使用有效/无效凭据测试登录
- 测试令牌刷新
- 测试受保护路由

步骤 3：审查和批准​

您审查计划，可以：

  • 输入 PROCEED 批准
  • 要求修改
  • 拒绝并重新开始

步骤 4：执行​

[执行模式] 继续执行认证计划。
准确实施已批准的内容。

步骤 5：验证​

执行后：

验证所有更改是否正确：
1. 检查认证中间件是否已应用
2. 测试登录端点
3. 运行认证测试

高级：自动计划解析​

对于复杂项目，使用结构化的计划格式：

## 计划 ID：AUTH-001
## 状态：待批准
## 优先级：高
## 预计时间：30 分钟

### 范围
- 添加基于 JWT 的认证
- 实现登录/注销/注册
- 添加密码重置流程

### 更改

#### 文件：src/middleware/auth.ts（新）
```typescript
import jwt from 'jsonwebtoken';

export const verifyToken = (req, res, next) => {
  // 实现
};

文件：src/routes/auth.ts（新）​

// 登录、注册、注销端点

文件：src/app.ts（修改）​

  • 第 15 行：添加 app.use('/auth', authRoutes)

回滚​

  • 删除：src/middleware/auth.ts
  • 删除：src/routes/auth.ts
  • 还原：src/app.ts 第 15 行

测试​

  • 使用有效凭据登录
  • 使用无效凭据登录
  • 没有令牌访问受保护路由
  • 使用有效令牌访问受保护路由

## 与版本控制集成

### 执行前检查点

在执行计划之前：

```bash
# 创建检查点分支
git checkout -b plan/auth-implementation

# 提交当前状态
git add -A && git commit -m "检查点：认证实现之前"

执行后验证​

# 审查更改
git diff

# 如果有问题，还原
git checkout -- .

# 或还原到检查点
git reset --hard HEAD~1

团队工作流​

代码审查​

  1. 开发者在 Cursor 中创建计划
  2. 开发者将计划粘贴到 PR 描述中
  3. 审查者在执行前批准计划
  4. 开发者使用 Plan 与 Act 工作流执行
  5. 审查者验证执行是否符合计划

PR 模板​

## 计划
[在此处粘贴 AI 生成的计划]

## 执行
- [ ] 所有计划更改已实施
- [ ] 无计划外修改
- [ ] 测试通过
- [ ] 计划与执行匹配

## 验证
[描述已执行的测试]

常见陷阱​

陷阱解决方案
代理跳过计划通过规则和模式限制强制执行
计划过于模糊要求具体的文件路径和行号
用户批准疲劳将相关更改分组为单个计划
执行偏离计划执行后比较 diff 与计划
来回过多允许微小偏差，标记重大偏差

快速入门清单​

  • 创建 .cursor/rules/plan-act-workflow.mdc
  • 用一个小而安全的任务测试
  • 验证代理遵守只读模式
  • 练习批准和拒绝计划
  • 在执行前设置 git 检查点
  • 为团队记录工作流

相关资源​