問題－解法契合度的紀律

資料來源#

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

摘要#

The Founder's Playbook: Building an AI-Native Startup 的構想階段論點是：當代理式編碼讓原型製作幾乎免費時，在開發「之前」進行驗證的紀律，會變得更難維持，而不是更容易。該手冊認為，CB Insights 在 AI 時代之前統計的 42%「做出了沒人想要的東西」新創失敗率，「只會繼續攀升」，因為抵禦過早開發的三道結構性防線同時遭到削弱——「時間成本」（消失）、「資源成本」（消失），以及「信念摩擦」（AI 現在能隨時提供確認式研究）。補救方法是結構化的對抗性思考：要求 AI 反駁這個想法、尋找不支持它的證據，並駁斥該假設。

三道遭削弱的防線#

1. 時間成本（消失）#

代理式開發之前：基本原型需要數月時間。成本本身會迫使創辦人先向自己和他人證明為何值得開發，進而促成驗證對話。

代理式開發之後：一個下午就能做出原型。「AI 讓創辦人太容易直接投入開發，而不先驗證它在真實世界中的效用。」

2. 資源成本（消失）#

代理式開發之前：聘請工程師或委託開發工作室需要資金；這又需要與投資人對話，迫使驗證更加嚴謹。

代理式開發之後：單人創辦人 + Claude Code。「我有個想法」與「我有個原型」之間不再有外部檢查。

3. 信念摩擦（如今站在 AI 這邊）#

「要求 AI 驗證你的新創想法，它會找到支持證據；要求它估算你的潛在市場，它會找到一個讓你的 TAM 看起來足以獲得融資的數字。」

這是三者中最陰險的一道。確認偏誤一直都存在；新的是，創辦人現在可以為一個糟糕的想法產出一份看起來經過充分研究的驗證文件，同時完全相信自己正在進行盡職調查。AI 會遵循指示——提出軟問題的創辦人得到的也是看似強硬的軟答案。

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

該手冊點出一個特定的認知錯誤：

「許多第一次創業的創辦人（甚至有經驗的創辦人）誤以為 AI 能繞過［驗證］，把流程變成 有個想法 → 立刻建立原型 → 把原型存在視為驗證。原型成了相信假設從一開始就是正確的理由，卻從未測試它是否真的成立。」

可運作的原型具體可見，也會帶來進展感。但原型只能驗證「開發任務」可解決，不能驗證「問題」確實存在，或「解法」是否契合。該手冊重新框定了原型的正確用途：「作為與潛在使用者對話時用來壓力測試的道具。這些對話本身才是真正的證據。」

解藥：把 AI 當作唱反調者#

該手冊的核心技巧，是使用同一個會產生確認偏誤的 AI 工具來產生反證：

「AI 對一個想法進行壓力測試的徹底程度，與它驗證一個想法一樣。」

具體做法：

1. 把假設磨利，直到它可被測試。「合約審查花太久」不可測試。「中型市場公司的內部法務團隊，每次合約審查週期都要花 3 天以上，因為修訂意見分散在電子郵件串中，而不是集中於單一具版本控制的文件裡」則可測試。
2. 要求 Claude 反駁這個想法。 找出失敗的競爭者、負面的市場訊號、結構性障礙，以及支持式綜合分析會悄悄降低優先級的客戶行為模式。
3. 要求 Claude 為「為什麼競爭者會成功，而你不會」提出最有說服力的論點。 這能反制「忽視競爭者」（過度專注於自身願景，以致系統性低估他人所做事情）的問題。
4. 檢查自己的訪談問題，找出引導式、面向未來，或誘發社會期許答案的模式。 新手常犯的錯誤是：「你會使用類似這樣的東西嗎？」（假設性、社交性）相較於「告訴我你上次處理這個問題的情況」（過去、具體）。
5. 每完成五次訪談後，產出兩份清單——支持證據與挑戰證據。 如果支持證據明顯較長，請問自己：這種不對稱反映的是資料中的情況，還是你希望找到的東西？

該手冊明確指出：「在 AI 新創生命週期的每個階段，使用 Claude 作為結構化的唱反調者都是核心用例。」這並非只適用於構想階段的紀律。

退出條件#

構想階段在以下三件事都成立時結束：

1. 問題真實且具體——你能說出誰會遇到它、頻率多高、嚴重程度如何，以及他們今天怎麼處理。
2. 你的解法處理的是「實際問題」——而不是你最初假設的問題；驗證往往會揭示一個不同於起點的新問題。
3. 有足夠訊號支持開發——有質性證據表明，投入製作 MVP 是經過理性推導的，而不是出於信念。

第 2 點的轉變是承重結構：讓驗證過程重塑問題的創辦人，比起只驗證「原始」問題假設的創辦人，進行了更嚴謹的驗證。

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

該手冊的「Loss of Objectivity」章節，正是對「研究引擎式確認偏誤」失敗模式的特定命名。其運作機制如下：

• 創辦人天生會對自己的想法充滿熱情（這是角色本身的特性）。
• AI 會以高度熱忱和高品質遵循指示（這是工具本身的特性）。
• 兩者結合後，會快速產出一份研究品質媲美、但論點完全有缺陷的成果，速度快到創辦人甚至察覺不到其中缺少證偽嘗試。

解藥就是以對抗方式使用同一個工具。紀律不是少用 AI，而是使用 AI 主動尋找不支持自身論點的證據。

相關連結#

• Polish No Longer Signals Readiness——姊妹陷阱：原型即準備就緒（看起來可以發布，其實不行），與原型即證據（證明開發成功，卻沒證明問題存在）並存
• AI-Native Startup Lifecycle——構想階段的核心論點
• 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——同樣的形狀：要求模型批評自己的輸出，作為除錯工具的測試框架技巧
• Narrow Wedge into a Legacy Market——John Glasgow 在 GTM 中執行問題－解法契合度的方式：創辦人－市場契合度選擇一個狹窄、真實且親身承受痛點的子群，而不是基於信念押注廣泛市場
• Founder-Led Sales Discipline——持續待在每個客戶 Slack 頻道中，才能不斷找到真正的問題－解法契合度，而不是研究引擎式確認偏誤
• Compounding Loop Optimization——緊密、反覆多次的迴圈，讓 Claude Design 在一週而非一季內發現錯誤押注（進階使用者控制）；這是執行實驗紀律的上線後形式
• Build for the Next Model——這套紀律所防範的反面： 「幾乎能運作」是能力押注，不是問題確實存在的證據（把原型當作證據的陷阱）
• Prototype Over PRD——同樣的提醒：快速的原型即規格，證明開發可行，卻沒證明問題真實存在；驗證仍須透過使用者進行

開放問題#

• 要求 AI 反駁一個想法，真的能以與確認證據相同的嚴謹程度產生反證嗎？還是模型仍會偏向創辦人提供的框架？值得測量。
• 該手冊建議「要求 Claude 為競爭者為何會成功、而你不會提出最有說服力的論點」。這與 Anthropic 發布的角色訓練（抗諂媚、願意唱反調）如何互動？
• 有人測量過採用 AI 建構產品的新創在 2026 年的失敗率嗎？「42% 會攀升」這項說法沒有測量依據，僅被直接提出。

資料來源#

• The Founder's Playbook: Building an AI-Native Startup——Idea Stage 章節（挑戰與 Claude 能提供的協助）
• Research: Why You Shouldn’t Treat AI Agents Like Employees——關於 AI 框架效應的補充證據（張力）