管理 AI 跟管理人一樣難：我用 TPM 思維治理四個 AI Agent

所有人都在教你怎麼裝 multi-agent 工具，沒人教你管 AI 團隊。我用十年 TPM 經驗學到的三件事：角色邊界、交叉 review、停損機制。

兩個月前我第一次讓四個 AI 同時幫我寫一個功能。Claude 負責拆任務、Gemini 查技術文件、Codex 寫程式碼，我負責拍板。聽起來很美好，結果是一場災難。

Claude 拆出來的架構，Codex 寫到一半發現行不通。Gemini 查到的最佳實務跟 Claude 的設計互相矛盾。三個 AI 各說各話，我花了整個下午在當翻譯和仲裁者。那天我寫了不到 50 行有效的程式碼。

回頭看，問題很眼熟。這跟我十年前當 TPM 的第一週一模一樣——丟三個工程師進同一個功能，沒給明確分工，結果每個人都覺得整個功能是自己的。

所有人都在教你裝工具，沒人教你管團隊

打開 GitHub 搜 "multi-agent"，滿坑滿谷的 orchestrator 框架。VS Code 原生支援了、Warp 也支援了、開源工具一堆。技術門檻已經低到複製貼上就能跑。

但跑起來之後呢？

你會遇到的問題跟工具無關：AI 之間結論衝突的時候聽誰的？某個 AI 開始在同一條錯誤路徑上打轉怎麼辦？兩個 AI 同時改同一個檔案，邏輯撞在一起怎麼收拾？

這些問題，沒有任何框架幫你解決。因為這根本不是技術問題，是管理問題。

做了十幾年 TPM，管過從三人到三十人的工程團隊。踩過的坑夠多之後，有些原則會變成直覺。我發現這些直覺，直接拿來管 AI 團隊竟然也適用。

帶過團隊的人都知道，三個資深工程師丟進同一個 feature，如果沒有事先分工，產出會比一個人還少。因為每個人都有主見，每個人都覺得自己的架構比較好。

AI 也一樣。你讓 Claude 和 Codex 都去「寫程式碼」，它們會寫出兩個完全不同方向的實作，然後你得花時間合併。你讓 Gemini 去「幫忙看看」，它會給你一堆建議，但你不知道哪些該聽、哪些只是它在自由發揮。

我後來給每個 AI 劃了明確的邊界：誰負責拆解、誰負責調查、誰負責動手寫、誰負責 review。就像帶團隊一樣，角色清楚了，衝突自然少了。

具體怎麼劃？這跟你的工作流有關，我還在迭代。但原則是一樣的：一個任務在同一時間只有一個 owner，其他人是 reviewer 或 advisor，不是共同 owner。

這大概是軟體工程最基本的共識。但大多數人用 AI 的方式，就是讓 Claude 寫完之後，再叫 Claude 自己 review。

這等於讓學生自己改自己的考卷。

更麻煩的是，同一個模型有相同的認知偏差。它寫程式時犯的盲點，review 時依然看不到。數據顯示，即使最好的模型幻覺率也有 17%。你讓同一個模型寫加 review，這 17% 不會因為多跑一次就消失。

我現在的做法是讓不同的 AI 互相 review。A 寫的東西讓 B 看，B 寫的讓 A 看。就像 code review 本來就該跨人做一樣。

聽起來理所當然，但你回想一下自己的工作流程——你有多常讓同一個 AI 既寫又審？

人類工程師卡關的時候，通常會來找你說「我試了兩小時還是不行」。AI 不會。AI 會一直試、一直繞、一直燒你的 token，直到 context window 爆掉或者你自己發現不對。

我踩過最痛的一次，是讓 AI 修一個 bug。它先 A 方案、再 B 方案、再回到 A 方案的變體，反覆繞了四十分鐘，最後我看記錄才發現：它根本在同一條死路上來回走。

管人的時候我們會設 check-in point：「做半小時如果沒進展就來找我討論」。管 AI 也一樣，你得主動設計停損機制。失敗幾次之後強制換方向、或者拉第二個 AI 進來給不同觀點。

這件事 AI 自己做不到。需要你替它設計。

市場上有大量文章教你怎麼寫 prompt、怎麼串工具、怎麼挑模型。這些都是「個人貢獻者」等級的技能。

但當你開始同時用多個 AI，你面對的挑戰就升級了。角色分工、衝突仲裁、品質稽核、停損判斷——這些是管理技能，不是技術技能。

有趣的是，業界花了二十年才搞清楚「會寫 code 跟會帶團隊是兩回事」。現在同樣的課題又出現了：會用一個 AI 跟會管理多個 AI，也是兩回事。

我的經驗是，TPM 的那套思維——定義角色、設計流程、管理風險、知道什麼時候該介入——在 AI 時代沒有過時。差別只是你管的「團隊成員」從人變成了模型。

而且說實話，模型比人好管多了。它們不會鬧情緒、不用 1-on-1、不會放假。它們只是需要一個懂得管理的人，替它們畫好邊界。