#Plan Mode

Plan Mode 在写任何代码之前先做一份可审的实现计划。Agent 会研究仓库、追问需求、生成你能改的计划，你点构建之后才动手。权威页：Plan Mode。

#怎么进入

在 Agent 输入框按 Shift+Tab 在模式间轮换（桌面里通常是 Agent / Plan / Ask）。也可以用模式下拉。输入里若带「复杂任务」类关键词，Cursor 有时会自动建议 Plan Mode。

CLI 与编辑器对齐：

agent --plan
# 或
agent --mode=plan

交互会话里用 /plan，或同样按 Shift+Tab。

#官方循环

1. 追问，把需求问清楚
2. 研究仓库，收集相关文件
3. 写出完整实现计划
4. 你在聊天里或 Markdown 文件中审阅 / 编辑
5. 准备好了再 Build

计划默认存在用户主目录。点 Save to workspace 可以挪进仓库，方便分享和以后对照。

flowchart TD
  A[Shift+Tab 进入 Plan] --> B[澄清问题]
  B --> C[搜索 / 阅读仓库]
  C --> D[可编辑的计划]
  D --> E{你批准吗?}
  E -->|否| B
  E -->|是| F[构建：改文件 / 跑命令]
  F --> G[审查 diff]
  G --> H{符合计划?}
  H -->|否| I[回滚 + 收紧计划]
  I --> F
  H -->|是| J[提交]

#什么时候用（什么时候别用）

官方适合：

• 有多种合理做法的复杂功能
• 会碰到很多文件或系统的任务
• 需求不清、需要先探范围
• 想先审架构再编码

快速上手或做过很多次的小改，直接用普通 Agent 即可。为改一行文案开 Plan Mode 只会增加往返。

经验法则：

#开场提示词

把完成定义和禁区写进去，这样问题会更具体：

Add a public /health JSON endpoint that returns { "ok": true }.

Constraints:
- Reuse the existing HTTP stack
- Do not change authentication
- Do not add a new framework

Ask me anything unclear. Research first. Produce a plan with:
- files you will touch
- test commands you will run
- risks

Do not edit files until I approve.

中文同样可以。计划应列出路径和命令；若只有形容词（「优雅地加健康检查」），把它打回去。

审计划时检查：

1. 文件列表是否过宽（「顺手重构 utils」）？
2. 测试命令是否是仓库里已有的脚本？
3. 迁移 / 特性开关是否写明了回滚？

把修改直接写进计划 Markdown，或回：Revise the plan: no new dependencies; add one unit test only.

#构建之后：从计划重来

实现偏了，不要靠叠十句「再改一下」：

1. 用 检查点 或 git checkout / git restore 回滚文件
2. 把计划改得更窄、更具体
3. 再点一次构建

官方认为这通常比修一条跑偏的 Agent 轨迹更快、更干净。难的是决定该改什么；计划对了，再把实现交给 Agent。

队列在 Plan Mode 里仍然有用：批准后入队 Then run the existing lint and typecheck only. 见 Agent。

#和规则、MCP 的关系

Plan Mode 会用 Available Tools，包括 MCP。研究阶段它可以读 issue、设计稿或文档，只要对应服务器已开。项目规则仍会注入——在 .cursor/rules 里写「超过 N 个文件必须先出计划」，比每次口头提醒稳。

团队：把计划 Save to workspace（例如 docs/plans/），PR 链到该文件。这比聊天记录更容易审。

#短练习

1. 打开任意仓库，Shift+Tab。
2. 粘贴 /health 提示词（按栈改名称）。
3. 回答澄清问题。
4. 确认计划还没有改业务代码。
5. 要么批准构建并审 diff，要么丢弃计划。

#下一步

• 与 CLI Agent 协作
• 实战案例
• 快速上手