AI 工作流 #02：打造最强全平台笔记工作流#

我有一个全平台同步的笔记库，手机、电脑、网页、服务器（龙虾）四端共享同一个 Vault，实时同步、随时可读写。

它不只是个人知识库。进了 AI 时代，这套笔记库同时是我跑 AI Agent 的 Harness——Agent 读素材、写草稿、取知识，都直接从这个库进出，不用再搭另一套数据层。想法先记进来，AI 负责后半段整理和输出。

下面按折腾的先后顺序，说说这条链路是怎么一步步搭起来的。

当前链路总览：

输入：手机（语音、Obsidian、随手记）/ PC（Obsidian、本地 Markdown）
              ↓ 实时同步
中枢：FNS Vault（同步、历史、REST/MCP、备份）
              ↓ 读写 / 输出
输出：服务器（FastNodeSync-CLI）/ Blog（blog.lumio.games）/ NoteGen（AI 整理）

实践 1：用 Obsidian 管本地笔记库，装插件接同步#

最开始就是用 Obsidian。这工具应该很多人知道，功能强大，笔记圈里算是标配。

我选它没别的原因：笔记就是本地 Markdown 文件，Vault 就是一个普通目录。这点很关键——文件在文件系统里，不是锁在某个私有格式里，后面不管接同步、AI 还是博客，都能直接读。

Obsidian 这侧只需要装一个 Fast Note Sync For Obsidian 插件。平时没有存在感，就在旁边盯着 Vault 的变化，把创建、更新、删除静默推到 FNS 服务端。我对它就两个要求：平时别打扰我，出问题时能查日志。都满足。

笔记得先是文件，后面才有得谈。Obsidian 管编辑，插件管同步，我不用再记得"手动同步"这回事。

填上远端地址和授权令牌，服务连上就行。

实践 2：用 FNS 做实时同步中枢#

真正开始折腾，是因为多端同步太磨人。手机记了一段，电脑上找不到；电脑改完，服务器还是旧文件；浏览器能看，却不能顺手写回去。笔记一旦散掉，后面那些 AI 工作流就全是空中楼阁。

我用的是 Fast Note Sync Service。一开始我只把它当 Obsidian 同步服务，用着用着才意识到它更像一个笔记中枢——Web 管理、实时同步、附件、历史、回收站、分享、REST API、MCP、备份和镜像，全压在服务端这一层。

对我来说，它的价值不止是"多端文件一致"。更关键的变化是：笔记库从一堆文件，变成了一个能被访问的服务。AI 要读写内容走 MCP 或 API，浏览器要看走后台，别的客户端只要接同一个 Vault，就不用再各做一套同步。这个转变我后知后觉，但回过头看是整条链路的转折点。

手机、电脑、浏览器、服务器之间不再靠人肉搬运。 FNS 顶在中间，所有客户端围着同一个 Vault 转。

FNS 的 Web 后台：笔记库、目录、附件、历史、分享都在服务端这一层管，不只是 Obsidian 插件的后台。

实践 3：用 CLI 把服务器也接进来#

这套链路真正变得有意思，是把服务器也接进来之后。OpenClaw 或普通 Linux 机器上跑 Obsidian 不现实，但我的 AI Agent、脚本和发布任务又大多在服务器上。

我想让服务器本身成为一个长期在线的同步节点，随时拿到最新笔记。Obsidian 那套客户端在这里不管用，于是我自己撸了个 CLI 版本：Go1c/FastNodeSync-CLI。

它跑在命令行里，run、sync、pull、push、status 这几条命令够用了。常驻模式下先做一次初始同步，再监听本地目录；断网会重连，恢复后补增量。配上 systemd，开机就自己起来，我基本不用管它。

工具本身不花哨，但很实用。服务器上终于有了一份活的笔记库——AI Agent 读素材、脚本处理 Markdown、博客取内容，都不用再等我手动上传。

这一下把无 GUI 服务器也拉进了笔记流。 OpenClaw、Linux 机器不再只是运行环境，也能当笔记库节点。

CLI 的价值在无界面环境里最明显：服务器上的 AI 直接读写 /opt/data/FastNodeSync-CLI/vault/，服务器也成了笔记库的一部分。

实践 4：让 Blog 吃同一套笔记流#

我的博客 blog.lumio.games 也接在这条链路上。这解决了我一个老毛病：写博客和记笔记不该是两套系统。

