AI 副業實戰教學

Micro SaaS暫停或放大決策:用閘門決定繼續、修復或停止

『再堅持 90 天就贏』不是判斷標準。本文給你 Micro SaaS 停 / 修 / 放大三閘門評審單:6 維評分(含情緒)+ 總分對映唯一檔 + 30 天硬停條件 + 4 步收尾或 1 件加碼動作。

📖 本篇術語速查表
英文 / 縮寫中文一句話解釋
brief專案簡報寫清目標、輸入、輸出、範圍和驗收標準的檔案。
workflow工作流從材料到交付再到覆盤的一組步驟。
scope範圍本次包含和不包含的內容邊界。
QA質量檢查交付或釋出前檢查事實、格式、許可權和風險。
feedback loop反饋迴圈把使用者行為和原話轉成下一步修改。
playbook操作手冊本文所在的Micro SaaS操作手冊階段。
Prompt提示詞寫給 AI 的任務說明,用來生成執行方案。

讀完你能交付:一份《[你的產品]》三閘門評審報告(6 維評分 / 總分對映唯一判斷 / 30 天硬停條件 / 收尾或加碼動作)。 一句話錨點:用單位經濟和留存說話,情緒做參考不做決策;30 天后某指標低於 X 就必須停。

不想讀完?把下面這段提示詞丟給 AI 幫你跑完——複製提示詞,餵給 Codex / Claude Code / Cursor / DeepSeek,把變數改成你的專案,AI 會按本文 H2 輸出執行方案。

# 角色:獨立軟體 SaaS 停 / 修 / 放大三閘門評審顧問

你是我 SaaS 方向的停 / 修 / 放大三閘門評審顧問。我會把已營運時長、付費使用者數、Aha 達成率、單位經濟、留存、客服時間、自己情緒交給你,你的工作不是替我決定融資或退出,而是按 6 個維度評分,給"停止 / 繼續修 / 加碼放大"三檔判斷,並寫清 30 天最後視窗期硬條件。

你只做現狀評估。不替我做退出 / 融資 / 招人決策、不編"業界停損線""SaaS 放大 ARR 閾值"、不替我判斷要不要返工或重做、不輸出"再堅持 90 天就贏"雞湯。

## 核心任務

把目前 SaaS 營運狀態翻譯成一份三閘門評審單:6 個維度(付費使用者數 / Aha 達成率 / 單位經濟 / 留存 / 客服時間佔比 / 自己情緒)每維 0 到 10 分加引用資料;總分對映唯一判斷(不低於 50 才"放大"、30 到 49"修"、低於 30 必"停");30 天最後視窗期含 3 件必做加硬停條件;如果選"停"列退訂 / 退款 / 資料匯出 / 伺服器關閉 4 步收尾;如果選"放大"列下個 30 天 1 件加碼動作。


**成功標準**:交付的結果必須同時滿足——6 維有資料;總分對映唯一;含硬停條件且數字明確;含情緒維但不替我決策;未編業界閾值;4 步收尾完整。 任意一條沒滿足即視為未達標,需補料後重跑。
## 資訊輸入

評審之前先看我手裡的欄位齊不齊。

如果已營運時長加付費使用者數加 MRR 能講、Aha Moment 達成率有數(首次成功 / 註冊數)、單位經濟能算(淨到賬 / 使用者 / 月)、30 天和 60 天留存能查、客服時間佔比有數、目前主觀情緒能講,這 5 件事我能填出 70% 以上,你就直接開始評審。如果付費使用者少於 3 人,強制走"停或繼續驗證"二選一,不給"放大"選項。

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

1. 已營運多久?目前付費使用者數?MRR 大概多少?
2. Aha Moment 達成率?(首次成功跑通核心閉環 / 註冊數 = ?%)
3. 單位經濟:單使用者淨到賬每月大概多少?正還是負?
4. 30 天留存 + 60 天留存大致是?
5. 你現在的主觀情緒?(興奮 / 平穩 / 疲憊 / 想放棄)

如果 6 類資料少於 3 類有數,拒絕評審讓我先做 1 周臺賬。情緒欄位空時預設按"平穩"處理。

## 工作流程

第一步是 6 維評分。在 `<thinking>` 標籤裡先梳理"使用者少是沒找到 vs 找到了留不住 vs 留住了不賺錢"。每維 0 到 10。

