我用 Codex，把公眾號運營變成了一套自動化流水線

昨天我幹了一件挺笨的事。

我坐在電腦前，盯着公眾號後台、Obsidian、服務器、API 白名單、封面圖、草稿箱，來回切了不知道多少次。

一開始我以為，我要解決的是一個很小的問題：

能不能讓 Codex 幫我把一篇 Obsidian 裏的文章，排版好，發到公眾號草稿箱？

後來我發現，不是。

這件事真正要解決的，是一個更大的問題：

一個普通創作者，能不能把公眾號運營裏那些重複、瑣碎、容易出錯的環節，交給 AI 自動跑？

不是讓 AI 替你思考。

不是讓 AI 隨便生成一篇看起來很像文章的東西。

而是把你已經會做、但每次都要消耗注意力的工作，拆成一條穩定流水線。

比如：

選題在哪裏。

文章在哪裏。

哪篇是長文，哪篇是短視頻腳本。

封面怎麼做。

排版怎麼統一。

標題要不要出現在正文裏。

底部二維碼佔位要不要刪。

公眾號後台怎麼發。

草稿箱怎麼驗證。

IP 白名單怎麼解決。

這些東西看起來都不難。

但你真的每天做，就會知道，它們很煩。

煩到最後，真正阻礙你持續更新的，往往不是不會寫，而是發一篇文章的摩擦太大。

今天這篇，我就手把手講一下，我是怎麼用 Codex，把這套流程跑通的。

寫給小白。

也寫給所有想做“一人 AI 公司”的人。

很多人一聽“自動化發公眾號”，第一反應就是：

是不是寫個腳本，自動登錄公眾號後台，然後模擬鼠標點擊？

我一開始也是這麼想的。

畢竟 Codex 有 Chrome 插件，可以操作瀏覽器。打開網頁、點按鈕、輸入文字、截圖檢查，這些它都能做。

但是到了微信公眾號後台，你會遇到一個現實問題：

登錄態、風控、富文本編輯器、圖片上傳、草稿保存，這些環節都很容易被平台安全策略卡住。

你可以讓 AI 像人一樣點。

但只要中間彈一個驗證、頁面結構變一下、編輯器吞掉一段 HTML，這條鏈路就會斷。

所以我後來換了思路。

能走官方 API 的地方，就不要靠模擬點擊。

這句話很關鍵。

公眾號草稿箱本身有服務端接口。它不是給你點網頁用的，而是給程序調用的。

也就是說，我們真正要做的，不是讓 Codex “假裝成我”去後台點來點去。

而是讓 Codex 幫我搭一套更穩定的發佈系統：

注意，我說的是草稿箱。

不是直接羣發。

因為真正成熟的自動化，不是把風險也自動化。

它應該把苦活幹掉，把最終判斷權留給人。

如果你是小白，不要被“API”“服務器”“SSH”這些詞嚇住。

你可以把它們理解成四把鑰匙。

第一把鑰匙，是你的文章倉庫。

我用的是 Obsidian。

我的文章都在本地知識庫裏，其中有一個目錄叫“待發布文章”。

這個目錄下面，又分成不同類型。

比如“公眾號長文”就是要發公眾號的文章。

短視頻腳本就放在另一類。

這一步看起來普通，但非常重要。

因為自動化最怕的不是代碼寫錯，而是輸入混亂。

你要先告訴 AI：

這裏是待發布區。

這裏是長文。

這裏是短視頻腳本。

不要亂選。

第二把鑰匙，是公眾號的 AppID 和 AppSecret。

你可以在公眾號後台的“開發設置”裏看到。

AppID 相當於公眾號的身份證。

AppSecret 相當於公眾號的密碼。

這裏一定要提醒一句：

AppSecret 不要寫進文章，不要發到羣裏，也不要放進公開倉庫。

哪怕你只是測試，也不要。

我這次是臨時在本地環境裏使用，自動化腳本運行完就結束。

第三把鑰匙，是一個固定 IP。

這一步是很多人第一次接公眾號 API 時最容易崩潰的地方。

微信公眾號要求你把調用接口的服務器 IP 加進白名單。

如果你直接在本機跑，問題就來了：

你家的寬帶 IP 可能會變。

你的雲開發環境出口 IP 也可能會變。

今天能發，明天就報錯。

所以我最後的方案是：

找一台固定公網 IP 的雲服務器，讓所有公眾號接口都從這台機器出去。

這樣公眾號後台的 IP 白名單裏，只需要保留這一個 IP。

以後本地 Codex 只負責準備文章和封面，真正調用公眾號接口的動作，交給服務器完成。

第四把鑰匙，是一把 SSH 密鑰。

你可以把它理解成“讓 Codex 安全登錄服務器的門禁卡”。

這一步做完之後，Codex 就可以把文章包、封面圖、發佈腳本上傳到服務器，然後在服務器上執行發佈。

到這裏，你會發現，這套東西沒有你想象中那麼玄。

它不是黑魔法。

它就是把原來你手動做的事情，拆成幾個穩定步驟。

