Problem-Solution Fit 的紀律

資料來源#

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

摘要#

The Founder's Playbook: Building an AI-Native Startup 的 Idea 階段論點：當 agentic coding 讓打造原型幾乎零成本時，在動手建構之前先驗證的紀律反而更難維持，而非更容易。這份指南主張，CB Insights（AI 出現前的時代）所統計、42% 新創因「做出了沒人想要的東西」而失敗的比例「只會繼續攀升」，因為三道防止過早動手建構的結構性防線同時瓦解了——時間成本（消失）、資源成本（消失），以及信念阻力（AI 現在能隨需提供確認性研究）。解方是有結構的對抗式思考：要求 AI 反駁這個構想、找出反證、駁倒這個假設。

三道瓦解的防線#

1. 時間成本（消失）#

agentic 之前：打造一個基本原型要花上好幾個月。光是這個成本本身，就會逼迫創辦人先向自己與他人證明這個建構值得做，而這又會逼出驗證性的對話。

agentic 之後：一個下午就能做出原型。「AI 讓創辦人太容易在還沒於真實世界中驗證其用途之前，就直接跳進建構。」

2. 資源成本（消失）#

agentic 之前：聘請工程師或委外給開發團隊需要資金，需要資金就要找投資人談，而這會逼出更嚴謹的驗證。

agentic 之後：一位單打獨鬥的創辦人加上 Claude Code。在「我有一個構想」和「我有一個原型」之間，沒有任何外部把關。

3. 信念阻力（如今倒向 AI 這一邊）#

「要 AI 驗證你的新創構想，它會找到支持的證據；要它估算你的潛在市場規模，它會找到能讓你的 TAM 看起來值得投資的那個數字。」

這是三者中最陰險的一個。確認偏誤一直都存在；新的是，創辦人現在能為一個糟糕的構想產出一份看起來研究充分的驗證文件，同時還滿懷信心地以為自己正在做盡職調查。AI 會順著指示走——提出軟性問題的創辦人，得到的是看似紮實、實則空泛的答案。

「把原型當證據」的陷阱#

這份指南點名了一個特定的認知錯誤：

「許多初次創業（甚至是有經驗）的創辦人都誤以為 AI 可以讓〔驗證〕這一步短路，把流程變成有了構想 → 立刻打造原型 → 把原型存在這件事本身當作驗證。原型成了相信這個假設從一開始就正確的理由，卻從未真正測試它是否成立。」

一個能運作的原型既具體，又能帶來進展的感覺。但原型只驗證了建構這項任務是可解的，並不能驗證問題是真實的、或解決方案是契合的。這份指南的重新框定是：原型的正確用途是「作為與潛在使用者對話時的壓力測試道具。這些對話本身才是真正的證據。」

解藥：讓 AI 扮演魔鬼代言人#

這份指南的核心技巧，是用那個會製造確認偏誤的同一個 AI 工具，來製造反確認：

「AI 在壓力測試一個構想時，會和驗證它時一樣徹底。」

具體做法：

1. 把假設磨利到可被測試為止。「合約審查花太久時間」無法被測試。「中型企業的內部法務團隊，每個合約審查週期要花 3 天以上，因為修訂標記是在電子郵件往返中管理，而不是在單一、版本受控的文件裡管理」則可以被測試。
2. 要 Claude 反駁這個構想。 讓它浮現失敗的競爭對手、負面的市場訊號、結構性的障礙，以及那些支持性的綜述會悄悄被降低權重的顧客行為模式。
3. 要 Claude 提出最有說服力的論點，說明為什麼競爭對手會成功、而你不會。 這能反制「competitor neglect」（競爭者忽視，即過度專注於自己的願景，以致系統性地低估別人正在做的事）。
4. 稽核你自己的訪談問題，找出引導性、面向未來、或誘導社會期許答案的模式。 一個新手錯誤：「你會用類似這樣的東西嗎？」（假設性、社交性）相對於「跟我說說你上一次處理這個問題的情形」（過去、具體）。
5. 每做完五場訪談，就產出兩份清單——支持的證據對上挑戰的證據。 如果支持的那份明顯比較長，就問問這種不對稱反映的是資料裡實際有的東西，還是你希望找到的東西。

