从 Quiver 到 Obsidian：我的技术笔记迁移和 AI 整理实践

我用 Quiver 记技术笔记快 10 年了。

这些年陆续记下了 Java、Python、MySQL、Linux、算法、软考等内容，数量接近一千篇。刚开始笔记不多，Quiver 的「笔记本 + 标签」很好用：内容放进对应分类，需要时再按目录或者全局找出来。

但笔记积累到一定数量后，原来的分类方式开始失效。

比如算法相关的内容，被我分别放在 python算法、剑指offer-python 和 算法 里；和高并发有关的内容，则散落在 MySQL、Redis、消息队列和分布式事务等不同目录中。单看每个目录都没问题，真正要解决一个具体问题时，却经常需要在多个地方来回翻找。

另一个问题是旧笔记越来越多。很多内容早已过时，但逐篇检查和整理的成本很高。它们还在知识库里，却很少再被找到，慢慢变成了「数字垃圾」。

我最终决定从 Quiver 迁移到 Obsidian。目的不只是换一个笔记软件，而是借这次机会重新整理这些笔记，让它们更容易被搜索、关联和继续维护。

一、先把 Quiver 笔记转换成 Markdown

迁移使用的是社区工具 @tettekete/quiver-to-obsidian-exporter。用的时候 npm 上的最新版本是 1.1.2，安装后可以通过 qvr2obs 转换 Quiver 库：

1
2

npm install -g @tettekete/quiver-to-obsidian-exporter
qvr2obs 你的笔记.qvlibrary -o 你的Obsidian仓库路径 -a subfolderUnderVault -n _attachments

几个主要参数分别是：

• <你的Quiver库文件.qvlibrary>：需要迁移的 Quiver 库。
• -o <输出文件夹>：转换后的 Obsidian 笔记存放位置。
• -a <附件存放策略>：如何存放附件。
• -n <附件文件夹名>：附件子目录的名称。

工具支持多种附件存放方式：

• vaultFolder：放在 Obsidian 仓库根目录。
• subfolderUnderVault：放在仓库根目录下的指定子目录。
• sameFolderAsEachFile：和对应的 Markdown 文件放在一起。
• subfolderUnderEachFolder：放在每个 Markdown 目录下的附件子目录中。

网上更多倾向于统一放进 _attachments 或 _assets。这样后续检查失效图片、清理重复附件或者做同步时，会比附件散落在各个目录里省事。我的话考虑到后面可能单独把某一领域的单独拎出来形成知识库，所以把附件放到某个领域的子目录下。

这个工具适合完成一次性转换，但不应该把全部希望都寄托在转换结果上。它的 README 已经说明项目不一定会持续维护，而且 Quiver 中不同类型的内容转换出来以后，多少会有一些格式问题。正式迁移之前，最好先备份 .qvlibrary，再找一个临时 Vault 试跑。

转换完先处理格式，不要急着重新分类

第一次看到近千篇 Markdown 时，很容易产生一种冲动：趁迁移的机会，把所有笔记一次整理干净。

我没有这样做。转换完成后，第一轮只处理影响阅读和检索的基础问题：

• 统一图片和附件目录，检查图片链接是否有效。
• 检查代码块是否正确闭合，并补充语言标识。
• 检查 LaTeX 公式前后的空行，避免 MathJax 无法识别。
• 把部分纯文本标题转换成标准 Markdown 标题。

这一阶段的目标只是让旧笔记能够正常阅读、搜索和链接。至于内容是否过时、应该放在哪个领域、是否需要与其他笔记合并，可以留到真正用到它时再处理。

二、先用 Copilot 规划怎么迁

格式转换完成后，新的问题马上出现了：近千篇笔记究竟应该怎么重新组织？

没有先手工建立一套新目录，再把文件逐篇搬过去，而是先接入 Copilot，让它分析现有内容，给出结构调整建议。确定大方向后，再让 Copilot 把建议展开成一份详细的迁移清单，包括哪些目录需要合并、哪些内容应该归档、哪些笔记需要补充链接，以及引用资源应该怎样跟着正文一起移动。

