从 RAG 到 llm-wiki：为什么个人知识库更适合做成“编译型系统”？

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

这篇文章从工程视角解释 Karpathy 提出的 llm-wiki 思路：为什么个人知识库不该只做一次性检索，而更适合按 Raw/Wiki/Outputs/Log 分层，做成可持续编译、可追溯、可维护的知识系统。

很多人对“个人知识库”的第一反应，还是两种老路：

一种是把资料不断剪藏进笔记软件，最后变成一个巨大但很少回看的仓库；
另一种是把资料丢给 RAG 系统，希望在提问时临时检索、临时生成答案。

这两条路都能用，但都不够理想。

普通笔记系统的问题，不是存不下，而是“存了之后不继续生长”。你收藏了文章、论文、代码仓库、截图和评论，但这些内容大多还是原材料。它们之间的关系、冲突、上下文和演化过程，并不会自动长出来。时间一久，你得到的是一个资料堆，而不是一个真正能复用的知识系统。

一次性 RAG 的问题，则是“每次都从头想一遍”。你问一个问题，系统去原始资料里检索几段上下文，再现场组织回答。这个办法适合问答，但不适合长期积累。因为它通常不会留下足够清晰、可维护、可复查的中间产物。下一次问相近的问题，系统很可能又重新检索、重新拼装、重新生成一遍。知识并没有被真正沉淀下来，只是被临时调用过一次。

Andrej Karpathy 最近提出的 llm-wiki 思路，值得关注，恰恰是因为它换了一个角度：不要把知识库设计成“每次查询时临时推导答案”的系统，而要把它设计成“持续编译知识”的系统。

简单说，就是：你负责剪藏，LLM 负责理解、整理、连接、补充和维护。

这听起来像一句口号，但如果把它落实成一个真正可运行的目录结构、工作流和操作规范，它其实对应的是一种很有工程味的知识系统设计方法。

先把问题讲清楚。

1. 普通笔记系统的问题：有存储，没有编译

很多人的 Obsidian、Notion 或者飞书文档里，资料已经很多了，但常见问题有三个：

第一，原始资料和结论混在一起。你很难分清哪些是原文摘录，哪些是自己的理解，哪些又是某次临时整理出来的观点。久而久之，信息污染会越来越重。

第二，链接是手工的，结构是偶然的。今天你记了一个“RAG”，明天记了一个“知识蒸馏”，后天记了一个“Agent memory”，这些东西彼此相关，但如果没有持续整理，它们只是共存在一个仓库里，并不构成网络。

第三，笔记系统默认不处理冲突。同一主题在不同来源里有不同说法时，多数人只是把它们都存下来，却没有进一步标注：哪些是一手证据，哪些是二手总结，哪些已经被新资料推翻。

所以传统笔记系统擅长“收集”，不擅长“持续沉淀”。

2. 一次性 RAG 的问题：有检索，没有记忆产物

RAG 的优点很明确：快、灵活、适合从大量文档里回答问题。

但它的短板也很明确：

它主要服务于“当前这一问”；
它的中间整理过程往往不会沉淀成稳定资产；
它不天然要求把矛盾、置信度、来源层级显式写下来；
它对“相似问题的连续迭代”支持不够好，因为每一轮都可能在重复做类似工作。

你今天问“模型蒸馏和知识蒸馏有什么关系”，系统会找资料、拼回答；明天问“为什么蒸馏在小模型部署里重要”，它又可能重新检索同一批文档。表面上看答案出来了，实际上系统并没有形成一份被维护过的“蒸馏主题页”。

这就是 llm-wiki 想解决的问题：把一次次零散问答，变成一个持续演进的知识工件。

Karpathy 这套思路最值得借鉴的地方，不是某个具体工具，而是它的系统边界划分。

它大致可以概括成四句话：

Raw 层不可变。 原始来源就是原始来源，不能为了“整理得更好看”而直接改写。
Wiki 层由 LLM 维护。 LLM 不是只在对话里回答问题，而是持续把原始资料编译成结构化的 markdown wiki。
输出要持久化。 一个高质量答案不能只停留在聊天窗口里，而应该写入 outputs/，变成以后还能复用的资产。
矛盾与演化必须显式记录。 知识不是一块静态石碑，而是不断修订的工程产物，所以需要日志、版本和冲突标注。

