173 lines
12 KiB
Markdown
173 lines
12 KiB
Markdown
|
# Requirements: 成長迴路（從「好用」到「非用不可」）
|
|||
|
|
|
|||
|
|
> Status: `draft`（待使用者批准）
|
|||
|
|
> Slug: `growth-loop`
|
|||
|
|
> Last updated: `2026-07-20`
|
|||
|
|
> 輸入真相：2026-07-20 PM 體檢結論；`apps/web` 現況 UI；`docs/product/haixun-backend/`（已交付能力）；git `main` 分支舊願景文件（`ai_threads_auto_account_ops.md`）
|
|||
|
|
|
|||
|
|
## 1. 一句話
|
|||
|
|
|
|||
|
|
把巡樓從「AI 內容＋外展工具組合包」升級成「**能證明 ROI、越用越準的 Threads 成長系統**」：先補 **成果歸因** 與 **學習閉環最小版** 兩塊護城河，再擴 **代操模式** 與 **帳號健康分**，最後以 **Playbook 市集＋邀請獎勵** 啟動自增長。
|
|||
|
|
|
|||
|
|
## 2. 誰用、在什麼情境
|
|||
|
|
|
|||
|
|
| 角色 | 目標 |
|
|||
|
|
|------|------|
|
|||
|
|
| 品牌／小電商島民（靠 Threads 獲客） | 明確看到海巡與發文帶來多少成果（觸達→對話→追蹤→成交），據此決定續費 |
|
|||
|
|
| 創作者島民 | 每週拿到「下週該做什麼」的具體建議，帳號穩定成長 |
|
|||
|
|
| 代操／Agency | 一套工具服務多個客戶：各自的品牌、人設、帳號、審核與月報 |
|
|||
|
|
| 營運／管理員 | 用數據證明產品價值、量化平台政策風險、讓邀請網絡真正帶來增長 |
|
|||
|
|
|
|||
|
|
## 3. 背景與動機（As-is → 為什麼改）
|
|||
|
|
|
|||
|
|
**2026-07-20 體檢結論（本 run 的存在理由）：**
|
|||
|
|
|
|||
|
|
- **現況是「很用心的組合包」：** 產文有 ChatGPT 替代、排程 Buffer 已支援 Threads、單點皆有替代品；組合＝方便≠必要。「非用不可」程度評估 **2.5 / 5**。
|
|||
|
|
- **儀表板只有成本視角：** 用量頁呈現「你花了多少點」，沒有任何地方告訴用戶「你賺回了多少」。無法證明 ROI 的工具，在續費時永遠是第一個被砍的。
|
|||
|
|
- **真正的護城河沒做：** 舊願景的核心是「成效回收 → 分析原因 → 策略自我更新 → 可解釋」的**學習閉環**（舊文件 MVP4），目前落在 P2 未實作。人設／品牌資產理論上「越用越準」，但**沒有可見的複利證據** → 轉換成本低。
|
|||
|
|
- **邀請網絡是裝飾：** 關係樹已建，但「日後活動再說」＝無獎勵機制＝無網路效應。
|
|||
|
|
- **灰帽功能無護欄：** ThreadPlay 多帳互回、養帳號短回屬平台政策敏感操作，目前無健康度量化、無降速機制；Meta 政策收緊是**存亡級風險**。
|
|||
|
|
- **不改的後果：** 用戶燒完免費點數即流失；無溢價能力；政策風險歸零核心功能；增長全靠人工推銷。
|
|||
|
|
|
|||
|
|
**已握有的三張王牌（本 run 要放大，不重造）：**
|
|||
|
|
|
|||
|
|
1. **海巡外展迴路**——最接近 painkiller：「每天 15 分鐘，找到正在講你產品痛點的真人，用像人的口吻回覆帶單」＝業務開發，市面 social listening 工具不碰這段。
|
|||
|
|
2. **TC／台灣 Threads 垂直深度**——語感、場景全 TC 原生，國際工具對 Threads 皆敷衍。
|
|||
|
|
3. **8D 人設語紋＋品牌知識資產**——具複利潛力，需要被「看見」。
|
|||
|
|
|
|||
|
|
**參考（非需求本體）：**
|
|||
|
|
|
|||
|
|
- 舊願景閉環與 MVP1–4 驗收：git `main` 分支 `ai_threads_auto_account_ops.md`
|
|||
|
|
- 已交付能力真相：`docs/product/haixun-backend/spec.md`（Insights 真管線維持 P2 的決策不變）
|
|||
|
|
- UI 真相：`apps/web`（今日／海巡／用量／Insights 頁）
|
|||
|
|
|
|||
|
|
## 4. 目標（To-be）
|
|||
|
|
|
|||
|
|
### 4.1 必須達成（P0）— 價值可見 ＋ 學習閉環最小版
|
|||
|
|
|
|||
|
|
1. **成果歸因（海巡 ROI 優先）**
|
|||
|
|
- 外展回覆送出後，追蹤可合理取得的訊號：對方回應、帳號追蹤數變化、貼文互動、自帶 UTM 連結點擊；成交先走**手動回報**。
|
|||
|
|
- 每筆成果可回溯到具體回覆／具體貼文（歸因鏈）。
|
|||
|
|
- **今日頁與用量頁改為「成本＋成果」並列**：本週／本月觸達、對話、追蹤、成交摘要卡。
|
|||
|
|
2. **每週帳號健檢＋下週行動建議（學習閉環 MVP）**
|
|||
|
|
- 基於**既有已同步貼文成效**（不重做 Insights 真管線），每會員每週自動產出一份 AI 報告：哪類題材／開頭／CTA 有效（**必須引用證據、可解釋**）＋下週 **3 個具體行動**，且每個行動可一鍵跳到對應功能（找話題／海巡／寫一則）。
|
|||
|
|
- 這是舊願景 MVP4 的最小版，**不是**完整 Insights 管線。
|
|||
|
|
3. **資產複利可見**
|
|||
|
|
- 呈現「系統從你的 N 篇貼文／M 次回饋學到什麼」：人設／品牌知識的學習摘要與版本，讓「越用越準」被感知，構成轉換成本。
|
|||
|
|
|
|||
|
|
### 4.2 應該有（P1）— 客群擴張 ＋ 風險護欄
|
|||
|
|
|
|||
|
|
1. **代操／Agency 模式**
|
|||
|
|
- 多客戶工作區：每客戶獨立品牌＋人設＋帳號＋方案視圖，工作區可切換、資料隔離。
|
|||
|
|
- 草稿審核流：草稿 → 待審 → 已准／退回，已准才進 Outbox。
|
|||
|
|
- 白牌月報 PDF 匯出（不含白牌域名）。
|
|||
|
|
2. **帳號健康分（灰帽護欄）**
|
|||
|
|
- 依操作密度／間隔／失敗率／平台訊號，給每個已連帳號 0–100 健康分與降速建議。
|
|||
|
|
- ThreadPlay／海巡送出**前**自動檢查；過載時降速並向用戶說明原因；今日頁可見警示。
|
|||
|
|
- **只做護欄，不新增更激進的多帳玩法。**
|
|||
|
|
3. **邀請獎勵落地（單層紅線）**
|
|||
|
|
- 直邀成員訂閱付費 → 邀請人得**產品點數**回饋（**單層、點數、非現金**，避免 MLM 觀感；文案維持「邀請人／直邀／延伸」）。
|
|||
|
|
- 邀請頁可見累計回饋。
|
|||
|
|
|
|||
|
|
### 4.3 以後再說（P2）
|
|||
|
|
|
|||
|
|
1. **利基 Playbook 市集**：分享／引用海巡 brief、人設風格、互回劇本模板（保養／母嬰／3C…），需可匿名化。
|
|||
|
|
2. **免費破冰工具**：公開免登入「風格指紋測驗」「痛點關鍵字產生器」，結果頁導註冊（用產品自己在 Threads 擴散）。
|
|||
|
|
3. **跨帳號基準（benchmark）**：匿名聚合「同利基帳號中位數」比較。
|
|||
|
|
4. 既有 P2 維持不變：Insights 真數據管線完整版、真實金流／發票。
|
|||
|
|
|
|||
|
|
## 5. 範圍
|
|||
|
|
|
|||
|
|
### In scope
|
|||
|
|
|
|||
|
|
- 上述 P0／P1 功能的**產品行為定義**；前端 `apps/web` 與後端 `apps/backend` 皆會異動（經 spec → plan → tasks 才動碼）。
|
|||
|
|
- 歸因以「**可合理取得的訊號**」為限：Threads API 可讀的公開計數、自帶 UTM 連結、手動回報。
|
|||
|
|
- 每週健檢**重用既有同步貼文成效資料**，不新建 Insights 管線。
|
|||
|
|
|
|||
|
|
### Out of scope（明確不做）
|
|||
|
|
|
|||
|
|
- **不做多層獎金、不做現金回饋**（MLM 紅線）。
|
|||
|
|
- **不為歸因繞過平台限制**爬取私人數據；不做侵入式追蹤。
|
|||
|
|
- 不串自動成交／真金流（P2 外）。
|
|||
|
|
- 不重做既有發文／海巡主流程——本 run 是**加值層**，不是重構。
|
|||
|
|
- 不新增灰帽玩法；多帳互回只加護欄。
|
|||
|
|
- 代操模式 P1 不做白牌域名、不做多租戶帳單。
|
|||
|
|
|
|||
|
|
## 6. 使用者故事（可驗收）
|
|||
|
|
|
|||
|
|
### P0
|
|||
|
|
|
|||
|
|
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|
|||
|
|
|----|--------|---------|--------|----------|
|
|||
|
|
| US-01 | 品牌島民 | 看到本週海巡帶來的觸達／對話／追蹤／成交 | 判斷值不值得續費 | 今日頁＋用量頁可見成果卡；每筆成果可回溯到具體回覆 |
|
|||
|
|
| US-02 | 創作者 | 每週收到健檢報告＋3 個下週行動 | 知道該做什麼 | 報告含證據引用；行動可一鍵跳到對應功能 |
|
|||
|
|
| US-03 | 島民 | 看到系統從我的貼文／回饋學到的東西 | 感到越用越準 | 資產頁可見學習摘要與版本號 |
|
|||
|
|
|
|||
|
|
### P1
|
|||
|
|
|
|||
|
|
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|
|||
|
|
|----|--------|---------|--------|----------|
|
|||
|
|
| US-10 | 代操 | 切換客戶工作區，各管各的品牌／人設／帳號 | 一套工具服務多客戶 | 工作區資料隔離；月報可匯出白牌 PDF |
|
|||
|
|
| US-11 | 代操 | 客戶審核草稿後才進 Outbox | 交稿流程可控 | 草稿有 待審／已准／退回 狀態；未准不可送出 |
|
|||
|
|
| US-12 | 島民 | 看到每個帳號的健康分與降速建議 | 不怕被平台懲罰 | 送出前自動檢查；過載自動降速並說明原因 |
|
|||
|
|
| US-13 | 島民 | 直邀付費後我得到點數回饋 | 願意主動推廣 | 單層回饋端到端成立；邀請頁可見累計 |
|
|||
|
|
|
|||
|
|
### P2
|
|||
|
|
|
|||
|
|
| ID | 作為… | 我想要… | 以便… | 驗收要點 |
|
|||
|
|
|----|--------|---------|--------|----------|
|
|||
|
|
| US-20 | 島民 | 引用別人的利基 playbook 模板 | 快速上手新利基 | 市集可瀏覽／引用；作者可匿名 |
|
|||
|
|
| US-21 | 訪客 | 免登入玩風格指紋測驗 | 認識產品 | 結果頁導註冊；可在 Threads 分享 |
|
|||
|
|
| US-22 | 島民 | 看我跟同利基帳號中位數的比較 | 知道自己程度 | 匿名聚合；樣本不足時不顯示 |
|
|||
|
|
|
|||
|
|
## 7. 成功標準
|
|||
|
|
|
|||
|
|
- [ ] **P0：** 至少一條「海巡外展 → 送出 → 成果（對方回應或追蹤變化）」完整歸因鏈可展示。
|
|||
|
|
- [ ] **P0：** 每週健檢報告自動產出，含 ≥3 條**帶證據**的行動建議，且可一鍵跳功能。
|
|||
|
|
- [ ] **P0：** 用量頁從純成本視角改為成本＋成果並列。
|
|||
|
|
- [ ] **P1：** 代操可在 2 個工作區間切換，各自產出月報 PDF；草稿未經審核不可進 Outbox。
|
|||
|
|
- [ ] **P1：** 健康分對每個已連帳號可見；高密度操作被自動降速並有說明。
|
|||
|
|
- [ ] **P1：** 單層邀請點數回饋端到端成立（訂閱 → 點數入邀請人帳）。
|
|||
|
|
- [ ] **定性：** 用戶訪談能說出「這工具幫我賺／省了多少」的**價值句**，而非只描述功能。
|
|||
|
|
|
|||
|
|
## 8. 約束與假設
|
|||
|
|
|
|||
|
|
- **約束：**
|
|||
|
|
- `AGENTS.md` 全部契約精神（UTC nano、envelope、分頁、guarded job、go-zero、etc 單份、數字 uid、權限中介層）。
|
|||
|
|
- 前端 `apps/web`：不引入新 UI 框架；mock｜live 同一 repository 介面；TC 台灣語感。
|
|||
|
|
- **平台政策紅線：** 所有自動化必須保留人工路徑（延伸現有「複製 → 開 Threads 留言 → 標記完成」模式）；灰帽功能只加護欄不擴大。
|
|||
|
|
- 與 `haixun-backend` 的關係：本 run 是**加值層**，其 spec 已交付能力為底座；「Insights 真管線維持 P2」決策不變。
|
|||
|
|
- **假設（spec 階段須驗證）：**
|
|||
|
|
- Threads API 可取得追蹤數／回覆計數等歸因訊號（權限項待查）；拿不到時降級為互動歸因＋手動回報。
|
|||
|
|
- 既有同步貼文成效資料足以支撐每週健檢最小版。
|
|||
|
|
- 成交回報 P0 先手動，用戶願意填。
|
|||
|
|
|
|||
|
|
## 9. 風險
|
|||
|
|
|
|||
|
|
| 風險 | 影響 | 緩解（需求層） |
|
|||
|
|
|------|------|----------------|
|
|||
|
|
| 歸因訊號拿不到（API 權限限制） | P0 價值證明變弱 | spec 先驗證權限；降級為對話／互動歸因＋手動成交回報，仍優於現況 |
|
|||
|
|
| Meta 平台政策收緊 | 存亡級 | 健康分＋人工路徑＋功能開關；不新增灰帽玩法；健康分本身即緩解 |
|
|||
|
|
| 學習閉環品質不穩、報告不可信 | 核心賣點崩壞 | 強制證據引用；先小範圍給既有用戶試用再全面推 |
|
|||
|
|
| 邀請獎勵被觀感為 MLM | 品牌風險 | 單層、點數非現金、既有「邀請人／直邀／延伸」用語不變 |
|
|||
|
|
| 代操模式範圍爆炸 | 工期失控 | P1 只做工作區隔離＋審核流＋PDF；白牌域名／多租戶帳單明確排除 |
|
|||
|
|
| P0 被 P1/P2 稀釋 | 本 run 失去存在理由 | 交付順序硬性：歸因＋健檢先行，其餘往後排 |
|
|||
|
|
|
|||
|
|
## 10. 開放問題
|
|||
|
|
|
|||
|
|
1. 歸因訊號清單與 Threads API 權限驗證 → **spec 階段列出並定案**。
|
|||
|
|
2. 每週健檢計費：建議**方案內含**（它是留存工具，不是變現點）→ 待批准。
|
|||
|
|
3. 代操工作區與現有單租戶／島民模型的關係（是否走向多 workspace）→ **spec 決策**。
|
|||
|
|
4. 邀請點數回饋的比例與每月上限 → plan 前定。
|
|||
|
|
5. 健康分的訊號來源、計算頻率與降速門檻 → spec 定。
|
|||
|
|
6. 成果卡的「成交」是否未來接 UTM 落地頁（P2）→ 現在先手動。
|
|||
|
|
|
|||
|
|
## 11. 批准
|
|||
|
|
|
|||
|
|
- [ ] 需求已批准（日期／誰）：
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
**給批准者：** 若整體方向 OK 請回「**需求 OK**」→ 下一回合寫 `spec.md`（歸因狀態機、健檢報告契約、健康分行為、工作區模型、Retain-Replace-Remove）。
|
|||
|
|
若只想先做 P0 兩項（強烈建議），也請指明，其餘維持文件紀錄即可。
|