一個 AI 扮 12 個工程師：真正值錢的不是人多，是它逼你把問題拆開

有個反直覺的事實，先放在這裡：如果你把一個 AI 拆成 12 個角色，它們背後其實是同一顆模型。沒有真的多請 11 個人，沒有多花 11 份腦力。那為什麼「一個 AI 扮 12 個工程師」這件事，做出來的東西反而會比「一個全能 AI 一次搞定」更靠譜？

my-claude-devteam 這個 Claude Code 外掛，就是把這個問題攤開來給你看。它把單一的 Claude 擴充成一支模擬的軟體開發團隊——產品經理幫你把需求拆成任務、架構師做技術選型、前端寫 UI、後端寫 API、QA 寫測試、資安審查員抓漏洞。聽起來像行銷話術，一堆頭銜疊上去顯得很厲害。但頭銜不是重點。重點是它逼你、也逼 AI，做了一件平常會偷懶跳過的事。

來源：my-claude-devteam GitHub repo（andrewgcodes/my-claude-devteam），內容為個人學習筆記整理，實際功能以官方 repo 為準。

你平常用 Claude Code，其實是「一個人校長兼撞鐘」

想像一間只有一個員工的公司。這個人早上是業務、中午變工程師、下午當會計、晚上還要自己稽核自己的帳。他每一項都會一點，但他一整天都在切換腦袋，而且沒有人幫他複查。

你平常開一個 Claude Code 對話，差不多就是這個狀態。你叫它寫功能，它寫；你叫它測試，它測；你叫它檢查安全性，它也檢查。表面上很方便，一個視窗全包。問題藏在那個「切換腦袋」的動作裡——它剛剛滿腦子都是怎麼把這個 API 兜出來，你馬上要它換一副「找碴」的眼睛去審自己的程式碼。人做這件事都很難了，因為你會下意識護著自己剛寫的東西。模型也一樣：它的 context 裡塞滿了「我要怎麼讓它動起來」的思路，這時候要它切成「我要怎麼弄壞它」，效果一定打折。

這就是單一通才模式最貴的隱藏成本。不是它不會,是它一次只能戴一副眼鏡,而它戴的還是剛剛那副沾滿實作細節的眼鏡。

devteam 到底做了什麼

它的做法說穿了很簡單:預先定義好 12 種角色,每一種都是一個帶著專屬 system prompt 的 subagent(子代理)。你丟一個需求進去,它不會一股腦寫完,而是走一條流程——先讓產品經理把需求拆成一張任務清單,再讓架構師決定技術方案,然後把任務分派給對應的工程師角色去做,最後由 QA 跟資安角色驗收。

12 個角色大致是這樣分的:產品經理負責把模糊需求拆成明確任務,技術主管做架構決策,前端、後端、資料庫、DevOps 各管一段實作,QA 寫測試,資安審查漏洞,還有程式碼審查員、技術文件、UX 設計、資料分析。整個排下來,就是一間小型軟體公司的組織圖。

安裝也不複雜,在 Claude Code 裡透過 marketplace 或直接指 GitHub repo 就能裝:

# 加入 marketplace（實際指令以專案 README 為準）
/plugin marketplace add andrewgcodes/my-claude-devteam

# 安裝 plugin
/plugin install my-claude-devteam

裝完之後,這些角色會以 subagent 的形式待命。Claude Code 在適當時機自動調度它們,你也可以手動點名——「這段我要 QA 角色來看」。

到這裡為止,它看起來就是個「多角色」工具。但把角色數量當賣點,是完全看錯重點了。

真正值錢的是那道「隔離牆」

回到開頭那個反直覺的問題。同一顆模型,拆成 12 個角色,為什麼會更好?

答案是 context 隔離。這才是整個設計的核心,其他都是包裝。

前端工程師的 context 裡,只裝跟前端有關的東西;它不會被後端一堆資料庫交易的細節干擾。QA 角色拿到的是一份「乾淨的、專門用來找碴」的 context,它沒有參與過實作,所以它不會護短——它看你的程式碼,就像一個沒有感情的外人在看,這正是你要的。資安審查員也是同理:一個從沒為「讓功能動起來」煩惱過的角色,才問得出「這裡會不會被注入」這種掃興但關鍵的問題。

用剛剛那間公司的比喻:與其讓一個人校長兼撞鐘,不如請幾個各自只管一件事的人。不是因為人多力量大,是因為「管稽核的那個人沒有參與做帳」——他的清白來自於他的無知,而這份無知恰好是複查的價值所在。

你有沒有發現,這其實跟軟體業幾十年來的分工制度,是同一個道理?先規劃、再架構、後實作、最後審查——這套流程不是誰拍腦袋想出來的,是無數專案踩坑踩出來的智慧。devteam 做的事,是把這套流程用 AI 重新演一遍,而且強迫它照著走,不准抄捷徑。

它的價值比較像鷹架,不是魔法

講到這裡要誠實標一件事:我是讀了這個 plugin 的設計跟文件去理解它,不是已經拿它跑過一整個大專案。所以下面講的是設計層面的判斷,不是實戰數據。

這個工具最容易被誤會的地方,是以為它「真的」多請了 11 個工程師。它沒有。它本質上還是同一個底層模型在扮不同角色。但這種「角色扮演加上 context 隔離」的組合,確實能逼出比單一通才模式更整齊的結果。它的價值,比較像蓋房子時搭的鷹架——鷹架本身不是房子,但沒有它,你很難把樓蓋高蓋正。它強迫 AI 按專業分工的方式思考,而不是把所有考量攪成一鍋粥。

當然,鷹架也有它的成本。12 個 subagent 輪流上工,token 消耗會比單一對話高出不少,你得盯著用量。而且它不是萬用解:如果你只是要寫一支一次性的小腳本,或只是問個語法問題,搬出一整支團隊就是殺雞用牛刀,反而拖慢你。它真正發光的場景,是那種從需求到上線、需要多個視角交叉把關的完整功能開發。