如果用工程语言来讲，这种系统不是“问一次算一次”，而是“输入原始材料，生成和维护中间表示，再从中间表示生成面向问题的输出”。这很像编译器，而不像单次函数调用。

因此，llm-wiki 相比传统 RAG 的根本差异，不在于有没有检索，而在于检索和生成服务的是一个长期存在的知识结构，而不是一次性回答。

这类系统容易被误解成“让模型自己管理一切”，其实不是。

比较稳妥的边界应该是：

人负责输入方向和质量控制：决定研究主题、选择要剪藏的材料、确认重要合并动作、判断哪些结论值得采纳。
LLM 负责高频整理劳动：提炼主题页、更新链接、补齐缺失字段、发现矛盾、形成阶段性输出。
原始证据始终保留：任何综合结论都要能回溯到具体 source 页面，而不是只剩一句“模型认为”。

换句话说，llm-wiki 不是把“思考”外包给模型，而是把大量机械但高价值的知识整理工作交给模型，前提是规则足够明确、原始证据不可丢。

如果真要搭，建议至少分成下面四层。

knowledge-base/ ├── raw/ # 原始材料：文章、论文、网页剪藏、图片、PDF、代码说明等 ├── wiki/ │ ├── concepts/ # 概念页 │ ├── entities/ # 人、公司、项目、论文、模型等实体页 │ ├── sources/ # 每份来源的结构化摘录与元数据 │ ├── synthesis/ # 跨来源综合分析页 │ ├── outputs/ # 面向问题生成的可复用输出 │ ├── index.md # 入口索引 │ ├── overview.md # 总览与健康状态 │ ├── QUESTIONS.md # 待研究问题清单 │ └── log.md # 全系统操作日志 ├── scripts/ # lint、reindex 等脚本 ├── CLAUDE.md # 或 AGENTS.md：LLM 行为契约 └── README.md

这套结构里，最关键的不是目录名，而是职责分离。

Raw 层：只进不改

raw/ 里放的是你真正收集到的材料。文章、论文、截图、网页归档、代码仓库说明，都可以放进去。核心规则只有一条：原始层不做“内容级美化修改”。

原因很简单：只要原始层会被随手改动，后面所有摘要、链接、冲突分析都可能失去依据。实际操作里，至少应该给 raw 材料保留来源链接、摄入时间，最好再加一个内容哈希，例如 raw_sha256，避免后续误把变更过的内容当成同一份原件。

Wiki 层：让 LLM 维护结构化知识

wiki/ 不是原始资料堆，而是经过编译的知识层。这里的页面应该是结构化的、可链接的、可审查的。

比如：

concepts/ 里写“RAG”“蒸馏”“函数调用”“上下文工程”这类概念；
entities/ 里写公司、项目、人名、模型名；
sources/ 里保留具体来源页，作为结论回溯的锚点；
synthesis/ 里写跨多个来源才能形成的综合判断。

一个很重要的实践是：回答问题时，核心结论尽量回溯到 sources 页面，而不是只引用概念页。

因为 concept 页本身也可能是 LLM 整理出来的二次产物，如果不能回到 source，你就很难判断结论到底有多稳。

Outputs 层：让“好答案”真正留下来

很多人和 LLM 的交互，问题不在于答案差，而在于答案会消失。

今天问出一个不错的结论，明天聊天窗口一滚就没了。于是你下次还得再问一遍。

所以 outputs/ 这一层很关键。凡是高复用价值的问题答案，都应该保存成 markdown 文件。最好再附上：

生成日期；
涉及的主题；
参考了哪些 source；
哪些结论把握高，哪些只是暂定判断；
是否存在相互冲突的来源。

这样，知识库才会越来越像一套资产，而不是越来越像聊天记录。

Log 层：记录系统如何演化

log.md 往往最容易被忽略，但它非常重要。

你今天 ingest 了什么，今天 merge 了哪些页面，今天做了哪次 lint，今天产出过哪些 synthesis，这些都应该记下来。因为知识系统的价值，不只在“现在有哪些页面”，还在“它是怎么变成现在这个样子的”。

没有日志，就很难追踪错误来源，也很难回顾系统是否在变好。

如果你是个人用户、独立研究者或者工程师，完全没必要一开始就把系统做得很重。一个最小可行版本，大概按下面的顺序就够了。

第一步：先搭骨架，不急着灌内容

