[情報] Cursor Projects：工作變成審查佇列

一、它實際是什麼

• Project：功能／遷移／整包 app 的長期工作容器。
• Coordinator：規劃與委派，自己不寫 code；可平行開實作 agent（雲端；本機測再叫 local）。
• Shared context：研究、產物、測試指令、團隊慣例跨機器同步——必須正確且更新。
• Subscriptions：訂閱 Slack／排程／PR，訊號來了就委派（週期 agent 本就有；Projects 把它收在同一 coordinator 下）。

二、商業後果：瓶頸變成審查佇列

共享脈絡可減少重複設定；Cursor 沒公布加速數字，beta 太新，別把「省下小時」寫進預算。

可量的變化是時間去哪：coordinator 可平行開多條實作，reviewer 仍串行讀 diff → 空 backlog 變滿 PR 佇列。窄任務＋可靠測試＋能快速裁決 → 有用；寬 diff／重複／意圖不清 → 變成昂貴庫存。

一人單任務可能幾乎沒感；測試弱／沒具名 reviewer 可能更亂；已在跑週期 Cloud Agent 的團隊，最大收益常是共享脈絡，不是觸發器本身。

三、四種情境怎麼用

• SaaS 遷移：明確非目標、測試、上線規則、邊界；量「被接受的改動＋審查時間」，不要量 agent 活躍度。
• Agency 客戶案：慣例／測試／交付規則放進該客戶 Project；客戶脈絡與憑證絕不可混池。
• Support 收 bug：公開 Slack＋嚴格資格（可重現才進）；目標是準備好的分支與證據，不是自動 merge。
• 平台例行維護：測試指令＋服務地圖放進 Project；合規團隊等安全審查涵蓋雲端 runtime／同步脈絡／secrets。

四、有限試點（六步）

1. 確認左側有 Projects、付費方案、團隊花費上限（再加週期觸發）。
2. 選一 repo、一類低風險可重複工作（有測試、小 diff、有人能判）。
3. 寫共享操作文件：地圖、setup、測試、DoD、禁區、升級規則——錯脈絡會更有效率地重複犯錯。
4. 加一條 intake（排程／PR／一個 Slack），寫清資格、可委派什麼、要交回什麼證據、何時必須停手。
5. 指定一位資深 reviewer；beta 期間合併權留在 Project 外。
6. 量：開工數、被接受改動、審查分鐘、重工、逃逸缺陷、模型用量——對照試點前同類型工作；勿把 agent 數當產能。

五、先把 review 編進預算

Teams Standard $40／人／月 → 四席 $160。Cloud Agents 依模型 API 計價；Teams／Enterprise 另有 Cursor Token Rate。文中假設模型：20 件工約 $12 用量 vs 審查約 $667（20×20 分、載重 $100/時）——重點不是這數字永遠對，而是 review 必須有自己的預算列。先 Standard、看 dashboard 實際用量，再談 Premium。

六、誠實部分＋本週怎麼做

• 仍是 beta：可見不等於採購文件齊全。
• 共享脈絡要有擁有者、覆核日、刪除規則。
• 產品契約＝交回給你查；不取代人工審查／測試／安全／合併權。
• 環境建不起＝沒有效證據；私網／合規要把邊界寫進審查。

※ 原文：https://omidsaffari.com/blog/cursor-projects-review-workflow
※ 圖文整理，非官方中譯；數字依原文假設模型，非發票預測