先说几个核心判断：构建 LLM Wiki 这件事，虽然已有 Karpathy 原生范式作为参考，但目前仍处于早期探索阶段。它到底好不好用、是否适合你的场景，只有亲手实践才能得出答案。以下流程尽量贴近业界通用工程实践，希望能帮你快速搭建一个可落地的专属知识库。
动手构建LLM Wiki的最佳时机
今天的内容力求遵循 Karpathy 原生 LLM Wiki 范式并参考业界通用工程实践。但毕竟这是一个新生事物，究竟好用与否，我们需要亲自尝试，在实践中寻找适用与不适用的边界。
01 资料准备
- 创建
/raw文件夹，放入所有原始资料：Markdown、PDF、TXT 等格式均可。 - 强制规范：系统仅读取
/raw目录，绝不修改、覆盖原始文件。 /raw文件是唯一可信数据源，所有 Wiki 内容均基于此增量生成。
raw 只是示例名称，你可以根据项目自行命名。
02 知识库约束配置
可新建 SCHEMA.md 或 PURPOSE.md 配置文件，用于：
- 明确知识库的主题边界、写作风格以及知识粒度
- 统一页面结构，避免生成内容发散
它的核心作用是为 LLM 提炼知识时划定方向，确保全站风格与标准保持一致，不会跑偏。
03 增量编译
以文件为粒度执行增量编译，流程如下：
- 扫描
/raw中新增或变更的文件（旧文件通过哈希缓存自动跳过，避免重复处理） - 提取核心实体、概念和论点，生成完整的、独立的、结构化的 Wiki 单页（注意：必须是完整页面，而非碎片或分块）
- 自动在页面间建立前向
[[wikilink]]知识网络（提醒：反向链接不建议直接写入 Wiki 页面，这会增加页面复杂度和 tokens 消耗。可以用脚本单独构建反向文档，在需要时读取） - 级联更新：新增资料会自动刷新所有相关旧页面和旧链接，解决冲突信息（但要注意：级联更新可能引发“级联爆炸”，大幅提升 tokens 消耗甚至导致失败。最好设置一个限制，例如最大深度不超过20层）
- 自动刷新全局索引目录
04 全局索引
index.md 相当于 LLM Wiki 的系统级“目录”和全局入口，它的作用是让模型清晰掌握整个知识库的全貌。其中存储了所有页面的标题及核心摘要。
- 中小规模知识库：使用单文件顶层索引即可满足需求
- 大规模优化：如果
index总内容超出模型上下文窗口，或页面数量过多，就需要分层拆分为多级索引。例如保留全局index.md，但其内容改为指向各主题，然后在topics/目录下为每个主题建立单独的索引文件，如topics/Agent.md，其中存放该主题下的具体 Wiki 页面索引。具体分几层，需要根据项目需求灵活决定。
05 查询模式
模式A：原生标准模式（中小型知识库默认）
适用场景：知识库规模适中，索引可以完整放入 LLM 上下文窗口
流程：
- LLM 完整读取顶层
index.md - 根据摘要自主判断相关页面
- 读取完整 Wiki 页面全文
- 借助页面内的
wikilink进行多跳推理，基于完整上下文作答
特点：零向量、零检索碎片、零 chunk 割裂。这是 LLM Wiki 最纯正、效果最佳的原生范式。
模式B：大规模扩展模式（社区工程方案）
适用场景：知识库极大，维护分层索引变得复杂且低效
本质：向量检索仅用于定位页面，不直接生成答案
流程：
- 对 Wiki 全页建立向量索引，每个 chunk 都标记父页面 ID
- 用户提问 → 向量+关键词混合检索 → 召回 Top-K chunks
- 根据 chunks 中的父页面 ID，从文件系统读取完整原始 Wiki 页面
- LLM 基于完整页面 +
wikilink多跳推理作答
几个关键点需要特别注意：
- 向量检索只是辅助定位的插件，不能替代原生索引范式
- 绝对不使用碎片 chunk 作为上下文——这是 LLM Wiki 与传统 RAG 的本质区别
index依然保留，但降级为知识分类概览
说到底，没有绝对最好的技术，只有最适配场景的方案。有些场景重视质量且对成本不敏感，有些场景允许一定质量损失但必须严格控制预算。不存在不受现实约束的需求与产品，适合的才是最优解。