我们平时说“知识管理”真落到自己手里往往是一堆分散的笔记、收藏夹和文档碎片。折腾过一段时间之后我越来越确定一件事个人知识库这件事真正值钱的部分不是“记”而是“取”。而在大模型时代之前“取”这件事几乎全靠人工——打标签、维护目录、写摘要、建立关联每一项都是体力活。我做了一个叫llm_wiki的个人 wiki 项目核心思路很直接把大语言模型LLM插进知识管理的每个环节让笔记自己学会整理、分类、关联和回答。这篇文章就把它完整拆开讲讲整体设计、实现细节和我在实际搭建过程中踩过的坑给也想把 LLM 和 wiki 结合起来的读者一条可以直接照着走的路。这个项目适合谁两类人最值得看一是笔记积累已经多到检索不动、维护成本明显上升的 Obsidian / Notion 深度用户二是想学大模型应用开发但不想只停留在调 API、想做一个完整产品闭环的开发者。前者能直接抄走工作流后者能看到一个 LLM 应用从数据准备到功能落地的完整选型和取舍过程。1. 聊聊“llm_wiki”到底在解决什么问题1.1 不是“笔记软件”而是“第二大脑”很多人在搭建知识库时有个误区以为装一个 wiki 系统、建好目录结构就算知识管理了最后往往会变成“收藏从未停止整理从未开始”。llm_wiki一开始就不是朝着“更好的笔记软件”去的我把它定位成一个可以持续自我生长的内容系统目标是让“取”这个动作从“我记得我写过但找不到”变成“我问它它直接告诉我答案还附上原文出处”。这个定位的差别决定了后续所有技术选型。普通的 wiki 是一堆静态文件的集合llm_wiki在静态文件之上加了一层“理解层”。这层理解层由大模型提供能力负责在内容入库时自动做摘要、提取关键词、判断内容类型在内容存储后维护语义索引在用户检索时理解自然语言问题并组织答案。理解层的存在让知识库从“仓库”变成了“助手”这是整个项目最核心的定位变化。从实际使用的感受来说这个定位带来的体验差异是明显的。以前我写一篇关于“Prompt 工程”的笔记一个月后想找“怎么设计 few-shot 示例”就得很费力地去翻目录现在只需要在库里输入一句自然语言系统会直接定位到相关章节并给出带原文引用的回答。这不仅仅是检索效率的提升是知识调用方式本身的改变。1.2 大模型在知识库里的五个真实用途做llm_wiki之前我对“LLM wiki”的想象比较模糊觉得无非就是做个聊天机器人挂在页面上。真正梳理需求之后才发现LLM 在个人知识库里的作用远不止问答我拆出了五个实际用途自动摘要每篇笔记入库时由 LLM 生成一个结构化的“一页纸摘要”包括核心观点、关键术语、前提条件和关联主题解决“内容太多、扫一眼抓不住重点”的问题。语义标签传统的标签是靠人手动归纳写多了就混乱。LLM 可以基于全文内容自动生成语义标签保持标签体系的一致性。关联发现库里 1000 篇笔记时靠人眼根本看不出《RLHF 训练细节》和《ChatGPT 的系统提示词设计》之间有什么关系LLM 可以通过语义相似度找到这个关联建议你手动建立双向链接。自然语言问答这是最直观的用途但实现方式上有讲究不是把整个库塞进 prompt 里让模型回答而是要配合检索步骤先从库里找出相关内容再让模型基于这些内容作答也就是常见的 RAG 方式。内容巡检定期让 LLM 扫描全库找出过时的内容、重复的笔记、互相矛盾的段落生成清理建议。这五个用途覆盖了知识管理的全流程输入、组织、关联、检索、维护。把它们串起来之后LLM 就不是一个偶尔用一下的辅助工具而是知识库正常运转的底层基础设施了。2. 整体架构与工具选型思路2.1 为什么底层我用 Obsidian 而不是 Notion / Confluence其实一开始我考虑过直接用现成的知识库产品比如 Notion 或者 Confluence。Notion 的 API 生态不错Confluence 在团队协作上很成熟但最后我还是选了 Obsidian核心原因有三个。第一是数据本地化。llm_wiki的很多处理环节要跑本地脚本比如批量处理、定时巡检、向量化索引如果数据全放在云端本地脚本要走 API 来回传输效率和成本都不划算。Obsidian 的库本质上就是一个本地文件夹Markdown 文件是纯文本脚本可以直接读、直接写没有任何限制。数据在自己手里这个自由度对后续开发很重要。第二是块结构支持。Obsidian 支持块引用block reference这让“答案附出处”这个功能变得很顺滑。LLM 回答问题时可以精确到引用某一段落并通过[[笔记名#^块ID]]直接跳转到原文位置。这种精确到块的引用体验是 Notion 这类数据库型产品不太好实现的。第三是自动化生态。Obsidian 的 Templater、QuickAdd、Dataview 插件都提供了可编程的入口配合社区插件可以构建完整的工作流。我要的“笔记入库 → 自动摘要 → 生成标签 → 写入属性”这条链路在 Obsidian 里几乎不需要额外开发基础设施用插件就能串起来。当然Obsidian 也有短板比如多人同时编辑会有冲突、移动端体验一般、没有原生 Web 端。但llm_wiki定位是个人知识库这些短板基本不构成影响。如果你要做团队级知识库架构思路可以保留但底层大概率要换一个支持协作的系统。2.2 LLM 的选择本地小模型 vs 云端 API怎么权衡LLM 的选型是整个项目里最需要权衡的决策。我在试验阶段同时试了本地模型和云端 API最后在不同环节用了不同方案。本地模型我用的是一套 7B 级别的量化模型跑在单张消费级显卡上延迟在可接受范围内。本地方案最大的优势是隐私和成本。知识库里会有不少个人心得、内部资料如果全部发给云端 API心里总觉得不踏实。另外内容量大之后频繁调用云端 API 的费用是持续性的而本地模型跑起来之后边际成本接近零。代价是生成质量。7B 模型在没有经过微调的情况下做摘要和标签提取还行但做“关联发现”和“巡检建议”这种需要综合推理的任务时效果明显不如云端的大参数模型。我的策略是“轻重分流”简单任务走本地小模型复杂推理走云端大模型。比如入库时的摘要生成用本地模型每日知识图谱关联分析用云端 API这样成本和效果能找到一个平衡点。如果你没有本地 GPU 资源直接全部用云端 API 也可以跑通整个链路。一套 32K 上下文的 API 加上合理的重试和缓存机制初期个人库规模在几百篇笔记时每月的 token 消耗并不会很大。关键是不要在每次问答时把整个库塞进去一定要做检索后再喂给模型这个细节后文会详细展开。2.3 全链路结构从采集、清洗、入库到检索问答整个llm_wiki的链路可以画成一条流水线采集 → 清洗 → 入库 → 索引 → 检索 → 生成。采集端最常用的是浏览器剪藏插件把网页文章保存为 Markdown 落到 Obsidian 库的 “inbox” 目录。代码片段、PDF、微信读书的划线也会定期整理进这个目录。技术类内容我还会用脚本从技术博客和论文页面直接抓取结构化内容减少人工复制粘贴的工作量。清洗环节是很多人容易忽略的。网页剪藏下来的内容往往带有很多噪音比如导航菜单、广告、无意义的空行、代码块格式错乱。这个环节我会用脚本做规则清洗去掉无用元素把代码块和引用格式规范为标准的 Markdown。清洗的质量直接决定后面 LLM 处理的效果如果输入里有大量广告文本生成的摘要有大概率会提到广告内容。入库是第一个 LLM 介入的环节。脚本监听 inbox 目录的新文件检测到新笔记后触发处理流程生成摘要、提取标签、识别内容类型、判断是否与已有笔记重复。处理完成后原文件被移动到主题目录同时往文件的 YAML frontmatter 写入标题、摘要、标签、日期、来源链接等结构化元数据。这些元数据后面会被向量索引和检索模块使用。索引和检索用的是一套本地向量库。入库时每篇笔记被切成 300 到 500 个 token 的块每个块做 embedding 后存进向量库查询时用户的自然语言问题同样转成 embedding做相似度检索取回 Top K 相关块再连同原始问题和相关块的上下文一起交给 LLM 生成最终回答。这个“先检索后生成”的架构就是典型的 RAG。它的价值在于LLM 不需要记住所有内容只负责理解问题并组织检索到的材料既控制了 token 成本也降低了幻觉出现的概率。3. 核心功能拆解与实现细节3.1 自动摘要让每篇笔记都有一张“一页纸”自动摘要功能是我最早落地、也是日常使用频率最高的功能。它的实现逻辑并不复杂检测到新笔记入库后把笔记正文按段落读进来调用 LLM 生成结构化的摘要。早期我直接让模型“总结这篇笔记”结果输出的摘要质量不稳定有时只是把开头几句话换个说法。后来我把 prompt 改成了结构化指令要求模型按固定格式输出四部分核心议题、关键结论、涉及概念清单、可能的前置知识。结构化约束加上明确的输出格式质量稳定了不少。实际生成的摘要会写入笔记 frontmatter在 Obsidian 文件列表和搜索结果里都能直接看到不用打开正文就能判断这篇笔记是否值得读。为了控制 token 消耗我设置了长度阈值。5000 字以下的笔记一次性交给模型处理超过这个长度就分段生成再合并。摘要模型用的是本地小模型速度可以接受一篇 2000 字的笔记大约 3 到 5 秒能完成处理。注意摘要生成不要只截开头几百字。很多文章的关键结论在中间或结尾截断开头会导致摘要严重跑偏。完整内容处理或有条件时按章节分段处理质量差异很大。3.2 语义标签让内容自己会分类标签这件事听起来简单做起来很考验功力。人工打标签的问题在于标准不统一今天觉得“大模型”和“LLM”是两个标签明天又觉得可以合并时间一长标签体系就变成了一个不可维护的大杂烩。LLM 打标签的方案我试过两条路线。第一条是开放式生成把全文给模型让它自由生成 5 到 8 个标签。效果是标签很贴切但同一个主题的笔记在不同时间生成的标签可能差异很大导致聚类效果差。第二条是候选标签制维护一个标签表模型只能从候选表里选如果候选表里没有合适的可以建议新增。这种方式一致性明显更好代价是标签表需要定期维护。最终我采用了第二种思路的变体标签分两层。上层是主题域比如“LLM 理论”“Agent 应用”“工具与工程”是个稳定的枚举集合模型在这个过程中只需要做分类。下层是自由标签允许模型基于笔记内容生成具体的关键词比如“RAG”“prompt 压缩”“embeddings”。这种双层结构的好处是上层的主题域提供了稳定的组织框架下层的自由标签保留了灵活性检索时既可以从主题向下筛选也可以直接用具体关键词精准定位。3.3 双向链接与知识图谱自动发现你想不到的关系Obsidian 有一个 Graph view 功能可以把笔记之间的链接关系可视化成一幅知识图谱。但一个本地知识库如果全靠手动建链接图谱上往往只有零星几个节点大多数笔记之间是孤立的。llm_wiki的关联发现功能就是解决这个问题的。实现上我每天跑一次批处理取当天入库或更新的笔记对每篇笔记做 embedding然后与库中所有已有笔记计算相似度。相似度超过阈值的笔记对按分数从高到低生成一个“建议关联”列表。列表里每条建议附带相似的原因——这一步会调用 LLM 简述两篇笔记的关系比如“A 笔记中的 XX 概念与 B 笔记中的 YY 问题相关”。生成建议后我并不会自动写入双向链接。自动写入容易产生大量低质量关联把知识图谱变成一张没有信息的网。更合理的方式是生成一个“待确认关联”清单我在 Obsidian 里过目一遍确认有价值的才手动建立链接。人机协同的关键在这里机器做批量计算人做质量把关。实测下来每天新增 5 到 10 篇笔记的量级通过这个功能建立的链接比手动建的多出几倍而且经常能发现我自己都没意识到的主题交叉技术上算是有价值的“意外收获”。3.4 基于向量检索的智能问答把“找笔记”变成“问笔记”智能问答是这个项目对外展示时最亮眼的功能但实现过程中踩的坑也最多。最初我以为直接调用 LLM 的 API 就能实现问答试了之后发现效果很差问题集中在两点一是整个知识库塞进 context 既不现实也没必要二是即使塞得下模型会一本正经地“编造”答案给出库里根本不存在的“事实”。后来我改造为标准的 RAG 流程彻底解决了这两个问题。具体步骤是用户提交问题后先对问题做一次意图判断确定是普通知识查询还是需要跨多篇笔记综合回答的复杂问题。把问题 embedding 化在向量库中检索最相关的 Top K 个内容块。将检索到的内容块按相似度排序连同用户问题一起组装成 prompt。调用 LLM 生成回答要求模型必须严格基于提供的材料作答并在每个论断后标注来源笔记。把来源笔记的链接渲染在回答下方点击即可跳转到原文。问答的 prompt 里我特意强调了一句话“如果问题在提供的材料中找不到依据请直接回答‘库中没有相关内容’。”这句话听起来简单实际上是控制幻觉最有效的一条约束。为了进一步减少幻觉我把检索的 Top K 设为了 8并且会先过滤掉相似度低于 0.7 的结果。宁可不答也不要答错这是问答模块的基本准则。3.5 内容巡检让知识库不至于越用越乱个人知识库的维护是一个持续性问题。笔记积累到一定量过时内容、矛盾观点、重复笔记都会出现。如果每天都靠人眼审阅全库显然不可行所以内容巡检交给脚本定时执行。巡检任务每周跑一次会用 LLM 扫描最近一段时间更新过的笔记输出一份“巡检报告”内容包括疑似重复的笔记对、观点有明显冲突的段落、明显过时的技术方案描述、以及长期没有被访问和引用的“冷内容”清单。重复和冲突这两项按相似度加关键词规则就能粗筛出来冷内容则用时间和引用次数做统计。得到报告后正常的处置路径是人工确认再执行。重复笔记可以合并或归档冲突内容要人工判断保留哪个版本过时描述则在原文中标注“已过时”并附上新方案的链接。冷内容我一般不会直接删除而是归档到 “archive” 目录保留历史记录又不会干扰主检索范围。提示AI 巡检的价值是“发现问题”最终判断和修改还是要人来执行。不要开自动修改权限我试过让模型自动合并重复笔记结果它把两个相似但不完全相同的方案合并得面目全非教训很深刻。4. 实操过程从零搭一个带 LLM 的 wiki 知识库4.1 第一步初始化 Obsidian 库与基础配置如果你打算照着做第一步先建一个干净的 Obsidian 库并规划好目录结构。我的目录结构经历了多次调整最终稳定为以下形式llm_wiki/ ├── 00_inbox/ # 剪藏和速记的临时入口 ├── 10_topics/ # 按主题域组织的正式笔记 │ ├── llm_theory/ │ ├── agent_apps/ │ ├── engineering/ │ └── reading_notes/ ├── 20_archive/ # 冷内容归档 ├── 30_templates/ # Templater 模板 ├── 40_assets/ # 图片、附件等静态资源 └── 90_meta/ # 知识库内部配置文件与索引目录命名以数字开头是为让排序逻辑先按目录结构再按数字顺序走避免一堆中文目录名在排序时乱成一团。Obsidian 里关闭“新建文件位置”的默认选项让新文件统一落到00_inbox这是整个自动化流水线的入口规范。基础配置上有几个插件是必须装的Templater 用来控制模板逻辑和后处理钩子QuickAdd 用来为“收藏新文章”这一类高频动作添加快捷命令Dataview 用来按元数据动态生成索引页Breadcrumbs或同类插件用来管理主题层级关系。插件不要装太多装三个处理工作流、一个做查询就足够了装多了配置复杂度会直线上升。4.2 第二步部署向量库并接入 LLM API向量库的选择范围很广从轻量级方案到重量级方案都有。个人知识库的场景不推荐一开始就上需要单独部署服务的重型方案。我用的是一套本地文件型向量库所有向量直接序列化保存在本地进程重启不会丢。如果你是第一次搭可以先用类似方案跑通等数据量真的超过百万级向量再做迁移。接入 LLM 的方式也要提前想清楚。我建议做一个统一的 API 封装层把 LLM 的具体实现藏起来。封装层对外暴露两个方法generate(prompt, config)负责文本生成embed(text)负责生成 embedding。在配置文件里设置 provider 为local或cloud代码内部根据配置切换不同的实现。这样在本地模型和云端 API 之间切换只改一个配置项不需要改动任何业务逻辑。配置项大体包括以下内容文本生成模型本地路径或云端模型名Embedding 模型本地路径或云端模型名上下文窗口长度用于决定内容分块大小最大生成 tokens限制回答长度防止超预算温度参数摘要类任务设为 0.2 左右问答类任务设为 0.3 左右温度参数的设置是细节但影响很大。摘要、标签、分类这类“确定性任务”温度要低过高会产生不可预期的输出格式问答可以稍高一点但不要超过 0.5再高就开始出现自由发挥了。4.3 第三步用 Templater 构建“入库—摘要—标签”自动化自动化是整个项目体验的关键。我用 Templater 做了一个“捕获新内容”模板这个模板绑定了三个动作读取剪藏内容、清洗正文、触发入库处理。模板里先定义 YAML frontmatter 的初始结构标题、来源、创建日期、状态置为processing。正文清洗规则放在模板的预处理脚本里基本是一组正则替换移除多余空行、去掉图片外链的追踪参数、把行内代码段规范化。清洗完成后正文会被保存到00_inbox。关键的一步是在 Templater 模板中嵌入一段自定义脚本这段脚本会在保存完成后调用封装层的 LLM 接口执行摘要生成和标签提取。脚本执行顺序是先读取刚保存的文件正文做长度判断超长则分段然后调用generate方法生成摘要和标签最后把结果写回 frontmatter并把状态从processing改为processed。一个完整的模板执行过程大约 10 到 20 秒取决于笔记长度和用的模型速度。这期间 Obsidian 界面会短暂卡顿属于正常现象。为了避免误操作模板执行期间不要在编辑器里切换文件我一开始不知道这点经常在等待时点开别的笔记导致处理中断。4.4 第四步搭建检索问答接口检索问答接口我实现成了一个本地 HTTP 服务用一个轻量级框架起一个小服务监听本地端口。Obsidian 里通过一个自定义命令调用这个接口把当前问题发过去服务端处理完后把结果和来源链接以 Markdown 格式插入到当前编辑器中。问答服务的核心逻辑是接收问题 → 问题 embedding 化 → 在向量库中检索 Top K 块 → 过滤低分块 → 组装 RAG prompt → 调用 LLM 生成 → 解析回答和引用 → 返回结果。整个流程平均耗时在 3 到 8 秒之间具体取决于检索到的内容块数量和模型速度。掐断问题的数据来源是保证回答质量的关键。检索返回的内容块要带上原始笔记的路径和标题组装 prompt 时材料按相似度从高到低排列。回答解析要同时输出正文和引用列表引用格式统一为[[笔记名#标题]]可以直接在 Obsidian 里点击跳转。4.5 第五步定时巡检与图谱刷新巡检任务我用系统级定时任务调度每天跑一次向量索引刷新每周跑一次全库巡检。索引刷新只处理当天变更过的文件巡检则对指定时间窗口内的笔记执行批量分析。巡检脚本会输出一份 Markdown 格式的报告落在一个固定的90_meta/weekly_report.md文件中。报告里列出重复笔记对、冲突观点、过时描述和冷内容列表。Obsidian 的首页会嵌一个 Dataview 查询把这个报告的最新内容直接展示在打开库的第一屏上这样我每次打开 Obsidian 就能看到本周的维护建议。图谱关联功能运行在同一批巡检任务里计算完相似度后生成“建议关联清单”。这个清单我会在周末花几分钟过一遍确认有质量的关联就手动补上双向链接。整套流程跑稳之后知识库的日常维护时间从每周几个小时降到了 20 分钟左右。5. 常见问题与排查技巧实录5.1 典型问题速查表问题现象可能原因解决办法摘要生成结果与正文无关清洗不彻底广告或导航文本混入正文检查清洗规则先把正文提取步骤独立验证标签大量重复或风格不一致标签生成采用全开放方式改为候选标签制维护一个稳定的主题域枚举问答给出库中不存在的答案RAG 检索召回不足模型无中生有降低相似度阈值提高 Top K在 prompt 中强调未知则拒答关联建议太多且无价值相似度阈值太低提高阈值建议控制在 0.75 以上再做人工确认批处理时 Obsidian 卡死脚本在主线程执行脚本改为异步执行或把重活放到外部服务token 消耗增长过快每次处理都传入完整全文设置长度阈值超长文档分段处理检索时只传相关块本地模型摘要比云端差很多小模型对长上下文推理能力弱简单任务用本地复杂推理任务切换到云端巡检报告误报太多规则过于宽松先用规则粗筛再用 LLM 二次校验最后人工确认排查的顺序有讲究。遇到问题时先用最小化样例定位准备一篇干净的短笔记只跑摘要生成能跑通再逐步加载完整流程。信息差越早缩小问题越容易暴露。提示不要跳过日志。第一次搭自动化流水线我完全没做日志出问题时只能靠肉眼盯命令行输出。后来我把封装层每个步骤的关键参数和执行耗时都写了日志排障时间缩短了几倍。5.2 几个踩过坑后我才明白的细节第一次做全库向量化的时候我没做增量处理每篇笔记入库都重新对整个库建索引。数据量还小的时候感觉不明显等笔记超过 500 篇每次入库的等待时间就变得难以忍受。后来改成增量索引维护一个“已索引文件哈希表”只有文件哈希变化才重新生成向量。这一步优化之后入库耗时从几分钟降到几秒。还有一次问答服务直接调用了云端 LLM结果一天下来 token 消耗高得吓人。排查发现是向量检索的 Top K 设置得太大而且没有过滤低分块一些与问题无关的内容块也被拼进了 prompt白白浪费了大量 token。后来我加上了相似度阈值过滤并允许用户在问答时手动调整检索范围成本立刻大幅下降。第三个教训是关于 prompt 的稳定性。标注式 prompt 不写死格式模型的输出格式经常飘。后来我强制要求模型输出 JSON 结构并在代码里做了解析重试如果连续两次解析失败就换一个更短的 prompt 重试一次再失败则使用默认摘要。这个兜底逻辑虽然朴素但保证了流水线不会因为一次格式错误而中断。6. 项目后续还能怎么扩展llm_wiki目前已经稳定运行了一段时间笔记规模从最初的一两百篇长到了上千篇检索和问答的体验还在可接受范围内。后续我准备做几件事一是把本地模型换成一个参数量更大的量化模型提升复杂推理任务的质量二是增加一个基于浏览器的采集入口让剪藏后的网页能自动完成清洗和摘要不需要再回到本地手动操作三是把“巡检报告”中的人工确认流程进一步简化做成一个小的轻量级审批界面。如果你准备做类似的系统我强烈建议你从最小闭环开始先只做“自动摘要 标签”这两件事跑顺之后再逐步加问答、关联和巡检。一上来就铺开所有功能会陷入脚本互相干扰、错误难以排查的泥潭。这个项目最让我意外的收获不是技术上的而是它真的改变了我的知识管理习惯。以前整理笔记靠毅力现在整理笔记靠系统而且系统能在我需要的时候把内容重新找回来。大模型时代的知识管理不再是“整理过去”更像是“经营一个会生长的内容生命体”。从工具使用的角度来说把 LLM 接进 wiki 这件事值得每个内容积累量不小的创作者认真做一次。