在 Codex 里跑通公众号发布：wechat-publisher 和 multi-platform-articles 教程

我最近把两个和微信公众号发布相关的 skill 装进了 Codex：wechat-publisher 和 multi-platform-articles。

这篇我不打算再写成“过程记录”了，直接写成教程版。目标很简单：你照着做，最后能把一篇 Markdown 真正发到微信公众号草稿箱。

先说结论。

如果你只是想让 Codex 帮你把文章发到公众号，优先用 wechat-publisher。链路短，配置也更直接。

如果你还想要主题、命令行、本地渲染 HTML，或者以后准备把文章发布流程工具化，那就用 multi-platform-articles，它背后真正工作的东西是 mpa CLI。

这两个我都已经在本机跑通，而且都做了真实草稿测试，不是“装上了理论可用”，而是真的把草稿创建到了微信后台。

你应该先知道的事

这两个方案都绕不过三件事：

1. 你必须有公众号的 AppID 和 AppSecret
2. 你必须把微信接口看到的公网出口 IP 加进白名单
3. 你改完 skill 或配置以后，最好重启一次 Codex

很多人卡在第二步。报错通常是 40164，看上去像凭证错了，实际上往往是 IP 白名单没配好。

更烦的是，如果你的网络环境是分流的，国内接口和国外网站可能看到的是两个不同的公网 IP。对微信来说，只有它自己看到的那个 IP 才算数。

方案一：wechat-publisher

这是更适合“我现在就要发”的方案。

它的配置文件路径是：

/Users/ldd/.codex/skills/wechat-publisher/config.json

内容长这样：

{
  "appid": "wx...",
  "appsecret": "...",
  "author": "你的作者名"
}

这里没什么花活，填对就行。appid 一般是 wx 开头的 18 位字符串，appsecret 直接从微信公众平台复制。

拿到这两个值之后，到微信公众平台后台做白名单配置：

1. 登录 https://mp.weixin.qq.com
2. 打开“设置与开发”
3. 进入“基本配置”
4. 找到“IP 白名单”
5. 把当前机器实际访问微信接口时的公网 IP 加进去

配完之后，重启 Codex。然后你就可以直接在 Codex 里说：

发布到微信

或者：

把这篇文章推送到公众号

这类表达就够了。这个 skill 的设计就是为了让你少碰命令行，直接交给助手完成。

什么时候选 wechat-publisher

我会在下面几种场景优先选它：

• 我已经有一篇 Markdown，只想尽快发草稿
• 我不想记太多命令
• 我更在意链路短、好排错
• 我希望助手直接替我做完上传图片、生成封面、创建草稿这整套动作

它不是最花哨的，但它非常像一个“到站即下车”的工具。配置完，直接干活。

方案二：multi-platform-articles + mpa

这个 skill 和上面那个不一样。multi-platform-articles 自身其实很薄，真正执行排版和发布的是 mpa CLI。

也就是说，这一套更像“给 Codex 一个外部工具链”，而不是单纯塞一个 skill 说明文件进去。

我没有直接用它文档里的 curl | sh 安装，而是换成了更稳的做法：先审源码，再下载 GitHub release 二进制，核对 SHA-256，最后只把 mpa 放进 ~/.local/bin。

原因很简单。我不喜欢让远端安装脚本顺手改 PATH、复制 skill、再跑一遍内置安装子命令。能手动安装的时候，尽量手动装。

mpa 装好之后，先确认命令在：

mpa --version

然后看主题列表：

mpa themes list

如果你要配置公众号凭证，可以直接运行：

mpa

它会打开一个 TUI 配置界面。它自己的配置文件默认在：

~/Library/Application Support/mpa/config.json

如果你想先把 Markdown 渲染成本地 HTML：

mpa convert your_article.md --mode local --theme default -o out.html

如果你要直接推送到微信草稿箱：

mpa publish wechat-draft \
  --md your_article.md \
  --mode local \
  --theme default \
  --title "文章标题" \
  --cover cover.jpg \
  --author "作者名"

这里我建议默认用 --mode local。

原因不是意识形态，而是工程上更稳。从源码看，mpa 的本地渲染已经足够支撑公众号草稿发布。只有当你主动启用 AI 生图或者 API 渲染时，它才会继续去调用额外的外部服务，比如 OpenAI、OpenRouter、Gemini、ModelScope 之类的接口。

如果你的目标只是“把文章发出去”，那就别平白给链路加变量。

什么时候选 multi-platform-articles

我会在这些场景选它：

• 我想先挑主题再发
• 我想在本地先生成 HTML 看效果
• 我想把发布流程命令化、脚本化
• 我后面可能会继续扩展更多平台或更多渲染流程

它不是更简单，但它更适合沉淀成工作流。

一个真实踩坑：mpa 0.1.19 的微信响应兼容问题

这个坑我觉得值得单独写，因为它非常像现实世界里会把人误导半天的那种问题。

我第一次跑 mpa publish wechat-draft 时，命令退出码是 1，看起来像失败了。终端里也确实打印了报错，说解析微信 draft/add 的响应失败。

但我继续看响应体，发现里面其实已经有 media_id 了。换句话说，微信草稿已经创建成功，只是 CLI 自己把成功响应误判成了错误。

最后定位下来，问题很具体：mpa 0.1.19 把微信返回的 errcode 当成了必填字段处理，但微信成功时并不一定总带这个字段。

所以这不是权限问题，不是内容问题，也不是白名单问题，而是响应解析写死了。

我本地把这个兼容问题修掉，重新编译了一版 mpa，再测就正常了。也就是说，如果你现在是在我这台机器上继续用，当前的 mpa 已经是修过的版本。

这两个方案到底怎么选

如果你懒得来回比较，我直接给一个最实用的判断。

选 wechat-publisher，当：

• 你只在乎发稿
• 你希望 Codex 多做事，你少碰命令
• 你希望配置尽量简单

选 multi-platform-articles，当：

• 你要主题
• 你要命令行
• 你要本地渲染 HTML
• 你要把整条发稿路径做成长期工作流

它们不是谁完全替代谁。

一个更像“直接干活的工具”，一个更像“可以持续扩展的流水线”。

我建议你怎么用

如果你现在刚把这两套都装好，我建议顺序是这样的：

1. 先用 wechat-publisher 跑通第一篇真实文章
2. 等你确认公众号配置和白名单都稳定了，再开始用 mpa 挑主题、跑命令行工作流
3. 如果以后你发现自己越来越依赖主题和本地渲染，再把重心转到 multi-platform-articles

别一上来就追求最完整的方案。先让链路跑通，再谈优雅。

这是我这次装完两个 skill 之后最强的感受。很多工具看起来功能越多越强，但真正长期好用的，往往是路径最短、最少添堵、出了问题最好查的那个。

如果你的目标是“今天把文章发出去”，那就先选最短的路。等短路走稳了，再去铺长路。