用 Obsidian 打造你的 LLM 知识库：大模型学习与个人 Wiki 实践指南

llm_wiki：用 Obsidian 建立你的第一座大模型知识库

入行做 NLP 这几年，我电脑里的资料比头发掉得还快。PDF 论文、微信公众号文章、GitHub 上的教程、飞书文档链接，散落在各个文件夹里，真到用的时候什么都找不到。后来我花了一个周末把思路捋顺，用 Obsidian 搭了一个叫 llm_wiki 的知识库，专门用来装大模型相关的所有东西——从 transformer 原理到 LoRA 微调，从 RAG 架构到 agent 工作流，现在每天查资料都在这个库里完成。这篇文章就是把我当时怎么设计、怎么搭、后期怎么维护的经验完整写出来，给同样被 LLM 知识淹没的朋友一个可以直接抄作业的方案。

这个项目核心回答三个问题：LLM 的知识体系应该长什么样，个人知识库怎么搭才能长期用而不烂尾，以及怎么把零散的笔记变成真正能检索、能复用的资产。适合正在系统性学习大模型的人、做 AI 应用的工程师或者打算转型做算法岗位的开发者参考。如果你只是想收藏几篇文章那用不着这么麻烦，但如果你要在这条路上走很久，一个结构化的 wiki 知识库绝对值得投入时间。

1. 为什么是 Wiki 而不是一堆收藏夹

1.1 LLM 知识的特点决定我们不能用旧方法

先聊聊大模型这个领域本身。LLM 相关的知识有一个很明显的特征：网状结构，而非线性结构。你今天学的是注意力机制，明天就可能要用到位置编码，然后发现还得回去翻 transformer 的原始论文；你研究 RAG，除了要理解向量化、检索排序，还得懂 embedding 模型怎么选、向量数据库怎么配、prompt 怎么写。传统那种"文件夹分门别类"的管理方式，本质上是在用线性的方式组织一个立体的知识网络，装着装着就会发现同一篇笔记放在 A 类也对、放在 B 类也行，最后干脆乱扔。

再加上这个领域迭代速度极快。去年大家还在讨论 BERT 和 GPT 的区别，今年都在聊 MoE 和长上下文；前阵子微调还主流，现在 RAG 又成了标配。如果没有一个能快速更新、方便建立关联的载体，你收藏夹里的资料一两个月就变成了"旧闻博物馆"。

1.2 Wiki 对个人知识管理意味着什么

Wiki 这个词大家都不陌生，但多数人的理解停留在"一个能多人编辑的网页"。其实 wiki 的核心在于词条之间的互相引用和网状关联——每个页面只写一个相对聚焦的主题，页面之间用链接形成语义网络。这恰恰是 LLM 知识管理的理想形态。

我最早试过 Notion，它更适合做项目管理和协作，数据库视图好用但页面之间的关系还是偏结构化，写起来不够自由。也试过语雀，适合团队知识库，但个人深度整理时总感觉少了点什么。直到切到 Obsidian 才发现它天生就是干这个的：本地 Markdown 文件，双链自由，插件生态丰富，数据完全在自己手里。用 Obsidian 搭 LLM wiki，本质上就是用一个本地的、个人化的 wiki 引擎来承载一套大模型知识体系。

注意：好工具只是起点，真正的关键是你怎么设计分类和关联规则。工具是骨架，结构是灵魂。

1.3 这个项目到底能解决什么问题

具体到我自己的场景，llm_wiki 当初设立的目标有四条：

• 把散落在各处的 LLM 资料统一收编，形成单一入口。跟正文相关的内容可以引用，跟建模相关的代码段可以留存，看到好文章能随手剪藏并标注来源。
• 让笔记之间自动形成知识网络，而不是躺在文件夹里吃灰。看到"RAG"这个词条，就能顺着链接跳到"向量数据库"、"Embedding""Chunking 策略"等相关的页面。
• 给自己做一份持续迭代的 LLM 学习路线。每学完一个主题就打一个勾，相关笔记自然沉淀为阶段性产出。
• 必要时可以把库里的素材快速整理成一篇技术博客或者一份分享 PPT，实现知识的二次输出。

