Agent、Plan、Ask、Debug、Tab 怎么分工

Cursor 的 AI 入口不是同一个按钮的不同皮肤。Ask（只读理解）、Agent（执行修改）、Plan（先审方案）、Debug（运行时排障）、Tab（局部补全）分别对应不同风险层级。模式选错，会直接放大返工和误改风险。

本章目标：你会按任务阶段选择 Cursor mode，并知道什么时候该停在 Ask，什么时候必须先进 Plan，什么时候切 Debug，什么时候只用 Tab。

1. 先给选择结论

最简单的判断：

看不懂代码：Ask。
知道要做什么，改动小：Agent。
范围大、路径不确定、影响多文件：Plan。
现象坏了但根因未知：Debug。
你正在手写局部代码，只需要补全：Tab。

flowchart TD
  Task["任务进入 Cursor"] --> Q{"根因和范围清楚吗"}
  Q -->|只想理解| Ask["Ask"]
  Q -->|清楚且小| Agent["Agent"]
  Q -->|不清楚且大| Plan["Plan Mode"]
  Q -->|运行时 bug| Debug["Debug Mode"]
  Q -->|正在局部编码| Tab["Tab Completion"]

不要把所有任务都推给 Agent。Agent 是执行入口，不是需求澄清、架构评审、运行时证据和局部补全的万能替代。

2. Ask：只读理解和风险评估

Ask mode 适合探索代码和提问，不适合写入。官方 Help Center 对 Ask 的定位就是不做改动地理解问题。

典型任务：

“解释这个目录的模块关系。”
“这个 API route 从哪里被调用？”
“这个错误可能来自哪些文件？”
“先列出可能风险，不要修改。”

3. Agent：小到中等范围的执行

Agent mode 适合你已经知道目标，并且能定义范围和验证方式的任务。

适合：

修单个组件 bug。
给已有函数补测试。
调整一个页面的 loading / empty / error state。
根据已确认方案补一个 API handler。

不适合：

需求不清楚。
改动跨太多模块。
涉及生产系统、账号、账单、密钥、数据库。
你不知道如何验收。

Agent prompt 需要写四件事：目标、范围、工具权限、验收方式。不要只写“帮我修一下”。

4. Plan：复杂任务前的刹车

官方 Plan Mode 文档说明，Plan 会先研究代码库、提出澄清问题、生成 implementation plan，让你 review 或 edit，再决定是否 build。

必须先进 Plan 的任务：

功能有多种实现路径。
改动会跨多个系统。
需要改架构、目录、状态模型或接口协议。
需求里有模糊词，比如“重构”“迁移”“完善”“商业级”。
你希望先评审文件范围和验证方案。

审查 plan 时看：

是否列出要改哪些文件。
是否说明不会改哪些边界。
是否给出测试、lint、build 或 browser 验证。
是否有回退策略。
是否把敏感数据写进计划。

Plan 默认保存到本地 home 目录；想让团队共享时，在 Plan 视图点 Save to workspace 把它移到 workspace 内并入 Git。

如果执行结果不对，不要只在偏掉的实现上继续追问。官方建议可以 revert changes，回到 plan，把 plan 写具体后再 build。

5. Debug：基于运行时证据排障

Debug Mode 适合“现象坏了，但不知道为什么”。官方 Debug 文档强调它会先生成假设、添加 instrumentation、要求你复现、分析 logs，再做 targeted fix。

适合：

race condition（竞态条件）。
timing issue（时序问题）。
memory leak（内存泄漏）。
performance issue。
只在特定浏览器、账号、数据状态下出现的 bug。
Agent 多次按猜测修不好。

关键概念：instrumentation（插桩） = 在代码里临时插日志、断点或观察点，让运行时行为可以被读取——是 Debug Mode 的基础。

Debug prompt 要给证据：

Debug 这个问题。Expected: [正确行为]。Actual: [错误现象]。
复现步骤：[步骤]。
错误日志：[粘贴日志]。
请先列假设和需要插桩的位置，等我确认后再修改。

Debug 的验收重点是：最终修复是否来自 logs、stack trace、runtime context，而不是 Agent 猜测。

6. Tab：你主导编码时的局部补全

Tab completion 适合你已经在写代码，只需要 Cursor 根据上下文补全下一小段。它不是完整任务代理。

适合：

补函数参数。
补重复结构。
补 import。
按上下文继续写 test case。
小范围重命名后的局部调整。

不适合：

设计整体方案。
跨文件重构。
修复根因未知的 bug。
涉及安全和生产边界的改动。

如果你发现自己连续用 Tab 接受大量跨逻辑补全，应该停下来改用 Ask 或 Plan，而不是一路接受——Tab 一次只看局部上下文，连续接受会让你跨过该用 Plan 整体审视的层级，最后改完 30 个文件才发现整体方向错了。

7. 一个支付页改版的模式顺序

真实任务可以这样拆：

Ask：只读解释支付页组件、状态、API、埋点和验证命令。
Plan：生成改版方案，列出文件、UI 状态、风险和测试。
Agent：只执行确认过的第一批小改动。
Browser / Debug：复现交互、看 console / network，定位运行时问题。
Tab：你手工调整样式时做局部补全。
Review：看 diff、跑测试、确认没有碰生产敏感逻辑。

这种顺序看起来慢，但它把风险分层了。商业级上线最怕的不是 Agent 慢，而是模式选错导致无关 diff 和假验证。

官方来源

Cursor Agent Help：官方说明 Agent mode、Ask、Plan、Debug、review changes 和 interrupt Agent。
Cursor Plan Mode：官方说明 Plan Mode 的研究、提问、计划、审查和 build 流程。
Cursor Debug Mode：官方说明 Debug Mode 的假设、插桩、复现、日志分析和清理流程。
Cursor Tab Completion：官方 Tab completion 帮助页。

接下来去哪

理解 Agent 的 instructions、tools、model 和 checkpoints。

继续处理上下文、索引、Rules 和 AGENTS.md 的分工。

官方 Plan Mode

查看官方重组页里的 Plan Mode 审查清单。