Plan 模式——让 Agent 先想清楚再动手

AI 改飞一整个项目，往往不是因为模型不够聪明——是你没让它先说清楚要干什么。

你发一条需求，它立刻开始动：改这个文件、删那个函数、顺手重构了一段你没提到的逻辑。五分钟后你看结果，发现方向就不对。这时候你只能撤回——但它已经动了十几个文件，git diff 乱成一锅粥，撤也不好撤。

这是 AI 编程工具最常见的失控场景之一，根因不是工具问题，是工作流问题：没有给 Agent 一个"先规划再执行"的卡口。

Plan 模式就是这个卡口。

---

Plan 模式是什么，解决什么问题

Plan 模式的逻辑很简单：Agent 先输出一份执行计划，等你确认，再开始真正的操作。

没有 Plan 模式时，流程是：

你说需求 → Agent 立刻动手 → 你看结果（可能已经偏了）

有 Plan 模式时，流程变成：

你说需求 → Agent 出计划 → 你审计划（可以纠偏）→ 确认 → Agent 执行

多出来的那步"你审计划"，就是所有价值所在。

它能解决三类问题：

1. 方向偏差：你的需求描述有歧义，Agent 理解的不是你想要的。计划阶段你能看出来，比执行完再发现要便宜得多。

2. 范围膨胀：Agent 很爱"顺手"做它觉得好的事情，改着改着多动了一堆你不想动的地方。计划里你能看到它打算碰哪些文件。

3. 路径错误：它选了一个你觉得有问题的实现思路——比如用了你不想引入的库，或者绕路了。计划里指出来，比等它写完再推翻要省力得多。

简单说：Plan 模式让你花一分钟审计划，省去二十分钟修烂代码。

---

Claude Code 的 Plan 模式：怎么进入与使用

Claude Code 的 Plan 模式不需要额外安装或配置，直接在对话里触发。

进入方式

在 > 提示符后，把你的需求加上"先给我一个计划"或者直接说"不要执行，先 plan"：

> 我想把用户认证模块从 JWT 改成 session-based，先给我一个修改计划，不要动代码

或者更直接：

> plan: 把 src/auth 里的 JWT 验证逻辑替换成 express-session，列出要改哪些文件、改什么

你应该看到什么

Claude Code 会输出一份结构化的计划，类似这样：

Here's my plan for migrating from JWT to session-based auth:

Files to modify:
1. src/auth/middleware.js - 替换 verifyToken() 为 session 校验
2. src/auth/login.js - 把 jwt.sign() 改成 req.session.userId = user.id
3. src/app.js - 添加 express-session 中间件配置
4. package.json - 移除 jsonwebtoken，添加 express-session、connect-mongo

Files to create:
- src/auth/sessionConfig.js - session 配置和 store 设置

Files NOT touched:
- src/models/ - 用户数据模型不用动
- src/routes/ - 路由层不需要变

Potential risks:
- 现有已颁发的 JWT token 会立刻失效，需要告知用户重新登录
- 如果你的应用是多实例部署，需要配置共享 session store（如 Redis），否则负载均衡会出问题

Should I proceed?

注意看这份计划里的三个维度：要改什么、不动什么、潜在风险。一份好的 plan 应该三个都有。如果它只列了"要改什么"，你可以追问"会不会影响到其他地方"。

确认执行

计划没问题就直接回复确认：

> 可以，继续执行

想改计划就直接说：

> 先不移除 jsonwebtoken，先并行跑一段时间，加一个 feature flag 控制走哪套逻辑

它会更新计划，等你再次确认，才开始动。

---

Cursor 的 Plan 类机制

Cursor 没有一个叫"Plan 模式"的开关，但它的 Agent 模式和多步操作在一定程度上有类似效果。

在 Cursor 里触发规划行为

打开 Cursor 的 Composer（Cmd+I 或 Ctrl+I），切到 Agent 模式（右上角下拉选 "Agent"），然后这样说需求：

先不要动任何文件。我想把用户认证从 JWT 改成 session，你先列出你打算修改的文件和主要步骤，等我确认后再开始

你应该看到什么：Cursor Agent 会在 Composer 面板里输出一段规划文字，列出它打算操作的文件。还没有任何文件被修改，右侧不会出现 diff。

查看和确认改动

Cursor 的一个实用机制是每个文件改动都会单独展示 diff，你可以逐个 Accept 或 Reject，不需要全盘接受。这本质上是另一种"计划确认"——只不过是在执行过程中而不是执行前。

如果你已经让它开始执行，但中途发现方向不对，直接在 Composer 里说：

停，先不要继续。把你已经做的改动还原，我们重新规划

然后重新描述需求，这次说清楚边界。

---

一个真实例子：复杂需求从 Plan 到执行

场景：你有一个 Express + MongoDB 的博客后端，想加一个"草稿自动保存"功能。

第一步：发需求，要计划

> 我想给文章编辑页面加一个草稿自动保存功能，每 30 秒保存一次。先给我一个计划，不要动代码。要求：
  1. 不影响现有的"发布"逻辑
  2. 草稿不算发布，不出现在文章列表里
  3. 用户能看到"上次保存时间"

第二步：审计划——看这几个信号

收到计划后，重点检查：

信号1：它是否理解了"不影响现有发布逻辑"

如果计划里要改 createPost 或 publishPost 的主函数，要警惕——问它为什么需要改，逼它解释。

信号2：数据结构是否合理

