Cursor 是什麼

你是 Cursor 適用性診斷顧問，幫我判斷 Cursor 適不適合我手頭的活，以及該靠 Tab 補全還是 Agent。

【角色】
你清楚 Cursor 作為 AI 編輯器的定位、Tab 補全和 Agent 的區別、它和純補全工具及獨立 Agent 的差異，知道新手常見誤用。

【輸入】
- 我想用它做的事：___
- 我現在用什麼編輯器 / 工具：___
- 我更想要隨手補全還是讓它接管任務：___
- 我的專案和經驗：___

【工作流程】
1. 判斷這件事更適合 Tab 補全、Agent 還是別的工具
2. 說明 Cursor 在我的場景能帶來什麼
3. 指出最可能的誤用
4. 給一句話上手建議

【輸出規範】
▌一、適配判斷 + 理由
▌二、該用 Tab 還是 Agent
▌三、誤用提醒
▌四、上手第一步

【硬約束】
- 不適合的活直說，不硬推 Cursor
- 不誇大能力，不確定的標註需查官方文件
- 判斷結合我的具體描述，不給通用套話
- 提醒 Agent 接管任務時也要給清邊界
- 給的建議具體可執行，不空泛

Cursor 不是"在編輯器旁邊加一個聊天框"。官方文件把它定義為 AI editor and coding agent——一邊保留日常寫程式碼需要的編輯器、檔案樹、終端、Git、擴充套件，另一邊把 Agent、Rules、MCP（Model Context Protocol，模型上下文協議）、Skills、CLI、Cloud Agent 和團隊治理放進同一條開發閉環裡。

換種說法：它不是給現有 IDE（Integrated Development Environment，整合開發環境，如 VS Code / JetBrains 系列）加 AI 外掛，而是把整條 coding loop（程式設計迴圈：讀程式碼 → 改程式碼 → 跑命令 → 審 diff → 驗證）重排了一遍——原本散落在不同視窗的動作收斂到一個工作面。

理解這一點比記住按鈕位置更重要。因為 Cursor 的價值不在於"能不能生成程式碼"——這一點所有 AI 程式設計工具都能做到——而在於它能不能圍繞真實 codebase 做 plan、edit、run commands、review changes，並把結果交給你驗證。

1. 兩層身份：編輯器和 Agent

Cursor 的第一層身份仍然是 editor。你會開啟 folder、瀏覽檔案、安裝 extensions、跑 terminal、看 Git diff、除錯應用。對從 VS Code 或 JetBrains 遷移過來的人來說，這一層保證了基本開發工作面不會斷。

Cursor 的第二層身份是 coding agent。Agent 可以讀取上下文、搜尋程式碼庫、提出計劃、修改檔案、執行 shell commands、使用 browser 驗證 UI、呼叫 MCP servers，甚至把任務切到 Cloud Agent 或 Bugbot 這類雲端入口。

flowchart TD
  Cursor["Cursor"] --> Editor["AI Editor"]
  Cursor --> Agent["Coding Agent"]
  Editor --> Local["Files / Terminal / Git / Extensions"]
  Agent --> Context["Codebase Context"]
  Agent --> Plan["Plan Mode / Agent Mode"]
  Agent --> Tools["Tools / MCP / Browser"]
  Agent --> Review["Diff Review / Checkpoints"]
  Review --> Human["Human Approval"]

這就是它和普通 AI 外掛的關鍵區別：外掛通常增強某個入口（比如在編輯器里加一個 chat 面板），Cursor 試圖重排整個 coding loop——讓 Agent 自己讀專案、自己跑命令、自己看 diff，把人從資訊搬運工變成審閱者。

2. 不要從模型列表開始學

Cursor 支援多種 frontier models，官方模型頁也會頻繁變化。但教學學習順序不應該從“哪個模型最強”開始。

更穩的順序是：

1. 先學 Cursor 如何讀取 project context。
2. 再學 Agent 如何把任務拆成 plan、edits、commands 和 verification。
3. 然後學 Rules、MCP、Skills、Subagents、Hooks 如何約束行為。
4. 最後再按任務複雜度選擇 model、mode 和 budget。

模型決定能力上限，工作流決定結果能不能上線。只盯模型，很容易把 Cursor 用成一個更貴的聊天框。

3. Cursor 適合解決什麼問題

最適合 Cursor 的任務有三個共同點：目標明確、上下文在程式碼庫裡、結果可以驗證。

典型場景：

• 解釋一個陌生專案的入口、模組關係和執行命令。
• 修復一個有記錄、復現步驟或測試失敗的 bug。
• 給現有功能補 test、補 loading state、補 empty state。
• 在小範圍內重構重複邏輯，並跑目標驗證。
• 根據專案規範生成新元件、route、API handler 或 docs page。
• 對本地 diff 做 review，找潛在 regression。

不適合直接交給 Cursor 自主執行的任務：

• 生產資料庫 migration。
• 支付、認證、許可權、賬單、刪除、金鑰輪換。
• 沒有 Git、沒有測試、沒有人工 review 的大範圍重構。
• “全面最佳化一下”“商業級完善一下”但沒有拆分邊界的模糊任務。

4. 正確的任務閉環

在真實專案裡，一個合格的 Cursor loop 應該長這樣：

flowchart LR
  A["只讀理解"] --> B["定義邊界"]
  B --> C["Plan"]
  C --> D["Small Edit"]
  D --> E["Run Check"]
  E --> F["Review Diff"]
  F --> G["Keep / Revert / Iterate"]

每一步都有不同許可權：

• 只讀理解：Ask 或 Agent 只解釋，不修改檔案。
• 定義邊界：明確目標檔案、禁止動作、驗證命令。
• Plan：讓 Agent 先給方案，複雜任務用 Plan Mode。
• Small Edit：一次只批准能完整審查的改動。
• Run Check：跑 lint、test、build、browser check 或手工驗收。
• Review Diff：看真實 diff，不只看 Agent summary。
• 沉澱規則：重複出現的問題寫入 Rules、commands 或 team workflow。

5. 一個真例項子

假設專案裡登入頁提交後沒有跳轉。不要一上來寫“幫我修復登入問題”。更好的寫法是：

只讀分析登入流程。請先找登入頁、表單提交邏輯、認證 API、路由跳轉位置和相關測試。
不要修改檔案。輸出：
1. 可能根因
2. 需要看的檔案
3. 最小修復計劃
4. 建議驗證命令

這條指令把 Cursor 放在“理解現場”的位置。等你確認計劃後，再讓它只改最小範圍，並要求跑目標 test 或 browser 驗證。這樣 Agent 的能力會變成受控執行，而不是黑箱改動。

6. 學完本章要能做的判斷

你應該能回答：

• 這個任務更適合 Ask、Agent、Plan 還是 Debug？
• Cursor 需要哪些 project context？
• 允許它呼叫 terminal、browser、MCP 嗎？
• 結果用什麼 evidence 驗收？
• 出錯後用 checkpoint、Git diff 還是 branch 回退？

透過標準：你能把 Cursor 解釋成“editor 工作面 + Agent 執行層 + rules/tools 治理層”，而不是隻說“它能寫程式碼”。

官方來源

• Cursor Docs：官方文件首頁，覆蓋 Agent、Rules、MCP、Skills、CLI、models、Teams 和 Enterprise。
• Cursor Documentation Index：官方文件索引，用於核對 Agent、customizing、cloud agents、CLI、Help Center 等頁面。
• Cursor Documentation Markdown：官方定位與能力域。

接下來去哪