N8N × THREADS API × GOOGLE SHEETS

你睡覺，
它發文。

一條 19 個節點的 n8n 生產線：每 4 小時醒來一次，從 Google Sheet 挑出最舊的一篇稿， 先抽一個隨機延遲假裝自己是人，再把主文發上 Threads，回頭把最多 5 則留言一則一則補完。 全程零人工，凌晨三點也照跑。

STATUS: RUNNING 19 NODES EVERY 4 HOURS RANDOM DELAY 1–100 MIN
PIPELINE OVERVIEWCRON → PICK ROW → WAIT → PUBLISH → REPLIES
SCROLL ↓
SEC.01 / OVERVIEW

為什麼要蓋這條線

手動發文有三個死穴：發文時間被生活綁死、忙起來就斷更、留言區永遠來不及補。這條線把「發」這個動作整個外包給機器，人只負責把稿寫好丟進表格。

19
個節點，串成一條發文流水線
6班
每 4 小時發車一次，凌晨也照開
1–100分
每班隨機延遲，模仿真人節奏
5
則留言自動串在主文底下

它管什麼

從 Google Sheet 排隊區挑稿、控制發文時間、呼叫 Threads API 發主文、把貼文 ID 回填表格、再逐則補上留言。發布這段路，全部它扛。

失敗也不漏稿：只要 ThreadId 沒被填上，下一班發車會重新挑中同一篇，等於自帶重試機制。

它管不到什麼

稿子的品質。表格裡的內容還是得靠人（或另一條 Claude 寫稿線）先寫好、審過，它只是準時把稿送出門的物流系統。

內容爛，發得再準時也沒用。這點後面講防鎖的時候會再回來打你一次。

SEC.02 / PANORAMA

兩條線的接力賽

上游是內容供給線（人跟 AI 一起寫稿），下游是這條 n8n 發布線。交棒點只有一個：Google Sheet。上游只管往表格塞稿，下游只管從表格拿稿，兩邊互不干涉。

上游：內容供給線（獨立系統，人工＋Claude Code）
Obsidian 素材庫
人設檔＋研究筆記
Claude Code 寫稿
依帳號人設產出主文＋留言
Webhook 上傳
JSON 打進 Apps Script
Google Sheet 排隊
一列一篇，等發車
▼ 交棒點：SHEET 裡 ThreadId 空白的列 ▼
下游：n8n 發布線（本頁主角，19 節點全自動）
排程＋選稿
節點 1–6
隨機等待
節點 7–8
主文發布
節點 9–12
留言鏈
節點 13–19
N8N EXECUTION LOG / 模擬跑帳
SEC.03 / 19 NODES

逐節點拆解

每一個節點都有存在的理由，湊數的一個都沒有。四個階段，照執行順序走一遍。

19 個節點的發布流程：選稿、隨機延遲、發主文、串留言
整條線的四個階段：從 Google Sheet 選稿、抽一個隨機延遲等待、發出主文，最後把留言一則一則串上去。
PHASE A

排程與選稿

節點 01–06
NO.01Schedule Trigger
整條流程的鬧鐘，每 4 小時響一次，響了才有後面的事。
NO.02Get row(s) in sheet
把整張 Google Sheet 的所有列一次讀進來，先看清楚倉庫裡有什麼貨。
NO.03Filter
只留下 ThreadId 欄空白的列。空白代表還沒發過，發過的在這裡直接出局。
ThreadId 就是這條線的記帳本。用「有沒有回填 ID」判斷發過沒，比另外維護狀態欄乾淨得多。
NO.04Sort
依 row_number 由小到大排，確保從最舊的稿開始發，順序不亂跳。
NO.05Limit
只取第一筆。一班車只載一篇稿。
一次把庫存全發出去是最像機器人的行為，也最容易觸發風控。寧可慢，不要死。
NO.06Set 內容/留言/rowNumber
把 main 主文和 p1 到 p5 留言整理成乾淨欄位，打包好交給後面的發文節點。
PHASE B

防鎖等待

節點 07–08
NO.07Code in JavaScript
抽一個 1 到 100 的隨機分鐘數，這班車的發車時間由骰子決定。
NO.08Wait1
照抽到的分鐘數乖乖等，時間到才放行。
Meta 盯的是「發文時間太規律」這種機器人特徵。加亂數是在模仿人類不完美的節奏，成本幾乎是零，卻是降低被判定自動化最有效的一招。
PHASE C

主文發布

