作为一个内容创作者，我长期面临一个现实的痛点：文章写完了，真正耗时间的反而是发布环节。
微信公众号不支持外链图片，每张都要手动上传；代码块、引用块需要逐个调整样式；封面图、头部提示、底部二维码要分别处理——这一套流程下来，一篇文章光发布就要花30-45分钟。我开始思考：能否用自动化工具把这个重复性的工作流程完全打通？
于是我用OpenClaw搭建了一套内容创作工作流，从信息采集、写作、配图，再到最后的发布，实现了端到端的自动化。
这篇文章分享其中发布环节的实现思路和具体做法。
整体架构：两层分工模式
这套系统分为两个独立模块：
article-writer（内容生产层）
负责从信息源采集资讯、生成截图、AI配图、生成Markdown格式文章，所有产出的素材存储在本地目录结构中。
wechat-article-publisher（发布执行层）
读取article-writer的产出物，自动完成图片上传、HTML渲染、草稿创建的全流程。
两层的分离设计让系统更清晰：内容生产专注内容质量，发布执行专注微信平台的技术对接。
执行方式极其简洁
整个发布流程只需要一行命令：
python3 scripts/publish.py --article-dir ~/Documents/openclawworkspace/articles/2026-03-07/主题/
执行完毕后，排版好的文章就会出现在公众号的草稿箱里，审核没问题就可以直接发布。
内容主体：技术实现细节
第一部分：图片处理的全自动流程
微信公众号对图片的限制最为严格——它不认可任何外链URL，所有图片必须是微信CDN的地址。
这是发布自动化的第一个难点。
脚本的处理逻辑分为三步：
1. 扫描阶段：遍历文章目录中的所有图片文件
2. 上传阶段：通过微信的upload-img接口逐个上传图片，获取微信CDN的URL
3. 替换阶段：用返回的微信CDN链接替换Markdown中原有的本地图片路径
缓存机制避免重复上传
上传过的图片URL会被记录在meta.json文件的wechat_image_map字段中。
当修改文章后重新发布时，脚本会检查缓存，已上传的图片直接调用缓存地址，不会重复上传到微信。
这样既节省了上传时间，也减少了不必要的微信API调用。
封面图的特殊处理
封面图使用微信的永久素材接口（add_material）上传，这个接口会返回media_id——这是创建草稿时微信后台要求的特定格式。
与普通文章内的图片流程不同，需要单独处理。
用户侧体验
整个过程对使用者完全透明。你只需要确保所有图片都放在文章目录里，脚本会自动处理上传、获取链接、替换引用的全过程。
第二部分：Markdown到微信HTML的渲染引擎
微信公众号的后台编辑器只认HTML格式，而且有个严格的限制：不支持CSS class选择器，所有样式必须以内联方式写入每个HTML标签里。
如果每次都手动编写带完整内联样式的HTML代码，工作量会非常大。所以我设计了一套自动渲染系统。
隐藏标签系统的工作原理
在Markdown文件中插入HTML注释标签，格式如下：
渲染器在处理文件时会识别这个注释，自动将其内容渲染成带蓝色左边框的导读框。
多平台兼容性设计
这些HTML注释在飞书、GitHub等标准Markdown渲染器中完全不可见，不会影响文档的正常阅读体验。
这意味着一份Markdown源文件可以同时适配多个平台：
• 在飞书中呈现为干净的文档格式
• 在GitHub中保持原始Markdown的可读性
• 在微信中自动转换为精美排版的文章
当前支持的样式标签包括：
| 标签名称 | 渲染效果 |
| wechat head | 蓝色左边框的导读框 |
| highlight | 加粗高亮特定句子 |
| card-list | 圆角卡片列表 |
| code-card | 提示词代码卡片 |
| summary | 蓝色总结区块 |
| follow-guide | 引导关注的提示区块 |
自动化的Header和Footer生成
渲染器在处理文章时会自动添加：
Header部分：星标提示、封面图、署名信息
Footer部分：文章结尾标记、关注二维码
这些内容不需要写在原始的Markdown文件中，渲染器会根据meta.json中的配置信息自动生成和插入。
第三部分：智能草稿管理机制
微信公众号的发布流程分为两个阶段：创建草稿→审核发布。我的自动化系统需要支持多个场景。
三种工作模式：
模式一：首次发布
• 脚本创建新的草稿
• 微信返回的media_id被写入meta.json文件中
• 脚本发送微信预览通知
模式二：修改更新
• 脚本检测到meta.json中已存在media_id
• 自动调用草稿更新接口
• 不会产生重复草稿
模式三：强制新建
• 执行命令时添加--force-new参数
• 脚本忽略缓存中的media_id
• 创建完全独立的新草稿
这个设计避免了操作错误导致的草稿重复，同时保留了必要的灵活性。
第四部分：图文笔记的独立处理流程
在开发过程中我遇到过一个比较坑的问题：微信将「文章」和「图文笔记」定义为两种完全不同的内容类型，需要走不同的API接口。
具体的差异如下：
| 内容类型 | 图片处理方式 | 适用接口 |
| 文章（长文） | 使用upload-img接口逐个上传 | news/add或news/update |
| 图文笔记（图片主体） | 所有图片必须用永久素材接口上传 | material/add_material |
一开始我用同一个脚本同时处理两种类型，结果发出来的图文笔记在微信端格式完全乱掉了。原因在于使用了错误的图片上传接口。
修正后的方案在脚本层面添加了类型判断逻辑，根据content-type字段自动选择对应的处理流程。这样两种内容类型都能被正确创建成对应格式的草稿。
用户需要手动决策的部分
自动化系统处理的是排版、上传这类重复性的技术工作，但发布决策权始终保留给用户。整个流程分为四步：
步骤1：文章写完 → 自动触发
步骤2：脚本把文章推到草稿箱，发送预览通知 → 自动执行
步骤3：在公众号后台审核内容 → 人工决策
步骤4：点击发布按钮 → 人工操作
步骤1-2完全自动化，步骤3-4由人来控制。内容质量和发布时机的决策权完全在你手里。
结尾总结
这套系统目前运行在我的Ubuntu服务器上，由OpenClaw进行调度。从AI写完文章、到自动推送到草稿箱、再到我审核发布，整个链路已经完全闭环。
从产品经理的角度看，这套自动化的核心价值在于：把不增加价值的重复工作从我的工作流中彻底移除。我不需要再花30-45分钟做排版、上传、样式调整这类机械劳动，这些时间现在可以用在思考内容策略、优化文章质量上。
对于也在用OpenClaw搭建内容创作工作流的人来说，这套发布自动化方案可以直接参考。如果你也想实现类似的功能，可以参考微信公众平台的官方开发文档和OpenClaw的API接口文档。
欢迎在评论区分享你的自动化实践经验。