🎯 什麼情境該想到我
當有人（或你自己）期待「導入某個新語言/框架/AI 工具，生產力就會十倍跳升、問題全解」時。
⚙️ 怎麼用（分清兩種複雜度）
「沒有任何單一技術或管理上的突破，能在十年內讓生產力、可靠性、簡單性提升一個數量級。」
- 本質複雜度（Essential）：來自問題本身的複雜（需求、概念、狀態）——工具消不掉，只能靠好的設計與思考馴服。
- 附屬複雜度（Accidental）：來自工具/語言/流程的笨拙——這部分工具能改善（但邊際遞減）。
- 判斷任何「銀彈」宣稱：它解的是附屬複雜度還是本質複雜度？宣稱能消滅本質複雜度的，多半是幻想。
★ 為什麼本質複雜度消不掉：書中的四個內在特性
布魯克斯列出軟體無法規避的四個內在特性（〈沒有銀彈〉一章）：
| 特性 | 書的論點 | 今天的樣子 |
|---|---|---|
| 複雜度 | 軟體實體可能比人類創造的任何其他實體都複雜，沒有兩個部分是相同的；元素以非線性方式交互，整體複雜度隨規模非線性增長。複雜度是本質屬性，抽掉複雜度的描述也就抽掉了本質 | 一個中型後端的狀態組合數，遠超過任何人能窮舉 |
| 一致性（conformity） | 物理學家相信自然有統一的簡單規律；軟體工程師面對的複雜度卻是隨心所欲的——來自人為制度和系統，必須遵從各種介面 | 稅法、第三方 API 的怪行為、舊系統的欄位格式——你必須配合，無法簡化 |
| 可變性 | 軟體持續承受變更壓力；因為它「看起來」容易改，所以被要求一直改 | 需求每個 sprint 都在變 |
| 不可見性 | 軟體無法被自然地視覺化；建築有平面圖，軟體的結構是好幾張互相重疊的圖（控制流、資料流、依賴） | 架構圖永遠只畫出其中一個面向 |
推論：這四個是問題本身的性質，不是工具的缺陷；所以沒有任何工具能讓它們消失。
★ 書承認的進展：都是在砍附屬複雜度
書中舉的過去突破——高階語言、分時系統、統一的程式設計環境——都被歸為解決了次要（附屬）困難：高階語言消除了「不是程式固有的」那一層複雜度（暫存器、位元操作）；較長的周轉時間也是次要困難。每次突破都很大，但做過一次就沒了：附屬複雜度越砍越少，下一次突破的空間就越小。
★ 書建議真正有希望的方向
布魯克斯不是悲觀論者，他列了四個攻擊本質困難的方向：
- 購買而不是自己開發：「構建軟體最可能的徹底解決方案是不開發任何軟體」——能買現成的就買。
- 需求精煉與快速原型：最難的部分是決定要建什麼；用原型和客戶反覆確認。
- 增量開發——培育而非搭建：先讓系統能跑，再一點一點長大；永遠有一個可運作的系統。
- 卓越的設計人員：軟體開發是創造性過程；好設計來自好的設計者，組織應該像培養管理者一樣投資培養他們。
★ 用這個框架評估任何新工具（包括 AI 程式助手）
問三個問題：
| 問題 | 例：AI 程式助手 |
|---|---|
| 它砍的是哪一種複雜度？ | 樣板程式碼、API 查詢、語法細節——附屬複雜度，而且砍得很多 |
| 本質複雜度還剩多少？ | 決定要建什麼、狀態如何互動、邊界情況怎麼處理——仍然在；而且生成速度變快後，「理解並驗證生成的程式碼」本身成為新的瓶頸 |
| 它有沒有新增附屬複雜度？ | 需要審查的程式碼量變多、提示與上下文管理、非決定性輸出 |
這樣分析的結論通常不是「沒用」或「萬能」，而是：它讓哪一段變快了、瓶頸移到了哪裡。瓶頸移動之後，要重新找約束點（見 工具-找出並管理約束點）。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意
-
這不是反對工具；工具能除附屬複雜度。只是別期待它解決「問題本身很難」這件事。
-
「十年內沒有數量級的提升」是 1986 年的預言：布魯克斯在二十週年版的回顧章節中重新檢視了它。重點不是預言準不準，而是本質／附屬的區分這個分析工具——它到今天仍然好用。