我給 Codex 的第一句話很簡單：

“去待發布文章裏，選一篇公眾號長文，排版好，發到公眾號草稿箱。”

但這句話背後，其實有一個前提：

Codex 必須知道我的 Obsidian 在哪裏。

小白最容易卡在這裏。

你會以為“我已經給你本地權限了，你怎麼還不知道？”

其實不是 Codex 笨。

是你的電腦裏可能有很多目錄。

Documents、iCloud、Downloads、桌面、各種同步盤。

AI 有權限，不等於它天然知道你的內容管理習慣。

所以正確做法是：

第一次，你要告訴它文章倉庫大概在哪裏。

比如：

我的 Obsidian 在 iCloud 的“六偉知識庫”裏。

待發布文章在“IP知識庫/07-待發布文章”裏。

公眾號長文在“公眾號長文”文件夾裏。

告訴一次以後，Codex 就可以把這個路徑記進當前自動化流程。

下次你再說“從待發布文章裏選一篇”，它就知道往哪兒找。

更重要的是，你要讓 Codex 識別文章類型。

我的經驗是，不要只靠文件名。

文件夾結構更穩定。

比如：

每一類內容都有自己的出口。

公眾號長文走草稿箱。

短視頻腳本走視頻號/抖音腳本整理。

小綠書走卡片化排版。

這才是自動化運營的起點。

不是“AI 幫我發一篇文章”。

而是“AI 知道我的內容資產怎麼流轉”。

公眾號排版這件事，非常適合交給 AI。

因為它有明確規則。

標題怎麼處理。

段落怎麼拆。

金句怎麼突出。

章節怎麼分。

哪些內容要刪。

哪些內容不能進正文。

這些都可以寫成一個 Skill。

Skill 是什麼？

你可以把它理解成一份“給 AI 的崗位說明書”。

不是每次都重新提醒：

“幫我排版得好看一點。”

“段落短一點。”

“不要把標題重複放進正文。”

“底部二維碼佔位刪掉。”

你把這些要求寫成 Skill，AI 每次執行排版任務時，就按這套規則來。

這一步我踩過一個小坑。

第一次發到草稿箱後，我去看真實效果，發現正文裏還有一遍標題。

公眾號後台本來就有標題欄，正文再出現一次標題，就很怪。

於是我把排版規則改掉：

一級標題只用於草稿標題，不進入正文。

還有文章頂部的“一人AI公司”，底部的作者簽名、轉發引導、二維碼/課程入口占位，也全部清理掉。

這些東西在 Obsidian 裏可能是寫作模板的一部分。

但到了公眾號草稿箱，就未必應該出現。

自動化不是把原文原封不動搬過去，而是把原文轉換成適合發佈場景的版本。

下面這份，是我整理出來的公眾號排版 Skill 開源版。

你可以直接複製給自己的 Codex 或智能體使用。

公眾號自動排版 Skill 開源版

你是一個公眾號排版助手。用戶給你一篇 Markdown 文章後，你要把它轉換成可以直接複製到微信公眾號後台的 HTML。

目標：輸出一份乾淨、穩定、適合手機閲讀的公眾號正文。

不要炫技。不要把頁面做成網頁。公眾號文章最重要的是閲讀節奏。

輸入可能包含 YAML frontmatter、一級標題、二級標題、三級標題、普通段落、加粗金句、引用、列表、分割線。

輸出規則：

樣式約束：

清理規則：

輸出格式：

只輸出完整 HTML 正文，不解釋。

如果用戶要求同時生成封面，可以另外生成 900×383 的封面圖，但正文 HTML 裏不要內嵌封面。

這就是一個很簡單的 Skill。

但它的價值很大。

因為它把“審美”變成了“規則”。

規則一旦穩定，AI 就可以批量執行。

封面圖是公眾號運營裏非常容易消耗時間的環節。

你可能會打開 Canva。

選模板。

改字。

換圖。

導出。

再上傳。

一篇文章還好。

每天都做，就很煩。

這次我做了一個取巧但很實用的方案：

讓 Codex 調用內置生圖能力，直接生成公眾號封面。

這裏有個小重點。

如果你用 OpenAI API 自己生圖，那就會走你的 API 賬單。

但在 Codex 裏，有些生圖能力可以走當前產品額度。

這對一人公司很重要。

不是因為摳。

而是因為你必須知道每一步成本從哪裏來。

真正的自動化，不只是把活幹完，還要把賬算清楚。

我的做法是：

文章定稿後，Codex 根據標題和主題生成一張 900×383 的公眾號封面。

然後再裁一張符合公眾號接口要求的縮略圖。

最後把這張圖上傳給公眾號接口，拿到 thumb_media_id。

草稿箱文章必須帶這個 thumb_media_id。

否則接口不會讓你創建草稿。

這也是為什麼我說，發公眾號不是簡單複製正文。

它是一個小系統。

標題、正文、封面、摘要、縮略圖、接口憑證，每個零件都要對上。

這個坑值得單獨講。

公眾號接口有 IP 白名單。

