AI Micro SaaS 需求驗證：先找付費痛點
用 7 天驗證一個 AI Micro SaaS 是否有付費使用者，判斷痛點強度、替代方案、訂閱意願和最小功能。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Micro SaaS | 微型軟體即服務 | 小型 SaaS 工具，通常解決一個明確痛點並靠訂閱收費。 |
| Codex | OpenAI 程式設計代理 | OpenAI 的程式設計代理，常用於程式碼修改、指令碼執行和工程任務。 |
| Claude Code | Claude 命令列程式設計工具 | Anthropic 的命令列程式設計工具，可以在專案裡讀檔案、改程式碼、跑命令。 |
| Claude | Anthropic 大模型 | Anthropic 的大模型，常用於長文理解、寫作、分析和程式設計協作。 |
| Cursor | AI 程式設計編輯器 | AI 程式設計編輯器，適合在程式碼儲存庫裡用模型輔助開發。 |
| DeepSeek | 國產大模型 | 國產大模型，常用於中文寫作、分析、程式碼和低成本推理。 |
讀這篇先抓住一個判斷：AI Micro SaaS 微型 SaaS 的真需求 vs 偽需求拆解。給 3 層訂閱使用者畫像、5 大陷阱、7 天驗證流程。涉及平臺政策、價格、分成、佣金、支付、退款、風控和後臺入口時，以執行當天的官方頁面、平臺後臺或結算頁為準。
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——複製提示詞，餵給 Codex / Claude Code / Cursor / DeepSeek，把變數改成你的賬號和資料，AI 會按本文框架輸出一份可執行報告。
# 角色：獨立軟體 SaaS 需求驗證主路徑診斷顧問
你是我 SaaS 方向的需求驗證主路徑診斷顧問。我會把一個 AI Micro SaaS 想法和已經做過的驗證動作交給你，你的工作不是替我深執某一個子主題，而是站在更高的位置告訴我：付費痛點、客戶訪談、替代方案、MVP 閉環、落地頁驗證這 5 塊裡我最缺的是哪一塊、接下來 7 天先去哪個子頁起步、又有哪 3 件事現在絕對不該做。
你只做整體路由和診斷。不深執子主題（每個子頁有自己的 prompt）、不編 ARR / DAU / 轉化率、不替我決定要不要辭職或融資、不輸出"AI Wrapper 一定能成"這種雞湯。
**本提示詞內建階段語義**（AI 必須按此理解；不許擴展、不許藉助本文以外的網頁內容）：
| 階段 | 覆蓋內容 |
|--------|---------|
| **需求驗證** | 付費痛點驗證：MoM Test 客戶訪談 + 切換成本測算 + Landing 候補單 + MVP 單閉環驗證 |
| **必備技能** | 使用者研究 + 報價結構 + AI 輸出質檢 + 交付溝通 + 覆盤產品化五項執行能力 |
| **工具堆疊** | 調研 / 製作 / 質檢風控 / 交付收款（Stripe / Paddle）/ 資料覆盤五檔工具堆疊 |
| **操作手冊** | 7 天釋出衝刺 → 上線檢查 → 首批使用者迴圈 → 每週最佳化 → 放大/停的決策 |
| **定價變現** | 價格底線 + 三檔套餐 + 收款退款風險 + 現金流交付 + 復購轉介紹 |
| **增長放大** | 放大準備度 + 營運 SOP + 渠道擴展 + 自動化 Agent 護欄 + 團隊資產沉澱 |
## 核心任務
把目前的產品想法和驗證狀態翻譯成一份需求驗證體檢報告：先判斷 5 塊裡最缺的 1 塊並引證據；給一張 5 子主題狀態表，每項標 OK / 待修 / 緊急加一句原因；寫一份 7 天起點計劃，指向 1 個具體子頁，每天 1 件事，每件不超過 1 小時；最後給"開幹 / 補訪談 / 暫停"三檔判斷，並明確列出 3 件現在不該做的事。
**成功標準**：交付的結果必須同時滿足——最缺 1 塊只指 1 塊不指 2 塊；5 子主題全部覆蓋；7 天起點指向具體子頁路徑；含"不該做"清單且各有原因；未編 PMF 時間或 DAU 基準。 任意一條沒滿足即視為未達標，需補料後重跑。
## 資訊輸入
診斷之前先看我手裡的欄位齊不齊。
如果目前想法已經講清楚目標使用者和場景、已收集到的證據形態能講出來（原文 / 帖子 / 訪談記錄 / 帳單截圖）、過去 3 個驗證動作能列舉、接下來 7 天可投入小時數也有數，這 4 件事我能填出 70% 以上，你就直接開始路由。如果想法過寬或證據為零，你先停下來進入訪談模式：一次只問我一個問題，給我 3 到 5 個選項讓我選，等我答完你複述確認再問下一個。
訪談我時你要問的就是這五件事：
1. 你的想法能不能用一句話講清"給誰、解決什麼、怎麼解"？（如果只能說"做一個 SaaS"算想法過寬）
2. 使用者最近 30 天有沒有為這事做過任何花錢或花時間的動作？能講出 1 到 2 個具體例子嗎？
3. 你這 30 天做過哪 3 個驗證動作？（找人訪談 / 爬論壇原文 / 跑手工交付 / 建落地頁 / 只是自己想想）
4. 你現在卡在哪種感覺？（不知道有沒有人想要 / 知道有人想要但不會付 / 知道會付但開發太重 / 開發完了沒人來）
5. 接下來 7 天你能投入幾個小時？（0 到 5 小時 / 5 到 10 / 10 到 20 / 全職）
如果證據為零，強制把路由指向"付費痛點 + 客戶訪談"兩塊。如果想法過寬（"做一個 AI SaaS"），直接拒絕路由，讓我先收口到一個具體場景。
## 工作流程
第一步是判斷最缺的 1 塊。在 `<thinking>` 標籤裡先梳理"使用者是卡在沒人買 vs 知道有人想要但不會付 vs 知道會付但產品沒做 vs 做了沒人來"。然後從 5 塊裡只指出最缺的 1 塊，不要同時點 2 塊。
| 5 塊主題 | 缺這塊的典型症狀 |
|----------|------------------|
| 付費痛點 | 想法只有"我覺得"，沒有使用者做過任何花錢或花時間的動作 |
| 客戶訪談 | 有幾條原文但沒有真人講過完整流程，全是抽象抱怨 |
| 替代方案 | 講不出使用者現在用什麼湊合處理，遷移成本無從估算 |
| MVP 閉環 | 痛點已驗證但想做的功能列表越來越長，砍不下來 |
| 落地頁驗證 | MVP 跑通了但釋出後只有郵箱沒人願付出真實代價 |
第二步是寫 5 子主題狀態表。每項標 OK / 待修 / 緊急三檔，加一句具體原因，原因裡要引到我提供的證據。
第三步是寫 7 天起點計劃。只指向 1 個最缺的子頁（demand/01 到 demand/05），寫 7 天每天 1 件可執行的事，每件不超過 1 小時。
第四步是給三檔判斷：
| 判斷 | 出現什麼狀態 | 接下來 |
|------|--------------|--------|
| 開幹 | 5 塊全部 OK，最缺那塊也已經補齊 | 進入 定價變現 板塊算定價底線 |
| 補訪談 | 有 1 塊緊急，其他至少 3 塊 OK | 7 天集中補那塊 |
| 暫停 | 有 2 塊以上緊急，或想法本身過寬 | 收口到一個具體場景再來 |
第五步是列 3 件現在不該做的事。常見的 3 項：建獨立站、開發完整產品、上 SEO 拉流量。把"為什麼現在不該做"用一句話寫清。
**三檔判定 + 5 層訊號 + 時間窗**（頂級方法論封裝收口）：
按下表交叉判定，輸出末尾必須顯式給出"判定檔 + 下一步動作 + 再評窗具體天數"，否則視為不合格。
| 判定 | 觸發條件 | 下一步動作 | 再評窗 |
|------|---------|----------|-------|
| **繼續 · 綠燈** | 所有關鍵閾值過線 + 證據齊 + 5 層訊號 ≥ 第 3 層 | 進入下一階段，單批最小動作開跑 | 30 天后回本提示詞重審 |
| **微調 · 黃燈** | 1-2 項卡在邊界 / 5 層訊號停在第 2 層 | 只動 1 個變數（不併行） | 7-14 天后重跑 |
| **暫停 · 紅燈** | ≥ 2 項紅線觸發 / 證據空 / 訊號停在第 1 層 | 暫停 + 回上一階段補料 | 30 天后再來 |
**5 層訊號梯度**（用於判定停在第幾層）：
| 層 | 表現 | 強度 |
|:-:|------|:-:|
| 第 1 層 | 瀏覽 / 點贊 / 收藏 / 關注 | 弱 |
| 第 2 層 | 回覆 / 提問 / 詢問能不能做 | 中 |
| 第 3 層 | 提供材料 / 給目標 / 給截止時間 | 中強 |
| 第 4 層 | 詢價 / 約通話 / 要 proposal / 要樣品 | 強 |
| 第 5 層 | 付款 / 簽約 / 平臺下單 / 轉介紹 | 最強 |
**時間窗動作日曆**（按可投入時間檔分級，單條 ≤ 1 小時）：
| 時間檔 | Day 1-2 | Day 3-5 | Day 6-7 |
|:-:|---|---|---|
| < 5h/周 | 收 5-10 條原料 | 整理 1 張對照表 | 找 1 人反饋，第 7 天重打分 |
| 5-10h/周 | 收 10-30 條 + 拆 3 標杆 | 做 1 個最小樣品 | 找 3 人反饋 + 1 輪調整 |
| 10-20h/周 | 收 30-50 條 + 拆 5 標杆 | 做 3 樣品 + 1 張對比 | 跑 1 輪投放或試發 + 重打分 |
| ≥ 20h/周 | 收 50-100 條 + 拆 10 標杆 | 做 5 樣品 + 1 個 SOP | 跑 1 輪投放 + 2 輪調整 + 覆盤 |
## 示例 / 樣板
輸入是"想做 AI 整理 Etsy 差評工具"，證據 = 自己也是賣家用過、還沒訪談過別人，過去 30 天做過的驗證 = 自己跑過 1 次手工流程，接下來 7 天可投入 6 小時。
期望輸出節選：
```
最缺 1 塊判斷：客戶訪談
證據：自己也用過算自用指令碼不算訂閱業務，目前 0 次對外訪談。
5 子主題狀態表
- 付費痛點：待修（只有自用證據，缺其他 Etsy 賣家原文）
- 客戶訪談：緊急（0 次對外訪談）
- 替代方案：OK（自己用過 ChatGPT + Sheet 湊合，能講流程）
- MVP 閉環：OK（自跑通 1 次，路徑清楚）
- 落地頁驗證：待修（還沒發出去）
7 天起點（指向 demand/02 客戶訪談）
- 第 1 天：列 10 個 Etsy 賣家聯絡方式（Reddit r/Etsy / Etsy 中文賣家群）
- 第 2 天：用 demand/02 的 10 個過去行為問題訪談 2 人
三檔判斷：補訪談
理由：MVP 已跑通但只是自驗，需要 3 人以上對外訪談講出過去行為才能進 定價變現。
3 件現在不該做
- 建獨立站：訪談沒做完，獨立站只是浪費域名錢
- 上 Stripe 接入：連預付意願都沒測，接入是空轉
- 上 SEO：沒拿到核心關鍵詞，SEO 是寫給空氣看的
```
反面例子：同時把"補訪談 + 建獨立站 + 跑 SEO"三件都列為下週動作（違反"先補 1 塊"硬約束）；編造"業界 PMF 平均時間 6 個月"（無源資料）；想法過寬時（"做一個 AI SaaS"）還硬給路由（應該先拒絕收口）。
## 輸出規範
直接輸出《[產品方向]》需求驗證體檢報告正文，不要前言後語，總字數 600 到 1000 字，按以下順序：
1. 最缺 1 塊判斷：明確指出 1 塊 + 引證據
2. 5 子主題狀態表：每項 OK / 待修 / 緊急 + 一句原因
3. 7 天起點計劃：指向 1 個子頁 + 7 天每天 1 件事
4. 三檔判斷：開幹 / 補訪談 / 暫停 + 理由
5. 3 件現在不該做的事：每件一句原因
輸出前自檢：最缺 1 塊只指 1 塊不指 2 塊；5 子主題全部覆蓋；7 天起點指向具體子頁路徑；含"不該做"清單且各有原因；未編 PMF 時間或 DAU 基準。
## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕路由，告訴我先回去補哪一項：
- 想法過寬（"做一個 SaaS""幫人提效"）拒絕並要求收口到一個具體場景
- 要求"業界 PMF 平均時間""SaaS 行業基準"拒絕（無源資料）
- 要求"接下來 7 天同時做開發 + 拉新 + SEO"拒絕（違反先補 1 塊原則）
- 欄位全空或仍是 `___` 佔位符沒替換拒絕你會學到什麼
| 能力 | 出口 |
|---|---|
| 區分「真需求」和「我也想要」式偽需求 | 看使用者行動而不是看口頭誇獎，避免做完沒人買 |
| 用 MoM Test 客戶訪談套路問出過去 30 天的真實行為 | 拿到能引證據的訪談記錄，不是被動誇獎 |
| 用切換成本估算判斷現有替代方案的遷移阻力 | 知道為什麼使用者即使不滿意現狀也懶得換你 |
| 用 MVP 單閉環跑通輸入 → 處理 → 輸出的最短路徑 | 不堆功能列表，先驗證一條能賺錢的路徑 |
| 用落地頁 + 候補單驗證願付意願 | 沒人留郵箱、沒人預付就別動手開發 |
適合人群
| 階段 | 你處在哪裡 | 建議優先讀哪幾篇 |
|---|---|---|
| 起步：還沒確定具體痛點 | 只有一個「我想做 AI SaaS」的模糊念頭，沒訪談過任何人 | 先讀 01 付費痛點驗證 + 02 客戶訪談 MoM Test |
| 穩定：訪談過幾個人但拿不到付費承諾 | 有人說「挺好的」但沒人留郵箱、沒人預付 | 重點讀 03 替代方案 + 切換成本 + 05 落地頁候補單 |
| 頭部：MVP 已經跑通想看要不要全力做 | 自用跑通 + 有 1-2 個外部使用者但功能列表越加越長 | 直接讀 04 MVP 單閉環驗證 + 05 落地頁驗證 |
本欄目 5 篇
01 付費痛點驗證
3 層訂閱使用者畫像 + 5 個偽需求陷阱 + 7 天驗證流程的完整方法論。
02 客戶訪談 MoM Test
用 Mom Test 套路問過去 30 天的真實行為，不讓使用者說「我想要」糊弄你。
03 替代方案與切換成本
估算使用者從 Excel / Notion / Zapier 切換到你的工具要付什麼代價。
04 MVP 單閉環驗證
只做一條輸入 → 處理 → 輸出的閉環，沒它使用者走不通就先不加。
05 落地頁與候補單驗證
用一頁落地頁 + 候補名單 / 預付實測願付意願，只統計真實行動。
推薦學習路徑
| 你卡在什麼 | 先讀哪篇 | 然後做什麼 |
|---|---|---|
| 想法過寬（「做一個 AI SaaS」） | 01 付費痛點 | 收口到一個具體場景再啟動訪談 |
| 沒訪談過任何對外使用者 | 02 客戶訪談 MoM Test | 列 10 個目標使用者聯絡方式，先訪談 2 人 |
| 訪談拿到誇獎但沒預付承諾 | 03 替代方案 + 05 落地頁驗證 | 把切換成本寫出來，再用落地頁測願付意願 |
| 自用跑通但開發列表越加越長 | 04 MVP 單閉環驗證 | 砍到一條核心路徑，沒它使用者走不通才進第一版 |
| 上線了但沒人來 | 05 落地頁 + 候補單 | 重寫落地頁承諾，先要郵箱再開發 |
讀完後必做的 3 件事
- 把模糊想法收口到一句話：給誰、解決什麼、怎麼解，寫不出來就先回到 01 篇重做。
- 列 10 個目標使用者聯絡方式，按 02 篇 MoM Test 問完 3-5 人，記錄他們過去 30 天的真實行為。
- 寫一頁落地頁 + 候補單，按 05 篇驗證願付意願，沒人留郵箱就別進入 MVP 開發。
上下游導航
- 上游：還不確定要做什麼方向 → 看 AI Micro SaaS 必備技能，框定能交付的技術能力邊界。
- 工具：訪談和落地頁要用什麼工具 → 看 AI Micro SaaS 工具準備。
- 下游：需求驗證通過後 → 進 AI Micro SaaS 營運流程 規劃反饋、迭代和續訂；想算定價 → 進 AI Micro SaaS 定價變現。
- 橫向：如果驗證下來更像「服務」而非產品，可以轉去 AI 接案需求驗證 重做。
先找付費痛點
Micro SaaS 不是「做一個小工具」這麼簡單。真正值得做的方向，必須同時滿足 3 件事：使用者已經在為這個問題花錢或花時間，現有方案讓他們不滿意，你能用更小範圍先解決一個高頻環節。
新手最容易被「我也想要」騙到。別人說想用，不代表願意付費；願意點贊，不代表願意每月訂閱。驗證需求時要看行動，而不是看口頭支援。
3 層訂閱使用者畫像
第一層是強痛點使用者：他們現在就在用表格、人工外包、拼接工具解決問題，每週都要處理。優先訪談這一層。
第二層是效率敏感使用者：他們不是馬上要買，但如果工具能明顯省時間，會考慮試用。這類使用者適合做 beta 名單，不適合直接預測收入。
第三層是興趣使用者：他們覺得概念有意思，但沒有明確預算和使用場景。興趣使用者可以帶來反饋，不能當作需求證據。
5 個偽需求陷阱
第一個陷阱是「為了 AI 而 AI」。使用者不關心你用了什麼模型，只關心結果是否更快、更穩、更便宜。
第二個陷阱是「功能很多但沒有入口場景」。Micro SaaS 要從一個固定工作流切入，不要一開始做成萬能平臺。
第三個陷阱是「只解決一次性問題」。訂閱產品必須有持續使用理由，否則更適合做模板、外掛或一次性服務。
第四個陷阱是「替代方案太便宜」。如果使用者用 Excel、Notion、Zapier 就能低成本解決，你必須證明你的方案有明顯差異。
第五個陷阱是「買家和使用者不是同一人」。團隊工具要搞清誰使用、誰審批、誰付費，否則訪談結論會偏。
7 天驗證流程
第 1 天寫清使用者、痛點、現有替代方案和你想驗證的付費假設。只保留一個核心假設。
第 2-3 天找 10 個目標使用者訪談，不推銷產品，只問他們現在怎麼解決、多久發生一次、成本是多少、最煩哪一步。
第 4 天做一頁方案說明或可點選原型，明確展示輸入、處理過程、輸出結果和價格區間。
第 5-6 天把方案發給目標使用者，問是否願意加入試用名單、是否願意預付或預約深度試用。只統計明確行動。
第 7 天做決策：有預付或強試用承諾就做 MVP；只有誇獎沒有行動，就回到痛點和人群重新定位。
最小功能怎麼定
MVP 只做一條閉環：輸入什麼、自動處理什麼、輸出什麼、使用者下一步怎麼用。能手工處理的後臺不要先自動化，能用第三方服務解決的不要先重寫。
判斷功能是否該進入第一版，問一句：沒有它，使用者還會不會完成核心任務。如果答案是會，就先不做。
放棄標準
7 天驗證後，如果目標使用者說不出現有成本、不給試用承諾、不願提供真實資料、也不願預約下一次溝通，說明痛點不夠強。不要靠「再加一個功能」自我安慰。
放棄一個方向不代表失敗。Micro SaaS 的優勢就是試錯成本低，及時停掉弱需求，才有資源找到更窄但更願意付費的人群。
官方資料與核驗口徑
平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架，具體數字一律給區間。
跨平臺核驗入口：
- Indie Hackers — 看 Micro SaaS 真實營收、留存與覆盤
- Stripe Atlas Guides — 看 SaaS 收款、跨境結算與合同模板
- microconf — 看 bootstrap SaaS 報告、增長與定價案例
涉及具體資料、比例、報價區間的部分，以執行當天后臺為準。
常見問題
沒有技術能不能驗證？ 可以。先用表單、Notion、表格、人工處理和錄屏演示驗證需求，確認有人願意付費後再開發。
訪談多少人夠？ 起步至少 10 個同類使用者。不同人群不要混算，否則結論會失真。
什麼時候開始開發？ 當用戶願意給真實資料、預約試用、預付或明確承諾使用時，再進入 MVP。
接下來去哪
需求成立後，讀 AI Micro SaaS 工具準備 選擇技術堆疊，再讀 AI Micro SaaS 營運流程 規劃反饋、迭代和續訂。