拓冰网站定制 
本文档主题是LLM Wiki——一种由 Andrej Karpathy 提出的、RAG 之外的大模型知识库范式。本目录本身就是一个按该模式生成的最小可用示例知识库见第 3 节。1. LLM Wiki 是什么一句话把 RAG 的查询时临时检索改为写入时编译——让 LLM Agent 像维基百科编辑一样把你的原始资料持续转化为相互链接、可版本化、人可审计的 Markdown 页面。提出者Andrej KarpathyOpenAI 创始成员、前 Tesla AI 总监2026-04-04 以 gist 形式发布。它不是软件而是一份想法文件idea file设计为复制粘贴给你自己的 LLM AgentClaude Code / Codex 等执行核心批评针对 RAGLLM 每次都在从零重新发现知识没有任何积累。问一个需要综合五份文档的问题模型每次都得重新找到并拼装相关片段。NotebookLM、ChatGPT 文件上传和大多数 RAG 系统都是这样两种模式对比RAG解释器模式LLM Wiki编译器模式知识形态向量库里的文档切片相互链接的 Markdown Wiki 页面何时处理知识查询时临时检索写入时由 LLM Agent编译成条目知识积累无每次从零综合有综合结论只算一次之后复用基础设施向量数据库、embedding 管线只需文件系统 Git可解释性难审计人可读、可改、可 diff、可 review优势与代价优势知识有复利效应查询延迟和成本低读几页 Markdown 即可全流程可审计可版本化矛盾被显式暴露天然适合做 Agent 的长期记忆层。代价前期编译很费 token 和时间编译质量依赖底层模型错误会被固化进页面靠 lint 与人工 review 兜底规模上限明显经验值约 100 份来源 / 数百页面。共识两者互补而非替代——中小规模、高价值、需深度消化的知识用 LLM Wiki海量、低价值密度、需全量召回的场景仍用 RAG。实践中常分层混用。注意辨析“LLM Wiki” 还有另一个技术分支以维基百科为语料做 RAG 接地如斯坦福 WikiChat用 Wikipedia 抑制聊天模型幻觉。那边 Wiki 是被检索的语料Karpathy 的 LLM Wiki 是让 LLM主动维护一个 Wiki。方向恰好相反。2. wiki 产物到底有哪些整个方法只有一个核心产物——一个由相互链接的 Markdown 文件组成的 wiki 目录外加两个配套件。三层结构层内容谁维护raw/原始资料论文、文章、图片、数据文件不可变LLM 只读不改事实源人收集wiki/目录LLM 生成并全权维护的所有页面核心产物LLMschema 文件CLAUDE.md/AGENTS.md规定结构约定与工作流人与 LLM 共同演化双方wiki/ 内的页面类型产物说明来源摘要页raw/每份文档对应一页摘要 要点 催生的页面 存疑实体页一个人物 / 产品 / 事物一页概念页一个概念一页对比页通常以对比表格形式存在总览页 综合页overview覆盖面与缺口、synthesis随阅读演化的论点查询回填页好答案回填成新页面形态可为 Markdown、对比表、Marp 幻灯、matplotlib 图、canvasindex.md内容导向总目录每页一行链接 一句话摘要按类别组织每次 ingest 更新查询时先读它log.md时间导向 append-only 日志条目统一前缀## [日期] 操作可选 / 外围产物页面 YAML frontmatter标签、日期、来源数供 Obsidian Dataview 查询、raw/assets/图片附件、git 版本历史、搜索 CLI规模变大后给 Agent 装的检索工具Karpathy 推荐 qmd带 CLI 与 MCP 接口。运作规则Ingest消化来源读全文 → 讨论要点 → 写摘要页 → 更新 index → 更新相关实体/概念页 → 记日志。一份新来源通常牵动 10~15 个已有页面新链接、交叉引用、矛盾标记Query查询见第 4 节Lint定期体检不产生新文件检查页面间矛盾、被新来源取代的过时论断、无入链的孤儿页、被反复提及却没有页面的概念、index 与实际文件一致性3. 本目录一个真实的最小示例本目录以Karpathy 的 gist 本身作为第一份原始资料按上述模式完成了首轮 ingest产物共 11 个文件LLM_WiKi/ ├── AGENTS.md # schema约定 工作流 ├── raw/ │ └── 2026-04-04-karpathy-llm-wiki-gist.md # 原始资料不可变 └── wiki/ # ★ 核心产物 ├── index.md # 总目录 ├── log.md # 时间线日志 ├── overview.md # 全局总览含缺口分析 ├── synthesis.md # 演化中的论点 ├── sources/2026-04-04-karpathy-llm-wiki-gist.md # 来源摘要页 ├── concepts/llm-wiki.md # 概念页 ├── concepts/rag.md # 概念页 ├── entities/karpathy.md # 实体页 └── analyses/rag-vs-llm-wiki.md # 查询回填页对比表示例中值得留意的三个模式精髓每页有 frontmatter 溯源任何事实性内容都标注依据来源concepts/rag.md甚至显式承认当前批评视角只有单一来源——矛盾和不完备是对外可见的而不是藏在向量库的召回失败里synthesis.md 是活的论点明确标注自己只有 1 个来源支撑并预测了什么新证据出现时需要修订回填闭环analyses/rag-vs-llm-wiki.md就是问了个好问题 → 答案沉淀成页面的实例下次再问同样的问题读这一页即可无需重新综合如何继续使用[!NOTE]来源不可变原则raw/属于只读事实层LLM 严禁改写。目前示例中的首份文件为核心要点整理版后续添加新知识时建议直接存放完整的原始文档Markdown、PDF、网页存档等。添加新知识直接往raw/投入新文档提示 Agent 严格按照 [AGENTS.md](file:///j:/Backup/x系统分析员/软件技术/AI/LLM_WiKi/AGENTS.md) 执行ingest流程Agent 将自动完成提炼、全库 10~15 处交叉引用更新、索引刷新与时间线登记。4. 查询工作流检索即推理每次提问的执行流程用户提问 ↓ ① 读 index.md一页看全库有哪些页面、各是讲什么的 ↓ ② LLM 推理要回答这个问题我需要读哪几页 ↓ ③ 打开对应页面 → 顺着页面里的链接再跳到相关页多跳 ↓ ④ 信息不够↺ 回到②/③ 继续钻取可能换个入口比如 grep 搜关键词 ↓ ⑤ 证据够了 → 综合回答引用出处指向具体页面 ↓ ⑥ 答案有沉淀价值→ 回填为新页面analyses/更新 index 和 log五个关键理解点检索这个动作被推理替代了。RAG 是先用向量相似度一次性召回 top-k 切片LLM 被动接收LLM Wiki 里没有检索系统是 LLM 主动决定下一步读什么每读一页都可能修正下一步去哪——读取和推理交替进行而非检索一次、生成一次循环不需要任何框架代码。它天然运行在任何带文件读取工具的 Agent 上Claude Code、Codex、ZCode 等这正是 Karpathy 的文件只是提示词的原因执行机制现成规模扩展与入口多样化不是每次都从 index.md 冷启动。百页规模内单文件index.md是最理想的全局地图与推理入口数百至千页规模可平滑演进为分级索引如按目录细分子 index或直接结合log.md时间线与关键词搜索grep / ripgrep超大规模外挂可接入 Karpathy 推荐的 qmd轻量 CLI 与 MCP 接口先由搜索工具帮 Agent 快速缩小候选页面集再无缝衔接多跳推理与综合。index是指路地图不是唯一的门。循环有自然终止条件。不是读完全库才回答——Agent 判断证据够了就停通常 3~10 次文件读取。一次查询 几轮 LLM 调用 若干文件读取比一次向量检索贵但换来多跳、可溯源的高质量回答第⑥步回填是复利开关。同一问题第二次被问起时Agent 在 index 里直接找到上次的答案页一次读取即结束循环——这正是 Karpathy 批评 RAG每次从零综合的反面一句话总结RAG 是检索喂给模型LLM Wiki 是模型自己去逛图书馆——而图书馆的书目index、书页面和借阅记录log都是 LLM 自己维护的。5. 常见实践问答FAQQ1如果在raw/目录下新增一个文件如何更新wiki/目录更新工作完全交由 LLM Agent 按照 [AGENTS.md](file:///j:/Backup/x系统分析员/软件技术/AI/LLM_WiKi/AGENTS.md) 的“编译器”规范自动化执行分为用户操作与Agent 编译闭环你的操作极简 2 步步骤 ①将原始文档放入raw/目录保持不可变只读步骤 ②给 Agent 发指令“我在raw/放入了xxx请按照 AGENTS.md 执行一次完整的 ingest 流程”。Agent 后台执行的 6 步编译闭环①通读提炼只读解析原始文件全文提取核心论点、事实与新概念②生成来源摘要页在wiki/sources/生成对应摘要页见 Q2③全局网状联动牵动 10~15 处概念/实体页新建未记录的概念/实体或在已有页面追加新论据并更新sources计数显式暴露矛盾若与已有条目观点冲突严禁私自覆写必须插入 [!CONTRADICTION]警告块暴露分歧综合论述与总览同步更新synthesis.md演化中论点与overview.md覆盖度与缺口④刷新总目录在wiki/index.md对应分类下追加新页面及一句话摘要⑤追加审计日志在wiki/log.md尾部追加一条时间线记录Append-only⑥定期体检Lint每隔若干次 ingest可唤起 Agent 进行lint排查孤儿页、未建页的重要概念与矛盾裁决。Q2每增加一个原始文件都会在wiki/sources/下新增一个 Markdown 文件吗是的完全正确两者是严格的 1:1 映射关系raw/里放了多少份原始文档wiki/sources/下就会对应生成多少个结构化 Markdown 摘要页。为什么必须多一层sources/而不是直接读raw/原料与说明书解耦raw/是长篇 PDF、网页存档或杂乱速记直接全量读取极度浪费 token 与时间wiki/sources/则是经过 LLM 结构化提炼后的“溯源身份证”与“使用说明书”。页内标准构成YAML Frontmatter记录创建时间、标签、以及指向raw/文件的相对路径核心论点摘要几百字高度压缩提炼人与 Agent 均可秒级重温下游衍生影响清单清晰列出该来源催生或更新了哪些concepts/和entities/页面存疑与待证伪点记录原文的主观推论或潜在缺陷供后续文献印证。长期复利价值精准溯源Wiki 概念页里的任何结论均可一键回溯至具体的来源页变更审计若某份原始论文后续被撤稿或证伪通过sources/页面的衍生清单即可顺藤摸瓜立刻找出全库受影响的页面实现受控维护。6. 参考资料Karpathy《LLM Wiki》gist 原文2026-04-04 — 一切的原点约 12KB 的想法文件从 RAG 到 LLM Wiki一文看懂大模型知识的演进路线知乎 — 中文世界梳理最完整的一篇LLM WikiAI 知识管理的新范式腾讯云开发者社区检索即推理基于 LLM-Wiki 的自演化智能体原生检索53AI面向个人与小型团队的 LLM 驱动编译型结构化知识库博客园nashsu/llm_wiki — 社区桌面客户端实现qmd — Karpathy 推荐的 wiki 搜索引擎CLI MCPWikiChat: Stopping the Hallucination of LLM Chatbots by Few-Shot Grounding on WikipediaarXiv — 另一分支用 Wikipedia 做语料接地的 RAG LLM Wiki 模式研究
本文档主题是LLM Wiki——一种由 Andrej Karpathy 提出的、RAG 之外的大模型知识库范式。本目录本身就是一个按该模式生成的最小可用示例知识库见第 3 节。1. LLM Wiki 是什么一句话把 RAG 的查询时临时检索改为写入时编译——让 LLM Agent 像维基百科编辑一样把你的原始资料持续转化为相互链接、可版本化、人可审计的 Markdown 页面。提出者Andrej KarpathyOpenAI 创始成员、前 Tesla AI 总监2026-04-04 以 gist 形式发布。它不是软件而是一份想法文件idea file设计为复制粘贴给你自己的 LLM AgentClaude Code / Codex 等执行核心批评针对 RAGLLM 每次都在从零重新发现知识没有任何积累。问一个需要综合五份文档的问题模型每次都得重新找到并拼装相关片段。NotebookLM、ChatGPT 文件上传和大多数 RAG 系统都是这样两种模式对比RAG解释器模式LLM Wiki编译器模式知识形态向量库里的文档切片相互链接的 Markdown Wiki 页面何时处理知识查询时临时检索写入时由 LLM Agent编译成条目知识积累无每次从零综合有综合结论只算一次之后复用基础设施向量数据库、embedding 管线只需文件系统 Git可解释性难审计人可读、可改、可 diff、可 review优势与代价优势知识有复利效应查询延迟和成本低读几页 Markdown 即可全流程可审计可版本化矛盾被显式暴露天然适合做 Agent 的长期记忆层。代价前期编译很费 token 和时间编译质量依赖底层模型错误会被固化进页面靠 lint 与人工 review 兜底规模上限明显经验值约 100 份来源 / 数百页面。共识两者互补而非替代——中小规模、高价值、需深度消化的知识用 LLM Wiki海量、低价值密度、需全量召回的场景仍用 RAG。实践中常分层混用。注意辨析“LLM Wiki” 还有另一个技术分支以维基百科为语料做 RAG 接地如斯坦福 WikiChat用 Wikipedia 抑制聊天模型幻觉。那边 Wiki 是被检索的语料Karpathy 的 LLM Wiki 是让 LLM主动维护一个 Wiki。方向恰好相反。2. wiki 产物到底有哪些整个方法只有一个核心产物——一个由相互链接的 Markdown 文件组成的 wiki 目录外加两个配套件。三层结构层内容谁维护raw/原始资料论文、文章、图片、数据文件不可变LLM 只读不改事实源人收集wiki/目录LLM 生成并全权维护的所有页面核心产物LLMschema 文件CLAUDE.md/AGENTS.md规定结构约定与工作流人与 LLM 共同演化双方wiki/ 内的页面类型产物说明来源摘要页raw/每份文档对应一页摘要 要点 催生的页面 存疑实体页一个人物 / 产品 / 事物一页概念页一个概念一页对比页通常以对比表格形式存在总览页 综合页overview覆盖面与缺口、synthesis随阅读演化的论点查询回填页好答案回填成新页面形态可为 Markdown、对比表、Marp 幻灯、matplotlib 图、canvasindex.md内容导向总目录每页一行链接 一句话摘要按类别组织每次 ingest 更新查询时先读它log.md时间导向 append-only 日志条目统一前缀## [日期] 操作可选 / 外围产物页面 YAML frontmatter标签、日期、来源数供 Obsidian Dataview 查询、raw/assets/图片附件、git 版本历史、搜索 CLI规模变大后给 Agent 装的检索工具Karpathy 推荐 qmd带 CLI 与 MCP 接口。运作规则Ingest消化来源读全文 → 讨论要点 → 写摘要页 → 更新 index → 更新相关实体/概念页 → 记日志。一份新来源通常牵动 10~15 个已有页面新链接、交叉引用、矛盾标记Query查询见第 4 节Lint定期体检不产生新文件检查页面间矛盾、被新来源取代的过时论断、无入链的孤儿页、被反复提及却没有页面的概念、index 与实际文件一致性3. 本目录一个真实的最小示例本目录以Karpathy 的 gist 本身作为第一份原始资料按上述模式完成了首轮 ingest产物共 11 个文件LLM_WiKi/ ├── AGENTS.md # schema约定 工作流 ├── raw/ │ └── 2026-04-04-karpathy-llm-wiki-gist.md # 原始资料不可变 └── wiki/ # ★ 核心产物 ├── index.md # 总目录 ├── log.md # 时间线日志 ├── overview.md # 全局总览含缺口分析 ├── synthesis.md # 演化中的论点 ├── sources/2026-04-04-karpathy-llm-wiki-gist.md # 来源摘要页 ├── concepts/llm-wiki.md # 概念页 ├── concepts/rag.md # 概念页 ├── entities/karpathy.md # 实体页 └── analyses/rag-vs-llm-wiki.md # 查询回填页对比表示例中值得留意的三个模式精髓每页有 frontmatter 溯源任何事实性内容都标注依据来源concepts/rag.md甚至显式承认当前批评视角只有单一来源——矛盾和不完备是对外可见的而不是藏在向量库的召回失败里synthesis.md 是活的论点明确标注自己只有 1 个来源支撑并预测了什么新证据出现时需要修订回填闭环analyses/rag-vs-llm-wiki.md就是问了个好问题 → 答案沉淀成页面的实例下次再问同样的问题读这一页即可无需重新综合如何继续使用[!NOTE]来源不可变原则raw/属于只读事实层LLM 严禁改写。目前示例中的首份文件为核心要点整理版后续添加新知识时建议直接存放完整的原始文档Markdown、PDF、网页存档等。添加新知识直接往raw/投入新文档提示 Agent 严格按照 [AGENTS.md](file:///j:/Backup/x系统分析员/软件技术/AI/LLM_WiKi/AGENTS.md) 执行ingest流程Agent 将自动完成提炼、全库 10~15 处交叉引用更新、索引刷新与时间线登记。4. 查询工作流检索即推理每次提问的执行流程用户提问 ↓ ① 读 index.md一页看全库有哪些页面、各是讲什么的 ↓ ② LLM 推理要回答这个问题我需要读哪几页 ↓ ③ 打开对应页面 → 顺着页面里的链接再跳到相关页多跳 ↓ ④ 信息不够↺ 回到②/③ 继续钻取可能换个入口比如 grep 搜关键词 ↓ ⑤ 证据够了 → 综合回答引用出处指向具体页面 ↓ ⑥ 答案有沉淀价值→ 回填为新页面analyses/更新 index 和 log五个关键理解点检索这个动作被推理替代了。RAG 是先用向量相似度一次性召回 top-k 切片LLM 被动接收LLM Wiki 里没有检索系统是 LLM 主动决定下一步读什么每读一页都可能修正下一步去哪——读取和推理交替进行而非检索一次、生成一次循环不需要任何框架代码。它天然运行在任何带文件读取工具的 Agent 上Claude Code、Codex、ZCode 等这正是 Karpathy 的文件只是提示词的原因执行机制现成规模扩展与入口多样化不是每次都从 index.md 冷启动。百页规模内单文件index.md是最理想的全局地图与推理入口数百至千页规模可平滑演进为分级索引如按目录细分子 index或直接结合log.md时间线与关键词搜索grep / ripgrep超大规模外挂可接入 Karpathy 推荐的 qmd轻量 CLI 与 MCP 接口先由搜索工具帮 Agent 快速缩小候选页面集再无缝衔接多跳推理与综合。index是指路地图不是唯一的门。循环有自然终止条件。不是读完全库才回答——Agent 判断证据够了就停通常 3~10 次文件读取。一次查询 几轮 LLM 调用 若干文件读取比一次向量检索贵但换来多跳、可溯源的高质量回答第⑥步回填是复利开关。同一问题第二次被问起时Agent 在 index 里直接找到上次的答案页一次读取即结束循环——这正是 Karpathy 批评 RAG每次从零综合的反面一句话总结RAG 是检索喂给模型LLM Wiki 是模型自己去逛图书馆——而图书馆的书目index、书页面和借阅记录log都是 LLM 自己维护的。5. 常见实践问答FAQQ1如果在raw/目录下新增一个文件如何更新wiki/目录更新工作完全交由 LLM Agent 按照 [AGENTS.md](file:///j:/Backup/x系统分析员/软件技术/AI/LLM_WiKi/AGENTS.md) 的“编译器”规范自动化执行分为用户操作与Agent 编译闭环你的操作极简 2 步步骤 ①将原始文档放入raw/目录保持不可变只读步骤 ②给 Agent 发指令“我在raw/放入了xxx请按照 AGENTS.md 执行一次完整的 ingest 流程”。Agent 后台执行的 6 步编译闭环①通读提炼只读解析原始文件全文提取核心论点、事实与新概念②生成来源摘要页在wiki/sources/生成对应摘要页见 Q2③全局网状联动牵动 10~15 处概念/实体页新建未记录的概念/实体或在已有页面追加新论据并更新sources计数显式暴露矛盾若与已有条目观点冲突严禁私自覆写必须插入 [!CONTRADICTION]警告块暴露分歧综合论述与总览同步更新synthesis.md演化中论点与overview.md覆盖度与缺口④刷新总目录在wiki/index.md对应分类下追加新页面及一句话摘要⑤追加审计日志在wiki/log.md尾部追加一条时间线记录Append-only⑥定期体检Lint每隔若干次 ingest可唤起 Agent 进行lint排查孤儿页、未建页的重要概念与矛盾裁决。Q2每增加一个原始文件都会在wiki/sources/下新增一个 Markdown 文件吗是的完全正确两者是严格的 1:1 映射关系raw/里放了多少份原始文档wiki/sources/下就会对应生成多少个结构化 Markdown 摘要页。为什么必须多一层sources/而不是直接读raw/原料与说明书解耦raw/是长篇 PDF、网页存档或杂乱速记直接全量读取极度浪费 token 与时间wiki/sources/则是经过 LLM 结构化提炼后的“溯源身份证”与“使用说明书”。页内标准构成YAML Frontmatter记录创建时间、标签、以及指向raw/文件的相对路径核心论点摘要几百字高度压缩提炼人与 Agent 均可秒级重温下游衍生影响清单清晰列出该来源催生或更新了哪些concepts/和entities/页面存疑与待证伪点记录原文的主观推论或潜在缺陷供后续文献印证。长期复利价值精准溯源Wiki 概念页里的任何结论均可一键回溯至具体的来源页变更审计若某份原始论文后续被撤稿或证伪通过sources/页面的衍生清单即可顺藤摸瓜立刻找出全库受影响的页面实现受控维护。6. 参考资料Karpathy《LLM Wiki》gist 原文2026-04-04 — 一切的原点约 12KB 的想法文件从 RAG 到 LLM Wiki一文看懂大模型知识的演进路线知乎 — 中文世界梳理最完整的一篇LLM WikiAI 知识管理的新范式腾讯云开发者社区检索即推理基于 LLM-Wiki 的自演化智能体原生检索53AI面向个人与小型团队的 LLM 驱动编译型结构化知识库博客园nashsu/llm_wiki — 社区桌面客户端实现qmd — Karpathy 推荐的 wiki 搜索引擎CLI MCPWikiChat: Stopping the Hallucination of LLM Chatbots by Few-Shot Grounding on WikipediaarXiv — 另一分支用 Wikipedia 做语料接地的 RAG