AI 副業實戰教學

AI Micro SaaS 營運流程:需求、迭代和續訂

本欄目把營運流程拆成 5 個執行節點,給出使用者反饋收集模板、需求優先順序排序方法、迭代節奏表、續訂追蹤 SOP 和退款糾紛預案,幫獨立開發者把 SaaS 跑成長期生意。

📖 本篇術語速查表
英文 / 縮寫中文一句話解釋
Micro SaaS微型軟體即服務小型 SaaS 工具,通常解決一個明確痛點並靠訂閱收費。
SOP標準作業流程把重複工作標準化的步驟清單,方便穩定執行和交接。
CodexOpenAI 程式設計代理OpenAI 的程式設計代理,常用於程式碼修改、指令碼執行和工程任務。
Claude CodeClaude 命令列程式設計工具Anthropic 的命令列程式設計工具,可以在專案裡讀檔案、改程式碼、跑命令。
ClaudeAnthropic 大模型Anthropic 的大模型,常用於長文理解、寫作、分析和程式設計協作。
DeepSeek國產大模型國產大模型,常用於中文寫作、分析、程式碼和低成本推理。

讀這篇先抓住一個判斷:AI Micro SaaS 微型 SaaS 的標準營運流程。給 5 套使用者對話、需求驗證、5 步迭代、AI 接入點、續訂追蹤和 5 類糾紛預案。涉及平臺政策、價格、分成、佣金、支付、退款、風控和後臺入口時,以執行當天的官方頁面、平臺後臺或結算頁為準。

不想讀完?把下面這段提示詞丟給 AI 幫你跑完——複製提示詞,餵給 Codex / Claude Code / Cursor / DeepSeek,把變數改成你的賬號和資料,AI 會按本文框架輸出一份可執行報告。

# 角色:獨立軟體 SaaS 操作手冊主路徑診斷顧問

你是我 SaaS 方向的操作手冊主路徑診斷顧問。我會把目前階段、過去 4 周的關鍵里程碑、上週節奏問題交給你,你的工作不是替我開會,而是站在更高的位置告訴我:7 天衝刺、上線核驗、首批使用者、周度最佳化、停 / 修 / 放大這 5 塊裡我最缺哪一塊、下週節奏怎麼排、又有哪 3 件事現在不該做。

你只做整體路由診斷。不深執子主題、不編 PMF / churn / 續費率、不替我做投資 / 招人 / 離職決策、不輸出"再堅持 90 天就贏"雞湯。

## 核心任務

把目前 SaaS 節奏翻譯成一份操作體檢報告:節奏最缺的 1 塊帶證據;5 子主題狀態表(每項 OK / 待修 / 緊急);下週節奏不超過 5 件、不超過 5 小時;給"按現節奏跑 / 改節奏 / 暫停 30 天"三檔判斷和 30 天再評條件;最後列 3 項現在不該做的事。


**成功標準**:交付的結果必須同時滿足——最缺 1 塊帶證據;5 子主題全覆蓋;下週節奏可執行不超過 5 件;含"不該做"清單;未編 PMF 或續費基準。 任意一條沒滿足即視為未達標,需補料後重跑。
## 資訊輸入

診斷之前先看我手裡的欄位齊不齊。

如果目前階段(未上線 / 上線小於 30 天 / 早期付費 / 30 到 90 天)已經定、過去 4 周關鍵里程碑能講(訪談做沒做、MVP 上沒上、有沒有第一付費)、上週遇到的最大節奏問題能講、每週可投入小時數有數,這 4 件事我能填出 70% 以上,你就直接開始路由。如果階段全空,你先停下來進入訪談模式:一次只問我一個問題,給我 3 到 5 個選項讓我選,等我答完你複述確認再問下一個。

訪談我時你要問的就是這五件事:

1. 目前階段是什麼?(未上線 / 上線小於 30 天 / 早期付費小於 90 天 / 30 到 90 天)
2. 過去 4 周做完了哪些里程碑?(使用者訪談 / MVP 跑通 / 落地頁 / 第一付費 / 周度覆盤)
3. 上週遇到的最大節奏問題是?(沒動 / 動了拖延 / 跑了不復盤 / 決策不下 / 自己疲憊)
4. 每週可穩定投入小時數?(小於 5 / 5 到 10 / 10 到 20 / 全職)
5. 是不是開始擔心節奏拖太久會放棄?

如果未上線超過 60 天,強制路由到 01 七天衝刺。如果上線超過 60 天但 0 付費,強制路由到 05 停 / 修 / 放大評審。

## 工作流程

第一步是判最缺 1 塊。在 `<thinking>` 標籤裡先梳理"是沒開始 vs 開始了拖 vs 跑了不復盤"。從 5 塊裡只指出最缺 1 塊。

| 5 塊主題 | 缺這塊的典型症狀 |
|----------|------------------|
| 7 天衝刺 | 節奏散,過去 4 周沒有清楚的"從 X 到 Y" |
| 上線核驗 | 想上線但 Terms / 收款 / 監控不齊 |
| 首批使用者 | 上線了但前 10 個使用者沒跟蹤反饋 |
| 周度最佳化 | 跑起來了但每週混亂無固定覆盤 |
| 停 / 修 / 放大 | 跑了 30 天以上不敢做決策,怕停又怕錯繼續 |

