---
title: "Agent、Plan、Ask、Debug、Tab 怎么分工"
description: "把 Cursor 的几类 AI 入口按风险和任务阶段分清，不把所有问题都丢给 Agent。"
verifiedAt: "2026-05-09"
---

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

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

## 1. 先给选择结论

最简单的判断：

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

```mermaid
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 从哪里被调用？”
- “这个错误可能来自哪些文件？”
- “先列出可能风险，不要修改。”

推荐 prompt：

```text
只读解释这段功能链路，不要修改文件，不要运行命令。
请输出入口文件、调用链、关键状态、潜在风险和建议下一步。
```

Ask 的验收不是 diff，而是你能不能根据它的输出决定下一步该 Plan、Agent 还是 Debug。

## 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 要给证据：

```text
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. 一个支付页改版的模式顺序

真实任务可以这样拆：

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

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

## 官方来源

- [Cursor Agent Help](https://cursor.com/help/ai-features/agent)：官方说明 Agent mode、Ask、Plan、Debug、review changes 和 interrupt Agent。
- [Cursor Plan Mode](https://cursor.com/docs/agent/plan-mode.md)：官方说明 Plan Mode 的研究、提问、计划、审查和 build 流程。
- [Cursor Debug Mode](https://cursor.com/docs/agent/debug-mode.md)：官方说明 Debug Mode 的假设、插桩、复现、日志分析和清理流程。
- [Cursor Tab Completion](https://cursor.com/help/ai-features/tab)：官方 Tab completion 帮助页。

## 接下来去哪

<Cards>
  <Card title="上一篇" description="理解 Agent 的 instructions、tools、model 和 checkpoints。" href="/docs/cursor/understanding/03-how-cursor-agent-works" />
  <Card title="下一篇" description="继续处理上下文、索引、Rules 和 AGENTS.md 的分工。" href="/docs/cursor/understanding/05-context-indexing-rules" />
  <Card title="官方 Plan Mode" description="查看官方重组页里的 Plan Mode 审查清单。" href="/docs/cursor/official/01-agent-workflow/12-plan-mode" />
</Cards>
