You don’t need ten agents. You need two tracks.

原始來源與檔名：2026-06-23T094135+0800-You don’t need ten agents. You need two tracks..md

NAPKIN | 餐巾纸

餐巾紙公式： Agent 開發產能 = Min(人類制定 Spec 的速度, Human 驗證與 UX 優化的速度) + Agent 實作速度

一句話： 在 AI Agent 輔助開發中，與其盲目追求多 Agent 平行處理，不如建立「規格 (Spec)」與「實作 (Implementation)」的雙軌工作流，由人類專注於高認知負荷的規格制定與 UX 驗證，Agent 專注於可自主的程式碼實作。

餐巾紙草圖：

[人類高注意力] 軌道1: 規格制定 (Spec Track) -> 功能發想 -> 系統架構 -> 實作計畫 (PRD)
       ↓ (交付上下文與計畫)                    ↑ (切換注意力，準備下一個規格)
[人類低注意力] 軌道2: 程式碼實作 (Implementation Track) -> Agent 自主寫 code -> (人類) Code Review / UX 驗證

ROUND 1: SKELETON | 骨架掃描

核心問題： 在擁有自主開發 Agent 的時代，為什麼平行跑 10 個 Agent 不能帶來 10 倍的產出？我們該如何最大化人機協作效率？

核心答案： 因為軟體開發系統的產出受限於「人類注意力」這個瓶頸（制定規格與驗證 UX）。應該採用雙軌開發模式（Dual-Track Development）：人類主導需要持續注意力的「規格軌道」，完成後將清楚的實作計畫交給「實作軌道」的 Agent 自主運行，同時人類再回頭處理下一個功能的規格。

論證結構與章節骨架：

1. 破除迷思：反對盲目平行運行多個 Agent 的假象。
2. 雙軌架構 (The two tracks)：
   • 規格軌道 (Spec track)：人類與 Agent 密集對話，產出 PRD 與技術架構設計，最終形成工程實作任務清單。
   • 實作軌道 (Implementation track)：Agent 根據完善的規格與計畫自主撰寫程式碼，人類僅需事後 Review。
3. 為什麼只需要兩個 Agent？：
   • 認知注意力分配：規格制定需要持續注意力，實作只需要偶爾反饋。
   • 瓶頸理論：產出速度受限於制定規格的人力。
   • 開發收尾的人力瓶頸：程式碼寫完不代表功能完成，還有 Code review, 測試, UX 調整。
   • UX 是主觀的，無法完全外包給 AI。
4. 目標受眾：獨立開發者 (Indie hackers)、一人全端開發者、技術創辦人。
5. 實踐與底層邏輯：這是敏捷開發、看板方法 (Stop starting, start finishing)、限制理論 (Theory of Constraints) 以及雙軌開發 (Dual-Track Development) 在 Agent 時代的自然演進。

ROUND 2: DISSECTION | 血肉解剖

隱形假設：

• 假設開發者本身具有判斷產品規格與系統架構設計的能力（Product decisions & Code）。
• 假設 Agent 在獲得完善的 Spec 與 Technical Design 後，能夠高度自主且正確地完成 80% 以上的程式碼實作。
• 假設程式碼是需要被長期維護的（非用完即丟的 Vibe coding）。

邊界條件：

• 適用於 Builder（掌握產品與技術決策的個體戶）。如果是在分工極度細化的大型企業中，PM 已經把 Spec 寫好，工程師可能可以平行開稍微多幾個 Agent 進行實作，但受限於 Code Review 依然不會是 10 個。
• 僅適用於需要長期維護的 Production Code。如果是寫完即拋的試驗性專案或短效腳本，直接用提示詞（Vibe coding）即可，無需嚴謹的雙軌流程。

ROUND 3: SOUL | 靈魂提取

知識連結：

• 限制理論 (Theory of Constraints)：系統產出取決於最慢的瓶頸環節（在這裡是人類制定規格與驗證的速度）。
• 看板方法 (Kanban)：Stop starting, start finishing（限制 WIP - Work in Progress），避免開啟過多平行任務導致認知過載。
• 雙軌敏捷開發 (Dual-Track Agile)：Marty Cagan 提出的 Product Discovery 與 Product Delivery 雙軌，完美對應到這裡的 Spec Track 與 Implementation Track。

深層洞見：

