多平台發文如何自動化？我捨棄 Buffer，用 n8n 串 API 一次發三平台

前言

同時經營 FB、IG、Threads 的行銷人都懂，每篇貼文複製貼上三遍、再分別調格式，光發文就吃掉半個下午。多平台發文自動化就是要把這件事交給系統：我捨棄 Buffer 這類現成工具，改用 n8n 自己串各平台 API，把一篇定稿一次送上三個平台。這篇會講為什麼這樣選、怎麼串，還有中間卡住的地方怎麼解——你不用是工程師也做得到，整套工作流文末也直接免費送你。

為什麼我沒用 Buffer，改自己用 n8n 串 API 發文

會想做社群貼文自動化的人，多半第一個想到的就是 Buffer、Hootsuite 這類現成排程工具。我也用過，它們很適合「我就一個帳號、發一樣的內容」的情況。但我是在行銷公司幫客戶顧帳號，需求一變多，這類工具的天花板就很明顯。最後我選擇自己用 n8n 串 API，原因有三個。

月費跟帳號數綁在一起，客戶一多就不划算

現成工具的訂閱方案，幾乎都是用「可連幾個社群帳號」「幾個團隊成員」來分級。我手上是好幾個客戶、每個客戶又有 FB／IG／Threads 三個帳號，這樣算下來每個月的費用很可觀，而且帳號越多、費用越高，成本是隨規模一直往上加的。改用 n8n 之後，這些發文流程都跑在自己的伺服器上，增加一個客戶幾乎沒有額外成本。

同一篇硬發三平台，不能各自調語氣和格式

FB 可以放長一點、Threads 偏短、IG 重圖配短文，三個平台的調性本來就不一樣。多數現成工具的「一次發多平台」是把同一段文字原封不動丟出去，頂多幫你裁圖。自己串就不一樣——我可以在流程中間插一段 AI 改寫，讓同一個主題，自動產出三個平台各自合適的版本，這是現成工具給不了的彈性。

平台規則一變只能乾等，自己串主動權在手上

社群平台的 API 三不五時改版，現成工具要等它們的工程團隊跟上，你只能等。自己用 n8n 串，哪天 Threads 開放新功能、或某個欄位改名，我自己改一個節點就好，不用看別人臉色。對長期經營來說，這個主動權比省下的設定時間更重要。

整體架構：一篇貼文怎麼同時串上 FB、IG、Threads

先把範圍講清楚。內容怎麼產、發出去前怎麼讓人審核，我在另一篇〈n8n + Claude Code 自動產生社群貼文：AI 小編生成器製作教學〉裡拆過——那篇講的是怎麼讓 AI 把一個主題自動生成圖＋文案、整理成可以直接發的定稿。這篇接在它後面：假設定稿都備好、也經人核准、登記在一張 Google Sheets 待發表單裡了，我們就從這裡開始，專心講怎麼把同一篇同時串上三個平台。下面這張是這條發文工作流在 n8n 裡的真實長相。

起點：一張已經備好定稿的 Google Sheets

這條流程的起點，是圖上最左邊那張 Google Sheets 待發表單——你可以把它想成「已經寫好、排定要發的貼文都放這裡」。接著「抓最新一篇」會去表裡挑出最新的一筆，「發文 token」再幫它配上這個客戶對應的各平台發文憑證（access token）。表單裡的內容一定是人核准過的，所以這條流程只負責「發」、不負責「決定要發什麼」。至於圖和文要怎麼自動生成、發前怎麼送審，那是另一條流程的事，我在AI 小編生成器那篇講過，這裡就直接從「定稿已經在表單裡」接著往下講。

主幹：配好 token 之後，分三條線送出去

憑證準備好，n8n 就把這篇分成三條線：FB、IG、Threads 各走各的。看上面那張圖最明顯的，是三條線的長度差很多——FB 一個節點就發完，IG 卻要一路接「抓 ID → 建容器 → 等待 → 發文」，Threads 也要「建容器 → 等待 → 發文」才送得出去。同樣是「發一篇」，為什麼差這麼多？這正是自己串多平台 API 最花時間的地方，下一段拆給你看。各平台憑證怎麼設定，可以參考 n8n 官方的憑證設定文件。

