微信图文自动化发布工作流应该怎么设计

“微信图文自动化发布工作流” 听起来很大，但如果拆开看，它其实就是一组连续动作：

• 内容从哪里来
• 怎么变成微信适配格式
• 图片和素材怎么处理
• 怎么进入草稿
• 哪一步保留人工审核

真正难的往往不是某一个接口，而是这几步之间怎么衔接。

为什么很多自动化尝试最后都停在半路

因为很多人一开始只解决了一小段：

• 要么解决“AI 写文章”
• 要么解决“Markdown 转 HTML”
• 要么解决“批量生成内容”

但如果没有把这些动作串起来，最后还是会卡在：

• 图片处理
• 草稿创建
• 手工复制到后台
• 发布前检查

所以“自动化发布工作流”不是一个点能力，而是一条链。

一个更合理的微信图文自动化发布链路

如果从实际落地看，我会把它拆成 5 段：

1. 内容输入

内容来源可以很多：

• Markdown
• Obsidian
• 飞书文档
• AI Agent 生成结果

这一层的重点不是统一写作工具，而是统一出口。

2. 排版转换

这一步解决的是：

• Markdown 怎么变成微信可用 HTML
• 主题和字号怎么控制
• 基础结构怎么稳定下来

这是整条链路里最基础的一层。

3. 素材处理

很多人低估了这一步的重要性。

真实发布里常见问题都在这里：

• 正文图片来源不稳定
• 封面图单独处理
• 多图内容需要批量上传

如果素材层没接住，后面的草稿也很难完整自动化。

4. 草稿创建

这一步是自动化链路真正开始产生业务价值的地方。

因为一旦内容进入公众号草稿箱，很多重复动作就被收缩掉了。

这里又可以继续分成两类：

• 图文消息草稿
• 小绿书草稿

不同内容形态，适合不同接口。

5. 人工审核与最终发布

大多数情况下，我并不建议把“自动化发布”理解成“全自动发出去”。

更稳的方式通常是：

• 前面 80% 自动化
• 最后 20% 人工审核

这对于公众号这种带品牌和合规要求的渠道，通常更现实。

为什么 Agent First 更适合这类工作流

因为 Agent 很适合做“串联动作”。

比如一个 Agent 可以负责：

• 接收内容输入
• 选择转换主题
• 调用素材上传
• 调用草稿接口
• 返回最终状态

这种工作方式比让人类在多个后台之间来回切换更自然，也更适合规模化。

这条链路里最常见的错误理解

一个常见误区是：

“只要我把 Markdown 转成 HTML，自动化就完成了。”

实际上，这只是工作流的前半段。

真正的自动化发布，更关心的是：

• 结果能不能进入草稿
• 图片是否可用
• 发布前是否还有稳定的审核点

如果这些没有设计好，所谓自动化就只是“少复制一次”。

对产品设计意味着什么

如果你的网站和 API 面向 Agent，产品表达就应该围绕工作流，而不是围绕孤立功能。

更合理的表达方式通常是：

• 基础转换
• 图文消息草稿
• 小绿书草稿
• 批量素材上传

再根据不同入口去提供：

• CLI
• skill
• 插件
• 文档

这样用户和大模型都更容易理解你的产品在链路中的位置。

总结

微信图文自动化发布工作流，不应该被理解成一个神奇的大按钮，而应该是一条分层清晰的链路：

• 输入
• 转换
• 素材
• 草稿
• 审核

把这条链路设计清楚，自动化才真正有可能稳定落地。