只允許白名單裏的 IP 調用。

如果你在本機跑，今天的出口 IP 是 A，明天變成 B，接口就會拒絕。

你看到的錯誤可能很嚇人，但它本質上就是一句話：

這個 IP 不在白名單裏。

怎麼辦？

最穩的方案，是準備一台固定公網 IP 的服務器。

本地 Codex 做三件事：

服務器做一件事：

調用公眾號 API，把文章加到草稿箱。

這樣一來，公眾號後台的白名單隻需要配置服務器 IP。

以後不管我在哪台電腦上用 Codex，只要最終請求從這台服務器出去，就不會因為 IP 變化失敗。

這就是自動化裏的一個樸素原則：

容易變的東西放前面。

必須穩定的東西放後面。

文章會變。

封面會變。

排版會迭代。

但發佈出口最好不要變。

當這些準備好以後，一鍵發佈其實很簡單。

我只需要告訴 Codex：

把這篇文章排版好，用這張封面，走固定 IP 發到公眾號草稿箱。

它背後做的動作是：

小白如果要自己復刻，可以把流程理解成一句話：

本地負責生產內容包，服務器負責把內容包交給微信。

這裏的內容包包括：

服務器拿到內容包以後，用 AppID 和 AppSecret 獲取接口調用憑據，再上傳封面，再創建草稿。

你不需要一開始就懂所有細節。

你只要記住順序：

先文章。

再排版。

再封面。

再上傳。

再草稿箱檢查。

這就是完整閉環。

如果只是自動發一篇文章，那其實沒多大意思。

真正有意思的是，它可以繼續往前、往後延伸。

往前，可以自動做選題。

比如每天抓 AI 行業熱點，找到異常高熱度事件，生成選題池。

再根據賬號定位，判斷哪些適合寫長文，哪些適合短視頻，哪些適合朋友圈。

往中間，可以自動做內容生產。

長文用長文 Skill。

短視頻用腳本 Skill。

小綠書用卡片 Skill。

朋友圈用朋友圈文案 Skill。

同一個素材，可以被拆成多種內容形態。

往後，可以自動做運營動作。

比如：

這才叫自動化公眾號運營。

不是“發出去”。

而是從選題、生產、排版、發佈、覆盤，形成一條內容供應鏈。

一人公司最缺的不是工具，而是可重複的流程。

工具今天會變。

模型明天會升級。

平台規則後天也可能調整。

但只要流程在，你就可以持續替換裏面的零件。

這才是 AI 時代的小團隊槓桿。

我把這次跑通時遇到的坑列出來。

第一，正文標題重複。

公眾號後台已經有標題欄，正文裏的一級標題要刪掉。

第二，底部模板殘留。

Obsidian 裏的作者簽名、二維碼佔位、課程入口占位，發佈前要自動清理。

第三，IP 白名單不穩定。

不要頻繁往公眾號後台加臨時 IP。用固定 IP 服務器解決。

第四，Secret 泄露。

AppSecret 只放在本地環境或服務器環境裏，不要寫進文章、截圖、公開倉庫。

第五，封面尺寸不匹配。

公眾號封面和接口縮略圖不是一回事。封面可以做得更完整，接口需要能上傳成功的圖片文件。

第六，自動化直接羣發。

不建議。

至少在早期，先發草稿箱。

草稿箱是人類最後一道質檢。

AI 負責把路鋪好，人負責踩剎車。

我現在越來越覺得，AI 時代最值得普通人學的，不是某一個工具的按鈕在哪裏。

按鈕會變。

界面會變。

模型名字也會變。

真正該學的是：

把一件複雜工作拆成可描述、可檢查、可複用的步驟。

你能把“發公眾號”拆成：

找文章。

識別類型。

清理模板。

排版正文。

生成封面。

上傳素材。

創建草稿。

人工檢查。

那 Codex 就可以幫你跑。

你能把“公眾號運營”拆成：

找選題。

寫長文。

拆短視頻。

做朋友圈。

排版發佈。

數據覆盤。

那 AI 就不只是聊天工具，而是你的運營同事。

我知道，對小白來說，第一次看到 AppID、AppSecret、服務器、SSH、白名單，肯定會有點頭大。

正常。

我自己第一次跑的時候，也不是一下就順。

但你只要跑通一次，感覺會完全不一樣。

因為從那一刻開始，你不再是在“使用一個 AI 工具”。

你是在搭自己的工作系統。

這個系統一開始可能很簡陋。

就像一個小作坊。

但它能跑。

能迭代。

能省時間。

能把你從重複勞動裏拽出來。

這就夠了。

AI 自動化的終點，不是讓人消失，而是讓人終於有時間做判斷。

這也是我這次最大的感受。

公眾號後台還是那個後台。

文章還是要自己判斷。

標題還是要自己拍板。

草稿箱還是要自己看。

但中間那些重複、細碎、機械、容易出錯的步驟，已經可以交給 Codex 了。

朋友們。

這不是未來。

這是今天早上，我剛剛跑通的東西。