好多朋友问我收藏了几百篇大模型文章、存了一堆PDF和网页链接真到学的时候还是无从下手感觉什么都看了又什么都没记住。这个llm_wiki就是我在被这个问题折磨了大半年之后决定彻底用wiki的方式重建个人大模型LLM知识库的方案。它不是某个现成软件而是一套用 Obsidian 搭建、以“双链原子笔记索引页”为核心的 LLM 学习知识库方法论。这篇就把完整的搭建思路、目录设计、实操步骤和踩坑记录都写清楚适合正在系统学习 LLM、做LLM相关项目的开发者也适合想把手边资料从“收藏夹”变成“可检索资产”的朋友。1. 项目整体设计与思路拆解1.1 为什么是 wiki 而不是零散笔记我最早记 LLM 学习笔记用的是文件夹分类比如“论文”、“教程”、“代码”三个大文件夹往里一顿丢。三个月后发现几个问题一篇文章可能既算“教程”又涉及“模型架构”放哪个文件夹都别扭学到后面想回头看某个概念比如 RLHF时得在十几个笔记里翻找最要命的是笔记之间没有任何关联今天记的“LoRA”跟上周记的“微调”在文件层面完全隔离。wiki 的“维基式”组织方式正好解决这些问题。说白了就是三点笔记之间靠双链互相引用形成一个可生长的网络用索引页比如 MOCMap of Content作为导航中枢不靠文件夹硬分类所有笔记内容保持“原子化”一篇只讲一个概念讲透了再和别的概念链接。这套玩法能完美适配 LLM 知识的特点——概念密度高、前后依赖强、更新速度快。你学“Attention”的时候自然会遇到“Transformer”“预训练”“token”如果这些都能通过链接一键跳过去知识就不再是一摞孤立的文档而是一张随时扩展的地图。1.2 工具选型我为什么选定 Obsidian做 wiki 的方案其实不少比如自建 MediaWiki、用 Notion、用思源笔记甚至直接写 HTML 页面。我之所以最后选了 Obsidian核心原因是本地 Markdown 文件存储内容永远是自己的不担心平台跑路双链、标签、图谱这些 wiki 核心能力开箱即用插件生态强能补上 Dataview、Templater、Excalidraw 这些生产力工具再加上纯文本格式以后想从 Obsidian 迁出去或者用脚本批量处理成本都很低。当时也考虑过自建一套 Wiki.js 或者 MediaWiki 服务但那意味着要维护服务器、数据库、权限系统而知识库本体的价值在于内容本身不应该把精力耗在基础设施上。用一个本地客户端做知识管理再用静态发布工具把最终成果导成网页版 wiki 分享出去这是投入产出比最高的组合。关于导出发布的方式我在后面第 5 节详细说。1.3 三层内容架构原子笔记、MOC、标签双链我实际跑下来的知识库内容分三层每层职责清楚不会互相打架。第一层是原子笔记这是最基础的知识单元。一篇笔记只讲一个概念比如“什么是 KV Cache”“LoRA 基本原理”“DPO 与 RLHF 的区别”。有些概念太复杂那就拆成多篇互相链接的笔记比如“Transformer 架构”可以拆成“Self-Attention”“位置编码”“残差连接与 LayerNorm”三篇。原子笔记的好处是复用性强多个主题都能链接到它而且单篇维护成本低。第二层是 MOC 索引页相当于一本书的目录加导读。比如“LLM 学习路线”这个 MOC下面按模块列出核心概念链接并写几句引导语说明学习顺序和重点。MOC 不存储具体知识内容只做导航这样即使笔记几百篇打开一个 MOC 就能找到入口。第三层是标签和属性负责横向聚合。比如给所有关于“训练”的笔记打#train给所有“数据准备”相关笔记打#data再加上 YAML 头里的状态字段status: learning/done就能用 Dataview 自动生成“待复习”“已完成”清单。这三层组合起来既保留了文件夹的秩序感又摆脱了单一分类的僵化。2. 核心细节解析与实操要点2.1 知识库目录设计从确定到可扩展虽然 wiki 强调不靠文件夹但完全不建文件夹几百个文件堆在一起照样乱。我采用的方案是“大类文件夹 索引反链”。根目录下先建这几个文件夹00-Inbox临时收集还没整理的内容放这里10-Concepts基础概念原子笔记20-Models具体模型、模型架构相关30-Training预训练、微调、RLHF 等训练相关内容40-Inference推理优化、部署、量化相关内容50-ApplicationsRAG、Agent、AIoT 等应用方向60-Tools框架和工具的使用笔记Transformers、vLLM、Dify 等70-Resources外部资源索引、论文清单、路线图90-MOC所有 MOC 索引页集中放99-Templates模板这套结构我用下来觉得比较顺手数字前缀让排序固定大类之间边界足够清晰又不至于细到无法归类。初期不建议超过 10 个文件夹类别越多整理成本越高最容易半途而废。2.2 核心知识点卡片的写法原子笔记的质量直接决定整个知识库的价值。我自己给 LLM 概念笔记定了一个四段式模板一句话定义、核心原理含必要的公式或流程图引用、代码/实验对照、链接和参考。举个例子写“KV Cache”时第一段一句话说明它是在推理阶段缓存历史 token 的 Key 和 Value避免重复计算第二段解释为什么生成是逐 token 的、如果不缓存复杂度会怎么变并画个简单示意第三段贴一段用 Transformers 库use_cacheTrue/False的对比推理时间第四段链接到“Self-Attention”“推理优化”“长上下文”等相关笔记并附上原始论文链接。这里有一个我踩过坑才总结出来的经验不要直接把别人的文章全文复制进来。复制的内容不会进脑子而且容易堆积成信息垃圾。我的做法是看完一篇文章或一段课程后用自己的话写 200 到 500 字的总结原文链接放进“参考”字段。这样既训练了理解也保证知识库里每一篇都是可读的原创笔记。2.3 模板与元数据让笔记“自动”组织起来纯靠手动维护几百篇笔记的状态不现实。我在每篇笔记头部加 YAML Front Matter字段包括title笔记标题tags主题标签statusidea/learning/done三态created/updated创建与更新时间source参考来源URL 或论文标题typeconcept/model/tutorial/moc等配合 Obsidian 的 Templater 插件新建笔记时按个快捷键就自动填充模板created自动生成不需要手敲。有了这些元数据第三层能力就出来了Dataview 可以按状态汇总待办按标签列出某主题全部笔记按更新时间找出“超过 3 个月没看”的旧笔记。这一步看着不起眼却是知识库从“一堆文件”变成“管理系统”的关键转折。2.4 双链使用原则宁缺毋滥双链是 wiki 的灵魂但一开始很容易上瘾写什么都加一堆[[]]最后图谱变成一团乱麻。我的原则是链接必须能回答“为什么点过去”凡是不解释关系的链接都不加。比如在“RAG”笔记里链接“向量数据库”语气可以是“关于索引方案见 [[向量数据库选型]]”而像“Transformer”这种每个概念都会碰到的词只在首次核心处链接一次不重复堆。另外我要求每个 MOC 页面同时承担“反向目录”的角色。每次新建概念笔记时顺手把链接挂到对应 MOC 下如果发现已有链接绕开了 MOC就检查是不是需要建一个新的 MOC 或者调整分类。这套“双向维护”的习惯保持住知识库就不会失控。3. 实操过程与核心环节实现3.1 初始化 Obsidian 仓库与核心插件开始之前先把环境准备好。我用的是 Windows 笔记本Obsidian 直接官网下载数据目录放在一个英文路径下比如D:\llm_wiki避免有些插件对中文路径支持不好。初始化步骤如下新建空仓库仓库路径指向D:\llm_wiki。按第 2.1 节建好文件夹目录。在“设置-核心插件”里开启反向链接、标签页、关系图谱、模板、日记。安装四个社区插件Templater增强模板、Dataview数据索引、Excalidraw画图、Advanced Tables表格编辑增强。在99-Templates里建concept.md和moc.md两个模板。这里提醒一句插件不是越多越好我装过十几个插件最后日常用到的就上面这四个。Obsidian 社区插件坑不少兼容性问题偶尔会出现建议装一个验证一个别一次性批量装。3.2 从零建立第一张 LLM 学习路线 MOC我的第一张 MOC 就是“LLM 学习路线”这个问题对新手最重要也最适合用它来验证知识库结构。页面分四个板块学习路径概览按阶段列出链接比如“基础篇 [[什么是LLM]]、[[Tokenizer与Token]]、[[Transformer架构]]”再到“训练篇 [[预训练目标]]、[[SFT]]、[[RLHF]]”再到“应用篇 [[RAG]]、[[Agent]]、[[模型部署]]”。当前学习进度用 Dataview 列出status: learning的笔记一眼看到卡在哪。资源索引链接到我收藏的文章、论文、视频播放列表。待办和疑问随手记录学习中产生的问题定期清理。MOC 写好后我不是一口气写完所有概念笔记而是“按需创建”学到哪个概念就新建对应原子笔记写完补链回 MOC。这样一周下来学习路线页会自动长成一棵树而不是一份空有框架的计划表。3.3 用 Dataview 做自动索引和状态看板Dataview 是 Obsidian 生态里最强大的插件之一它的核心能力是“用类 SQL 的方式查询笔记库”。我常用的三个查询第一个是按状态汇总TABLE status, tags, updated FROM 10-Concepts WHERE type concept SORT status ASC, updated DESC第二个是在每个 MOC 里列出“还没学完”的笔记LIST FROM 10-Concepts WHERE contains(file.inlinks, this.file.link) AND status ! done第三个是发现长期没更新的笔记安排定期复习TABLE updated FROM 10-Concepts WHERE date(updated) date(today) - dur(90 days) SORT updated ASC把这些块直接写在笔记正文里打开页面就会自动渲染成表格或列表不用手动维护。我第一次跑通的时候感觉整个世界都清爽了——知识库自己会告诉你“该复习什么”“哪些还没学完”比任何待办软件都靠谱。3.4 把外部资料包进来PDF、代码、URL做 LLM 相关学习资料类型很多论文 PDF、GitHub 代码、网页文章、B 站视频。我的处理方式是在70-Resources下建“论文索引”和“文章收藏”两篇笔记统一用表格记录“标题、作者、链接、一句话总结、相关笔记链接”。对于本地 PDF我直接用 Obsidian 自带的链接语法[[论文文件名.pdf]]嵌入对应笔记配合 Zotero 一起用效果更好。GitHub 仓库则在笔记里用普通链接并手写几行代码版本说明比如“用了哪个 commit 跑通的”。小技巧是每个外部资源都必须在相关原子笔记中出现一次链接否则就属于无效收藏——这是我对“收藏等于学会”这个坏习惯的强制免疫手段。4. 常见问题与排查技巧实录4.1 链接断链和“孤儿笔记”怎么处理知识库用久了最常遇到的问题就是链接指向不存在的笔记、或者一篇笔记没有任何链接也没有任何反链。Obsidian 本身有“孤立的笔记”核心插件打开后能在左侧面板看到没有入链的文件。我一般每个周末处理一批能补链接的补链接补不了的要么挂到00-Inbox重新整理要么果断删除。这里我想强调一件事知识库不是仓库不是只进不出定期清掉没用的笔记留下的内容质量才会高。4.2 笔记越来越乱定期“复盘整理”的节奏即使有结构时间长了也会乱主要表现是MOC 里链接越来越多但条目之间没有顺序两位同行概念分别写了两篇笔记内容高度重叠有些笔记只用过一次已经被新知识替代。我的整理节奏是每月一次“知识库大扫除”先看 Dataview 的更新列表再检查标签是否冗余然后合并重复笔记最后把每个 MOC 的内容重新排一遍顺序。这个方法听起来简单但能一直保持知识库可用比任何高级技巧都重要。4.3 问题排查速查表我把实际踩过的坑和解决办法整理成了表格遇到类似问题可以直接对照。现象原因解决方法新建笔记没有自动套模板Templater 模板目录未设置在 Templater 设置里指定模板文件夹并把“触发模板”快捷键绑定好Dataview 查询不显示内容查询语法或字段名不匹配检查 YAML 字段名是否和查询里一致注意大小写和空格关系图谱一团乱双链乱加缺少索引节点删掉无意义链接确保所有原子笔记至少挂在某个 MOC 下同步后笔记互相冲突多端同步导致的冲突文件优先用官方同步或 Git 同步避免两个客户端同时编辑同一笔记图片和附件丢了附件路径配置导致移动文件后失效在设置里把“附件默认保存路径”固定到一个文件夹例如80-Attachments电脑上打开仓库卡顿仓库太大且启用了大量插件把00-Inbox里的大文件清掉关闭不用的插件或把核心库和临时库分开4.4 备份与多端同步建议知识库是资产不备份等于裸奔。我的方案是本地目录直接用 Git 管理每次整理完手动 commit 一次同时用一个网盘文件夹做自动同步。注意 Markdown 文件纯文本Git 对文本比较友好diff 也清晰。如果更懒一点Obsidian 官方同步每月订阅也不贵胜在省心。我不太建议用某些第三方实时同步工具直接同步整个 Obsidian 目录因为索引文件.obsidian里的配置容易在多端之间互相覆盖轻则设置丢失重则插件异常。5. 后续扩展从个人知识库到可对外分享的 Wiki5.1 接入本地大模型做语义问答llm_wiki跑起来之后我做的第一个扩展是给知识库接上本地大模型实现“问自己的笔记”功能。做法就是用常见的 RAG 流程把10-Concepts等文件夹里的 Markdown 文档做分块用 embedding 模型转成向量再用一个开源问答模型做检索增强生成。开源社区里有不少相应用工具直接指向本地仓库目录就能工作。这一步做完相当于知识库拥有了语义检索能力过去“明明记得写过但搜不到”的问题基本消失。5.2 一键发布成静态 wiki 站点很多知识积累到一定程度就值得分享给团队或者社区。Obsidian 笔记想要对外发布我试过两条路一是用 Quartz、obsidian-export 这类工具把仓库导出成静态网页再部署到 GitHub Pages 或 Cloudflare Pages二是用 Digital Garden 这类插件直接搭建一个数字花园站点。两个方案都不需要维护数据库Markdown 改完同步即可。我更推荐先把隐私信息清理干净再选择一个单独的子目录做公开发布避免把整个仓库都晒出去。5.3 从学习仓库变成真正的工作资产到这一步llm_wiki对我来说已经不只是学习笔记了。遇到新模型、新框架我会先在知识库里检索有没有相关积累然后直接基于已有笔记产出技术方案、实验记录甚至周报素材。下个项目如果需要调研“垂域 LLM 数据准备”也能从知识库里快速拉出之前整理的数据清洗、标注、去重相关笔记省掉了大量重复资料收集时间。我个人实操中最深的体会是知识库的搭建从来不是一次性工程它是靠日记累加、周度维护、月度大扫除慢慢养出来的。与其追求一开始就规划得完美不如从今天建一个llm_wiki仓库写完第一篇“什么是 LLM”顺手挂到一张空白的 MOC 上。等笔记数量跨过一百篇你会明显感觉到这种“维基式”组织方式的价值——知识开始自己连接起来了。
好多朋友问我收藏了几百篇大模型文章、存了一堆PDF和网页链接真到学的时候还是无从下手感觉什么都看了又什么都没记住。这个llm_wiki就是我在被这个问题折磨了大半年之后决定彻底用wiki的方式重建个人大模型LLM知识库的方案。它不是某个现成软件而是一套用 Obsidian 搭建、以“双链原子笔记索引页”为核心的 LLM 学习知识库方法论。这篇就把完整的搭建思路、目录设计、实操步骤和踩坑记录都写清楚适合正在系统学习 LLM、做LLM相关项目的开发者也适合想把手边资料从“收藏夹”变成“可检索资产”的朋友。1. 项目整体设计与思路拆解1.1 为什么是 wiki 而不是零散笔记我最早记 LLM 学习笔记用的是文件夹分类比如“论文”、“教程”、“代码”三个大文件夹往里一顿丢。三个月后发现几个问题一篇文章可能既算“教程”又涉及“模型架构”放哪个文件夹都别扭学到后面想回头看某个概念比如 RLHF时得在十几个笔记里翻找最要命的是笔记之间没有任何关联今天记的“LoRA”跟上周记的“微调”在文件层面完全隔离。wiki 的“维基式”组织方式正好解决这些问题。说白了就是三点笔记之间靠双链互相引用形成一个可生长的网络用索引页比如 MOCMap of Content作为导航中枢不靠文件夹硬分类所有笔记内容保持“原子化”一篇只讲一个概念讲透了再和别的概念链接。这套玩法能完美适配 LLM 知识的特点——概念密度高、前后依赖强、更新速度快。你学“Attention”的时候自然会遇到“Transformer”“预训练”“token”如果这些都能通过链接一键跳过去知识就不再是一摞孤立的文档而是一张随时扩展的地图。1.2 工具选型我为什么选定 Obsidian做 wiki 的方案其实不少比如自建 MediaWiki、用 Notion、用思源笔记甚至直接写 HTML 页面。我之所以最后选了 Obsidian核心原因是本地 Markdown 文件存储内容永远是自己的不担心平台跑路双链、标签、图谱这些 wiki 核心能力开箱即用插件生态强能补上 Dataview、Templater、Excalidraw 这些生产力工具再加上纯文本格式以后想从 Obsidian 迁出去或者用脚本批量处理成本都很低。当时也考虑过自建一套 Wiki.js 或者 MediaWiki 服务但那意味着要维护服务器、数据库、权限系统而知识库本体的价值在于内容本身不应该把精力耗在基础设施上。用一个本地客户端做知识管理再用静态发布工具把最终成果导成网页版 wiki 分享出去这是投入产出比最高的组合。关于导出发布的方式我在后面第 5 节详细说。1.3 三层内容架构原子笔记、MOC、标签双链我实际跑下来的知识库内容分三层每层职责清楚不会互相打架。第一层是原子笔记这是最基础的知识单元。一篇笔记只讲一个概念比如“什么是 KV Cache”“LoRA 基本原理”“DPO 与 RLHF 的区别”。有些概念太复杂那就拆成多篇互相链接的笔记比如“Transformer 架构”可以拆成“Self-Attention”“位置编码”“残差连接与 LayerNorm”三篇。原子笔记的好处是复用性强多个主题都能链接到它而且单篇维护成本低。第二层是 MOC 索引页相当于一本书的目录加导读。比如“LLM 学习路线”这个 MOC下面按模块列出核心概念链接并写几句引导语说明学习顺序和重点。MOC 不存储具体知识内容只做导航这样即使笔记几百篇打开一个 MOC 就能找到入口。第三层是标签和属性负责横向聚合。比如给所有关于“训练”的笔记打#train给所有“数据准备”相关笔记打#data再加上 YAML 头里的状态字段status: learning/done就能用 Dataview 自动生成“待复习”“已完成”清单。这三层组合起来既保留了文件夹的秩序感又摆脱了单一分类的僵化。2. 核心细节解析与实操要点2.1 知识库目录设计从确定到可扩展虽然 wiki 强调不靠文件夹但完全不建文件夹几百个文件堆在一起照样乱。我采用的方案是“大类文件夹 索引反链”。根目录下先建这几个文件夹00-Inbox临时收集还没整理的内容放这里10-Concepts基础概念原子笔记20-Models具体模型、模型架构相关30-Training预训练、微调、RLHF 等训练相关内容40-Inference推理优化、部署、量化相关内容50-ApplicationsRAG、Agent、AIoT 等应用方向60-Tools框架和工具的使用笔记Transformers、vLLM、Dify 等70-Resources外部资源索引、论文清单、路线图90-MOC所有 MOC 索引页集中放99-Templates模板这套结构我用下来觉得比较顺手数字前缀让排序固定大类之间边界足够清晰又不至于细到无法归类。初期不建议超过 10 个文件夹类别越多整理成本越高最容易半途而废。2.2 核心知识点卡片的写法原子笔记的质量直接决定整个知识库的价值。我自己给 LLM 概念笔记定了一个四段式模板一句话定义、核心原理含必要的公式或流程图引用、代码/实验对照、链接和参考。举个例子写“KV Cache”时第一段一句话说明它是在推理阶段缓存历史 token 的 Key 和 Value避免重复计算第二段解释为什么生成是逐 token 的、如果不缓存复杂度会怎么变并画个简单示意第三段贴一段用 Transformers 库use_cacheTrue/False的对比推理时间第四段链接到“Self-Attention”“推理优化”“长上下文”等相关笔记并附上原始论文链接。这里有一个我踩过坑才总结出来的经验不要直接把别人的文章全文复制进来。复制的内容不会进脑子而且容易堆积成信息垃圾。我的做法是看完一篇文章或一段课程后用自己的话写 200 到 500 字的总结原文链接放进“参考”字段。这样既训练了理解也保证知识库里每一篇都是可读的原创笔记。2.3 模板与元数据让笔记“自动”组织起来纯靠手动维护几百篇笔记的状态不现实。我在每篇笔记头部加 YAML Front Matter字段包括title笔记标题tags主题标签statusidea/learning/done三态created/updated创建与更新时间source参考来源URL 或论文标题typeconcept/model/tutorial/moc等配合 Obsidian 的 Templater 插件新建笔记时按个快捷键就自动填充模板created自动生成不需要手敲。有了这些元数据第三层能力就出来了Dataview 可以按状态汇总待办按标签列出某主题全部笔记按更新时间找出“超过 3 个月没看”的旧笔记。这一步看着不起眼却是知识库从“一堆文件”变成“管理系统”的关键转折。2.4 双链使用原则宁缺毋滥双链是 wiki 的灵魂但一开始很容易上瘾写什么都加一堆[[]]最后图谱变成一团乱麻。我的原则是链接必须能回答“为什么点过去”凡是不解释关系的链接都不加。比如在“RAG”笔记里链接“向量数据库”语气可以是“关于索引方案见 [[向量数据库选型]]”而像“Transformer”这种每个概念都会碰到的词只在首次核心处链接一次不重复堆。另外我要求每个 MOC 页面同时承担“反向目录”的角色。每次新建概念笔记时顺手把链接挂到对应 MOC 下如果发现已有链接绕开了 MOC就检查是不是需要建一个新的 MOC 或者调整分类。这套“双向维护”的习惯保持住知识库就不会失控。3. 实操过程与核心环节实现3.1 初始化 Obsidian 仓库与核心插件开始之前先把环境准备好。我用的是 Windows 笔记本Obsidian 直接官网下载数据目录放在一个英文路径下比如D:\llm_wiki避免有些插件对中文路径支持不好。初始化步骤如下新建空仓库仓库路径指向D:\llm_wiki。按第 2.1 节建好文件夹目录。在“设置-核心插件”里开启反向链接、标签页、关系图谱、模板、日记。安装四个社区插件Templater增强模板、Dataview数据索引、Excalidraw画图、Advanced Tables表格编辑增强。在99-Templates里建concept.md和moc.md两个模板。这里提醒一句插件不是越多越好我装过十几个插件最后日常用到的就上面这四个。Obsidian 社区插件坑不少兼容性问题偶尔会出现建议装一个验证一个别一次性批量装。3.2 从零建立第一张 LLM 学习路线 MOC我的第一张 MOC 就是“LLM 学习路线”这个问题对新手最重要也最适合用它来验证知识库结构。页面分四个板块学习路径概览按阶段列出链接比如“基础篇 [[什么是LLM]]、[[Tokenizer与Token]]、[[Transformer架构]]”再到“训练篇 [[预训练目标]]、[[SFT]]、[[RLHF]]”再到“应用篇 [[RAG]]、[[Agent]]、[[模型部署]]”。当前学习进度用 Dataview 列出status: learning的笔记一眼看到卡在哪。资源索引链接到我收藏的文章、论文、视频播放列表。待办和疑问随手记录学习中产生的问题定期清理。MOC 写好后我不是一口气写完所有概念笔记而是“按需创建”学到哪个概念就新建对应原子笔记写完补链回 MOC。这样一周下来学习路线页会自动长成一棵树而不是一份空有框架的计划表。3.3 用 Dataview 做自动索引和状态看板Dataview 是 Obsidian 生态里最强大的插件之一它的核心能力是“用类 SQL 的方式查询笔记库”。我常用的三个查询第一个是按状态汇总TABLE status, tags, updated FROM 10-Concepts WHERE type concept SORT status ASC, updated DESC第二个是在每个 MOC 里列出“还没学完”的笔记LIST FROM 10-Concepts WHERE contains(file.inlinks, this.file.link) AND status ! done第三个是发现长期没更新的笔记安排定期复习TABLE updated FROM 10-Concepts WHERE date(updated) date(today) - dur(90 days) SORT updated ASC把这些块直接写在笔记正文里打开页面就会自动渲染成表格或列表不用手动维护。我第一次跑通的时候感觉整个世界都清爽了——知识库自己会告诉你“该复习什么”“哪些还没学完”比任何待办软件都靠谱。3.4 把外部资料包进来PDF、代码、URL做 LLM 相关学习资料类型很多论文 PDF、GitHub 代码、网页文章、B 站视频。我的处理方式是在70-Resources下建“论文索引”和“文章收藏”两篇笔记统一用表格记录“标题、作者、链接、一句话总结、相关笔记链接”。对于本地 PDF我直接用 Obsidian 自带的链接语法[[论文文件名.pdf]]嵌入对应笔记配合 Zotero 一起用效果更好。GitHub 仓库则在笔记里用普通链接并手写几行代码版本说明比如“用了哪个 commit 跑通的”。小技巧是每个外部资源都必须在相关原子笔记中出现一次链接否则就属于无效收藏——这是我对“收藏等于学会”这个坏习惯的强制免疫手段。4. 常见问题与排查技巧实录4.1 链接断链和“孤儿笔记”怎么处理知识库用久了最常遇到的问题就是链接指向不存在的笔记、或者一篇笔记没有任何链接也没有任何反链。Obsidian 本身有“孤立的笔记”核心插件打开后能在左侧面板看到没有入链的文件。我一般每个周末处理一批能补链接的补链接补不了的要么挂到00-Inbox重新整理要么果断删除。这里我想强调一件事知识库不是仓库不是只进不出定期清掉没用的笔记留下的内容质量才会高。4.2 笔记越来越乱定期“复盘整理”的节奏即使有结构时间长了也会乱主要表现是MOC 里链接越来越多但条目之间没有顺序两位同行概念分别写了两篇笔记内容高度重叠有些笔记只用过一次已经被新知识替代。我的整理节奏是每月一次“知识库大扫除”先看 Dataview 的更新列表再检查标签是否冗余然后合并重复笔记最后把每个 MOC 的内容重新排一遍顺序。这个方法听起来简单但能一直保持知识库可用比任何高级技巧都重要。4.3 问题排查速查表我把实际踩过的坑和解决办法整理成了表格遇到类似问题可以直接对照。现象原因解决方法新建笔记没有自动套模板Templater 模板目录未设置在 Templater 设置里指定模板文件夹并把“触发模板”快捷键绑定好Dataview 查询不显示内容查询语法或字段名不匹配检查 YAML 字段名是否和查询里一致注意大小写和空格关系图谱一团乱双链乱加缺少索引节点删掉无意义链接确保所有原子笔记至少挂在某个 MOC 下同步后笔记互相冲突多端同步导致的冲突文件优先用官方同步或 Git 同步避免两个客户端同时编辑同一笔记图片和附件丢了附件路径配置导致移动文件后失效在设置里把“附件默认保存路径”固定到一个文件夹例如80-Attachments电脑上打开仓库卡顿仓库太大且启用了大量插件把00-Inbox里的大文件清掉关闭不用的插件或把核心库和临时库分开4.4 备份与多端同步建议知识库是资产不备份等于裸奔。我的方案是本地目录直接用 Git 管理每次整理完手动 commit 一次同时用一个网盘文件夹做自动同步。注意 Markdown 文件纯文本Git 对文本比较友好diff 也清晰。如果更懒一点Obsidian 官方同步每月订阅也不贵胜在省心。我不太建议用某些第三方实时同步工具直接同步整个 Obsidian 目录因为索引文件.obsidian里的配置容易在多端之间互相覆盖轻则设置丢失重则插件异常。5. 后续扩展从个人知识库到可对外分享的 Wiki5.1 接入本地大模型做语义问答llm_wiki跑起来之后我做的第一个扩展是给知识库接上本地大模型实现“问自己的笔记”功能。做法就是用常见的 RAG 流程把10-Concepts等文件夹里的 Markdown 文档做分块用 embedding 模型转成向量再用一个开源问答模型做检索增强生成。开源社区里有不少相应用工具直接指向本地仓库目录就能工作。这一步做完相当于知识库拥有了语义检索能力过去“明明记得写过但搜不到”的问题基本消失。5.2 一键发布成静态 wiki 站点很多知识积累到一定程度就值得分享给团队或者社区。Obsidian 笔记想要对外发布我试过两条路一是用 Quartz、obsidian-export 这类工具把仓库导出成静态网页再部署到 GitHub Pages 或 Cloudflare Pages二是用 Digital Garden 这类插件直接搭建一个数字花园站点。两个方案都不需要维护数据库Markdown 改完同步即可。我更推荐先把隐私信息清理干净再选择一个单独的子目录做公开发布避免把整个仓库都晒出去。5.3 从学习仓库变成真正的工作资产到这一步llm_wiki对我来说已经不只是学习笔记了。遇到新模型、新框架我会先在知识库里检索有没有相关积累然后直接基于已有笔记产出技术方案、实验记录甚至周报素材。下个项目如果需要调研“垂域 LLM 数据准备”也能从知识库里快速拉出之前整理的数据清洗、标注、去重相关笔记省掉了大量重复资料收集时间。我个人实操中最深的体会是知识库的搭建从来不是一次性工程它是靠日记累加、周度维护、月度大扫除慢慢养出来的。与其追求一开始就规划得完美不如从今天建一个llm_wiki仓库写完第一篇“什么是 LLM”顺手挂到一张空白的 MOC 上。等笔记数量跨过一百篇你会明显感觉到这种“维基式”组织方式的价值——知识开始自己连接起来了。