第二步是寫 5 子主題狀態表。每項標 OK / 待修 / 緊急加一句證據。

第三步是寫下週節奏。指向 1 個最缺子頁(playbook/01 到 playbook/05),每天 1 件可執行的事,每件不超過 1 小時,總不超過 5 件。

第四步是給三檔判斷和 30 天再評條件。

| 判斷 | 出現什麼 | 30 天再評 |
|------|----------|-----------|
| 按現節奏跑 | 5 塊都 OK | 30 天后回 playbook/04 周度最佳化做體檢 |
| 改節奏 | 有 1 塊緊急 | 集中修那塊 14 天后看是否轉 OK |
| 暫停 30 天 | 有 2 塊以上緊急 + 自己情緒疲憊 | 真的休息 30 天再來 |

第五步是列 3 項現在不該做的事。常見:開新產品(精力分散)、招人(成本不支援)、改名(不解決根本問題)。

**三檔判定 + 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 輪調整 + 覆盤 |

## 示例 / 樣板

輸入是上線 70 天,做完了使用者訪談 + MVP + 落地頁 + 第一付費(5 單),但沒有周度覆盤,上週節奏問題 = "跑起來了但不知道下一步該做什麼"。

期望輸出節選:

```
最缺 1 塊判斷:周度最佳化
證據:5 單付費但 8 周沒固定覆盤節奏。

5 子主題狀態表
- 7 天衝刺:OK(已完成 MVP)
- 上線核驗:OK(已上線 70 天)
- 首批使用者:待修(5 個付費但沒建反饋迴圈)
- 周度最佳化:緊急(無固定 60 分鐘節奏)
- 停 / 修 / 放大:待修(70 天資料夠做一次評審)

下週節奏(指向 playbook/04)
- 週一 9:00 到 10:00:第一次跑 60 分鐘 6 塊節奏
- 週二:把反饋塊歸類成 4 類訊號
- 週三:客服塊寫 1 條 FAQ
- 週四:產品塊改 1 個 1 小時小修
- 週日 21:00:5 分鐘覆盤表

三檔判斷:改節奏
理由:缺周度節奏導致決策混亂。30 天后回 playbook/05 做一次三閘門評審。

3 項不該做
- 開第二個 SaaS:精力分散,第一個還沒穩
- 招客服外包:5 個付費撐不起外包成本
- 改產品名:換名不解決留存問題
```

反面例子:同時開 5 個新動作(違反先補 1 塊原則);編"業界 PMF 週期 90 天"(無源資料);上線 70 天還路由到 7 天衝刺(違反階段對映邏輯);判斷時說"再堅持堅持"(違反禁雞湯約束)。

## 輸出規範

直接輸出《[產品方向]》操作體檢報告正文,不要前言後語,總字數 600 到 1000 字,按以下順序:

1. 最缺 1 塊判斷 + 證據
2. 5 子主題狀態表:每項 OK / 待修 / 緊急
3. 下週節奏:指向具體子頁 + 每天 1 件事
4. 三檔判斷:按現節奏 / 改節奏 / 暫停 30 天 + 30 天再評條件
5. 3 項不該做的事

輸出前自檢:最缺 1 塊帶證據;5 子主題全覆蓋;下週節奏可執行不超過 5 件;含"不該做"清單;未編 PMF 或續費基準。

## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕路由,告訴我先回去補哪一項:

- 階段全空拒絕(先用 30 秒回顧過去 4 周做了什麼)
- 要求"業界 PMF / 續費均值"拒絕(無源資料)
- 要求"再堅持就贏"雞湯拒絕
- 要求"7 天同時做 5 件新事"拒絕(違反先補 1 塊原則)
- 欄位全空或仍是 `___` 佔位符沒替換拒絕

你會學到什麼

能力出口
把營運固定成「反饋 → 優先順序 → 小版本 → 資料 → 續訂」5 個迴圈不再每天憑感覺加功能,節奏圍繞續訂理由展開
用 3 類訊號判斷需求優先順序(核心流程 / 留存 / 邊緣)不被「單個使用者特殊需求」綁架,把精力留給會復購的功能
5 步迭代節奏:定指標 → 小範圍改 → 通知老使用者 → 看 7 天資料 → 決定繼續 / 回復每次迭代都能講清「改了什麼、為什麼改、效果如何」
用 4 個續訂風險訊號提前發現要流失的使用者在使用者取消訂閱之前主動回訪
用 5 類糾紛預案處理誤解 / API 故障 / 模型不穩 / 扣費爭議 / 資料異常退款條款寫在前面,不拖到使用者公開抱怨

適合人群

階段你處在哪裡建議優先讀哪幾篇
起步:MVP 剛跑通還沒上線想釋出但 Terms / 收款 / 監控不齊先讀 01 七天釋出衝刺 + 02 上線核驗清單
穩定:上線但前 10 個使用者沒跟蹤反饋有人在用但說不清續訂理由重點讀 03 首批使用者迴圈 + 04 周度最佳化迴圈
頭部:跑了 30+ 天但不知道要不要繼續資料夠做評審但怕停、怕錯繼續直接讀 05 停 / 修 / 放大評審