这里主要把 Copilot 当成规划工具，而不是让它直接批量修改文件。先用它解决“应该怎么迁”，真正执行文件和引用资源迁移的工作，后面再交给 Claudian 中接入的 Codex。

为 Copilot 配置语义检索

Obsidian Copilot 的 Vault QA 使用 RAG 从整个 Vault 中检索相关内容，再根据检索结果回答问题。

这里需要区分两种模型：

• 聊天模型负责生成回答、总结和分类建议。
• 嵌入模型负责把问题和笔记转换成向量，用于语义检索。

如果用一个不太严谨但容易理解的比喻，聊天模型像负责回答问题的人，嵌入模型像熟悉书架位置的图书管理员。提问后，嵌入模型先找出相关笔记，聊天模型再根据这些内容组织回答。

模型 API 使用的是硅基流动 SiliconFlow。中文 API 文档中的接口示例是：

1
2

https://api.siliconflow.cn/v1/chat/completions
https://api.siliconflow.cn/v1/embeddings

因此，在 Copilot 中配置 OpenAI-compatible 服务时，使用的 Base URL 是：

1

https://api.siliconflow.cn/v1

尝试过的模型包括：

• 聊天模型：DeepSeek-V4。
• 嵌入模型：BAAI/bge-m3。

截至 2026 年 8 月，SiliconFlow 价格页将 BAAI/bge-m3 列为免费模型，而 Pro/BAAI/bge-m3 是付费模型。价格和赠送额度都可能调整，实际使用时仍应以官网为准。

接入嵌入模型时选错了配置位置

401 和 CORS 报错出现在给 Copilot 接入嵌入模型的时候。

Copilot 的设置页面里，开头显示的是聊天模型配置；继续向下滚动，后面才是嵌入模型配置。当时没有注意到这两个入口，把 BAAI/bge-m3 填进了聊天模型的位置。因为两处都需要填写 Provider、模型名和 API 地址，配置完成后看起来也像那么回事，排查时一直没有意识到模型类型选错了。

一开始检查的是 API Key、额度和接口地址，也单独调用过 SiliconFlow API。领取代金券后，接口能够正常调用，说明服务本身没有问题。后来重新检查 Copilot 的完整设置页面，才看到下方单独的嵌入模型配置入口。

把模型放到正确的位置后，这个问题才算找到方向。如果你们遇到类似报错，建议按下面的顺序检查：

1. 先确认 API Key 和账户额度是否正常。
2. 用独立请求验证 API 本身能否调用。
3. 检查当前添加的是聊天模型还是嵌入模型。
4. 核对 Base URL、模型名和 Provider 是否对应。
5. 如果出现 CORS，再检查 Copilot 自定义模型中的 CORS 选项。

另外还要留意站点和域名。中文文档示例使用 .cn，国际站和国内站的入口不要混在一起使用。

三、再用 Claudian 中的 Codex 执行迁移

Copilot 帮我形成迁移方案和清单后，下一步是实际移动、重命名和修改这些文件。这个阶段需要的不是继续问答，而是能够直接操作 Vault 的 Agent。

我使用的 Claudian 可以把 Claude Code、Codex、Grok、OpenCode、Pi 等 coding agent 接入 Obsidian。Vault 会成为 Agent 的工作目录，因此它可以搜索文件、修改 Markdown、执行命令，以及完成多步骤的整理任务。

我主要把它用于：

• 批量检查 Markdown 格式。
• 移动、重命名和重构笔记。
• 根据目录规则整理文件。
• 根据 Copilot 生成的清单迁移正文和引用资源。
• 在 Obsidian 中完成涉及多个文件的编辑任务。

为什么最后选择 Codex

一开始我考虑接入的是 Claude Code 和 Codex。

