多平臺(tái)內(nèi)容分發(fā)最怕兩件事：一是每個(gè)平臺(tái)都要重復(fù)復(fù)制粘貼，二是腳本明明顯示成功，結(jié)果實(shí)際只保存了草稿。真正能長(zhǎng)期使用的自動(dòng)發(fā)布流程，不應(yīng)該只是“讓程序點(diǎn)按鈕”，而應(yīng)該是一套可以判斷狀態(tài)、處理異常、記錄結(jié)果的發(fā)布系統(tǒng)。

這篇文章記錄一套更穩(wěn)的做法：用統(tǒng)一瀏覽器登錄態(tài)串起多個(gè)平臺(tái)，平臺(tái)腳本負(fù)責(zé)填表和發(fā)布，總控程序負(fù)責(zé)按順序調(diào)度。能自動(dòng)發(fā)布的平臺(tái)就直接跑完；遇到掃碼、滑塊、風(fēng)控驗(yàn)證時(shí)，不硬繞、不亂點(diǎn)，而是暫停等待人工處理，處理完繼續(xù)下一個(gè)步驟。

1. 為什么不能只做“自動(dòng)點(diǎn)擊”

很多發(fā)布腳本剛開(kāi)始看起來(lái)很簡(jiǎn)單：打開(kāi)編輯器，填標(biāo)題，填正文，點(diǎn)發(fā)布?？烧嬲芷饋?lái)會(huì)發(fā)現(xiàn)，麻煩都藏在最后幾步。

常見(jiàn)問(wèn)題包括：

? 頁(yè)面自動(dòng)保存了上一次測(cè)試留下的臟草稿

? 同名草稿導(dǎo)致平臺(tái)拒絕提交

? 富文本編輯器沒(méi)有正確渲染 Markdown

? 發(fā)布按鈕點(diǎn)了，但頁(yè)面仍停在草稿頁(yè)

? 彈窗里有多個(gè)同名按鈕，腳本點(diǎn)到了隱藏按鈕

? 公眾號(hào)、百家號(hào)、微博可能突然出現(xiàn)掃碼或滑塊

? 平臺(tái)進(jìn)入審核中，但腳本誤判成失敗

所以自動(dòng)發(fā)布不能只看“按鈕有沒(méi)有被點(diǎn)到”。更可靠的判斷是：發(fā)布后有沒(méi)有出現(xiàn)成功頁(yè)、公開(kāi)鏈接、審核中提示、平臺(tái)限制提示，或者明確的錯(cuò)誤信息。

2. 總控程序只負(fù)責(zé)順序，不搶平臺(tái)腳本的工作

比較穩(wěn)的架構(gòu)是分兩層。

第一層是平臺(tái)腳本。每個(gè)平臺(tái)腳本只關(guān)心自己的頁(yè)面：怎么打開(kāi)編輯器，怎么清空舊內(nèi)容，怎么寫(xiě)標(biāo)題、正文、摘要、分類(lèi)、標(biāo)簽和封面，最后怎么確認(rèn)發(fā)布。

第二層是總控程序?？偪爻绦虿焕斫饷總€(gè)平臺(tái)的頁(yè)面細(xì)節(jié)，它只做幾件事：

檢查統(tǒng)一瀏覽器是否可用。

按平臺(tái)順序啟動(dòng)腳本。

實(shí)時(shí)顯示每個(gè)平臺(tái)的日志。

識(shí)別驗(yàn)證碼、掃碼、人工確認(rèn)等結(jié)構(gòu)化事件。

一個(gè)平臺(tái)結(jié)束后記錄結(jié)果，再進(jìn)入下一個(gè)平臺(tái)。

全部完成后生成匯總報(bào)告。

這樣做的好處是邊界清楚。某個(gè)平臺(tái)頁(yè)面改版時(shí)，只修那個(gè)平臺(tái)腳本；調(diào)度、日志、超時(shí)和匯總?cè)匀环€(wěn)定。

3. 統(tǒng)一瀏覽器登錄態(tài)很關(guān)鍵

國(guó)內(nèi)內(nèi)容平臺(tái)大多依賴(lài)復(fù)雜登錄態(tài)。如果每次腳本都新開(kāi)瀏覽器、重新登錄，流程會(huì)非常不穩(wěn)定。

更好的方式是讓所有平臺(tái)共用一個(gè)發(fā)布瀏覽器：

? 固定 Chrome 調(diào)試端口

? 固定瀏覽器用戶(hù)目錄

? 人工提前登錄各個(gè)平臺(tái)

? 后續(xù)腳本復(fù)用這個(gè)登錄態(tài)

這樣電腦重啟后，只要重新拉起同一個(gè)瀏覽器 profile，登錄狀態(tài)仍然有機(jī)會(huì)保留。即使個(gè)別平臺(tái)要求重新掃碼，也只需要處理一次，不影響其他平臺(tái)繼續(xù)跑。

4. 驗(yàn)證碼不要硬繞，要做人工接管