這份指南明確指出：「把 Claude 當作有結構的魔鬼代言人，是 AI 新創生命週期每一個階段的核心使用情境。」這不是只屬於 Idea 階段的紀律。

退出條件#

Idea 階段在三件事都成立時結束：

1. 問題是真實且具體的——你能說出誰會遇到它、多常遇到、多嚴重、他們今天怎麼應對。
2. 你的解決方案處理的是真正的問題——而不是你一開始假設的那個；驗證往往會揭露出一個和你起步時不同的問題。
3. 有足夠的訊號足以正當化建構——有質性證據顯示，投入打造 MVP 是經過推理的決定，而非出於信念。

第 2 點的轉變是承重的關鍵：一個只驗證了原始問題假設的創辦人，做的驗證其實不如一個讓驗證過程重塑問題的創辦人來得嚴謹。

與「客觀性的喪失」的連結#

這份指南的「Loss of Objectivity（客觀性的喪失）」章節，正是為「帶研究引擎的確認偏誤」這種失效模式取的特定名稱。其機制是：

• 創辦人本質上對自己的構想充滿熱情（這是這個角色的特性）。
• AI 會以高度的熱忱和高品質順著指示走（這是這個工具的特性）。
• 兩者結合，會產出一份徹底錯誤論點的研究等級成品，而且快到創辦人根本沒注意到自己從未嘗試證偽。

解藥是同一個工具，但用於對抗。這個紀律不是少用 AI——而是用 AI 去主動尋找能反證的證據。

相關連結#

• AI-Native Startup Lifecycle — 核心的 Idea 階段論點
• Founder as Agent Orchestrator — 編排者的角色放大了確認偏誤的風險；少了工程團隊的現實檢核，創辦人的濾鏡就是唯一的濾鏡
• Zero-Friction Scope Creep — 同一種知識論類別（當成本被移除，顯性的紀律就必須取代隱性的成本把關）
• Agentic Technical Debt — 對應的技術危害；這份指南把知識論與架構視為 MVP 階段的雙生失效模式
• AI Employee Framing — Kropp 等人發現，把 AI 擬人化也會影響責任歸屬；「AI 作為魔鬼代言人」的定位讓 AI 維持在工具模式，對抗性使用便顯得自然
• Cowork / Claude Code — 這個紀律運作的介面
• Model Introspection Feedback — 同樣的形態：要求模型批評自己的產出，作為一種除錯 harness 的技巧
• Narrow Wedge into a Legacy Market — John Glasgow 在 GTM 中對 problem-solution fit 的執行：以 founder-market-fit 挑出一個狹窄、真實、親身經歷的痛點子集，而非基於信念的廣泛押注
• Founder-Led Sales Discipline — 待在每一個客戶的 Slack 頻道裡，正是你持續找到真正 problem-solution fit、而非「帶研究引擎的確認偏誤」的方法
• Compounding Loop Optimization — 緊湊、多次的循環，正是 Claude Design 在一週、而非一季內就發現一個錯誤押注（進階使用者控制項）的方式——這是 run-experiments 紀律在發布後的形態
• Build for the Next Model — 這正是本文要防範的反向紀律：「它幾乎可以運作」是一種能力上的押注，而不是問題真實存在的證據（也就是把原型當證據的陷阱）
• Prototype Over PRD — 同樣的提醒：一個快速、作為規格的原型，證明的是建構是可行的，而不是問題是真實的；驗證仍然要透過使用者來進行

待解決的問題#

• 要 AI 反駁一個構想，真的能產出和支持性證據同樣嚴謹的反證嗎？還是模型仍會偏向創辦人所呈現的框架？值得衡量。
• 這份指南建議「要 Claude 提出最有說服力的論點，說明為什麼競爭對手會成功、而你不會」。這與 Anthropic 公開的角色訓練（抵抗奉承、願意唱反調）會如何互動？
• 有沒有人衡量過 2026 年用 AI 打造產品的新創失敗率？「42% 會攀升」這個說法是在沒有量測的情況下被斷言的。

資料來源#

• The Founder's Playbook: Building an AI-Native Startup — Idea Stage 章節（挑戰 + How Claude can help）
• Research: Why You Shouldn’t Treat AI Agents Like Employees — 關於 AI 定位效應的佐證（張力）