thread-master/docs/product/growth-loop

growth-loop

欄位	值
Goal	從「好用」到「非用不可」：成果歸因＋每週健檢（學習閉環 MVP）優先，代操模式＋帳號健康分其次，市集＋邀請自增長墊後
Phase	awaiting-requirements-approval
由來	2026-07-20 PM 體檢（對話結論）→ 落成改善計劃
Frontend / Backend	apps/web / apps/backend
Updated	2026-07-20

文件

檔案	狀態
requirements.md	draft（待使用者批准）
spec.md	未開始（需先批准需求）
plan.md	未開始
tasks/	未開始

接手說明（給下一位 model）

1. 先讀 requirements.md §3（體檢結論＝本 run 存在理由），再讀底座真相：
   • docs/product/haixun-backend/spec.md（已交付能力；「Insights 真管線 P2」決策不變）
   • apps/web（UI 真相：今日／海巡／用量／Insights 頁）
   • 舊願景：git main 分支 ai_threads_auto_account_ops.md（MVP1–4、學習閉環原始設計）
2. 流程：使用者回「需求 OK」→ /spec-driven growth-loop 進 spec 階段 → plan → tasks → 指定 T### 才寫碼。各階段都要等批准，不得跳層一次寫完。
3. 硬性提醒：
   • P0 兩項（成果歸因、每週健檢）是本 run 的存在理由，不可被 P1/P2 稀釋或調換順序。
   • 每週健檢重用既有同步貼文成效，不是重做 Insights 真管線。
   • MLM 紅線：邀請回饋單層、點數、非現金。
   • 灰帽功能只加護欄（健康分／降速），不新增玩法；所有自動化保留人工路徑。
   • 歸因只用可合理取得的訊號（API 公開計數／UTM／手動回報），API 權限清單在 spec 階段驗證。

閘門

1. 需求批准 ← 目前在這裡
2. spec 批准
3. plan 批准
4. tasks 批准 → ready-to-implement