緣起

利用 AI Vibe coding，做專案時功能邊界一直外擴，邊做邊覺得「這個使用者可能也需要」，就一直加上去，然後出現錯誤，再修正，又錯誤，只好再修補，陷入這個循環，等到察覺時，上萬行的程式碼已經堆積起來，我也都看不懂，來不及收斂邊界，連基本的 MVC 都無法端出來。 我能做得就是捨棄前面的上萬行，已經失去掌控能力的我，推掉重做是唯一能繼續的選項。

回顧去想，我像是坐落在不斷疊加的高樓，晃來晃去，但我還在想說再一個，就多一個就上太空了

（疊加高樓的那個遊戲）

核心主張

加法是人類認知預設，減法常被遺漏或放到最後。要把減法變成可靠的工具，重點不是讀更多書做更多事，而是要在思考流程的最前面裝一個 HOOK，強制減法選項要成為一個預設項目。

Less is more.

研究底子

Klotz 2021 年發表在 Nature 的論文《People systematically overlook subtractive changes》用八個實驗證明：人在解決問題時系統性忽略「減」這個選項。

  • Lego 穩定平台：59% 的人加積木，移除一塊就能解決。
  • 加上「移除也是免費的」這句提示後，加積木比例降到 39%。
  • 反向實驗同步證實，即使再補上「加是免費的」提示不會提高加法比例，因為加法本來就是預設。

「瓶頸在選項生成，不在評估」減法選項一旦被列出來，多數人才意識到而去移除多餘，但若沒被列出來，整個決策流程就只剩加法在競爭，頂多是 +1, +5, +10 的差別。

為什麼人類偏加法

四個機制互相強化：

  1. 認知成本：加法的點子先冒出來，減法要常常是下一輪。
  2. 損失趨避：刪掉感覺像損失，損失的心理權重大約是收益的兩倍。
  3. 努力可見性：加上去的工作別人看得到，刪掉像沒做事。
  4. 文化偏好：「更多」連結到進步與成長，「更少」連結到退縮。

四個放在一起，減法在每個層面都直接輸，沒得玩。BUT

我的實際案例

案例 A：模糊需求下的功能擴張

收到一個頁面開發，沒有明確規格，只有期待的操作方式。動手之後，隨著 AI 推薦的功能補齊，求好心切（貪心）的我都按接收採納， todo 不斷增加。每加一個我都覺得「這樣使用者體驗會更好」，我好棒呢。

問題拆解：

  • 沒有事前的「完成定義」，所以邊界邊做邊長。
  • 「使用者需要這個」是想像出來的，從來沒有與那個真實的對象確認過。
  • 或許想像中的使用者是無法被反駁的對象，因此每個加法理由都成立。

案例 B：30% 成功率該不該丟出去

對方沒指定準確率，是我自己心裡設了門檻覺得 30% 太低。這跟功能擴張同源：用想像中的使用者標準，取代真實使用者反饋。

判斷準則應該是：對方沒指定，就先丟出去問「這樣夠用嗎」，而不是等到 70% 才開口。

不做清單作為約束觸發器

開始撰寫「不做清單」吧！

「不做清單」之所以有用，不只是紀律問題。當你寫下「為什麼不做這個」的瞬間，會逼把流程與假設落地下來，直面需求。

它把主動增加延後到之後的迭代，面對每個版本的「使用者是否需要這個」的取捨，都是在打磨你對產品的細緻度。要你命 3000 就是難登大雅之堂的雜物。

時序問題

清單要在「開始想功能」之前寫，不是動手寫程式之前。因為加法擴張發生在思考階段，不是 coding 階段。

實作層面：找出每個專案最早的動作（開 editor、寫需求、找人討論），不做清單就插在那個動作之前。甚至是先找 AI 討論，不同的 AI 一起做參照。

模糊需求是最危險的時刻

需求越不清晰，想像使用者的空間越大，每個加法都顯得合理。所以模糊需求是最該寫不做清單的時刻，不是最該邊做邊探索的時刻。

三角約束：MVP × Sprint × 不做清單

不做清單只解決「顯式拒絕」這一面。要把減法做成可靠系統，還要兩個維度的補強：MVP 解決內容層減法，Sprint 解決時間層減法。

MVP：用最少努力換最多驗證

Eric Ries 在《The Lean Startup》定義 MVP 是「以最少努力收集最多驗證學習的版本」。重點不是「功能最少的產品」，是「驗證假設的最小可執行版本」。

最常見誤解：把 MVP 當「先做基本版上線」，結果變成精簡版產品而不是驗證機。Henrik Kniberg 的滑板圖說得很清楚：要造車的 MVP 是滑板（端到端可用、能收回饋），不是輪子（半成品、無法驗證）。每個版本都要解決使用者完整的問題，只是粗糙。

對應到擴張困境：問「這個功能要驗證什麼假設」，不能驗證的就砍。「使用者可能會用這個」不是假設，「使用者願意走完五步流程」才是。

Sprint：時間箱本身就是減法

Scrum Guide 定義 Sprint 是固定長度的迭代（常見兩週），時間到就停，不論工作完成沒完成。時間固定、範圍浮動，這就是減法機制：你不能加時間，只能砍範圍。

關鍵紀律：sprint backlog 一旦鎖定就不再加東西。新需求進下一個 sprint 的待評估池，當前週期不動。Google Ventures 的 Design Sprint 把這個約束壓到五天，更極端。

