對抗「只會加東西」的預設偏誤，在任何輸出前、途中、之後強制執行減法審查。 減法有兩個方向：移除沒有存在理由的東西、簡化現有的東西讓它更直接有效。 適用於所有需要「做出某個東西」或「改善某個東西」的場合——商業決策、服務規劃、 組織設計、行銷方案、提案、流程、產品、報告、程式開發皆適用。 當使用者要新增、改善、或問「還缺什麼」時自動觸發。
人在改善任何事情的時候，會系統性地優先想到加法——加功能、加流程、加選項、加人手、加說明。減法的方向不會自然浮現，必須被強制提示。
減法思維的目標不是讓東西變少，而是讓每個部分都有存在的理由。豐富不是問題，冗餘和失焦才是。
它有兩個截然不同的方向：
| 方向 | 核心問題 | 舉例 |
|---|---|---|
| 移除 | 這個東西拿掉之後，真正的損失是什麼？ | 砍掉沒人用的方案選項、刪掉每週沒有結論的例行會議、移除顧客從未觸碰的服務環節 |
| 簡化 | 這件事可以用更直接的方式達到同樣效果嗎？ | 把三層審批壓縮成一層、把複雜定價方案重整成顧客看一眼就懂的結構、把十頁報告重組成讓決策者三分鐘內找到答案 |
1. 有什麼可以不做、或者停掉？（移除方向）
2. 現有的東西有沒有地方可以更直接、更清楚、更少摩擦？（簡化方向）
這兩個方向都沒有空間了，才輪到「加什麼」。
✦ Won't List：這次選擇不做什麼？為什麼？
✦ 最小有效版本：最少需要哪幾個部分，核心目的才能達到？
✦ 簡化優先：現有的東西有沒有地方可以先整理，而不需要新增？
✦ 驗證成本：有沒有更便宜的方式先確認這個方向是對的，再全力投入？
如果使用者沒有「Won't List」，主動提出建議版本再開始。
移除方向
✦ 拿掉它，核心目的會受損嗎？受損多少？（若不會 → 延後或不做）
✦ 有沒有更輕量的替代方式達到同樣目的？
✦ 加這個會讓整體變得更難理解、更難維護、還是引入新的例外情況？
簡化方向
✦ 加入之後整體路徑變長了嗎？有哪段可以合併？
✦ 這個新增是在解決問題，還是在繞過一個可以直接修掉的根本原因？
✦ 使用者、顧客、或下一個接手的人，看到這個東西需要花多少時間理解？
主動執行一輪減法審查，結論必須說出「建議移除或簡化的項目」，不能只給正面清單：
移除方向：
✦ 哪些部分其實可以整個拿掉，而不影響核心目的？
✦ 哪些東西是「以防萬一」加上去的，但實際上從未被用到或觸發？
✦ 哪些步驟、環節、或規則是因為不信任而存在，而不是因為真實需求？
簡化方向：
✦ 哪些部分可以合併？
✦ 哪裡讓人需要多想一下才能理解？
✦ 從使用者或顧客的視角，從開始到完成的路徑，有哪些不必要的彎路？
✦ 如果讓一個第一次接觸的人來看，他會在哪裡卡住？
遇到以下情況，必須暫停，先執行減法審查再繼續：
輸出任何方案、規劃、報告時，必須包含：
【減法審查】
▸ Won't List：（這次選擇不處理的事，以及理由）
▸ 建議移除：（可以整個拿掉的部分，以及拿掉的理由）
▸ 建議簡化：（東西還在，但可以讓它更直接的地方）
▸ 需要留意：（如果繼續往現在的方向走，哪裡可能會變成不必要的複雜）
簡短場合至少加一行：
💡 減法提醒：[一句話指出可移除或可簡化的地方]
| 反模式 | 識別特徵 | 減法對策 |
|---|---|---|
| 層架屋 | 每一層都是在修補上一層造成的問題 | 往根本原因找，修掉根本，不是繼續往上加蓋 |
| 繞路解法 | 加一個新環節來解決現有流程中的某個摩擦 | 先問：那個摩擦本身可不可以直接消掉？ |
| 備案堆疊 | 「萬一 A 不行就用 B，萬一 B 不行就用 C」 | 先做一個，驗證之後再考慮備案 |
| 選項膨脹 | 加更多選項讓方案看起來更完整 | 更多選項不等於更好的方案，問顧客或使用者真正需要的是哪個 |
| 承諾競爭 | 提案列越多項目顯得越認真、越有誠意 | 每個項目都要能說明它對目標的具體貢獻，說不清楚的先拿掉 |
| 沉沒成本抗刪 | 「都做了一半，刪掉很可惜」 | 已投入的成本不是繼續的理由，問的是繼續做的邊際價值 |
| 預防性複雜 | 「先把這個做好，之後要改比較方便」 | 沒有明確的需求證據，不先為未來設計 |
| 複雜度包裝 | 把複雜的東西說成「彈性」「可擴展」「全面」 | 問：現在真的需要這個彈性嗎？誰需要？什麼時候會用到？ |
詳細工具說明與模板請參考 references/tools.md
使用這個 skill 最大的失敗模式是：走完了減法審查的形式，但沒有真正找出冗餘或失焦的地方。
成功標準不是「更短」或「更少」——豐富的輸出沒有問題。成功標準是：每個部分都有存在的理由，沒有任何東西是靠慣性或習慣留下來的。
減法不是目的，但它是改進時最常被跳過的方向。強制把它放進來，才能讓加法的選擇是在真正評估過之後做出的，而不是預設值。