以前写完文章还得坐在电脑前排版发布，现在手机上跟 Agent 聊几句，文章就进草稿箱了。不只是省了几分钟，是整个发布流程从”必须开电脑”变成了”随时随地”。
写公众号的朋友大概都知道 md.doocs.org——把 Markdown 粘进去，选好样式，复制渲染结果，贴到公众号后台。我一直在用这个工具，很方便，也叠加了自己的自定义样式。
但这套流程有个小问题：图片。如果 Markdown 里用的是本地图片路径，粘贴到 md.doocs.org 之后需要手动把每张图片替换成它图床上的链接，网络不稳的时候还经常上传失败。所以我之前的做法是 Typora 里先把图片上传到 OSS，Markdown 里引用线上地址，这样粘贴到 md.doocs.org 就不用管图片了。多了一步，但省心。
今天把整个流程自动化了：写完 Markdown，两条命令，直接进公众号草稿箱。图片、封面、样式全自动，不用再管图床的事。
从手动到命令行
md.doocs.org 是开源的（GitHub 14k+ star），核心链路是 Markdown → marked 解析 → CSS 主题 → juice 内联样式 → 可以粘贴到公众号的 HTML。我的目标就是把这个手动步骤变成命令行，同时加上自己的自定义样式。
跟 Hermes 说了一下需求，它在执行过程中发现 baoyu-skills 里的 baoyu-markdown-to-html 底层用的就是 doocs/md 同一套引擎，而且已经封装好了命令行接口，支持参数指定主题和颜色，直接输出 HTML。既然有人把同样的引擎封装成了命令行工具，就没必要自己再搭一遍渲染链路了。
加了一层自己的主题
这套工具的主题系统支持继承——默认主题处理了微信公众号的兼容性问题（内联 CSS、段间距、代码块样式），我只需要写 CSS 覆盖层。
jovi 主题做了几件事：h2 标题左对齐加主色下边框，去掉默认的居中和背景色；加粗文字用黑色加暖橙色波浪下划线，比单纯加粗更有辨识度；引用块是暖橙左边框配浅橙背景；图片加了圆角和阴影；整体字重降到 400，阅读感更舒服。
整个 CSS 63 行。在主题配置里加入注册就完成了。
渲染命令：
npx -y bun skills/baoyu-markdown-to-html/scripts/main.ts "文章.md" --theme jovi --color blue输出一个 HTML 文件，CSS 全内联了，粘贴到公众号编辑器就能用。
推草稿：脚本处理剩下的事
渲染完的 HTML 不能直接丢进草稿箱。微信的 draft/add API 有几个前置要求：正文里的图片必须是微信图床的 URL（mmbiz.qpic.cn），封面要走永久素材接口拿 thumb_media_id。
推送脚本做的事：
扫描 HTML 里所有 <img> 标签，按优先级找本地图片文件——先看渲染时写入的绝对路径，再看相对路径、外部 URL。找到文件后通过 uploadimg 接口上传到微信图床，拿回 URL 替换原来的 src。封面图走 material/add_material 接口，拿回 thumb_media_id。中间还有一步：清理 Markdown 渲染残留的 \_ 转义字符——不清理的话微信直接拒绝。
推送命令：
python3 wechat-draft-push.py "文章.html" --title "标题" --author "jovi AI电报" --digest "摘要" --md-file "文章.md" --cover "封面图.png"跑完打开公众号后台，草稿已经在那了。
踩过的坑
第一个坑是 errcode 45166，invalid content。第一次推送长文直接被微信打回来，报错信息就一个 errcode 加一句 “invalid content”，没有任何线索。当时第一反应是 CSS 的问题——是不是自定义主题里哪个样式微信不认？把 CSS 一条条去掉重试，都不行。后来把 HTML 源码翻出来逐段排查，才发现是 Markdown 渲染残留的 \_ 转义字符，肉眼在渲染后的页面里根本看不出来，但微信那边的校验就是过不了。加了个 sanitize_html() 把这些字符清掉，才通过。
第二个坑是图片接口。微信有两个不同的图片接口，干的不是同一件事：正文插图走 uploadimg，返回 URL 直接替换 src；封面走 material/add_material，返回 media_id 用于 draft 字段。一开始搞混了，接口报错才分清楚。文档里其实写了，但一开始没细看，踩了坑才回去读的。
附带一个收益：以前用 Typora 写文章要先上传图片到 OSS，是因为本地图片在 md.doocs.org 里要手动替换，有时候网络不好还传不上去。现在脚本直接把本地图片上传到微信图床，OSS 这步省了，md.doocs.org 的图片问题也一并解决了。
真正的变化：不依赖电脑了
打通 Markdown 到草稿箱这一步，对我来说意义挺大的。
之前写公众号，写完了上传发布的过程必须在电脑上操作——打开 md.doocs.org、复制渲染结果、登录公众号后台、粘贴、上传封面、填摘要，一步一步来。手机上干不了这些事。
现在 Hermes Agent 已经把选题、新闻筛选、内容分析、写作串起来了，加上直接推草稿箱这一步，整个内容生产链都通了。我在手机上跟 Hermes 聊几句，选题可以定、文章可以写、草稿可以推，随时随地把一篇公众号文章发出去。
这不只是省了几分钟排版时间，是把整个发布流程从”必须坐在电脑前”变成了”手机上就能完成”。
还有哪些环节没法自动化
API 能做的：正文插图、封面图、摘要，都支持。不能做的：原创声明没有 API 字段，只能在后台手动勾；合集/专辑是发布后才走 album/* 接口，不属于 draft 流程。
所以推完草稿还得去后台做两步：勾原创、加合集。好消息是也就十几秒的事，跟以前打开浏览器排版比，已经省了一大截。
回过头看整个流程：Typora 写 Markdown → 一条命令渲染 → 一条命令推草稿 → 后台勾原创加合集 → 发布。中间所有排版、图片、封面的活都自动化了，人只管写内容和最后确认。
工具太多，筛选成本才是真的
做这件事的过程里有个细节：Hermes 在执行的时候发现 baoyu-skills 用的是跟 md.doocs.org 一样的引擎，于是直接用了它的命令行封装。这不是一开始就规划好的，是执行过程中碰到的。
这个时代开源工具和 AI skill 多到数不过来，但没有人有精力去搜索所有的 skill、测试所有的 skill，找出符合自己工作流程和使用场景的那个。很多时候你跑通了一个工具，发现设计逻辑跟你的习惯对不上，或者配置方式跟你的环境不兼容。你不是专门做这件事的，手头还有别的事要干。
让 Agent 帮忙找、帮忙判断能不能用，然后在这个基础上快速走通自己的路径——每一步都踩过、改过、知道为什么这么写。工具多、环境杂、每个人的流程都不一样，这个阶段大概没有捷径——你只能把属于自己的那条路走通。