我本机的 Claude Code 客户端通过 CCSwitch 配置了 DeepSeek 模型，但如果在当前这套 Claudian 使用方式中接入它，还需要额外启动服务。Codex 这边，我已经在使用桌面版，同时也安装了 Codex CLI。对我来说，直接复用现有的 Codex 环境更方便，所以最后先选择了 Codex。

配置了 Codex，为什么聊天框里还是 Claude Code

配置完成后又遇到了一个问题：Claudian 的聊天框仍然显示 Claude Code，模型列表中也只看到 Claude 和 Haiku 相关内容，看起来并没有切换到 Codex。

这里有两个容易混淆的概念：Claudian 仍然是界面本身，接入 Codex 不会让它变成 Codex App；Codex 在这里是 provider 或 Agent 运行环境，也不一定会显示成一个叫 codex 的模型。正常切换完成后，更明显的变化是模型列表中出现 gpt-* 模型。

我的情况是当前 Vault 的会话状态仍然绑定在 Claude provider。最后检查并修改了两个配置文件：

1
2

.claudian/claudian-settings.json
.obsidian/plugins/realclaudian/data.json

主要调整包括：

• 将 settingsProvider 从 claude 改为 codex。
• 将当前模型从 haiku 改为可用的 gpt-* 模型。
• 清理新标签页里残留的 draftModel: haiku。

Claudian 的部分配置按 Vault 保存。Codex CLI 的登录状态可以是全局的，但每个 Vault 仍可能需要单独切换 provider。遇到模型状态不更新时，应该先升级插件并重新刷新模型列表，再考虑手工修改配置文件。

截至核实时，Claudian 最新 release 是 2.0.41，其中包含 provider state 和模型发现刷新相关修复。项目 README 同时说明，Codex 等 provider 虽然已经可用，但在不同平台和安装方式下仍需要继续测试。

Copilot 规划，Codex 执行

Copilot 和 Claudian 看起来都能使用 AI，实际负责的工作并不相同。

这次迁移中，Copilot 先分析笔记内容、提出结构建议，再生成详细的迁移清单；Claudian 中的 Codex 根据清单移动文章和引用资源，修改 Markdown 链接，并按新的目录规则完成整理。

一个负责规划，一个负责执行。这样比让某一个工具从分析到批量改文件全部包办更容易控制，出现问题时也能看清是规划不合适，还是执行过程出了偏差。

四、迁移完成后的目录和内容结构

原来的 Quiver 目录基本是按技术名或者当时的用途直接创建的。从截图中可以看到，目录数量很多，命名方式也不统一：既有 java、linux、mysql 这样的技术分类，也有 python面试180题、软考架构师杂七杂八、通用IT 这种临时形成的分类。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

通用IT                    67
linux                     79
PHP                       76
python                    67
架构                      56
软考架构师杂七杂八         51
mysql                     47
系统集成项目管理工程师      43
python面试180题            38
剑指offer-python           30
Django                    29
nginx                     26
java                      25
Flask                     24

完整迁移方案扫描到了 1004 篇 Markdown。旧目录在记录时很方便，时间久了却容易出现重叠：算法内容同时存在于 算法、python算法 和 剑指offer-python，架构相关内容也分散在数据库、缓存、消息队列和运维目录中。

结合 Copilot 给出的建议和实际迁移结果，一级目录最终调整为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

00_Inbox 临时收集
01_工程开发
02_架构与系统设计
03_数据与存储
04_运维与基础设施
05_测试与质量保障
06_安全与逆向
07_AI与效率工具
08_项目与产品
09_求职面试与考试认证
10_场景知识库
99_索引与地图 MOC

新结构并没有完全放弃技术分类，而是把它们放到更稳定的领域下面。例如 Go、Java、Python 放在 01_工程开发/后端开发，MySQL、Redis 和 ELK 放到 03_数据与存储，软考和面试内容统一放进 09_求职面试与考试认证。

另外增加了 10_场景知识库。它不是用来重复存放笔记，而是从一个具体问题出发，把散落在不同领域的内容重新串起来。

不一次性精修全部旧笔记

