問題解決契合度的紀律

資料來源#

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

摘要#

The Founder's Playbook: Building an AI-Native Startup 在構想階段的核心論點是：當代理式程式設計讓原型幾乎不花成本時，維持「先驗證、再開發」的紀律會變得更難，而非更容易。該手冊指出，42% 的新創公司失敗是因為「做出沒人想要的東西」（CB Insights，AI 時代前）；這個比例「只會繼續攀升」，因為三道防止過早投入開發的結構性防線同時消退了——時間成本（消失）、資源成本（消失）以及信念阻力（現在 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 點的轉變至關重要：只驗證原始問題假設的創辦人，驗證得還不如願意讓驗證過程重新塑造問題的創辦人嚴謹。

與「客觀性流失」的關聯#

該手冊以「客觀性流失」來具體描述研究引擎式確認偏誤的失敗模式。其機制如下：

• 創辦人天生會熱衷於自己的點子（這是角色特性）。
• 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 — 同樣的概念：要求模型批判自己的輸出，作為調整 harness 的技巧
• 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 — 同樣的提醒：快速原型作為規格，只能證明開發可行，不能證明問題真實存在；驗證仍須透過使用者進行
• The 1% Rule for Wedge Selection — 正交的篩選條件：本篇檢驗問題是否真實，Dean 的法則檢驗答案面對接下來兩次模型發布時是否仍然持久。沒有人有的問題，即使成功率為 0%，仍是糟糕的生意；因此他把熱情與實用性排在自己的能力測試之前
• Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — 將技巧與其底層基礎區分開來：透過提示要求唱反調，是可移植的框架遵循；未經提示便提出、真正承載認識論分量的反駁，則來自訓練出的特質

開放問題#

• 要求 AI 反駁一個點子，真的能以與確認證據同樣嚴謹的方式產生反證嗎？還是模型仍會偏向創辦人提出的框架？值得測量。
• 有人測量過 2026 年 AI 開發產品的新創公司失敗率嗎？「42% 只會繼續攀升」的說法並無測量依據。

已解答問題#

• 該手冊建議「請 Claude 提出最有說服力的論點，說明競爭者為何會成功而你不會。」這和 Anthropic 發布的特質訓練（抗諂媚、願意唱反調）有何關係？已解答：Playbook Boundary Conditions: the Devil's-Advocate Substrate and the Prototype's Edge — 兩者互補而不衝突：這些提示做法是框架遵循任務，任何遵循指示的模型都能執行（都不要求模型反對創辦人）；特質訓練則提供提示無法憑空製造的未經提示的反駁——可移植的技巧、特定供應商的安全網，而剩餘差距（指定對抗任務中的框架偏誤）就是上方同屬一系列的 #oq/source。

資料來源#

• The Founder's Playbook: Building an AI-Native Startup — 構想階段章節（挑戰 + Claude 如何提供協助）
• Research: Why You Shouldn’t Treat AI Agents Like Employees — 關於 AI 框架效應的補充證據（存在張力）