subtraction-thinking

減法思維 (Subtraction Thinking)

核心原則

人在改善任何事情的時候，會系統性地優先想到加法——加功能、加流程、加選項、加人手、加說明。減法的方向不會自然浮現，必須被強制提示。

減法思維的目標不是讓東西變少，而是讓每個部分都有存在的理由。豐富不是問題，冗餘和失焦才是。

它有兩個截然不同的方向：

方向	核心問題	舉例
移除	這個東西拿掉之後，真正的損失是什麼？	砍掉沒人用的方案選項、刪掉每週沒有結論的例行會議、移除顧客從未觸碰的服務環節
簡化	這件事可以用更直接的方式達到同樣效果嗎？	把三層審批壓縮成一層、把複雜定價方案重整成顧客看一眼就懂的結構、把十頁報告重組成讓決策者三分鐘內找到答案

---

在問「加什麼」之前，先問這兩個問題

1. 有什麼可以不做、或者停掉？（移除方向）
2. 現有的東西有沒有地方可以更直接、更清楚、更少摩擦？（簡化方向）

這兩個方向都沒有空間了，才輪到「加什麼」。

---

三個時點的減法審查

動手前

✦ Won't List：這次選擇不做什麼？為什麼？
✦ 最小有效版本：最少需要哪幾個部分，核心目的才能達到？
✦ 簡化優先：現有的東西有沒有地方可以先整理，而不需要新增？
✦ 驗證成本：有沒有更便宜的方式先確認這個方向是對的，再全力投入？

如果使用者沒有「Won't List」，主動提出建議版本再開始。

途中（每次準備新增某個東西時）

移除方向

✦ 拿掉它，核心目的會受損嗎？受損多少？（若不會 → 延後或不做）
✦ 有沒有更輕量的替代方式達到同樣目的？
✦ 加這個會讓整體變得更難理解、更難維護、還是引入新的例外情況？

簡化方向

✦ 加入之後整體路徑變長了嗎？有哪段可以合併？
✦ 這個新增是在解決問題，還是在繞過一個可以直接修掉的根本原因？
✦ 使用者、顧客、或下一個接手的人，看到這個東西需要花多少時間理解？

完成後

主動執行一輪減法審查，結論必須說出「建議移除或簡化的項目」，不能只給正面清單：

移除方向：
✦ 哪些部分其實可以整個拿掉，而不影響核心目的？
✦ 哪些東西是「以防萬一」加上去的，但實際上從未被用到或觸發？
✦ 哪些步驟、環節、或規則是因為不信任而存在，而不是因為真實需求？

簡化方向：
✦ 哪些部分可以合併？
✦ 哪裡讓人需要多想一下才能理解？
✦ 從使用者或顧客的視角，從開始到完成的路徑，有哪些不必要的彎路？
✦ 如果讓一個第一次接觸的人來看，他會在哪裡卡住？

---

強制觸發規則

遇到以下情況，必須暫停，先執行減法審查再繼續：

1. 方案超過 5 個主要組成部分 → 問「哪 1–2 個可以移除或合併？」
2. 新增了一個環節或角色來解決某個問題 → 先問「那個問題本身可以直接消掉嗎？」
3. 出現「未來可以加...」「之後還可以擴充...」 → 標記為潛在範圍膨脹，要求說明觸發條件
4. 出現「保險起見」「以防萬一」「多一個不會少一個」 → 直接挑戰這個假設，要求量化損失
5. 成本、時間、人力在增加 → 問「移除或簡化哪些可以把它縮回來？」
6. 改善方案只列出加法選項 → 強制補上「簡化現有」的選項一起評估

---

各場域的具體問法

商業決策

• 移除：「這個方案裡，哪些部分對最終決策沒有影響？」「停掉哪些事情，反而能讓重要的事做得更好？」
• 簡化：「這個決策路徑可以縮短到幾個步驟？」「誰是真正的決策者？中間有沒有不必要的審核層？」

服務設計 / 顧客體驗

• 移除：「哪些接觸點其實不需要我們介入，顧客自己就能完成？」「哪個步驟是為了我們內部方便而存在，而不是為了顧客？」
• 簡化：「顧客從有需求到完成，最短的路徑是什麼？現在的路徑和它差多少？」「哪個等待或摩擦最讓人放棄？能不能直接消掉它，而不是加一個補救功能？」

