Content Cascade Engine：寫一篇部落格，自動變出 5 篇社群貼文
寫部落格最痛苦的不是寫，是寫完之後
我相信大部分有在經營內容的人都遇過同樣的問題：
你花了兩小時寫了一篇技術文章。寫完的那一刻，你覺得很有成就感。
然後你想到：「啊，我還要把這篇的重點整理成 Threads 貼文。」
於是你打開 Threads，盯著空白的發文框，開始想：這篇文章的核心論點是什麼？要用什麼 hook 開頭？要切幾則？每則的角度要不同但又要連貫...
又花了一個小時。
最後你產出了 6 則內容（1 篇部落格 + 5 則社群），但花了 3 小時。其中 1/3 的時間花在「把已經寫過的東西用不同方式再講一遍」。
這不是創作，這是搬運。而搬運應該交給機器。
Content Cascade Engine：自動內容瀑布
三月底我建了一套系統叫 Content Cascade Engine。
概念很簡單：你寫部落格，系統自動把它拆成社群貼文。
┌─────────────────────────────────────────────────┐
│ Content Cascade │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Blog MD │───▶│ Ollama │───▶│ MindThread│ │
│ │ (new post)│ │ultralab:7b│ │ API │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │ │ │ │
│ 每天 07:00 拆成 3-5 篇 自動發布到 │
│ 掃描新文章 不同角度的 @ultralab.tw │
│ 社群短文 Threads 帳號 │
│ │
│ 成本：$0 模型：本地 人工：0 分鐘 │
└─────────────────────────────────────────────────┘
跑在 WSL2 裡，用 systemd timer 每天早上 7 點觸發。整個流程大概 45 秒跑完。
完整流程拆解
Step 1: 偵測新文章
# content-cascade.sh 核心邏輯（簡化版）
BLOG_DIR="/mnt/c/Users/User/UltraLab/content/blog"
POSTED_LOG="$HOME/.openclaw/data/cascade-posted.json"
# 找出 24 小時內新增或修改的 .md 文件
NEW_POSTS=$(find "$BLOG_DIR" -name "*.md" -newer "$POSTED_LOG" -type f)
if [ -z "$NEW_POSTS" ]; then
echo "[cascade] No new posts found. Exiting."
exit 0
fi
系統會比對一個 JSON log 檔案，確保每篇文章只會被 cascade 一次。修改過的舊文章不會重複發。
Step 2: 提取文章內容
讀取 Markdown 檔案，去掉 frontmatter，把純文字內容送進 Ollama。
# 提取文章正文（去掉 frontmatter）
CONTENT=$(sed '1{/^---$/!q;};1,/^---$/d' "$POST_FILE")
TITLE=$(grep '^title:' "$POST_FILE" | sed 's/title: *"\(.*\)"/\1/')
TAGS=$(grep '^tags:' "$POST_FILE" | head -1)
Step 3: Ollama 拆分（關鍵步驟）
這是整個系統最核心的部分 — Prompt 的設計決定了產出品質。
PROMPT=$(cat <<'PROMPT_END'
你是 Ultra Lab 的社群內容策略師。
## 任務
將以下部落格文章拆分成 3-5 則 Threads 貼文。
## 規則
1. 每則貼文必須獨立成立 — 沒讀過原文的人也能看懂
2. 每則 200-280 字（繁體中文），不超過 300 字
3. 每則用不同的 hook 類型開頭：
- 反直覺觀點（「大家都說 X，但其實...」）
- 個人經驗（「上週我花了 3 小時在...」）
- 數據驅動（「我們測了 30 天，結果...」）
- 問題引導（「你有沒有想過為什麼...」）
- 實用技巧（「這個方法幫我每天省 1 小時：」）
4. 語調：技術人的口語，不要行銷腔。可以用「我」、「你」
5. 每則結尾加一個 CTA 或思考問題
6. 不要用 emoji 轟炸，最多每則 1-2 個
7. 包含 1-2 個相關 hashtag
## 輸出格式
用 --- 分隔每則貼文。只輸出貼文內容，不要加編號或說明。
## 文章標題
{TITLE}
## 文章內容
{CONTENT}
PROMPT_END
)
注意幾個設計重點：
Hook 類型多樣化 — 強制要求每則用不同的 hook 開頭，避免 5 則貼文讀起來像同一個模子刻出來的。
字數限制精確 — 200-280 字是 Threads 的甜蜜點。太短沒深度，太長沒人看。我測了 300+ 則貼文的數據，200-280 字的完讀率比 300+ 字高 34%。
獨立成立 — 這是最重要的規則。社群貼文不能假設讀者看過你的部落格。每則必須自帶上下文。
語調控制 — 「技術人的口語」這六個字比寫一大段 prompt 有用。Ollama 理解這個指令的效果出奇地好。
Step 4: Ollama 推理
RESPONSE=$(curl -s http://localhost:11434/api/generate \
-d "{
\"model\": \"ultralab:7b\",
\"prompt\": \"$ESCAPED_PROMPT\",
\"stream\": false,
\"options\": {
\"temperature\": 0.75,
\"top_p\": 0.9,
\"num_predict\": 2048
}
}" | jq -r '.response')
用的是我們自己 fine-tune 的 ultralab:7b 模型（基於 Qwen2.5:7b），跑在 RTX 3060 Ti 上，推理速度約 13.2 tok/s。生成 5 則貼文大概 30-40 秒。
Temperature 0.75 是反覆測試的結果。0.5 太保守，產出的 hook 太相似；1.0 太發散，偶爾會跑題。0.75 在多樣性和準確性之間取得好平衡。
Step 5: 透過 MindThread API 發布
# 拆分回應為個別貼文
IFS='---' read -ra POSTS <<< "$RESPONSE"
for post in "${POSTS[@]}"; do
CLEAN_POST=$(echo "$post" | sed '/^$/d' | head -20)
[ -z "$CLEAN_POST" ] && continue
# 透過 MindThread API 發布到 Threads
curl -s -X POST "http://localhost:18789/api/mindthread/post" \
-H "Content-Type: application/json" \
-d "{
\"accountId\": \"vll91c1mmN8ZowrvfNuc\",
\"content\": \"$ESCAPED_POST\",
\"source\": \"cascade\"
}"
sleep 300 # 每則間隔 5 分鐘，避免被判為垃圾訊息
done
MindThread 是我們自己的 Threads 自動化系統，管理 27 個帳號。Content Cascade 的產出直接走 MindThread API 排程發布到 @ultralab.tw 帳號。
實際案例：一篇文章 → 五則貼文
拿上週的文章《一個人怎麼同時管 5 個產品》當範例。
原始文章
2400 字的技術文，講一人公司如何用 AI Agent 和 Claude Code 同時管理 5 個產品線。
Cascade 自動產出
貼文 1（反直覺 hook）：
一個人同時跑 5 個產品，在正常世界裡是自殺行為。但如果你的「團隊」是 4 隻 AI Agent + Claude Code 呢？
我現在同時管 UltraLab、MindThread、Ultra Advisor、UltraTrader、OpenClaw。分佈在 3 台機器、4 種語言、2 個 Firebase 專案。
關鍵不是你有多少時間，是你有沒有把「決定做什麼」這件事也自動化。
每天早上我的系統自動掃描 5 個產品的狀態，排出優先級，我只需要執行。
一人公司最大的敵人不是能力，是決策癱瘓。 #一人公司 #AI自動化
貼文 2（數據 hook）：
我算過，如果 5 個產品各需要一個 3 人團隊，我需要 15 個人。
實際上我有：我自己 + 4 隻 AI Agent + 34 個 systemd timer。
過去 30 天的數字：UltraLab 接了 3 個案、MindThread 330 萬次觀看、Ultra Advisor 63 篇 SEO 文章。全部同時在跑。
秘密不是「什麼都自己做」，是「建系統讓你不用自己做」。
你的一天有幾個小時花在重複的決策上？ #BuildInPublic
貼文 3（實用技巧 hook）：
這個方法幫我每天省 2 小時：把 context switch 的成本交給 AI。
我的 Coordinator 架構：每天早上 Agent 自動彙整 5 個產品的 git log、錯誤紀錄、用戶回饋，產出一份「今日行動清單」。
我不需要花 30 分鐘回想「昨天 UltraTrader 那個 bug 修到哪了」。系統直接告訴我。
人腦不該用來記事情，人腦應該用來做判斷。 #效率工具
貼文 4（問題 hook）：
你有沒有想過，為什麼大公司可以同時做 10 個產品，你做 2 個就快累死？
不是因為他們有更多人。是因為他們有系統。
差別在：大公司的系統是 Jira + Slack + 週會。一人公司的系統可以是 AI Agent + 自動排程 + 零會議。
我把 5 個產品的監控、報告、排程全部自動化。週報是 Agent 自動寫的，日報是 systemd timer 自動跑的。
一人公司不是什麼都一個人做，是建一個系統讓一個人就夠。 #SaaS
貼文 5（個人經驗 hook）：
上週三早上，我的 Ollama 記憶體飆到 2G 被 systemd 砍掉。
同一時間 MindThread 有 3 個帳號觸及率下降，Ultra Advisor 有客戶回報手機跑版。
三件事同時爆。如果是以前的我，大概會先焦慮 30 分鐘。
但系統已經自動排好優先級：Ollama（影響所有 Agent）> 客戶 bug > 觸及率（可以晚點處理）。
建系統不是為了順風時省時間，是為了逆風時不崩潰。 #開發日常
品質比較：手寫 vs Cascade
我做了一個月的 A/B 測試：
| 指標 | 手寫貼文 | Cascade 貼文 | 差異 |
|---|---|---|---|
| 平均觸及 | 1,420 | 1,285 | -9.5% |
| 互動率 | 4.2% | 3.8% | -0.4% |
| 完讀率 | 67% | 71% | +4% |
| 產出時間 | 12 min/篇 | 0 min/篇 | -100% |
| 每週產出量 | 5-8 篇 | 15-25 篇 | +200% |
結論：Cascade 單篇品質略低 10%，但產量高 3 倍。
觸及量 = 品質 x 數量。就算每篇少 10% 觸及，多 3 倍的量讓總觸及翻倍。
而且有一個意外發現：Cascade 的完讀率比手寫還高。我推測原因是 Prompt 強制要求 200-280 字，自然維持在甜蜜點。手寫時我偶爾會寫到 400+ 字，完讀率就掉了。
系統比人更守紀律。
30 天數據
Content Cascade 上線 30 天的實際數據：
部落格文章產出： 12 篇
Cascade 自動社群貼文： 47 篇
平均每篇文章分裂數： 3.9 篇
自動發布成功率： 97.9%（1 篇因 API timeout 失敗，手動重發）
Ollama 推理失敗： 0 次
每日運算成本： $0（本地 GPU）
總內容產出： 59 篇（12 + 47）
如果全部手寫： 約 42 小時
實際花費時間： 約 24 小時（只寫部落格）
節省時間： 18 小時/月
每個月省下 18 小時的內容搬運時間。這 18 小時我可以拿去寫更多部落格、做產品、或睡覺。
為什麼用 Ollama 而不是 Gemini / Claude API
這是最常被問的問題。我同時有 Gemini 和 Claude 的 API 存取權限，為什麼 Content Cascade 選擇用本地的 Ollama？
1. 成本
Cascade 每天跑一次，每次處理 1-3 篇文章，每篇約 2000 token input + 1500 token output。
| 方案 | 每月成本 | 每年成本 |
|---|---|---|
| Ollama (本地) | $0 | $0 |
| Gemini Flash | ~$0.30 | ~$3.60 |
| Claude Haiku | ~$1.80 | ~$21.60 |
| GPT-4o mini | ~$1.20 | ~$14.40 |
Gemini Flash 其實很便宜，但 $0 更便宜。而且我已經有 GPU 在跑其他 Agent 任務了，邊際成本是零。
2. 隱私
部落格內容理論上是公開的，所以隱私不是硬需求。但我有一個原則：能不送出去的數據就不送出去。 養成習慣。
3. 可靠性
API 會掛。Gemini 在三月初掛過一次 3 小時（正好是我的 cascade 時段）。Ollama 跑在自己的機器上，只要不停電，它就在。
4. 延遲
Ollama 在本地跑，沒有網路延遲。整個 cascade 流程 45 秒完成。走 API 大概要 2-3 分鐘（考慮網路 + rate limit）。
5. 品質夠用
社群貼文不需要 Claude Opus 等級的推理能力。Qwen2.5 7B 的中文能力在這個任務上完全夠用。我測過 Claude Sonnet 和 Ollama 的產出品質差異大概 5-8%，但社群貼文的讀者不會注意到這個差異。
用大模型做小任務是浪費。 就像你不會用 Ferrari 去超市買菜一樣。
進階：Cascade 的自我修正
系統不是完美的。最常見的問題是 Ollama 偶爾會產出格式不對的回應（沒有用 --- 分隔、某則超過 300 字）。
我加了一層後處理：
validate_post() {
local post="$1"
local char_count=$(echo -n "$post" | wc -m)
# 字數檢查
if [ "$char_count" -gt 320 ]; then
echo "[cascade] Post too long ($char_count chars), truncating..."
post=$(echo "$post" | head -c 850) # UTF-8 中文約 3 bytes
post="${post}..."
fi
# 空白檢查
if [ "$char_count" -lt 50 ]; then
echo "[cascade] Post too short, skipping."
return 1
fi
echo "$post"
}
加了這層之後，發布成功率從 91% 提升到 97.9%。
你也可以做到
Content Cascade 的核心概念不難：
- 有一個內容源（部落格、YouTube、Podcast）
- 有一個 LLM（Ollama、Gemini、ChatGPT 都行）
- 有一個分發管道（Threads API、Twitter API、IG API）
- 寫一個腳本把它們串起來
如果你不想自己建，我們的 UltraGrowth 全託管方案 包含了 Content Cascade 功能：
- 你寫文章（或我們幫你寫）
- 系統自動分裂成社群貼文
- 自動排程發布到多個平台
- 每月報表追蹤成效
一篇文章的價值不該只停在部落格。讓它 cascade 下去。
技術細節速查
| 項目 | 規格 |
|---|---|
| 排程 | systemd timer, 每天 07:00 CST |
| LLM | Ollama ultralab:7b (Qwen2.5 7B base) |
| GPU | NVIDIA RTX 3060 Ti 8GB |
| 推理速度 | ~13.2 tok/s |
| 每篇處理時間 | ~45 秒 |
| 發布目標 | Threads @ultralab.tw via MindThread API |
| 分裂數 | 3-5 篇/文章 |
| 成功率 | 97.9% |
| 月成本 | $0 |
寫一次，發五次。這就是 cascade 的意義。