说白了，它就是一个可以陪着你从入门到进阶、随时能查阅的私人维基百科。

2. 目录、标签与双链：整体设计先定好

2.1 顶层目录设计：以知识点为中心

一个知识库用久了会不会乱，第一眼就看它的目录结构。有个现成的思路叫"PARA 法"：Projects（项目）、Areas（领域）、Resources（资源）、Archives（归档）。但我试过之后发现，这个方法适合通用知识管理，放在 LLM 这种专业性极强的领域里还是太抽象了。

我在 llm_wiki 里用的是按知识域划分的一级目录，加上一个专门的 Inbox 作为临时收集箱：

llm_wiki/ ├── 00-Inbox/ # 临时捕获区 ├── 01-Basics/ # LLM 基础理论 ├── 02-Architecture/ # 模型架构 ├── 03-Training/ # 训练与微调 ├── 04-Inference/ # 推理与部署 ├── 05-Application/ # 应用与工程化 ├── 06-Tools/ # 工具与框架 ├── 07-Papers/ # 论文笔记 ├── 08-Projects/ # 个人项目 ├── 09-Archives/ # 归档区 ├── _templates/ # 模板目录 └── _assets/ # 图片附件目录

这套结构的好处是，你拿到一篇新文章时，大多能立刻判断出该放进哪个大类。比如看到一篇《从零实现一个 GPT》，放 02-Architecture；看到《RLHF 的工程实践》，放 03-Training；看到《vLLM 部署技巧》，放 04-Inference 或者 06-Tools 都可以，看你自己的核心关注点。

2.2 双链：wiki 的灵魂所在

Obsidian 里的[[双链]]是我最看重的功能。在 llm_wiki 里，我给自己定了一条硬规矩：每篇笔记的正文中至少包含 3 个与其他笔记的链接。没有链接的笔记就是一座孤岛，那跟普通文件夹里的 Markdown 文件没区别。

我的实际操作习惯是：只要某个概念在笔记里出现且它是值得单独展开的话题，就顺手加上双链，比如写 RAG 的时候必然会提到[[向量数据库]]、[[Embedding]]、[[重排模型]]。这样积累一段时间后，Obsidian 的图谱视图会自动长出一张知识网络，你能很直观地看到哪些主题是枢纽节点、哪些领域还有待补充。

双链还有一个隐性好处：它倒逼你把概念拆得更细。以前我收藏一篇讲 LoRA 的文章就是收藏一整篇；现在我会把它拆成[[LoRA 原理]]、[[QLoRA]]、[[PEFT 库]]三个词条，每个词条聚焦一个点，相互链接。以后要查什么，从入口进来之后顺着链接走就行，不用反复翻长文。

2.3 标签：纵向维度的补充

有了双链，还需要标签吗？我的答案是：需要，但别太复杂。我对标签的使用原则是——标签负责"属性"和"状态"，双链负责"知识关系"。

在 llm_wiki 里我只保留了这几类标签：

注意，标签千万不要做成年月日这种毫无意义的维度，也不要做得太细导致每个标签下只有一篇文章，那就失去筛选的意义了。

3. 用什么搭：我对 Obsidian 和个人 Wiki 方案的选型对比

3.1 为什么从 Notion、语雀、Doku 一路换到 Obsidian

做 LLM 知识库，工具选型看起来是小事，实际上对长期使用体验影响极大。我把主流方案都过了一遍，简单说下我的真实感受：

Notion的编辑体验和数据库功能确实强，适合做团队协作和项目管理。但对个人知识库来说有三个问题：一是内容存在云端，搜索速度依赖网络；二是 Markdown 兼容性一般，从其他平台导入经常格式错乱；三是页面层级限定严格，双链逻辑是为数据库服务的，用起来总觉得笨重。

语雀在国内访问体验好，文档排版漂亮，尤其适合知识沉淀和分享阅读。但它的定位还是偏"团队知识管理系统"，单人深度整理时自定义能力有限，比如本地存储、插件扩展都做不到。

Doku、BookStack这类开源 Wiki 系统解决的是团队协作场景，适合做项目 Wiki 或者公司内部文档，做成个人知识库就太重了，部署、运维都要花精力。

