如果只先记住一个结论，那么可以记这句：

LLM wiki 不是“让 AI 帮你整理笔记”，而是把项目知识从原始资料提升为 Agent 可消费、可引用、可演化的知识中间层。

这个判断的关键在于，问题并不只是“资料有没有被存下来”，而是“资料是否已经被整理成 Agent 可以稳定工作的形状”。在这件事上，RAG 和 LLM wiki 处理的根本不是同一层问题。Andrej Karpathy 提出的 llm-wiki.md 范式 给出的也不是一个笔记软件教程，而是一种把知识从原始材料编译成可维护工作上下文的思路。

本文想讨论的是三个问题：

  • LLM wiki 到底是什么
  • 它和 RAG 的边界到底在哪里
  • 如果要把它落到工程实践里，最小实现应该长什么样

1. Agent 真正缺的不是“更多文档”，而是知识编译层#

很多仓库并不缺文档。

README、ADR、issue、PR、聊天记录、代码注释、发布记录，甚至临时会议纪要，往往已经足够多。问题在于，这些材料大多是围绕“人怎么理解系统”自然长出来的，而不是围绕“Agent 应该如何进入系统、命名概念、定位事实、拼装上下文”组织出来的。

这会带来几个很典型的摩擦：

  • 资料很多，但没有稳定入口
  • 术语存在，但定义分散甚至漂移
  • 同一个问题需要每次重新检索和重新拼接上下文
  • 原始资料适合追溯事实，不适合直接充当工作层

所以 LLM wiki 试图解决的，不是“把一堆东西再存一遍”，而是另一件更具体的事：

它的价值不在存储，而在预编译；不在收集，而在把知识变成可持续复用的中间表示。

Karpathy 在原始 gist 里把这件事描述得很清楚：系统并不直接依赖原始材料回答问题，而是先把原始材料经过整理，沉淀成持续更新的 wiki 层，并由 schema 约束其结构与工作流，再把它作为后续查询和工作的主上下文层。来源

2. 与 RAG 的绝对区分：一个是运行时召回，一个是离线知识编译#

很多讨论会把 LLM wiki 和 RAG 混在一起，但这两者并不是同义替换。

RAG 的经典定义来自 Lewis 等人的论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：模型在生成前，先从外部知识源检索相关内容，再把检索结果并入生成过程。论文链接

RAG 的重点天然落在运行时：

  • 找不找得到
  • 召回的片段准不准
  • 噪音高不高
  • 排序和相关性好不好

而 LLM wiki 的关注点并不在“这一问检索到什么”，而在“平时有没有把知识整理成一个稳定的工作骨架”。

这里可以直接用一张表来区分说明：

维度RAGLLM wiki
主要工作阶段运行时离线持续维护
核心目标找回相关片段组织成稳定知识骨架
输入形态原始文档切片经整理后的主题页、术语页、决策页
主要优化对象召回率、相关性可导航性、可引用性、一致性
失败模式没召回 / 召回噪音结构陈旧 / 术语漂移 / 入口失效
更像什么检索系统知识编译系统

一句话说，RAG 更像是在 query time 做“找”，而 LLM wiki 更像是在 authoring time 做“整理”和“压缩”。

Karpathy 在 gist 里讲得很直接：不要只在 query time 从 raw documents 里临时捞片段，而是让 LLM 持续维护一个位于你和原始资料之间的 persistent wiki。这个动作本质上就是先把知识整理成稳定结构，再用这层结构服务后续工作，而不是每次都直接在原始材料里临时搜索。来源

这也是为什么更适合把 LLM wiki 理解成知识层的 build step，而不是检索层的补丁。

3. 关键不在载体，而在知识形状#

LLM wiki 很容易被误解成“用 Obsidian 记笔记”“用 Notion 建文档”“用 Hugo 发布知识库”。这些都可以是载体，但都不是重点。

哪怕都是 Markdown 文件，面向博客的写法和面向 Agent 的写法也完全不同。

普通文档更关心的是：

  • 人类读起来顺不顺
  • 章节结构清不清楚
  • 能不能从头到尾顺着看

