富阳说：做 1000 个 AI 工具，让每个人享受 AI 便利。
最近我做了一个小工具：yishan-mp。
它不是一个“自动群发机器人”，也不是一个营销系统。它解决的是一个更具体、更高频的问题：如何把 AI 生成的 Markdown 文章，快速变成可以放进微信公众号后台的草稿。
如果你经常写公众号，大概率会遇到这样的流程：
AI 生成初稿
|
v
本地改 Markdown
|
v
复制到排版工具
|
v
调整标题、列表、代码块、引用
|
v
复制到公众号后台
|
v
上传封面、填摘要、保存草稿
这个流程不难，但非常碎。
真正消耗时间的不是“写一篇文章”，而是文章写完以后那些重复动作：排版、预览、复制、封面、摘要、账号选择、草稿保存、失败重试。
所以我把这件事做成了一个内部内容中台：
AI / 本地 Markdown
|
v
yishan-mp
|
+--> 微信格式预览
|
+--> 一键复制到公众号后台
|
+--> 保存到公众号草稿箱
|
+--> 发布记录留痕
这篇文章分享它的设计思路和实现细节，重点是方法，而不是让大家照抄某个项目。
痛点：AI 写得快，但公众号发布还是慢
现在 AI 已经能很快生成文章初稿。
比如你给它一个主题：
帮我写一篇关于微信开放平台管理公众号草稿的技术分享，面向独立开发者，强调 Markdown 到微信富文本的自动化流程。
几分钟后，你就能拿到一版结构完整的 Markdown。
但问题来了：公众号后台不是 Markdown 编辑器。
微信公众号文章实际需要的是一段兼容微信编辑器的富文本 HTML，而且有很多细节：
AI 解决了“内容生成”的一半问题，但没有解决“内容入库”的另一半问题。
如果每篇文章都手工复制、手工排版、手工保存，AI 带来的效率会被后半段流程吃掉。
所以我对这个工具的目标定义很明确：把公众号文章发布前的重复动作平台化。
yishan-mp 做了什么
yishan-mp 是一个公众号运营后台，目前主要做几件事：
它的定位不是替代微信公众平台，而是在“AI 生成内容”和“公众号后台发布”之间加一层自动化工作台。
一个典型工作流是这样的：
1. AI 生成文章初稿
2. 本地或后台修改 Markdown
3. 选择公众号账号
4. 选择排版模板
5. 预览微信样式
6. 保存到公众号草稿箱
7. 到公众号后台做最后检查
8. 人工确认后再发布
这里最重要的一点是：系统默认只到草稿箱，不做正式群发。
公众号正式发布涉及内容合规、账号权限、群发频率和人工审核，不应该被一个内部工具随便自动触发。自动化应该帮人减少重复劳动，而不是绕过关键确认。
为什么要接微信开放平台
如果只管理一个公众号，最简单的做法是直接配置公众号的 AppID 和 AppSecret，用它换 access_token，再调用草稿箱接口。
这条路能跑，但扩展性不够。
一旦你想管理多个公众号，就会遇到这些问题：
微信开放平台的第三方平台机制更适合做“公众号内容中台”。
它的核心逻辑是：
开放平台第三方平台
|
v
生成授权链接
|
v
公众号管理员扫码授权
|
v
系统保存 authorizer_appid / refresh_token
|
v
后续按 appid 获取 authorizer_access_token
|
v
调用公众号草稿箱、素材等接口
这样一来，后台不再只服务某一个公众号，而是可以维护一组授权公众号。
这对个人开发者也有价值。你可能有自己的技术号、项目号、测试号，也可能帮朋友或客户维护几个公众号。用开放平台接入以后，发布目标就变成了一个可选择的账号列表，而不是写死在代码里的配置。
核心链路：Markdown 到微信公众号草稿箱
整个系统最关键的链路可以拆成五步。
其中最容易被低估的是 Markdown 转微信 HTML。
普通 Web 页面可以依赖 CSS 文件，但公众号编辑器更适合内联样式。否则复制到后台以后，很容易出现样式丢失、行距不稳定、代码块变形等问题。
所以转换后的 HTML 大致会变成这样：
<p style="margin:12px 0;line-height:1.8;font-size:16px;color:#333">
这是一段正文。
</p>
代码块也要变成适合微信编辑器的结构：
<pre style="background:#f5f5f5;border:1px solid #e0e0e0;padding:12px 16px">
<code style="font-family:Menlo,Monaco,Consolas,monospace;color:#333">
pnpm mp:publish publish ./article.md --env dev
</code>
</pre>
这件事不复杂，但很值得做成基础设施。
因为只要这层稳定了，后面不管文章是人写的、AI 写的、脚本生成的，最终都能进入同一条发布链路。
模板系统：不要每篇文章重新排版
公众号排版最怕两件事。
第一，每篇文章都手工调样式。
第二，同一个账号里的文章风格不统一。
所以我没有把样式写死，而是做成模板。
一个模板本质上就是两类配置：
比如技术文章可以用“技术极客蓝”，代码多的文章可以用“深色代码夜读”，教程型内容可以用“知识卡片清爽”。
模板化之后，发布流程会变成：
同一篇 Markdown
|
+--> 技术极客蓝
|
+--> 知识卡片清爽
|
+--> 产品增长橙
内容和表现分离以后，公众号写作会轻很多。
你不需要每次都纠结标题多大、引用什么颜色、代码块背景怎么调。只要选模板，系统自动把样式注入到 HTML 里。
后台发布和 CLI 发布要同时存在
我一开始只做后台页面，后来又补了 CLI。
原因很简单：AI 自动化更适合走命令行。
后台适合人工编辑：
打开后台 -> 粘贴 Markdown -> 预览 -> 选择模板 -> 保存草稿
CLI 适合自动化流水线：
pnpm mp:publish publish ./article.md --env dev --appid wxxx --template-id 2
如果封面已经有本地文件，也可以让 CLI 先上传封面，再保存草稿：
pnpm mp:publish publish ./article.md \
--env dev \
--appid wxxx \
--template-id 2 \
--cover-file ./cover.jpg
这就把公众号发文变成了一个可以被脚本调用的能力。
以后 AI Agent 生成完文章后，不一定要把结果丢给人手动复制。它可以把 Markdown 写到文件里，然后调用 CLI 保存到草稿箱。
更完整的链路可以是：
选题库
|
v
AI 生成初稿
|
v
AI 自检标题、结构、摘要
|
v
生成 Markdown 文件
|
v
CLI 保存到公众号草稿箱
|
v
人工在公众号后台最终审核
这才是我想要的 AI 内容自动化：AI 负责提效，系统负责落地，人负责最终判断。
发布记录很重要
很多人做内部工具时容易忽略日志。
但只要接外部平台 API，就一定会失败。
微信公众号接口可能因为这些原因返回错误：
如果没有发布记录，你只会看到“失败了”。
有发布记录以后，至少可以知道：
这类记录不一定要做得很复杂，但必须有。
因为内容生产系统一旦进入自动化，就不能只靠终端输出或浏览器提示。失败必须能追溯，成功也必须能查到。
安全边界：自动化不等于自动群发
做公众号自动化时，我最看重的一条边界是：默认只保存草稿箱。
原因很现实。
公众号文章不是普通日志，也不是内部消息。它一旦群发，就是公开内容，涉及品牌、合规、事实准确性和读者体验。
所以我把系统分成两段：
这也是我建议大家做内容自动化时遵守的原则：让 AI 和系统负责前置生产，让人保留最后发布权。
除了发布边界，凭据也要收好。
AppSecret、开放平台密钥、管理员密码、Session 密钥都不应该进仓库。它们应该放在服务器环境变量或进程配置里。
最小可用的安全设计至少包括：
技术栈不是重点，但要够轻
这个项目用的是：
这里没有上很重的后台系统，也没有一开始就做复杂队列。
原因是这个工具的核心不是“高并发”，而是“流程闭环”。
对个人开发者或小团队来说，一个轻量 Web 后台加 SQLite 已经够用。真正应该优先打磨的是：
先把主链路跑通，再考虑复杂能力。
可以怎么复制这套思路
如果你也想做一个类似工具，不一定要照搬我的技术栈。
可以按这条路线逐步做：
第一阶段：先做 Markdown 到微信格式
不要一上来就接开放平台。
先做一个最小工具：输入 Markdown，输出微信可复制 HTML。
Markdown -> HTML -> 内联样式 -> 复制到剪贴板
这一阶段就能明显减少排版时间。
第二阶段：加入模板系统
当文章多起来以后，把样式抽成模板。
文章内容 + 模板配置 = 微信富文本
这样可以让不同栏目保持稳定风格。
第三阶段：接草稿箱接口
有了稳定 HTML，再接微信公众号 draft/add。
这一阶段要处理封面、摘要、作者、thumb_media_id、错误记录。
第四阶段：接微信开放平台
如果只服务一个号，可以先不做。
如果要服务多个号，再接第三方平台授权，把公众号变成可选资源。
第五阶段：接 AI 自动化
最后再让 AI Agent 或脚本进入流程。
AI 写初稿 -> 生成 Markdown -> 调 CLI 保存草稿 -> 人工审核发布
这个顺序很重要。
先解决确定性工程问题，再接 AI。否则你会同时面对内容质量、样式兼容、接口权限、发布失败等一堆问题，很难定位到底哪里出错。
总结
AI 让写文章变快了，但公众号发布链路本身并没有自动变短。
如果每篇文章仍然要手工排版、手工复制、手工上传封面、手工保存草稿，AI 的效率只能发挥一半。
yishan-mp 做的事情，就是把后半段流程工程化：
Markdown -> 微信富文本 -> 模板排版 -> 封面素材 -> 草稿箱 -> 发布记录
这套系统的价值不在于技术多复杂，而在于它把高频重复动作变成了可复用能力。
更重要的是，它保留了正确边界：AI 可以生成内容，系统可以保存草稿，但正式发布仍然交给人最后确认。
对个人开发者来说，这就是一个很实用的内容自动化范式：
AI 提效
系统落地
人做判断
当这三件事分工清楚，公众号内容生产就不再是一堆手工步骤，而是一条可以持续优化的生产线。
相关项目
yishan-mp 是我用来管理公众号文章草稿和微信富文本排版的内部工具。
核心能力包括：Markdown 转微信富文本、模板化排版、微信开放平台授权、多公众号草稿箱、CLI 发布和发布记录。