布魯克斯法則已誕生 50 年，且依舊正確

1975 年，弗雷德·布魯克斯（Fred Brooks）出版了《人月神話》（The Mythical Man-Month），並提出了後來被稱為「布魯克斯法則」（Brooks' Law）的定律：向進度落後的軟體專案增加人手，只會讓專案更加落後。其核心觀點是，軟體開發不像挖水溝，人數加倍並不意味著時間減半。它涉及溝通、協調與整合，而這些工作的複雜度會隨著團隊規模的擴大而呈指數級增長。在某個節點上，新增人員所帶來的溝通成本將超過他們所能貢獻的產出。

五十年後，工具已經發生了翻天覆地的變化。非同步溝通、CI/CD 流水線、基礎設施即代碼（IaC）、模組化架構、AI 輔助代碼審查。問題在於，這些工具是否已讓布魯克斯法則失效？

數據表明，事實並非如此。這些工具只是移平了曲線（現在開始出現溝通瓶頸的團隊規模比 1975 年時更大），但「溝通路徑的增長速度遠超人數增長」這一根本動態依然成立。

數學規律並未改變

團隊中一對一溝通路徑的數量隨著 n(n-1)/2 增長。5 個人時：10 條路徑；10 個人時：45 條；20 個人時：190 條；50 個人時：1,225 條。這是任何工具都無法改變的數學事實。每條路徑都是一個潛在的協調點、一個潛在的誤解源、一次潛在的會議。

現代工具降低了每條路徑的成本。非同步溝通意味著並非每條路徑都需要同步時間。CI/CD 可以自動捕獲過去需要人工協調的整合問題。清晰的 API 規範減少了跨團隊討論介面的需求。然而，降低單條路徑的成本並不能減少路徑的總數，而路徑數量的增長如此迅速，以至於即便單條路徑的成本再低，累積起來依然非常昂貴。

對 100 多家 B2B 公司（PanDev Metrics, 2026）的真實工程數據分析證實了這一規律：小團隊（2-5 名開發人員）在一天中用於編寫代碼的時間比例更大，而大團隊在協調上花費的時間比例更高。擴展效果最好的團隊通常具備三個特徵：小型自主子團隊、清晰的所有權邊界，以及對非同步流程的投入，從而降低每條路徑的協調成本。

現代工具究竟改變了什麼

現代工具並沒有打破布魯克斯法則，但它們確實推遲了拐點的出現。

非同步溝通（如 Slack、Notion、Loom）通過允許在並非所有人同時在線的情況下進行協調，減少了會議開銷。但非同步工具也帶來了自身的協調負擔：需要監控更多頻道、跟進更多對話串、處理更多通知。協調工作只是從會議轉移到了即時通訊，總開銷並不一定會減少。

CI/CD 流水線會自動捕獲整合問題，減少了在代碼合併和部署時進行人工協調的需求。這確實顯著降低了某一類別的協調成本，但它無法解決更大類別的問題：上下文傳遞、決策制定和知識共享。

模組化架構（微服務、定義明確的 API）減少了團隊之間的耦合，使他們能夠更獨立地工作。這是最有效的緩解措施，因為它減少了實際產生協調需求的溝通路徑。然而，模組化架構需要大量的前期投入，且模組之間的邊界本身也會產生新的協調需求。

自動生成文件通過讓知識在無需撰寫者在場的情況下隨時可用，降低了上下文傳遞的成本。這直接解決了布魯克斯提出的三個溝通成本來源之一（另外兩個是培訓和整合）。當新進人員可以通過閱讀文件而不是詢問現有團隊來了解背景時，布魯克斯所指出的新人培訓負擔將大大減輕。

AI 時代的新變數

近期的研究引入了一個布魯克斯未曾預料到的新變數。在 AI 時代，團隊中的每個人都可以調配 AI 代理來放大個人產出。一名配備 AI 工具的工程師，其代碼產出速度可能相當於以往兩到三名工程師的總和。

直觀的結論是，因為需要的人手變少了，所以 AI 打破了布魯克斯法則。然而，一篇 2026 年關於「新穎性瓶頸」（Novelty Bottleneck）的論文提出了一個更微妙的觀點：AI 實際上可能會加劇布魯克斯法則。

其原因在於：如果每個人的產出放大，都會增加團隊中其他所有成員的整合負擔，那麼增加第 n+1 個人所帶來的邊際協調成本，將隨著 AI 代理能力的提升而增加。一個由五名工程師組成的團隊，即便每個人都使用 AI 代理產出 3 倍的代碼，仍然需要對這些代碼進行整合、評審、測試，並維持整個系統的一致性。整合負擔會隨著總產出的增加而增加，而 AI 提高了每個人的總產出。

這帶來的實際預測是：AI 賦能的企業應該傾向於建立更小、更自主的團隊，而不是擴大團隊規模。一個由 5 名配備 AI 的工程師組成的團隊，可以達到以往 50 人團隊的產出，同時產生的協調成本要低得多。這與目前新興的小型 AI 初創公司擊敗大型傳統工程組織的趨勢相吻合。

實際啟發

布魯克斯法則常被用作警示（不要給落後的專案增加人手），但其更深層的啟發在於指導性：應投資於降低協調開銷，而不是增加員工人數。

降低協調開銷的投資方向，自布魯克斯提出以來就未曾改變，只是在現代工具下進行了升級：

團隊之間清晰的邊界和介面，使每個團隊都能自主工作。雙披薩團隊模式就是這種理念在組織架構上的體現。

文件化以減少培訓和上下文傳遞的負擔，使新成員能夠在不消耗現有團隊時間的情況下快速產生生產力。

可檢索的知識庫使資訊隨手可得，因此協調不需要同步溝通。

非同步優先的流程可以減少會議負擔，使協調以書面形式進行，而非即時會議。

布魯克斯在 1975 年的觀點是正確的，其核心洞察至今未變：溝通成本的增長速度遠快於團隊規模的擴大。唯一的問題在於，你願意承受多少這種溝通成本，又願意投入多少去降低它。

常見問題解答

是否有公司真正打破了布魯克斯法則？ 許多公司通過模組化架構、清晰的團隊邊界和完善的文件顯著改善了這一曲線。亞馬遜的雙披薩團隊是最常被引用的例子。但是，底層的動態規律（路徑隨 n² 增長）並未消失，只是被有效管理了。

這是否意味著我們永遠不應該擴展團隊規模？ 這意味著團隊擴展的同時，必須按比例投資於協調基礎設施。如果只增加人手，而不增加文件、清晰的邊界和非同步流程，布魯克斯法則的負面影響將會最為嚴重。

團隊規模多大才合適？ 研究一致指出，5-8 人是自主團隊的最佳規模範圍。超過 8 個人時，應考慮拆分為具有清晰介面的子團隊。雙披薩團隊模式提供了一個實用的框架。

延伸閱讀：知識擴展難題、如何擴展工程團隊、為什麼你的團隊變得越來越慢、協調稅。相關頁面：自動生成文件、適用於工程團隊。