从本地文件夹到云端：我重新整理了个人 AI 知识库

月鹿造物 · AI 知识库升级

这套知识库不是最近才开始搭的。之前我写过怎么从素材库里找选题，也写过怎么管理个人知识库。那时候，我已经在电脑里建了一个名叫“月鹿的思考”的本地文件夹，把文章、素材、项目文档和历史对话都放进去，再让 WorkBuddy 或 Codex 直接读取这个文件夹。收集、整理、找选题和写文章，这套流程已经能够运转。

真正让我重新折腾它的，是笔记本电脑的键盘坏了，需要把整台电脑送去维修。

我有点担心：如果整机维修时电脑里的本地文件夹出了问题，这些年积累下来的文章、素材、项目记录和历史对话会不会一起丢掉？工作流坏了还可以重新搭，但内容没了，很难再原样找回来。所以我先想找一种自动同步云端的办法，再顺着想到：既然文件已经上云，能不能接给 NotebookLM 直接读取？

我当时觉得这条路应该挺顺。文件放进 Google Drive，再接一个能读资料的 AI，不就完了吗？

实际做起来比我想得复杂。我先后试了 NotebookLM、Obsidian 和 ima知识库，才发现云盘同步、管理文件和让 AI 读取资料，根本不是同一件事。

CONTENTS · 本文目录

1云盘同步，不等于知识库同步

2先把本地文件夹清干净

3Obsidian 功能很多，但没接上我需要的手机收集流程

4ima知识库补上了手机和 AI 检索这一环

5Codex 和 WorkBuddy，负责整理本地文件夹

6我最后保留下来的工作流

1云盘同步，不等于知识库同步

我先选了 Google Drive。它就是 Google 的网盘，我手头的账号有大约 5TB 可用额度，基本不需要再花钱。更重要的是，安装桌面客户端以后，可以把“月鹿的思考”这个本地文件夹和网盘连接起来。以后我在文件夹里新增或修改内容，它会在后台自动同步到 Google Drive，不需要每次手动上传。

Google Drive 自动同步本地文件夹并显示同步完成

其实在之前那套本地工作流里，AI 给过我的免费备份方案是同步到 GitHub，我当时也照着做了。可我的知识库每天都会增加和修改很多内容，GitHub 里也跟着出现大量更新。直到这次重新梳理工作流，我才发现：这个建议放在我的场景里并不合适。GitHub 更适合管理代码和版本，像“月鹿的思考”这种频繁变化的文件夹，直接交给 Google Drive 自动同步更省事。

这里不一定非要用 Google Drive。国内云盘也可以承担备份这件事，主要看自己已经在用哪个、剩余空间有多少，以及同步本地文件夹方不方便。

文件开始往 Google Drive 同步以后，我想到了 NotebookLM。

这个工具我很早以前就用过。当时主要拿它分析基金资料，也试过添加视频，体验还不错。现在它又能生成播客、视频和思维导图，还可以从 Google Drive 添加资料。我当时以为，只要选中网盘里的知识库文件夹，里面的资料就能持续同步到 NotebookLM，备份和内容利用也就自然接在了一起。

实际操作后才发现，它所谓的“从 Google Drive 添加资料”，只是让我按文件选择并添加来源。即使一次可以勾选多份文件，也不能直接接入整个文件夹；本地文件夹后来新增或修改的内容，也不会自动更新到 NotebookLM。我的资料有几千份，如果每次都要手动挑选和补充，这条路就不适合我，只能换一个方案。

NotebookLM 可以多选文件，但不能直接添加整个文件夹

Google Drive 继续负责自动同步并保留云端副本，NotebookLM 适合少量精选资料，但不适合我这套不断增长的文件夹知识库。

2先把本地文件夹清干净

继续往下看，我发现自己的文件夹也不够干净。

“月鹿的思考”里不只有文章和知识文档，还混着 node_modules、缓存、日志、锁文件和大体积媒体。这些东西对项目运行有用，放进云盘和知识库却没有必要。它们不但占空间，还会让真正有价值的资料被淹没。

所以我和 Codex 先做了一次物理分流，在原目录旁边新建了一个：

月鹿的思考_DevEnv

我不是把整个项目都搬走，而是把一个项目拆成两层。“月鹿的思考”继续保留文章、PDF、设计图、需求说明、核心源码和复盘，这些内容既要长期保存，也值得以后被 AI 读取。DevEnv 只接收依赖包、编译产物、缓存、日志、锁文件和大体积运行素材，它们服务于项目运行，却不属于知识语料。

之所以要做物理分流，是因为 Google Drive 会同步整个指定文件夹。只要工程文件还混在“月鹿的思考”里，它们就会一起被传到云端。分开以后，Google Drive 只同步“月鹿的思考”，同级的 DevEnv 留在电脑上，不进入云盘，也不交给 AI 知识库。

独立的 Vibe Coding 项目仍然可以使用 Git 和 GitHub，只是不再用 Git 备份整个知识库。

分完以后，云盘里终于不会再混着一大堆运行文件。哪些内容值得长期留，最好还是在交给 AI 之前先想清楚。

