09 · Plan 模式

先想清楚再动手——Plan 模式是 Cursor 给你的”设计阶段”，让 AI 先做方案，等你批准再写代码。

01 为什么需要 Plan 模式

在之前的文章中，我们介绍了 Cursor 的四层 AI 能力：Tab 补全、Cmd+K 编辑、Chat 对话、Composer/Agent 自主执行。这四层有一个共同特点——它们都默认 AI 马上就开始动代码。

但现实开发中，有些场景你并不希望 AI 直接开写：

• 你还不确定方案对不对，想先讨论
• 架构级改动，影响面大，需要先评估
• 面对一个完全陌生的代码库，想让 AI 先帮你理解
• 实现成本高，想先确认方向再投入

在这些场景下，直接让 Agent 写代码有三个风险：

Plan 模式就是来解决这些问题的。 它把”思考”和”执行”拆成两个阶段：先让 AI 只做调研和方案设计，等你确认了，再让 Agent 去执行。

02 Plan 模式 vs Agent 模式：核心差异

Cursor 的 Chat（Cmd+L）有四个子模式：Ask、Debug、Plan、Agent。其中 Plan 和 Agent 是最容易混淆的两个。

通俗地说：

Agent 模式是”先干再说”——它拿到任务就开始干；Plan 模式是”先说再干”——它先输出方案让你审，你说 ok 它才动手。

这个区别在 Chat 面板里非常直观：用 Plan 模式时，AI 的回复有明确的”方案结构”——它分析需求、评估影响、给出方案清单，然后等你确认。

03 什么时候用 Plan 模式

场景 1：架构决策

你要给系统加一个”实时通知”功能。是用 WebSocket？Server-Sent Events？还是轮询？这个决策会影响到整个后端和前端的架构。

如果用 Agent 模式，它可能直接选一种它认为最合适的方案开写——也许写完了才发现方案不是你想要的。

用 Plan 模式，你可以问：

“我想给系统加一个实时通知功能。分析一下 WebSocket、SSE、轮询三种方案的优劣，考虑我们的技术栈是 Node.js + React，部署在 Kubernetes 上。”

AI 会输出一个方案对比表，包括每种方案的技术实现、复杂度、性能影响、维护成本。你看了方案，决定用 SSE，然后切换 Agent 模式让它实现。

场景 2：复杂多步骤功能

开发一个”用户邀请系统”——涉及邮件发送、邀请码生成、权限分配、过期处理。这种功能步骤多、分支多，AI 一旦方向偏了，后面整个都偏。

Plan 模式下，你可以让 AI 先输出一份完整的实现计划：

“设计一个用户邀请系统的实现方案，包括：邀请码生成、邮件发送、权限分配、过期处理。输出实现步骤、涉及的文件、每个步骤的依赖关系。”

拿到方案后，你可以：

• 检查有没有遗漏的功能点
• 确认每一步的方案是否合理
• 和 AI 讨论替换某个步骤的实现方式

等方案批准了，再让 Agent 按步骤执行。

场景 3：接手陌生代码库

你刚加入一个新项目，或者要修改一段很久以前写的代码。直接让 Agent 改代码，很可能改出 Bug——因为你（和 AI）都不够理解代码的上下文。

Plan 模式让你先问清楚：

“分析这个项目中认证模块的完整流程。告诉我：代码入口在哪、关键函数是什么、数据流是怎样的、有哪些边界情况处理。”

AI 会阅读相关代码，输出一份代码分析报告。你读完确认理解了，再动手改。

场景 4：评估改动影响面

修改一个 API 接口，它可能被多个前端页面、第三方 SDK、定时任务使用。直接改可能导致连锁报错。

“我要修改 /api/v1/user/profile 接口的返回格式。分析所有调用这个接口的地方，评估改动影响。”

AI 会搜索代码库中所有引用，列出影响面，甚至帮你识别哪些是不安全的改动点。

04 Plan 模式的工作流

Plan 模式遵循一个清晰的三个阶段：调研 → 方案 → 执行。

第一阶段：调研（Research）

AI 阅读项目代码，收集信息。它可能做这些事：

