一键发布：我是如何用 AI 把笔记同步到飞书和博客的
起因：写完之后最烦的事
我用 Obsidian 写东西。写完一篇文章之后，往往需要发到不同的地方——飞书知识库给团队看，个人博客给互联网上的人看。
这个”发”的过程，比写本身还烦。
发飞书：复制内容 → 打开飞书 → 新建文档 → 粘贴 → 发现格式全乱了 → 手动调标题层级 → 手动调代码块 → 流程图直接没了。
发博客：检查文章格式 → 生成链接 → 推送代码 → 等部署。
每次都是这样。写作 10 分钟，发布折腾 30 分钟。
我就想：能不能说一句”把这篇文章发出去”，剩下的事情全自动完成？
后来，我还真做到了。
先说结果
现在我在终端里对 Claude Code 说一句话：
“把这篇文章内容发布”
它会问我要发到哪里（飞书？博客？两个都要？），我勾选完，它就自动把文章分别发到对应的平台。完事之后，给我一张卡片：
🧙🏻♂️ codex公益中转站合集（2026.02.09）
🔗【主】https://my.feishu.cn/wiki/Bqd3w4...
🔗【辅】https://blog.brmys.cn/codex-proxy-collection
📑 收集各类支持Codex CLI的公益中转站API资源
📅 2026.02.09
🏷 #codex #公益站 #API
链接直接可用，格式完好，流程图也在。整个过程不到 10 秒。
下面讲讲我是怎么一步步做到的。
第一个问题：怎么把 Obsidian 笔记发到飞书？
调研：别人是怎么做的
我找到了两个开源项目，它们给了我很大的启发。
第一个：ObShare
这是一个 Obsidian 插件，专门用来把笔记同步到飞书。它的思路是调用飞书的”导入”接口——就像你在飞书里点”导入文档”按钮一样，只不过它帮你自动完成了。
它的优点是快，整篇文档一次性导入，几秒钟就搞定。而且它帮我踩了不少飞书接口的坑，比如某些参数飞书文档里没写清楚，但其实是必须的。
它的局限是，需要打开 Obsidian 的图形界面才能操作，没法在终端里一句话完成。另外，遇到 Mermaid 流程图，它是转成图片上传的——能看，但不是飞书原生的图表，没法在飞书里编辑。
第二个：Feishu-MCP
这是一个让 AI 工具（比如 Claude Code、Cursor）直接操作飞书文档的服务。它可以做到非常精细的控制——一段一段地往飞书文档里写内容，包括标题、段落、代码块，甚至原生的 Mermaid 流程图。
它的优点是精确，什么块类型都能写，流程图是原生的可交互图表。缺点是慢——因为是逐段写入，一篇稍长的文档需要几十次调用，要花好几分钟。
思路：取两者之长
两个项目一个快但不够精细，一个精细但太慢。我就想：能不能让快的先干活，精细的后面补？
于是方案出来了：
- 先用 ObShare 的思路（飞书导入接口），把整篇文章秒级上传到飞书
- 上传之前，把文章里的 Mermaid 流程图代码先抽出来，放个占位符（比如”这里有张流程图”）
- 上传之后，再用 Feishu-MCP 找到那些占位符，一个个替换成原生的流程图
这样就兼顾了速度和质量——没有流程图的文章，秒级完成；有流程图的文章，也只多几秒。
额外处理：清理 Obsidian 的”私货”
Obsidian 笔记里有很多本地才用得到的东西，发到飞书是不需要的：
- Frontmatter（文章开头那段属性信息）：标题、标签、日期这些是给 Obsidian 用的，飞书文档不需要
- 双链关联（
关联主题::、同级::）：这是我本地知识管理用的标注，别人看不懂
所以上传之前，会自动把这些内容剥掉，只留干净的正文。
一个意外收获：更新功能
一开始只做了”新建”——每次上传都是创建一篇新的飞书文档。但用了几次之后发现，我经常会修改 Obsidian 里的文章内容，改完想让飞书那边也同步更新。
如果每次都创建新文档，链接就变了，之前分享出去的链接全部失效。
所以我又加了”更新”功能：如果文章之前已经上传过飞书（Obsidian 里记录了飞书链接），再次同步时就不会创建新文档，而是直接更新原来那篇的内容。链接不变，分享不受影响。
判断逻辑很简单：看文章的属性信息里有没有 feishu_url 字段。有就更新，没有就新建。
第二个问题：怎么把文章发到博客？
我的个人博客（blog.brmys.cn）用的是 Quartz 框架，部署在 Cloudflare Pages 上。发布流程本质上是：
- 把文章文件推送到 GitHub
- Cloudflare 检测到更新，自动构建并部署
所以发博客的核心动作就是 git push。但在推送之前，有几件事需要自动处理：
生成文章链接标识（slug）：博客文章的网址是根据 slug 来的，比如 blog.brmys.cn/obsidian-sync-feishu。如果没有 slug，网址就会变成一长串中文路径，既不美观也不利于分享。所以如果文章没有 slug，需要根据标题自动生成一个简洁的英文短链接。
检查发布状态：只有标记为”已发布”的文章才会出现在博客上。如果文章还是草稿状态，会提醒我确认。
回写博客链接：推送之前，把博客的访问网址写回 Obsidian 文件里，这样在 Obsidian 里就能直接看到博客链接，方便后续查阅。
整个过程只需要说一句”把这篇文章推送到博客”，slug 生成、状态检查、链接回写、git 推送全部自动完成。
第三个问题：能不能一键发到所有平台？
飞书和博客各搞定了，但每次还是要分别说”发到飞书”和”发到博客”，两个指令、两次操作。
我就做了一个”编排层”——内容发布。它的作用很简单：
- 问我要发到哪些平台（可以多选）
- 按顺序依次触发对应的同步功能
- 全部完成后，汇总一张卡片给我
发布顺序也有讲究：先发博客，再发飞书。因为博客发布后会生成博客链接，回写到文章里；然后飞书再上传时，文章内容里就已经包含博客链接了。这样飞书文档里自然就有了博客的跳转链接，一举两得。
整体是怎么串起来的
用一句话总结就是：三个技能，层层叠加。
内容发布（编排层）
├── 同步博客：slug 生成 → 状态检查 → 链接回写 → git push
└── 同步飞书：导入接口秒级上传 → Mermaid 补刀 → 链接回写
每个技能各自独立，可以单独使用（“发到飞书”/“发到博客”），也可以通过编排层一键全发。
这三个技能都是用 Claude Code 的 Skill 机制实现的——本质上就是一份 SOP 文档，告诉 AI 在什么条件下触发、按什么步骤执行。AI 读到这份 SOP 后，就会严格按照流程操作，不需要我每次重复解释该怎么做。
两个开源项目的贡献
在这个过程中，两个开源项目起到了关键作用：
ObShare 帮我验证了飞书导入接口的可行性，它的源码帮我踩掉了好几个飞书 API 的隐藏坑。没有它，我可能要在参数问题上多花几倍的时间。
Feishu-MCP 让 AI 能直接操作飞书文档的每一个块，这是 Mermaid 流程图能变成原生图表的基础。而且它后来也是我实现”更新已有文档”功能的核心能力——清空旧内容、重新写入新内容，都是通过它提供的文档块操作完成的。
写在最后
回头看，整件事的核心思路其实很简单：
- 找到现有工具：不是从零开始造轮子，而是先看看别人怎么解决类似问题
- 取长补短：每个工具都有擅长和不擅长的地方，组合使用比追求单一完美方案更实际
- 逐步叠加：先解决单个平台的同步，再做多平台的编排，一层一层往上搭
最终的效果是：写完文章，说一句话，飞书和博客同时搞定。写作归写作，发布归 AI，各干各的。