零摩擦的範圍蔓延

資料來源#

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

摘要#

這是 The Founder's Playbook: Building an AI-Native Startup 中指出的一種失敗模式：當用 Claude Code 加一個功能只要一個下午、而不是一個衝刺週期時，傳統上對抗範圍蔓延的強制機制——工程時間的成本——就崩塌了。每一個單獨的新增在當下都站得住腳（產品當然應該處理那個邊緣案例；使用者當然會想要那個工作流程），但累積起來的效果卻是產品膨脹、超出原本的邊界。最陰險的特性在於：它在當下並不感覺像是範圍蔓延——因為每個功能建起來確實都很便宜。

為什麼這在結構上是新的#

agentic 時代之前的範圍蔓延是會自我管控的。工程時間是看得見、稀缺、可被衡量的；「我們沒有頻寬」是一個真實的答案。當建置時間下降 10–20 倍時，說「好」的單位成本就降到了創辦人對「這是一個有意義的承諾」的感知門檻以下。成本會在後來才浮現——在維護上、在測試面上、在決策架構的漂移上（Agentic Technical Debt）——但決策時點卻被壓縮到了短短幾秒。

這份 playbook 的框架：

「These don't feel like scope creep in the moment because each one takes so little effort to build with agentic coding, but as your product sprawls beyond its original boundaries you risk losing direction and momentum.」

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

這個補救之道是結構性的，而非靠意志力：

「A written scope definition created before building begins, describing what the product does, what it deliberately does not do, and the specific evidence from real users that would justify adding something new.」

決策時點從*「我們該不該建這個？」轉移到「是否已經有一群關鍵多數的使用者告訴我們，沒有這個東西他們就無法從產品中獲得價值？」*這把每一個功能需求都轉化成一次證據查核，而非一次主觀判斷。

MVP 階段的紀律：

1. 在寫任何程式碼之前先定義範圍。
2. 明確列出產品刻意不做的事。（這是不尋常的一步——大多數範圍文件只指明要做的正面項目。）
3. 定義修訂標準——什麼樣來自真實使用者的具體訊號，才足以正當化擴張。
4. 當新功能點子冒出來時，用 Claude 當魔鬼代言人 來壓力測試——這究竟是真正的使用者訊號，還是被包裝成產品思維的創辦人熱情？

更深層的失敗#

這份 playbook 把這件事框定為不只是功能臃腫——它是一種方向上的失敗。每一層堆疊上去的功能，都讓產品的身分稍微偏移一點。二十個下午之後，產品已不再對應到 Idea 階段所驗證的那個問題。創辦人從「把已驗證的問題解決得很好」漂移到了「做一大堆與已驗證問題相鄰的事」。

這正是與假性產品市場契合（false product-market fit）的連結：一個四處蔓延、使用面廣但很淺的產品，看起來像是有牽引力。Sean Ellis 測試與努力測試（MVP 退出標準）能識破這一點——廣而淺的使用不會產生「如果失去它我會非常失望」這樣的答案。但等到測試揭露問題時，大量的建置努力已經花在了無法複利累積的方向上。

「所有功能都站得住腳」的陷阱#

個別站得住腳的決策，集合起來可能是錯的。這在結構上類似於：

• Idea 階段中客觀性的喪失（Problem-Solution Fit Discipline）：每一份印證性的證據都是真的；問題出在那份不對稱性上。
• 過早規模化：每一個規模化的步驟都是理性的；缺的是前提（已驗證的方向）。

這個模式是：當犯錯的成本下降時，前提查核就必須從隱性（由成本來把關）移轉到顯性（由一份書面文件來把關）。

相關連結#

• Narrow Wedge into a Legacy Market — 一個有紀律的狹窄楔入點，正是對抗無摩擦範圍蔓延的解方
• AI-Native Startup Lifecycle — MVP 階段的風險
• Agentic Technical Debt — 範圍蔓延會加速複利型的技術債；更多功能 = 更多需要重新推導的表面積
• Problem-Solution Fit Discipline — 同一種知識論類別（當 AI 移除了某個成本障礙時，就必須用一套顯性的紀律來取代那套隱性的紀律）
• Claude Code — 那個以速度移除成本門檻的工具
• Design Concept Grilling — Matt Pocock 的 grill-me 模式作為上游防線（一個強健的設計概念能抵抗蔓延）
• Harness Shrinkage as Models Improve — 不處理範圍蔓延；這是人為流程的工作，不會遷移進模型裡

待解決的問題#

• 這份 playbook 推薦書面範圍，卻沒有提供範本或實作範例。「我們刻意不做什麼」要寫得多具體，才能真正擋下需求？
• 是否存在一個可衡量的門檻，讓範圍蔓延越過界線、變成徹底的轉向（pivot）？這份 playbook 暗示了「失去方向」，卻沒有給出指標。
• 這如何與 Cat Wu 的一天出貨節奏互動？Anthropic 的內部實務出貨很快，但伴隨強大的產品判斷力；對一個初次創業的創辦人來說，那份判斷力要如何轉譯過去？

資料來源#

• The Founder's Playbook: Building an AI-Native Startup — MVP Stage chapter