Skill 更像一份给 AI 编程助手的操作说明书

我一开始也把 Skill 当成插件

这段时间用 Codex 写东西，经常碰到一个词：Skill。

我一开始也把它当成插件。

后来用 baoyu-skill 跑公众号流程，才发现这个理解不太准。插件通常有 UI、有按钮、有版本号；Skill 更像一份写给 AI 编程助手看的操作说明书。

打个比方：你新招了一个实习生，他什么都能干，但不知道你们公司的流程。你不会让他自己猜，而是给他一份 SOP：

• • 第一步做什么
• • 用什么工具
• • 输出格式是什么
• • 哪些地方不能碰

Skill 就是这份 SOP。只不过读它的不是实习生，是 AI Agent。

具体来说，一个 Skill 通常是一个 .md 文件（或者一组文件），里面用自然语言写清楚：

- 这个任务的目标是什么- 需要调用哪些脚本或 API- 每一步的输入和输出是什么- 出错了怎么处理

Agent 读到这份文件后，就知道该按什么顺序执行、该调什么命令、该怎么处理异常。

所以它不是普通代码，也不是传统插件。

我现在会这样区分 Skill、插件和脚本：

baoyu-skill：一个具体的例子

baoyu-skill 是宝玉老师开源的一组 Skill，专门用来做公众号内容发布。

我没有参与开发。我做的事情是把它接到了自己的写作流程里——后面一篇文章会具体讲怎么配置。这里先聊它的设计思路。

它把"从 Markdown 到公众号发布"这件事，拆成了四个独立的动作。每个动作就是一个 Skill 文件，Agent 按需调用：

format-markdown → cover-image → post-to-wechat → 博客同步

为什么要拆成四个，而不是写一个"一键发布"？

因为实际写作中，你不是每次都需要走完全流程。有时候只是想看看排版效果，有时候只是换个封面，有时候文章还没写完但想先推一版草稿到手机上预览。

拆开以后，每个动作都可以单独用。这比"要么全跑要么不跑"灵活得多。

动作一：format-markdown —— 排版转换

做什么： 把你写的 Markdown 源稿，转换成微信公众号能正确显示的 HTML 格式。

为什么需要它：

微信公众号的编辑器不认 Markdown。你在本地写的 # 标题、> 引用、`代码`，直接粘过去全是乱的。

以前的做法通常是：打开一个在线 Markdown 转换器（比如 mdnice），把内容贴进去，调好样式，再复制到公众号后台。每次发文章都要重复这套操作。

format-markdown 做的就是这件事，但它是自动的：

• • 读取你的 .md 文件
• • 按照预设的排版样式（字号、行距、引用框颜色、代码块主题等）转换成 HTML
• • 输出的 HTML 可以直接被微信公众号 API 接受

关键细节： 排版样式是可以改的。如果你不喜欢默认的配色或字号，可以在 Skill 的配置文件里调整。这比每次在在线工具里手动选样式省事。

单独使用场景： 文章还在改，但想看看最终排版效果 → 只跑 format-markdown，不推到草稿箱。

动作二：cover-image —— 封面图生成

做什么： 根据文章标题和你指定的风格，自动生成一张公众号封面图。

为什么需要它：

公众号封面图的规格是 900×383 像素（或 2.35:1 比例）。每篇文章都需要一张，但大多数时候它的内容很简单——就是标题加一个简洁的背景。

手动做的话，通常是打开 Canva 或 Figma，找一个模板，换标题，导出，上传。不难，但每次都要花五到十分钟做一件完全重复的事。

cover-image 把这个过程自动化了：

• • 读取文章标题
• • 根据你选的风格预设（比如 minimal、sketch、蓝灰系）生成封面
• • 输出符合公众号尺寸要求的图片文件

关键细节： 风格预设是 Skill 文件里定义的，不是硬编码的。如果你想统一自己公众号的视觉风格，只需要改一次预设，后面所有文章的封面都会保持一致。

单独使用场景： 文章内容没变，但觉得封面不好看 → 只跑 cover-image，换一张封面。

动作三：post-to-wechat —— 推送到微信草稿箱

做什么： 把排版好的 HTML 正文、封面图、摘要等信息，通过微信公众号 API 推送到你的草稿箱。

为什么需要它：

注意：它推送的是草稿，不是直接发布。

这个区分很重要。公众号文章发出去就不能大改了（只能修改错别字），所以最后的发布动作一定要人来做。post-to-wechat 做的是把所有素材打包送到草稿箱门口，你在手机或电脑上预览满意了，再按发布。

它的工作流程大致是：

