如果你和我一樣公眾號后臺的“定時群發(fā)”按鈕按了四年你應該早就發(fā)現(xiàn)一個事實寫字本身從來不費時間真正吃掉你精力的是寫字之外的那條流水線。我現(xiàn)在的做法是把整條流水線交給WorkBuddy再給它裝上兩個自建skill一個負責把歷史文章和碎片素材變成結構化的選題庫另一個負責把草稿變成能直接發(fā)布的公眾號排版。做完這件事之后日更對我來說不再是負擔而是每天早上二十分鐘的固定動作。這篇文章想把整個過程拆開講清楚包括兩個 skill 的功能設計、任務拆解思路、中間產物怎么組織以及我在實際運行中踩過的幾個坑。如果你也在做公眾號或者你正在用 WorkBuddy 之類的智能體工具但不知道怎么真正落地這篇文章應該能給你一套可以直接抄走的方案。1. 被公眾號日更拖垮之后我決定讓WorkBuddy接管1.1 我的時間都去哪了寫作之外的五個重復環(huán)節(jié)先說一個真實的場景。我有一次從下午兩點坐到晚上九點七個多小時里真正用于“寫”的時間不超過一個小時。剩下的時間全部耗在五個環(huán)節(jié)上找素材翻自己的收藏夾、翻歷史文章、翻各個群里轉發(fā)的鏈接就為了確認某個觀點我之前有沒有寫過。配圖找圖、裁剪、壓縮還要改文件名把圖傳到服務器上拿到鏈接之后再插進文章。排版標題層級、加粗、引用塊、代碼塊樣式每次都在編輯器里手動調一遍。檢查外鏈點開每一個鏈接確認沒有失效確認圖片沒有被防盜鏈攔截。發(fā)布前的最后核對看一遍按鈕、合集標簽、摘要、封面確認別出烏龍。這些事情單看都不難但湊在一起就是一座山。更崩潰的是這套流程每周要重復五到六次每次都要重來。說白了公眾號運營根本不缺寫作能力缺的是對重復勞動的容忍度。1.2 為什么是WorkBuddy而不是ChatGPT加一堆插件我也試過用對話式 AI 來加速這個流程比如直接在對話框里讓它“整理這篇文章”“生成排版 HTML”。結果發(fā)現(xiàn)一個問題每次都要把上下文重新描述一遍它給出的結果格式還不穩(wěn)定有時候給我 Markdown有時候給我?guī)邮降?HTML有時候干脆漏掉圖片。零零散散湊合能用但離“解放自己”還差得遠。WorkBuddy 打動我的地方是它的skill 機制。你可以把一個 skill 理解成一個高度定制化的崗位說明書加操作手冊——它定義了輸入是什么、輸出是什么、中間按什么步驟執(zhí)行、遇到什么情況怎么處理。裝好之后只要用自然語言發(fā)出觸發(fā)指令整個流程就會按預設邏輯跑而不是每次現(xiàn)場“即興發(fā)揮”。我還特意對比過 skill 和 agent 的區(qū)別。Agent 是那個做決策的主體skill 是技能包一個 agent 可以掛載多個 skillskill 也能被不同的 agent 復用。我這兩個 skill 就是獨立的技能包誰用都行掛在 WorkBuddy 上只是我個人的習慣。1.3 兩個skill的定位劃分一個管入口一個管出口動手之前我把“公眾號自由”拆成了兩個方向入口側和出口側。入口側解決的是“內容從哪來”的問題。歷史文章、碎片筆記、網(wǎng)上的好文章這些信息如果只是躺在收藏夾里等于不存在。需要有人把它們抓出來、洗干凈、貼上標簽、放進一個可以隨時檢索的素材庫。這是第一個 skill 的活。出口側解決的是“內容怎么發(fā)出去”的問題。草稿寫完之后圖片要上傳、鏈接要替換、排版要統(tǒng)一、還要過一遍平臺規(guī)則。這些工作重復且規(guī)則明確非常適合自動化。這是第二個 skill 的活。中間那塊“判斷和表達”留給人類自己。我不指望 skill 幫我思考我只指望它幫我把思考之前的準備和思考之后的交付全部包圓。2. 自建skill前必須搞懂的三個概念任務拆解、工具邊界和狀態(tài)流轉2.1 skill到底是什么一個帶輸入輸出契約的小型工作流很多人第一次接觸 skill 會把它理解成一個“超長提示詞”其實不對。提示詞是寫給 AI 看的愿望清單skill 是寫給 AI 看的崗位說明書它必須包含四個東西觸發(fā)條件、處理步驟、輸入格式、輸出格式。我自己寫 skill 的時候習慣用一套類似下面的 YAML 模板來定義name: article-collector version: 1.2.0 description: 采集指定公眾號歷史文章或單篇文章提取正文與圖片按主題歸檔為素材卡 trigger: 用戶提供公眾號名稱或文章URL inputs: - target: string outputs: - cards_dir: 素材庫目錄 steps: - 1. 解析入口獲取文章列表 - 2. 逐篇提取標題、作者、時間、正文 - 3. 過濾無關區(qū)塊推廣、頁腳、打賞引導 - 4. 下載正文圖片到本地按文章ID序號重命名 - 5. 生成素材卡Markdown寫入素材庫 constraints: - 只處理用戶有權訪問的內容 - 不繞過任何訪問限制這樣做的好處是每一步都有明確的驗收標準Agent 在執(zhí)行的時候不會自由發(fā)揮偏離軌道。2.2 任務拆解把“公眾號自由”拆成skill可執(zhí)行的最小單元接手任何一個自動化項目最忌諱上來就寫 prompt。你連自己要什么都不知道AI 再聰明也幫不了你。我的做法是先畫一條“內容處理流水線”把公眾號從選題到發(fā)布拆成六個環(huán)節(jié)環(huán)節(jié)是否適合自動化原因素材采集適合規(guī)則明確重復性高素材歸類適合標簽體系固定判斷標準清晰正文撰寫部分適合機器出初稿人工做觀點和事實核驗圖片處理適合邏輯簡單下載、重命名、上傳、替換排版適合格式規(guī)則固定可模板化發(fā)布部分適合可自動生成但推送前要人工確認拆完之后你會發(fā)現(xiàn)真正需要“人”的部分其實很少。其他環(huán)節(jié)全都符合自動化的三個特征重復、規(guī)則明確、有客觀的驗收標準。2.3 工具邊界哪些事交給skill哪些事必須人工兜底我見過不少人踩的坑是把 skill 當成萬能工具箱讓它“幫我寫一篇有深度的文章”。結果出來的東西看著通順實際上觀點空泛甚至數(shù)據(jù)都是編的。這里必須劃一條邊界。Skill 適合做的是信息處理比如抓取、歸類、格式轉換、圖片上傳、鏈接替換、生成固定結構的模板文本。Skill 不適合做的是價值判斷比如“這個觀點是否成立”“這個案例是否真實”“這句話會不會冒犯到某類讀者”。這些事一旦交給機器風險極高。我自己的原則是skill 做流水線人做質檢員。任何一篇文章在點擊發(fā)布之前必須經過五分鐘的人工審核。具體看哪些內容我在第五部分會詳細列一個清單。2.4 狀態(tài)流轉兩個skill如何共享一份工作目錄兩個 skill 不是孤立的它們的協(xié)作方式需要提前設計好否則就是兩條各干各的流水線。我用的是“中間產物”的方式Skill A 把處理好的素材寫進一個固定的工作目錄Skill B 再去這個目錄里讀取。目錄結構大概是這樣的post-packages/ ├── 2026-01-14-ai-writing-tools/ │ ├── source.json # 素材來源信息 │ ├── cards/ # 素材卡(Markdown) │ ├── images/ # 本地圖片 │ └── draft.md # 我寫的草稿狀態(tài)流轉的關鍵在于中間產物必須用穩(wěn)定、可解析的格式而不是一段對話里的零散回答。這樣哪怕執(zhí)行到一半崩潰了重新跑一次也能從斷點繼續(xù)不至于翻車。3. Skill一號歷史文章采集與素材庫自動歸類3.1 為什么先做素材采集而不是直接生成文章最初有人建議我直接做一個“自動寫文章”的 skill我猶豫了一下還是決定先做素材采集。原因是公眾號內容的核心從來不是文字堆砌而是素材密度。你寫一個觀點如果背后有一兩個鮮活案例、兩三句準確引用、一組可靠數(shù)據(jù)文章的可讀性立刻就不一樣。我的收藏夾里存了上千篇“以后可能會用”的文章但真正要用的時候根本找不到。因為它們的標題、來源、核心觀點都散落在不同地方沒有統(tǒng)一的索引。做一個采集 skill本質上是在給這些散落的信息建索引。這件事不做后面所有自動化都是空中樓閣。3.2 采集規(guī)則設計入口、正文提取、圖片落盤Skill A 的觸發(fā)方式很簡單支持兩種輸入一個公眾號的名字或者一條具體的文章鏈接。給它一個名字時它會去抓取該公眾號最近一段時間的文章列表給它一條鏈接時它會把單篇內容完整扒下來。正文提取的規(guī)則我調教了很久因為公眾號文章里總是混著一堆跟正文無關的東西比如頂部引導關注、底部廣告、往期推薦。我在 skill 的描述里明確要求過濾器只保留標題、作者、發(fā)布時間、正文段落、配圖、引用金句其余一律丟棄。圖片落盤是一個容易被忽略的關鍵點。我在 skill 里規(guī)定圖片必須以“文章ID_序號”的格式命名并且在下載完成后自動做一次 MD5 去重。這樣同一張圖出現(xiàn)在多篇文章里時只保留一份原始文件節(jié)省空間的同時也讓后續(xù)素材查重變得簡單。3.3 素材庫組織主題聚類和標簽體系素材抓下來只是第一步能不能用好取決于怎么組織。Skill A 每處理完一篇文章會生成一張結構化的素材卡類似這樣--- title: 為什么說提示詞工程正在變成一門手藝 source: https://mp.weixin.qq.com/s/xxx author: 某作者 date: 2025-12-03 topics: [AI, 提示詞, 寫作] desc: 提示詞不是填空題而是對需求的精確描述。 --- 核心觀點 - 提示詞的本質是約束信息空間 - 結構化輸出優(yōu)于自由發(fā)揮 - 好的提示詞需要迭代而非一次成型 引用金句 “你問不出好問題就得不到好答案。” 相關素材 - [[20251203-提示詞工程入門]] - [[20251210-結構化Prompt模板]]素材卡會按主題自動歸檔比如 AI、效率、產品、寫作。這樣我在寫新文章的時候只需要在素材庫里按標簽檢索就能快速找到可用的案例和引用。3.4 合規(guī)邊界只處理你有權訪問的內容這里必須說清楚一個邊界問題。Skill A 的設計初衷是整理你自己有權限訪問的內容包括你訂閱的公開文章、你自己寫的歷史文章、你購買課程的配套資料。它不應該、也不能用來繞過任何平臺的訪問限制更不應該做任何形式的批量濫用。我在 skill 的配置里寫死了一條約束只處理用戶有權訪問的內容不破解任何登錄或訪問限制。如果在實際操作中遇到需要授權才能查看的內容直接跳過并在報告里標注“需人工確認”。守住這條線工具才能長久地用下去。4. Skill二號圖片本地化與公眾號排版發(fā)布4.1 公眾號排版最煩的一件事圖片外鏈失效公眾號后臺的編輯器是所有排版工具的終點站但如果你直接把網(wǎng)上的圖片鏈接粘進去翻車概率非常高。最常見的兩個問題一是某些平臺開啟了防盜鏈圖片在其他域名下直接顯示裂圖二是外鏈域名可能有訪問時效過幾個月圖片就掛了。所以 Skill B 的第一職責是把草稿里所有圖片先下載到自己服務器再把鏈接替換成自己的地址。只有圖片在自己的服務器上才能保證長期穩(wěn)定顯示。這個需求說出來簡單但實際操作里藏著一個很深的坑后面踩坑章節(jié)我會專門講。4.2 圖片上傳與鏈接替換的實現(xiàn)思路先看一下整套邏輯。輸入是一個 Markdown 草稿里面圖片都是本地相對路徑或者外部鏈接。Skill B 分四步處理掃描草稿正文里所有圖片引用把它們提取出來。對每張圖片計算 MD5 值先查一下是否已經上傳過避免重復上傳。把新圖片通過 HTTPS 接口上傳到自己的服務器拿到永久鏈接。把草稿里的原始圖片引用全部替換成新鏈接。核心去重邏輯可以參考下面這段偽代碼import hashlib def upload_image(path, remote_base_url): content open(path, rb).read() file_hash hashlib.md5(content).hexdigest() if file_hash in uploaded_map: return uploaded_map[file_hash] resp upload_to_server(path, remote_base_url) uploaded_map[file_hash] resp[url] return resp[url]這段邏輯看著簡單但它幫我省了無數(shù)重復勞動。以前手動上傳圖片的時候最煩的就是同一張圖傳了好幾次服務器里一堆垃圾文件。有了 MD5 去重服務器清爽多了。4.3 一鍵生成公眾號風格的排版第二步是排版標準化。公眾號文章的排版風格如果每次手動調色號、字號、間距都不一樣讀者體驗就很差。Skill B 內置了一套我自己的排版規(guī)范一級標題用加粗大字二級標題用帶編號的加粗文字引用金句統(tǒng)一用引用塊樣式代碼塊使用等寬字體并加淺色底紋關鍵結論用加粗強調不濫用顏色段落間距固定圖片下方統(tǒng)一加居中的圖注Skill B 拿到 Markdown 草稿后會按照這套規(guī)則生成一份結構化的富文本內容。我只需要復制粘貼到公眾號后臺再微調個別細節(jié)就行。整個排版過程從原來的半小時壓縮到三分鐘以內。4.4 發(fā)布接口對接與測試號驗證最后一步是發(fā)布。公眾號平臺有官方的素材管理接口和發(fā)布接口Skill B 可以先幫你把內容和封面圖上傳到素材庫生成一個待發(fā)布的草稿然后由人工確認后正式發(fā)布。這里強烈建議用一個公眾號測試號先跑通全流程再在正式賬號上操作。測試號可以走一遍從上傳素材到創(chuàng)建草稿的完整鏈路但不會真的推送給粉絲容錯率極高。我第一次對接的時候就因為一個參數(shù)寫錯導致發(fā)布失敗如果直接在正式號上試就是一次真實的推送事故。另外如果你希望 Skill B 在排版之前順帶生成一段推薦摘要可以給它配置一個兼容 OpenAI 格式的模型 API比如 DeepSeek 這類服務傳入草稿正文讓它提煉三句話。但這只是錦上添花不是核心鏈路配不配都不影響主流程。5. 兩個skill協(xié)作跑通全流程從選題到發(fā)文只用20分鐘5.1 完整流程演示從一篇原始筆記到已發(fā)布文章拿我最近寫的一篇關于效率工具的推文舉例。整個流程是這樣的早晨我把一條需求扔給 WorkBuddy“把上周收藏的 5 篇效率工具相關文章整理成選題素材庫。”Skill A 立刻開始工作解析文章列表、提取正文、下載圖片、生成素材卡。五分鐘后工作目錄里躺著一份整潔的素材庫。我打開素材庫掃了一眼那些文章的核心觀點和引用金句確定了一個切入點。然后花了十分鐘寫下八百字左右的草稿把我的觀點和素材卡里的案例串起來。這一步完全人工因為觀點和判斷是文章的靈魂我不想交給機器。草稿完成后我把文件丟給 Skill B。它自動上傳了文中的三張配圖替換了鏈接套用了排版規(guī)則還幫我生成了一段摘要。最后我在后臺預覽、微調、點擊發(fā)布。整個過程下來不到二十分鐘。5.2 時間對比改造前后單篇文章的耗時差異我特意記錄過改造前后的耗時整理成一張表環(huán)節(jié)改造前耗時改造后耗時找素材、回顧歷史文章45 分鐘5 分鐘圖片處理與上傳20 分鐘2 分鐘排版30 分鐘3 分鐘發(fā)布前外鏈與圖片檢查15 分鐘5 分鐘撰寫正文60 分鐘10 分鐘總計170 分鐘25 分鐘總耗時從接近三小時壓到了二十五分鐘節(jié)省出來的時間我用來做一件事多讀兩篇資料、多改兩遍稿件。這才是公眾號自由真正有價值的地方——不是讓你少干活而是讓你把時間分配給真正重要的事。5.3 質量兜底發(fā)布前的五分鐘人工檢查清單自動化程度再高發(fā)布前的人工檢查也不可省略。我給自己定了一份五分鐘清單標題是否夸大是否有標題黨嫌疑AI 生成的內容容易過度承諾。文中的數(shù)據(jù)、引用、案例是否核實過來源AI 引用容易漂移。引用的原文是否保留原意有沒有被斷章取義。圖片是否清晰、是否被壓縮變形、鏈接是否替換成功。文末的引導關注、合集標簽、封面圖是否更新。說白了這套流程把重復勞動外包給了機器但把責任留給了人。你不審核就發(fā)布出了問題是賬號的問題不是 skill 的問題。6. 踩坑實錄發(fā)布失敗、鏈接歸屬報錯和二維碼失效的排查鏈6.1 “鏈接內容不屬于當前公眾號”到底是怎么回事第一次跑通全流程的時候我在發(fā)布環(huán)節(jié)遇到了最讓人頭疼的報錯“鏈接內容不屬于當前公眾號”。這個報錯看起來像密碼不對其實是鏈接歸屬問題的提示。我的排查思路是反著來的。先看這個報錯出現(xiàn)的時機——它只在“原文鏈接”字段校驗時出現(xiàn)。也就是說我在草稿里填的原文鏈接并不是當前公眾號體系內的文章鏈接。常見原因有三個從第三方平臺復制的鏈接帶了跳轉參數(shù)導致平臺識別不到原始站內路徑。原文鏈接字段直接填了其他公眾號的文章 URL。正文里的圖片鏈接指向他站圖床被平臺校驗攔截。解決方案也很直接把“原文鏈接”改成當前賬號已發(fā)布的文章鏈接或者干脆留空。正文里的圖片全部通過 Skill B 替換成自己服務器的地址繞開跨域校驗。6.2 發(fā)布失敗后去哪里看日志三種定位手段發(fā)布失敗之后最怕的就是對著屏幕干瞪眼。我的排查順序是固定的三層日志逐級看第一層看 WorkBuddy 的任務運行日志。每次任務執(zhí)行都會有記錄按任務 ID 篩出來能看到每一步的輸入和輸出定位是哪一步出的問題。第二層看 API 返回的錯誤碼。微信類接口返回的errcode和errmsg信息量極大比如40078 invalid url基本可以確定是鏈接格式問題48001 api unauthorized則說明權限沒配好。第三層看我自己的服務端記錄。我會在調用發(fā)布接口前把請求參數(shù)完整打出來包括媒體素材 ID、原文鏈接、封面圖地址這樣一旦出現(xiàn)問題可以直接比對參數(shù)和平臺要求。一層層往下看大多數(shù)問題十分鐘內可以定位。找不到日志才是最大的問題所以我從一開始就在 skill 的配置里寫死了“每個步驟結束必須輸出結構化日志”這條規(guī)則。6.3 圖片防盜鏈和二維碼失效一個隱藏很深的坑這是我在圖片處理上踩過最深的一個坑。第一次跑 Skill B 的時候所有圖片都顯示上傳成功了但文章發(fā)布后預覽有一張大圖直接裂掉。排查之后發(fā)現(xiàn)那張圖所在的源站做了 Referer 防盜鏈直接下載時返回的是 403。解決方案是下載圖片時帶上原始響應頭信息特別是上游域名。但代碼里寫死 Referer 不夠因為不同源站的校驗規(guī)則不同。我索性在 Skill B 里加了一個規(guī)則下載失敗時自動重試三次帶上原始頁面的 Referer 和 User-Agent如果還失敗就把該圖片標記為“需人工處理”而不是讓它靜默失敗。二維碼失效則是另一個隱蔽的坑。很多平臺生成的二維碼本質上是帶時效參數(shù)的短鏈抓取下來的時候是好的但存到本地一百年后它還是同一個文件里面的內容早已過期。所以我在 skill 里規(guī)定遇到二維碼類圖片默認不做靜態(tài)存檔而是記錄二維碼所指向的原始鏈接由人工決定是否需要重新生成。6.4 持續(xù)改進skill版本化與回歸測試Skill 寫完之后不是一勞永逸的平臺接口會變、排版需求會變、你的內容策略也會變。我給兩個 skill 都加了版本號每次改動都記錄在職責描述里。同時沉淀了一套回歸測試用例選了十篇風格迥異的歷史文章每次修改后批量跑一遍確認排版輸出還是原來的樣式。這個習慣幫我避免了很多次“改一處、壞三處”的尷尬。Skill 本質上也是代碼是代碼就要有版本管理和回歸測試意識。沒有這套兜底你根本不敢放心升級。我在實際使用中最大的體會是公眾號自由的核心不是“不用寫”而是“終于可以把力氣花在值得花的地方”。兩個 skill 解決的從來不是寫作問題而是寫作前后那些瑣碎卻消耗人的環(huán)節(jié)。它們不替你思考但幫你把思考之外的一切安排得明明白白。最后分享一個小技巧給 skill 命名和寫描述的時候多寫動詞少寫形容詞。像“采集、歸類、生成、上傳、替換、校驗”這些詞AgEnt 理解得遠比“智能處理”“高效整理”準確。你在定義上省下的每一分鐘都會在執(zhí)行時十倍還給你。