写完公众号以后，最烦的那一步，也可以交给 Skill

写公众号有一个很烦的时刻。

不是写开头，也不是改标题。

是文章差不多写完以后，要把它搬进公众号后台。

标题要复制。

摘要要填。

正文要贴。

图片要传。

封面要选。

最后还要拿手机预览一遍，看图有没有糊，段落有没有挤，封面裁切有没有怪。

每一步都不难。

但很碎。

碎事最耗人。写文章时还有劲，到了发布这一步，人已经开始烦了。

baoyu-post-to-wechat 处理的就是这段最后一公里。

它把 Markdown、封面和正文图片整理好，保存到微信公众号草稿箱。

注意，是草稿箱。

不是直接群发。

这点我很喜欢。自动化负责搬运，人负责最后检查。

1. 它解决什么问题：写完以后别死在复制粘贴上

公众号写作最累的地方，有时候不是写。

是写完以后的那堆杂活。

Markdown 里看着好好的标题，进编辑器以后样式可能变。

本地图片要一张张传。

封面要单独上传。

外链在公众号里也不能照原样处理。

如果你只是偶尔发一篇，忍一忍也过去了。

但如果你想做一个系列，每周发，甚至一周发几篇，这些动作就会变成固定损耗。

baoyu-post-to-wechat 的价值很清楚：把固定损耗变成固定流程。

写作的人，少碰一点后台。

文章先自动进草稿箱，再由人检查。

这比一上来追求“全自动群发”更稳。

2. 直接看效果：一篇 Markdown 进草稿箱

它要处理的东西很普通：

一篇 Markdown 正文
一张封面图
正文里的插图
公众号 AppID / AppSecret
公众号后台的 IP 白名单

跑完以后，它做几件事：

渲染 Markdown
上传正文图片
上传封面
调用公众号接口
保存到草稿箱

最后，公众号后台会多出一篇草稿。

标题、摘要、作者、封面、正文图片都在。

人要做的事，是进去预览。

看标题是否顺眼。

看封面是否被裁坏。

看手机上读起来是否太挤。

它没有替你做最后判断。

它只是把重复的小动作接过去。

3. 怎么使用：最短上手路径

这个 Skill 在宝玉的 Skills 仓库里：

https://github.com/JimLiu/baoyu-skills

把这个 GitHub 地址扔给 AI，然后说：

帮我安装这个仓库里的 baoyu-post-to-wechat Skill。

装好以后，需要先配置一次公众号信息。

你要准备三样东西：

公众号 AppID
公众号 AppSecret
公众号后台的 IP 白名单

这些在公众号后台的“设置与开发 / 开发 / 基本配置”附近。

这里有个小提醒：不要把 AppSecret 发到聊天里。

正确做法是让 AI 引导你保存到本机配置文件里。

你可以这样说：

请一步步引导我配置 baoyu-post-to-wechat。
密钥只保存在本机，不要让我发到聊天里。

配置好以后，每次文章写完，就可以直接说：

请把这篇 Markdown 文章保存到我的微信公众号草稿箱。
不要直接群发。

第一次配置会稍微麻烦一点。

后面就轻很多。

4. 它到底是怎么实现的

这里要讲实一点。

baoyu-post-to-wechat 不是一句“帮我发布公众号”的提示词。

它背后有一组脚本，把发布拆成了几段。

核心文件大概是这些：

SKILL.md
scripts/md-to-wechat.ts
scripts/wechat-api.ts
scripts/wechat-article.ts
scripts/wechat-image-processor.ts
scripts/wechat-extend-config.ts

SKILL.md 负责告诉 AI：什么时候触发、先读什么配置、走 API 还是浏览器、标题摘要封面怎么取。

md-to-wechat.ts 负责把 Markdown 渲染成公众号能用的 HTML。

wechat-api.ts 负责走公众号 API，把文章保存到草稿箱。

wechat-article.ts 负责浏览器路线，用 Chrome 打开公众号后台，像人一样把内容放进编辑器。

wechat-image-processor.ts 负责处理正文图片。比如图片太大、格式不合适时，先压缩或转换，再上传。

wechat-extend-config.ts 负责读取配置。作者名、主题颜色、默认发布方式、评论开关，都从这里进来。

所以它的真实链路不是“AI 自己点点点”。

更接近这样：

AI 读文章和配置
-> 脚本把 Markdown 转成 HTML
-> 脚本识别正文图片
-> 图片上传到公众号
-> 封面上传成素材
-> 调用 draft/add 保存草稿
-> AI 把 media_id 和下一步告诉你

这套设计里，AI 更像调度员。

真正干活的是脚本和公众号接口。

5. 跟着一个例子看它怎么跑

拿一篇普通 Markdown 文章来说。

文章开头有 frontmatter：

title: 文章标题
summary: 文章摘要
author: 作者名
coverImage: imgs/cover.png

正文里有几张图：

正文图：imgs/flow.png
实现图：imgs/architecture.png

你让 AI 发布到公众号草稿箱。

AI 会先按 Skill 规则读配置。

比如默认主题是什么，作者是谁，走 API 还是浏览器。

如果走 API，wechat-api.ts 会先调用 md-to-wechat.ts。

这一步做的事很具体：