• AI 工具沒有顛覆軟體工程的物理法則。雖然寫程式碼的速度變快了，但「定義正確的問題 (Spec)」與「驗證最終體驗的主觀品質 (UX)」依然是硬需求，且完全依賴人類的認知與決策。
• 管理 AI Agent 就像管理初階工程師，給予模糊的指令會得到混亂的結果。高產出的秘訣不在於「雇用」更多 AI，而在於給予 AI 「更清晰、結構化的上下文與實作計畫」。

行動呼籲：

• 停止無意義的 Agent 數量軍備競賽。
• 專注建立一套標準化的「規格產生與架構設計」工作流（例如使用 Superpowers 等工具萃取 PRD 與計畫）。
• 將注意力聚焦在產品決策、使用者體驗與系統架構，讓 Agent 負責繁瑣的編碼勞動。

You don’t need ten agents. You need two tracks. (Architectural Deep Dive)

前言/背景

隨著 AI Agent 的興起，網路上充斥著展示平行運行 10 個 Coding Agent 的火力展示，暗示著「更多 Agent = 更快產出」。然而，對於實際打造生產環境軟體的開發者（如獨立開發者、技術創立者）來說，這是一個迷思。本文作者 Hugo Baraúna 透過自身開發 Elixir Radar 後台系統的經驗，提出了一套基於「雙軌 (Two Tracks)」的務實 AI 協作架構。

章節詳細總結

1. 雙軌工作流 (The two tracks) 作者將工作流拆分為兩個軌道：

• 規格軌道 (Spec Track)：這是一個高度需要人類注意力的過程。從一個功能靈感開始，人類透過與 Agent 的反覆對話、腦力激盪、並讓 Agent 閱讀現有程式碼，產出詳細的功能規格 (PRD)。接著，Agent 根據 PRD 產出技術架構設計，最後拆解成具體的「工程實作任務計畫」。
• 實作軌道 (Implementation Track)：將規格軌道產出的 PRD 與實作計畫丟給 Agent，讓其自主編寫程式碼。在此階段，人類不需要給予全神貫注，可以利用這個空檔開啟下一個「規格軌道」的作業。

2. 為什麼只需要兩個 Agent？ 作者提出四個核心原因，解釋為什麼 10 個 Agent 平行開發在現實中不可行：

• 注意力分配的需求差異：規格制定需要人類高頻互動與持續的注意力；而實作階段可以讓 Agent 自主運行。平行進行兩個「規格制定」對人類來說認知負荷過高，因此 1+1 (1 Spec + 1 Implementation) 是最適合人類認知頻寬的配置。
• 規格是第一個瓶頸：就算有 10 個實作 Agent，如果人類制定規格的速度跟不上，那些 Agent 也只能閒置。整個開發系統的產出速度受限於最慢的環節，即人類。
• 寫完程式碼不等於完工：即便 10 個 Agent 同時完成了 10 個功能的程式碼，後續的 Code Review、功能測試、整合驗證依然會全部塞車在人類身上。
• 無法外包的 UX 決策：好的產品體驗是主觀的，需要人類的主觀意見不斷微調。AI 可以寫出像素級的 UI，但無法代為決定什麼樣的 UX 體驗能感動用戶。

3. 目標受眾與邊界條件 這個框架最適合掌握「產品決策」與「程式碼」的 Builder (Solo devs, indie hackers, technical founders)。如果身處大型組織，且已有 PM 提供明確規格，或許可以容納多一兩個實作軌道，但也絕對達不到 10 個。此外，若程式碼只是用完即棄的（Vibe coding），則不需要這麼嚴謹的雙軌制。

4. 軟體工程理論的演進 這個做法並非憑空創造，而是傳統軟體工程理論在 Agent 時代的演化：

• 瓶頸理論 (Theory of Constraints / Queueing Theory)：系統速度取決於瓶頸（人類）。
• 看板方法 (Kanban)：“Stop starting, start finishing”，強調限制 WIP (Work in Progress)，完成手邊的工作再開啟新工作。
• 雙軌開發 (Dual-Track Development)：源自 Marty Cagan 等人提出的敏捷開發產品管理理念（Product Discovery vs Product Delivery）。

總結與結論

「You don’t need ten agents. You need two tracks.」深刻點出了目前 AI 輔助開發中的一個盲點：工具的升級並未改變軟體工程的本質。真正的瓶頸在於「弄清楚要解決什麼問題 (Spec)」以及「確保產品體驗良好 (UX)」。這篇文章為希望導入 AI 開發工作流的開發者與架構師提供了一個務實、符合人類認知極限，且奠基於經典系統思考理論的落地指南。最佳的 AI 協作模式不是最大化 Agent 的數量，而是最大化人類在「規格與驗證」上的專注力。