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 審查清單。