我後悔教朋友用多 AI Agent 協作了

上週我把自己在用的「多 Agent 協作框架」教給了一個朋友。這個框架讓 Claude、Codex、Gemini 各司其職——Claude 當架構師、Codex 當工程師、Gemini 當分析師，人類當主席（Chair），最終拍板決策。

聽起來很美好。結果一週後，我收到了一份「架構升級方案」：5 層系統架構圖、8 個風險矩陣、4 個開發階段、15 個整合需求。

文件寫得非常漂亮。結構完美，風險面面俱到，每一層的職責劃分清晰得像教科書。

但是提出這份方案的人，連產品的第一個功能都還沒用過。

AI 是決策放大器，不是決策替代品

我回頭看了那份文件的產出過程——他把需求丟給 Claude，Claude 召集 Codex 審架構、Gemini 分析風險，三個 Agent 你來我往討論了一輪，產出一份滴水不漏的方案。

問題是：沒有一個判斷是人自己做的。

AI 做的每一件事都很「對」——列風險是對的、考慮 edge case 是對的、規劃分階段也是對的。但「對」跟「該不該現在做」是兩回事。

同一天，我用同樣的框架，從零開始建了一個 RAG Gateway——設計、實作、部署、灌入資料、寫使用手冊，全部在一個 session 內完成。用了同樣的 Claude、Codex、Gemini。

差別在哪？

我至少做了五次「喊停」的判斷：

• Agent 建議做 async job queue → 我說先不要，MVP 夠用
• Agent 建議做 client_id 強制化 → 我說 42 筆資料不需要
• Agent 建議做 Remote MCP → 我說 Swagger UI 就好
• Agent 建議用便宜的 Flash 模型 → 我說不行，品質優先
• 對方提了 15 個整合需求 → 我說大部分現在不需要做

每一次喊停，都不是 AI 能替我做的。因為 AI 不知道：

• 這個團隊有幾個人在用
• 資料庫裡才 42 筆資料
• 使用者連第一次搜尋都還沒做過
• 花兩週開發不如花兩小時先試用

AI 會幫你把任何方向都做到完美，但選方向是你的事。

比框架更重要的是：你什麼時候說「夠了」

多 Agent 協作是強大的工具。我自己每天都在用，它確實讓我的生產力翻了好幾倍。

但它有一個危險的副作用：讓人誤以為「讓 AI 討論得夠充分」就等於「想清楚了」。

沒有。

Claude 幫你列了 8 個風險，不代表你理解這些風險。Codex 幫你審了架構，不代表你認同這個架構。Gemini 幫你分析了 3 個方案的利弊，不代表你知道該選哪個。

真正的判斷力來自：

• 你親手用過這個產品
• 你跟使用者聊過
• 你踩過坑，知道哪些問題是真的、哪些是想像的

這些都不是 AI 能替你做的。

先做一份報告，再談架構升級

我最後跟他說的話是：

「先挑一個品牌，手動跑一份完整報告。做完之後告訴我哪一步最卡。」

不是因為我不重視架構，而是因為——

在你連 v0.1 都沒跑過的時候，任何架構設計都是在替想像中的問題找解法。

PoC 的價值不是「證明技術可行」，而是「讓你親手摸到真正的問題」。

那份漂亮的架構升級方案裡列了 8 個風險。我敢打賭，實際跑完一輪之後，真正的痛點不在那 8 個裡面。

結論

如果你也在用多 AI Agent 協作，記住一件事：

Agent 是用來加速決策的，不是用來延遲決策的。

當你發現自己讓 3 個 Agent 討論了半小時，產出了一份 20 頁的方案，但你自己一行 code 都還沒跑過——停下來。

關掉那個對話。

打開終端機，跑你的第一個 PoC。

跑完之後你會知道，那 20 頁裡面有 18 頁是不需要的。

而剩下那 2 頁，你根本不需要 AI 幫你寫。

作者：江中喬（Maki Chiang）— 91APP 廣告業務部 AI PoC Lead。每天用 Claude Code + 多 Agent 協作開發產品，相信 AI 是最好的加速器，但方向盤必須握在人手上。