近千篇笔记如果逐篇检查，很可能整理到一半就放弃。因此，迁移清单采用了热数据优先的方式：先处理最近 3 个月查阅过的高频笔记，给核心领域建立入口页和链接关系；剩下的旧笔记先放进归档区，通过标签或者 Dataview 保持可检索，以后用到哪一篇，再继续整理哪一篇。

这个过程有点像处理系统里的冷热数据。高频内容值得优先投入时间，低频内容只要暂时不丢失、不妨碍搜索，就没有必要在迁移阶段全部精修。

用 MOC 串联一个完整场景

目录解决了文件放在哪里的问题，但不能完全解决“遇到一个具体问题时，应该看哪些内容”。因此给重要场景建立了 MOC（Map of Content，内容地图）。

MOC 可以理解为人工整理的主题导航页。它不存放新的知识正文，而是围绕一个场景，说明会遇到哪些问题、对应哪些解决方向，并链接到已经存在的笔记。

例如 高并发系统设计 这个 MOC，会把负载均衡、限流、缓存、消息队列、数据库和监控等原本分散的内容串在一起：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 高并发系统设计

## 入口层：负载均衡 / 反向代理
- [[LVS负载均衡]]
- [[负载均衡之 LVS 与 Nginx 对比]]

## 应用层：限流 / 降级 / 幂等
- [[三种常见的限流算法]]
- [[四种幂等性解决方案]]
- [[分布式锁的几种实现方式]]

## 缓存层：Redis / 缓存异常
- [[缓存穿透、击穿、雪崩]]
- [[Redis应用场景例子]]

## 消息层：MQ 异步削峰 / 解耦
- [[究竟什么时候该使用MQ？]]
- [[kafka、rabbitmq、redis区别，各自适合什么场景？]]

## 数据层：读写分离 / 分库分表
- [[mysql数据库的主从同步，实现读写分离]]
- [[数据库垂直拆分和水平拆分使用场景]]

真正排查或设计高并发系统时，可以先从这个页面建立整体思路，再跳转到对应的技术笔记，不需要自己回忆相关内容分别放在哪些目录。对于 Copilot 来说，这些链接也能补充笔记之间的关系，让检索结果不只是几篇彼此独立的文档。

同一个问题尽量只保留一篇主笔记

以前我会因为实现语言不同，分别记录 Python 快速排序和 Go 快速排序。迁移后，我更愿意让一篇笔记围绕「快速排序」本身展开：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 快速排序

## 核心思想
分治法：选基准值，递归排序。

## Python 实现
...

## Go 实现
...

## 关键差异
| 维度 | Python | Go |
| --- | --- | --- |
| 语法表达 | 更简洁 | 更显式 |
| 内存管理 | 自动管理 | 注意切片底层数组共享 |

语言实现仍然保留，但它们变成了同一个问题下面的不同部分，不再各自占据一篇孤立的笔记。

五、迁移之后

从 Quiver 到 Obsidian，转换 Markdown 只是最前面的一步。真正花时间的，是决定旧内容如何处理，以及以后用什么方式继续维护。

目前对我最有用的做法有三点：

1. 不追求一次整理完近千篇旧笔记，先处理仍然会用到的内容。
2. 先用 Copilot 分析内容、形成迁移清单，再让 Claudian 中的 Codex 执行文件和资源迁移。
3. 目录只提供稳定边界，用标签和 MOC 补充跨领域的关联。

这套结构还会继续调整。至少现在，当我需要查找一个问题时，不再只能依赖自己记得「当年把它放在哪个文件夹」。旧笔记也不只是被搬到了另一个软件里，而是有机会重新进入日常使用。

参考资料

• @tettekete/quiver-to-obsidian-exporter README
• SiliconFlow 对话 API 文档
• SiliconFlow 嵌入 API 文档
• SiliconFlow 价格页
• SiliconFlow 计费规则
• Copilot Vault QA 文档
• Copilot Settings 文档
• Claudian README
• Claudian 2.0.41 release