掃碼、滑塊、拼圖驗(yàn)證碼屬于平臺(tái)安全驗(yàn)證。它們和賬號(hào)狀態(tài)、發(fā)布頻率、網(wǎng)絡(luò)環(huán)境、瀏覽器指紋、內(nèi)容風(fēng)險(xiǎn)都有關(guān)。今天不出現(xiàn)，不代表明天不出現(xiàn)。

穩(wěn)定策略不是強(qiáng)行破解，而是把驗(yàn)證碼當(dāng)成流程狀態(tài)：

腳本檢測(cè)到驗(yàn)證頁(yè)面或驗(yàn)證彈窗。

輸出結(jié)構(gòu)化事件，告訴總控程序當(dāng)前平臺(tái)需要人工處理。

總控程序在命令行持續(xù)提示。

人在當(dāng)前瀏覽器里完成掃碼或滑塊。

平臺(tái)腳本檢測(cè)到頁(yè)面恢復(fù)后繼續(xù)發(fā)布。

超過(guò)等待時(shí)間仍未處理，就標(biāo)記為跳過(guò)或失敗，并繼續(xù)下一個(gè)平臺(tái)。

這套方式更適合長(zhǎng)期運(yùn)行。它不會(huì)因?yàn)橐粋€(gè)驗(yàn)證碼卡死整批任務(wù)，也不會(huì)因?yàn)閬y點(diǎn)觸發(fā)更多風(fēng)控。

5. 格式適配不能一稿通吃

多平臺(tái)發(fā)布還有一個(gè)容易被低估的問(wèn)題：正文格式。

有的平臺(tái)適合 Markdown，有的平臺(tái)必須把 Markdown 轉(zhuǎn)成 HTML 后粘貼，有的平臺(tái)是 ProseMirror、Draft.js、Slate、Quill 或 iframe 編輯器?？雌饋?lái)都是“正文框”，實(shí)際內(nèi)部機(jī)制完全不同。

例如：

? 技術(shù)社區(qū)可以保留 Markdown 結(jié)構(gòu)

? 富文本平臺(tái)通常需要 Markdown 轉(zhuǎn) HTML

? 公眾號(hào)更重視排版、封面、原創(chuàng)聲明和來(lái)源聲明

? 微博頭條文章要注意導(dǎo)語(yǔ)和可見(jiàn)范圍

? 抖音圖文不能直接塞長(zhǎng)文，應(yīng)該拆成卡片腳本

所以一輪發(fā)布最好準(zhǔn)備兩類(lèi)文章：通用長(zhǎng)文稿和抖音圖文專(zhuān)用稿。長(zhǎng)文稿給公眾號(hào)、博客、技術(shù)社區(qū)；抖音稿拆成 9 張豎版卡片和一段簡(jiǎn)短 caption。

6. 每輪發(fā)布都要換新稿

自動(dòng)化流程最容易犯的低級(jí)錯(cuò)誤，是今天又把昨天的稿子發(fā)了一遍。

解決方法很簡(jiǎn)單：待發(fā)目錄里的文件名要帶主題和日期。昨天發(fā)布過(guò)的文章不要繼續(xù)當(dāng)默認(rèn)稿。每次正式跑之前，都先確認(rèn)：

? 通用文章是不是新文件

? 抖音文章是不是新文件

? 抖音卡片目錄是否和文章同名

? 標(biāo)題是否和昨天不同

? 文件名是否能在日志里清楚區(qū)分

這一步看似瑣碎，但能避免很多平臺(tái)的重復(fù)標(biāo)題錯(cuò)誤，也能讓后續(xù)排查更輕松。

7. 匯總報(bào)告比口頭成功更重要

一次批量發(fā)布結(jié)束后，最重要的不是看程序最后有沒(méi)有退出，而是看結(jié)果表。

比較有用的狀態(tài)包括：

? 已發(fā)布

? 審核中

? 草稿已保存

? 平臺(tái)限制

? 重復(fù)標(biāo)題

? 驗(yàn)證超時(shí)

? 腳本失敗

每個(gè)平臺(tái)還應(yīng)該保存獨(dú)立日志。這樣出了問(wèn)題可以直接回看：腳本停在哪個(gè) URL，頁(yè)面提示了什么，最后一次點(diǎn)擊后出現(xiàn)了什么狀態(tài)。沒(méi)有這些記錄，就只能靠記憶復(fù)盤(pán)，很容易重復(fù)踩坑。

8. 一句話(huà)總結(jié)

內(nèi)容分發(fā)自動(dòng)化的核心，不是把所有平臺(tái)都偽裝成一個(gè)按鈕，而是把每個(gè)平臺(tái)的不確定性收進(jìn)狀態(tài)機(jī)。

能自動(dòng)的部分就自動(dòng)跑完；必須人工處理的驗(yàn)證就及時(shí)交給人；失敗、審核、限制和重復(fù)標(biāo)題都清楚記錄。這樣一套流程跑下來(lái)，才真正接近“盡量不用人干預(yù)”的批量發(fā)布。

---