Obsidian刚好补全了上面这些短板：本地 Markdown 文件，数据不锁定；双链语法原生支持；插件生态非常活跃；而且有全文搜索和图谱视图。对个人搭 LLM wiki 来说，它是最省心的选择。其实也不用担心"本地存储不方便多设备查看"的问题，网上大把方案可以做多端同步，我后面会细说。

补充一句：如果你本来就是重度 VS Code 用户，也可以考虑用 Markdown 仓库 + Foam 插件实现类似效果。但 Foam 的双链体验和插件生态还是比不上 Obsidian，综合看 Obsidian 更"开箱即用"。

3.2 需要装的插件清单和使用配置

Obsidian 默认功能其实够用，但装了合适的插件，效率能上一个台阶。我在 llm_wiki 项目里长期在用的是这几个：

• Dataview：所有"查询"类需求都靠它。比如你要列出某个目录下所有#status/done的笔记、列出所有链接到[[Transformer]]但还没有写正文的空笔记，它都能做到。查询语句长这样：

```dataview TABLE file.ctime as 创建时间, file.mtime as 修改时间 FROM "02-Architecture" WHERE contains(tags, "status/done") SORT file.mtime DESC

- **Templater**：配合 `_templates` 目录使用。每次新建笔记时自动带入模板，比如论文笔记模板、术语词条模板、项目复盘模板。这能保证所有笔记结构一致，不会因为今天心情好就多写几段、明天心情差就只扔一个标题。 - **Excalidraw**：画架构图、流程图、模型结构图用的。直接内嵌，支持在图上做双链跳转。我整理模型架构对比时经常用它，比手写 Markdown 表格直观得多。 - **Recent Files**：快速切换近期编辑过的笔记，查资料的时候少点几下鼠标。 - **Calendar**：如果你有写日志的习惯，用它按天快速建笔记，做工作日志和 idea 记录很方便。 - **Smart Connections**：利用本地 embedding 找到语义相近的笔记，这也算是"AI 辅助建 wiki"的一种玩法。不过它比较吃性能，库太大的时候会卡，我后来关掉了。 插件别贪多，装得多不代表用得多，反而会让 Obsidian 启动变慢。**我的原则是：先默认功能，用到一个痛点再补一个插件，不提前堆装备。** ### 3.3 工作流设计：Inbox → 清洗 → 入库 知识库搭好之后，最大的挑战其实是"怎么持续喂内容"。很多人坚持不下去，不是因为不知道用什么工具，而是因为没有一个标准的物料流转流程。 我在 llm_wiki 里设计了"三步走"流程，跟 GTD 的思路有点像： 1. **收集**：平时看到好文章、好教程，随手扔到 00-Inbox，标题简单写成日期加来源，比如 `20240612-huggingface-blog-随想`。甚至可以给 Obsidian 的移动端装一个快捷插件，手机端看到什么就一键保存到 Inbox。 2. **清洗**：每周抽 30 到 60 分钟处理 Inbox 里的内容。读一遍，决定它属于哪个知识域，移动文件到对应目录并改成规范命名；在正文里提取关键点、添加双链，懒的时候至少也要加标签和摘要。 3. **入库**：如果原文很长，我会拆成骨架放进目标笔记，外链保留在笔记顶部作为参考来源。如果原文只是某段话对我有启发，我就把那句话摘录进相关词条，在引用块里注明出处。 这套流程的核心思想是**"先捕获，后整理"**。看资料的时候不用纠结该放哪，每周统一处理一次就够，不会给自己增加维护负担。 ## 4. LLM 知识内容体系梳理：这个 Wiki 里到底装什么 ### 4.1 从入门到主线：先把学习路线想清楚 目录结构搭好了，具体往里面装什么就成了关键。我在建库初期踩过一个大坑：贪多嚼不烂，什么热词都往 wiki 里塞，结果库建好了，里面的词条十个有九个是空的。后来我重新梳理了学习主线，只保留跟自己当前方向强相关的内容，库存量一下子就健康了。 对于现在准备系统性学习 LLM 的朋友，我的建议是先把一条主线走通，具体可以参考这个顺序： - **入门基础**：了解什么是大语言模型、语言模型的基本任务、Transformer 核心组件（注意力机制、位置编码、层归一化）。 - **模型架构**：GPT 系列演进、BERT 和 GPT 的区别、Encoder-Decoder 架构、MoE 架构、长上下文技术。 - **训练与后训练**：预训练目标与损失函数、SFT（有监督微调）、RLHF / DPO、LoRA / QLoRA 等参数高效微调方法。 - **推理优化**：KV Cache、量化、vLLM 等推理引擎、批处理策略。 - **应用开发**：Prompt Engineering、RAG 架构、Agent 与工具调用、评估方法论。 - **工具链选型**：HuggingFace Transformers、LangChain、LlamaIndex、Dify、Ollama 等。 这条主线不是暑假两个月就能学完的，但每一步走的都是核心，不会绕远路。你的 wiki 里的词条应该围绕这条主线来建。 ### 4.2 词条分类方法：词条越细，使用越顺手 在 llm_wiki 里，我把词条分成三类： **概念词条**，比如 `[[注意力机制]]`、`[[温度系数]]`、`[[上下文窗口]]`。这类词条的标准写法是：一句话定义、核心细节、直观比喻、相关链接。以 `[[温度系数]]` 为例，我一般先写"温度系数是控制生成随机性的超参数，值越大输出越发散，值越小越发确定，一般 0.1 到 1.0 之间使用"，然后写 sample 函数里除以 temperature 的数学公式，再给一个"做饭调料"的类比，最后链接到 `[[解码策略]]`、`[[生成参数调优]]`。 **论文词条**，比如 `[[Attention Is All You Need]]`、`[[LoRA: Low-Rank Adaptation]]`。模板固定为：研究背景、核心方法、关键实验、我的理解、可复现代码链接。注意一定要写"我的理解"，也就是用自己的话把论文的贡献说清楚，这能帮你确认自己真的读懂了。一行字也好，坚持写。 **项目词条**，比如 `[[本地知识库问答机器人]]`、`[[论文摘要工具]]`。记录项目的目标、技术选型、踩坑记录、结果复盘。以后写简历或者做分享的时候，直接在 wiki 里翻出项目词条改一改就能用。 ### 4.3 如何避免 Wiki 烂尾：维护节奏与最小可行笔记 这是我想重点聊的话题。Obsidian 类的 wiki 工具上手很容易，但大多数人会在两周左右放弃，为什么？因为"维护成本失控"了，总觉得要把每篇笔记写到完美才行，然后越想越焦虑，最后干脆不写了。 我给自己定了一条"最小程度可用"的规矩： - **新词条只要能在 5 分钟内写出一段话，就算完成**，不用追求论文级别的完整度。以后看到相关内容，随时回来补充。 - **每周只花 60 分钟整理 Inbox**。超过时间就停，留给下周，绝不熬夜清空。 - **空链接不可怕**。Obsidian 里允许创建还没有对应文件的链接（比如你写 `[[RLHF]]` 时它还没有词条），这时链接会变红，这反而是好事——它是一个待办事项，提醒你哪里需要补充。 有了这条规矩之后，我的 llm_wiki 基本能稳定每周增加 10 到 20 条笔记，而不是成堆的"半成品吃灰"。知识库这东西，细水长流远比一蹴而就重要。 ## 5. 关键实操环节：从空白仓库到可用的 LLM Wiki ### 5.1 本地方案初始化 我自己当时是这么起步的，步骤很简单，你也可以照做： 第一步，打开 Obsidian，新建一个仓库，仓库名字就叫 llm_wiki，存放在一个盘符空间充裕的位置。建议直接放在本机固态硬盘上，不要放在云盘同步目录里，否则 Obsidian 的索引会频繁触发同步，体验很差。 第二步，按 2.1 节的目录结构建好顶层文件夹，同时在设置里开启"新建笔记默认存放位置"为 `00-Inbox`，这样你按快捷键 Ctrl+N 随手记的内容会先落到收件箱，不会污染正式分类。 第三步，打开核心插件里的"模板"，指定模板文件夹为 `_templates`。把下面几类模板文件创建好： - 术语词条模板 - 论文笔记模板 - 项目复盘模板 - 学习日志模板 以术语词条模板为例，我常用的内容结构是： ```markdown --- tags: [status/developing, stage/intermediate] --- # {{title}} 一句话定义：... 核心原理：... 关键细节：... 直观类比：... ## 相关链接 - [[]] - [[]]

