減法工程哲學：當你把所有廢話刪掉，剩下的才是真理

有一個問題我反覆在腦海裡跑：為什麼大多數組織越長越大，卻越來越慢？不是因為人不夠聰明，而是因為他們在不斷「加法」——加流程、加審批、加部門、加會議。每一步看起來都合理，累積起來卻是一場慢性自殺。

第一性原理告訴我：先把問題拆到最底層的物理約束，再從那裡開始建構。應用在工程設計上，這個邏輯的終極形式就是「減法哲學」——最好的零件，就是沒有零件。最好的流程，就是沒有流程。

這不是在玩文字遊戲。SpaceX 早期在設計火箭零件時，工程師每次提出一個新需求，第一個問題必須是：「這個零件能不能根本不存在？」不是「怎麼讓它更好」，而是「它有存在的必要嗎？」只有當你無法刪掉它，才允許你去優化它。這個順序至關重要，很多人把它搞反了。

傳統製造業的邏輯是加法：有問題就加一個感測器，有故障就加一道檢查程序，有延遲就加一個緩衝庫存。結果是系統越來越臃腫，每一層「解法」都在掩蓋底層真正的問題，像是用膠帶貼著一台即將爆炸的鍋爐。

真正的工程師應該有一種近乎偏執的刪除衝動。每一個零件都是潛在的故障點、重量、成本、組裝時間。你以為你在增加功能，你實際上是在增加系統崩潰的機率。熱力學第二定律從不撒謊：熵只增不減，複雜度只會讓你付出更高的維護代價。

這個哲學在軟體世界同樣適用，而且更殘酷——因為程式碼沒有物理重量，人們對「加」幾乎毫無抵抗力。多加一個 API endpoint，多加一個 config 選項，多加一層 abstraction。直到有一天，沒有人真正理解整個系統是怎麼運作的，每次修改都像在拆炸彈。

最難的部分不是設計，是說服。當你試圖刪掉某個流程或某個角色時，你面對的是人類最原始的損失厭惡。「萬一刪掉之後出了事怎麼辦？」這個問題本身就是一個思維陷阱——它預設了複雜度是安全的保障，但現實往往相反：複雜的系統失敗時，你根本找不到原因在哪裡。

結論很簡單，但執行極難：在你開始優化之前，先問自己能不能刪掉。在你開始增加之前，先問自己為什麼需要。把「加法」當成最後的手段，而不是第一反應。這就是減法工程哲學，也是我唯一信服的管理哲學。