LLM Wiki 是一种借助 LLM 持续维护有效知识的方法；
OKF 则是让这套知识能够在不同工具之间交换的开放格式。
现在我们来探讨一些 LLM Wiki 相关的工程实践。
一、为 AI Coding 创建可维护的上下文知识地图
LLM Wiki + OKF 的一个应用场景是 AI Coding，特别是对大型企业应用 — 它们通常依赖于大量、多形态、且不断演变的领域知识。
LLM 的强大很容易制造一种错觉：模型看得懂代码，所以它便能理解我的项目。但事实上，看懂一段 Java 或 TypeScript，和理解“这段逻辑为什么只能放在这一层”、“这个接口为什么不允许跨模块直调”、“这段无用的代码为什么不废弃”，是两回事。
一个大型的企业软件系统常常涉及多个代码仓库与多个系统层次。真正的业务、技术与数据知识往往散落在需求与设计文档里，很多边界藏在工程师的脑海中，而各种接口协议又可能分布在代码和配置文件里。
可行的方法是构建一个面向 Coding Agent 的 OKF Knowledge Bundle（知识包）。
如何设计这张知识“地图”
这个 Wiki 知识库独立于工具和编程语言，也不依赖数据库与向量索引。你可以围绕 Agent 在完成编程任务时真正需要经过的路径来组织：理解业务、理解架构、选择技术、确认边界、寻找接口和数据，完成设计与编程。
比如这样一个 LLM Wiki 知识库：
这套目录并非 OKF 定义，而是自己定制的一套本地专有知识体系。还记得吗 — OKF 只提供最小的互操作格式规则，真正的知识结构由你自己来决定。
根index.md是 Agent 的上下文入口。它告诉 Agent：
你可以读取 business 目录了解业务流程；并从 architecture 学习架构知识；编码时则需要从 engineering 等读取编码规范、API、数据模型等。
index.md 负责导航；知识单元承载知识；而源码负责代码事实。
如何从 LLM Wiki 加载上下文
Wiki 建好后，不是把所有页面一次性塞进上下文（代价太高）。你需要指导 Agent 如何阅读：先看全局地图，再沿目录和关系逐层下钻，获得完成任务所需的最小完整上下文。你可以在 Coding Agent 的全局规则或者 Skills 中给予提示，例如：
- 先读根索引 index.md，判断并选择最相关的知识域- 读取对应目录索引 index.md - 加载相关的 Concept，并沿必要的 Markdown 链接继续展开，补齐必要的知识信息- 区分已核验事实、来源观点和你的推断；资料不足时标记知识缺口- 上下文足够后停止导航，执行输入任务这是一种典型的“基于知识地图的渐进式上下文加载”。
假设你的需求是：
“为订单失败增加自动补偿机制”
那么 Agent 可以这样加载上下文：
在此过程中，Agent 在必要时会回到代码核验方法签名、配置项、字段和真实调用链等，因为 LLM Wiki 页面更适合描述相对稳定的知识、约束和规则等，代码仍然是当前实现的最终证据。
为了方便 Agent “探索”知识库，一个实用的 AI Coding 的知识库最好同时记录结论和必要证据信息。你可以在知识单元中维护更多的元数据。比如：
resource：指向对应代码、OpenAPI 规格、数据库 Schemasource_commit：固定已经核验的代码版本owner：说明由谁负责维护，责任人是谁review_status：区分草稿、Agent 推断、人工确认和已废弃timestamp：最近一次有意义的更新时间；正文：进一步写清本知识适用条件、反例、何时要核查代码等
注意，这个 OKF 知识库应由 LLM 负责维护，人工负责审核与指导。
如何让知识产生“复利”效应？
这种由 LLM 持续维护的知识体系的另一个好处是可以产生“复利”效应。比如，一次开发任务中可能会：
- 发现新的跨模块约束，并补进架构页
- 验证了某个 API 的副作用，可以更新 API 契约页
- 测试过程发现新的失败模式，可以加入 Checklist
等等。这样下次 Agent 就不必重蹈覆辙，知识地图会随着任务逐渐完整。
具体到实现方法，可以让 Agent 在任务过程中把一些有价值的输出直接沉淀下来。
比如把推理结果写入到 outputs / 目录（自定义格式），随后让 LLM 整理出有长期价值的结果，并在审核后（通过 PR 提交）回流到 Wiki，为下一次探索留下可复用制品。
你也可以在任务结束后，让 LLM 根据生成的代码与制品，整理出可能的新知识。
以上介绍了 LLM Wiki 在 AI Coding 中的应用实践。这种经过整理的、半结构化、持续维护的企业知识体系，还可以在企业内部的知识培训、共享与传递、检索问答、客户服务等多个领域发挥作用。
二、在 Obsidian 中构建 LLM Wiki 知识体系
Obsidian 已经成为很多人的知识库选择，特别是它强大的知识表示、链接能力与丰富的插件。
如果把 LLM Wiki 的构建类比成“编译”，Obsidian 则可以作为你的 IDE：既可以保存你的原始笔记，也可以保存“编译”后的 Wiki；并提供编辑、链接与图谱展示的 UI。
我们先看两种在 Obsidian 中编撰 LLM Wiki 知识体系的方法。
路径一：借助 Obsidian 的 LLM Wiki 插件
Obsidian 中有个第三方的社区插件 Karpathy LLM Wiki。它把 LLM Wiki 的摄入、查询和维护流程直接放进 Obsidian，只需要配置一个 LLM 即可。
大致的使用方法如下（具体请参考插件说明）：
1、搜索并安装，在插件设置中设置模型提供商：
2、从 Obsidian 命令面板执行“摄入单个源文件”，或者“从文件夹摄入”、“多选文件摄入”。插件可以读取 Markdown 笔记或 PDF（需要 LLM 支持），然后由 LLM 总结、提取实体和概念等，生成带别名、来源与[[Wiki Link]]的知识页面，并维护索引wiki/index.md。原始笔记保持不变，新知识则默认写入以下目录：
3、构建完成后，可以打开插件的右侧面板“查询 Wiki”，与你的知识对话。
注意这里的对话并没有使用传统的 RAG 方法，而是从 index.md 导航进入，再沿页面中的[[Wiki Link]]图进行扩展，最后得出答案，所以无需配置嵌入模型。
4、后续知识维护。
这个插件并不只负责一次生成。它可以定时自动检查重复页、断链、空页、孤立页、缺失别名和矛盾等问题，并智能修复；也可以“监听文件夹的改动”并自动摄入：
你还可以定义自己的 Schema 描述，来决定最终的知识结构。上面看到的输出结构，是在默认的 config.md 中定义的（该结构会被注入 LLM 提示词）：
该插件适合个人的小型知识库：安装简单，使用界面完整，几分钟就能看到结果。不过，该插件目前生成的 LLM Wiki ，还不是一个符合 OKF 标准的 Bundle，你可以尝试自定义 config.md 来调整其 LLM 输出格式为 OKF。
目前 Obsidian 社区中也有一些 OKF 插件，但功能还不够强大。
路径二：自定义生成 Wiki 的 Agent/Skill
如果你更看重 OKF 兼容、Git 审核，或需要接入企业数据源、自定义治理规则，可以参考上篇中介绍的方法构建自己的 Agent：
把现有的 Obsidian Vault 当作只读 Raw 来源。你仍然在熟悉的 Obsidian 环境里阅读、思考并用自己的语言记录笔记，由 Agent 在旁边维护一个独立的 LLM Wiki。
比如，你的知识结构可以像这样：
raw可以是符号链接，对应到自己的原始笔记。但要注意人工笔记不能被摄入 Agent 自动覆盖；Wiki 可以由 Agent 修改，但涉及隐私和重要决策的内容需要人工确认。
基于 Agent 的 LLM Wiki 构建流程：
- 发现新增或变化的笔记
- 读取相关 Raw 与已有 Concept，生成变更计划
- 更新概念页、交叉链接、索引和日志
- 执行格式、断链与必填元数据等质量检查（门禁）
- 通过 Git Diff 、 Pull Request 等提交给人工审核
这种方法的好处是灵活、强大、可以根据自己的需要定制维护逻辑、可以结合 Git 进行团队的共享知识治理；缺点是实现较复杂，具体而言又可以有不同的路径，比如：
- 借助 Agent 开发框架与 SDK（如 LangChain、Pi、Google ADK） 自行实现
- 直接调用现有的 Coding Agent 来完成 — 为它配备必要的 Skill 即可
自定义摄入 Agent 可以参考 GitHub 上 Google 官方 OKF 项目中的例子。
无论你的 LLM Wiki 是由插件还是自定义 Agent 生成，都可以直接用 Obsidian 打开，把它作为浏览界面，比如查看 Graph 视图（根据 Wiki Link 自动生成）：
借助 Obsidian 的双向链接与 Graph，可以帮助我们观察到知识页的结构与质量问题：某页是否成为异常中心节点、两个主题是否由某页连接、是否出现大量孤立页面、同一个概念是否因为缩写和全称被拆成多个节点等等。
三、LLM Wiki 与 RAG：定位与融合应用
在对 LLM Wiki 的应用有了一定基础后，让我们再次来认识它与 RAG 之间的关系。
定位：一个重在治理，一个擅长检索
很显然，两者的重点并不一样：
- LLM Wiki + OKF 的重点是在知识的组织、治理与交换：把文档整理、“编译”为标准格式的知识单元，并持续维护它们的内容、关系和索引。
- RAG + 向量检索的重点更偏向知识的运行时检索能力：根据当前问题，从大规模材料中召回候选知识内容，重排并组装进模型上下文。
用一个表格来总结：
| 维度 | LLM Wiki + OKF | RAG + 向量检索 |
| 定位 | 知识组织、治理、交换格式 | 运行时知识检索与上下文增强 |
| 核心任务 | 整理可复用、持续演化的知识 | 针对当前问题召回相关知识 |
| 工作时间 | 摄入、变更和审查时持续进行 | 预先做向量索引；查询时实时检索 |
| 主要单元 | 目录、概念页、链接、索引、日志、元数据 | Chunk、Embedding、元数据、索引、Reranker |
| 长期产物 | 可读、相互连接、可版本化的知识单元与地图 | Chunks、向量索引 |
| 加载方式 | 从入口索引逐层导航，按需读取知识单元，沿链接扩展 | 将问题向量化，召回 Top-K Chunks，排序后注入上下文 |
| 适用场景 | 需要理解定义、关系、规则、操作方法的知识探索 | 目标明确的事实查询、证据查找与大规模语料的问答 |
| 上下文 | 显式保留知识之间的层级、引用与依赖关系 | 切块割裂了上下文（可通过父子块、GraphRAG等缓解） |
| 优势 | 知识治理、重复利用、可移植、审计、渐进式披露 | 大规模、语义检索、长尾问题、多模态检索、响应速度快 |
| 主要风险 | 过度整理（丢失细节）、维护成本、大规模下的性能 | 召回知识的偏差、碎片化的知识丢失上下文、索引更新成本 |
总的来说：RAG 擅长快速找到可能相关的知识片段，而最常见的方式是借助向量索引；而 LLM Wiki 则擅长告诉 Agent 有哪些知识、彼此有什么关系，按什么路径读取，但具体查询知识的方式则由 Agent 决定。
融合：让 Wiki 成为知识源，RAG 成为查询加速层
由于二者在解决的问题领域、原理与方法存在如此大的区别，因此，两者不仅可以融合，还能够形成互补：
LLM Wiki 作为权威的、持续维护的知识源；而 RAG 则用来构建检索加速层。
这样的知识系统有两个循环：
- **知识准备与更新。**读取 Raw、定位受影响的知识单元、生成知识变更，经过门禁与审核后发布到 LLM Wiki；然后对 Wiki 构建 BM25与向量索引。
- 查询与上下文注入。根据问题的特点采用不同策略查询与组装上下文。比如：
查询具体的 API 规格或规范术语，可通过索引精确读取
只知道某个知识领域，可从
index.md渐进式下钻问题表达模糊或 Wiki 很大，先用 BM25 或向量定位候选知识单元
先用向量检索到具体知识块，再沿 Wiki Link 扩展必要的关联知识
例如，开发者要求 Coding Agent 完成任务：
“在订单创建完成后，调用物流平台 API 创建运单。”
那么 Agent 加载上下文的方式就可以是 LLM Wiki 与向量检索的配合：
这个例子可以简单概括为：沿着 LLM Wiki 理解应该怎么做；并用 RAG 查清 API 具体怎么调用。
LLM Wiki 并非万能：不要过度神话
在上面的例子中，理论上 Agent 也完全可以通过 Wiki 导航找到这个 API 相关的知识页。但这里必须要考虑的一个问题是：
如果你的知识规模非常庞大（知识页的数量、每一页的知识内容、Wiki Link 的数量），逐层探索 Wiki 也可能会带来性能下降与成本升高。
当然，这本身和你对知识组织与治理的能力有关。但整体而言，对于相对独立、结构明确的知识（如 API 规范、表结构、错误码等），通过 RAG 检索可以更高效、简单地定位信息。两者结合可以兼顾理解能力与检索效率。
实际应用时，可以随着规模扩大，按实际问题逐步增加基础设施：
- 几十到上百个 Concept，优先使用
index.md、文件路径和关键词 - 页面达到数千，且表达差异增大，增加 BM25 与向量混合检索
- 经常询问跨系统影响范围，增加链接图（Graph）与图查询
- 原始材料包含图片、录音和视频，增加多模态解析与检索能力
- 知识更新频繁，增加增量构建、缓存和索引一致性检查等
总之，不要因为新方法的出现，就轻易下“某某已死”的结论。很多时候技术演进只是能力边界的重新划分，而非新旧替代。成熟的技术决策者不应该追逐单一的新技术，而是深入理解每种技术的背景与价值，选择最合适的方案。
以上两篇文章，是我们对 LLM Wiki 概念、方法与实践的系统介绍。
LLM Wiki 的核心价值不是简单替代 RAG，而是让企业知识成为一套可理解、可维护、可持续演进的知识体系，而背后的核心能力来自 LLM。这种范式可以让 AI 能够基于一个持续成长的知识体系，更可靠地完成诸如 Coding 这样的关键任务。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～