摩擦歸零的範疇蔓延

資料來源#

摘要#

The Founder's Playbook: Building an AI-Native Startup指出一種失敗模式：過去抑制範疇蔓延的制約機制——工程時間的成本——在使用 Claude Code 新增功能只需一個下午、而非一個開發週期時，便會瓦解。每一項新增功能單獨看來都有其道理（產品當然該處理那種邊界情況；使用者當然會想要那種工作流程），但累積起來，產品便會膨脹到超出原先界線。最棘手之處在於，當下感覺不到這是範疇蔓延——每項功能都確實很容易建置。

為何這在結構上是新的#

代理式程式設計出現之前，範疇蔓延會自我約束。工程時間明確可見、稀缺，而且能夠估算；「我們沒有餘裕」是個真實的理由。當建置時間縮短 10 至 20 倍，答應新增功能的單位成本便低到創辦人察覺不到這是一項「有意義的承諾」。成本稍後才會浮現——在維護、測試範圍，以及決策架構偏移之中（Agentic Technical Debt）——但做決定的時間點已縮短到幾秒鐘。

這份創業指南如此描述：

「當下感覺不到這是範疇蔓延，因為用代理式程式設計建置每項功能都只需很少心力；但產品一旦超出原先界線，你就可能失去方向與動能。」

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

解方在於結構，而非仰賴意志力：

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

決策問題從「我們該建置這個嗎？」轉為「是否已有足夠多的使用者告訴我們，沒有這項功能就無法從產品獲得價值？」如此一來，每項功能需求都會先接受證據檢驗，而不是憑主觀判斷決定。

MVP 階段的紀律：

在寫任何程式碼之前，先定義範疇。
明確列出產品「刻意不做」的事。（這是不同尋常的一步——大多數範疇文件只列出要做的事。）
訂出修訂標準——哪些來自真實使用者的明確訊號，足以支持擴大範疇。
出現新功能構想時，請 Claude 扮演唱反調者來檢驗——這是真實的使用者訊號，還是創辦人把熱情包裝成產品思考？

更深層的失敗#

這份創業指南將此問題描述為不只是功能膨脹，更是方向失準。每增加一項功能，產品定位就會稍微改變。二十個下午之後，產品已不再符合構想階段經過驗證的問題。創辦人已從「妥善解決經驗證的問題」轉向「做許多與經驗證問題相鄰的事」。

這也與虛假的產品市場契合度有關：功能繁多、使用面廣但淺的產品，看起來像是已有市場 traction。Sean Ellis 測試和努力測試（MVP 退出標準）仍然有效——廣泛但淺層的使用，不會讓人回答「如果失去它，我會非常失望」。然而等到測試揭露問題時，已經有大量建置心力耗費在無法累積成長的方向上。

「每項功能都有道理」的陷阱#

單獨看都有道理的決定，合在一起仍可能是錯的。這在結構上類似於：

構想階段失去客觀性（Problem-Solution Fit Discipline）：每一項支持性證據都是真的，問題在於證據的不對稱。
過早擴張：每一步擴張都合乎理性，但缺少必要前提（方向已經過驗證）。

模式是：當犯錯的「成本」降低時，先決條件檢查就必須從隱性（由成本把關）轉為明確（由書面文件把關）。

尚待探討的問題#

這份創業指南建議把範疇寫下來，卻沒有提供範本或完整範例。「刻意不做的事」需要寫得多具體，才能真正擋下需求？
範疇蔓延跨過什麼可衡量的門檻，才會演變成明確轉向？這份指南提到「失去方向」，卻沒有提出衡量標準。
這如何與 Cat Wu 的一天交付節奏互動？Anthropic 內部的做法是快速交付，但同時具備強烈的產品判斷力；初次創業的創辦人該如何培養這種判斷力？

資料來源#

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

摩擦歸零的範疇蔓延

資料來源#

摘要#

為何這在結構上是新的#

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

更深層的失敗#

「每項功能都有道理」的陷阱#

延伸閱讀#

尚待探討的問題#

資料來源#