| 維度 | 0 到 3(差) | 4 到 6(中) | 7 到 10(好) |
|------|--------------|--------------|---------------|
| 付費使用者數 | 小於 3 | 3 到 10 | 10 以上 |
| Aha 達成率 | 小於 20% | 20 到 50% | 50% 以上 |
| 單位經濟 | 負到打平 | 微正小於 5 美元 | 5 美元以上 |
| 留存 30 天 | 小於 30% | 30 到 60% | 60% 以上 |
| 客服時間佔比 | 大於 50% | 20 到 50% | 小於 20% |
| 自己情緒 | 想放棄 / 疲憊 | 平穩 | 興奮 / 平穩清晰 |

第二步是總分對映唯一判斷:50 分以上"放大"、30 到 49"修"、低於 30"停"。

第三步是寫 30 天視窗期。如果選"修",列 3 件 30 天內必做事和必修指標(比如"30 天后 Aha 達成率必須超過 40%")。

第四步是設硬停條件。如果 30 天后某個指標仍低於某個數(具體數字),就必須停。這條硬條件必須明示,不能用"再看看"敷衍。

第五步是給收尾或加碼動作。

| 判斷 | 接下來 |
|------|--------|
| 停 | 4 步收尾:發退訂通知 → 處理退款 → 資料匯出給使用者 → 關伺服器 |
| 修 | 30 天內 3 件必做 + 硬停條件 |
| 放大 | 下個 30 天 1 件加碼:拉新 / 加價 / 拉團隊 / 上 SEO 四選一 |

## 示例 / 樣板

公開範圍引數:產品型別 = B2C AI 工具按月訂閱;營運時長 = 8 周;付費使用者 = 3 人;MRR = $57;單位經濟 = -$2 / 使用者 / 月;30 天留存 = 33%;客服時間佔比 = 60%;情緒 = 疲憊。

期望輸出節選:

```
6 維評分
- 付費使用者數:3 分(3 人在 3 到 10 區間下沿)
- Aha 達成率:5 分(50% 中等)
- 單位經濟:2 分(負 2 美元)
- 留存 30 天:4 分(33% 中下)
- 客服時間佔比:2 分(60% 太高)
- 自己情緒:2 分(疲憊)

總分:18 → 停

4 步收尾
1. 7 天內給 3 個付費使用者發郵件:14 天后服務停止,提前申請退款
2. 處理剩餘訂閱週期內的退款
3. 提供資料匯出 zip(使用者上傳過的 CSV + 歷史分析結果)
4. 關 Vercel + Stripe + 域名(域名留 1 年作 redirect)

理由
單位經濟為負且情緒疲憊,按目前節奏繼續只會更累。
如果有重啟意願,30 天后回訪談板塊換人群再來。
```

反面例子:根據"我感覺專案有前景"給放大判斷(主觀情緒不是資料證據);編"業界放大門檻 MRR 10000 美元"(無源資料);總分 25 還給"修"判斷(違反低於 30 必停硬約束);硬停條件寫"看情況"(違反必須具體數字硬約束)。

## 輸出規範

直接輸出《[產品方向]》三閘門評審報告正文,不要前言後語,總字數 800 到 1200 字,按以下順序:

1. 6 維評分卡:維度 / 資料 / 0 到 10 / 扣分原因
2. 總分 + 三檔判斷:停 / 修 / 放大
3. 如選修:30 天視窗期 3 件必做 + 必修指標
4. 硬停條件:30 天后 X 仍低於 Y 必須停
5. 如選停:4 步收尾;如選放大:1 件加碼動作

輸出前自檢:6 維有資料;總分對映唯一;含硬停條件且數字明確;含情緒維但不替我決策;未編業界閾值;4 步收尾完整。

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

- 6 維資料少於 3 維有數拒絕(先做 1 周臺賬)
- 要求"業界停損 / 放大基準"拒絕(無源資料)
- 要求"雞湯式堅持就勝利"拒絕
- 要求設計避稅或隱瞞收入拒絕
- 欄位全空或仍是 `___` 佔位符沒替換拒絕

先給結論

Micro SaaS 停 / 修 / 放大要先回答五個問題:

問題要判斷
已營運時長 + 付費數是否過了 8 周觀察期 + ≥ 3 付費
Aha 達成率首跑通 / 註冊 比例(< 20% / 20-50% / > 50%)
單位經濟單使用者淨到賬每月(負 / 微正 / ≥ $5)
30 天留存< 30% / 30-60% / > 60%
自己情緒興奮 / 平穩 / 疲憊 / 想放棄(不替決策只做警示)
流程图加载中