而 LLM wiki 还必须满足额外约束：

  • 页面能不能被独立引用
  • 概念有没有稳定命名
  • 页面之间有没有显式关系
  • 知识能不能被逐步重写，而不是只追加

Obsidian 官方文档一直强调链接、反向链接、图谱和知识库组织能力，例如 internal links、backlinks、graph view 这些能力，本质上都是在增强“知识节点之间的关系可见性”。官方帮助文档 这和 LLM wiki 的思路是相通的，但 LLM wiki 还会再向前一步：它不只要求可读，还要求这些页面天然适合被模型抽取、拼接、引用和重写。

所以问题不在“你是不是用了 wiki 工具”，而在“你的页面是不是构成了稳定知识节点”。

4. 一个工程可用的 LLM wiki，最小结构其实只有三层#

如果严格按照 Karpathy 的原始范式来看，最小结构应该收缩成三层，而不是先发明一套很重的目录体系。

最小结构就是：

raw/
schema
wiki/

这里三层各自的职责非常明确：

  • raw/：原始资料层，放文章、论文、图片、数据文件等。它是事实来源层，默认不可变，LLM 只读不改。
  • schema：规则层，通常就是 AGENTS.md、CLAUDE.md 这类文件。它负责告诉 LLM 这套 wiki 怎么组织、有哪些命名约定、如何 ingest、如何 query、如何 lint。
  • wiki/：知识层，由 LLM 生成和维护的 markdown 页面集合。摘要页、实体页、概念页、比较页、总览页、综合分析页都在这里。

这是原始 gist 里最重要的架构判断之一：原始资料、知识页、维护规则，必须分层。来源

继续往下拆，这三层里真正决定上限的，往往反而不是 wiki/，而是 raw/ 和 schema。

对 raw/，重点应该放在数据清洗和人工审核上。无论是自己总结的随记、技术文档、学习笔记、心得，还是外部文章、PDF、Word、Markdown、截图、数据表，只要准备进入这套系统，都更适合先被视为原始知识材料，而不是直接可用知识。这里最怕的是脏数据、重复信息、低质量摘录、未经确认的引用、格式噪音和上下文残缺。因为 raw/ 作为最底层，决定了后面所有 synthesis 的上界；如果地基层就松，后面的 wiki 写得再漂亮，也只是把偏差结构化。

所以，raw/ 这一层不是“收集得越多越好”，而是“清洗得越干净越好”。进入 raw/ 的材料，应该尽量经过明确整理和人工审核，至少保证来源可追溯、内容可读、格式可处理、重复可识别、噪音可控。

而 schema 的重要性，很多时候甚至会被低估。schema 不只是一个说明 LLM 怎么写 wiki 的配置文件，它本质上是在约束 LLM 的边界，控制每一轮循环的误差，规定它如何 ingest、如何建立 cross-references、如何回写、如何做 lint、如何处理冲突、何时该保守、何时可以改写。它真正解决的问题不是“格式统一”，而是“这套系统如何在多轮迭代中维持 cross-reference quality 和整体 consistency”。

再说得具体一点，schema 要回答的其实是这些问题：

  • 每一轮 ingest 的标准动作是什么
  • 更新一个 source 时允许触碰哪些页面
  • 新信息和旧结论冲突时应该如何处理
  • query 产出的分析什么时候允许回写进 wiki
  • 哪些页面必须保守，哪些页面可以积极重构
  • lint 应该检查哪些一致性问题

如果这些规则不清楚，LLM 每一轮虽然都在“工作”，但系统的熵其实是在增加的。旧结论和新增信息之间的冲突、命名漂移、cross-references 退化、页间不一致，都会慢慢侵蚀整个 wiki 的可信度。可以把 schema 理解成一套控制循环误差和管理新增熵的机制，它的目标不是让 LLM 更自由，而是让它更稳定。

在这三层之下，index.md 和 log.md 是两个非常关键的特殊文件：

  • index.md 是内容导向的目录，帮助 LLM 和人快速找到相关页面
  • log.md 是时间导向的追加日志，记录 ingest、query、lint 等动作