節點 09–12
NO.09Threads - Create Post Container
Threads API 發文的第一步：POST /me/threads 建立草稿容器，拿到容器 ID，但貼文這時還沒公開。
NO.10Wait
固定等 1 分鐘。
Meta 收到草稿後需要時間在後台處理。太快按發布，容器還沒準備好就會失敗。官方建議約 30 秒，等滿 1 分鐘更保險。
NO.11Threads - Publish Post
第二步：帶著 creation_id 正式發布，貼文上線，回傳正式的貼文 ID。
NO.12Update Sheet - 已發布
把貼文 ID 寫回表格的 ThreadId 欄。
這一步是 Filter 判斷「發過沒」的依據。少了回填，同一篇稿會被重複發布到天荒地老。
PHASE D

留言鏈

節點 13–19
NO.13Edit Fields1
把 p1 到 p5 收成一份留言清單，空白欄自動濾掉，不會發出空留言。
NO.14Split Out1
把清單攤平成一則一列，方便逐則處理。
NO.15Loop Over Items1
迴圈開始，一次只處理一則留言。
NO.16Threads - Create Reply Container1
建立留言草稿，多帶一個 reply_to_id，指定要掛在哪篇主文底下。
NO.17Code in JavaScript1
再抽一次骰子，這次是 1 到 2 分鐘的隨機數。
NO.18Wait2
照抽到的數字等滿，才把這一則送出去。
一秒內連噴五則留言是明顯的機器人動作。隔開 1 到 2 分鐘，才像一個人想到什麼慢慢補充。
NO.19Threads - Publish Reply
留言正式發出，然後回到迴圈開頭處理下一則，直到最多 5 則跑完，這班車收工。
SEC.04 / ANTI-DETECTION

防鎖設計哲學

整條線最值錢的部分其實只有一個概念：讓機器學會人類的不準時。

防鎖三招：隨機延遲、自動重試、帳號分流
防鎖只做三件事：發文時間隨機延遲、失敗自動重試不用人盯、一個帳號配一張表各走各的。

只改變「何時發」，
從頭到尾不碰「發什麼」。
這是成本最低、效果最好的偽裝。

整條工作流的核心取捨
  • R1
    主文延遲 1 到 100 分鐘隨機。固定整點發文等於在額頭上貼「我是排程」，亂數把這個特徵抹掉。
  • R2
    一班只發一篇。Limit 節點鎖死單次發文量，庫存再多也不貪快。
  • R3
    留言間隔 1 到 2 分鐘。像真人一邊想一邊補充，五則秒發的機器味就沒了。
  • R4
    失敗自動重試，不用人盯。發失敗就不會回填 ThreadId，下一班自然重新挑中它。
  • R5
    頻率背不了內容的鍋。延遲都加好了還是被限流？實際跑下來的結論很直接：那通常出在內容本身，重複模板、太像 AI。頻率的鍋反而排最後。
RANDOM DELAY GENERATOR
37
MINUTES / 示範抽一次的結果
1 MIN100 MIN
節點 07 每一班都會重抽，沒有兩班車的發車時間長得一樣。
一天的班表長這樣 6 DEPARTURES / DAY · 班點示意，實際發文時間＝班點＋隨機延遲
00:00
04:00
08:00
12:00
16:00
20:00
24:00
SEC.05 / DATA LAYER

一張表就是整個資料庫

沒有後端、沒有資料庫伺服器。一張 Google Sheet 同時當排隊區、記帳本、重試清單，欄位規格如下。

欄位放什麼誰在用它
main主文全文，500 字元以內節點 09 拿去建容器
p1 – p5最多 5 則留言，用不到的留空，空欄自動跳過節點 13 收成留言清單
ThreadId發布成功後回填的貼文 ID 狀態機空白＝待發｜有值＝已發，Filter 全靠它
row_number列序節點 04 排序用，確保先進先出
⚠
一帳號一張表，鐵則。兩個帳號共用同一張 Sheet 會互搶稿、發亂帳。要多開帳號就整條工作流複製一份，換 Token、換表，互不打架。
SEC.06 / OFFICIAL LIMITS

官方天花板，先認識再開車

這些數字來自 Threads API 的官方限制與建議。這條線每天最多發 6 篇、30 則留言，離天花板遠得很，但你得知道天花板在哪。還沒拿到 Token 的，先照Threads API 申請教學把兩把鑰匙申請好。

