看板 Soft_Job / Tech_Job ※ 圖文整理回首頁
[情報] Cursor Projects：關筆電還在做事的 coordinator
每個新 coding chat 都有隱藏稅：重講專案、重指檔案、重記上一個 agent 試過什麼。
Cursor Projects 瞄準這個交接問題——用一條持續對話，在背後協調工作。
Cursor Projects 瞄準這個交接問題——用一條持續對話，在背後協調工作。
一、核心：Coordinator，不是又一個寫 code 的 chat
官方說法：這個 agent 指揮其他 agents，自己不寫程式。Worker 在改 code 時，coordinator 仍可接收你的下一句指令——需求半路改了，仍走同一條 thread，不必為每個任務開新對話。
適用尺度：跨多個 PR 的功能、遷移、整包應用。「改一個 label」仍是小任務；跨 UI／service／tests 才是「一塊工作」。
二、雲端電腦＋共享脈絡
- 自己的 cloud computer：關筆電不中斷；要本機再叫 local agent。依賴／權限／環境問題不會自動消失。
- Shared context：研究、計畫、產物、測試教訓可跨 agent／機器延續——延續有用，前提是記得的東西還正確。
三、Subscriptions＝事件驅動
Coordinator 可訂閱排程、Slack、PR 活動等訊號：CI 掛了不必每次自己開聊。建議起步：窄目標＋可重現步驟＋修法必須通過的檢查，再人工 review。
四、官方例子與開跑前三問
- 遷移：同模式套很多檔，每批改完跑測——偏小批次＋檢查點。
- 維護：design system 專案審新 PR，從你的修正學習回饋迴圈。
影片強調：漂亮 demo ≠ 在你 codebase 可靠。放大前先問：
- 能不能看懂它的計畫？
- 能不能檢查／測試改動？
- 能不能看出何時要你介入？
並自行核對帳號定價與可用性——公告 alone 算不出你的成本。
五、一句話帶走
有趣的轉變：從管理一堆個別 chat，變成指揮一個持續的 project。
先給一小塊真實工作、檢查輸出，結果夠好再放大。你會先試功能、遷移，還是例行維護？
先給一小塊真實工作、檢查輸出，結果夠好再放大。你會先試功能、遷移，還是例行維護？
※ 原文：https://www.youtube.com/watch?v=S-cVvNmvgvY
※ 完整英文逐字稿：transcript.txt（84 段）
推 anon: coordinator 聽起來就是 PM bot
→ anon2: shared memory 過期才可怕
→ OP: 圖文整理自公開影片，非官方中譯／非評測