
飞书文档如何转微信公众号?一个调用 md2wechat API 的 Chrome 插件
介绍 feishu-md2wechat 的真实定位:它是一个把飞书文档转成公众号排版的 Chrome 插件,底层调用 md2wechat API 完成转换。
“飞书文档怎么转微信公众号?”
更准确地说,这个问题在 feishu-md2wechat 里对应的不是“一个独立的飞书 API 产品”,而是:
- 一个运行在 Google Chrome 中的飞书转公众号插件
- 插件内部调用
md2wechat API - 把飞书文档更顺地转成适合公众号的排版结果
这和“专门为飞书设计一套独立 API 服务”是两回事。
项目地址:
- GitHub: geekjourneyx/feishu-md2wechat
这个项目的真实定位是什么
根据项目说明,feishu-md2wechat 是一个浏览器插件,目标是把飞书文档转成微信公众号文章排版。
它本身并不是一个单独售卖“飞书文档转公众号 API”的后端产品,而是基于 md2wechat API 提供能力。
所以更准确的理解方式应该是:
- 前端形态:Chrome 插件
- 底层能力:
md2wechat API - 使用场景:飞书文档到公众号排版
为什么插件形态很合理
因为飞书本来就是网页文档环境。
如果你的内容已经写在飞书里,一个浏览器插件通常比单独导出到别的系统更顺手:
- 不需要离开飞书工作界面
- 可以直接对当前文档做转换
- 更适合“先写完,再排版”的轻量流程
这也是浏览器插件相对于“纯后端 API”更贴近用户动作的地方。
md2wechat API 在这里扮演什么角色
这个项目真正复用的是底层转换能力。
也就是说,插件不是自己重新实现一套排版引擎,而是把飞书文档内容交给 md2wechat API 去处理,再把结果呈现回来。
这样做的好处是:
- 前端入口更轻
- 底层转换能力可以和其他工具复用
- 后续如果要继续接草稿、素材或高级能力,路径也更清楚
它适合哪些人
下面这些情况比较适合先看这个插件:
- 飞书文档是主要写作环境
- 想快速把飞书内容转成公众号排版
- 还不想一上来就搭完整 API 工作流
- 希望先把“写作入口 -> 排版出口”这一步跑顺
它和其他 md2wechat 项目的关系
可以这样理解:
- feishu-md2wechat:飞书入口的插件
- obsidian-md2wechat:Obsidian 入口的插件
- md2wechat-lite:CLI / shell 入口
- md2wechat-skill:Claude Code / OpenClaw 的 skill 入口
共同点在于,它们底层都围绕 md2wechat API 这层能力展开;不同点在于它们服务的入口不同。
为什么这篇需要纠正表述
因为如果把它写成“飞书文档转公众号 API 值得做吗”,会让读者误以为:
- 这是一个单独的飞书 API 产品
- 或者它本身提供独立于 md2wechat 的后端服务
而真实情况是:
- 这是一个 Chrome 插件
- 底层调用
md2wechat API - 插件形态才是它最核心的产品特征
总结
feishu-md2wechat 更准确的定位,是一个把飞书文档转成公众号排版的 Chrome 插件,而不是一个独立的“飞书转公众号 API 产品”。
插件负责承接飞书这个入口,底层则复用 md2wechat API 的转换能力。
这样理解,才和项目本身一致。
更多文章

适合自动化调用的微信公众号 API 应该满足什么条件
从最小示例、接口边界、参数命名和错误返回四个方面,说明什么样的微信公众号 API 更容易接入自动化流程。

从内容抓取到公众号草稿:我为 AI Agent 设计的一条内容创作工具链
从 jina-cli 到 md2wechat Agent API,梳理一条更适合 AI Agent 的内容创作工作流:前期内容获取,中期选题与写作,后期自动排版并进入公众号草稿箱。

Obsidian 发布到微信公众号,现实里最顺的一条路径是什么
面向 Obsidian 用户的文章,解释从笔记写作到微信公众号排版与发布的常见路径,以及插件、API、自动化流程的分工。
邮件列表
加入我们的社区
订阅邮件列表,及时获取最新消息和更新