先建目录，再写规则文件。无论你用 Claude Code、Codex 还是别的 Agent，最重要的都是那份“行为契约”——也就是 CLAUDE.md 或 AGENTS.md。

这份文件要明确写清楚：

Raw 不可修改；
Wiki 页面如何命名；
哪些页面可以自动生成，哪些必须人工确认；
QUERY、INGEST、LINT、REFLECT、MERGE、ADD-QUESTION 分别怎么执行；
输出需要写入哪些目录；
冲突和置信度如何标记。

如果没有这份契约，LLM 每次都可能按不同习惯工作，知识库很快会失控。

第二步：用 Obsidian 打开，用 Web Clipper 喂数据

Obsidian 在这里更像一个 IDE，而不是单纯的笔记本。

它的作用不是替代 LLM，而是提供：

本地文件视图；
wikilink 浏览；
Graph 关系图；
搜索和手动巡检入口。

配上 Web Clipper 之后，你日常的工作会很简单：看到值得收藏的文章，直接剪进 raw/；至于整理、抽象、挂链接、归档到哪个主题页，交给后面的 ingest 流程。

这样做的好处是，“收集”与“整理”分离。你不用每次收藏时都做知识工程，先把素材稳定收进来，再由系统持续编译。

第三步：做一次全系统标定和 Audit

在真正日用之前，建议先跑一次系统级 Audit：

目录是否齐全；
命名规则是否统一；
source 页、concept 页、entity 页有没有混用；
是否存在无法回溯来源的结论；
索引是否与真实文件数一致；
旧页面之间是否已经有重复或近义冲突。

这一步越早做，后面维护越轻松。

llm-wiki 最容易失败的地方，不是技术，而是节奏设计太重。

一个更现实的日常节奏是这样的：

你的日常：每天 5 分钟

剪藏值得保留的内容到 raw/；
把临时想到的问题加进 QUESTIONS.md；
偶尔看一眼 overview 或 index，确认主题结构是不是跑偏。

LLM 的日常：批量做脏活累活

ingest 新材料，生成/更新 source 页面；
维护 concept、entity 之间的链接；
对已有 wiki 跑 lint，检查缺字段、断链、命名不一致、低质量条目；
定期 reflect，找出值得做成 synthesis 的主题；
把高价值回答写入 outputs/，而不是只回复在窗口里。

这时，知识库才真正开始出现“复利”：你不是每次都从零问，而是在不断复用已经编译过的结构。

1. INGEST：摄入

目标是把原始材料变成可用知识节点。

关键不是“总结一下这篇文章”，而是：

生成 source 页面；
抽取关键概念和实体；
识别是否应更新已有 concept；
建立必要的 wikilink；
记录这次摄入进了哪些页面。

2. QUERY：查询

QUERY 不是直接对 raw 做一锤子问答，而是先从 wiki 中检索相关页面，再回到 source 做证据核对，然后把答案输出到当前对话，必要时落盘到 outputs/。

一个好的 QUERY 流程，至少要做到三件事：

结论能溯源；
冲突要显式标注；
有复用价值的答案必须保存。

3. LINT：健康检查

知识库不是越大越好，关键是是否健康。

LINT 应该定期检查：

命名是否统一；
链接是否断裂；
页面是否缺少关键字段；
source 与 concept 是否脱节；
索引是否过期；
是否存在长期孤立、没人再引用的条目。

如果没有 LINT，知识库会慢慢退化成另一个资料堆。

4. REFLECT：二阶合成

这是 llm-wiki 最有价值的一步。

不是回答一个显式问题，而是让系统主动扫描整个 wiki，寻找：

跨来源模式；
隐性关联；
内容空白；
明显矛盾；
值得新写一篇分析文章的主题。

这一步本质上是在把“知识存储”升级成“知识发现”。

5. ADD-QUESTION：记录问题

不是所有问题都要立刻回答。有些问题更适合作为未来研究队列的一部分。

把问题正式写进 QUESTIONS.md，有两个好处：

它能驱动后续 ingest 和 reflect；
它让知识库不只围绕资料组织，也围绕真实认知缺口组织。

6. MERGE：去重与合并

知识库长大之后，重复页面几乎不可避免。

比如“function calling”和“tool use”可能部分重叠，“知识蒸馏”和“模型蒸馏”可能边界不清。此时必须支持 merge，但不建议让模型无条件自动合并。

