用 Obsidian 写博客：我的发布流程改造

背景

这个博客从 2017 年开始，经历了 Hexo → Astro 的迁移，部署方式也从手动到 Travis CI 再到 GitHub Actions。工具链一直在变，但有一个问题始终没解决好：写作体验不够好。

之前的流程是这样的：

1. 在 VS Code 里打开博客仓库
2. 手动创建 Markdown 文件，复制粘贴 front matter 模板
3. 写完后在终端 git add / commit / push
4. 等 CI 构建部署

问题很明显：写一篇博客要同时打开编辑器和终端，写作环境和日常笔记是割裂的。我平时用 Obsidian 记笔记，但博客内容却在另一个地方，两边的内容没有打通。

为什么选择 Obsidian + Astro

一开始我考虑过直接换成 Quartz——一个专门为 Obsidian 设计的静态站点生成器，原生支持 wikilinks、双向链接、图谱视图。但它的问题是主题生态很有限，视觉风格偏 wiki/数字花园，不像传统博客。

最终的决定是：Obsidian 负责写作，Astro 负责构建发布。各做各擅长的事。

现在的流程

改造后，发布一篇博客只需要三步：

1. 在 Obsidian 里写文章（Blog/drafts/ 目录）
2. 写完后 Cmd+P → “发布当前文章到博客”
3. 完成。剩下的全自动。

插件在背后做了这些事：

• 把 Obsidian 的 ![[image.png]] 转成标准 Markdown 图片语法
• 把 [[双链]] 降级为纯文本
• 移除 draft: true
• 复制图片到博客仓库
• 把源文件从 drafts/ 移到 posts/
• Git commit + push
• CI 自动构建部署

核心设计：Obsidian 是唯一真源

整个方案最重要的一个决定是：Obsidian 是内容的唯一真源，博客仓库里的 Markdown 只是发布产物。

这意味着：

• 改文章必须回 Obsidian 改，然后重新发布
• 博客仓库里的 src/data/blog/*.md 不手工编辑
• 所有历史文章也迁移到了 Obsidian vault 中

这个决定让整个流程变得很清晰：只有一个地方管内容，不会出现”这篇文章到底以哪边为准”的问题。

技术实现

技术上其实很简单，就三个东西：

1. 发布脚本 (scripts/obsidian-publish.mjs)

一个 Node.js 脚本，读取 Obsidian 的 Markdown 文件，校验 front matter，转换语法，复制图片，输出到 Astro 的内容目录。通过 .env 文件配置 vault 路径。

2. Obsidian 插件 (blog-publish)

一个极简的 Obsidian 插件，注册一个命令，调用发布脚本，然后自动 git commit + push。总共不到 100 行代码。

3. 目录约定

Obsidian Vault/Blog/
├─ drafts/      ← 正在写的草稿
├─ posts/       ← 已发布的文章
├─ assets/      ← 图片
└─ templates/   ← front matter 模板

就这些。没有复杂的配置，没有数据库，没有构建管道。

回头看

从 2017 年折腾 GitHub Webhook 自动部署，到现在 Obsidian 一键发布，九年过去了，工具越来越顺手。但写博客这件事本身，还是得靠自己坐下来写。

工具解决不了”没东西可写”的问题，但至少可以让”想写的时候”少一些阻力。