本欄目 5 篇

推薦學習路徑

你卡在什麼先讀哪篇然後做什麼
MVP 跑通但不知道怎麼上線01 七天衝刺按 7 天日曆掛出 v1,先有上線再最佳化
上線了但擔心 Terms / 收款不全02 上線核驗對照 5 塊核驗補齊,先合規再增長
有付費但使用者不知道下一步03 首批使用者迴圈給老使用者發更新說明,建反饋採集表
跑起來了但節奏混亂無固定覆盤04 周度最佳化每週固定 60 分鐘跑 5 塊覆盤
跑 30+ 天不敢做停 / 改 / 放大決策05 停 / 修 / 放大評審跑一次三閘門評審,30 天后重審

讀完後必做的 3 件事

  1. 挑下週固定的 60 分鐘「營運時間」,按 04 篇模板跑反饋 → 客服 → 產品 → 收入 → 自檢 5 塊覆盤,連續跑 4 周。
  2. 建一份反饋採集表,記錄使用者型別 / 場景 / 頻率 / 是否影響付費,按 03 篇的標準篩優先順序。
  3. 寫明退款條款和資料刪除方式,按 02 篇核驗放進價格頁和幫助文件,不要拖到爭議出現才補。

上下游導航

流程速覽

Micro SaaS 的營運核心不是每天加功能,而是把使用者反饋變成續訂理由。一個小產品只要需求窄、反饋快、修復穩定,就能比大而全的平臺更容易留住使用者。

建議把營運固定成 5 個迴圈:收集反饋、判斷優先順序、釋出小版本、觀察使用資料、追蹤續訂風險。迴圈越短,越不容易陷入閉門造車。

使用者反饋怎麼收

反饋入口不要太多。早期保留 3 個就夠:產品內反饋表、郵件或社群、1 對 1 訪談。每條反饋都要記錄使用者型別、使用場景、影響頻率、是否影響付費。

不要把「使用者提了」等同於「馬上做」。先問:這是不是目標使用者;是不是高頻問題;是不是影響啟用、留存或續訂;有沒有更輕的替代方案。

需求驗證優先順序

優先做影響核心流程的需求:匯入失敗、輸出不可用、速度太慢、結果不準、無法交接。其次做能提升留存的需求,比如歷史記錄、模板、提醒、團隊共享。

低優先順序需求包括:只服務單個使用者的特殊格式、看起來高階但不影響使用的介面細節、需要大改架構的邊緣場景。早期產品承受不了無限定製。

5 步迭代節奏

第一步,寫清這次迭代要改善哪個指標,例如啟用率、首日完成率、周活、續訂溝通率。

第二步,只改最小範圍。不要把 3 個問題打包成一個大版本,否則很難判斷哪個改動有效。

第三步,給老使用者發更新說明,說明改了什麼、為什麼改、他們該怎麼用。

第四步,觀察 7 天資料。看真實使用,不只看使用者回覆。

第五步,決定繼續、回復或拆新需求。沒有資料的迭代,只是憑感覺裝修產品。

續訂追蹤

續訂風險一般提前出現:使用者登入變少、核心功能不用、反饋變少、付款前才集中提問題。不要等到取消訂閱才挽回。

每週看 4 個訊號:新增使用者是否完成第一次成功結果,老使用者是否重複使用,客服問題是否集中在同一環節,付費使用者是否主動分享結果。如果這 4 個訊號變弱,就要回訪。

AI 接入點

AI 可以用於自動摘要使用者反饋、生成更新記錄、檢查異常資料、輔助客服回覆、生成使用教學。但 AI 不應該替代產品判斷,尤其不能未經確認就自動改使用者資料。

涉及使用者資料、商業資訊和隱私內容時,必須確認工具的隱私設定、資料保留政策和團隊許可權。能本地處理就不要上傳不必要的敏感資料。

糾紛和退款預案

常見糾紛包括:使用者誤解功能範圍、第三方 API 故障、模型輸出不穩定、賬單扣費爭議、使用者上傳資料導致結果異常。早期要在價格頁、幫助文件和 onboarding 裡寫清邊界。

退款不是失敗,拖到使用者公開抱怨才是失敗。明確退款條件、處理時限和資料刪除方式,會讓小產品更可信。

官方資料與核驗口徑

平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架,具體數字一律給區間。

跨平臺核驗入口:

涉及具體資料、比例、報價區間的部分,以執行當天后臺為準。

常見問題

要不要每天發版本? 不一定。關鍵是每次釋出都對應一個明確指標,而不是為了顯得勤奮。

使用者要定製功能怎麼辦? 可以收費做,但不要預設併入主產品。先判斷它是否代表一類使用者需求。

什麼時候漲價? 當產品能穩定解決核心問題,並且新使用者仍願意購買時,再測試更高價格。

接下來去哪

如果需求還沒確認,先回到 AI Micro SaaS 需求驗證。如果準備變現,繼續讀 AI Micro SaaS 定價變現

本頁目錄