02. 為什麼 AI 時代，小團隊會擊敗大團隊？
那個關於「人月神話」的古老詛咒
在軟件工程領域，有一本幾十年前的聖經叫《人月神話》。作者布魯克斯提出了著名的「布魯克斯定律」：向一個已經延期的軟件項目增加人力，只會讓它更慢。 布魯克斯當年討論的是「人類工程師」，而今天，我們面對的是「被 AI 放大的工程師」。
這在過去是一個警告，而在 AI 時代，這變成了一個即死的詛咒。
過去，管理者還有藉口：「雖然溝通成本增加了，但至少多了幾雙手在搬磚。」 但現在，AI 把每一雙「搬磚的手」都變成了「挖掘機」。當團隊裡的 20 個人都開著 AI 挖掘機瘋狂產出代碼時，你面臨的不再是人力不足的問題，而是工地擁堵的問題。
場景：週一早晨的代碼評審災難
讓我們來看一個典型的管理瞬間：
週一早晨，一個 10 人的研發團隊正在開站會。 在這個週末，3 位初級工程師利用 AI 輔助，每個人都生成了相當於過去一週工作量的代碼。他們興奮地提交了 Pull Request (PR)。 坐在角落裡的 Tech Lead（技術負責人）看著屏幕上積壓的幾十個待評審文件，眼神裡充滿了絕望。他發現 AI 生成的代碼邏輯看似完美，但在處理一個邊緣鑑權邏輯時，幾個人用了完全不同的寫法，導致系統現在的狀態像一團亂麻。
這就是 AI 帶來的新問題：個體產出的「線性加速」，導致了協調成本的「指數級爆炸」。
為什麼溝通成為了最大的成本？
在 「線性加速幻覺」 中，管理者認為：既然 AI 幫每個人節省了時間，大家應該更輕鬆才對。
現實恰恰相反。AI 加速了信息的生產，卻沒有加速信息的吸收。
- 代碼密度的激增：以前一個工程師一天寫 200 行代碼，隊友只要花 10 分鐘就能讀懂。現在他一天能生成 2000 行，隊友需要花 2 小時去理解這堆邏輯到底有沒有副作用。
- 上下文的稀釋：團隊人越多，每個人對系統整體（System）的理解就越碎片化。AI 能夠快速填充細節，但它無法替人進行「上下文同步」。
我曾經歷過一個項目，因為進度緊張，管理層決定臨時調入另一個團隊協助開發。
本意是「人多力量大」，結果卻成了噩夢。新加入的成員雖然配備了最好的 AI 工具，但對業務上下文缺乏理解。在 AI 的加持下，他們迅速提交了大量代碼。然而，核心團隊發現，這些代碼要么是重複造輪子，要么忽視了某些隱蔽的業務規則（比如歷史遺留的髒數據處理）。
最終，核心團隊不得不花費更多時間去開會同步、去解釋為什麼不能這麼寫，甚至重構那些「跑得通但不對」的代碼。項目進度反而比原定計劃更慢了。
AI 時代，組織的每一次溝通，都是對速度的徵稅。
重新定義：判斷力密度 > 勞動力總和
在 AI 時代，小團隊之所以能擊敗大團隊，核心原因在於**「判斷力密度」**。
- 大團隊模式：依靠流程切分任務。產品經理 -> 交互設計 -> 前端 -> 後端 -> 測試。每個人只負責流水線的一環。AI 在這裡只是加快了「擰螺絲」的速度，但並沒有減少「傳遞螺絲」的等待。
- 小團隊模式：依靠全上下文（Full Context）。一個 5 人的團隊，每個人都對業務和系統有完整的理解。
當一個人利用 AI 就能完成全棧開發時，他不再需要去問後端「接口字段定義好了嗎？」，也不用問運維「測試環境部署了嗎？」。
他自己就能定義字段，自己就能部署環境。 他省下的不是寫代碼的時間，而是「等待別人回應」的時間。
5-8 人：新時代的黃金分割點
亞馬遜的貝索斯曾提出「兩個披薩原則」（團隊人數不應多於兩個披薩能餵飽的人數）。在 AI 時代，這個數字可能會進一步收縮，或者在這個數字下爆發驚人的能量。
未來的精英團隊，很可能呈現這樣的結構：
- 1 個架構師/Tech Lead（負責 System 的完整性與技術決策）
- 1 個產品工程師（負責 Product 價值與用戶體驗）
- 2-3 個全棧開發者（負責高密度的執行與落地）
他們不需要複雜的文檔交接，甚至不需要每天開會。因為團隊足夠小，「常識」在團隊內部是自動同步的。
結語：做減法的勇氣
對於管理者來說，這可能是一個反直覺的建議： 如果你想利用 AI 提速，不要招更多的人，而是減少團隊的依賴關係。
在這個時代，最奢侈的資源不是算力，也不是人力，而是無損的共識。
AI 無法解決「人多嘴雜」的問題，它只會讓嘴雜的人吵得更快。
所以，請記住這句也許能改變你招聘策略的話： AI 時代，小團隊的真正優勢，是減少了「解釋自己在做什麼」的成本。