核心概念

MVP 階段的核心問題：「我該做的最小版本是什麼？人們會不會真的用它？」

這個階段仍然是收集證據的過程，只是對象從「問題」換成「方案」：有沒有一群明確的人覺得它有價值、會使用、會回來用、願意付費、或願意告訴別人？

離開 MVP 階段的條件：

有「產品-市場契合度」（PMF）的真實證據：

  • 一群具體、可辨識的用戶覺得產品有價值
  • 留存（持續回來用）、營收（願意付費）、或推薦（告訴別人）中至少一個有信號

三個並行目標：

  1. 把驗證過的問題變成真人會用的產品（最小、最聚焦版本）
  2. 快但不要埋地雷（這個階段的決策決定後面能走多遠）
  3. 從第一天建立持續的知識脈絡（規格書、架構決策文件、CLAUDE.md）

關鍵要點

AI 時代技術債的新形態：

AI 不只加速開發，也加速累積技術債。問題不在於單一功能寫得不好，而是當架構決策沒有寫下來放到 AI 讀得到的地方時，每次開發都得從頭猜意圖，最後程式碼變成功能上可跑但結構上不成體系的東西。

解法：在 Claude Code 寫第一行正式程式碼之前，先定義和記錄架構決策，這份文件成為所有開發的護欄。

四個最常犯的錯：

  1. AI 時代技術債 — 速度是保證的，品質不是；上線前做一次安全檢查
  2. 把早期成績當 PMF — 發布動能來自朋友和曝光，不能預測六週後的留存
  3. 零阻力範圍蔓延 — 每個「再加一個功能」都說得通，但讓產品失去方向；事前寫好範圍定義：做什麼、刻意不做什麼
  4. 安全疏忽 — AI 產出「能動的程式碼」不是「安全的程式碼」；真實數據需要真實保護

實務應用

架構優先 → 再開始寫程式的工作流程：

  1. 用 Claude Chat / Cowork 定義架構決策，記錄下來
  2. 把架構文件放在 Claude Code 讀得到的地方（如 CLAUDE.md）
  3. Claude Code 按架構指引開發，而不是每次重新猜意圖

早期成長 ≠ PMF 的訊號差異：

訊號 說明
假 PMF 朋友試用、媒體曝光帶來的一次性流量
真 PMF 自發回流、付費意願、主動推薦

相關頁面：AI 時代的創辦人角色 創業想法驗證指南 現金流管理與創業跑道計算 GTM 上市策略框架 AI 驅動一人公司創業規劃

延伸觀點

PMF 是光譜，不是開關——「第二次使用率」才是 AI 產品的真正指標（跨源共識）

Bessemer Venture Partners 的 AI 創辦人手冊與多份 2025-2026 研究都指向同一個觀點：AI 產品的早期高增長極容易被誤讀為真正的 PMF，但背後可能只是新奇感。真正的 PMF 判斷標準應該是「用戶是否無法想像沒有你的產品而工作」。最具 AI-native 性格的衡量指標是第二次使用率（second-bite usage rate）：用戶完成第一個用例後，是否自發回來處理類似任務。這比整體留存率更能區分「被拉去試用」和「真的被整合進工作流」。Time to Value（TTV，用戶多快看到價值）也是早期 PMF 評估的關鍵維度。

範圍窄，留存高——40% 差距來自焦點（跨源共識）

CB Insights 2026 年更新的分析指出，70% 的失敗 MVP 把「功能太多」列為主因，而聚焦在單一驗證過的痛點的 MVP，前 90 天用戶留存率比廣泛定義範圍的版本高出 40%。這和 Anthropic 手冊裡「MVP 的核心是最小」完全一致——不是因為資源不夠，而是窄範圍才能產生清晰的 PMF 信號。

AI 生成程式碼的安全現實：「能動」≠「安全」（跨源共識）

多項 2025-2026 獨立研究顯示，AI 生成程式碼含有安全漏洞的比例在 18-50% 之間。更具體的情境：YC 2025 冬季梯隊中，25% 的新創有超過 95% 的程式碼由 AI 生成，安全研究人員在一個下午就掃出 170 個存在漏洞的生產應用。此外，2025 年 GitHub 上有 2,900 萬組 credentials 外洩，其中大量源於 vibe coding 流程中的憑證管理疏忽。這些數字支持了 Anthropic 手冊的建議：上線前的安全審查是最低負責任門檻，而非可選項。

反向連結

以下頁面引用了本頁：