你不需要十個智慧體，兩條軌道就夠了

近年來，AI編碼代理的流行讓許多開發者開始嘗試同時執行多個智慧體以提升效率。然而，Hugo Baraúna在本文中提出了一種截然不同的觀點：你不需要十個智慧體，只需要兩條軌道。

他分享了自己構建Elixir Radar通訊後臺系統的實際工作流程。該系統用於策劃和組裝每期通訊、透過郵件平臺傳送，並允許客戶管理自己的贊助。在這個流程中，他只使用兩個智慧體，分別承擔規格定義和程式碼實現的任務。

第一條軌道是規格軌道。從模糊的功能想法開始，開發者與智慧體反覆討論。智慧體會閱讀程式碼庫以瞭解現有結構，並一步步引導開發者理清思路。最終產出一份完整的功能規格說明書（PRD）和技術設計方案。這個過程需要開發者全程參與，但產出物為第二條軌道提供了清晰的指導。

第二條軌道是實現軌道。智慧體根據規格文件自主編寫程式碼，開發者可以同時開始下一個功能的規格制定。當實現需要反饋時，開發者介入調整，然後繼續推進規格工作。這種交替迴圈避免了多智慧體並行帶來的管理複雜性。

Baraúna解釋了為什麼只使用兩個智慧體。他指出，多智慧體並行的核心瓶頸在於人的注意力。規格軌道需要持續的關注，而實現軌道相對自主。即使有十個實現智慧體，也只能一個一個地提交規格任務。此外，程式碼編寫完成後，還要進行人工程式碼審查、功能測試和UI迭代。這些環節無法完全自動化，因此並行化瓶頸環節以外的階段並不能提升整體速度。

他還強調，使用者體驗設計不能委託給智慧體。智慧體可以實現前端程式碼並連線到全棧，但構建優秀產品的主觀判斷和品味來自開發者自身，而非智慧體。

該工作流最適合“建造者型”開發者——那些同時掌握產品決策和編碼能力的人，如獨立開發者、技術創始人。對於開發團隊成員，即使有產品經理提供需求規格，仍需將規格轉化為技術設計，可能最多處理兩條以上軌道，但遠達不到十個。

Baraúna也指出，這種嚴謹的工作流適用於長期維護的程式碼；對於一次性實驗性專案，隨意編碼（vibe coding）就足夠了。為了驗證方法的實用性，他錄製了完整的工作流程影片，並展示了他使用的工具：Tidewave（Phoenix和Rails的智慧體開發環境）和Superpowers（用於建立規格和實現計劃的智慧體技能）。

最後，他反思了該方法的理論基礎：約束理論、排隊理論、看板方法中的“停止開始，開始完成”原則，以及產品管理領域的“雙軌開發”理念。他強調，新工具雖然強大，但已有的工程原理仍然適用，關鍵在於將其適應到智慧體開發的新環境中。