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

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

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

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

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

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

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

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

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

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