很多人讀《人月神話》只記得那句「專案落後時別再加人」的金句，這其實低估了 Brooks 的野心。他真正想拆解的，是我們潛意識裡那套深深刻在 DNA 裡的工業直覺：以為複雜問題只要切得夠碎、手加得夠多、時程催得夠緊，結果就會像工廠產線一樣自動冒出來。
Brooks 提醒我們一件尷尬的事：軟體開發之所以難搞，主因不在於工程師偷懶，而在於這項工作打從底層就拒絕被「線性加總」。這本書並非過時的工程古籍，它更像一把至今依然鋒利的手術刀，精準切開了知識勞動中最常見的認知誤區——我們總想用「算術」去管「邏輯」。
軟體開發不是搬磚，是關於「理解」的接力賽
搬磚這類體力勞動，確實符合「人多好辦事」的邏輯，畢竟磚頭之間沒什麼話好說，工作邊界清晰。你今天多找十個人，進度多半真的會超前。但軟體開發的核心產出其實是「結構化的理解」。工程師最燒腦的時刻，通常不是手指敲鍵盤那幾秒，而是大腦在處理需求邊界、邏輯自洽、或是預測那些可能爆炸的依賴關係。每一段程式碼都像一根毛線，背後牽動著資料流、權限設定、甚至影響到隔壁同事對整個系統的想像。
這就是 Brooks 最在意的**「概念完整性（Conceptual Integrity）」**。一個好系統能長久運作，靠的是背後那套設計邏輯始終如一。一旦這套邏輯亂了，團隊再怎麼拼命加班，也只是在製造更多需要互相抵銷的「整合債」而已。簡單說，這是一場依賴大量判斷的認知運動，最怕的從來不是缺人，而是大家的腦袋不在同一個頻道上。
為什麼「補人救火」反而讓火燒得更旺？
「Brooks 法則」之所以出名，是因為它指出了軟體專案的一個反直覺現象：追加人力，往往會讓落後的進度雪上加霜。
這背後的邏輯其實很樸素。新成員不是隨插即用的硬體，他需要前輩帶他看過一遍架構、避開那些沒寫在文件裡的坑、搞清楚為什麼去年某個決策不能動。當前輩停下手頭工作去傳承這些「隱性知識」時，舊成員的產能會先打折。再加上溝通路徑會隨著人數呈指數成長，每多一個理解版本，系統崩潰的風險就高一分。
專案告急時，團隊最缺的是「穩定的共同模型」，而補人這動作，短期內恰好是在稀釋這種模型。很多時候，領導者補人只是為了尋求心理安慰，以為在救火，實則是在擴張受災面積。
管理者的工業遺毒：麥當勞化的代價
如果把視野拉高一點看，這反映了我們對「效率」的一種病態信仰：只要一切都能標準化、量化、切分，我們就能控制結果。
這在漢堡店（麥當勞化）運作良好，因為品質來自於控制。但在高耦合的知識工作中，品質卻來自於「秩序」。軟體開發中真正稀缺的資源是**「認知秩序」**——讓複雜系統維持在可理解的狀態。這種秩序沒辦法靠填工時表換來，更沒法靠人海戰術堆疊。Brooks 反對的並非團隊合作，而是反對把合作誤解為「人力算術」。
2026 年，Agent 是否打破了這面牆？
今天很多人覺得 Brooks 的理論該退休了，因為我們有更好的 CI/CD、自動測試、雲端協作。但我認為，這些進步只降低了「摩擦」，卻沒減少「複雜」。甚至因為開發門檻降低，導致更多不同的理解版本同時進場，整合難度反而變大。
不過，我在 DeepWave 的實務現場，確實看到了轉機。
傳統上補人會拖慢進度，但今天「補 Agent」似乎真的有效。這並非因為軟體變簡單了，而是因為**「溝通成本」被極限壓縮了**。
當我一個人能調度二十個 Agent 去寫程式、補測試、翻修文件時，這更像是「單一大腦的外接硬碟」，而非「多大腦的協作」。傳統團隊裡最昂貴的成本——人與人之間的理解斷層、漫長的對齊會議——在這裡幾乎消失。因為所有的決策核心、坑洞記憶、架構邏輯，依然維持在同一個人的腦袋裡。
這意味著 Brooks 面對的某些物理限制開始鬆動了。我們第一次有機會讓「同一個概念中心」驅動超乎想像的執行力，而不必承擔溝通爆炸的代價。
但別高興得太早，這並不代表神話就此破滅。
這更有可能是把問題「由外轉內」。當外部溝通摩擦下降時，維持內部「認知秩序」的壓力會呈倍數集中在主導者身上。Agent 也許真的提供了一條新路，但也可能只是把「多加工程師」的舊幻覺，換包裝成了「多開 Agent」的新陷覺。
如果系統的靈魂仍然是「概念完整性」，那麼 Agent 帶來的不只是解法，更是一場關於大腦容量的新考驗。
這就是下一篇要聊的重點：當生產力趨近無限時，身為「概念守門員」的我們，會先被解放，還是先被壓垮？
