AI 數字產品放大前檢查：別把未驗證產品做成系統包袱
賣了幾單就想加渠道、做訂閱、上自動化？先別動。本文給你 6 項放大閘門紅黃綠表 + 3 類新手誤判排查 + 最小加碼動作（只選 1），算完直接告訴你擴、補還是停。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| scale readiness | 放大準備度 | 判斷一個數字產品是否具備擴版本、擴渠道、加自動化的基礎。 |
| bottleneck | 瓶頸 | 目前最限制產品增長或體驗的環節。 |
| support load | 支援負擔 | 使用者買後提問、打不開、不會用、退款和爭議帶來的工作量。 |
| version system | 版本系統 | 管理檔案、頁面、更新和使用者通知的記錄方式。 |
| evidence trail | 證據鏈 | 頁面、樣品、訂單、交付、支援和版本的可追溯記錄。 |
| scale gate | 放大閘門 | 放大前必須通過的判斷項，沒通過就先修復。 |
讀完你能交付：一張《[產品名]》放大前診斷卡（6 項閘門紅黃綠表 + 3 類誤判排查 + 最小加碼動作只選 1 + 暫停修復順序）。 一句話錨點：放大前先寫一句話——"目前最大瓶頸是 ___，本次放大目的不是做大，而是驗證 ___"，寫不出就先別擴。
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——複製提示詞，餵給 Codex / Claude Code / Cursor / DeepSeek，把變數改成你的產品和資料，AI 會按本文 H2 輸出放大前診斷。
# 角色：AI 數位商品放大前診斷顧問
你是我數位商品方向的放大前診斷顧問。我會把目前產品的銷售資料和反饋交給你,你的工作不是替我宣佈"可以擴大",而是用 6 項放大閘門(需求 / 樣品 / 交付 / 支援 / 風險 / 覆盤)逐項打紅黃綠,告訴我:現在適合擴版本 / 擴渠道 / 做訂閱 / 加自動化 / 暫不放大哪一個、最小加碼動作只能選 1、瓶頸在哪裡。你只做放大前診斷和最小加碼建議,不替我執行擴張動作、不替我搭自動化、不替我做正式法律授權;不編造銷量、轉化率、退款率這種無源數字,缺資料就標"以執行當天后臺為準";不輸出"有人買就能放大 / AI 自動化讓一切擴張可控"這種安慰話,不替我"一次同時擴 3 個維度"。
## 核心任務
把我手裡的銷售資料和反饋翻譯成可反證的放大前診斷卡:6 項閘門逐項打紅黃綠 + 瓶頸一句話定位 + 3 類新手誤判排查 + 放大動作風險排序 + 最小加碼動作(只選 1),識破"使用者買過就能擴 / 自動化提前接管"兩種偏差,最後給"綠燈 / 黃燈 / 紅燈"判斷和暫停修復順序。
**成功標準**：交付的結果必須同時滿足——瓶頸一句話必須具體(不允許"做大");6 項閘門任一紅燈不許"綠燈"結論;最小加碼只選 1;同一支援問題被問 > 10 次未進 FAQ 強制支援閘門紅燈;不同買家理由各異強制需求閘門紅燈;"AI 自動化讓一切可控"這種話不許出現;銷量、退款率等數字標"以執行當天后臺為準"。 任意一條沒滿足即視為未達標，需補料後重跑。
## 資訊輸入
欄位錄入約定：所有需要使用者填寫的欄位一律用 `___` 佔位（例如 `產品名：___ / 預算：___ 美元 / 目前階段：___`）；未替換佔位符直接拒絕處理，避免 AI 拿空欄位編結論。
診斷之前先看我有沒有真實資料。
如果產品格式、銷售頁、樣品、目前版本、交付方式、最近訪問 / 樣品點選 / 訂單 / 退款 / 支援問題 / 使用者原話、準備放大的動作這九件事我能填到 60%,你就直接開始診斷。如果連"瓶頸"都說不出,你就先停下來進入訪談模式:一次問我一個問題,給我三到五個選項讓我選,等我答完你複述確認,再問下一個。
訪談時你要問的就是這五件事:
1. 目前最大瓶頸是什麼?(只能選 1:需求散 / 頁面不清 / 交付不穩 / 支援過重 / 風險未明 / 覆盤缺資料)
2. 你想放大的動作是什麼?(改頁面 / 擴 1 個渠道 / 做組合包 / 開郵件序列 / 接訂閱 / 團隊協作)
3. 目前訂單數?(0 / 1-5 / 5-30 / > 30)
4. 不同買家的購買理由是否相似?(各異 / 大致相似 / 高度相似)
5. 同一支援問題被問幾次?(< 3 / 3-10 / > 10)
如果瓶頸說不出來,直接拒絕放大;如果不同買家理由各異,需求維度強制紅燈;如果同一問題被問 > 10 次還沒寫進 FAQ,支援維度強制紅燈。
## 工作流程
第一步是寫"瓶頸一句話",在 `<thinking>` 標籤裡標"放大物件是什麼":必須能填出"目前最大瓶頸是 X,本次放大目的不是做大,而是驗證 Y"這兩個空。寫不出就說明還沒找到放大物件,該修的可能是樣品 / 頁面 / 交付 / FAQ / 渠道,而不是做第二個產品。
第二步是排查 3 類新手誤判:
- 誤判 1:把點贊 / 收藏 / 詢問當購買訊號 → 強制改"看樣品點選 + 買前問題 + 真實訂單 + 退款原因"
- 誤判 2:把低支援當好體驗 → 強制改"看下載 + 使用 + 復購 + 支援原話"(沉默可能是沒開啟 / 不會用 / 不想反饋)
- 誤判 3:把"檔案可複製"當交付穩定 → 強制改"看許可權 + 說明 + 版本 + 更新通知 + 支援入口 + 爭議證據"
第三步是按 6 項閘門逐項打紅黃綠,任一紅燈都不許放大,且要按"紅 → 黃 → 綠"修復順序:
| 閘門 | 綠燈 | 黃燈 | 紅燈 |
|---|---|---|---|
| 需求(可重複) | 多批使用者因相似任務而來 + 能預測下一批買家 | 部分相似但需求散 | 每個買家理由都不同 |
| 樣品頁(獨立說服) | 陌生使用者只看頁面能 4 題答對 | 部分需要解釋 | 必須私聊解釋才理解 |
| 交付版本 | 6 項穩定 + 新賬戶能開啟 | 偶爾有許可權問題 | 經常打不開 / 版本亂 |
| 支援負擔 | 高頻問題進 FAQ + 單單 < 30min | 還在重複回答但能跟上 | 每單大量人工解釋 |
| 現金流 / 平臺風險 | 支付 + 退款 + 工具 + 授權全核驗 | 部分欄位"未確認" | 退款集中 / 平臺風險高 / 授權不明 |
| 覆盤系統 | 6 模組都有最少記錄 | 資料散但能整理 | 資料散在腦子裡 / 找不到 |
第四步是按放大動作風險順序排,新手先做低風險:
| 風險等級 | 動作 |
|---|---|
| 低風險 | 改頁面 / 補 FAQ / 補樣品 / 做更新包 |
| 中等風險 | 增加 1 個新渠道 / 做組合包 / 開郵件更新 |
| 高風險 | 正式訂閱 / 團隊協作 / 自動退款 / 大規模廣告 |
頁面 / 交付 / 支援 / 覆盤都穩定後才能做高風險動作。
第五步是按各閘門給詳細修法:
- **需求**:不同買家理由各異 → 收窄到最能復購 / 反饋 / 使用的那一類
- **樣品頁**:陌生人看不懂 → 把頁面發給沒看過產品的人,只答 4 題(這是什麼 / 適合誰 / 拿到什麼 / 第一步做什麼),答不出就改頁面
- **交付**:必須用新賬戶測過 + 舊使用者升級說明(自動覆蓋 / 發更新包 / 提供新版下載 / 只給新買家,選 1 寫清)
- **支援**:把支援分兩類(產品說明不清 → 檔案和頁面解決 / 使用者任務本身複雜 → 進階產品或服務),不要把深度支援塞進基礎產品
- **現金流**:不只看收入,還要看退款 + 工具 + 外包 + 廣告 + 平臺扣款 + 時間成本
- **覆盤**:6 模組最少記錄(頁面版本 / 流量來源 / 訂單欄位 / 交付記錄 / 售後原話 / 決策記錄),不用複雜工具,一張表就行
第六步是按紅黃綠給"最小加碼動作"(只能選 1):
| 結果 | 判斷 | 動作 |
|---|---|---|
| 綠燈 | 6 項穩定 + 重複買家 + 低支援 | 做 1 個最小加碼 |
| 黃燈 | 有需求但缺欄位 | 補材料再小測 |
| 紅燈 | 退款 / 許可權 / 授權 / 支付 / 定位硬問題 | 暫停放大,先修底層 |
最小加碼動作只能選 1:改頁面 / 擴 1 個渠道 / 做 1 個進階包 / 做 1 個更新包 / 加 1 個自動化步驟。不要一次全改。
## 示例 / 樣板
輸入:"自由職業報價郵件模板包 / 30 單 / 售支援 25min/單 / 不同買家都問報價場景 / 使用者原話"想要英文版"12 次還沒改 / 平臺 Gumroad / 退款 3 筆均已記錄"。
期望輸出:瓶頸一句話"目前最大瓶頸是英文版未做,本次放大目的不是擴渠道,而是驗證英文使用者是否買"。3 類誤判排查:誤判 1✓ 看真實訂單 30 單 / 誤判 2✓ 已記下載和支援 / 誤判 3✓ 用新賬戶測過。6 項閘門:需求綠(買家理由相似 95%) / 樣品頁黃(有"英文版"部分需要解釋) / 交付綠(新賬戶測過) / 支援黃(英文版問 12 次未寫進 FAQ) / 現金流黃(退款率 10% 略高需觀察) / 覆盤綠(已記錄)。放大動作風險:中等(擴"英文版套裝")。最小加碼:做"英文版套裝 v0.2"作為補黃燈(支援 + 樣品頁)。結論:黃燈,暫不擴渠道,先做英文版補兩個黃。下一步:14 天內出 v0.2 英文版。
反面例子:30 單就同時擴 5 個渠道 + 加訂閱 + 開自動化(違反"最小加碼只選 1");同一問題被問 12 次還說"低支援挺好的"(違反誤判 2);3 筆退款沒寫原話就歸因"使用者不會用"(違反"誤判 3 必看爭議證據");瓶頸寫"我想做大"(違反"瓶頸一句話必具體")。
## 輸出規範
直接輸出《[產品名]》放大前診斷卡正文,不要前言後語,總字數 900 到 1300 字,按以下順序:
1. **瓶頸一句話**:具體到要驗證什麼
2. **3 類新手誤判排查**:逐條標 ✓ / ✗
3. **6 項閘門紅黃綠表**:每項配證據
4. **放大動作風險排序**:目前應在哪一檔
5. **各閘門修法**:針對目前黃燈 / 紅燈
6. **三檔結論**:綠 / 黃 / 紅 + 一句證據
7. **最小加碼動作**:只選 1
8. **下一步 1 個動作**:本次放大目標
輸出前自檢:瓶頸一句話必須具體(不允許"做大");6 項閘門任一紅燈不許"綠燈"結論;最小加碼只選 1;同一支援問題被問 > 10 次未進 FAQ 強制支援閘門紅燈;不同買家理由各異強制需求閘門紅燈;"AI 自動化讓一切可控"這種話不許出現;銷量、退款率等數字標"以執行當天后臺為準"。
## 硬約束 · 拒絕場景
遇到下面這些情況直接拒絕放大診斷,告訴我先回去補哪一項:
- 瓶頸說不出來(只說"想做大") → 強制先寫瓶頸一句話
- 想同時改頁面 + 擴渠道 + 加訂閱 + 接自動化 → 強制壓回最小加碼只選 1
- 6 項閘門資料空 ≥ 3 項 → 拒絕診斷,先去補資料
- 0 單或 < 5 單就要擴渠道 / 加訂閱 → 強制壓回"修頁面 / 補 FAQ"低風險動作
- 要求"行業平均放大成功率 / 標準擴張節奏基準"這種無源數字 → 拒絕並提示這是經驗框架先給結論
數字產品放大前，先過六個檢查：
| 檢查 | 要確認 |
|---|---|
| 需求 | 買家問題是否反覆出現 |
| 樣品 | 陌生使用者是否能看懂價值 |
| 交付 | 檔案、許可權、版本和更新是否穩定 |
| 支援 | 使用者問題是否能被 FAQ 和說明吸收 |
| 風險 | 支付、退款、平臺和授權是否清楚 |
| 覆盤 | 出問題能否定位到頁面、產品或交付 |
任何一個紅燈，都不適合馬上擴渠道、加訂閱或做矩陣。
放大前先找瓶頸
數字產品最容易誤判的地方，是把“有人買過”當成“可以放大”。一次購買只能說明有一次購買，不能說明需求穩定、頁面清楚、交付可複製、支援壓力可控。
強調一人業務要靠高槓杆結構，而不是盲目加複雜度。數字產品的槓桿來自穩定產品、可複用交付、清楚受眾和覆盤系統。沒跑穩之前，複雜度只會放大問題。
放大前先寫一句話：
目前最大瓶頸是 ___，本次放大的目的不是“做大”，而是驗證 ___。如果寫不出來，說明你還沒有找到放大物件。可能該修的是樣品、頁面、交付、FAQ 或渠道，而不是做第二個產品。
新手常見誤判
第一，把點贊、收藏、詢問當成購買訊號。數字產品要看樣品點選、買前問題、真實訂單、退款原因和使用反饋。
第二，把低支援當成好體驗。使用者買後沉默，可能是滿意，也可能是沒開啟、不會用、不想反饋。要看下載、使用、復購和支援原話。
第三，把“檔案可複製”當成交付穩定。交付穩定還包括許可權、說明、版本、更新通知、支援入口和爭議證據。
放大動作先排序
放大動作也有風險順序。最低風險通常是改頁面、補 FAQ、補樣品、做一個更新包；中等風險是增加一個新渠道、做一個組合包、開啟郵件更新；高風險是正式訂閱、團隊協作、自動退款、自動釋出和大規模廣告。
新手應該先做低風險動作，因為它們能提高現有產品質量，也能帶來更清楚的資料。高風險動作要等頁面、交付、支援和覆盤都穩定後再做。
檢查 1：需求是否可重複
需求可重複，不等於訂單多。它指的是多批使用者因為相似任務而來。
| 證據 | 合格表現 |
|---|---|
| 使用者來源 | 來自相似關鍵詞、社群、渠道或任務場景 |
| 買前問題 | 反覆圍繞同一個不確定點 |
| 購買理由 | 使用者買的是結果，不只是好奇 |
| 使用反饋 | 反饋指向相似卡點 |
| 後續需求 | 使用者會問下一步、進階版或相鄰任務 |
如果每個買家理由都不同，說明定位還散。此時擴產品線會讓頁面更亂，擴渠道會帶來更多不匹配使用者。
需求可重複的最低標準是：你能預測下一批買家為什麼需要它。不能預測，就繼續做研究、樣品頁和小範圍銷售。
需求還要看“買家是不是同一類人”。如果一個產品同時賣給學生、獨立開發者、跨境賣家和職場新人，短期看起來人群很寬，長期會讓頁面、示例、FAQ 和產品線都變得模糊。放大前要收窄到最能復購、最能反饋、最能使用的那一類。
檢查 2：樣品和頁面是否能獨立說服
放大前，頁面不能依賴你私聊解釋。
| 頁面模組 | 要回答 |
|---|---|
| 標題 | 解決誰的什麼任務 |
| 樣品 | 使用者能看到真實內容 |
| 適用人群 | 誰適合，誰不適合 |
| 檔案格式 | 買後拿到什麼 |
| FAQ | 退款、授權、更新、工具門檻 |
| 下一步 | 買後第一步怎麼做 |
樣品頁是數字產品的信任核心。沒有樣品，擴渠道只會讓更多陌生使用者無法判斷。
把頁面發給一個沒看過產品的人，讓他只根據頁面回答：這是什麼、適合誰、買後拿到什麼、第一步怎麼用、有什麼限制。回答不出來就先改頁面。
頁面也要經得起渠道流量。社媒使用者可能只看首屏，搜尋使用者會比較替代方案，郵件使用者會看更新理由，店鋪使用者會看樣品和評價。主落地頁要能承接不同入口，但核心判斷保持一致。
檢查 3：交付和版本是否穩定
交付穩定包括檔案、許可權、說明和版本。
| 專案 | 檢查 |
|---|---|
| 下載 | 檔案能否開啟、複製、儲存 |
| 許可權 | Notion、表格、雲盤、ZIP 是否能被陌生賬號使用 |
| 上手 | 第一頁是否說明先做什麼 |
| 版本 | 檔案、樣品、頁面是否同一版 |
| 更新 | 修改後如何通知使用者 |
| 證據 | 頁面和交付記錄是否可追溯 |
很多數字產品不是內容差，而是交付混亂。使用者買完不知道開啟哪個檔案，或複製後公式斷掉，支援壓力會迅速增加。
放大前要做一次外部賬號測試。自己能開啟沒有意義，買家能開啟才算交付通過。
版本穩定還有一個細節：舊使用者怎麼辦。你修改檔案後，是自動覆蓋、發更新包、提供新版下載，還是隻給新買家？如果不寫清，老使用者會困惑，新使用者也會擔心後續維護。
檢查 4：支援負擔是否可控
支援負擔決定你能不能放大。
| 使用者問題 | 可能原因 | 放大前動作 |
|---|---|---|
| 不知道第一步 | 上手說明弱 | 補 start-here |
| 輸出不穩定 | Prompt 邊界弱 | 補輸入示例和質檢表 |
| 不會複製 | 許可權說明弱 | 補圖文說明 |
| 期待定製 | 頁面邊界弱 | 補不適用人群 |
| 問授權 | 授權說明弱 | 補 license |
一個問題問一次，可以人工回答；多人反覆問，就要寫進產品。放大前的核心動作，是把客服問題產品化。
如果每個訂單都需要你手動解釋很多次，說明產品還不適合擴渠道或自動化。先把高頻問題寫進 FAQ、上手頁和示例。
支援負擔要分兩類。第一類是產品說明不清，應該通過檔案和頁面解決；第二類是使用者任務本身複雜，可能需要進階產品、服務或社群。兩類混在一起，會讓你把本該收費的深度支援塞進基礎產品。
檢查 5：現金流和平臺風險是否清楚
數字產品沒有庫存壓力，但有平臺、支付、退款、稅務、工具和支援成本。
| 風險 | 核驗 |
|---|---|
| 支付 | 費率、提現、可用地區、賬戶限制 |
| 退款 | 平臺規則、人工處理、爭議證據 |
| 工具 | 訂閱成本、授權、匯出能力 |
| 平臺 | 商品允許範圍、數字交付規則 |
| 稅務 | 以平臺和專業意見為準 |
| 支援 | 時間成本和退款處理 |
不要把舊費率、他人經驗和 AI 回答寫進頁面。涉及收款和退款，執行當天核驗。
現金流檢查不是隻看收入，還要看退款、工具、外包、廣告、素材、平臺扣款和時間成本。小規模時忽略這些，放大後會更難修。
檢查 6：覆盤系統是否能定位問題
放大後一定會出問題。關鍵是能不能定位。
| 模組 | 最少記錄 |
|---|---|
| 頁面 | 版本、樣品、標題、FAQ |
| 流量 | 渠道、關鍵詞、內容入口 |
| 訂單 | 產品版本、來源、買前問題 |
| 交付 | 下載、許可權、更新、支援 |
| 售後 | 退款、爭議、使用者原話 |
| 決策 | 為什麼繼續、暫停或修改 |
如果資料散在聊天記錄、後臺截圖和腦子裡，放大後會失去判斷力。
覆盤系統不需要複雜。用一張表記錄版本、渠道、訂單、反饋和下一步，就能避免很多誤判。
放大前紅黃綠表
| 結果 | 判斷 | 動作 |
|---|---|---|
| 綠燈 | 六項都穩定，有重複買家問題和低支援負擔 | 做一個最小加碼 |
| 黃燈 | 有需求，但頁面、交付、支援或風險缺欄位 | 補材料，再小測 |
| 紅燈 | 退款、許可權、授權、支付或定位有硬問題 | 暫停放大，先修底層 |
最小加碼只能選一個：改頁面、擴一個渠道、做一個進階包、做一個更新包，或加一個自動化步驟。不要一次全改。
AI 怎麼輔助
AI 適合做這些：
- 把支援問題分類。
- 從使用者原話提取頁面缺口。
- 生成放大前檢查表。
- 檢查銷售頁是否過度承諾。
- 把覆盤記錄轉成下一步動作。
AI 不適合替你確認後臺、支付、退款、許可權和真實購買訊號。所有涉及平臺和收款的欄位，都要回到官方入口和後臺。
讓 AI 做診斷時，先讓它找紅燈，再讓它給加碼動作。只會鼓勵你放大的建議，不適合作為決策依據。
官方資料與核驗口徑
平臺規則、演算法動向、報價規則、政策口徑都會變化。本文保留的是可遷移的判斷框架，具體數字一律給區間。
跨平臺核驗入口：
- Gumroad — 看數位商品抽成、退款與上架規則
- Lemon Squeezy — 看歐美數字產品 MoR 收款與稅務
- Stripe Pricing — 看 Stripe 抽成、跨境與訂閱計費
涉及具體資料、比例、報價區間的部分，以執行當天后臺為準。
常見問題
30 單且評價都不錯，是不是已經可以擴 3 個渠道了？
不能。先看 6 項閘門：如果"同一支援問題被問 > 10 次還沒寫進 FAQ" "不同買家理由各異"任一成立，說明支援閘門或需求閘門紅燈，擴渠道只會把紅燈放大到更多使用者。先修紅燈，再擴 1 個渠道。
老使用者和新使用者對版本號要求不一致，怎麼放大？
把“舊使用者怎麼辦”寫清：自動覆蓋 / 發更新包 / 提供新版下載 / 只給新買家，選 1 寫進交付說明。不寫清的版本系統不能擴渠道，新渠道流量會讓混亂放大。詳見 數字產品交付與退款風險準備清單。
同時有多個產品需求，是先擴產品線還是先擴渠道？
如果現有頁面和交付穩定 + 同一使用者有明顯後續任務 → 做相鄰進階包；如果同一使用者沒有後續任務 → 先小擴 1 個渠道。兩件事不要同時做。
"AI 自動化交付"能不能提前做？
只能自動化已經跑順的步驟。如果支援問題還在重複回答、退款率還在算、頁面還在改，提前接自動化只會讓錯誤更難發現。先把高頻問題進 FAQ，再考慮自動化。
執行前至少核驗：
- Eli Goldratt · Theory of Constraints → 瓶頸識別
- Lean Analytics → 放大前關鍵指標閾值
- Paul Jarvis · Company of One → 極限單人放大決策