这里的{{title}}是 Templater 或核心模板功能自动填充的占位符，用的时候会替换成当前文件名。

第四步，安装 Dataview 插件，把 2.3 节那段查询代码放到一个叫"索引页"的笔记里。这样你每次打开这个索引页，就能自动看到所有已完成词条的最新列表，对整个库的进度一目了然。

5.2 多端同步方案：本地为主、加密云端为辅

提到 Obsidian，很多人第一反应就是"数据都在本地，那手机上看不了怎么办"。这确实是需要解决的一个问题。我目前的方案是：核心库放在本地，通过同步盘做加密备份和多端访问。Git 配合私有仓库同步是很多技术人用的方案，GitHub 和 Gitee 都行，只在能正常访问的环境下使用即可。不想折腾 Git 的话，也可以直接用坚果云、OneDrive 这类网盘工具进行目录同步。

我自己用 Git 方案比较多，因为还能顺便做版本管理。常用流程是：写完一批笔记之后git add . && git commit -m "update llm wiki"，再推送到远程私有仓库。另外在.gitignore里排除.obsidian/workspace.json这类本地状态文件，避免多设备同步时界面布局乱掉。

需要注意，如果你在手机端也要编辑，建议在手机上只保留一个只读副本或者用网盘按需同步，不然手机空间会被撑爆。

