34 KiB
34 KiB
AI 自動經營 Threads 帳號系統規格書
目標：建立一套可以自動經營 Threads 帳號的 AI 系統。
系統不是單純產文，而是能夠「找話題、判斷切角、生成內容、檢查品質、發布排程、回收成效、分析原因、更新策略」的閉環內容營運系統。
0. 核心概念
這套系統的核心不是「AI 幫我寫一篇文」，而是：
AI 自動經營 Threads 帳號 =
話題雷達
+ 帳號大腦
+ 內容公式池
+ 切角推理
+ 品質閘門
+ 自動排程/發布
+ 成效回收
+ 策略自我更新
系統要做到：
- 自己發現新話題。
- 自己判斷話題適不適合帳號。
- 自己選擇內容任務，例如漲粉、互動、收藏、信任、人設。
- 自己從公式池選擇適合的開頭、中段、結尾、CTA。
- 自己產出多版本草稿。
- 自己檢查是否太 AI、太公式化、太像競品、太高風險。
- 自己排程或進入人工審核。
- 自己回收發文後的成效。
- 自己分析哪裡有效、哪裡沒效。
- 自己更新下一輪發文策略。
1. 系統總流程
flowchart TD
A[資料來源收集] --> B[資料清洗與解析]
B --> C[帳號大腦 Brand Brain]
C --> D[話題雷達 Topic Radar]
D --> E[話題評分與分類]
E --> F[內容策略決策器]
F --> G[公式池與切角引擎]
G --> H[AI 產文工廠]
H --> I[品質閘門 Gatekeeper]
I --> J{是否可發布}
J -->|高信心| K[自動排程/發布]
J -->|中信心| L[人工審核]
J -->|低信心| M[退回重寫]
L --> K
M --> H
K --> N[成效回收]
N --> O[成效分析]
O --> P[策略自我更新]
P --> D
2. 系統模組拆分
flowchart LR
A[Ingestion Service] --> B[Knowledge Brain Service]
B --> C[Topic Radar Service]
C --> D[Strategy Planner]
D --> E[Formula Engine]
E --> F[Content Generator]
F --> G[Quality Gatekeeper]
G --> H[Scheduler & Publisher]
H --> I[Insight Collector]
I --> J[Learning Engine]
J --> B
2.1 Ingestion Service
負責收集資料。
資料來源包含：
| 來源 | 用途 | 優先級 |
|---|---|---|
| 使用者上傳 Excel / Markdown / PDF | 建立帳號知識庫與風格資料 | 高 |
| 自己歷史貼文 | 學習帳號語氣、主題、成效 | 高 |
| Threads 關鍵字搜尋 | 發現新話題 | 高 |
| 指定競品帳號 | 拆解內容 DNA，不直接複製 | 高 |
| Brave Search / Google Search | 補充外部資料與查證 | 中 |
| RSS / 官方網站 | 專業帳號資料來源 | 中 |
| 手動輸入筆記 | 補充人設、想法、禁忌 | 中 |
| 留言與回覆 | 找粉絲真正關心的問題 | 高 |
2.2 Knowledge Brain Service
負責維護帳號大腦。
包含：
- Brand Memory：帳號設定、人設、語氣、禁用規則。
- Knowledge Memory：文件、主題、知識點、可引用資料。
- Style Memory：句型、開頭、結尾、CTA、語氣節奏。
- Formula Memory：不同任務對應的內容公式。
- Feedback Memory：成效、成功模式、失敗模式、人工評分。
2.3 Topic Radar Service
負責找話題、去重、分類、評分。
2.4 Strategy Planner
負責決定：
- 今天要發什麼主題。
- 這篇文的任務是什麼。
- 要用什麼切角。
- 要用什麼情緒槓桿。
- 要不要進人工審核。
2.5 Formula Engine
負責從公式池中挑出：
- 開頭方式。
- 中段結構。
- 情緒槓桿。
- 結尾方式。
- CTA 類型。
2.6 Content Generator
負責產出多版本草稿，並根據帳號語氣改寫。
2.7 Quality Gatekeeper
負責檢查：
- AI 感。
- 公式感。
- 相似度。
- 事實風險。
- 醫療、金融、法律等高風險內容。
- 帳號一致性。
- 發文頻率與疲乏度。
2.8 Scheduler & Publisher
負責排程與發布。
支援：
- Threads API 發布。
- Web Intent 半自動發文。
- 一鍵複製手動發文。
2.9 Insight Collector
負責回收成效。
收集：
- impressions。
- likes。
- replies。
- reposts。
- quotes。
- follows gained。
- profile visits。
- reply sentiment。
- manual rating。
2.10 Learning Engine
負責分析成效並更新策略。
3. 資料收集流程
flowchart TD
A[資料來源] --> B[Raw Data Pool]
B --> C[清洗 HTML / 雜訊]
C --> D[切 Chunk]
D --> E[抽取主題 Topic]
D --> F[抽取實體 Entity]
D --> G[抽取觀點 Claim]
D --> H[抽取語氣 Style]
D --> I[抽取公式 Pattern]
E --> J[Knowledge Brain]
F --> J
G --> J
H --> J
I --> J
J --> K[向量索引]
J --> L[關係資料]
3.1 匯入文件
支援格式：
.xlsx
.csv
.md
.txt
.pdf
.docx
.zip, for Obsidian vault
3.2 Excel 匯入邏輯
如果使用者上傳類似「小日子長大中.xlsx」這種內容檔案，可以這樣解析：
| Sheet 類型 | 解析用途 |
|---|---|
| 發文 | 當作歷史貼文範例、語氣樣本、主題樣本 |
| 產圖 | 當作 IG 輪播與視覺規格 |
| 脆文 | 當作 Threads prompt 與內容風格樣本 |
每一列轉成：
{
"source_type": "excel",
"sheet_name": "發文",
"title": "備孕搜尋紀錄",
"content": "開始備孕後，Google 或 AI 可能比我本人更了解我的身體狀況...",
"topics": ["備孕", "焦慮", "搜尋", "共鳴"],
"content_type": "情緒共鳴文",
"style_tags": ["溫柔", "真實", "口語", "不焦慮推進"]
}
3.3 Obsidian 匯入邏輯
Obsidian 不要當核心資料庫，只當匯入與輸出入口。
解析內容：
frontmatter
# headings
[[internal links]]
#tags
tables
paragraphs
attachments references
轉成：
{
"note_title": "第一次看生殖門診",
"tags": ["備孕", "生殖門診"],
"links": ["AMH", "FSH", "試管流程"],
"chunks": [],
"topics": [],
"claims": [],
"source_path": "/vault/備孕/第一次看生殖門診.md"
}
4. 帳號大腦 Brand Brain
flowchart TD
A[帳號基本設定] --> F[Brand Brain]
B[歷史貼文] --> F
C[上傳文件] --> F
D[競品分析] --> F
E[成效回饋] --> F
F --> G[Brand Memory]
F --> H[Knowledge Memory]
F --> I[Style Memory]
F --> J[Formula Memory]
F --> K[Feedback Memory]
4.1 Brand Memory
記住帳號是誰。
{
"account_name": "小日子長大中",
"persona": "拾日",
"positioning": "備孕、試管、孕育日常心境分享",
"tone": ["溫柔", "真實", "陪伴", "不焦慮推進"],
"avoid": ["太AI", "太醫療", "太雞湯", "保證效果", "過度正能量"],
"content_pillars": [
"備孕心情",
"試管流程",
"生殖門診",
"伴侶陪伴",
"等待焦慮",
"幽默共鳴"
],
"signature_lines": [
"不是只有成功那天，這段路才算數",
"把這些小小的日子，一點一點拾起來"
]
}
4.2 Knowledge Memory
記住專業知識與資料來源。
{
"topic": "第一次看生殖門診",
"knowledge_points": [
"可先整理月經週期",
"可準備過去檢查報告",
"可列出想問醫生的問題"
],
"risk_level": "medium",
"requires_fact_check": true,
"source_ids": ["doc_001", "doc_002"]
}
4.3 Style Memory
記住帳號怎麼說話。
{
"opening_patterns": ["其實我一直覺得", "有時候不是", "今天突然想到"],
"sentence_style": {
"short_sentence_ratio": 0.65,
"paragraph_spacing": "loose",
"emoji_usage": "low"
},
"common_endings": ["今天先這樣也沒關係", "慢慢來也算有在往前"],
"avoid_phrases": ["在這個快節奏的時代", "總而言之", "讓我們一起"]
}
4.4 Formula Memory
記住不同內容任務的公式。
{
"mission": "情緒共鳴文",
"formula": {
"opening": "真實情緒開場",
"body": "生活細節堆疊",
"emotion": "被理解感",
"ending": "溫柔但不雞湯",
"cta": "輕提問"
},
"use_case": ["等待焦慮", "月經來", "看到別人懷孕"],
"avoid": ["不要寫成衛教文", "不要硬塞解方"]
}
4.5 Feedback Memory
記住什麼有效。
{
"insight": "反差開場的 reply rate 高於帳號平均 42%",
"action": "提高反差開場權重",
"confidence": 0.78,
"applied_to_strategy_version": "v3"
}
5. 話題雷達 Topic Radar
flowchart TD
A[每日定時掃描] --> B[收集候選話題]
B --> C[去重]
C --> D[分類]
D --> E[熱度分數]
D --> F[帳號適配分數]
D --> G[互動潛力]
D --> H[可延伸性]
D --> I[風險分數]
E --> J[Topic Score]
F --> J
G --> J
H --> J
I --> J
J --> K[候選題庫]
5.1 話題評分公式
Topic Score =
熱度分數 * 0.25
+ 帳號適配度 * 0.30
+ 可延伸性 * 0.15
+ 互動潛力 * 0.15
+ 資料可信度 * 0.10
- 風險分數 * 0.20
5.2 話題分類
| 類型 | 用途 | 範例 |
|---|---|---|
| 熱點話題 | 跟上討論，提高曝光 | 最近大家在討論 AMH |
| 長尾知識 | 建立專業與收藏 | 第一次看生殖門診準備 |
| 情緒共鳴 | 增加轉發與留言 | 等待開獎真的很累 |
| 互動提問 | 養留言 | 大家第一次看診最怕什麼 |
| 人設生活 | 讓帳號像真人 | 今天只是好好吃飯 |
| 系列主題 | 長期內容資產 | 備孕小字典系列 |
5.3 Candidate Topic Schema
{
"id": "topic_001",
"account_id": "account_001",
"name": "第一次看生殖門診，可以準備什麼？",
"source": "keyword_search",
"category": "長尾知識",
"heat_score": 72,
"fit_score": 94,
"interaction_score": 68,
"extend_score": 85,
"risk_score": 35,
"final_score": 78.5,
"recommended_missions": ["收藏文", "互動文", "情緒共鳴文"]
}
6. 內容策略決策器 Strategy Planner
系統每次產文前，要先決定「這篇文的任務」。
flowchart TD
A[候選話題] --> B[讀取帳號策略]
B --> C[讀取最近貼文]
C --> D[讀取成效記憶]
D --> E[決定內容任務]
E --> F[決定切角]
F --> G[產生 Content Plan]
6.1 內容任務分類
| 任務 | 目的 | 適合公式 |
|---|---|---|
| 漲粉文 | 擴散、追蹤 | 共鳴、反差、痛點、金句 |
| 互動文 | 引留言 | 提問、二選一、經驗募集 |
| 收藏文 | 提高保存 | 清單、步驟、懶人包 |
| 信任文 | 建立專業與真實感 | 經驗、觀察、案例 |
| 人設文 | 讓帳號有個性 | 生活、價值觀、吐槽 |
| 轉換文 | 引導私訊/連結/資源 | 模板、工具、服務 |
| 系列文 | 長期經營 | 連載、週更、固定單元 |
6.2 Content Plan Schema
{
"topic": "第一次看生殖門診",
"mission": "互動文",
"target_audience": "準備第一次去生殖門診的備孕女性",
"angle": "診間會腦袋空白，所以先問大家都準備什麼",
"opening_type": "具體問題開場",
"body_type": "列出 3 個自己想到但不確定的問題",
"emotion": "緊張但想準備好",
"ending_type": "邀請補充",
"cta_type": "經驗募集型",
"risk_level": "medium",
"requires_human_review": true,
"avoid": [
"不要寫成衛教文",
"不要太完整，保留留言空間",
"不要溫柔金句收尾",
"不要使用最近 7 天重複用過的開頭"
]
}
7. 公式池與切角引擎 Formula Engine
flowchart TD
A[Content Plan] --> B[選擇開頭公式]
A --> C[選擇中段結構]
A --> D[選擇情緒槓桿]
A --> E[選擇結尾方式]
A --> F[選擇 CTA]
B --> G[組成產文指令]
C --> G
D --> G
E --> G
F --> G
7.1 開頭公式池
| 類型 | 用途 | 範例 |
|---|---|---|
| 情緒直球 | 快速共鳴 | 其實我一直覺得，備孕最累的是等待。 |
| 反差開場 | 提高停留 | 以前以為看診最難，後來發現最難的是不知道要問什麼。 |
| 場景開場 | 增加真人感 | 今天在診間等叫號的時候，腦袋突然一片空白。 |
| 衝突觀點 | 建立觀點 | 我不太喜歡別人說「放輕鬆就好」。 |
| 問題開場 | 引互動 | 第一次看生殖門診，大家最怕的是什麼？ |
| 自嘲開場 | 增加親近感 | 備孕後，我的 Google 搜尋紀錄比我本人還像醫生。 |
7.2 中段結構池
| 類型 | 用途 |
|---|---|
| 生活細節堆疊 | 情緒共鳴文 |
| 三點整理 | 收藏文、知識文 |
| 自問自答 | 觀點文、焦慮文 |
| 故事推進 | 人設文、信任文 |
| 對比以前和現在 | 成長型內容 |
| 錯誤觀念澄清 | 專業文 |
| 故意不講滿 | 互動文 |
7.3 情緒槓桿池
| 情緒 | 適合內容 |
|---|---|
| 被理解感 | 共鳴文 |
| 小小委屈 | 備孕、職場、生活 |
| 無奈但不崩潰 | Threads 短文 |
| 自嘲 | 反差、幽默 |
| 溫柔補償 | 陪伴帳號 |
| 不想說破的疲憊 | 深夜文 |
| 終於有人講出來 | 轉發型內容 |
7.4 結尾公式池
| 類型 | 用途 |
|---|---|
| 溫柔陪伴 | 情緒文 |
| 反諷補刀 | 幽默文 |
| 開放提問 | 互動文 |
| 收藏提醒 | 知識文 |
| 留白不收 | 日記文 |
| 系列預告 | 系列內容 |
7.5 CTA 公式池
| CTA 類型 | 範例 |
|---|---|
| 共鳴型 | 你也有這種感覺嗎？ |
| 經驗募集型 | 第一次看診你最慶幸自己有準備什麼？ |
| 補充型 | 有漏掉的也歡迎補充。 |
| 收藏型 | 可以先存起來，下次看診前翻一下。 |
| 轉發型 | 轉給那個一直叫你放輕鬆的人。 |
| 無 CTA | 讓文章自然停在情緒裡。 |
8. 防膩系統 Anti-Fatigue Engine
避免每篇都長一樣。
flowchart TD
A[新草稿] --> B[讀取最近 7/14/30 天貼文]
B --> C[檢查開頭重複]
B --> D[檢查結尾重複]
B --> E[檢查 CTA 重複]
B --> F[檢查任務比例]
B --> G[檢查句型相似度]
B --> H[計算膩感分數]
H --> I{是否過高}
I -->|是| J[退回重寫]
I -->|否| K[通過]
8.1 防重複規則
| 檢查項目 | 規則 |
|---|---|
| 開頭類型 | 連續 3 篇不能同類型 |
| 結尾類型 | 連續 3 篇不能都是溫柔金句 |
| CTA | 不能每篇都「你也會這樣嗎」 |
| 文章長度 | 長短文要交錯 |
| 情緒走向 | 不能每天都是焦慮到安慰 |
| 內容任務 | 不能連續 5 篇都是共鳴文 |
| 句型相似度 | 超過閾值退回重寫 |
| 主題密度 | 同一主題設定冷卻期 |
8.2 Fatigue Score
Fatigue Score =
Opening Similarity * 0.20
+ Ending Similarity * 0.20
+ CTA Similarity * 0.15
+ Structure Similarity * 0.25
+ Topic Repetition * 0.20
建議門檻：
0 - 40：安全
41 - 70：需要微調
71 - 100：退回重寫
9. AI 產文工廠 Content Generator
flowchart TD
A[Content Plan] --> B[生成初稿 A]
A --> C[生成初稿 B]
A --> D[生成初稿 C]
B --> E[帳號語氣改寫]
C --> E
D --> E
E --> F[真人感修稿]
F --> G[Threads 格式優化]
G --> H[版本評分]
H --> I[選出最佳版本]
9.1 生成版本
每次至少產 3 個版本：
| 版本 | 目的 |
|---|---|
| A 版 | 穩定帳號風格 |
| B 版 | 更有共鳴 |
| C 版 | 更容易互動 |
| D 版 optional | 更短、更 Threads |
| E 版 optional | 更幽默、更反差 |
9.2 產文指令格式
請產出一篇 Threads 文。
帳號：小日子長大中
人設：拾日
語氣：溫柔、真實、陪伴、不焦慮推進
主題：第一次看生殖門診
內容任務：互動文
切角：診間會腦袋空白，所以先問大家都準備什麼
開頭方式：具體問題開場
中段方式：列出 3 個自己想到但不確定的問題
情緒：緊張但想準備好
結尾方式：邀請補充
CTA：經驗募集型
禁止：
- 不要寫成衛教文
- 不要太像 AI
- 不要使用「在這個快節奏的時代」
- 不要溫柔金句收尾
- 不要超過 500 字
- 不要直接給醫療建議
10. 品質閘門 Quality Gatekeeper
flowchart TD
A[草稿] --> B[AI 感檢查]
A --> C[公式感檢查]
A --> D[競品相似度檢查]
A --> E[事實查證]
A --> F[風險檢查]
A --> G[帳號一致性檢查]
A --> H[發布頻率檢查]
B --> I[總分]
C --> I
D --> I
E --> I
F --> I
G --> I
H --> I
I --> J{決策}
J -->|高分| K[可自動排程]
J -->|中分| L[人工審核]
J -->|低分| M[退回重寫]
10.1 檢查分數
| 分數 | 說明 |
|---|---|
| ai_score | 越高代表越像 AI，需降低 |
| formula_score | 越高代表公式感越重 |
| brand_fit_score | 越高代表越符合帳號 |
| risk_score | 越高代表越危險 |
| similarity_score | 越高代表越像競品或過去貼文 |
| engagement_potential | 預測互動潛力 |
| freshness_score | 新鮮感 |
10.2 發布決策
總分 >= 85 且 risk_score < 30：可自動排程
總分 70 - 84：進人工審核
總分 < 70：退回重寫
risk_score >= 60：強制人工審核
similarity_score >= 75：退回重寫
ai_score >= 70：退回真人感修稿
10.3 高風險內容
以下內容預設不能全自動發布：
- 醫療建議。
- 金融投資建議。
- 法律判斷。
- 政治爭議。
- 指控個人或公司。
- 可能造成恐慌的資訊。
- 未查證的數據。
11. 排程與發布 Scheduler & Publisher
flowchart TD
A[通過品質閘門] --> B[選擇發布時間]
B --> C[檢查頻率限制]
C --> D[建立排程]
D --> E{發布方式}
E -->|API| F[Threads API 發布]
E -->|Web Intent| G[開啟半自動發文]
E -->|Manual| H[一鍵複製]
F --> I[記錄 post_id]
G --> I
H --> I
I --> J[等待成效回收]
11.1 發布策略
| 模式 | 用途 |
|---|---|
| API 自動發 | 權限完整、低風險內容 |
| Web Intent | API 權限不足時 |
| 一鍵複製 | 初期 MVP 或人工操作 |
11.2 排程策略
系統需要根據過去成效找出最佳時間。
第一版可先用簡單設定：
{
"posting_windows": ["12:00-13:30", "20:30-23:00"],
"max_posts_per_day": 3,
"min_gap_minutes": 180,
"high_risk_requires_review": true
}
12. 成效回收 Insight Collector
flowchart TD
A[已發布貼文] --> B[1 小時成效]
A --> C[6 小時成效]
A --> D[24 小時成效]
A --> E[72 小時成效]
B --> F[Performance DB]
C --> F
D --> F
E --> F
F --> G[成效分析器]
12.1 回收時間點
| 時間 | 用途 |
|---|---|
| 1 小時 | 初速判斷 |
| 6 小時 | 當日表現 |
| 24 小時 | 主要成效 |
| 72 小時 | 長尾成效 |
| 7 天 optional | 長期資料 |
12.2 指標
{
"post_id": "post_001",
"collected_at": "2026-07-02T21:00:00+08:00",
"impressions": 12000,
"likes": 580,
"replies": 72,
"reposts": 31,
"quotes": 8,
"follows_gained": 45,
"profile_visits": 320,
"engagement_rate": 0.057,
"reply_sentiment": "positive"
}
13. 成效分析 Performance Analyzer
flowchart TD
A[Performance DB] --> B[按主題分析]
A --> C[按公式分析]
A --> D[按開頭分析]
A --> E[按 CTA 分析]
A --> F[按情緒分析]
A --> G[按發布時間分析]
B --> H[洞察]
C --> H
D --> H
E --> H
F --> H
G --> H
13.1 分析問題
系統每次分析要回答：
- 哪個主題表現最好？
- 哪種開頭最容易讓人回覆？
- 哪種 CTA 真的有效？
- 哪種情緒最容易被轉發？
- 哪種內容最容易漲粉？
- 哪種內容收藏價值最高？
- 哪個發文時間效果最好？
- 哪些內容應該減少？
- 哪些內容可以延伸成系列？
13.2 分析結果範例
{
"account_id": "account_001",
"period": "last_14_days",
"insights": [
{
"type": "opening_pattern",
"finding": "反差開場的平均 reply rate 比帳號平均高 42%",
"recommendation": "下週提高反差開場權重，但避免連續使用",
"confidence": 0.82
},
{
"type": "content_mission",
"finding": "收藏文的 follows gained 較低，但 profile visits 較高",
"recommendation": "收藏文結尾加入更明確的人設介紹或系列預告",
"confidence": 0.74
}
]
}
14. 策略自我更新 Learning Engine
flowchart TD
A[成效分析] --> B[更新主題權重]
A --> C[更新公式權重]
A --> D[更新 CTA 權重]
A --> E[更新發布時間]
A --> F[更新禁用規則]
A --> G[更新內容比例]
B --> H[Strategy Version]
C --> H
D --> H
E --> H
F --> H
G --> H
H --> I[下一輪產文使用]
14.1 策略權重更新
第一版不要 fine-tune，先更新權重。
{
"strategy_version": "v3",
"content_mix": {
"emotion_posts": 30,
"knowledge_posts": 30,
"interaction_posts": 20,
"life_posts": 10,
"conversion_posts": 10
},
"opening_weights": {
"反差開場": 35,
"情緒直球": 25,
"問題開場": 20,
"場景開場": 15,
"金句開場": 5
},
"cta_weights": {
"經驗募集型": 35,
"收藏型": 25,
"共鳴型": 20,
"轉發型": 10,
"無CTA": 10
}
}
14.2 策略版本化
每次更新都要記錄原因。
{
"from_version": "v2",
"to_version": "v3",
"changes": [
{
"field": "content_mix.interaction_posts",
"from": 15,
"to": 20,
"reason": "過去 14 天互動文 reply rate 高於帳號平均 38%"
},
{
"field": "opening_weights.金句開場",
"from": 15,
"to": 5,
"reason": "金句開場連續三週互動下降，且 AI 感評分偏高"
}
]
}
15. Dashboard 設計
首頁應該像「AI 經營戰情室」。
15.1 首頁區塊
今日建議發文
- 推薦主題
- 推薦任務
- 推薦切角
- 推薦時間
- 風險提醒
草稿工廠
- 待審核
- 可排程
- 需重寫
- 已發布
昨日成效
- 最佳貼文
- 最差貼文
- 主要原因
- 下一步建議
策略更新
- 本週提高什麼比例
- 本週降低什麼比例
- 新增禁用規則
15.2 單篇貼文分析頁
貼文內容
內容任務：互動文
主題：第一次看生殖門診
開頭類型：問題開場
中段類型：故意不講滿
CTA：經驗募集型
成效：
- impressions
- likes
- replies
- reposts
- follows gained
AI 分析：
- 為什麼有效
- 哪裡可以更好
- 是否適合延伸成系列
- 下次建議用什麼變奏
16. DB Schema 草案
16.1 accounts
CREATE TABLE accounts (
id UUID PRIMARY KEY,
name TEXT NOT NULL,
platform TEXT NOT NULL DEFAULT 'threads',
persona TEXT,
positioning TEXT,
tone_config JSONB,
avoid_config JSONB,
content_pillars JSONB,
status TEXT DEFAULT 'active',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
16.2 sources
CREATE TABLE sources (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
type TEXT NOT NULL,
title TEXT,
url TEXT,
file_path TEXT,
raw_content TEXT,
parsed_status TEXT DEFAULT 'pending',
metadata JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
16.3 knowledge_chunks
CREATE TABLE knowledge_chunks (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
source_id UUID REFERENCES sources(id),
content TEXT NOT NULL,
topics JSONB,
entities JSONB,
claims JSONB,
style_tags JSONB,
risk_level TEXT,
embedding VECTOR,
created_at TIMESTAMP DEFAULT NOW()
);
16.4 topics
CREATE TABLE topics (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
name TEXT NOT NULL,
source TEXT,
category TEXT,
heat_score NUMERIC,
fit_score NUMERIC,
interaction_score NUMERIC,
extend_score NUMERIC,
risk_score NUMERIC,
final_score NUMERIC,
status TEXT DEFAULT 'candidate',
created_at TIMESTAMP DEFAULT NOW()
);
16.5 formula_pools
CREATE TABLE formula_pools (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
type TEXT NOT NULL,
name TEXT NOT NULL,
pattern TEXT,
use_case JSONB,
avoid JSONB,
weight NUMERIC DEFAULT 1,
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
16.6 content_plans
CREATE TABLE content_plans (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
topic_id UUID REFERENCES topics(id),
mission TEXT NOT NULL,
target_audience TEXT,
angle TEXT,
opening_type TEXT,
body_type TEXT,
emotion TEXT,
ending_type TEXT,
cta_type TEXT,
risk_level TEXT,
requires_human_review BOOLEAN DEFAULT FALSE,
avoid JSONB,
status TEXT DEFAULT 'planned',
created_at TIMESTAMP DEFAULT NOW()
);
16.7 drafts
CREATE TABLE drafts (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
content_plan_id UUID REFERENCES content_plans(id),
content TEXT NOT NULL,
version_name TEXT,
ai_score NUMERIC,
formula_score NUMERIC,
brand_fit_score NUMERIC,
risk_score NUMERIC,
similarity_score NUMERIC,
freshness_score NUMERIC,
status TEXT DEFAULT 'draft',
created_at TIMESTAMP DEFAULT NOW(),
updated_at TIMESTAMP DEFAULT NOW()
);
16.8 published_posts
CREATE TABLE published_posts (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
draft_id UUID REFERENCES drafts(id),
platform_post_id TEXT,
published_at TIMESTAMP,
publish_mode TEXT,
status TEXT DEFAULT 'published',
created_at TIMESTAMP DEFAULT NOW()
);
16.9 post_metrics
CREATE TABLE post_metrics (
id UUID PRIMARY KEY,
post_id UUID REFERENCES published_posts(id),
collected_at TIMESTAMP NOT NULL,
impressions INT,
likes INT,
replies INT,
reposts INT,
quotes INT,
follows_gained INT,
profile_visits INT,
engagement_rate NUMERIC,
metadata JSONB,
created_at TIMESTAMP DEFAULT NOW()
);
16.10 strategy_versions
CREATE TABLE strategy_versions (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
version TEXT NOT NULL,
content_mix JSONB,
opening_weights JSONB,
cta_weights JSONB,
formula_weights JSONB,
posting_windows JSONB,
change_reason JSONB,
is_active BOOLEAN DEFAULT FALSE,
created_at TIMESTAMP DEFAULT NOW()
);
16.11 learning_events
CREATE TABLE learning_events (
id UUID PRIMARY KEY,
account_id UUID REFERENCES accounts(id),
post_id UUID REFERENCES published_posts(id),
insight_type TEXT,
finding TEXT,
recommendation TEXT,
confidence NUMERIC,
applied_status TEXT DEFAULT 'pending',
created_at TIMESTAMP DEFAULT NOW()
);
17. API Endpoint 草案
17.1 Account
POST /api/accounts
GET /api/accounts/:id
PATCH /api/accounts/:id
GET /api/accounts/:id/brain
POST /api/accounts/:id/rebuild-brain
17.2 Source / Ingestion
POST /api/accounts/:id/sources/upload
POST /api/accounts/:id/sources/url
POST /api/accounts/:id/sources/obsidian-import
GET /api/accounts/:id/sources
POST /api/sources/:source_id/parse
17.3 Topic Radar
POST /api/accounts/:id/topic-radar/scan
GET /api/accounts/:id/topics
PATCH /api/topics/:topic_id
POST /api/topics/:topic_id/create-plan
17.4 Content Plan / Draft
POST /api/accounts/:id/content-plans
GET /api/accounts/:id/content-plans
POST /api/content-plans/:id/generate-drafts
GET /api/content-plans/:id/drafts
PATCH /api/drafts/:id
POST /api/drafts/:id/quality-check
POST /api/drafts/:id/approve
POST /api/drafts/:id/reject
17.5 Publishing
POST /api/drafts/:id/schedule
POST /api/drafts/:id/publish
GET /api/accounts/:id/calendar
17.6 Insights / Learning
POST /api/published-posts/:id/collect-metrics
GET /api/accounts/:id/performance
POST /api/accounts/:id/analyze-performance
POST /api/accounts/:id/update-strategy
GET /api/accounts/:id/strategy-versions
18. Worker / Cron Jobs
18.1 每日 Job
每日 08:00
- 掃描話題
- 更新候選題庫
- 產生今日內容建議
每日 10:00
- 根據今日內容建議產生草稿
- 執行品質檢查
- 高信心進排程，中信心進審核
每日 12:00 / 21:00
- 執行排程發文
18.2 成效回收 Job
每小時
- 找出已發布但未收 1h / 6h / 24h / 72h 成效的貼文
- 呼叫平台 API 收集 insights
- 寫入 post_metrics
18.3 每週學習 Job
每週一 09:00
- 分析過去 7 / 14 天成效
- 產生 learning_events
- 產生 strategy_version draft
- 若 confidence 高，自動套用低風險策略更新
- 若 confidence 中，進人工確認
19. MVP 開發階段
MVP 1：AI 社群助理
目標：先證明「找題 + 產文 + 檢查」有價值。
功能：
- 建立帳號。
- 上傳 Excel / Markdown。
- 建立 Brand Brain。
- 手動輸入關鍵字。
- AI 產生候選話題。
- AI 產生 Content Plan。
- AI 產 3 版草稿。
- AI 感與公式感檢查。
- 人工核准。
- 一鍵複製發文。
驗收：
使用者可以在 10 分鐘內：
建立帳號 → 匯入資料 → 產出 5 篇可用 Threads 草稿。
MVP 2：半自動營運
目標：開始排程與成效回收。
功能：
- Topic Radar 每日自動掃描。
- 自動產生每日 3-5 篇候選草稿。
- 人工審核。
- 排程發文。
- 手動或 API 回收成效。
- 產生週報。
驗收：
使用者每週只要審核草稿，系統能自動維持一週發文節奏。
MVP 3：低風險自動發布
目標：低風險內容自動發，高風險內容人工審。
功能：
- 自動發布低風險草稿。
- 高風險草稿強制人工審核。
- 發文後自動回收成效。
- 自動更新部分策略權重。
驗收：
系統能連續 14 天自動經營帳號，且不出現高風險錯誤內容。
MVP 4：自我改善閉環
目標：讓系統真的越跑越準。
功能：
- 每週自動分析成效。
- 自動調整內容比例。
- 自動調整公式權重。
- 自動產生內容節奏表。
- 生成策略版本與變更原因。
驗收：
系統能說明：
這週為什麼提高互動文比例，
為什麼降低某種開頭，
下週策略和上週有何不同。
20. Coding Agent 開發任務建議
Phase 1：資料模型與帳號大腦
1. 建立 DB schema。
2. 建立 Account CRUD。
3. 建立 Source upload API。
4. 實作 Excel parser。
5. 實作 Markdown parser。
6. 建立 Brand Brain builder。
7. 將 parsed content 寫入 knowledge_chunks。
Phase 2：話題與策略
1. 建立 Topic model。
2. 實作手動 keyword topic import。
3. 實作 Topic Score。
4. 建立 Content Plan generator。
5. 建立 Formula Pool seed data。
Phase 3：產文與品質檢查
1. 建立 Draft generator。
2. 每個 Content Plan 產出 3 版草稿。
3. 實作 AI 感檢查。
4. 實作公式感檢查。
5. 實作相似度檢查。
6. 實作人工 approve / reject。
Phase 4：排程與發布
1. 建立 Schedule table。
2. 實作草稿排程。
3. 實作一鍵複製模式。
4. 實作 Web Intent fallback。
5. 預留 Threads API publisher adapter。
Phase 5：成效與學習
1. 建立 Published Posts。
2. 建立 Post Metrics。
3. 實作手動成效輸入。
4. 實作 performance analyzer。
5. 產生 learning_events。
6. 建立 strategy_versions。
21. 產品原則
21.1 不要做洗稿工具
系統可以分析競品，但不能直接複製競品內容。
允許：
分析主題
分析切角
分析公式
分析情緒槓桿
分析 CTA
分析互動方式
禁止：
直接複製原文
高度相似改寫
批量搬運他人貼文
規避平台規範的自動化抓取
21.2 人設一致，但形式要變
語氣一致
主題一致
價值觀一致
但：
開頭要變
結尾要變
CTA 要變
長短要變
內容任務要變
21.3 高風險內容要保守
醫療、金融、法律類內容，預設要查證與人工審核。
21.4 自我改善要可解釋
AI 每次調整策略，都要說明：
調整了什麼
為什麼調整
依據哪段成效
信心分數多少
是否需要人工確認
22. 最終產品定位
這不是一般 AI 發文工具。
更精準的定位是：
AI Threads Account Operator
或：
AI Content Brain for Threads
一句話描述：
讓 AI 像內容編輯一樣，替每個 Threads 帳號找題、選切角、產文、排程、分析成效，並根據結果持續調整經營策略。
產品真正的價值不是「會寫文」，而是：
知道為什麼要發這篇，
知道這篇打中誰，
知道發完好不好，
知道下一篇要怎麼改。
23. 最終閉環摘要
flowchart TD
A[輸入帳號資料與知識] --> B[建立帳號大腦]
B --> C[每日找話題]
C --> D[挑選適合帳號的主題]
D --> E[決定內容任務]
E --> F[選公式與切角]
F --> G[產生多版本草稿]
G --> H[品質檢查]
H --> I[排程或人工審核]
I --> J[發布]
J --> K[回收成效]
K --> L[分析有效原因]
L --> M[更新策略權重]
M --> C
24. 建議第一版畫面
24.1 帳號大腦頁
帳號名稱
人設
定位
語氣
禁用語
主題池
公式池
知識來源
歷史貼文
成效記憶
24.2 今日話題雷達
今日推薦主題
- 熱度
- 帳號適配度
- 互動潛力
- 風險分數
- 推薦內容任務
24.3 草稿工廠
草稿列表
- 內容任務
- 主題
- 公式組合
- AI 感分數
- 公式感分數
- 風險分數
- 狀態
24.4 成效分析頁
已發布貼文
成效數據
AI 分析
下次建議
是否延伸系列
24.5 策略版本頁
目前策略版本
內容比例
公式權重
CTA 權重
發布時間
本次調整原因
25. 開發時的最小可交付結果
第一個可交付版本只需要做到：
1. 建立一個帳號。
2. 上傳一份 Excel。
3. 系統解析出帳號大腦。
4. 手動輸入一個主題。
5. 系統產出 Content Plan。
6. 系統產出 3 篇 Threads 草稿。
7. 系統檢查 AI 感與公式感。
8. 使用者可以 approve / reject。
9. 系統記住這次人工回饋。
這樣就可以開始驗證核心價值。
不要一開始就把所有 API、圖譜、全自動發布都做完。
先讓 AI 真的能寫出「像這個帳號」的內容，再讓它慢慢接管營運。