
md2wechat 2.0.5 发布:把确认层做出来,让系统不再误导你
聚焦 md2wechat 2.0.5 这次版本更新,讲清 inspect、preview、JSON 纯输出、错误提示修正,以及为什么这不是一次简单加功能,而是一次把确认层做出来的更新。
大家好,我是极客杰尼。
md2wechat 2.0.5 已经发布了。
这次更新最重要的点,不是多了几个命令,而是把“确认层”正式做出来了。
如果用一句话概括这次版本,我会这样说:
它不是一次堆功能的更新,而是一次把系统可信度往前推了一步的更新。
截图链接:2.0.5 release cover
这次 2.0.5 到底在解决什么问题
如果你让 AI 帮你写公众号、排版公众号,应该很容易遇到这几类问题:
- AI 说“已经搞定”,但真正发到公众号后台后,效果完全不是你理解的那样
- 本地图片看起来没问题,结果发到草稿箱里显示异常
- 主题很多,但你并不知道系统最后到底用了哪个,也不知道结果会长什么样
- 出错时提示不准确,结果你沿着错误方向排查了半天
这些问题表面上看很散,实际上都指向同一个根因:
你看不到系统会怎么理解你的内容,也看不到最终会生成什么。
所以这次 2.0.5 的核心,不是“继续加能力”,而是把这中间缺失的确认层补上。
这次版本最重要的 4 个变化
我会把这次更新收口成 4 个核心变化。
1. 新增 inspect
inspect 的作用很直接:
在真正转换、上传、创建草稿之前,先告诉你系统会怎么理解这篇文章。
它会提前暴露出一些最关键的信息,比如:
- 标题最终会取哪一行
- 作者和摘要会从哪里来
- 正文里的
H1会不会重复 - 当前状态到底适不适合直接发草稿
命令也很简单:
md2wechat inspect article.md --json这一步的价值不在于“多一个命令”,而在于你终于能在执行前看清楚系统的理解结果。
以前很多问题都是发出去之后才发现。
现在你可以先看,再决定要不要继续。
2. 新增 preview
如果说 inspect 解决的是“系统会怎么理解”,那 preview 解决的就是“最后会长什么样”。
md2wechat preview article.md它会先给你一个本地预览,让你在浏览器里直接看效果。
这里有两个很关键的变化:
API模式下,能给出真实预览AI模式下,不再假装已经得到了最终稿
这件事非常重要。
因为很多工具最容易误导用户的地方,恰恰就是“看起来像最终结果,但其实不是最终结果”。
我这次明确做的选择是:
宁可诚实地告诉你当前只是确认页,也不伪造一个看起来已经完成的假结果。
3. 机器输出更干净了,脚本和 Agent 更稳了
除了面向人的确认层,这次我也把面向脚本和 Agent 的输出收紧了一轮。
几个关键修正包括:
--json现在保持stdout纯 JSONconvert --preview现在直接输出纯 HTML- 机器可读输出不再混入多余提示信息
这意味着什么?
意味着脚本、自动化任务、Agent 在接这套工具时,不需要再先清洗一遍输出,稳定性会高很多。
这类改动不一定最显眼,但在真实工作流里影响很大。
因为一旦机器输出不稳定,上层自动化就很容易被拖垮。
4. 错误提示、文档、Skill、发布检查都重新校准了一轮
这次我还花了不少时间在“看起来不像新功能”的地方。
比如一个很实际的例子:
微信常见错误 45004,以前很容易被误导成“正文太长”。
但真实排查时,更应该优先检查的是:
digestsummarydescription
这类校准的价值在于,它会直接减少误判。
这次我重新对齐了:
- 文档
- Skill 入口说明
- 发布前检查
- 版本锚点
- 错误解释
目标很明确:
尽量让文档写的、Agent 理解的、工具实际做的,是同一件事。
现在的主线已经很清楚了
这次更新之后,md2wechat 的核心使用链路可以收口成:
inspect -> preview -> convert / upload / draft也就是:
- 先检查
- 再看样
- 最后发布
这条链路的意义,不只是步骤更完整。
更重要的是,它把“确认”和“执行”分开了。
用户不再需要先赌一次结果,再回过头来补救。
现在可以先确认,再决定是否继续往下走。
为什么我会特别强调“确认层”
我越来越相信一个判断:
AI 工具真正难的,不是“能不能做”,而是“会不会误导你”。
一个系统如果功能很多,但确认层和执行层不一致,用户只会越来越不敢用。
因为你根本不知道:
- 它理解的是不是你想表达的内容
- 它生成的是不是你最终要发布的结果
- 出错时它提示的是不是真正的问题
这也是为什么我把 2.0.5 看得比普通小版本更重要。
它解决的不是表面上的命令数量,而是底层的信任问题。
这次版本我已经在真实链路里跑过什么
这次更新不是只停留在写功能。
我已经把核心链路在真实环境里跑通过,重点确认了这些环节:
- 本地图上传成功
- 图片回填成功
- 预览链路可用
- 草稿创建成功
也就是说,这次主线不是纸面成立,而是实跑通过的。
这次更新对谁最有价值
如果你正好属于下面这几类人,这次更新会比较直接地改善体验:
- 用 Markdown 写公众号文章的人
- 让 AI 帮你写公众号的人
- 把
md2wechat接到 Agent 工作流里的人 - 想把“写作 -> 排版 -> 草稿发布”串成自动化的人
因为你最需要的,往往不是再多一个命令,而是:
- 能不能先知道系统会怎么理解
- 能不能先看到结果
- 能不能减少误导和返工
这正是 2.0.5 在补的部分。
后面还会继续补高级主题和内容模块
这次版本把确认层补出来之后,后面我会继续往“商业级排版感”这条线推进。
接下来准备继续补的方向包括:
- 封面卡
- 数据卡片
- 对比模块
- 步骤流模块
这些能力更适合:
- 品牌发布稿
- 销售方案稿
- 产品介绍稿
也就是说,后面的重点会不只是“能发布”,还会继续往“更适合真实业务场景”推进。
最后
这次 md2wechat 2.0.5,对我来说,不是一版“加了几个参数”的更新。
它更像是一次把发布闭环重新收紧的更新。
从结果上看,这版最大的变化就是:
系统终于更诚实了,也更可确认了。
如果你也在用 Markdown + Agent 写公众号,这一版应该会明显顺手很多。
项目地址:github.com/geekjourneyx/md2wechat-skill
原文发表自微信公众号:md2wechat 2.0.5 版本发布
更多文章

OpenClaw 如何安装 md2wechat skill?按真实安装路径梳理一遍
基于 OpenClaw 官方文档和 md2wechat-skill 公开说明,整理在 OpenClaw 中安装 md2wechat skill 的几种方式与适用场景。

md2wechat-skill 使用指南:安装顺序、第一次调用与 Agent 最该先做什么
一篇讲清楚 md2wechat-skill 安装顺序、discovery-first、第一次成功调用,以及最常见误区的保姆级长文。

微信公众号草稿 API 是什么?它和 Markdown 转 HTML 有什么区别
解释微信公众号草稿 API 的作用、适用场景,以及它和基础转换接口在流程位置上的区别。
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新