公众号自动化发布流水线

为什么做这件事？

公众号「强强的FDE成长日记」是每周更新的连载。起初每篇发布都要手工做一长串操作：把 Markdown 正文转成微信能认的 HTML、上传十几张配图、逐张生成封面、手动建草稿，还得记得删掉上一期同标题的旧稿。一次发布小两个钟头，而且人肉操作最容易在「删旧稿」这种地方出岔子——稍不留神，草稿箱里就堆出两篇同标题的稿子。

于是我把它做成了一条自动化流水线：从正文 Markdown 到公众号草稿箱，脚本一键跑完。这本身就是一次完整的工程交付——把「内容生产」和「发布」这两段里所有重复、易错、机械的部分，全交给代码，人只留最后那一判断。

流水线的三段

这条流水线由三块组成，各管一段。

1. AI 配图 + 后期

配图走本地 ComfyUI 的 Z-Image-Turbo 模型（动漫插画风），尺寸统一 960×544。模型出的是底图，后期用 PIL（Pillow）在图上叠中文对话气泡、底部说明条、顶部标题横幅。这里有个关键判断：AI 直接画中文几乎必然乱码，所以文字一律代码叠上去，不交给模型画。

2. 微信 API 封装

写了一个 Python 的 WeChatAPI 客户端，把最常用的三件事封成方法：access_token 获取与自动缓存（过期前 60 秒刷新）、素材上传（封面走永久素材、正文内嵌图走 uploadimg 拿 URL）、建草稿（draft/add）。最终一个 publish_article() 就能「上传封面 → 建草稿」两步走完。

3. 一键发布脚本

发布脚本做的事：解析正文的 YAML frontmatter → 上传正文里的内容图与封面 → 把 Markdown 构建成微信兼容的内联 HTML → 调建草稿接口 → 用 batchget 列出草稿箱、删掉同标题旧稿 → 回读确认只剩新稿。

草稿箱 API 的坑（逐个排过）

自动化真正的难点不在写代码，在微信接口的一堆反直觉行为。这 6 个坑是真实踩过、每个都导致过一次发布返工的：

1. batchget 中文标题乱码：接口返回的 JSON 中文标题会变成乱码，导致「按标题找旧稿」匹配失败。根因是 resp.json() 按响应头猜测编码（Latin-1），把中文标题错误解码。解法：不用 .json()，先 resp.content.decode("utf-8") 再 json.loads。
2. 同标题旧稿不自动覆盖：重复发同一标题，微信不会自动顶掉旧稿，草稿箱会堆两篇同题草稿。必须先遍历 batchget 定位旧稿 media_id，先删再传。
3. 改标题后旧稿按标题删不掉：比上一条更阴。模板按「标题精确匹配」删旧稿，一旦改了标题，旧稿就「失联」删不掉。得改成按内容特征（如旧标题关键词）去定位 media_id 删除。
4. 摘要超长报错：摘要超过 60 字符，微信返回 errcode 45004。这个 60 要用 len() 实测，不能手数。
5. author 字段有讲究：作者名用错（非「强强」）会报 errcode 45110。
6. 发布后必须回读验证：所有「删旧稿」逻辑都可能静默失败，脚本跑完必须 batchget 回读，确认草稿箱里只有新稿。

沉淀

这套东西沉淀下来的不只是几个脚本，而是三件可复用的事：

• 一条可复用的发布管线：任何「Markdown 正文 → 公众号草稿」的内容，换参数就能复用。
• 一份微信 API 踩坑清单：上面 6 个坑写进了文档，下次遇到不用再试错。
• 一个「内容自动化」的心法：凡是重复两次以上、且人肉做容易错的操作，就该交给脚本。AI 负责生成，脚本负责搬运，人只负责把关与判断。

自动化要做的不是把活干完，是把「重复且易错」的活从人手里接过去，让人只做判断。