5.3 与外部工具结合：Dify、API 和自动化脚本

llm_wiki 虽然是"个人知识库"，但它完全可以跟大模型应用生态打通。最典型的就是知识库问答。Dify 这类 LLM 应用开发平台天然支持知识库功能，你可以把 llm_wiki 里的 Markdown 文件作为离线知识源，在处理后上传到 Dify 里构建 RAG 应用。

我第一次是用 llm_wiki 的论文摘要笔记和架构笔记生成了一份内部 FAQ，然后上传到 Dify 构建了一个"LLM 知识问答机器人"。效果很好，因为笔记都是自己写的，风格和术语比较统一，检索时的命中率比直接喂网页文本高得多。

如果你有一定的编程能力，还可以写个小脚本，每周自动扫描 llm_wiki 目录里修改时间最近的笔记，生成一份"本周更新摘要"，然后推送给自己。这既是学习回顾，也相当于给知识库做周报，很有仪式感。

6. 常见问题速查：我在搭建和使用中的踩坑实录

6.1 链接失效、图片丢失、文件命名混乱，怎么办

问题一：笔记里的双链是文字，没有变成可点击的链接

大部分情况是语法写错了。Obsidian 双链必须是[[笔记名]]，如果笔记名里有特殊字符，比如LoRA: Low-Rank Adaptation包含冒号，也需要注意有没有闭合括号。建议命名规范统一用中文-英文或者纯语义化短语，避免冒号、斜杠、问号这类容易出问题的字符。

问题二：图片附件到处都是，库越来越乱

一开始我图省事，直接把图片粘贴进笔记，Obsidian 默认存在根目录下的附件文件夹，用久了文件一多就成了垃圾场。后来我设置了附件默认存放路径为_assets，并通过插件把已有笔记中的图片统一迁移过去。现在新笔记插入图片会自动归位，库的整洁度提升很多。

问题三：文件名重复

手写笔记时容易不小心创建两个名字几乎一样的文件，比如RAG.md和rag.md，在 Obsidian 文件系统里这其实是两个文件。Windows/Mac 大小写不敏感会自动合并，但同步到 Linux 服务器或者 Git 上就会出问题。我的建议是新建笔记时直接搜索一下有没有同名文件，或者用命名带编号的方式来规避。

6.2 Dataview 查询不出结果、性能变差

问题一：Dataview 查出来的列表是空的

