零摩擦的範疇蔓延

資料來源#

The Founder's Playbook: Building an AI-Native Startup

摘要#

The Founder's Playbook: Building an AI-Native Startup 所指出的一種失敗模式：傳統上用來抑制範疇蔓延的強制函數——工程時間的成本——在使用 Claude Code 新增一項功能只需一個下午而非一個 sprint 時便會崩解。每一項新增功能個別來看都合理（產品當然應該處理那個邊界案例；使用者當然會想要那種工作流程），但累積效果卻是產品擴張到超出原本界線。其有害之處在於，當下並不感覺像範疇蔓延——每項功能確實都很便宜、很容易建置。

為何這在結構上是全新的#

代理式程式設計出現以前的範疇蔓延，具備自我約束機制。工程時間是可見、稀缺且可估價的；「我們沒有頻寬」是真實的答案。當建置時間降低 10–20 倍時，答應一項工作的單位成本便低於創辦人感知中「這是一項有意義的承諾」的門檻。成本會在之後出現——出現在維護、測試表面積，以及決策架構漂移（Agentic Technical Debt）上——但決策點被壓縮到幾秒鐘。

該 playbook 的說法是：

「這些事情在當下不會讓人覺得是範疇蔓延，因為使用代理式程式設計建置每一項都只需很少力氣；但當你的產品擴張到超出原本界線時，你可能會失去方向與動能。」

解方：書面範疇、以證據為基礎的修訂標準#

補救方式是結構性的，而非依賴意志力：

「在開始建置前建立書面的範疇定義，說明產品做什麼、刻意不做什麼，以及來自真實使用者、足以支持新增項目的具體證據。」

決策點從*「我們應該建置這個嗎？」轉變為「是否已有足夠多的使用者告訴我們，沒有這個功能，他們就無法從產品獲得價值？」*這會把每項功能請求轉化為證據檢查，而不是主觀判斷。

MVP 階段的紀律：

在寫任何程式碼之前定義範疇。
明確列出產品刻意不做什麼。（這是不同尋常的做法——大多數範疇文件只規定正向內容。）
定義修訂標準——來自真實使用者、足以支持擴張的具體訊號。
當新的功能構想浮現時，使用 Claude as devil's advocate 進行壓力測試——這是真實的使用者訊號，還是包裝成產品思考的創辦人熱情？

更深層的失敗#

該 playbook 將此描述為不只是功能膨脹，而是方向失敗。每項累積加入的功能，都會稍微改變產品的身分。二十個下午過後，產品已不再符合 Idea 階段驗證過的問題。創辦人已從「把驗證過的問題解決好」轉向「做許多與驗證過的問題相鄰的事情」。

這正是它與虛假的產品市場契合之間的連結：一個廣泛但使用淺薄的龐大產品，看起來像是取得了 traction。Sean Ellis 測試與努力測試（MVP exit criteria）能揭露這一點——廣泛但淺薄的使用，不會產生「如果失去它，我會非常失望」的答案。但等到測試揭露問題時，大量建置努力已經投入到無法形成複利效應的方向上。

「所有功能都說得通」的陷阱#

個別來看合理的決策，合在一起可能是錯的。這在結構上類似於：

Idea 階段的客觀性喪失（Problem-Solution Fit Discipline）：每一段支持性證據都是真的；問題在於不對稱性。
過早擴張：每一步擴張都很理性；但前提條件（驗證過的方向）並不存在。

其模式是：當犯錯的成本降低時，前提條件檢查就必須從隱性的（由成本設下關卡）轉為顯性的（由書面文件設下關卡）。

開放問題#

該 playbook 建議採用書面範疇，但沒有提供範本或實作範例。「我們刻意不做什麼」需要具體到什麼程度，才能真正阻擋請求？
是否存在一個可衡量的門檻，能判定範疇蔓延已跨入徹底轉向？該 playbook 提到「失去方向」，卻沒有提供衡量指標。
這與 Cat Wu's 的 1 天發布節奏如何互動？Anthropic 的內部實務發布速度很快，但具備強大的產品判斷力；對首次創業的創辦人而言，該如何轉化這種判斷力？

資料來源#

The Founder's Playbook: Building an AI-Native Startup — MVP Stage 章節

零摩擦的範疇蔓延

資料來源#

摘要#

為何這在結構上是全新的#

解方：書面範疇、以證據為基礎的修訂標準#

更深層的失敗#

「所有功能都說得通」的陷阱#

相關連結#

開放問題#

資料來源#