1. 1. 用 AppID 和 AppSecret 获取 access_token
2. 2. 把封面图上传到微信素材库，拿到 media_id
3. 3. 把正文里的本地图片也上传到素材库，替换为微信的图片链接
4. 4. 把正文 HTML、封面 media_id、标题、摘要、作者等信息组装成一篇图文
5. 5. 调用草稿箱接口，把图文存进去

关键细节：

• • 这里需要你提前配好 .env 文件（AppID、AppSecret）和 IP 白名单。具体配置步骤我会在下一篇文章里详细写。
• • 图文摘要如果不填，微信会自动抓取正文前 54 个字。如果正文开头是 HTML 标签，抓出来就是一堆乱码。所以 Skill 会要求你在 front matter 里写好 summary 字段。

单独使用场景： 排版和封面都没问题，只是想更新草稿箱里的版本 → 只跑 post-to-wechat。

动作四：博客同步 —— 本地归档

做什么： 把定稿的文章同步保存到你指定的本地目录，作为博客源文件或长期归档。

为什么需要它：

公众号的问题是：文章发出去以后，它就"困"在微信生态里了。你不能批量导出，不能全文搜索，不能用 Git 做版本管理。

如果你同时在做个人博客（或者将来打算做），本地留一份源文件就很重要。而且即使不做博客，把所有发过的文章按目录归档，也比在公众号后台翻历史消息方便得多。

博客同步 做的事情很简单：

• • 把最终版本的 Markdown 文件（含 front matter）复制到你指定的发布目录
• • 文件名按日期 + slug 命名，方便排序和检索
• • 如果你的博客用的是静态站点生成器（比如 Hugo、Hexo），这个文件可以直接被构建

关键细节： 这个动作是幂等的——跑多少次都一样，不会产生重复文件。如果源文件有更新，它会覆盖旧版本。

单独使用场景： 文章已经在公众号发了，后来发现一个表述想改 → 改完 Markdown 后只跑 博客同步，更新本地归档。公众号那边的已发布文章改不了，但至少你的本地版本是最新的。

四个动作串起来是什么样

当你准备好一篇文章，想从头到尾跑一遍完整流程时，大概是这样：

你："帮我发布这篇文章。"Agent 的执行顺序：  1. 读取 Markdown 源文件  2. [format-markdown] 转换排版  3. [cover-image] 生成封面图  4. [post-to-wechat] 推送到草稿箱  5. [博客同步] 归档到本地目录  6. 回复你："已推送到草稿箱，请预览确认。"你：打开微信公众号后台 → 预览 → 满意 → 发布

整个过程你只需要说一句话，然后做最后的检查。

但你也可以在任何环节停下来。比如：

• • "先排个版我看看效果" → 只跑到第 2 步
• • "封面换成 sketch 风格" → 单独跑第 3 步
• • "内容改了，重新推一版草稿" → 跑第 2 + 4 步

这就是拆成四个独立 Skill 的好处：流程可以组合，也可以拆开。

为什么 Skill 比浏览器自动化更稳

有人可能会问：我用浏览器自动化（比如 Selenium、Puppeteer）直接操作公众号后台，不也能自动发文章吗？

能，但不够稳。

浏览器自动化的问题在于，它依赖页面结构。微信公众号后台今天的按钮叫"新建草稿"，明天可能改成"创建图文"；今天登录流程是扫码，明天可能加一个滑块验证。每次页面改版，你的脚本都可能挂掉。

API 不一样。access_token、素材上传、草稿箱接口，这些是微信官方提供的标准接口，有文档、有版本号、有兼容承诺。除非微信主动废弃某个接口（会提前通知），否则你的流程不会因为前端改版而中断。

Skill 在这里的角色是：把调用 API 的步骤和参数，用自然语言写清楚，让 Agent 能读懂并执行。

你不需要自己写代码调 API。你只需要确保配置正确（AppID、AppSecret、IP 白名单），Skill 会告诉 Agent 剩下的事该怎么做。

最后

Skill 这种模式让我觉得有意思的地方在于：它降低了"自动化"的门槛。

以前想自动化一个流程，你要么写代码，要么找插件。现在多了第三条路：写一份说明书，让 AI 去执行。

这份说明书不需要编程知识。它需要的是你对自己工作流程的清晰理解——每一步做什么，为什么这么做，出错了怎么办。

下一篇文章，我会写具体的配置过程：怎么把 baoyu-skill 接到 Codex 里，怎么配微信 API，怎么跑通第一次发布。

如果你也在用 Markdown 写东西，并且想建一条稳定的公众号发布管道，可以等下一篇。