更稳妥的做法是：

先给出合并方案；
保留主页面；
更新旧链接；
被合并页做 redirect；
在 log 里记录合并动作。

对个人知识库来说，这比“一删了之”要安全得多。

它特别适合三类人：

独立研究者：持续跟踪某个主题，需要把零散资料逐步沉淀成自己的结构化认知。
工程师：长期维护某一技术域，比如 Agent、推理系统、数据库、编译器、端侧 AI，希望把问题解法沉淀成可复用资产。
内容创作者：需要持续产出文章、演讲、分享材料，希望让过去的研究能为新的输出提供脚手架。

但它也不适合所有人。

如果你的需求只是“偶尔问几个问题”，那一个简单的 RAG 就够了；如果你的输入源本来就很少，维护一套 wiki 的收益也未必高。

llm-wiki 真正适合的是：输入很多、主题相对聚焦、并且你确实需要长期复用这些知识。

优点

知识会累积，而不是每次重算；
回答更容易溯源；
冲突和不确定性可以显式暴露；
输出可复用，不再困在聊天窗口；
随着资料增长，系统价值是复利式上升的。

局限

前期要花时间定规则；
LLM 维护 wiki 仍然可能引入幻觉或错误合并；
如果主题过杂，结构很容易失控；
隐私、版权、来源合规都需要自己把关；
没有定期 lint 和 reflect，系统很快就会老化。

常见坑

第一，过早追求全自动。 一开始最该自动化的是 ingest、链接、检查，不是“让模型自己定义真理”。

第二，混淆原文与观点。 一旦 Raw 层被污染，后面所有 synthesis 都会受影响。

第三，不做持久化输出。 如果 outputs/ 长期为空，说明你其实还在把知识库当聊天工具用。

第四，不记录冲突。 真实世界的信息本来就相互矛盾。把矛盾藏起来，只会让系统看起来更整洁，但更不可信。

如果你今天就想开始，不要想着“一次搭出终极知识库”，而是先做一个能连续用 30 天的版本。

我的建议是：

只选一个主题域起步。 比如只做“Agent 工程”或“端侧模型部署”。
先把目录和规则写死。 比如哪些是 source，哪些是 concept，哪些结论必须带 confidence notes。
强制 Raw 不可变。 这是整个系统可信度的底座。
要求所有高价值回答落盘。 不落盘，就不算完成。
每周至少跑一次 lint。 知识库和代码库一样，需要健康检查。
把 merge 视为高风险动作。 尤其是近义概念和跨语言页面，先看方案再执行。
允许系统保留“未解决问题”。 一个成熟的知识库不应该假装什么都知道。

说到底，llm-wiki 最值得学的，不是某个目录模板，而是它背后的认知：

知识管理不是把信息存起来，而是把信息逐步编译成自己以后还能继续调用、继续修正、继续扩展的结构。

当你这样设计个人知识库时，LLM 才不是一个“随问随答的聊天机器人”，而更像一个持续维护知识图谱、文档层和分析层的协作系统。

这也是为什么我认为，相比把个人知识库做成“更聪明的搜索框”，把它做成“编译型系统”更有长期价值。

如果你只想先做一个能跑起来的版本，下面这份清单就够了：

建一个本地目录：raw/ + wiki/ + outputs/ + log；
用 Obsidian 打开整个目录，方便浏览和巡检；
用 Web Clipper 把网页、文章、PDF 稳定收进 raw/；
写一份 CLAUDE.md 或 AGENTS.md，明确 INGEST / QUERY / LINT / REFLECT / MERGE 规则；
约定 source 页面是所有结论的回溯锚点；
规定高价值答案必须写入 wiki/outputs/；
规定每次重要操作都追加 wiki/log.md；
每周做一次 lint，每两周做一次 reflect。

如果这套最小版本你能连续用一个月，再去考虑更复杂的索引、脚本和自动化，而不是一上来就把系统做成一个庞大的“知识操作平台”。

对于个人知识库来说，能持续运行，远比看起来先进更重要。

说明：本文草稿基于用户提供的飞书教程要点、本地已保存的《LLM Wiki 搭建教程》剪藏内容，以及公开可检索到的 Karpathy 相关讨论整理而成；其中具体命令与目录可按你的实际环境调整。