提到SNS自動化，很多人只想到排程與AI寫文案。
真正困難的是：只配送已驗證的內容、防止重複、把單一帳號故障限制在局部、遇到CAPTCHA時不違規繞過、只把機器不能正當完成的步驟交給人，並用實際閱讀行為改善下一次配送。
多語言、多平台、電子報一旦串起來，這就不是排程器，而是一個小型分散式系統。
1. 目標不是「完全無人」，而是「人只處理例外」
CAPTCHA、SMS、2FA、身分驗證、明確同意、開發者app審核，是平台刻意保留的人類邊界，不是無限retry就該突破的錯誤。
正常流程應是：內容 → QA → 在地化 → 正式上線 → production readback → 配送候選 → locale文案 → 發送 → 成效回收 → 下一次判斷。
某一帳號遇到人類驗證，就只暫停那個scope。其他語言、平台、電子報、分析和內容產線照常運作。
Cloudflare Workflows支援持久多步驟執行、自動重試以及等待外部事件或人工核准。[1] 重點不是一定使用某個產品，而是把「等人」視為狀態，不是總停機。
2. 分開「文章存在」與「文章可以配送」
Git倉庫裡有Markdown，不代表讀者已能讀到正確的公開頁面。翻譯完成、build成功也不夠。
內容identity可使用 articleId × locale × contentSha；配送再加入 platform × campaignType。
contentSha能區分同一URL不同revision，避免舊文案替新內容宣傳。
最安全的入口是實際讀回production HTML，確認精確locale與精確revision已公開後，才建立社群或email工作。
3. timeout不等於失敗，否則會生出雙胞胎貼文
API送出後client timeout，可能是真失敗，也可能provider已經發布，只是回應沒回來。
此時直接重送，就可能出現兩篇一模一樣的貼文。
Cloudflare Queues預設是at-least-once delivery，官方文件也明確提醒少數情況可能重複投遞，建議用unique ID與idempotency key去重。[2]
例如使用 sha256(articleId + locale + contentSha + platform + campaignType)，並讓receipt的key具有UNIQUE限制。
模糊timeout後先查receipt，再盡可能做provider readback；只有確認結果不存在才retry。
目標不是保證程式碼只跑一次，而是跑多次時外部效果仍只剩一次。
4. 把故障限制在最小scope
failure domain至少拆到 platform × locale × account。
單一帳號認證過期，就只BLOCK該帳號；429只讓該channel進入RETRY_WAIT；人工驗證只讓該scope變成HUMAN_ACTION_REQUIRED。
狀態可以分成READY、ACTIVE、DEGRADED_BUT_RUNNING、HUMAN_ACTION_REQUIRED、BLOCKED_PROVIDER、RETRY_WAIT、DISABLED_BY_POLICY。
429遵守Retry-After，5xx使用有界限的exponential backoff，401/403只使用官方refresh流程。CAPTCHA不做無限自動重試。
呼叫一百次API也不會把API變成人類。
5. Human Handoff Queue要像操作手冊，不是「請幫忙看看」
好的handoff要包含platform、locale、account、blocker、發現時間、URL、人要做的精確動作、不要動的設定、完成後系統如何readback，以及只阻塞哪些scope。
例如：「登入此官方帳號，只完成目前顯示的CAPTCHA。不要修改個人資料或發文設定。完成後，下次自動巡檢會重新讀取認證狀態，並從canary貼文恢復。」
不使用CAPTCHA solver，也不假裝challenge。人工只接手機器本來就不該越界的部分。
password、OAuth access/refresh token、session cookie、SMS/2FA code、recovery code與private API secret都不寫入GitHub或一般log。只留下public handle、state、sanitized error、receipt ID、public post URL等非秘密營運資訊。
6. 自動發文與engagement bot要分開
自動發布自家文章，和自動按讚、追蹤、回覆、DM是不同能力，也受不同規則限制。
X在2026年4月更新的Automation Rules允許合規的資訊型自動貼文，但禁止規避rate limit、以非API腳本操控X網站、垃圾或重複行為，且禁止自動按讚。[3]
因此初期只開AUTO_PUBLISH，其餘engagement功能維持關閉，是更清楚的責任邊界。
Bluesky官方API提供正常post record與langs語言metadata。[4] 多語言系統應讓貼文語言與實際locale一致。
定常配送盡量使用官方API與官方認證，不把逆向內部API當永久通道。
實用的初始channel map可以是 ja→X、en→X/Bluesky、ko→X、zh-Hans→Weibo、zh-Hant→Facebook/Threads、es・pt-BR・id・th・vi・fr→Facebook、de→Facebook/X。Instagram、TikTok、Reels等圖片/影片優先平台，等自動media card與QA穩定後再進第二階段。實作時再次確認各平台最新API與Automation Policy。
7. 12種語言不是把一篇日文SNS文案翻譯11次
既然每個locale都有自己的實際文章，社群文案也應讀那份locale正文後獨立生成。
文案可以很短：官方網站帳號對自己的文章自然說一句話，再附URL。
避免「必看」「震驚」「現在就看」等廣告味，也不要偽裝成第三方讀者的見證。
品牌身份共通，但每種語言要自然。
醫療、法律、投資、大額金錢、災害、犯罪、死亡、自傷、暴力、性暴力、未成年、安全、政治與選舉、強烈衝突進入serious mode：原則無emoji、中性、不煽動、不超出原文斷言、不增加政治endorsement。
8. 電子報是另一個adapter，不是「把SNS寄到email」
訂閱資料至少要有explicit opt-in、locale、topics、consentAt、status、unsubscribeAt、createdAt，並避免同一文章重複寄送。
客服回信信箱與大量發信基礎設施邏輯分離。Reply-To可以保留既有支援地址，發送provider則保持可替換。
Gmail的sender guidance對大量寄件者強調驗證、避免未請求郵件與方便退訂；subscription message也把unsubscribe視為重要要求。[5][6]
退訂後要立即退出未來campaign資格。
9. 最佳化「讚」最後會得到一台討讚機器
文章站更重要的指標通常是site visit、meaningful reading、next article、return visit、newsletter signup。
campaign可分NEW、UPDATED、TRENDING、POPULAR、EVERGREEN。
只改一個錯字不該觸發UPDATED。POPULAR與TRENDING應重用既有第一方閱讀資料，不要再建立第二套熱門榜。
發文時間也用真實 locale × country × platform × weekday × hour 表現逐步學習，而不是永久相信直覺。
10. 實際用法：不是「發一篇」，而是推動狀態
流程是：精確locale revision上線 → production HTML readback → 建立配送identity → 讀locale正文產生短文案 → policy與serious mode驗證 → 帶idempotency key進outbox → 官方API發送 → receipt與public readback → 歸因閱讀行為 → 下一輪campaign判斷。
每個adapter先做單一canary：auth readback、dry run、一篇真實文章、receipt、公開貼文readback、locale檢查、duplicate suppression與analytics attribution。
成功後才擴大。
管理者應從單一current-status入口理解整體狀態，不要人工挖十幾份檔案。
架構上也不要為distribution再生第二套內容工廠或第二scheduler。把它接成 PRODUCTION_VERIFIED之後的post-publication child，並在安全可行時重用既有durable runtime/state store。
好的自動化不是永不失敗。
它是失敗時知道壞在哪裡、影響很小、能合法恢復、必要時只把那一件事交給人，恢復後還能避免重複副作用繼續跑。
拿掉發布按鈕只是開場。
真正的自動化把失敗那天也設計進去。
資料來源
- Cloudflare — “Cloudflare Workflows” (updated 2026-09-18) Used for durable multi-step execution, automatic retries, persistent state, and waiting for external events or human approval. The article does not imply that a separate workflow or scheduler must be created when an existing stateful runtime already provides the needed function developers.cloudflare.com
- Cloudflare — “Delivery guarantees” (Cloudflare Queues, updated 2026-04-21) Used for the fact that Queues uses at-least-once delivery by default, rare duplicate delivery can occur, and unique IDs / idempotency keys are recommended when duplicate processing would create unintended effects developers.cloudflare.com
- X Help — “Automation rules” (updated 2026-04) Used for the distinction between compliant informational automated posts and prohibited behavior such as rate-limit circumvention, non-API website scripting, spam/duplicative use, and automated likes help.x.com
- Bluesky Protocol Services — “Creating a post” Used for official post creation, returned post identifiers, and language metadata through the langs field docs.bsky.app
- Gmail Help — “Email sender guidelines FAQ” Used for current high-volume sender requirements around authentication, unwanted mail, and easy unsubscribe support.google.com
- Gmail Help — “Learn about bulk email best practices” Used for explicit consent, clear sender identity, non-deceptive content, unsubscribe, and reasonable sending frequency support.google.com
