一個真實專案裡的 Cursor 工作流
把 Cursor 用在真實專案:只讀理解、計劃、小步修改、驗證、審查、沉澱規則。
真實專案裡的 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"]
逐步說明:
- Ask 只讀分析登入元件、auth API、路由和測試。
- Debug Mode 根據復現步驟新增最小 instrumentation。
- 使用者復現,Cursor 讀取 logs。
- Plan 寫出根因、修復範圍、驗證命令。
- Agent 只改登入元件和相關測試。
- Terminal 跑 focused test。
- Browser 檢查登入流程和 console / network。
- Agent Review 對本地 diff 做 Deep review。
- 人工審 diff,決定是否提交。
- 如果發現"不要改 auth schema"是長期邊界,寫入 Project Rule。
這個流程看起來比"一句幫我修"長,但每一步都有證據和停點。
9. 停止條件
出現這些情況就停:
- Agent 開始修改未授權檔案。
- 任務範圍從 2 個檔案擴到 20 個檔案。
- 測試失敗但 Agent 想跳過。
- 它修改測試來迎合錯誤實現。
- 需要生產金鑰、賬單、刪除、資料庫寫入。
- 其他人或其他 agent 正在同一檔案上改。
- 你看不懂 diff。
停止不是失敗。停止是把風險重新拉回可控範圍。
10. 最終交付清單
一個 Cursor 任務完成時,至少留下:
- 修改檔案清單。
- 關鍵實現說明。
- 已執行驗證。
- 未執行驗證和原因。
- 斷點 / UI 檢查結果。
- 剩餘風險。
- 若任務走的是 Cloud Agent,PR、artifacts、遠端桌面錄影也要進交付物。
- 是否沉澱 Rules / Skills / Hooks / Bugbot rules。
- commit 是否只包含本任務檔案。
官方來源
- Cursor Agent Overview:Agent tools、checkpoints、queued messages 和執行模型。
- Cursor Plan Mode:複雜任務先計劃再構建。
- Cursor Debug Mode:基於執行時證據定位 root cause。
- Cursor Agent Review:本地 diff 提交前 review。
- Cursor Browser Tool:Browser 截圖、console、network 和 UI 驗證。