用一个 Obsidian Vault 管理多个 Web 项目 CMS：真实预览、单一事实源与 Git 边界

同时维护两个、三个甚至更多网站时，最容易失控的往往不是写作本身，而是内容周围那一圈事情：每个项目各有一套编辑入口、图片目录、预览方式、AI 配置和 Git 流程。把文章复制来复制去，短期看似省事，几周后却常常说不清哪一份才是最新版。

我现在使用的是一套本地优先的做法：让每个网站继续保有自己的仓库、内容、图片、构建和部署；再用一个 Obsidian Vault 作为统一的内容工作台。它不替代网站，也不接管 Git，只让编辑、浏览和审核这一步更顺手。

为了把“在 Obsidian 里看到真实网页”变成可复用的能力，我也把预览工具开源了：CMS Live Preview。它是一个桌面端、本地优先的 Obsidian 插件：在目前明确支持的内容目录中，它能找到文章对应的本地网页路由、检查预览服务状态，并在你主动点击后启动或停止配置好的开发服务。项目仍处于早期版本，适用范围是透明且有限的；这正是我希望它保持的样子。

一个 Vault 应该是工作台，而不是第二个内容仓库

这套工作流的关键不是把所有项目“收编”到一个目录，而是先把职责分开。

位置	应该负责什么
Obsidian Vault	浏览、编辑、检索和内容审核
各项目 Git 仓库	真实的 MDX、图片、代码与历史记录
项目本地开发服务	渲染真实路由、组件、样式和 SEO 结构
各项目的 Git/CI/部署流程	测试、提交、发布与回滚

这样看，Obsidian 不是新的 CMS 数据库，而是进入现有 CMS 的一个更舒服的入口。内容的“真相”始终留在原项目里。

用符号链接连接项目，不复制项目

假设你有两个网站，它们本来就位于两个独立的 Git 仓库中，各自有不同的内容目录、图片目录和构建命令。不要把它们再复制到 Vault；只需把真正需要编辑的目录以符号链接挂进去。

Content-CMS/
├── Project-A  → Project A 的内容目录
├── Project-B  → Project B 的内容目录
└── assets/
    ├── project-a → Project A 的图片目录
    └── project-b → Project B 的图片目录

符号链接看起来像文件夹，打开后也像文件夹，但它不保存另一份内容。它只是告诉系统：当你访问这里时，去原来的真实路径读取文件。

因此，当你在 Obsidian 中打开 Project-A/en/example.mdx，改标题、调整段落或插入图片时，改动直接落在 Project A 的 Git 仓库中。没有导出，也没有回写，更不会多出一份等待同步的副本。

这就是“统一入口，单一事实源”的实际含义。

为什么不要把内容复制进 Obsidian

常见方案看起来都能工作，但它们承担的长期成本并不一样。

做法	是否复制文章	是否容易漂移	Git 是否直接识别改动	长期成本
每个项目一个 Vault	否	否	是	上下文切换多
复制一份到知识库	是	是	否	需要不断确认版本
导出或同步工具	通常会	取决于规则	不直接	需要维护同步规则
一个 Vault + 符号链接	否	否	是	最轻量

复制内容的真正问题，不是多占了一点磁盘空间，而是它把“写好一篇文章”变成了“管理几份文章之间的关系”。原本你只需要判断内容是否足够好；复制之后，还要先判断哪一份才是真的。

所以这里有一个看起来反直觉、却很实用的结论：

多项目内容管理里，最好的同步，往往是不需要同步。

预览必须交给真实网站，而不是让 Obsidian 模拟网站

能在 Obsidian 里读到 MDX，并不等于看到了用户最终会看到的页面。真实页面还包含项目自己的组件、样式、图片处理、路由、语言规则和 SEO 结构。让 Obsidian 去模拟这些事情，只会把一个轻量编辑器重新做成一套不完整的网站运行时。

更可靠的流程是：

在 Obsidian 编辑当前 MDX
        ↓
识别项目与文章 slug
        ↓
打开该项目已经运行的本地预览路由
        ↓
在 Obsidian 标签页或系统浏览器审核真实页面

开源的 CMS Live Preview 就放在这两个步骤之间。当前版本会为已支持的 Glowise 与 Bible Note 内容目录映射文章路由，检查健康状态，并把 Start、Stop、Refresh、Open、服务日志放在同一个预览界面中。它只会在你明确点击 Start 后执行配置好的本地命令；如果页面不适合嵌入，仍可回退到系统浏览器。

这种边界很重要：插件负责把你带到真实预览，而不是接管项目的运行方式。支持范围、安装步骤和配置要求都以仓库说明为准。

在 Vault 里使用 AI，但不要把所有能力都塞进去

如果你在 Vault 中使用 Codex、Claude 或其他 Agent，很容易产生一个冲动：既然机器上有很多 Skill，不如全部加载。实际体验通常恰好相反——Agent 还没开始处理文章，有限的上下文已经被一大堆无关说明占满。

我更推荐白名单：只保留这一类内容工作真正需要的能力。

Obsidian Markdown
Obsidian CLI
网页搜索与阅读
PDF 阅读
Blog Writer

同样不要再复制一份 Skill 到每个 Vault。直接引用同一套源文件即可：规则升级一次，下一次打开时自然生效；不相关的能力则不占上下文。

统一编辑，不等于统一 Git

最后有三个边界不能省略。

第一，不要把整个项目仓库都挂进 Vault。通常只需要内容目录和必要的图片目录；node_modules、构建产物和缓存文件只会增加噪音。

第二，Git 仍然属于原项目。即使你从同一个 Vault 编辑多个网站，测试、提交、预览、部署和回滚也必须回到各自仓库的流程中完成。

第三，Obsidian 没有立即看到新挂载目录时，先刷新索引或重新打开 Vault。多数情况下不是数据丢失，而是文件监听还没有更新。Vault 自己的 .obsidian 配置也应按项目需要加入 .gitignore。

结语

一个 Vault 并不会把多个项目变成一个项目。它做的只是给内容层一个统一而舒适的界面，同时不掩盖每个网站各自的代码、运行时和部署边界。

让项目继续做项目，让 Git 继续管理版本，让网站继续负责真实渲染；Obsidian 则专注于它最擅长的部分：成为一个随时可写、容易检索、适合审核的内容入口。若你也在维护代码驱动的 CMS，可以从 CMS Live Preview 开始了解这套工作流。