新手不要用熱情替代判斷。這個階段最容易出錯的地方,是把“我會工具”誤讀成“我能交付”。真正要檢查的是:輸入是否清楚、交付物是否可用、邊界是否寫明、風險是否能被發現。如果這些問題答不上來,先補材料,不要急著放大。

暫停或放大決策先服務真實任務

Micro SaaS的暫停或放大決策,不是為了顯得更專業,而是為了讓有明確流程痛點的小團隊或獨立使用者能在真實任務裡得到可檢查的結果。它應該服務一個真實任務:讓使用者從不確定狀態,進入能判斷、能執行、能覆盤的狀態。

Micro SaaS 暫停 / 放大決策這類文章的共同啟發是:專業能力不是堆概念,而是把模糊問題整理成可執行流程。這意味著 MRR / Churn / 單位經濟三個數提前設閾值,單月波動不算依據。

如果你只寫“做得更好”“提升效率”“擴大影響”,客戶或使用者很難行動。更好的寫法是:本週收集哪些材料,做出哪個樣品,用什麼表檢查,出現哪些紅燈就暫停。

新手先收窄場景

不要同時服務所有人。先選擇一個更窄場景,例如一類使用者、一種交付物、一個平臺或一個業務階段。場景越窄,例子越具體,風險也越容易提前發現。

如果你發現文章或方案可以套到任何行業,通常說明它還不夠具體。把物件、材料、工具、交付和覆盤都寫具體,才會真正幫助新手。

第 1 步:把目前營運狀態翻譯成 6 維評分輸入

先寫一句話:

我這次要幫助 ___ 在 ___ 場景下,用 ___ 材料,完成 ___ 結果。

這句話寫不出來,後面所有動作都會漂。目標不清,會導致樣品不清;輸入不清,會導致 AI 輸出不穩;使用者不清,會導致頁面和交付無法聚焦。

欄位填寫方式
目標使用者有明確流程痛點的小團隊或獨立使用者
目前任務用閘門決定繼續、修復或停止
已有輸入原話、樣品、資料、連結、舊流程
交付結果訪談記錄、MVP 單閉環、支付路徑、支援記錄和迭代表
紅燈偽需求、過度開發、支付失敗、隱私資料和長期支援壓力

這一步不要讓 AI 替你編材料。AI 可以整理你給出的資訊,但不能證明使用者真的存在,也不能確認平臺和支付規則。

輸入材料的最低線

至少要有三類材料:1 周以上單位經濟臺賬(如 周度現金流覆盤)、30/60 天留存資料、6 維評分原始資料。臺賬缺先回去做 1 周覆盤再來評審。

第 2 步:算總分對映停修放大紅黃綠

判斷表要讓你知道現在該繼續還是暫停。

判斷項綠燈黃燈紅燈
總分對映≥ 50 → 放大30-49 → 修< 30 → 必停
單位經濟> $5 / 使用者 / 月$0-5 微正負值
30 天留存> 60%30-60%< 30%
客服時間佔比< 20%20-50%> 50%
30 天硬停條件寫明指標 + 閾值 + 日期模糊"看情況“沒寫或寫”再堅持"

表格不是為了好看,而是為了停止錯誤動作。很多失敗不是因為執行不努力,而是黃燈和紅燈被忽略。

反證也要寫

判斷表裡要保留反證。比如使用者不願提供材料、只想免費試做、平臺規則不清、工具能力未核驗、交付後支援壓力過高。反證能幫你避免把小問題做大。

第 3 步:搭最小評審樣品和硬停條件草稿

最小樣品或流程要足夠小,但必須真實。

型別最小樣品
服務一頁 Brief、一個樣品交付、一個驗收清單
工具一個可執行流程或欄位表
內容一段樣稿、一張結構表、一份質檢記錄
變現一個範圍清楚的報價頁或提案
規模化一個小渠道實驗或 SOP 片段

樣品的目標不是展示你能做很多,而是讓使用者判斷“這是不是我需要的”。如果樣品需要你在旁邊解釋很久,就說明它還不夠清楚。

做完樣品後,至少找一個真實使用者或舊客戶看。只聽讚美沒有用,要問他哪裡不懂、哪裡有風險、是否願意進入下一步。

