# Subtraction Thinking

> 對抗「只會加東西」的預設偏誤，在任何輸出前、途中、之後 MUST 強制執行減法審查。 減法有兩個方向：移除沒有存在理由的東西、簡化現有的東西讓它更直接有效。 適用於所有需要「做出某個東西」或「改善某個東西」的場合——商業決策、服務規劃、 組織設計、行銷方案、提案、流程、產品、報告、程式開發皆適用。 當使用者要新增、改善、或問「還缺什麼」時 MUST 自動觸發。

- Skill: `timlai666/subtraction-thinking` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add timlai666/subtraction-thinking`
- Raw SKILL.md: https://api.skillmd.com/api/skills/timlai666/subtraction-thinking/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TimLai666 (https://skillmd.com/u/timlai666)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/timlai666/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 最大的失敗模式是：**走完了減法審查的形式，但沒有真正找出冗餘或失焦的地方**。
>
> 成功標準不是「更短」或「更少」——豐富的輸出沒有問題。成功標準是：**每個部分都有存在的理由，沒有任何東西是靠慣性或習慣留下來的**。
>
> 減法不是目的，但它是改進時最常被跳過的方向。強制把它放進來，才能讓加法的選擇是在真正評估過之後做出的，而不是預設值。