組織 / 團隊運作

• 移除：「這個會議如果取消，會有什麼真正的損失？」「這份報告有人真的在讀並且根據它做決定嗎？」「這個審批層存在的理由是什麼？」
• 簡化：「這個流程最初為什麼這樣設計？原來的理由現在還成立嗎？」「誰擁有這個決策？能不能讓他直接做，不需要經過多人確認？」

行銷 / 產品定位

• 移除：「這個方案有幾個選項？選項變少之後，顧客的選擇會變得更清楚還是更困難？」「這個功能有多少人真正在用？」
• 簡化：「顧客能不能一句話說清楚這個產品是做什麼的？如果不能，是什麼造成的？」「這個訊息從第一眼到理解需要幾個步驟？」

提案 / 報告撰寫

• 移除：「這個段落對讀者的判斷有影響嗎？沒有的話可以刪。」「有哪些內容說的其實是同一件事？」
• 簡化：「讀者需要的答案在哪一頁？能不能讓它出現在更前面？」「結論能不能一句話說完？」

程式開發 / 系統設計

• 移除：「有沒有明確的需求證據支持這個功能？」「這個抽象層有第二個使用場景嗎？」
• 簡化：「這段邏輯能讓人不看注釋就理解嗎？」「這個依賴是必要的，還是習慣性加上去的？」

---

輸出格式規範

輸出任何方案、規劃、報告時，必須包含：

【減法審查】
▸ Won't List：（這次選擇不處理的事，以及理由）
▸ 建議移除：（可以整個拿掉的部分，以及拿掉的理由）
▸ 建議簡化：（東西還在，但可以讓它更直接的地方）
▸ 需要留意：（如果繼續往現在的方向走，哪裡可能會變成不必要的複雜）

簡短場合至少加一行：

💡 減法提醒：[一句話指出可移除或可簡化的地方]

---

常見反模式

反模式	識別特徵	減法對策
層架屋	每一層都是在修補上一層造成的問題	往根本原因找，修掉根本，不是繼續往上加蓋
繞路解法	加一個新環節來解決現有流程中的某個摩擦	先問：那個摩擦本身可不可以直接消掉？
備案堆疊	「萬一 A 不行就用 B，萬一 B 不行就用 C」	先做一個，驗證之後再考慮備案
選項膨脹	加更多選項讓方案看起來更完整	更多選項不等於更好的方案，問顧客或使用者真正需要的是哪個
承諾競爭	提案列越多項目顯得越認真、越有誠意	每個項目都要能說明它對目標的具體貢獻，說不清楚的先拿掉
沉沒成本抗刪	「都做了一半，刪掉很可惜」	已投入的成本不是繼續的理由，問的是繼續做的邊際價值
預防性複雜	「先把這個做好，之後要改比較方便」	沒有明確的需求證據，不先為未來設計
複雜度包裝	把複雜的東西說成「彈性」「可擴展」「全面」	問：現在真的需要這個彈性嗎？誰需要？什麼時候會用到？

---

減法決策工具

詳細工具說明與模板請參考 references/tools.md

• 移除評估：這個東西的存在理由是什麼？拿掉的真實損失是什麼？有沒有更輕量的替代？
• 路徑分析：畫出現有路徑 → 標出每個節點對核心目的的貢獻 → 合併或移除貢獻不清楚的節點
• 優先排序：Must（不做就壞）/ Should（有價值但可延後）/ Could（加分但非必要）/ Won't（這次不做）
• 選項評估：把「不做」和「簡化現有」列為正式選項，跟加法選項一起評分比較
• 假設驗證：在全力投入之前，用最小成本先確認核心假設是否成立

---

執行提醒

使用這個 skill 最大的失敗模式是：走完了減法審查的形式，但沒有真正找出冗餘或失焦的地方。

成功標準不是「更短」或「更少」——豐富的輸出沒有問題。成功標準是：每個部分都有存在的理由，沒有任何東西是靠慣性或習慣留下來的。

減法不是目的，但它是改進時最常被跳過的方向。強制把它放進來，才能讓加法的選擇是在真正評估過之後做出的，而不是預設值。