• 搜索相关代码（grep 搜索关键函数、接口定义）
• 阅读关键文件（读入口文件、配置文件、核心模块）
• 分析依赖关系（谁依赖谁、调用链）
• 检查现有实现（如果是要修改的功能）

这一阶段 AI 只读不写。你看到的是它在疯狂读文件，但不会有任何改代码的动作。

第二阶段：方案（Plan）

AI 输出结构化的实现方案。好的方案应该包含：

## 需求分析
- 明确了哪些需求
- 发现了哪些隐含需求（边界情况、错误处理）

## 实现方案
- 推荐方案 vs 备选方案
- 涉及的文件清单
- 数据结构/接口设计

## 实施步骤
- 步骤 1: xxx
- 步骤 2: xxx  
- 步骤 N: xxx

## 风险与注意事项
- 已知的边界情况
- 不建议的做法
- 需要手动确认的点

读完方案后，你可以和 AI 讨论、修改、补充细节。这个讨论的成本远低于等代码写完了再改方案的成本。

第三阶段：执行（Execute）

方案通过后，有两种执行方式：

方式 A：在同一对话中，切换到 Agent 模式，让 AI 按计划执行。 方式 B：用 Composer（Cmd+I）新开一个 Agent 任务，把方案内容粘贴进去，让它执行。

05 问好问题：Plan 模式的关键技能

Plan 模式的效果，直接取决于你的提问质量。这不是玄学——一个清晰的 prompt 和一个模糊的 prompt，输出质量的差距是巨大的。

不好的提问 vs 好的提问

好 Plan prompt 的模板

## 背景
[当前项目的技术栈、架构风格]

## 目标
[你要实现什么功能]

## 约束条件
[必须在框架内做什么？不能用什么？性能要求？兼容性要求？]

## 需要回答的问题
[你不确定的地方，让 AI 帮你决策的问题清单]

例如：

## 背景
项目是一个 Next.js 14 的 SaaS 应用，使用 Prisma + PostgreSQL，部署在 Vercel。

## 目标
实现一个多级审批流程：用户提交申请 → 主管审核 → 经理审批 → 最终确认。

## 约束
- 审批状态变更需要写操作日志
- 每个节点的审批人可以随时修改
- 不超过 5 级审批

## 需要回答的问题
1. 审批工单表应该和业务表分开还是合在一起？
2. 状态机怎么设计才能清晰且可扩展？
3. 通知机制用 WebSocket 还是轮询？为什么？

这样 AI 输出的方案才有针对性，有深度。

06 心智模型：Plan 模式是”白板阶段”

好，我们来建立 Plan 模式的心智模型。

在传统软件开发中，你在写代码之前会经历一个”白板阶段”——在文档、白板、或者笔记本上画架构图、写伪代码、推演逻辑。这个阶段的目的不是生成代码，而是理清思路。

Plan 模式就是 Cursor 给你的一块 AI 白板。 在这个白板上，AI 不是”写代码的工具”，而是”和你一起画设计图的搭档”。

区别在于：

• 传统白板上，你画，你看
• AI 白板上，你说，AI 帮你画，你审，你改

心智模型一句话：Plan 模式 = AI 驱动的架构师 + 代码分析师，在写代码开始之前。

这个模型帮你理解几个关键点：

• Plan 模式不用手写任何代码——它的输出是文本、是方案、是设计，不是 diff
• Plan 模式的核心产物是”理解”——你对方案的理解，AI 对代码库的理解
• Plan 模式不是在浪费时间——它是在降低试错成本。改一个方案可能花 5 分钟，改一套写错的代码可能花 5 小时

花在 Plan 上的每一分钟，都是为后面节省的一小时。

07 从 Plan 到 Agent：完整工作流案例

让我们看一个完整的例子。假设你要在一个电商项目中实现”购物车倒计时”功能——用户把商品加入购物车后，商品的价格只在 30 分钟内有效。

Step 1：Plan 模式做方案

在 Chat 中切换到 Plan 模式，输入：

“设计购物车倒计时价格保护机制。用户加购后商品价格锁定 30 分钟，超时后失效。需要考虑：

1. 后端如何记录和校验价格锁定
2. 前端如何展示倒计时
3. 超时后的处理逻辑
4. 极端情况：用户在最后一秒下单”