FB、IG、Threads 的發文 API，做法其實不一樣

很多人以為「發文」就是把文字丟出去這麼一件事，三平台應該大同小異。實際串下去才知道，三個平台一步到位的只有一個，另外兩個都要分好幾步。這也是用現成工具永遠看不到、自己串才會撞上的差別。先用一張表看全貌。

平台	走哪支 API	發一篇要幾步	關鍵差異
Facebook	Meta Graph API	1 步	圖加文直接送出
Instagram	Meta Graph API	3 步	先拿 IG 帳號 ID → 建容器 → 發布
Threads	Threads API	2 步	建容器 → 發布

Facebook：一個請求就發完，最好搞

FB 是三個裡面最單純的。把圖片網址、貼文文字、發文憑證一起丟給 Graph API 的發文入口，一個請求就發出去了，沒有什麼眉角。如果你只發 FB，老實說自己串和用現成工具差別不大。麻煩的是另外兩個。

Instagram：要先拿帳號 ID、再建容器，才能發布

IG 是三個裡面步驟最多的。它沒有獨立後門，得先透過 FB 粉專去問出「這個粉專綁的 IG 商業帳號 ID」，拿到 ID 之後也不能直接發——要先把圖和文字送去建立一個媒體容器，等容器準備好，再用容器的編號去「發布」。等於同一篇 IG 貼文，要打三次 API 才出得去。

Threads：跟 IG 一樣兩段式，中間一定要等

Threads 雖然是獨立 API，邏輯卻跟 IG 很像：先建立容器、再發布。而且這兩步中間不能連著打，因為平台需要一點時間把你傳的圖片處理好。我在流程裡放了一個等待節點，讓它停 10 秒再去發布。這個「等」一開始最容易被忽略，後面〈我卡最久的一次〉那段會講到我就是栽在這裡。

自己串 API 最麻煩的一件事：Token 會過期

如果說 IG 兩段式是「一開始會卡」，那 token 過期就是「上線之後才會出事」的那種狀況，而且更麻煩，因為它不會當場報錯給你看。這也是用 Buffer 永遠不用煩、自己串就必須自己扛的一件事。

為什麼用現成工具不用管、自己串就得管

每個平台的發文憑證（access token）都有有效期限，Meta 這邊的長期 token 大約兩個月就會到期。現成工具會在背後幫你默默續期，所以你從來不會感覺到它的存在。自己串 API 的話，這件事就變成你的責任——token 一過期，所有發文請求都會被擋下來。

我另外寫了一條每月自動更新 token 的工作流

為了不要每兩個月手動換一次，我另外做了一條獨立的工作流：每個月固定一天自動跑，把所有客戶撈出來、篩出有 token 的，逐一去跟平台換一張新的長期 token，確認換成功之後寫回資料庫。這條和發文那條是分開的，各做各的事，互不干擾。

更新失敗一定要被通知，不然會默默發不出去

這條工作流最後我刻意加了一步：換完之後統計成功幾筆、失敗幾筆，再主動通知我。原因很實際——token 出問題時不會有人提醒你，等到客戶問「我這週怎麼沒發」才發現，就太慢了。讓系統主動回報，我才能在它真的影響到發文前先處理掉。這個習慣是吃過虧之後才養成的。

發文之後：怎麼確認三個平台都成功發出去

自動化最怕的不是發不出去，而是「以為發出去了，其實沒有」。所以發文那一刻不是流程的結束，後面還有兩件事要顧：留紀錄、和確認。

每篇發布結果寫回 Google Sheets 留底

每一篇發完，我都會把結果回寫到那張表單，標記這篇已經發了。這樣做有兩個好處：一是不會重複發同一篇，二是哪天想回頭查「這個客戶這個月發了幾篇、哪天發的」，打開表就看得到，不用一個一個平台去翻。

三平台都成功才通知，避免漏發沒人發現

FB、IG、Threads 三條線我會等它們都跑完，合流之後（就是圖上那個 Merge 節點）才發出一則通知。這則回報走 LINE——發完直接在手機上看到「文章發佈成功」的 push，等於每篇都有系統幫我確認有沒有真的送出去。這比自己每天去三個平台一一檢查可靠太多。

