# AI 工作流 #02：笔记库的同步与管理 > 我用 Obsidian 加 Fast Note Sync Service（FNS）搭了一个四端共享的笔记库，手机、电脑、浏览器和无界面服务器读写同一个 Vault。服务器端靠自己写的 FastNodeSync-CLI 接进来，博客直接吃这条笔记流，语音输入负责最前面的捕捉。这套库同时是 AI Agent 读素材、写草稿的 Harness。 - 来源: https://blog.lumio.games/posts/ai-workflow-02-note-sync.html - 作者: Lumio - 发布: 2026-06-25 - 更新: 2026-08-17 - 标签: ai, workflow, notes, obsidian, fns --- # AI 工作流 #02：笔记库的同步与管理 **我有一个全平台同步的笔记库**，手机、电脑、网页、服务器（OpenClaw）四端共享同一个 Vault，**实时同步、随时可读写**。 它不只是个人知识库。进了 AI 时代，**这套笔记库同时是我跑 AI Agent 的 Harness**（承载 Agent 读写的那层底座）——Agent 读素材、写草稿、取知识，都直接从这个库进出，不用再搭另一套数据层。想法先记进来，AI 负责后半段整理和输出。 下面按折腾的先后顺序，说说这条链路是怎么一步步搭起来的。 **当前链路总览：** ``` 输入：手机（语音、Obsidian、随手记）/ PC（Obsidian、本地 Markdown） ↓ 实时同步 中枢：FNS Vault（同步、历史、REST/MCP、备份） ↓ 读写 / 输出 输出：服务器（FastNodeSync-CLI）/ Blog（blog.lumio.games）/ NoteGen（AI 整理） ``` ![工作流总览：手机和 PC 在上方向下实时同步进 FNS Vault 中枢，服务器、Blog、NoteGen 在下方从 Vault 读写输出](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/4ff49044-4815-4698-b7f7-b403112dba2a.png) --- ## 实践 1：用 Obsidian 管本地笔记库，装插件接同步 最开始就是用 Obsidian。这工具应该很多人知道，功能强大，笔记圈里算是标配。 我选它没别的原因：笔记就是本地 Markdown 文件，Vault 就是一个普通目录。这点很关键——文件在文件系统里，不是锁在某个私有格式里，后面不管接同步、AI 还是博客，都能直接读。 Obsidian 这侧只需要装一个 [Fast Note Sync For Obsidian](https://github.com/haierkeys/obsidian-fast-note-sync) 插件。平时没有存在感，就在旁边盯着 Vault 的变化，把创建、更新、删除静默推到 Fast Note Sync Service（FNS）服务端。我对它就两个要求：平时别打扰我，出问题时能查日志。都满足。 > **笔记得先是文件，后面才有得谈。Obsidian 管编辑，插件管同步，我不用再记得"手动同步"这回事。** ![Obsidian 里 Fast Note Sync 插件的远端配置页，已连接 FNS 服务](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782384384689-3ae5ed6f-d77d-41b5-981c-527ade99fba2.png) 填上远端地址和授权令牌，服务连上就行。 --- ## 实践 2：用 FNS 做实时同步中枢 真正开始折腾，是因为多端同步太磨人。手机记了一段，电脑上找不到；电脑改完，服务器还是旧文件；浏览器能看，却不能顺手写回去。笔记一旦散掉，后面那些 AI 工作流就全是空中楼阁。 我用的是 [Fast Note Sync Service](https://github.com/haierkeys/fast-note-sync-service)。一开始我只把它当 Obsidian 同步服务，用着用着才意识到它更像一个笔记中枢——Web 管理、实时同步、附件、历史、回收站、分享、REST API、MCP、备份和镜像，全压在服务端这一层。 对我来说，它的价值不止是"多端文件一致"。更关键的变化是：笔记库从一堆文件，变成了一个能被访问的服务。AI 要读写内容走 MCP 或 API，浏览器要看走后台，别的客户端只要接同一个 Vault，就不用再各做一套同步。这个转变我后知后觉，但回过头看是整条链路的转折点。 > **手机、电脑、浏览器、服务器之间不再靠人肉搬运。** FNS 顶在中间，所有客户端围着同一个 Vault 转。 ![FNS 笔记管理后台：Lumio 笔记库的目录浏览界面](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782384323164-b9e599fc-78a5-4cc8-8756-6184f96ba5ae.png) FNS 的 Web 后台：笔记库、目录、附件、历史、分享都在服务端这一层管，不只是 Obsidian 插件的后台。 --- ## 实践 3：用 CLI 把服务器也接进来 这套链路真正变得有意思，是把服务器也接进来之后。OpenClaw 或普通 Linux 机器上跑 Obsidian 不现实，但我的 AI Agent、脚本和发布任务又大多在服务器上。 我想让服务器本身成为一个长期在线的同步节点，随时拿到最新笔记。Obsidian 那套客户端在这里不管用，于是我自己撸了个 CLI 版本：[Go1c/FastNodeSync-CLI](https://github.com/Go1c/FastNodeSync-CLI)。 它跑在命令行里，`run`、`sync`、`pull`、`push`、`status` 这几条命令够用了。常驻模式下先做一次初始同步，再监听本地目录；断网会重连，恢复后补增量。配上 systemd，开机就自己起来，我基本不用管它。 工具本身不花哨，但很实用。服务器上终于有了一份活的笔记库——AI Agent 读素材、脚本处理 Markdown、博客取内容，都不用再等我手动上传。 > **这一下把无 GUI 服务器也拉进了笔记流。** OpenClaw、Linux 机器不再只是运行环境，也能当笔记库节点。 ![服务器上的 AI 助手在 FastNodeSync-CLI 同步出来的 vault 里干活](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782391235960-ff3cce73-4670-47e1-be5b-6099e922269e.png) CLI 的价值在无界面环境里最明显：服务器上的 AI 直接读写 `/opt/data/FastNodeSync-CLI/vault/`，服务器也成了笔记库的一部分。 --- ## 实践 4：让 Blog 吃同一套笔记流 我的博客 [blog.lumio.games](https://blog.lumio.games/) 也接在这条链路上。这解决了我一个老毛病：写博客和记笔记不该是两套系统。 以前素材在笔记里，文章在另一个后台里，发布前要复制、改格式、重新找图。来回几次我就开始拖。现在我更想让文章从笔记库里长出来：原始记录先进 Vault，AI 帮我搭结构，我再补判断、配图、frontmatter。 Orca 那篇就是这么写出来的——先随手记使用体验，再整理成文章，最后才处理 `slug`、`visibility`、`cover`。发布退回成文档流的最后一段，不再是另起炉灶的一摊活。 > **博客不再是个孤立后台。** 笔记、草稿、文章、配图、发布状态，全在同一条内容链路里。 ![Lumio 后台笔记库界面：vault 下的 blog、Doc、Work 目录，顶部带同步内容按钮](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782384618616-ad71593c-ad7b-410a-94a8-9e7bb4afb12c.png) 博客是笔记管理链路的输出端。 --- ## 实践 5：二开 NoteGen，做更轻的记录入口 Obsidian 适合认真写、认真整理，但拿它随手记还是重了点。打开笔记库、翻目录、想标题、调格式，这几个动作一上来就把口述的节奏拖慢了。 所以 2026 年 6 月我开始基于 [NoteGen](https://github.com/codexu/note-gen) 做二开。吸引我的点很直白：先记录，后整理。文本、语音、截图、链接、文件先一股脑丢进去，AI 再慢慢把它们生成 Markdown、总结、文章或知识库条目。 我的 fork [Go1c/note-gen（feat/fast-note-sync 分支）](https://github.com/Go1c/note-gen/tree/feat/fast-note-sync)已经在接 FNS。接上之后 NoteGen 就不是又一个孤岛，而是同一套 FNS Vault 的一个入口。这块还在试，但方向我挺确定：我负责把想法说出来，AI 负责把材料收拾成能存、能搜、能发的东西。 > **分工慢慢清楚了：Obsidian 管深度整理，NoteGen 管轻量捕捉，** 两头最后都回到同一个笔记库。 ![NoteGen 记录与 AI 整理界面：左侧笔记目录，中间新手引导，右侧把口述记录整理成结构化内容](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782389081800-1609b05f-8779-43e7-87e4-96802d8743d5.png) NoteGen 这张图体现"记录先发生，整理后发生"。 --- ## 实践 6：用豆包输入法做记录入口 最后这个工具最小，但对我影响最大：豆包输入法。 我现在很多记录都靠语音。想法刚冒出来的时候是口语，不是文章。以前我会想着等有空再写，可真有空了，脑子里只剩一个模糊主题。现在我先把它说出来，顺序乱、用词糙都无所谓，先留住。 语音输入把第一步的成本压到了几乎为零。只要文本先进了笔记库，后面 AI 整理、同步、发布才有得接。反过来想，入口要是太重，前面那一串 FNS、CLI、Blog、NoteGen 的能力其实都用不上——你根本懒得开始记。 > **记录不再绑在"坐下来写"这件事上。** 先用口述把现场想法接住，结构的事交给后面的工具。 ![豆包输入法 macOS 版本，语音识别能力 + 拼音输入候选](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/orca-paste-1782385046797-61c17956-93a8-41d2-ab92-43cc082c644f.png) 真正的入口是语音记录。 --- ## 回头看，我其实在补几个断点 把这六步串起来看，我发现自己一直在做的不是"搭系统"，而是补一个个断掉的地方。想法冒出来到记进笔记，中间断过；手机记的和电脑看的，断过；服务器想用笔记，断过；写好的笔记要变成文章，又断过。每补上一个，下一个断点才暴露出来——它们是被我一个一个踩出来的，不是一开始就规划好的。 语音输入接住了第一下，Obsidian 插件加 FNS 把几个设备拉到同一个 Vault，CLI 让没界面的服务器也能进来，Blog 直接吃笔记流，NoteGen 和 AI 负责把粗料收拾成型。说起来是六七个工具，做的其实是同一件事：别让内容在某一环掉地上。 我最开始以为自己缺的是一个更强的笔记软件。折腾到现在才明白，我要的是一条不断的笔记流。软件可以换，入口可以换，服务端以后还能加东西，唯一不能动的是——所有内容最后都得回到同一个地方。 --- ## 相关仓库 - [haierkeys/fast-note-sync-service](https://github.com/haierkeys/fast-note-sync-service)：FNS 服务端，负责实时同步、Web 管理、REST/MCP、历史、分享和备份。 - [haierkeys/obsidian-fast-note-sync](https://github.com/haierkeys/obsidian-fast-note-sync)：Obsidian 客户端插件，负责把 Vault 里的变化同步到 FNS。 - [Go1c/FastNodeSync-CLI](https://github.com/Go1c/FastNodeSync-CLI)：无界面服务器同步客户端，适合 OpenClaw 和 Linux 常驻任务。 - [codexu/note-gen](https://github.com/codexu/note-gen)：开源 NoteGen，上游是"先记录、后整理"的轻量 AI 笔记工具。 - [Go1c/note-gen（feat/fast-note-sync）](https://github.com/Go1c/note-gen/tree/feat/fast-note-sync)：我的 NoteGen fork，给它接上 FNS 同步，让记录入口也回到同一个 Vault。 --- 这套流程还在变，估计明年再看又是另一个样子。但有一点我现在挺确定：别一上来就追求完美笔记，先让记录这件事自然发生再说。 等入口轻到你不假思索就会去记，笔记库又能默默同步、被 AI 读写、往博客输出——这几环接上之后，个人知识库才真的开始像个能天天用的东西，而不是又一个建好就吃灰的系统。 --- 欢迎大家交流。 ![LumioGames-AI 交流群二维码](https://s3.lumio.games/lumio-blog/blog/my-ai-workflow/IMG_6783.JPG)