AI 读一遍项目代码后输出方案：

## 需求分析
...

## 推荐方案
- 后端：在 cart_item 表增加 price_locked_at、price_expires_at 字段
- 前端：用 useCountdown hook 实现倒计时展示
- 校验：下单接口校验 price_expires_at > now()

## 涉及文件
- prisma/schema.prisma（加字段）
- services/cart.ts（新增校验逻辑）
- components/CartTimer.tsx（新文件，倒计时组件）
- hooks/useCountdown.ts（新文件）
- pages/api/checkout.ts（改下单接口）

## 步骤
1. 数据库 migration
2. 后端价格锁定逻辑
3. 前端倒计时 hook
4. CartTimer 组件
5. 下单接口集成校验

## 风险
- 服务器时区问题
- 用户设备时间不准确（用服务器时间）
- 最后一秒下单的并发处理

Step 2：Review 方案

你看完方案后发现一个问题：方案没有涉及”加购时价格已经变化”的情况（比如用户加购后商品调价了，是按加购时的价还是当前价？）。

你和 AI 讨论后补充了这一项。方案更新完，你确认了。

Step 3：Agent 执行

确认方案后，你可以在同一个对话中切换到 Agent 模式，或者打开 Composer（Cmd+I）：

“按我们刚才确认的方案实现购物车倒计时功能。后端数据库 migration、服务层逻辑、前端组件按步骤来。”

Agent 会按方案中的步骤一步步执行。由于方案已经清晰，Agent 的执行效率很高，方向不会偏。

回头看整个过程：

Plan 模式：5 分钟讨论方案 → 发现 1 个遗漏问题 → 修正
Agent 模式：15 分钟完成所有代码

如果没有 Plan：
Agent 直接写 → 写到一半发现方案有问题 → 重来 → 30 分钟+

Plan 模式投入的 5 分钟，节省了至少 15 分钟的返工时间。

08 技巧与最佳实践

技巧 1：把 Plan 和 Agent 当作”思考-执行”循环

不要认为 Plan 和 Agent 是二选一的关系。最佳实践是把它们组合成一个循环：

对复杂步骤 → Plan（思考）→ Approved → Agent（执行）
                    ↑                      │
                    └── 发现问题，回到 Plan ──┘

每次 Agent 执行完一个步骤，如果发现新问题，切回 Plan 讨论，再继续执行。

技巧 2：利用 Plan 做代码审查

Plan 模式不只是做”功能方案”。你可以用它来做代码审查：

“Act as a senior code reviewer. Review services/payment.ts for potential bugs, security issues, and performance problems.”

AI 会在不修改任何代码的前提下，输出一份 code review 报告。

技巧 3：用 Plan 生成长篇文档

因为 Plan 模式不写代码文件，它的回复可以很长。如果你需要 AI 帮你写 API 文档、架构说明、设计文档，用 Plan 模式（或 Ask 模式）——它不会突然开始改代码。

技巧 4：先用 Plan 缩小上下文

面对大项目时，Agent 的上下文窗口容易爆。先用 Plan 模式让 AI 定位到相关的文件：

“在这个项目中，和用户通知相关的代码在哪些文件？列出关键文件和它们的职责。”

拿到准确的上下文后，再切换到 Agent 模式操作相关文件。这样 Agent 的上下文利用率更高。

技巧 5：在 Composer 中引用 Plan 的结论

Composer（Cmd+I）支持 @file 引用。你可以让 Plan 模式的方案输出到一个 markdown 文件中，然后在 Composer 中 @这个文件，告诉 Agent “按照这个方案执行”。这样可以保持 Plan 和 Agent 之间的上下文隔离。

09 Plan 模式的局限性

任何工具都有边界，Plan 模式也不例外：

10 小结

总结成一句话：

Plan 模式是 Cursor 给你的”刹车”——在这些 AI 疯狂输出代码的时代，有时候最珍贵的技能不是”让 AI 写得更多”，而是”让 AI 想清楚再写”。

下一篇：10 Agent 模式：从零到一的 AI 编程搭档 —— 让 AI 独立完成完整功能开发，从需求到代码到测试的全流程实战。