Cursor Plan 模式在做什么：计划这一步省下的是哪一部分

2026-08-18

先把问题问具体一点：你按了 Shift+Tab 切到 Plan，跟 Agent 来回聊了几轮，它给你出了一份实现计划。这时候磁盘上和会话里到底多了什么东西？这份东西在你点了「开始构建」之后，又是以什么方式作用于后面那一段真正写代码的过程？

这个问题值得单独问，是因为很多人把计划阶段理解成「让模型先想清楚再动手」——那是效果层面的描述，没法据此做任何工程判断。真正能拿来判断的是：产物是什么、存在哪、谁能读到、它能不能被改、改了之后走哪条路径。这几件事 Cursor 官方文档写了一部分，也有一部分没写，我们一条条对着文档过。

入口不止一个，而且各端的写法不一样

编辑器里的入口，官方文档 cursor.com/docs/agent/plan-mode 写明是从聊天输入框按 Shift+Tab 轮换到 Plan Mode，同一页还写明 Cursor 会在你输入「表明任务复杂」的关键词时自动建议这个模式。帮助中心 cursor.com/help/ai-features/plan-mode 把这一步拆得更细，并且分了平台：打开 Agent 面板时 Mac 按 Cmd + I，Windows/Linux 按 Ctrl + I，然后再用 Shift + Tab 循环模式直到 Plan。本站读者以 Windows 居多，这里别照着 Mac 的写法去按。

命令行侧是另一套。cursor.com/docs/cli/overview 的模式表里，Plan 这一行的入口写的是 Shift+Tab、/plan、--plan、--mode=plan 四种；cursor.com/docs/cli/reference/parameters 里 --mode <mode> 的取值说明是 plan 或 ask，不指定时默认是 agent，而 --plan 被标注为 --mode=plan 的简写。斜杠命令表里 /plan [prompt] 的语义是「切到 Plan 模式、显示当前计划，或者在 Plan 模式下提交一个 prompt」——注意它是三合一的，光看名字容易只当成切换命令。

agent --mode=plan
agent --plan

以上两行分别抄自 cursor.com/docs/cli/reference/parameters 与 cursor.com/docs/cli/using 中写明的参数语义，未经实测，以官方文档与 --help 的实际输出为准。

程序化调用还有第三套。TypeScript 与 Python 两份 SDK 文档都写明可以传 mode: "plan" / mode="plan" 来决定这一次运行是先探索出计划还是直接改代码；Agent.create() 上设置的 mode 用来给第一次运行铺底，后续 send() 不传就沿用会话当前模式，传了则只对这一次运行生效。Cloud Agent 的 API 端点文档里也有同名的 mode 字段，可选，默认值是 agent，plan 的说明是「先探索并起草计划，再进入编码」。这几处的字段名是一致的，这一点在跨端脚本里省事。上面提到的这些默认值（--mode 不指定时走 agent、SDK 与 API 的 mode 默认 agent）都是文档写明的默认值，随版本可能变动，也不等于「你跑起来一定是这个行为」，脚本里该显式传的还是显式传。

计划阶段本身：允许调外部工具

计划阶段不是「关起门来想」。cursor.com/docs/mcp 的「Using MCP in chat」一节写明，Cursor 会在相关时自动使用 Available Tools 下列出的 MCP 工具，并且明确写了这也包括 Plan Mode。也就是说，你接的 MCP 服务在计划阶段就可能被调用到——如果某个 MCP 工具带副作用，别以为「还在计划阶段所以什么都没发生」。同一页还写明 Cursor 默认会在使用 MCP 工具前请求批准。

流程本身，两份文档写的顺序一致：Agent 先提澄清问题、再调研你的代码库收集上下文、然后生成一份完整的实现计划。快速上手页 cursor.com/docs/get-started/quickstart 把最后一步写成「等待你的批准再构建」。CLI 更新日志里标注为 April 2026 的那一批改动中有一条写明「One question at a time」——澄清问题改为逐个呈现，并带一个自由填写的「Other」选项。

产物：一份可编辑的计划，默认不在你的仓库里

这是全篇最该记住的一句。两份文档口径一致：Plans are saved by default in your home directory，点 Save to workspace 才会把它移进工作区，用途写明是「日后参考、团队共享和文档化」。帮助中心那页补了一句形态描述：计划以一个 virtual file 打开，你可以读也可以改。docs 那页的说法是你可以「通过 chat 或 markdown 文件」来 review 和 edit 这份计划。

把这几句合起来读，能得出的结论只有这些：

计划是一份文本产物，可读可编辑，编辑入口有对话和文件两种
默认落点是 home directory，不在你的项目目录里，所以默认不进 Git、不进 code review、同事拉了分支也看不到
想让它进仓库、进团队，需要你主动做「Save to workspace」这一步

