夜雨聆风你现在看到的这篇文章，从配图、排版到进草稿箱，是用我这次做的一个工具一键完成的。
而这篇文章要讲的，正是这个工具本身是怎么被做出来的。
这件事本身就有点意思：一个 AI 产品试点的产物，反过来发布了一篇讲它自己的文章。
事情的起点，和我做过的很多项目一样，只有一句话：
我想做一个工具，把写好的 Markdown，自动配好图、排好版，一键发到公众号。
听起来很简单。但我没有一上来就动手。
一、一句话的想法，我没有直接开干
这种"一句话需求"最容易让人直接打开编辑器开写。
但我这次刻意把它当成一个试点项目来做，先调研，再动手。
这是上一个项目（ChatBI）教我的事：方向大致清楚、但路径不确定的东西，先对齐、先调研，比急着写代码省时间。急着写出来的，往往是个方向不对的 demo。
调研之后我很快发现一件事——这个领域，开源已经很成熟了。
二、别人已经解决了 80%，我只该做那 20%
把"Markdown 一键发公众号"拆开看，其实是好几层：排版、配图、发布。
排版（把 Markdown 转成公众号兼容的样式）已经被开源项目解决得很好，成熟方案一大把。发布相关的接口封装，也有现成的轮子。
如果我从头自研一个排版引擎，那就是在重复造轮子，还不一定做得过人家。
真正没被很好解决、又最花我时间的，其实是两件事：
配图：尤其是封面和每一段的示意图，既花时间，又没有标准答案；
把"内容 → 配图 → 排版 → 发布"串成一条龙，而不是在四个工具之间来回搬运。
所以策略一下就清楚了，和 ChatBI 一模一样：成熟的部分尽量复用，自研只聚焦在差异化的那一小块。
真正值得你亲自做的，往往是别人没解决的那 20%。
三、先跑通最有价值的一段，别想着一步到位
想清楚做什么之后，我也没有一上来就去接微信的发布接口。
我先做了一个最小闭环：Markdown → 自动配图 + 排版 → 手动复制粘贴进后台。
为什么第一步是"手动粘贴"这么土的方案？
因为这一步最该验证的，根本不是"能不能自动发出去"，而是"配图和排版到底行不行"。微信 API 有它自己的坑（后面会讲），我先把它放一放，用最低的成本去验证最大的不确定性。
这就是最小闭环的意义：先打穿那个最不确定的点，其他地方用临时方案先扛着，不丢分。
手动粘贴一点都不丢人，它让我用最快的速度看到了真正想看的东西。
四、真正的难题，是"一篇文章里多张图怎么统一风格"
配图最大的风险，我一开始就标出来了：一篇文章配六张图，如果各画各的，放在一起就像东拼西凑。
解法说起来不复杂：固定一套"风格模板"——固定画风、固定配色、固定留白，再加一条硬约束：画面里不出现任何文字（否则 AI 容易生成乱码）。每张图，只换"画什么内容"。
结果，六张图放在一起，配色、线条、留白高度统一，像出自同一套视觉系统。
这个抽象眼熟吗？
它和 ChatBI 里"引擎不变、知识包可变"是同一个东西：不变的是模板，可变的是内容。
两个看起来毫不相干的项目——一个是对话式数据分析，一个是公众号配图——最后落在了同一个抽象上。这让我更确信，这套方法不是某个项目的巧合。
五、形态怎么选，要看硬约束，不要看潮流
做之前我纠结过一阵：做成网页版，还是做成接进 Cursor 的工具？
想清楚之后发现，真正的分水岭根本不是"网页还是工具"，而是另一个问题：要不要自动去调微信的发布接口。
因为微信发布有两个躲不掉的硬约束：
密钥（AppSecret）不能暴露；
调用的服务器 IP 必须在白名单里。
顺着这两条往下推就清楚了：纯前端的网页，密钥会暴露、还跨域，做不到一键发布；带后端的网页，要部署、要固定 IP、还要管每个用户的密钥，成本一下就上去了。
而我的第一批用户，是懂技术的朋友——他们本来就在 Cursor、在命令行里工作。做成一个本地运行的工具正好：不用部署、密钥天然留在本地、还和写作环境合在一起。
所以我选这个形态，不是因为它新，而是因为它最贴合约束和真实用户。
形态选择，先看硬约束和真实用户，别看哪种形态更时髦。
六、踩的坑，我都尽量变成下次的判断
这个项目里也踩了不少坑。我的习惯是：每个坑不只解决掉，还记下它的"范式"——下次遇到类似的，怎么判断。
IP 白名单报错：我本地查到的是一个 IPv6 地址，但微信那边看到的是 IPv4，怎么填都不对。范式：别假设你本地探测到的 IP 就等于对方看到的 IP，以对方报错里给出的为准。
AI 配图老是冒出乱码文字：图像模型写中文很不稳。范式：别让图像模型写字，让它只画图标，文字交给排版层。
微信编辑器不认外部样式：范式：排版全部用内联样式；这种平台限制要顺着来，复用成熟引擎比自己硬刚更稳。
这些坑，当场解决掉就过去了。但记下来，它们就变成了下一个项目的检查清单。
七、从"我自己能跑"到"别人能用"，中间隔着一层
闭环跑通之后，其实我可以收工了——它已经能用了。
但我想把它给朋友用，甚至开源出去。这一步，比想象中多了一层。
它要求我把所有"在我这里写死的东西"，全部变成"每个人各自填的配置"：公众号账号、配图风格、排版主题、内容来源。
自用的时候，这些都是固定的；一旦要给别人用，它们就全都变成了"变化点"，必须配置化、零改代码。
你看，又是同一个道理：引擎统一，配置各异。
这一层"产品化"经常被低估：能自己跑通，不等于别人能用。 中间隔着的，是把每一个隐含的前提，都变成显式的、别人能填的配置。
八、写到这里，这篇文章正要被它自己讲的工具发出去
绕了一圈，回到开头那句话。
你现在读的这篇文章，发出它的，正是它从头到尾在讲的这个工具。
我在 Cursor 里和 AI 一起，把一句话的想法，做成了一个能用的工具；然后这个工具，又把这篇讲它自己怎么诞生的文章，配好图、排好版，一键送进了草稿箱。
这正是我一直想要的状态：
做产品攒下的经验，能变成一个工具；这个工具，又能把经验本身发出去，被更多人看到。
经验和工具，从此开始互相喂养——做一个项目，沉淀一点方法，做成一个小工具或一篇文章，而工具又让下一篇内容发得更快。转一圈，下一次就更省力。
你现在看到的这篇，就是这个循环转完一整圈，留下的第一个产物。
最后多说一句：这个工具我整理好之后会开源出来。如果你也常写公众号，又不想在配图和排版上反复耗时间，到时候可以拿去用。
— 关于 AI 产品落地经验的记录 —
