NailPost 自動發文工作流複盤

在社群媒體當道的時代，品牌帳號的經營往往需要耗費大量的時間與心力。為了替 Nailora 品牌帳號（IG + Threads）打造高效的內容產出流程，筆者獨立開發並實作了一條名為 NailPost 的自動化發文工作流。這條管線實現了「每週掃描趨勢、AI 生成文案與美甲圖、Puppeteer 渲染輪播圖、Email 送審、CLI 核准、每日自動發布」的全自動生產線。

本文將複盤這個「機器產、人把關」管線的架構設計、技術棧，以及在對抗社群平台反爬蟲與發文限制時累積的實戰經驗。

成果速覽

透過 NailPost 專案，我們成功建立了以下成果：

全自動內容管線：一條從「趨勢掃描 → AI 生成 → 渲染 → 送審 → 發布」的完整內容流水線，使用 node-cron 進行常駐排程。
「機器產、人把關」安全機制：AI 生成內容後會自動寄送 Email 送審，必須由人工在 CLI 上核准（approve）後才會正式發布。這項設計守住了品牌帳號的安全底線，避免 AI 內容直接上線而出包。
摸清社群平台限制：深入掌握了 TikTok、Pinterest、Instagram 與 Threads 的反爬蟲與發文限制，並將這些限制直接內建為流程的約束條件。

技術棧與架構設計

為了保持 MVP（最小可行性產品）階段的輕量化，我們在儲存上選擇了純本地 JSON 檔，無使用資料庫。整體技術棧配置如下：

環節	技術
趨勢爬蟲	Puppeteer（TikTok、Pinterest）+ Cheerio（媒體源）
AI 文案 / 生圖	Gemini（文案用 pro 系列、美甲圖用 flash image 系列）
圖片渲染	Puppeteer + Handlebars 樣板 HTML（多種版型 + 品牌色）
排程	node-cron（常駐自動執行）
送審通知	Nodemailer + Gmail SMTP
發布	Instagram Graph API + Threads API（同一 Meta App）
儲存	純本地 JSON 檔，無資料庫

系統架構概觀

整條管線的運作流程如下：

每週定時觸發：
  1. 趨勢掃描（多來源加權）：TikTok / Pinterest / 媒體源 / 品牌新品
        -> 加權週報 JSON
  2. AI 生成：週報 -> 數篇選題 + IG 文案 + Threads 文案
  3. AI 生圖：依參考圖庫匹配風格 -> 生成美甲圖
  4. 渲染：Puppeteer + Handlebars -> 輪播圖 + 限動圖
  5. 送審：Nodemailer 把預覽寄 Email
  6. 人工核准：CLI approve / reject
  7. 每日定時發布：IG carousel + Threads 貼文 -> 記錄發文

關鍵設計決策與經驗

在規劃與執行這個專案的過程中，筆者整理出幾個關鍵的設計決策，這些經驗對於任何想做內容自動化的人來說都極具參考價值：

1. 人審閘門不可省

雖然目標是自動化，但 AI 生成內容直接自動發布的風險極高。因此，在流程中加入一道「Email 送審 + CLI approve」的人工關卡，是維護品牌帳號形象與安全性的底線。

2. 多來源加權而非單一來源

趨勢資料如果只依賴單一平台，很容易因為該平台政策變更、反爬蟲升級或資料失準而導致整條管線中斷。NailPost 選擇從多個平台與媒體源抓取趨勢，並按照設定的權重進行合併，提高了系統的容錯率與趨勢精準度。

3. 跨語言關鍵字映射

美甲界的流行詞彙在不同語言中可能有完全不同的說法（例如：鍍鉻、mirror、或各語系的特定稱呼）。為此，我們建立了關鍵字映射表進行歸類，這大幅提升了跨來源趨勢確認的準確度。

4. 生圖品質的 Prompt 控管

利用 AI 進行美甲生圖時，最常遇到的問題是產生莫名的文字或浮水印。我們在多處 Prompt 中強力禁止生成任何文字與浮水印，並餵給 AI 真實的參考圖，同時明確指示它忽略參考圖上的浮水印。若偶爾仍有不完美的圖片，系統也支援手動重新生成單張圖片的機制。

5. 降低複雜度，純 JSON 儲存

在 MVP 階段，為了降低開發與部署的複雜度，發文記錄與草稿皆存放在本地的 JSON 檔案中，免去了維護資料庫的成本。

社群平台踩雷與限制約束

在與各大社群平台對接時，我們踩過了無數的坑。這些平台限制在設計自動化流程時，必須直接當作系統的「第一級約束」：

TikTok 反爬升級：TikTok 的內部 API 容易被擋，必須偽造 user-agent 並加入延遲時間。此外，CJK（中日韓）語系的 hashtag 容易被重導向，需要特別跳過。
Pinterest 完整搜尋限制：Pinterest 進行完整搜尋時需要登入帳號。考量到自動登入容易面臨封號風險，我們改採用了爬蟲備援方案。
Instagram 限制：IG 的輪播圖（Carousel）上限大約是 10 張，因此在 Puppeteer 渲染圖片時，就必須將頁數嚴格控制在上限之內。
Threads 限制：Threads 的文字長度有上限，文案必須與 IG 分開撰寫。我們採用的策略是：IG 走精美圖文路線，Threads 則偏向口語化與使用問句來引導討論。
API 發文頻率限制（Rate Limit）：日常的週更頻率遠低於平台的發文上限，但如果遇到需要大批補發貼文的情況，很容易會撞到限制，因此流程中必須針對不同平台進行節流（Throttling）。
Meta OAuth 權限申請：IG 與 Threads 的內容發布權限是分開的，必須在 Meta App 中分別申請，且存取權限（Token）需要定期進行刷新。

安全與金鑰管理

本專案運行時需要使用多個敏感的金鑰，包括 IG/Threads 商業帳號的 OAuth token、Gemini API key、Gmail SMTP 認證以及 Pinterest cookies。為了確保帳號安全，這些敏感資料一律只存放在本機的 .env 檔案中，絕對不能進入版本控制系統（Git）。

小結

內容自動化真正的價值在於「降低重覆性的人力消耗」，但內容品質與帳號安全的最後一關，永遠應該留給人類來把關。任何想要長期穩定運作的社群自動化專案，平台方的反爬蟲機制與 API 發文限制，都是在設計架構時就必須摸透並納入考量的核心約束。

Jun 的學習筆記

探索