---
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="/zh-Hant/docs/cursor/understanding/03-how-cursor-agent-works" />
  <Card title="下一篇" description="繼續處理上下文、索引、Rules 和 AGENTS.md 的分工。" href="/zh-Hant/docs/cursor/understanding/05-context-indexing-rules" />
  <Card title="官方 Plan Mode" description="檢視官方重組頁裡的 Plan Mode 審查清單。" href="/zh-Hant/docs/cursor/official/01-agent-workflow/12-plan-mode" />
</Cards>