再往下扩展成 entities/、concepts/、systems/ 之类的目录，当然可以做，但那已经是某个具体领域的实例化，不是这个范式本身的最小要求。

所以如果只讲核心，可以把它概括成一句话：

LLM wiki 的最小骨架不是一堆分类目录，而是 raw、schema、wiki 三层分离。

5. 页面不是“文档”，而是知识节点#

这是 LLM wiki 和普通知识库教程最不一样的地方。

在普通文档系统里，一页文章写得顺、写得全，通常就已经够用了。但在 LLM wiki 里，一页首先是一个可以被引用、组合和追踪的知识节点，而且这页默认是由 LLM 持续维护的，不是主要靠人手工慢慢改出来的。

落到写法上，页面最好尽量满足这些原则：

  • 一页只承载一个稳定主题
  • 页面标题必须是可复用的引用名
  • 先写定义、边界、关系，再写叙述性背景
  • 显式写出相关页、前置概念、依赖系统和常见误解
  • 让页面可以被独立抽出，而不是必须通读整篇才能理解

差页面和好页面的区别通常很直接。

差页面往往是：

  • 流水账
  • 混合多个主题
  • 没有链接
  • 没有边界
  • 读完之后仍然不知道它在知识图里属于哪里

好页面通常具备这些特征：

  • 主题单一
  • 命名稳定
  • 关系显式
  • 可以被独立引用
  • 被抽取进上下文后仍然保留语义完整性

这也是为什么 LLM wiki 里的页面更像“可组合单元”，而不是“仅供线性阅读的章节”。至于 wiki 本身为什么应该是 persistent、compounding、interlinked artifact，Karpathy 在原始 gist 里已经讲得很完整，这里不再重复扩写，重点只放在这套结构真正落地时，哪些地方最容易失真。

6. Agent 工作流闭环：Ingest、Query、Lint、Rewrite#

如果只把 LLM wiki 当成一个静态文件夹，它很快就会失效。真正有用的是把它变成一条持续运行的知识维护流水线。

一个比较自然的最小闭环是四步：

6.1 Ingest#

从 raw/ 提取事实，更新 wiki 页面，而不是把原始资料直接塞进上下文。

这一步做的不是复制粘贴，而是：

  • 抽概念
  • 归术语
  • 拆主题
  • 建链接
  • 标记来源

按照 gist 的描述，一个 source 进来之后，LLM 不只是写一页摘要，还可能同时更新 index.md、相关实体页、概念页，以及 log.md。也就是说，ingest 不是“收录一份文件”，而是“把新知识并入现有 wiki”。来源

6.2 Query#

后续回答、分析、规划，优先基于 wiki 层展开；原始资料只作为追溯证据层。

这样做的好处是，上下文不再是一次次临时拼装的碎片，而是来自同一套稳定骨架。并且 gist 里另一个很重要的点是，好的 query 结果不该只留在聊天记录里，它本身也可以回写成新的 wiki 页面，让分析结果继续沉淀。来源

6.3 Lint#

定期检查结构健康度，例如：

  • 断链
  • 重复页
  • 命名冲突
  • 过时页
  • 空入口
  • 孤儿页
  • 已经被新来源推翻但没更新的旧结论
  • 被频繁提到但还没有单独页面的重要概念

Karpathy 在 gist 里专门把 lint 作为一个动作提出，这一点非常关键，因为知识系统和代码系统一样，也会腐化。来源

6.4 Rewrite#

随着任务推进，持续重写结构，让 wiki 跟着系统演化，而不是无限追加新页面。

真正的维护不是“越写越多”，而是“该折叠的折叠，该合并的合并，该改名的改名”。

所以这套东西的关键判断应该是：

LLM wiki 不是静态知识库，而是一条持续运行的知识维护流水线。

而这条流水线能不能长期稳定运转，最终看的还是两件事：raw/ 有没有把好底层质量关，schema 有没有把好多轮循环的一致性关。

7. 为什么这套东西在今天才真正可行#

如果把时间拉长一点看，LLM wiki 并不是完全凭空冒出来的新想法。