POST LENGTH
500字元 / 篇
主文超過就直接報錯 text too long，寫稿端先控字數。
POSTS / 24H
250篇上限
本線日發 6 篇，用量約 2.4%，非常安全。
REPLIES / 24H
1,000則上限
本線日發最多 30 則留言，用量 3%。
TOKEN LIFETIME
60天
長效 Token 效期 60 天，到期不報錯只會安靜罷工，要設提醒。
CONTAINER WAIT
30秒（官方建議）
草稿到發布的處理時間。本線等滿 1 分鐘，加倍保險。
IMAGE SIZE
8MB / 張
升級成圖片貼文時才用得到的限制，先記著。
THREADS API 免費 GOOGLE SHEETS 免費 N8N 雲端付費或自架免費
SEC.07 / SETUP

開車前的五個前置動作

只有第一次要做，做完之後這條線就自己活著。

建 Meta 開發者 App

登入 developers.facebook.com，My Apps 裡 Create App 開一個新的。

掛上 Threads API 權限

App 用途加入 Threads API，勾兩個 scope：threads_basic 讀基本資料、threads_content_publish 發文。

換長效 Token

先授權拿 1 小時短效 Token，再拿它換成 60 天長效 Token。日曆同步設個第 50 天的續約提醒。

n8n 掛憑證

Credentials 新增 Header Auth：Name 填 Authorization、Value 填 Bearer + Token，存成一份憑證給所有 Threads 節點共用。

接上 Google Sheets

再加一份 Google Sheets OAuth2 憑證，登入授權，讓 n8n 有權限翻你的表格。

SEC.08 / DEBUG

踩坑急救站

跑了幾個月下來，會遇到的錯就這幾種。照抄處理方式就好，別重新恐慌一遍。

401 Invalid OAuth access token
Token 過期或貼錯。回 Meta 開發者後台重新產生，換掉 n8n 憑證裡的舊值。
text too long
主文超過 500 字元上限。回寫稿端縮字數，這不是 n8n 的錯。
rate limit exceeded
當天發太多被限流。本線用量離上限很遠，這個錯通常出現在自己調高頻率之後，等 24 小時自動解。
403（Google Sheets 節點）
表格權限不足。重新登入 Google 憑證，確認授權的是對的帳號。
Media not ready / 發布失敗
草稿還沒處理完就急著發布。把節點 10 的 Wait 從 1 分鐘拉長到 2 分鐘。
最陰的一種：什麼錯都不報
Token 到期不會跳錯誤，只會安靜地發不出去。第 50 天的續約提醒就是為了防這招。
SEC.09 / ROADMAP

之後還能長出什麼

現在這條線是純文字版。骨架不動，往上疊功能的路線已經畫好。

小改

圖片貼文

media_type 改成 IMAGE、多帶一個 image_url 就行，單張最大 8MB。

小改

發完通知你

流程尾端接 LINE、Email 或 Discord 節點，每班發完回報一聲，躺著也知道車開走了。

中等

多帳號分身

整條工作流複製一份，換 Token、換 Sheet。一帳號一條線一張表，互不打架。

進階

AI 直接進駐寫稿

前面多接一個 AI 節點，定期把草稿寫進 Sheet 新列，變成「AI 寫、你審、助理發」的完整體。目前寫稿還在線外由 Claude Code 供稿，這一步是下個版本的事。

升級鐵則：一次只加一個功能，加完先試跑，穩了再加下一個。一口氣全加，壞掉時你不會知道兇手是誰。
SEC.10 / TRACK RECORD

這條線背後的帳號成績

先講清楚：數字是內容力＋自動化一起跑出來的，機器只保證不斷更，讓內容有穩定的出場機會。

24萬+
全網累積粉絲
2800萬+
單月最高總曝光
15萬+
主帳號 @techtip_s 粉絲
170萬
新帳號 2 週流量（驗證可複製）

新測試帳號從零開始，不到兩週做到 500 粉、170 萬流量，首篇 8000 讚起跳。開新帳號驗證的用意只有一個：確認這套方法換一個帳號還是成立，排除主帳號只是運氣好。

n8n Threads 自動發文生產線：19 個節點、每 4 小時自動排程

流程跑順之後，
剩下的問題只有一個：稿子夠不夠好？

這條 19 節點工作流的手把手教學（含可直接匯入的 workflow 檔與 Sheet 模板）已整理成 8 堂線上課，第 1 課免費試讀。機器的事讓機器做，人回去做只有人能做的事。

免費試讀 8 堂完整教學