草稿自动保存通常有两种方案：加一个 draft 字段到现有 Post 表，或者单独建 Draft 集合。两种方案各有取舍，计划里应该提到它选了哪种、为什么。如果它没解释，让它解释。

信号3：前端部分是否考虑到了

"上次保存时间"需要前端有一个轮询或者显示逻辑，如果计划只改了后端，忘了前端，现在指出来比等它写完后端再说要好。

第三步：纠偏

假设它计划里的方案是把草稿存在 localStorage（你不想这样），你直接说：

> 草稿要存到数据库，不要用 localStorage。用户换浏览器也能找回草稿。
  重新更新计划。

等它给出新计划，确认没问题再放行。

第四步：执行后验证

执行完，跑一遍你自己的验证：草稿保存了吗？发布流程还正常吗？文章列表里没出现草稿？

Plan 模式减少了偏差，但不是零风险——执行后你还是要检查。关于这套"指定→规划→实现"的完整工作流，见 SDD 规范驱动开发。

---

什么时候该用 Plan，什么时候直接干更快

Plan 模式不是万能药，用错地方反而拖慢你。

适合用 Plan 的场景：

• 需求涉及多个文件：改动在 3 个以上文件，用 Plan 能让你看清楚它的整体思路，避免遗漏或越界。
• 有明确的"不能碰"区域：比如"不影响现有 API"、"不改数据库结构"，这些边界条件需要在计划阶段显式确认。
• 需求描述有歧义：你自己也不确定怎么实现，Plan 阶段可以看它的方案再决定接受还是换思路。
• 高风险操作：删数据、改数据库 schema、动核心业务逻辑，先看计划再动。

直接干更快的场景：

• 改动明确且小："把这个函数的返回值从 string 改成 number"——范围清晰，不需要 plan。
• 探索性修改：你自己也不确定最终要什么，希望先看看效果再说，这时候直接让它改，看结果再迭代。
• 有完整测试覆盖：如果改了出错，测试会抓住，Plan 价值降低。
• 你已经非常熟悉这块代码：你自己能预判它会改哪里，就不需要它先汇报了。

经验法则：改动超过 3 个文件、或者需求里有"不能影响 XX"的边界条件，几乎一定值得先 plan。

---

故障排查表

症状	原因	解法
说了"先 plan"但它还是直接开始改文件	提示词不够明确，或 Agent 惯性	加更强的约束："在我回复'确认'之前，不要修改任何文件"
计划里列了文件，但执行时改了计划外的文件	Agent 执行中发现了"关联问题"自作主张	执行完用 git diff 对比计划；下次在提示词里加"只改计划里列出的文件，其他的告诉我再说"
给出的计划太粗，看不出它打算怎么做	需求描述太模糊，或你的约束条件没说	追问具体方案："列出每个文件具体改哪个函数、改成什么逻辑"
执行后结果和计划描述不一致	Agent 在执行中遇到了意外情况，偷偷换了方案	用 git log --oneline + git diff 复盘；大型任务考虑用 Subagent 分步执行
每次改都要 plan，效率感觉低了	Plan 模式用在了不该用的地方	参考上一节"什么时候直接干更快"，小改动不需要 plan

---

常见问题

Q：Claude Code 有没有一个正式的"Plan 模式"按钮？

没有专门的开关，是通过提示词控制的。效果和你怎么说有直接关系——"先给我一个计划，不要动代码"比"帮我改一下"能多出一个确认环节。Claude Code 的上下文管理细节见 上下文是一切：引用规则。

Q：计划批准了，执行过程中能打断吗？

可以。Claude Code 里随时按 Ctrl+C 中断；Cursor 在 Composer 里也可以手动停止。中断后用 git status 和 git diff 看它改了哪些，决定是回滚还是继续。

Q：Plan 模式和 CLAUDE.md 里写的规则有什么关系？

CLAUDE.md 是持久规则，每次对话都生效，适合写长期不变的约束（比如"永远不动 legacy 目录"）。Plan 模式是单次操作的确认机制。两个配合用：规则管底线，Plan 管具体任务的方向确认。关于如何写好 CLAUDE.md，见 上下文是一切：引用规则。

Q：需求很长、很复杂，Plan 会不会也写得乱？

需求越复杂，越要拆成小段喂给它。一个 1000 字的需求描述，Agent 很可能抓住的重点和你以为的不一样。拆分方法：先 plan 整体架构，确认后再 plan 每个模块的具体实现。分层规划，比一次性抛出全部需求效果更好。

---

增量提示：把"等待确认"写进项目规范

如果你有团队在用同一套 AI 工具，可以在项目的 CLAUDE.md 或者 Cursor 的 .cursorrules 里直接写死这条规则：

在执行任何涉及多文件的修改之前，必须先输出执行计划，等用户回复"确认"或"proceed"后才能开始修改文件。

这样不需要每次手动要求 plan，规则自动生效。SDD 规范驱动开发 里有这套工作流更完整的描述。

---

相关延伸：

• Claude Code 上手：第一个项目 — 如果还没跑通过 Claude Code，先看这里。
• 上下文是一切：引用规则 — Plan 模式的前置是喂好上下文，否则计划再详细也不准。
• SDD 规范驱动开发 — Plan 模式的进阶版：先写规范文档再 plan 再实现，适合大型功能。
• AI 编程工具全景 — 回到大图确认自己在哪个位置。
• 了解 Subagent 是什么——复杂任务可以拆成多个 subagent 并行处理，Plan 模式在这种场景下尤其重要。

---

👉 看看我们的 AI 编程实战体系课，或逛 AI 编程教程大全 把基本功打扎实。