Vannevar Bush 在 1945 年的文章 As We May Think 里提出过著名的 memex 概念，强调通过关联路径组织个人知识，而不是只靠线性归档。原文链接

这个方向并不新，真正长期卡住的，是维护成本。

过去的问题不是没人想到链接化知识系统，而是：

  • 资料整理太费人
  • 命名统一太费人
  • 跨页归并太费人
  • 持续重写太费人

而 LLM 真正改变的一点，不只是“能生成文字”，而是它显著压低了这些知识维护动作的边际成本：摘要、归并、重写、抽术语、补链接、生成索引页、维护跨页一致性，这些以前昂贵的操作，现在终于可以低成本持续执行。

所以 LLM wiki 不是旧 wiki 的换皮，而是旧知识系统在新维护成本条件下的再成立。Karpathy 的 gist 之所以让人眼前一亮，也正是因为它把这件事从模糊愿景落到了可执行结构上。来源

8. 失败模式与反模式：它什么时候会退化成垃圾层#

任何知识系统只要开始维护，就会面临腐化问题。LLM wiki 也不例外。

最常见的失败模式大概有这几类：

8.1 不区分 raw 和 wiki#

如果什么都往 wiki/ 里塞，而不是先把原始资料留在 raw/、把整理后的知识放进 wiki/，信息密度很快就会失控，后面所有页面都会变成冗长噪音。

8.2 没有术语页#

同一个概念今天叫 workflow state，明天叫 task context，后天又叫 execution memory，Agent 没法稳定对齐，知识骨架会从内部崩掉。

8.3 当前任务态和长期知识混写#

任务临时结论、调试痕迹、一次性 workaround，如果直接写进稳定概念页，后面会持续污染判断。

8.4 页面之间没有显式关系#

只有孤立页面，没有 related pages、前置概念、依赖系统，这样的知识库看起来很多，实际仍然不可导航。

8.5 只增不改#

知识库一旦只追加、不折叠、不重写，就会像没有重构的代码一样越来越不可用。

8.6 把 schema 当装饰，把 wiki 当真理源#

如果 schema 没有持续演化，LLM 很快就会退化成一个泛化聊天机器人，而不是一个有纪律的 wiki maintainer。更具体地说，一旦没有人去约束每轮循环的动作、更新范围、冲突处理和链接策略，系统表面上看起来还在增长，实际上 cross-reference quality、inbound links 和跨页 consistency 已经在悄悄下降。反过来，如果把 wiki 当成最终事实本身，也会出问题。代码、测试、运行行为、生产数据，依旧是更高优先级的事实源。

也就是说，LLM wiki 最危险的状态不是“没有写”，而是“写得很多，但结构已经失真”。

9. 适用场景：它是给长期系统准备的#

LLM wiki 并不是任何项目都值得上。

它更适合这些场景：

  • 长期维护代码库
  • 多模块系统
  • 研究型或架构型项目
  • 高频使用 Agent 参与设计、编码、调试、审查的工作流

它不太适合这些场景：

  • 一次性脚本
  • 临时 demo
  • 变化太快且没有沉淀意愿的项目
  • 对上下文一致性没有要求的低复杂度工作

简单说，如果系统还没有复杂到需要知识骨架，那么引入 LLM wiki 只会制造额外维护成本。

工程基础设施从来都不是越多越好，而是只在复杂度真正出现时再引入。

10. 把它理解成知识层的 build step#

如果要给全文做一个最短总结，可以把 LLM wiki 理解成知识层的 build step。

它不是文档层的附件，也不是一个“更会记笔记”的工具，而是一层位于原始资料和运行时检索之间的知识编译层：

  • 原始资料是真实来源
  • schema 是维护规则
  • RAG 是运行时检索机制
  • LLM wiki 是两者之间的知识编译层

真正有区分度的地方，从来不是“也有知识库”，而是是否把知识组织成了 Agent 可以稳定工作的形状。

当 Agent 开始参与真实工程工作流时，知识库就不再只是备忘录，而会逐渐演化成上下文基础设施。

参考资料#