MultiAgent 在做什麼
MultiAgent 是一套偏 PM-led 的 agent team 範本。它不承擔正式專案工作區，也不是拿來塞程式碼的 repo，而是專門放流程、prompt、template、文件與範例。
在這套分工裡，RA 負責新專案需求訪談，CRA 負責既有專案的變更需求訪談，PM 負責主持與收斂，SA 與 SD 補齊規則與技術設計，最後再交給 PG 依規格實作。重點不是把角色切得很華麗，而是每個角色只處理自己該處理的責任。
為什麼先處理需求訪談
真的做過功能規劃的人，通常都知道最累的不一定是寫 code，而是前面那段大家以為自己講清楚、其實每個人腦中版本都不一樣的需求訪談。
使用者常說的是感覺，不是規格。像是「想做方便追蹤的系統」、「希望操作更直覺」或「讓 AI 幫我自動處理一部分工作」，這些都不算錯，但如果直接拿去設計系統，後面很容易一路補洞。
需求沒先收斂時，後面的開發很像拿便利商店微波便當去開會。外面看起來有熱，裡面其實還冷。
RA / CRA 為什麼有用
RA 與 CRA 的價值不是幫你把對話打成逐字稿，而是幫你把需求裡還沒想完整的地方挖出來。它們會追問產品目標、使用者、核心場景、資料欄位、範圍、驗收條件、邊界情境與限制，讓需求從口語想法變成可以交接的結構化資訊。
更重要的是，它們會主動補盲點。像是要不要登入、資料需不需要保存、是不是多人同時使用、哪些既有行為不能被破壞、驗收到底看結果還是連錯誤處理都要算進去。這些問題如果前面沒補，後面通常就會變成工程端邊做邊猜。
MultiAgent 的流程怎麼跑
新專案大致流程是：PM 先判斷需求是否清楚，如果模糊就先委派 RA 訪談；RA 整理成 ra-handover.md 後，PM 再整合 SA 與 SD 的分析，輸出 system spec、API spec、domain model 與 implementation plan，最後才交給 PG 實作。
既有專案增修則改成 CRA 先整理 change-request.md，再由 PM 做 impact analysis 與 implementation plan。這樣的順序很實際，先把需求收斂，再做設計；先把邊界講清楚，再談修改。
- 需求模糊時，先由 RA 或 CRA 對談收斂。
- 收斂結果落成可交接文件，而不是只留聊天紀錄。
- PM 依文件整合 SA / SD，補齊規格與風險。
- 文件夠完整後，再由 PG 進入實作與驗證。
這個設計適合誰
如果你是一人團隊，卻同時要切換 PM、分析、設計與開發幾種工作，這套流程會很有感。它也適合常常卡在需求講不清楚、結果後面反覆修改的人，或是想把 change request、spec、implementation plan 變成可重複工作流的人。
它提醒了一件很實際的事：很多時候真正該補的，不是再換一個更強的模型，而是先把需求結構處理好。
GitHub 從哪裡開始看
如果你想直接進 repo 看內容，可以先從這裡開始：
- GitHub Repository: tsod/MultiAgent
README.md：先看專案定位與放置規則。team-template/workflow/pm-team-workflow.md：看整體流程怎麼串。team-template/prompts/ra.md：看 RA 怎麼做需求訪談。team-template/prompts/cra.md：看 CRA 怎麼做既有專案變更訪談。team-template/docs/QUICK_START.md：想快速上手可先從這裡進。
如果你只想先抓主線，建議先看 README，再讀 workflow，最後補 RA 與 CRA prompt。這樣比較不會一開始就被文件量嚇到。
結語
MultiAgent 最有意思的地方，不是它用了幾個 agent，而是它承認了一件很真實的事：需求訪談才是很多功能開發真正的瓶頸。
當 RA 與 CRA 能先把邊界框住、把漏掉的情境補出來，後面的 PM、SA、SD、PG 才比較有可能接得穩。它不花俏，但很實用。尤其對常在需求模糊、規格反覆、修改連鎖反應裡打轉的人來說，這套設計不是幫你變魔術，而是幫你少走很多冤枉路。