2. Cursor 四大模式完全指南
很多人用 Cursor 效率不稳定，不是因为模型不够强，而是因为每一轮都用同一种方式交给 AI。只是想问清楚一段代码，却让 Agent 去读项目、跑工具、准备改文件；只是想改眼前一小段，却让它在整个仓库里找方案；真正要做跨文件功能时，又没有先把计划对齐，最后只能靠一轮轮补充 Prompt 修偏。
Cursor 的核心不是一个万能聊天框，而是一组不同放手程度的入口。新版 Cursor 的模式菜单里可以看到 Agent、Plan、Debug、Multitask、Ask 等选项，本文聚焦日常开发最高频的四个入口：Ask、Agent、Plan 和 Edit。前三个在右侧 Agent 面板里切换，Edit 最常用的入口是编辑器里的 Cmd+K。掌握这四个入口，才算真正开始按任务性质使用 Cursor。
1. 模式的本质
模式的本质是控制 AI 的权限和工作范围。Ask 适合只读理解，目标是回答问题，不主动改文件。Edit 适合局部修改，范围通常是你选中的代码或光标附近的上下文。Plan 适合复杂任务前的方案整理，先研究项目、生成计划、让你审查。Agent 适合明确目标后的执行，它可以读文件、改文件、运行命令、根据结果继续迭代。
把四种入口放在一条线上看，会更清楚：从只读到局部编辑，再到先规划，最后到自主执行。新手最容易犯的错，是把所有问题都直接丢给 Agent。Agent 能力强，但强不等于每次都该用。问清楚问题时用 Ask，精确改一小块时用 Cmd+K，复杂任务先走 Plan，目标明确后再交给 Agent，这才是 Cursor 的基本节奏。
2. 模式切换
Cursor 的 Agent 面板底部有一个模式按钮。点击它，可以看到当前可用的模式列表。官方 Plan Mode 文档也说明，可以从聊天输入框按 Shift+Tab 快速切换到 Plan Mode；实际使用时，模式按钮更直观，尤其适合新手确认当前到底处在哪个模式。
下面这张图是在本地 codex-tutorial-demo 项目里截的真实 Cursor 窗口。主编辑区打开 README.md，右侧是 Agent 面板，底部模式菜单展开后能看到 Agent、Plan、Debug、Multitask、Ask。这也说明一个现实情况：Cursor 版本在持续更新，菜单里可能出现更多模式，但本文讲的四个入口仍然是最基础、最高频的一组。
使用时先做一个小动作：输入 Prompt 前先看底部图标和模式名称。绿色对话气泡通常对应 Ask，紫色链环样式对应 Agent，橙色清单样式对应 Plan。如果当前模式不对，先切换再输入任务。这个动作很小，但能避免很多低级事故，比如本来只想问问题，却不小心让 Agent 进入可执行任务流程。
模式状态本身也是上下文的一部分。同一句 Prompt 放在不同模式里，Cursor 的行为边界会不同。放在 Ask 里，它更像代码阅读助手；放在 Plan 里，它会优先整理方案；放在 Agent 里，它会把任务理解成可以执行的工作；放在 Cmd+K 里，它会围绕当前选区改写。新手不需要记住所有快捷键，先养成发送前确认模式的习惯，就能避开大部分误操作。
切换模式后也不要急着立刻发送。先看当前文件是否对，选区是否对，右侧面板里是否还残留上一轮任务的上下文。如果你刚刚问过一个完全无关的问题，下一轮又要做项目改动，最好新开一轮更干净的对话，或者在 Prompt 开头重新声明目标和范围。Cursor 很擅长利用上下文，但上下文不干净时，它也可能把上一轮的假设带进下一轮。
还有一个容易忽略的点：模式菜单里出现的新能力不等于都适合写入基础工作流。比如 Debug 和 Multitask 可以在特定场景下提高效率，但小白刚开始学 Cursor，先把 Ask、Agent、Plan、Edit 四个入口用稳，比一次性记住所有菜单项更重要。基础入口稳定后，再理解细分模式会轻松很多。
3. Ask 模式
Ask 是只读问答入口。它适合理解代码、解释报错、讨论方案、做改动前的判断。你可以让它分析 README.md、解释一个函数、比较两个实现思路，也可以让它帮你把陌生项目的目录结构讲清楚。关键是 Prompt 里要明确本轮目标是分析，不要修改文件。
Prompt：
请只分析 README.md：这个项目当前怎么运行？不要修改任何文件。
这类 Prompt 里有两个重要信息。第一，指定分析对象，比如 README.md、package.json、某个目录或某段代码。第二，明确边界，比如 不要修改任何文件、只给出排查思路、先不要执行命令。Ask 的价值不只是安全，也能帮你在动手前把上下文补齐。
Ask 适合三类高频场景。第一类是读项目：让 Cursor 解释项目结构、启动方式、核心模块关系。第二类是读错误：把报错、日志、相关文件放进上下文，让它判断可能原因。第三类是做方案比较：比如问它本地状态该放在组件里、Context 里还是路由 loader 里。只要这一轮的产出是理解和建议，而不是文件改动，就优先用 Ask。
不要把 Ask 写成一句空泛问题，比如：
这个项目怎么样？这种问题太宽，Cursor 只能给泛泛介绍。更好的写法是：
请只阅读 README.md 和 package.json，回答三个问题：
1. 这个项目用什么命令安装依赖
2. 用什么命令启动开发环境
3. README 里有没有缺少新手容易踩坑的说明
不要修改文件，只给结论和建议。这类写法能让 Ask 输出更稳定，也为后续是否进入 Plan 或 Agent 提供判断依据。
Ask 的另一个实用价值，是帮你把模糊需求变成更清楚的开发任务。很多人一上来就让 Agent 写代码，其实真正的问题是需求还没整理好。比如你想给项目加一个登录页，不要直接说 帮我做登录页，可以先用 Ask 让它检查项目已有路由、UI 组件、状态管理方式，再让它给出需要确认的问题。
Prompt：
请只分析当前项目结构，帮我判断如果要新增登录页，需要先确认哪些信息。
请重点看：
1. 当前是否已有路由
2. 是否已有 UI 组件风格
3. 是否已有登录相关接口或 mock 数据
4. 这个需求适合直接 Agent 实现，还是应该先 Plan
不要修改文件，只输出判断依据和待确认问题。这种问法不会把 Cursor 推进执行阶段，却能把下一步要做什么讲清楚。对小白来说，Ask 常常不是用来问最终答案，而是用来补齐上下文、发现缺口、整理更好的下一轮 Prompt。
Ask 也适合做改动前的风险预判。比如你准备删除一个函数，可以先问它这个函数在哪里被引用；准备升级依赖，可以先问它哪些文件可能受影响；准备重构目录，可以先问它项目有没有路径别名或构建配置。只要问题本质是理解和判断，不是马上落地修改，都应该先用 Ask。
需要注意的是，Ask 的回答仍然要当成建议，而不是事实判决。涉及具体文件引用、命令、配置时，后续最好再让 Agent 读取文件或自己打开对应文件确认。Ask 帮你降低理解成本，但不能替代最终验收。
4. Agent 模式
Agent 是 Cursor 最强的执行入口。官方 Agent 文档把它描述为面向自主编码任务、终端命令和代码编辑的助手。它不是单纯回答问题，而是会围绕目标使用工具：搜索文件、读取文件、编辑文件、运行 shell 命令、检查结果，并把改动以 diff 的方式交给你审查。
Prompt：
请检查 README.md 和 package.json，判断这个 demo 项目的本地运行说明是否完整；如果缺少关键信息，给出要修改的文件和修改点。
Agent 适合目标明确、需要真正动手的任务。例如补充 README、本地修复一个测试失败、实现一个清晰的小功能、把重复代码抽成工具函数。它的优势在于能跨文件看上下文，也能在必要时运行命令验证结果。对于小白来说，Agent 最有价值的不是一次生成多少代码，而是它能把读文件、改文件、验证这三件事串起来。
但 Agent 不是越早用越好。任务越复杂，越要先把边界讲清楚。一个合格的 Agent Prompt 至少包含四个部分：目标、范围、限制、验收方式。
请帮我完善 README.md 的本地运行说明。
范围：
1. 只允许修改 README.md
2. 可以读取 package.json 确认脚本名称
3. 不要修改 package.json 和其他文件
要求：
1. 面向第一次打开项目的新手
2. 保留已有 Local Development 小节
3. 增加安装依赖、启动开发环境、运行测试三段说明
完成后：
1. 展示 README.md 的 diff
2. 说明你为什么这样改如果你直接写 帮我完善文档，Agent 会自己猜范围。它可能读很多文件，也可能加上你并不需要的内容。把范围和验收写清楚，Agent 才能在正确轨道上发挥自主能力。
Agent Prompt 的关键是让 Cursor 少猜。目标写清楚，决定它要做什么；范围写清楚，决定它能动哪里；限制写清楚，决定它不能做什么；验收写清楚，决定它完成后要用什么证据证明。只写目标不写限制，是新手最常见的失控来源。
可以把 Agent 任务拆成两种。第一种是小闭环任务，例如补 README、修一个明确报错、给一个函数补测试。这类任务可以直接让 Agent 做，但要限制文件范围和验收方式。第二种是探索任务，例如项目启动失败、不知道问题在哪、要做一个跨模块功能。这类任务最好先要求 Agent 只调查并汇报，不要第一轮就改文件。
Prompt：
请先调查这个项目为什么本地启动说明不完整。
本轮只允许：
1. 读取 README.md
2. 读取 package.json
3. 总结缺少哪些说明
本轮不允许：
1. 修改文件
2. 安装依赖
3. 运行长期占用的开发服务器
请输出你建议下一轮修改 README.md 的具体小节。这其实是把 Agent 当成会使用工具的研究员，而不是一上来就让它写代码。等调查结果清楚后，再开第二轮让它执行修改。复杂问题分两轮，通常比一轮大 Prompt 更稳。
Agent 执行后，要重点看三样东西。第一，看它改了哪些文件，是否超出你给定范围。第二，看 diff 里有没有风格突兀、重复解释、无关重构。第三，看它有没有运行你要求的验证命令，以及命令结果是否真的通过。Cursor 有 checkpoints 和 diff 审查能力，但这些能力只是给你回退和确认的入口，不能代替人工判断。
如果 Agent 做偏了，不要连续追加十几句纠偏。更稳的做法是先停止，回到问题本身：是目标没写清，范围没限制，还是验收没定义。把这三项补清楚，再让它基于当前状态修正，必要时回退 checkpoint 或用 Git 丢弃不需要的改动。Agent 越强，越需要你把边界写实。
5. Plan 模式
Plan 是复杂任务前的计划入口。官方 Plan Mode 文档说得很清楚：Plan Mode 会在写代码之前创建详细实现计划，Agent 会研究代码库、提出澄清问题，并生成一份可审查、可编辑的计划。它适合多个方案都可行、会触及多个文件、需求还不够清晰、或者涉及架构取舍的任务。
下面这个例子不是直接让 Cursor 改 README，而是先让它为 README 改动制定计划。重点在于底部已经切到橙色的 Plan 模式，Prompt 里也明确写了只生成计划，暂时不要改文件。
Prompt：
请先为 README.md 增加一段面向新手的本地运行说明制定计划：需要检查 package.json、现有 README 结构、要新增哪些小节；只生成计划，暂时不要改文件。
Plan 的价值是把纠偏提前。直接让 Agent 做复杂任务，问题往往在改完后才暴露：方向不对、范围太大、改动风格和项目不一致。Plan 模式先产出计划，你审的是步骤和范围，不是一堆已经落地的改动。发现不对时，只需要改计划，而不是回滚一批文件。
Plan 特别适合四类任务。第一，多文件功能，比如新增一个页面、接口和状态管理。第二，有迁移风险的改造，比如替换路由方案、拆分模块、调整目录结构。第三，需求不完整的任务，比如只知道要做一个后台管理页，但字段、权限、交互还没想清楚。第四，需要团队评审的任务，可以先把计划保存为 Markdown，再让同事看方案。
审 Plan 时不要只看它写得是否像样，要看五个具体点。第一，计划里列出的目标是否等于你的真实目标，有没有把需求扩大。第二，涉及文件是否合理，有没有动到不该动的目录。第三，执行顺序是否能逐步验证，而不是最后才发现跑不起来。第四，是否写了风险和回退办法。第五，是否有明确验收标准，比如需要跑哪个命令、检查哪个页面、确认哪段文档。
如果计划不合适，不要直接进入执行。你可以继续在 Plan 模式里要求它收窄范围：
Prompt：
这个计划范围太大，请收窄到只修改 README.md。
请保留：
1. 读取 package.json 确认脚本
2. 补充安装依赖和启动命令
3. 补充测试命令
请删除：
1. 新增示例代码
2. 修改 package.json
3. 调整目录结构好的 Plan 应该让你一眼看出接下来会发生什么。看不懂、太宽、太抽象，都不应该放行。特别是对零基础读者来说，Plan 模式最大的意义不是显得专业，而是把改动拆成能理解、能检查、能回退的步骤。
也不是所有任务都该 Plan。改一个错别字、调整一段 README 文案、补一行注释，用 Cmd+K 更快。Plan 的成本适合用在方向错误代价很高的任务上。判断标准很简单：如果 Agent 做错后你能一分钟内看懂并撤回，就不用 Plan；如果做错后你可能不知道哪里被改坏，就先 Plan。
6. Edit 模式
Edit 是局部编辑入口，最常用的操作是选中一段代码或把光标放在目标位置，按 Cmd+K，然后用自然语言说明怎么改。它和 Agent 的差异非常明显：Agent 会自己判断该读哪些文件、该动哪些地方；Edit 只围绕你当前选中的区域或光标附近内容做局部改写。
下面是在同一个 codex-tutorial-demo 项目中打开 README.md 后，用 Cmd+K 唤起的局部编辑输入框。左侧是项目文件树，编辑区能看到选中的 README 片段，输入框里是对选中内容的改写要求。
Cmd+K 适合三类小改动。第一，文字或注释润色，比如把 README 写得更适合新手。第二，局部代码改写，比如把一个回调改成 async/await。第三，小范围补充，比如给当前函数加错误处理、补一个边界判断、调整一段样式。它不适合让 AI 自己探索全项目，也不适合多文件任务。
写 Edit Prompt 时要短而准。你已经通过选区告诉了 Cursor 范围，Prompt 就专注说明目标：
把选中的说明改得更像新手教程，保留项目无害、只用于练习这层意思。如果你发现自己在 Cmd+K 里写了很多范围说明，比如要它读取多个文件、检查项目结构、运行测试，那就说明这个任务已经超出局部编辑，应该切到 Agent 或 Plan。
Edit 的使用质量，很大程度取决于选区。选得太少，Cursor 只能改一句话，可能缺少上下文；选得太多，它会在大段内容里重写，容易把你不想动的部分也改掉。比较稳的做法是只选中一个函数、一个段落、一个小组件、一个样式块。一个选区对应一个明确目标，不要在一次 Cmd+K 里同时要求润色文档、调整结构、补充命令和删除重复内容。
下面是几个可以直接套用的 Edit Prompt。
把选中的 README 段落改成新手能看懂的步骤说明，保留原有命令，不新增没有依据的命令。把选中的函数改成更清晰的写法，保持函数签名不变，不改调用方。给选中的代码补充必要的错误处理，不改变正常路径的返回值。这些 Prompt 都有共同点：范围来自选区，任务是单一动作，限制写得很具体。局部编辑的目标不是让 AI 自由发挥，而是让它在你圈定的区域内做一次高质量改写。
Cmd+K 改完后也要看 diff。局部编辑虽然范围小，但也可能误删注释、改变变量名、改掉原本的语气。文档类改动要看是否新增了没有根据的命令；代码类改动要看函数签名、返回值、异常路径是否改变。小改动不代表可以不验收。
7. 推荐工作流
四种入口不是互相替代，而是顺序配合。复杂任务最稳的节奏是：先用 Ask 或 Plan 想清楚，再用 Agent 执行，最后用 Edit 精修。
一个典型流程可以这样走。先用 Ask 问清项目当前状态，例如 README 里缺了哪些本地运行说明。发现只是小文本问题，就直接 Cmd+K 改掉。发现需要先确认 package.json、脚本名称、测试命令，就切到 Agent，让它读取相关文件并提出修改点。发现任务会影响多个文件，或者方案可能有争议，就先切 Plan，让它出计划，确认后再交给 Agent。
这套流程的核心不是慢，而是减少返工。Ask 降低理解成本，Plan 降低方向错误，Agent 提高执行效率，Edit 负责最后的局部细节。四个入口各管一段，Cursor 才不会变成一个难以控制的自动改代码黑盒。
放到一个真实工作场景里，可以这样组织。假设你打开一个陌生项目，想让 README 更适合新手。第一步用 Ask 读 README 和 package.json，只问当前说明缺什么，不改文件。第二步如果发现只是补几段说明，用 Agent 限定只改 README，并要求展示 diff。第三步如果 Agent 的文案有一段语气太硬，就在编辑器里选中那一段，用 Cmd+K 局部润色。第四步自己再检查命令是否和 package.json 一致，必要时运行一次测试命令。
如果需求变成给项目增加一个完整示例页，流程就不同。先用 Plan，让 Cursor 研究路由、组件结构、样式约定和数据来源，输出执行计划。你审完计划后，再进入 Agent 执行。执行完成后，看 diff、看终端验证、看页面效果。最后只对局部文案或样式用 Edit 精修。任务越复杂，越不能跳过计划和验收。
这种分工看起来比直接一句话让 AI 做慢一点，但它把风险拆小了。每一步只承担一个角色：Ask 只负责理解，Plan 只负责路线，Agent 只负责执行，Edit 只负责局部修正。出了问题也容易定位，到底是需求没问清、计划没审好、执行越界，还是局部编辑选区太大。
8. 模式选择
选择模式时，不要先问哪个模式更强，而要问两件事：这一轮是否要改文件，改动范围有多大。
如果不想改文件，只想理解、分析、讨论，用 Ask。如果要改文件，但只改眼前选中的一小块，用 Edit / Cmd+K。如果要改文件，任务清晰，可能涉及多个文件，用 Agent。如果要改文件，但任务复杂、方案不确定、影响范围较大，用 Plan 先把路线定下来。
可以把判断写成一个小表：
| 任务状态 | 推荐入口 | 原因 |
|---|---|---|
| 只想问问题 | Ask | 只读分析，不引入改动风险 |
| 只改选中区域 | Edit / Cmd+K | 范围最小，反馈最快 |
| 清晰的小功能 | Agent | 能跨文件读写并验证 |
| 复杂或不确定 | Plan | 先审方案，再执行 |
| Agent 做偏了 | 回到 Plan | 先修计划比追着补 Prompt 更干净 |
还有一种选择方式，是看你愿意承担多少不确定性。Ask 的不确定性最低，因为它不应该改文件；Edit 的不确定性也低，因为范围由选区控制；Plan 的不确定性体现在方案是否合理，但还没落地；Agent 的不确定性最高，因为它会真正读写项目并可能运行命令。越靠后，越要写清楚限制和验收。
新手可以用下面这组判断句快速自检：
我只是想知道为什么，先用 Ask。
我已经知道改哪里，用 Cmd+K。
我知道目标，但不知道要动哪些文件，先用 Plan。
我知道目标、范围和验收，交给 Agent。
Agent 做偏了，回到 Plan 或收窄 Prompt。不要被模式名字吓住。Cursor 的模式选择，本质是普通开发流程的拆分：读代码、定方案、改代码、验收。传统开发里这些步骤也存在，只是以前都由人自己完成；Cursor 把其中一部分交给 AI，但你仍然要决定什么时候读、什么时候计划、什么时候执行。
9. 验收回退
只会切模式还不够，真正决定安全性的，是执行后的验收。Cursor 的优势是能帮你快速改项目，但任何 AI 改动都要经过检查。尤其是 Agent 和 Plan 转执行后的任务，不能只看聊天区的一段解释就接受。
第一步看文件范围。改动列表里有没有出现你没有授权的文件，是否动到了配置、锁文件、自动生成文件、历史文档。对于小任务，文件范围越窄越好。如果你只要求修改 README，却看到 package.json、源码文件、配置文件都被动了，就要停下来逐个确认。
第二步看 diff 质量。文档改动要看命令是否有依据，步骤是否能照着执行，有没有把作者要求写进正文。代码改动要看函数签名、错误处理、边界条件、导入路径和类型变化。AI 生成的代码有时能跑，但风格可能和项目不一致；有时文案看起来顺，却加了不存在的命令或功能。
第三步看验证证据。如果任务里要求运行测试，就看终端输出是否真的运行了对应命令。如果任务是网页效果，就看本地页面是否真的打开检查过。如果任务是配置修改，就看配置文件格式是否正确，相关命令是否能读取。没有验证证据的完成说明，只能算 AI 自己认为完成，不能算你验收通过。
下面是这个 demo 项目里更完整的执行后状态。README 里已经能看到新增的 Local Development 小节，安装依赖、启动开发环境、运行测试三段命令都在文件中落地。读者真正需要看的不是聊天区一句完成说明，而是文件里到底多了什么内容。
如果任务要求验证，效果还要继续落到终端输出里。这个 demo 项目把 npm test 指向本地的 scripts/smoke-test.js，真实运行后输出 codex tutorial demo ok，这才说明 README 里写的测试命令至少在当前项目里能跑通。
回退也要提前想好。小范围 Edit 可以直接撤销或看 diff 拒绝；Agent 改动可以通过 Cursor 的 checkpoint 回到前一状态，也可以用 Git 查看和丢弃改动。真正做项目时，建议开始前先确认 git status 是干净的，至少知道哪些文件是本轮 AI 改出来的。这样 AI 做偏时，你不是靠记忆找改动，而是靠版本控制恢复。
一个实用习惯是把验收要求直接写进 Prompt。比如：
完成后请按这个顺序汇报：
1. 修改了哪些文件
2. 每个文件为什么需要修改
3. 是否运行了验证命令
4. 如果没有运行，原因是什么
5. 还有哪些需要我人工确认这样做不会保证 AI 永远正确，但会让它的汇报更容易检查。你也能更快发现缺口：它没跑测试、范围超了、解释含糊、还有待确认项。Cursor 的高效不是跳过验收，而是让执行更快、验收更清楚。
10. 常见问题
Q：新版菜单里有 Debug 和 Multitask，为什么本文还说四大模式？
因为本文讲的是新手日常开发最基础的四个入口：只读问答、局部编辑、先规划、执行任务。Debug 和 Multitask 也有价值，但它们是更细分的能力，不影响这四个入口的基本判断。
Q：什么时候不该用 Agent？
当你还没想清楚要改什么，或者只是想问问题时，不该直接用 Agent。先 Ask 或 Plan，能减少跑偏和无意义改动。
Q：Plan 会不会浪费时间？
简单任务会。比如改 README 里一句话，直接 Cmd+K 更快。但复杂任务先 Plan 往往更省时间，因为它把方向审查提前到了动手前。
Q：Ask 能不能读取项目文件？
可以读取上下文并分析，但它的定位是回答和讨论。你仍然要在 Prompt 里写清楚 不要修改文件，让本轮目标保持只读。
Q：Edit 和 Agent 的边界是什么？
看范围。你知道要改哪里，且只改一小块，用 Edit。你只知道目标，需要 Cursor 自己找文件、判断修改点、跑验证，用 Agent。
11. 小结
Cursor 的关键不是把所有活都交给最强模式，而是根据任务选择合适入口。Ask 负责理解，Edit 负责局部，Plan 负责方向，Agent 负责执行。四个入口的边界越清楚，Cursor 就越像一个可控的开发环境，而不是一个偶尔灵、偶尔乱的聊天框。
真正稳定的使用方式，是每次输入 Prompt 前先停一下：这轮要不要改文件，改多大范围，需不需要先定计划。这个判断一旦形成习惯，Cursor 的效率会明显稳定下来，代码改动也更容易被你掌控。
关注秀才公众号：IT杨秀才，回复：面试
