Hacker News
The author shares a lightweight, manual setup using tmux and structured Markdown files called Feature Designs to orchestrate multiple AI coding agents in parallel. This system enables efficient context management and high-volume development by treating agents as specialized planners and workers within a terminal-based workflow.
AI 生成摘要
我分享了一套輕量級的手動設置，利用 tmux 和稱為功能設計（Feature Designs）的結構化 Markdown 文件，來同時協調多個 AI 編碼代理程式。這套系統透過在終端機工作流中將代理程式視為專門的規劃者與執行者，實現了高效的上下文管理與高產量的開發模式。
本文作者 Manuel Schipper 分享了他如何利用 tmux、Markdown 規範文件與自定義的斜槓指令，在不依賴複雜編排器的情況下，同時驅動 4 到 8 個 AI 編碼代理人（Coding Agents）。這套系統的核心在於將功能設計（Feature Design, FD）文件化，透過嚴格的生命週期管理與角色分工，讓 AI 能夠在明確的規格指導下進行並行開發。
針對這種大規模並行代理人的開發模式，Hacker News 社群展開了多維度的討論。部分參與者對其實際產出抱持懷疑態度，認為目前網路上充斥著 AI 影響者推銷開發工具的雜音，卻鮮少看到由這類系統產出的高品質軟體。對此，作者與其他開發者反駁指出，許多應用場景目前仍集中在企業內部工具或個人專案，例如自動化狀態儀表板、財務追蹤應用、甚至是用於 Wayland 的視窗合成器。這些專案往往是為了滿足特定需求或實驗性質，未必會公開發布，且開發者有時為了避免社群對 AI 生成內容的過度批評，傾向於不公開這些成果。
在技術實踐層面，社群對「上下文漂移」與「同步衝突」表達了高度關注。有開發者分享了類似的瀏覽器自動化經驗，指出當多個代理人在不同 tmux 視窗中運行時，隨著時間推移，各個視窗的會話狀態會逐漸脫節，導致代理人對專案現狀的認知產生偏差。雖然 Markdown 規格文件能提供一定的指導，但仍需要一個即時更新的「事實來源」文件來防止不同代理人以互不相容的方式解決同一個問題。此外，並行運行的成本也是一項考量，頻繁調用頂級模型不僅會迅速消耗 Token 配額，也容易觸及 API 的頻率限制。
關於人類開發者能管理的代理人上限，社群普遍認為 8 到 10 個已接近目前的認知極限。超過這個比例後，人類在決策品質與程式碼審查上的負擔將大幅增加。討論中也提到，目前的 AI 代理人在處理特定任務時雖然表現優異，但在判斷力與程式碼重用性上仍顯不足，常會出現重複造輪子或遺留廢棄程式碼的情況。因此，開發者必須建立詳盡的開發指南（Dev Guide）來彌補 LLM 的品味缺失。儘管如此，社群共識仍傾向於認為這類工具大幅降低了「從想法到實作」的門檻，讓原本需要數週的開發工作縮短至數天，即便產出的程式碼仍需人類細心把關。