對個人專案：跑一週 sprint，週日花 30 分鐘決定下週要驗證的單一假設與 sprint goal，週一到週五鎖死範圍，週中冒出的新點子寫進 next-sprint.md。

三角合起來

維度工具約束
內容MVP砍功能，只留驗證假設所需
時間Sprint到點就停
範圍不做清單顯式拒絕本期不做的事

三件事互相 enforce。

  • 想「再加一個功能就好」時，sprint timebox 擋你
  • 想「先做基本版」時，MVP 的「要驗證什麼假設」擋你
  • 想「這個小東西順便加一下」時，不做清單擋你。

AI 互動的加法陷阱

很容易被忽略的加法來源：與 AI 互動本身就是加法。

Claude 或 ChatGPT 給建議是它的工作模式，輸出常常會是「也可以加 X」「考慮 Y」「順便處理 Z」。每次問 AI 就是在接收新的提案疊加，如果預設「全收」，等於加法 × 加法 × 加法，讓專案複雜度無限地擴張，邊界也越來越難收斂。 不做清單在這個輸入流前面會失守，因為清單寫在動工前，AI 對話發生在動工中。看似每個合理，還跟你說會強化使用者體驗與精準度，都在悄悄地探測你的底線（AI 也是好意提醒），但在不斷衝擊你的「不做清單」「MVP 定義」時，你能不能守住真正的需求，將「選擇不做」或「延後做」也納入個選項，甚至是比「做」更重要的選項，這是非常重要的事情。 否則就跟吃到飽一樣，狂吃猛吃，最後一吐不完。

這個現象沒有在 Klotz 研究範圍（他研究的是「自己解問題時忽略減法」）中被提及。AI 互動會給你「餵進大量加法選項」，挑戰更難，因為每個選項看起來都是甜美具體可行的，就只差你選 OK。真的危險

對應 cue：

  • AI 給的建議默認 50% 不採納
  • 每收到三個建議先問「哪兩個我不要」
  • 每輪 AI 對話結束做一次「砍」的 retrospective，不是寫在 todo 裡

另一個隱藏機制：對自己作品的喜愛，導致的盲目。不去問真實使用者的體驗，只專注在自己作品越長越有成就感，強制的 retrospective 來把這個加法輪迴打破。減法同時對抗當前版本的依附，讓你去思考目前作品功能的去留，淬鍊雜質，如同我們打鐵淬煉獲得更完美個物件。

適用範圍判準：自用工具不需要這套約束，因為沒有想像對象、沒有投射對象。只有「為了給別人用」的專案相較比較需要。一個可靠的提示：當你發現自己在替不存在的使用者打分，就該停下思考開始精煉。

入手點

進三步，停一下，再退一步

一件機械化動作：任何計畫、清單、解決方案動工前，可以嘗試寫下一個要移除的東西，再寫要加的東西。

Klotz 的研究證明，這一句話就能實質改變行為。讓減法選項變得可見，後面的評估自然會發生。

操作模板（個人 1 週 sprint 版）

週日 planning（30 分鐘）

## Sprint Goal
這週驗證：[一個假設，不是兩個]

## 假設驗證表
假設：使用者 X 在情境 Y 會做 Z
驗證方式：最便宜能產生信號的版本
成功訊號：具體可觀察的事
失敗訊號：會讓我放棄或轉向的事
時間預算：N 小時

## 不做清單
- [ ] 不做 X，因為 ...
- [ ] 延後 Y，等 ... 才考慮
- [ ] 移除既有的 Z

## 這次只做
- ...

順序很重要：先寫 sprint goal 與假設，再寫不做清單，最後才列要做的事。

RoutineAction
週一到週五鎖死 backlog，只動 sprint goal 上的事。週中冒出的新點子全部進 next-sprint.md，本週不開新分支。
週末回顧假設驗證了什麼？成立、調整、還是放棄？
- 哪些「順便加進來」的東西其實沒必要？
- 下週的 sprint goal 是什麼？

核心紀律句：時間到就停（sprint），假設驗完就停（MVP），清單上就不做（不做清單）。

常見失效情境

  • 對方是真實使用者且給了具體回饋：這時減法直覺反而會讓你忽略真正重要的需求。但我自己會覺得可以同時思考合併。
  • 系統本身已經很稀疏：減法已經被執行夠了，再砍會傷到核心功能。
  • 已經砍過一輪：再砍是過度優化，注意力應該回到加法。

延伸閱讀

減法心理／決策

  • Leidy Klotz, People systematically overlook subtractive changes, Nature 2021
  • Greg McKeown, Essentialism: The Disciplined Pursuit of Less
  • Nassim Taleb, Antifragile（via negativa 章節）
  • Stephen King, On Writing（kill your darlings）
  • Tim Ferriss, The Not-To-Do List（部落格文章）

內容層減法（MVP）

  • Eric Ries, The Lean Startup
  • Henrik Kniberg, Making sense of MVP（滑板圖原文，Crisp blog 2016）

時間層減法（Sprint）

  • The Scrum Guide（scrumguides.org 官方版）
  • Jake Knapp, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

相關 vault 頁

  • karpathy-guidelines — 最小化原則作為每次截斷的外部錨點
  • harness-engineering — 機械化約束的設計哲學，與「裝 cue」同一思路