以前素材在笔记里，文章在另一个后台里，发布前要复制、改格式、重新找图。来回几次我就开始拖。现在我更想让文章从笔记库里长出来：原始记录先进 Vault，AI 帮我搭结构，我再补判断、配图、frontmatter。

Orca 那篇就是这么写出来的——先随手记使用体验，再整理成文章，最后才处理 slug、visibility、cover。发布退回成文档流的最后一段，不再是另起炉灶的一摊活。

博客不再是个孤立后台。 笔记、草稿、文章、配图、发布状态，全在同一条内容链路里。

博客是笔记管理链路的输出端。

实践 5：二开 NoteGen，做更轻的记录入口#

Obsidian 适合认真写、认真整理，但拿它随手记还是重了点。打开笔记库、翻目录、想标题、调格式，这几个动作一上来就把口述的节奏拖慢了。

所以我最近在基于 NoteGen 做二开。吸引我的点很直白：先记录，后整理。文本、语音、截图、链接、文件先一股脑丢进去，AI 再慢慢把它们生成 Markdown、总结、文章或知识库条目。

我的 fork Go1c/note-gen（feat/fast-note-sync 分支）已经在接 FNS。接上之后 NoteGen 就不是又一个孤岛，而是同一套 FNS Vault 的一个入口。这块还在试，但方向我挺确定：我负责把想法说出来，AI 负责把材料收拾成能存、能搜、能发的东西。

分工慢慢清楚了：Obsidian 管深度整理，NoteGen 管轻量捕捉， 两头最后都回到同一个笔记库。

NoteGen 这张图体现"记录先发生，整理后发生"。

实践 6：用豆包输入法做记录入口#

最后这个工具最小，但对我影响最大：豆包输入法。

我现在很多记录都靠语音。想法刚冒出来的时候是口语，不是文章。以前我会想着等有空再写，可真有空了，脑子里只剩一个模糊主题。现在我先把它说出来，顺序乱、用词糙都无所谓，先留住。

语音输入把第一步的成本压到了几乎为零。只要文本先进了笔记库，后面 AI 整理、同步、发布才有得接。反过来想，入口要是太重，前面那一串 FNS、CLI、Blog、NoteGen 的能力其实都用不上——你根本懒得开始记。

记录不再绑在"坐下来写"这件事上。 先用口述把现场想法接住，结构的事交给后面的工具。

真正的入口是语音记录。

回头看，我其实在补几个断点#

把这六步串起来看，我发现自己一直在做的不是"搭系统"，而是补一个个断掉的地方。想法冒出来到记进笔记，中间断过；手机记的和电脑看的，断过；服务器想用笔记，断过；写好的笔记要变成文章，又断过。每补上一个，下一个断点才暴露出来——它们是被我一个一个踩出来的，不是一开始就规划好的。

语音输入接住了第一下，Obsidian 插件加 FNS 把几个设备拉到同一个 Vault，CLI 让没界面的服务器也能进来，Blog 直接吃笔记流，NoteGen 和 AI 负责把粗料收拾成型。说起来是六七个工具，做的其实是同一件事：别让内容在某一环掉地上。

我最开始以为自己缺的是一个更强的笔记软件。折腾到现在才明白，我要的是一条不断的笔记流。软件可以换，入口可以换，服务端以后还能加东西，唯一不能动的是——所有内容最后都得回到同一个地方。

相关仓库#

• haierkeys/fast-note-sync-service：FNS 服务端，负责实时同步、Web 管理、REST/MCP、历史、分享和备份。
• haierkeys/obsidian-fast-note-sync：Obsidian 客户端插件，负责把 Vault 里的变化同步到 FNS。
• Go1c/FastNodeSync-CLI：无界面服务器同步客户端，适合 OpenClaw 和 Linux 常驻任务。
• codexu/note-gen：开源 NoteGen，上游是"先记录、后整理"的轻量 AI 笔记工具。
• Go1c/note-gen（feat/fast-note-sync）：我的 NoteGen fork，给它接上 FNS 同步，让记录入口也回到同一个 Vault。

这套流程还在变，估计明年再看又是另一个样子。但有一点我现在挺确定：别一上来就追求完美笔记，先让记录这件事自然发生再说。

等入口轻到你不假思索就会去记，笔记库又能默默同步、被 AI 读写、往博客输出——这几环接上之后，个人知识库才真的开始像个能天天用的东西，而不是又一个建好就吃灰的系统。

欢迎大家交流。