文档没有写明的部分同样要点清楚：计划文件的具体文件名、目录名、扩展名，有没有固定结构或 schema，多份计划怎么组织——官方文档没有说明这些。所以任何「计划会写到某某路径下的某某文件」的说法，都不要当成事实来用。

计划怎么约束后面的执行

帮助中心那页写明：对计划满意之后，点 Build 开始编码。CLI 更新日志里标注为 February 2026 的那一批写明「A persistent plan menu with Build Locally / Build in Cloud, and plan content transfers correctly to cloud agents」——一个常驻的计划菜单，两个落点分别是本地构建和云端构建，并且计划内容会正确传递给 Cloud Agent。同一份更新日志里标注为 April 2026 的一条写明 headless 侧的改进包括「plan mode works with -p」。

这些是文档能给到的全部。到这里必须停下来说一句：Build 之后计划以什么方式约束 Agent，官方文档没有说明这一点。上面这几页从头到尾没有写 Build 之后 Agent 是否被禁止偏离计划，也没有写执行阶段会不会拿计划去做校验。所以「有了计划就不会跑偏」不是文档给的保证，别把它当 guardrail 用。

这里还有两处文档措辞值得并排看一眼，因为它们指向的边界宽窄不一样。CLI 概览页的模式表里，Plan 这一行的描述是「Design your approach before coding with clarifying questions」，Ask 那一行才是「Read-only exploration without making changes」；而 ACP 文档 cursor.com/docs/cli/acp 的 Modes 一节里，三种模式被写成 agent（full tool access）、plan（planning, read-only behavior）、ask（Q&A/read-only behavior）——这一处把 plan 也标成了 read-only behavior。两处并排读，只能得出「文档在不同页面上对 Plan 的动作边界给的措辞不一致」这个结论，至于计划阶段到底能不能落盘改文件、这个 read-only 覆盖到哪一层，官方文档没有进一步说明。别替它补完。

真正被文档明确写成限制手段的是另外几样：Ask 模式那一行的 read-only 表述、参数表里的 --sandbox <mode>（取值写明为 enabled 或 disabled），以及 MCP 那一页写明的工具批准机制。文档里唯一带「不写代码」意味的补充手段，是 cursor.com/docs/cli/using 提示词一节里给的那个土办法：在 prompt 里直接写「do not write any code」，文档自述这样能确保 agent 不去编辑文件，并说这在实现前做规划时通常有帮助。这仍然是提示词层面的东西，不是权限层面的。

计划走歪了：官方给的是回退，不是修补

docs 页对这一步的建议很直接：Agent 建出来的东西不符合预期时，与其用追问一点点纠，不如回到计划——撤销改动、把计划改得更具体、重跑一遍，文档自述这通常比修一个跑到一半的 Agent 更快，结果也更干净。

帮助中心那页给了可操作的三步（以下按官方文档写明的说法转述）：在此前某条聊天消息的右下角找到 Revert 按钮，点击后按 Confirm 把文件回滚到那个阶段，然后细化计划再跑一次。Agent 总览页 cursor.com/docs/agent/overview 里的 Checkpoints 与这条路径配合使用：Agent 会在做重要改动前自动创建快照，捕获所有被修改文件的状态；同一页明确写了 Checkpoints 存在本地、与 Git 分开，只用来撤销 Agent 的改动，永久版本控制仍然用 Git。这句限定值得留意——回退能力是 Cursor 自己的，不要指望它替代版本控制。

docs 页还写了一句判断标准：改动越大，越值得多花时间把计划做精确、把范围划清楚，「难的往往是想清楚要做什么改动」。这是文档自述的理由，不是我们的推论。

什么时候不值得走这一步

两份文档给的适用场景一致，都是四条：多种可行方案的复杂功能、涉及很多文件或系统的任务、需求不清需要先探索才能确定范围、想先审一遍方案的架构决策。反过来，改动很小或者这类任务你已经做过很多遍时，直接用 Agent 模式就行——这句是文档自己写的，不是我们加的保留意见。

还有个容易被忽略的连带影响：团队分析页 cursor.com/docs/account/teams/analytics 在定义 Chats 这个指标时写明，它统计的是用户在聊天界面发出的消息数，括号里列的是「Agent, Plan Mode, Ask Mode, etc」。也就是说，计划阶段的那几轮澄清往返同样会计入这个指标。看团队数据时别把它当成纯粹的编码活跃度。

最后照例提一句：Cursor 迭代频繁，上面涉及的模式入口、参数名、按钮名与保存行为都随版本变动，动手前请以官方文档最新内容为准。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。