检查三处：是否在笔记的 YAML 区写了正确的标签（注意 YAML 数组的写法是tags: [a, b]或者tags:\n- a）；查询语句里的路径是否写对，Obsidian 对大小写敏感；是否把查询代码块指定为dataview而不是js。

问题二：库笔记多了之后，打开图谱或者 Dataview 明显卡顿

我的经验是：图谱视图不要开全局展开，只按需查看某个文件夹或者某个关键词的局部图谱；Dataview 查询尽量缩小范围，不要全库扫描，比如写成FROM "02-Architecture"而不是全库。另外一些重插件（比如 Smart Connections）如果吃资源，不要开机自动启动。

6.3 内容不知从何下手或者不知道怎么分类

如果问"这个主题应该放哪个目录"，我一般按下面的逻辑快速判断：理论、概念类放01-Basics或02-Architecture；训练、微调、数据相关放03-Training；推理、部署、性能优化放04-Inference；写代码、做应用、调 API 放05-Application或08-Projects；拿不准的都先丢00-Inbox，等整理时再归位。

建库初期最容易犯的错是"为了结构完美而迟迟不开始写"。别管分类对不对，先写了扔进 Inbox，后面移动文件就是几秒钟的事。一个不完美的词条永远比一个不存在的词条有用。

7. 加分项：从"能用的 Wiki"到"好用的 LLM 助手"

7.1 把 Wiki 变成 Prompt 素材库

llm_wiki 积累到一定量之后，我发现它不仅能被动查资料，还能主动变成大模型的 prompt 素材库。比如我写技术方案之前，会先把 wiki 里相关的词条全部打开，然后把关键结论复制给 ChatGPT，让它基于这些材料帮我起草一份方案初稿。因为材料都是我自己的笔记，背景信息交代得很清楚，生成的效果比直接问"帮我写一个 RAG 方案"好非常多。

这个用法给我的启发是：知识库的价值不只是给自己看，它还是喂给大模型的"上下文缓存"。与其每次临时写一堆 prompt 背景，还不如直接在库里把背景知识写清楚，用的时候一并贴进去。

7.2 用 LLM 反向整理 Wiki

反过来，也能用 LLM 的能力辅助维护 wiki。比如把一部分零散的 Inbox 笔记交给模型，让它帮忙总结成结构化词条，然后你再人工校对一遍。这能大幅降低"整理笔记"的心理负担。

我个人现在每周清理 Inbox 时会跑一个小脚本：把 Inbox 里各条笔记汇总生成一篇 Markdown，然后丢给大模型让它给出建议的文章分类和标题优化，再人工过一遍。这样整理时间从原来的 60 分钟降到了 20 分钟左右，而且分类的错误率不高。

提示：用模型生成的条目不要直接入库，一定要经过人工检查和修正，毕竟大模型可能会一本正经地胡说八道。知识库一旦被污染，越往后越难收拾。

7.3 后续可以怎么扩展

llm_wiki 做了一段时间之后，完全可以往多个方向扩展：

• 把它变成团队小圈子共享的知识库，用 Git 或者局域网同步，让团队新人从 wiki 开始了解技术栈。
• 把其中的部分词条整理成系列文章，发布到技术社区，相当于自己的"公开版 wiki"。
• 和自动化脚本绑定，每天自动从论文网站拉取最新论文标题和摘要入库，形成持续更新的论文追踪系统。
• 和日历结合，每个月自动生成学习统计，看看自己的知识分布在哪些领域、最近有没有偏离主线。

我从一个只会收藏小黄书签的初学者，到现在能靠这个库支撑起一个又一个技术方案，最大的体会是：知识库的价值不取决于工具的强大程度，而取决于你愿不愿意用结构化的方式对待自己的知识。工具只是给你提供了一片可以自由生长的土壤，真正的种子和耕耘还得靠你自己。

最后再分享一个小技巧，也是我现在还在坚持的习惯：每次学到一个重要概念，第一件事不是收藏原文，而是先用自己的话在 llm_wiki 里写一条一两句话的词条，哪怕很粗糙也没关系。先建链接，再慢慢丰满内容。长期积累下来，你不仅会拥有一个别人抄不走的 LLM 知识库，更会在写作的过程中真正建立起自己的技术理解框架。这个过程本身就是收获。