這條只負責發，不會自己決定要發什麼

講到自動發文，最多人擔心的是「AI 會不會亂發東西到我客戶的帳號上」。在我的設計裡這件事是切開的：要發什麼、發之前給不給過，都是人決定的（內容怎麼產、怎麼送審，前面那篇連結講得比較細），這條工作流只負責把「已經核准的那一篇」準確地送上三個平台。自動化省的是重複的體力活，不是把「要不要對外發聲」這種判斷交給機器。

📖 延伸閱讀：n8n + Apify 社群監控工具教學：一次追蹤 5 個平台的競品動態

我卡最久的一次：IG 怎麼發都失敗

整個流程裡，我卡最久的就是 Instagram。因為 FB 先做、又一次就成功，那種「原來這麼簡單」的順感，反而害我以為 IG、Threads 照抄就好。結果 IG 怎麼發都失敗，回傳的訊息也看不太懂哪裡錯。

我一開始以為是憑證的問題，換了憑證還是不行；後來才注意到一件事——IG 根本不吃「直接發文」這種做法。我把錯誤訊息丟給 Claude Code 一起看，才確認 IG 的流程是要先建立媒體容器、拿到容器編號、再用那個編號去發布，跟 FB 完全是兩種邏輯。

以為解決了，結果又卡第二次：容器建好馬上發，還是失敗。這次我猜是時間問題——平台處理圖片需要一點時間，我發得太快，它還沒準備好。加了一個等 10 秒的步驟之後，就穩定了。回頭看，那兩天卡關不是因為多難，而是我用 FB 的直覺去套 IG。這也讓我後來看任何 API 都會先假設「它跟別的不一樣」，先讀清楚再動手。在幫客戶實際把流程跑順之後，我更確定一件事：自動化真正花時間的不是串工具，是搞懂每個平台的脾胃。

常見問題 FAQ

Q1：我沒有工程師背景，這個做得到嗎？

做得到，但要有心理準備這是三個裡面比較進階的。真正要寫程式的部分幾乎沒有，主要是設定 n8n 節點、填對網址和欄位。比較吃力的是看懂各平台 API 的規則、和申請發文憑證。我的建議是先從只發一個平台（例如 FB）開始跑通，再慢慢加 IG、Threads，不要一開始就想三個一起上。

Q2：這樣會不會被平台判定灌水、封帳號？

用官方 API、正常頻率發自己的內容，不會。會出事的是那種一天狂發幾十篇、或用非官方手段操作的行為。這套流程是透過 Meta、Threads 的官方 API 發文，跟你手動發的性質一樣，只是改由系統代勞，發文頻率也跟人工差不多，風險很低。

Q3：Token 多久會過期？一定要做自動更新嗎？

Meta 的長期 token 大約兩個月到期。如果你只是自己一個帳號，老實說手動每兩個月換一次也還好。但只要你管的帳號一多，手動換很容易忘、忘了就默默發不出去，這時候做一條自動更新的工作流就很值得。要不要做，看你的帳號數量決定。

Q4：可以再加更多平台嗎，例如 LinkedIn、X？

可以，這正是自己串 API 的好處。只要那個平台有開放發文 API，就多接一條線進來，整體架構不用改。差別只在於每個平台 API 的規則要重新讀一次——像前面講的，有的一步、有的要兩三步，不能假設它跟現有的一樣。

Q5：跟直接用 Buffer 比，到底省不省？

看規模。如果你只發一兩個平台、一個帳號，老實說用現成工具就好，不用走這條。自己串的划算之處，是在帳號多、要客製各平台內容、或想長期掌握主動權的時候——前期多花的設定時間，會在規模變大之後一次賺回來。

總結

多平台發文自動化的重點不是炫技，是把「同一篇複製貼上三遍」的體力活交給系統，把人留給真正要判斷的內容。我捨棄 Buffer、自己用 n8n 串 API，換到成本不隨帳號數暴增、能各平台客製、平台改版自己說了算；代價是得搞懂每個平台的脾胃和 token 過期這些雜事。整套工作流我直接免費送你——清乾淨、可直接 import 的 n8n 範本，到官網免費資源區領取，填上自己的 token 就能跑。