3Obsidian 功能很多，但没接上我需要的手机收集流程

文件整理完以后，我装了 Obsidian。

第一次打开关系图谱时，不少文件挤在一起，文件名又有很多是过去随手记的，几乎看不出关系。我这才发现，图谱能把连接展示出来，但前提是文件名、分类和链接本身已经整理清楚。

后来我把现有资料整理成一份知识图谱概览，原来分散在不同文件夹里的内容，终于可以按分类和主题放在一起看。

Obsidian中的月鹿知识库分类与知识图谱概览

后来我又试了 Bases、Properties、Web Clipper 和 Defuddle。它们可以整理属性、清洗网页并保存 Markdown。尤其是 Web Clipper，可以把网页正文和图片直接保存成 Obsidian 里的本地笔记，这个功能我当时觉得还不错。

Obsidian Web Clipper把网页正文和图片保存到本地

不过后来我发现，ima知识库也能收藏网页，而且手机端用起来更方便。这样一比较，网页收藏就不再是我必须保留 Obsidian 的理由了。Obsidian 仍然能直接读取电脑里的文件，还可以做双向链接、Canvas 和数据库式视图。

它很适合做本地工作台，插件生态也很丰富。只是我现在更需要一条连接手机收集和 AI 检索的路径，所以它没有进入最后的主流程。

Obsidian 前几个月很火，但一个工具有没有名气，并不是我一定要用它的理由。不用某个热门工具，也不代表自己落伍了。更实际的办法，是把它放进自己的工作流程里试一遍：能不能解决眼前的问题，用起来顺不顺手。适合自己的就留下，不适合的暂时放下，不必因为别人都在用，就勉强改变自己的习惯。

4ima知识库补上了手机和 AI 检索这一环

后来我试了 ima知识库。

它可以直接上传整个文件夹，手机上也能收藏网页和 PDF。我从手机上传了一本 PDF，又从电脑“课程包”里上传了两份，同时在“月鹿的思考”保留原件。手机负责随时收集资料，电脑继续保留原始文件，需要找资料时再去 ima知识库里问。这就是我最后选择它的原因。

手机上传资料后，电脑端 ima知识库同步可见

这里的“同步”是指手机上传的资料能在电脑端 ima知识库里看到，并不是文件会自动下载到“月鹿的思考”本地文件夹。不过，安装 ima Skill 以后，Codex 可以搜索和读取 ima知识库，把手机上传的文件下载到本地文件夹，再由 Google Drive 自动同步并保留云端副本。

反过来也一样。电脑里的文件整理好以后，Codex 也可以通过 ima Skill 上传到 ima知识库。这样两边的资料都能搬运，只是它并非实时双向同步：什么时候取回、什么时候上传，仍然需要我来决定。

5Codex 和 WorkBuddy，负责整理本地文件夹

几种工具来回测试以后，这套流程的分工也逐渐清楚了：Google Drive 管自动同步和云端副本，ima知识库管收集和检索，文件本身还是在本地文件夹里处理。

这里不限定某一个工具。WorkBuddy 和 Codex 都能读取本地文件夹，帮我找资料、写文章和整理内容。这次升级主要由 Codex 完成：修改 Markdown、分类文件、通过 ima Skill 在知识库和本地文件夹之间搬运资料，并把工程杂质分流到 DevEnv。

6我最后保留下来的工作流

从电脑开始时，我这样做：

写文章 / 做项目 / 整理资料

→ Codex 或 WorkBuddy 创建、修改和分类

→ 保存进“月鹿的思考”

→ Google Drive 自动同步并保留云端副本

→ 稳定内容由 Codex 通过 ima Skill 上传到 ima知识库

从手机开始，则是另一条路：

手机发现网页或 PDF

→ 先收藏到 ima知识库

→ 用 ima知识库检索和提问

→ 确定要长期保留的资料由 Codex 通过 ima Skill 取回本地文件夹

→ 进入“月鹿的思考”并由 Google Drive 自动同步到云端

小鹿管理电脑端与手机端的双向知识库工作流

这套流程仍然需要手动操作，做不到完全自动。ima知识库和本地文件夹之间，什么时候“收回来”、什么时候“传上去”，仍然要由我判断。

我觉得人工最该介入的是信息源。每个人关心的领域和判断标准都不一样，哪些内容值得进入长期知识库，不能完全交给工具决定。至于改名、分类、去重和搬运这些重复动作，则可以交给 AI。等资料积累起来以后，再让 AI 帮我寻找关联、提炼线索，把原本躺在文件夹里的内容真正利用起来。

笔记本电脑送修前，我想解决的只是文件别丢。折腾一圈后，云端副本有了，手机收集也接上了，原件还在电脑里的本地文件夹中。

这套工作流未必是最好的版本，只是目前比较适合我的版本。工作流也不是一开始设计好，就永远不再改变。真正重要的是先用起来，在实际使用中发现哪里麻烦、哪里重复、哪里容易丢东西，再一点点调整。与其一开始就追求完美，不如先让它跑起来，再不断迭代。

“

与其一开始就追求完美，不如先让工作流跑起来，再在真实使用中不断迭代。

— 月鹿造物 —