一個真實專案裡的 Cursor 工作流

📖 本篇術語速查表

英文 / 縮寫	中文	一句話解釋
工作流	workflow	真實專案裡串起各能力的用法鏈。
閉環	loop	從理解到驗證的完整迴圈。
習慣沉澱	habit	把跑順的用法固化下來。

不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你為一個真實專案設計一套順手的 Cursor 工作流。

你是 Cursor 工作流設計顧問，幫我為一個真實專案設計一套從理解到交付的順手工作流。

【角色】
你熟悉真實專案裡怎麼串起 Cursor 的 Tab、Agent、上下文、Rules、審查，形成穩定閉環。

【輸入】
- 我的專案型別和階段：___
- 我最常做的任務：___
- 現在用得彆扭 / 重複返工的環節：___
- 團隊還是個人：___

【工作流程】
1. 診斷目前用法的不順點
2. 按理解→規劃→執行→驗證串起工作流
3. 把長期約定沉澱進 Rules
4. 給把跑順用法固化的建議

【輸出規範】
▌一、目前不順點
▌二、串起來的工作流
▌三、該進 Rules 的約定
▌四、固化習慣的建議

【硬約束】
- 工作流可落地，不堆理論
- 長期約定進 Rules，不靠每次重複
- 驗證環節不能省
- 改動小步、可回復
- 不替我假設專案情況，不清先問
- 給的工作流具體可執行
- 給的每條結論都要落到具體可照做的步驟或示例，不停留在「建議」「考慮一下」這類沒法直接執行的空泛表述

真實專案裡的 Cursor 工作流不是"讓 AI 一次性做完"。商業級用法是一條可觀察閉環：讀現場、定邊界、寫計劃、小步改、跑驗證、看 diff、做 review、沉澱規則。

本章目標：你會把前面 11 篇串成一個可以直接落地的專案流程，並知道每一步用哪個 Cursor 入口、留下什麼證據、什麼時候停止。

1. 開始前：先看現場

不要在未知工作樹上直接啟動 Agent。

先確認：

目前分支是什麼。
git status 裡有哪些已有改動。
哪些改動不是你或 Cursor 做的。
任務允許修改哪些目錄。
驗證命令是什麼。
是否有其他人或其他 agent 同時在改。

如果有並行改動，任務 prompt 必須寫清“不觸碰某些路徑”。提交時也要精確 stage，不能 git add .。

2. 第一步：Ask 只讀理解

第一條 prompt 不要要求修改：

只讀分析這個任務，不要修改檔案，不要執行寫入命令。

目標：[描述問題]

請輸出：
1. 相關檔案和呼叫鏈
2. 目前行為
3. 可能原因
4. 最小修改範圍
5. 建議驗證命令
6. 風險和停止條件

這一步用 Ask 或 Agent 的只讀約束都可以。核心是先把專案現場從“感覺”變成“檔案、命令、風險”。

3. 第二步：Plan 先審方案

只要任務跨多個檔案、影響公共模組、涉及認證、支付、資料、許可權、部署、Cloud Agent、MCP 或 CI，就先進 Plan。

Plan 裡必須有：

改動目標。
涉及檔案。
不會改的邊界。
實現順序。
驗證命令。
回退方式。
需要人工確認的點。

如果 Plan 沒寫清這些，不要 Build。讓 Cursor 修改計劃，比在錯誤實現上修修補補更穩。

4. 第三步：Agent 小步執行

批准執行時，把範圍壓小：

按已確認計劃執行第一步。
只允許修改：
- src/components/LoginForm.tsx
- src/components/LoginForm.test.tsx

不要修改 package.json、lockfile、認證 schema、環境變數和路由設定。
完成後執行 pnpm test -- LoginForm，並輸出 diff 摘要。

小步執行的標準：你能完整審查這次 diff。如果 diff 大到看不完，就說明任務拆得不夠——遇到這種情況立即停下，把"改檔案 + 改測試 + 改型別"拆成 3 個獨立任務再繼續。

5. 第四步：Terminal 和 Browser 驗證

程式碼改完必須跑證據。

後端 / 庫程式碼常見驗證：

lint。
focused tests。
type check。
build。
migration dry-run。

前端 / 文件站常見驗證：

build。
本地預覽。
console error。
network error。
mobile / tablet / desktop viewport。
橫向 overflow。
長程式碼塊、表格、Cards、details、Mermaid。

Browser 驗證 prompt 示例：

啟動本地預覽，只開啟 localhost。
檢查這些 viewport：390、768、1024、1440。
重點看橫向溢位、導航遮擋、程式碼塊、Cards、details 和 Mermaid。
輸出 URL、viewport、問題和證據。

6. 第五步：Review 不只看總結

Cursor summary 只是索引，不是驗收。

提交前看：

git diff。
測試輸出。
build 輸出。
browser 檢查結果。
是否改了無關檔案。
是否引入格式化大面積重排。
是否碰了 secrets、憑據、生產設定、lockfile。

可以用 Agent Review 或獨立 verifier subagent（驗證子 agent，專責驗證已完成工作而不動手實現），但結論仍要回到 diff 和命令輸出。

7. 第六步：沉澱規則和流程

如果同一類問題反覆出現，不要每次重新靠 prompt。

沉澱方式：

一句長期約束：Project Rule。
多步流程：Skill。
獨立驗證角色：Subagent。
固定事件檢查：Hook。
對 PR 審查：.cursor/BUGBOT.md。
對團隊統一策略：Team Rules 或 dashboard controls。

沉澱標準：重複三次、邊界清楚、驗收明確、失敗可回退。

8. 一個完整登入模組例子

任務：登入後偶發不跳轉。

正確流程：

flowchart TD
  A1["1.Ask 只讀分析"] --> A2["2.Debug 加 instrumentation"]
  A2 --> A3["3.使用者復現 + Cursor 讀 logs"]
  A3 --> A4["4.Plan 寫根因和修復範圍"]
  A4 --> A5["5.Agent 只改登入元件 + 測試"]
  A5 --> A6["6.Terminal 跑 focused test"]
  A6 --> A7["7.Browser 檢查 console / network"]
  A7 --> A8["8.Agent Review 做 Deep review"]
  A8 --> A9["9.人工審 diff 決定是否提交"]
  A9 --> A10["10.沉澱 Project Rule"]

逐步說明：