樣品要有退出條件

如果樣品沒人看、看了沒人問、問的問題都和目標不相關,就不要繼續加大投入。先回到目標、使用者和輸入,重新判斷場景是否成立。

第 4 步:檢查雞湯式堅持和情緒綁架紅線

風險檢查要放在交付前,而不是出了問題以後。

風險檢查動作
平臺規則到官方幫助中心或後臺核驗
支付退款看平臺和支付工具當天規則
版權隱私檢查素材、案例、截圖和客戶資料
賬號許可權只拿必要許可權,優先用測試資料
過度承諾刪除不可控結果,補適用邊界

偽需求、過度開發、支付失敗、隱私資料和長期支援壓力都不是小細節。新手越想快點完成,越容易跳過這些檢查。真正專業的做法,是把未確認欄位寫出來,而不是假裝已經知道。

邊界要寫給使用者看

邊界不要藏在腦子裡。哪些不包含、哪些需要客戶提供、哪些需要執行當天核驗、哪些結果不承諾,都要寫進頁面、提案或交付說明。

第 5 步:30 天再評並固化下一檔動作

覆盤要落到下一步,不要只寫感想。

發現下一步
使用者任務清楚繼續做完整版本或下一篇教學
輸入材料缺失先補訪談、樣品或官方核驗
支援問題重複回寫 FAQ、模板或 SOP
風險未確認暫停釋出或暫緩報價
反饋分散收窄使用者和場景

覆盤時要同時看行為和原話。行為告訴你使用者做了什麼,原話告訴你為什麼可能這樣做。只看其中一個,都容易誤判。

如果覆盤後沒有產生新動作,說明覆盤還停在總結層。好的覆盤應該讓下一步更小、更清楚。

操作檢查表

欄位填寫
目前主題Micro SaaS暫停或放大決策
目標使用者有明確流程痛點的小團隊或獨立使用者
關鍵輸入___
最小樣品___
主要風險偽需求、過度開發、支付失敗、隱私資料和長期支援壓力
官方核驗入口___
覆盤指標使用者原話、樣品行為、交付問題、下一步動作
目前判斷繼續 / 補證據 / 暫停

這張表可以直接複製到你的專案文件裡。每完成一輪,就更新一次,不要只靠記憶。

AI 怎麼輔助

AI 適合做這些:

  1. 把使用者原話整理成問題分類。
  2. 生成 Brief、檢查表、SOP 或覆盤表。
  3. 標出未確認欄位和風險點。
  4. 改寫頁面、提案或交付說明。
  5. 把反饋轉成下一步動作。

AI 不適合替你確認平臺規則、支付退款、客戶授權、隱私邊界和真實購買意願。沒有證據時,必須寫未確認。

讓 AI 輔助時,不要只問“怎麼做”。要給它材料、目標、約束和目前判斷,讓它幫你找遺漏。

官方資料與核驗口徑

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

跨平臺核驗入口:

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

常見問題

單位經濟為負但我覺得“再做 3 個月就能轉正”怎麼辦?

按資料走,不按感覺。設硬停條件:“30 天后單使用者淨到賬仍低於 $0 / 月就必須停”。情緒是參考指標,不是決策證據。如果 3 個月內有具體降本路徑(如 cache 複用 / 模型降級)能讓單位經濟轉正,寫成 30 天必做事,每週覆盤。

Indie Hacker 收購視窗怎麼判斷?

通常具備 3 條訊號才算視窗期:MRR 12 個月穩定 + 月度 Churn < 4% + 自己營運時間能壓到每週 5 小時以下。三條都不滿足就不要為了“賣出去”調整產品方向,反而會拖累。

總分卡在 35 分(修檔但很想停)怎麼決定?

按“硬停條件 30 天后再看”。這 30 天裡只做 3 件必做事(不併行)。如果心理上已經放棄 5 周以上、客服時間 > 50%、單位經濟為負,三條同時滿足時即使總分 35 也建議直接進收尾流程——繼續修反而是機會成本。

停服後老使用者能保留多久資料?

至少 90 天可下載,發停服郵件時附資料匯出連結(CSV / JSON 都給)。GDPR 適用區域必須給刪除請求入口。域名留 1 年作 redirect 指向新產品或歸檔頁,不要直接 404。

執行前至少核驗:

接下來去哪

本頁目錄