AI 程式設計教程中文版
從原理到實戰

一個真實專案裡的 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"]

逐步說明:

  1. Ask 只讀分析登入元件、auth API、路由和測試。
  2. Debug Mode 根據復現步驟新增最小 instrumentation。
  3. 使用者復現,Cursor 讀取 logs。
  4. Plan 寫出根因、修復範圍、驗證命令。
  5. Agent 只改登入元件和相關測試。
  6. Terminal 跑 focused test。
  7. Browser 檢查登入流程和 console / network。
  8. Agent Review 對本地 diff 做 Deep review。
  9. 人工審 diff,決定是否提交。
  10. 如果發現"不要改 auth schema"是長期邊界,寫入 Project Rule。

這個流程看起來比"一句幫我修"長,但每一步都有證據和停點。

9. 停止條件

出現這些情況就停:

  • Agent 開始修改未授權檔案。
  • 任務範圍從 2 個檔案擴到 20 個檔案。
  • 測試失敗但 Agent 想跳過。
  • 它修改測試來迎合錯誤實現。
  • 需要生產金鑰、賬單、刪除、資料庫寫入。
  • 其他人或其他 agent 正在同一檔案上改。
  • 你看不懂 diff。

停止不是失敗。停止是把風險重新拉回可控範圍。

10. 最終交付清單

一個 Cursor 任務完成時,至少留下:

  • 修改檔案清單。
  • 關鍵實現說明。
  • 已執行驗證。
  • 未執行驗證和原因。
  • 斷點 / UI 檢查結果。
  • 剩餘風險。
  • 若任務走的是 Cloud Agent,PR、artifacts、遠端桌面錄影也要進交付物。
  • 是否沉澱 Rules / Skills / Hooks / Bugbot rules。
  • commit 是否只包含本任務檔案。

官方來源

接下來去哪

本頁目錄