我在 VPS 上用 Claude Code 的频率，比在本地 Windows 上高得多。但 Obsidian 是个 GUI 应用，没法装在无头服务器上——vault 本体只能待在本地。结果是写笔记的地方和攒沉淀的地方分了家：VPS 上跑出来的一堆有价值的东西，没有一个顺手的地方落地。
架构：Git 串起两端
思路很直接：vault 本体放本地，靠 Git 做同步。
- 本地 Windows：Obsidian 装了 Git 插件，启动时自动 pull，每 10 分钟自动 commit/push。人完全不用管 git，插件在后台默默做。
- GitHub 私有仓库：中转站，两端都认它。
- VPS：
git clone下来一份，不装 Obsidian 本体。碰 vault 前 pull 一下，改完 commit，会话收尾时 push 掉——不长期攒着不推，不然本地那边的自动提交会把冲突窗口越拉越大。
两端的目录结构特意对齐成一致的样子，vault 根目录就是 Git 仓库根目录，没有本地一层、VPS 又是另一层嵌套的问题。
一个刻意的不对称：技能拆开装
Obsidian 生态里有一批处理 .md/.base/.canvas 文件格式的技能，这些是纯文件操作，不需要 Obsidian 进程在跑，两端都装了。
但还有一个 obsidian-cli，只在本地装。原因是它不是真正意义上的命令行工具——它需要连一个正在运行的 Obsidian 实例才能工作，本质是通过 IPC 跟活的 GUI 进程说话。VPS 是无头机器，没有 GUI 进程可连，装了也是摆设。
所以拆成两条线：文件格式类技能给两端，交互式 CLI 只给本地，靠 Git 仓库串联而不是在 VPS 上硬装一个 Obsidian 本体。
AI 写、人审的工作流
光有同步管道还不够——真正的问题是：VPS 端 Claude Code 做完一段有沉淀价值的工作后，应该主动写进 vault，而不是只留在对话里；但人也不想每次都盯着看它写了什么。
搭了一套显式的审核队列：
📥 Inbox/：AI 写的草稿先落地在这里，frontmatter 必须带status: draft、source（标注是 VPS 会话还是本地写的）、tags。🗺️ MOC/：主题枢纽笔记（Map of Content），审核通过归位时按主题建一个，只放链接不放内容，负责把散落的原子笔记串成可导航的知识地图。📋 模板/原子笔记模板.md：新笔记统一的 frontmatter 模板，一篇一件事。待审核队列.base：vault 根目录下用 Obsidian Bases 做的一个视图，过滤status == "draft"，按天数排序。人要审核，打开这一个文件就够了，不用满目录翻。📖 知识库说明.md：给人和未来的 AI 会话看的整体说明，把以上几条约定串起来，避免下次开新会话时重新解释一遍。
人审完一篇笔记，把 status 改成 reviewed，挪出 Inbox，就算走完一轮。
为什么要做成显式状态机
最初的念头是”AI 写完随手扔进某个文件夹，人有空自己翻”——但这撑不住。文件夹里新旧笔记混在一起，人没法一眼看出”这些是新写的、还没看过的”。
用 status 属性 + Base 视图做成一个明确的审核队列界面，比隐式约定靠谱得多：状态写在 frontmatter 里，机器能过滤，人一打开 base 就是一个待办列表，不需要记忆或猜测。
这套结构目前还在磨合——💡 碎片想法 文件夹建了还没真正用起来，Git 偶尔会因为两端同时改到同一篇笔记产生冲突，需要手动解决。但至少现在，AI 产出的东西有了一条从落地到复核的清晰路径，不再是写完就沉进对话历史里，没人看得到。