提取标题和摘要
把 Markdown 渲染成 HTML
把正文图片先替换成占位符
把外链按公众号习惯处理成底部引用
记录每张图片的本地位置

为什么要替换成占位符？

因为公众号正文里的图片不能只写本地路径。

本地的 imgs/flow.png，公众号后台不认识。

脚本要先知道“这里原来有一张图”，再把这张图上传到公众号，拿到公众号返回的图片地址，最后把占位符换成真正的 <img>。

正文图片走的是 media/uploadimg。

封面不一样。

封面要走素材上传，拿到 thumb_media_id。

最后 wechat-api.ts 才会调用公众号的草稿接口：

draft/add

发给它的内容里包括：

title
author
digest
content
thumb_media_id
need_open_comment
only_fans_can_comment

接口成功后，会返回一个 media_id。

这个 media_id 就是草稿保存成功的凭据。

如果 API 路线走不通，比如 IP 白名单不对，就会报错。

这不是玄学。

公众号接口会直接告诉你：这个 IP 不在白名单里。

这时候要么把当前 IP 加进去，要么换成浏览器路线。

浏览器路线慢一点，但思路也很清楚。

wechat-article.ts 会用 Chrome 打开公众号后台，进入文章编辑器，填标题，填作者，粘贴 HTML，再把图片占位符一个个替换成上传后的图片。

它不是更高级。

它只是另一条路。

API 像走正门。

浏览器像照着人的动作做一遍。

6. 为什么好用：它把麻烦事写成了边界

这个 Skill 好用，不是因为它能“发布公众号”这几个字很厉害。

厉害的是它把边界写得清楚。

第一，默认保存草稿

公众号文章不是随便发个临时消息。

发出去以后，读者马上就能看到。

所以它默认保存草稿，而不是直接群发。

这条边界我会专门保留。

自动化处理重复动作。

人做最后检查。

第二，它承认 API 会卡在 IP 白名单

很多发布工具写得很理想。

只要填 AppID 和 AppSecret，就好像一定能发。

实际不是。

公众号 API 还有 IP 白名单。

你的机器 IP 没加进去，接口就会拒绝。

这个 Skill 把这件事放进配置流程里，也支持浏览器路线兜底。

这就实在多了。

第三，它认真处理图片

公众号文章最容易出小问题的地方，是图片。

正文图片要上传。

封面要上传。

图片太大要压。

格式不合适要转。

本地路径要换成公众号里的地址。

wechat-image-processor.ts 专门处理这些琐碎事。

这类细节平时不起眼。

但流程能不能稳定跑通，靠的就是这些不起眼的地方。

第四，它把配置和执行分开

AppID、AppSecret、作者名、评论开关、默认发布方式，不应该散落在每次对话里。

这个 Skill 会读配置文件。

你配置一次，后面复用。

这样也更安全。

密钥留在本机。

聊天里少出现敏感信息。

7. 如果你要写一个类似的 Skill

这类 Skill 最值得学的，不是“怎么调用某个平台 API”。

而是怎么把发布拆成一套可检查的流程。

可以照这个结构写：

适用场景：
用户已经有内容，需要保存到某个平台的草稿箱。

触发条件：
用户说“发布到公众号”“保存到草稿箱”“上传文章”“生成平台草稿”。

输入：
文章文件、标题、摘要、作者、封面图、正文图片、账号配置。

输出：
平台草稿、草稿 ID / media_id、预览或检查提醒。

工作流：
1. 读取配置。
2. 检查账号凭证。
3. 解析文章元信息。
4. 转换正文格式。
5. 处理正文图片。
6. 上传封面。
7. 保存到草稿箱。
8. 返回结果和检查项。

关键约束：
- 不要默认直接群发。
- 不要在聊天里暴露密钥。
- 图片要先上传，不能保留本地路径。
- 出错时说清楚是哪一步失败。
- API 不通时，要给浏览器或人工 fallback。

可选工具：
- 平台 API
- 浏览器自动化
- Markdown 渲染器
- 图片压缩 / 格式转换
- 配置文件读取

可改造方向：
- 小红书图文草稿
- 微博长文草稿
- 多平台内容分发
- 发布前质量检查

这里最值得抄的是顺序。

先把内容变成平台能接受的格式。

再处理图片。

再保存草稿。

最后让人检查。

顺序乱了，问题就多。

8. 我会给它加什么

如果继续改这个 Skill，我会加一个发布前自检。

保存草稿前，让 AI 先看一遍：

标题是否太长？
摘要是否像广告话术？
封面图是否存在？
正文图片是否过多？
文章里有没有本地绝对路径？
有没有不适合公众号的外链？

这些检查不复杂。

但很实用。

很多发布事故，不是大问题。

是小地方没看。

自动化流程里多一道检查，会省掉很多回头修。

9. 最后给一个可复制的行动步骤

如果你只是想用：

先让 AI 帮你配置一次，然后每次写完文章都说：

请用 baoyu-post-to-wechat 把这篇文章保存到微信公众号草稿箱。
不要直接群发。
发布前请检查标题、摘要、封面和正文图片。

如果你想学着写：

记住这个设计：发布类 Skill 要有边界。

它可以自动处理重复动作。

但最后那一下，最好留给人。