AI 社群營運系統

0總覽：這是什麼、為什麼是你們

一個「用講的就把每天社群營運做完」的 AI 系統。

產品的核心機制：AI 是入口，所有表格（品牌定位、內容行事曆、營收、CRM）只是 AI 背後的資料庫。使用者不用一直開 Excel，而是直接跟 AI 說「幫我規劃八月內容」「給我這個月的成效月報」，AI 讀資料、算數字、產內容、更新表格，最後可以一鍵下載 Excel 或同步到 Google Sheets。

為什麼是你們兩個：Zoe 有一套被市場驗證過的 IG 社群營運工作流（每日e錠破千萬營收、5,000+ 學員），還有 8 張實際天天在用的表格；老K 有把這套自動化的引擎（threads-ops）和 AI 團隊。她手動拉的表，你其實已經自動在跑，只是平台是 Threads 不是 IG。

誠實結論：技術不是瓶頸。真正要先想清楚的是「賣給誰、怎麼變現」，別在沒驗證前就一頭栽進訂閱制 SaaS（理由見第 4 節）。

1三條受眾路線並陳

2核心 MVP 功能

建議的楔子：把「自家社群數據 → 自動月報 / OKR 達成率」做到——跟 AI 講一句話，就拿到填好的報表，再一鍵匯出。

為什麼是這個切入點：

• 最可自動：數據型的表格（你的表 1、2、5、6）內容只有「算出來的」或「平台抓的」，正是 AI 的本行。
• 最痛：每月手動填數據、做月報，是 Zoe 代操時最花工的環節之一。
• 引擎現成：你 threads-ops 的數據追蹤已經在做這件事。
• 零平台審核：先用 Threads 自家數據，不必等 Meta 審核就能跑起來（IG 審核是後面才解的關卡）。

註：「一鍵下載 Excel」是過渡橋樑，不是賣點。真正的賣點是「你不用再開那 8 張表，用講的就把當天營運做完」。

33-6 個月推出排程

按「成本與風險最低、價值最高」往後排，每個階段之間設一道風險閘門。

4商業模式提醒（別忘了）

先看清現實：訂閱制 SaaS = 低單價 × 高流量 × 高留存壓力，剛好是老K「高單價低數量」哲學的反面。這類面向個人創作者的工具，每月流失率高達 6-8%（一年掉一半客戶），是整個品類的結構性難題。

三種變現劇本，要有意識地選：

建議：MVP 先走 B 或 C 驗證需求並變現，只有當「使用者真的每天打開、churn 活得下去」再畢業到 A。

5技術架構（伺服器）

• 沿用 threads-ops 同一個 repo 擴充（Next.js + Postgres + Drizzle + Zeabur，而且 @anthropic-ai/sdk 已經裝好沒用）。現有的單人資料當成「租戶 0」。重起一個新 repo 等於丟掉現成的派工、海巡、競品庫，不划算。
• 多租戶是最大的一塊新工：要新增 users / organizations / brands 等表，並把所有業務表加上 orgId（這段遷移最重、做錯會「串租戶」把別人資料露出來）。登入用 Auth.js 或 Clerk（待選）。
• 好消息：「接案小編管 3-5 個品牌」這個情境，剛好就是 org 底下掛多個 brand，跟現有結構天然吻合。

6自建 AI 引擎 + 成本控管

重要現況：你現在 threads-ops 的產文 AI 其實是外包給廠商 Elijah / Persona，你不掌控模型，也沒有成本熔斷。產品化要把這塊收回自建。

用 Claude API 直連（不走 Zeabur AI Hub）

理由：要做精準成本控管，需要 caching、token 用量這些原生欄位，AI Hub 的相容層拿不到（例如 cache_read_input_tokens）。AI Hub 留作備援比價。

每個功能配不同等級的模型（省錢關鍵）

成本控管（threads-ops 完全沒有，要全新做）

• 每次呼叫 AI 都記一筆用量與成本（usageLog）。
• 單一用戶月成本超「軟上限」自動降級（Opus → Sonnet），超「硬上限」直接熔斷擋下。
• 品牌定位 / 風格樣本放進 system prompt 並釘 caching，命中時讀取成本只剩約十分之一。
• 每人每天產文次數設軟限，防止「狂改重產」吃掉毛利。

毛利估算（待真實 prompt 校準）：單一付費用戶的 AI 成本約 US$3-8/月，對比訂閱 NT$500-900（Creator）/ NT$1,500+（Social Manager），毛利可以做到 80% 以上，前提是 caching 有命中、短任務別誤用 Opus。

7資料怎麼進來 + 數據變洞察

這是整個產品最關鍵、也最不確定的一層——資料怎麼自動長進系統。

好消息：現成的 Persona 後台其實已經是一個運作中的數據後台（帳號 → 貼文 → 每日數據 → 帳號日快照，還附 API），「數據追蹤」的骨幹已經存在，新系統是「接上它 + 補 IG + 加 Radar」，不是重造。

IG 資料（最大不確定，全部要送審才知道）

• 官方 Graph API 只能拿自家帳號的數據（粉絲、觸及、單篇成效），需要 instagram_basic + instagram_manage_insights 權限，且 IG 要是商業帳號並綁定 FB 粉專（要先確認 Zoe 每日e錠的狀態）。
• 要給別人用就得過 Meta App Review，這關最可能卡 2-6 週甚至被打回，是整案最大風險。
• 拿不到「別人帳號」的內容數據——所以 KOL Radar 不能靠這條（見第 8 節）。
• 對照 Zoe 的表：自家數據送審後可全自動；代操客戶願意授權才自動、否則半自動。

Threads 資料（三條路都通）

官方 API 拿自家貼文成效；登入態爬蟲可深爬任意公開帳號（已實證爬過競品三個帳號各數百到上千篇）。注意 token 是 60 天制、目前已過期要先重新授權。

數據 → 對應模型（你問的第三點）

把原始數字（粉絲 / 觸及 / 互動 / 播放）轉成洞察，全是純算式：成長率、互動率、爆文偵測（單篇超過近 30 篇中位數的 N 倍）、OKR 達成率自動算。沿用你現成的量化腳本（用「中位數對照」避免被高倍率假象騙）。

註：私訊 DM 兩個平台都沒有 API、自動化實測也無效 → 不要排進產品承諾。

8KOL Radar 設計（賣給廠商）

四步：探勘網紅清單 → 撈 profile 與數據 → 品質評分 → 廠商查詢後台。

建議：Threads Radar 用自建爬蟲；IG Radar 接第三方（自建 IG 爬蟲最容易把 Zoe 帳號封掉，不值得）。給廠商的產品先做「查詢後台 + 報表匯出」最快變現，開放 API 留到最後。

9你們已有 vs 要新建

這是最能讓人安心的一段：引擎做掉一半，新工集中在「多租戶 + 自建 AI + IG 資料 + KOL Radar + 匯出」。

技術優化四項對位（你列的）

• 社群策略健檢 = 競品分析（現成引擎）+ 定位落差 → AI 健檢報告。
• 內容產出文字調試 = 自建產文 + 品牌風格樣本 + 品質評分；要做 A/B 盲測確認追得上 Persona。
• 數據追蹤產生對應模型 = 見第 7 節的資料管線。
• KOL Radar 穩定爬蟲 = 見第 8 節。

10風險與未知