Karpathy LLM Wiki评测：告别RAG的知识管理新解法

最近圈子里都在聊 Karpathy 的 LLM Wiki，不过不少人把它和 RAG 搞混了，甚至觉得这只是个“花里胡哨的笔记技巧”。说真的，这么想的话，那可就错过精髓了。

作为 OpenAI 前核心成员、特斯拉 AI 的负责人，Karpathy 搞出来的东西，肯定不是什么“小技巧”，而是一套旨在解决「知识碎片化、重复劳动」的底层工作流。

翻了他原始的 gist，再结合 Obsidian 官方文档、Microsoft GraphRAG 的实现逻辑，以及在圈子里调研各位技术博主和大量实操经验，我们整理出了这份全细节指南。

总体可以做个判断：LLM Wiki 不是 RAG 的替代品，而是一个「知识编译层」。它的核心价值在于，把零散的原始素材，通过 LLM 持续整理成结构化、可复用、可进化的 Wiki，从而解决 RAG 那种“每次查询都要重新合成，有用的结论藏在聊天记录里”的痛点。

一、先搞懂：LLM Wiki 到底是什么？

Karpathy 在 gist 里给的定义很简洁，但也确实比较抽象，我们重新拆解一下：

LLM Wiki 是一套「以 Markdown 为载体、LLM 为维护者、人类为监督者」的知识管理模式。它的核心是“提前编译知识，而非临时检索合成”。简单说，就是让 LLM 帮你把散乱的文档、笔记、PR、会议记录，整理成一本“活的百科全书”——你负责丢素材，LLM 负责整理、更新、链接，而你只需要做最终的审核和使用。

1. 核心三层架构

Karpathy 在 gist 里提到了三层结构，但没具体说清楚每层的规范和实操边界。这边做些补全，照着搭就行：

每层的核心要求如下，否则搭出来的就是个“伪 Wiki”。

（1）Raw Sources 原始素材层：只读不改，保留溯源能力

这层是整个 Wiki 的“数据源”，核心原则就是「原始性、不可修改」。所有素材直接归档，不做任何编辑，目的是为了后续溯源，避免 LLM 总结出错后无法验证。

实操规范（目录结构）：

raw/
├── docs/        # 官方文档、技术手册、论文（PDF/MD格式）
├── prs/         # 代码PR记录、代码评审意见（导出为MD）
├── incidents/   # 故障复盘、问题记录（会议纪要、复盘报告）
├── meetings/    # 会议记录（直接粘贴或导出MD）
├── images/      # 截图、架构图、可视化素材（命名规范：日期_主题.png）
└── others/      # 零散素材（书签导出、笔记碎片、网页剪辑）

关键细节：素材命名必须规范，格式为「日期_主题_来源」，比如 20260405_LLM_Wiki_Karpathy_gist.md，方便 LLM 识别和链接。

（2）Wiki 结构化知识层：LLM 主导，人类审核

这层是核心产出，全部由 LLM 维护，人类只做“审核 + 引导”，不直接编辑（除非紧急修正错误）。本质是「LLM 对原始素材的二次加工」，重点是“结构化、可链接、可更新”。

实操规范（目录结构 + 文件模板）：

wiki/
├── overview.md      # 全局概览：Wiki用途、结构说明、核心链接
├── glossary.md      # 术语表：领域内核心术语、缩写、释义
├── concepts/        # 概念页：核心概念、原理、对比分析（每个概念一个MD）
├── entities/        # 实体页：人物、工具、产品的详细说明（如Obsidian、GraphRAG）
├── incidents/       # 故障知识页：故障原因、解决方案、预防措施
├── decisions/       # 决策记录页：关键决策的背景、依据、结果
└── links.md         # 全局链接索引：所有页面的关联关系

文件模板（强制统一，否则 LLM 会乱写）：

---
title: 【页面主题】
status: draft/ready/review   # 状态标记，方便审核
owners: 【负责人】
source_count: 【引用原始素材数量】
last_reviewed: 【最后审核日期】
sensitivity: internal/public # 敏感级别
---

## 摘要
（1-2句话概括页面核心内容，方便LLM快速识别关联）

## 核心内容
（结构化撰写，用二级/三级标题拆分，避免大段文字）

## 引用来源
（列出所有引用的原始素材路径，格式：../raw/xxx/xxx.md，方便溯源）

## 关联页面
（用Obsidian链接格式 [[页面名称]]，建立页面间关联）

## 待补充/疑问
（LLM标记的不确定点、需要人类补充的内容）

（3）Schema 规则定义层：约束 LLM，避免混乱

这层是“LLM 的操作手册”，核心作用是告诉 LLM「怎么维护 Wiki」，避免 LLM 乱建页面、乱改内容、遗漏引用。很多人搭 LLM Wiki 失败，就是因为少了这层。

核心规则文件（必须放在根目录，命名为 AGENTS.md）：

# LLM Wiki 操作规则（AGENTS）
1. 禁止修改 raw/ 目录下的任何文件，仅可读取；
2. 优先更新现有Wiki页面，禁止随意新建页面（除非没有相关主题）；
3. 所有内容必须引用原始素材，关键结论需标注来源路径，无来源不写入；
4. 不确定的内容，标记为「待补充/疑问」，禁止作为确定结论；
5. 页面关联需合理，禁止强制链接无关页面；
6. 更新Wiki后，必须同步更新 overview.md 和 links.md 的索引；
7. 重要页面（如故障、决策）的修改，需生成diff，等待人类审核后再提交；
8. 禁止删除任何Wiki页面，如需删除，标记为「废弃」，保留历史版本。

补充：可以在根目录新增 lint.md 文件，定义语法检查规则（如标题层级、引用格式），让 LLM 定期自检 Wiki 的规范性。

2. 与 RAG、GraphRAG 的核心区别

很多人把 LLM Wiki 和 RAG 搞混，甚至觉得“有 RAG 就不需要 LLM Wiki”——其实两者是互补关系，不是替代关系。这里用表格对比，一目了然：

二、Karpathy 的实操 workflow

Karpathy 在 gist 里只提了个大概，后续的 X 推文补充了很多细节。我们把他的 workflow 拆成 8 步，每一步都有具体命令和配置，可以直接照搬。

1. 数据摄入：从 Raw 到 Wiki 的转换

这不是简单的“上传素材”，而是让 LLM 对素材进行“加工转换”——这是 LLM Wiki 和普通笔记的核心区别。

实操步骤：

1. 将原始素材（论文、PR、会议记录等）放入 raw/ 对应目录，命名规范遵循「日期_主题_来源」。
2. 编写摄入提示词（放在根目录 prompt/ingest.md），让 LLM 按照规则处理素材：

# 摄入提示词（Ingest Prompt）
请读取 raw/ 目录下的新文档，按照以下规则处理：
1. 优先更新Wiki中已有的相关页面，不新建重复页面；
2. 撰写摘要（不超过7句话），核心内容结构化拆分；
3. 所有关键结论必须标注引用来源（格式：../raw/xxx/xxx.md）；
4. 不确定的内容，标记为「待补充/疑问」，不强行下结论；
5. 更新对应Wiki页面后，同步更新 overview.md 和 links.md 的索引；
6. 不直接修改Wiki页面，生成diff文件（放在 diff/ 目录），等待人类审核。

3. 执行摄入命令（用 Claude Code，Karpathy 首选工具）：

# 安装Claude Code（需Node.js环境，建议版本16以上）
npm install -g @anthropic-ai/claude

# 导航到Wiki根目录
cd ~/llm-wiki

# 执行摄入（指定raw目录和prompt路径）
claude --ingest ./raw --prompt ./prompt/ingest.md --output ./diff

关键细节：diff 文件命名规范「日期_页面名称_diff.md」，方便审核时对比原始内容和修改内容。

2. 前端展示：Obsidian 作为“Wiki IDE”

Karpathy 在 gist 里明确提到用 Obsidian 作为前端，这并非随意选择。Obsidian 的本地 Markdown 存储、双向链接、图谱视图，完美适配 LLM Wiki 的需求。

实操配置（Obsidian 必做设置）：

1. 安装 Obsidian 后，创建 Vault，选择 LLM Wiki 的根目录（~/llm-wiki）。
2. 安装必备插件，很多 Karpathy 本人也大概率在用：
   • Advanced Tables：优化表格编辑。
   • Backlinker：自动生成页面双向链接。
   • Diff Viewer：直接在 Obsidian 中查看 diff 文件。
   • Web Clipper：一键将网页内容剪辑为 Markdown，存入 raw/docs 目录。
3. 开启“图谱视图”，可以直观看到所有 Wiki 页面的关联关系，方便排查链接遗漏。

重点：不要手动编辑 Wiki 页面。Obsidian 只作为“阅读 + 审核”的前端，所有修改都通过 LLM 生成 diff 后，审核通过再应用，避免破坏 LLM 维护逻辑。

3. 问答交互：小体量无需复杂 RAG

Karpathy 在 X 推文中提到，他的研究 Wiki 有 100 篇文章、40 万字。在这个体量下，不需要复杂的 RAG 基础设施——LLM 直接读取 Wiki 文件，就能给出精准答案。

实操命令（Claude Code 直接查询）：

# 导航到Wiki根目录
cd ~/llm-wiki

# 启动Claude Code，直接查询
claude
# 输入查询示例（自然语言即可）
"总结wiki/concepts/llm_wiki.md的核心内容，引用来源"
"查找所有与RAG相关的Wiki页面，并说明它们的关联关系"
"我要写一篇关于LLM Wiki的技术分享，需要用到哪些页面的内容？"

关键细节：查询时，Claude 会自动读取 Wiki 页面和关联的原始素材，给出带来源标注的答案，有效避免 hallucination。

4. 结果回写：让知识持续积累

这是 LLM Wiki 最核心的优势——查询的优质结果，可以回写到 Wiki 中，形成“查询→合成→回写→优化”的闭环，让 Wiki 越用越完善。

实操步骤：

1. 查询得到优质结果后，让 Claude 生成回写提示，指定要更新的 Wiki 页面。
2. Claude 生成 diff 文件，放入 diff/ 目录。
3. 人类审核 diff，确认无误后，执行回写命令。

例如：查询“LLM Wiki 与 RAG 的区别”后，将优质对比内容回写到 wiki/concepts/llm_wiki_vs_rag.md 页面，丰富 Wiki 内容。

5. 质量校验：LLM 自检查，人类做终审

Karpathy 提到，他会用 LLM 对 Wiki 进行“健康检查”，这一步不能少，否则 Wiki 会慢慢变成“错误知识库”。

实操配置：

1. 编写校验提示词（放在 prompt/lint.md）：

# 校验提示词（Lint Prompt）
请对Wiki所有页面进行以下检查：
1. 检查引用来源是否完整，无来源的关键结论是否标记为疑问；
2. 检查页面关联是否合理，无强制链接、无效链接；
3. 检查格式是否符合模板，标题层级、标签是否规范；
4. 检查内容是否存在矛盾，同一概念的释义是否一致；
5. 检查是否有重复页面，或内容过于零散的页面，提出合并建议；
6. 生成校验报告（放在 report/ 目录），标注问题页面和修改建议。

定期执行校验命令（建议每周 1 次）：

# 执行校验
claude --lint ./wiki --prompt ./prompt/lint.md --report ./report

重点：校验报告必须由人类审核，LLM 只提修改建议，不直接修改 Wiki，避免引入新的错误。

6. 工具扩展：从基础到进阶

Karpathy 在推文中提到，随着 Wiki 体量增长，会逐步添加工具。不要一开始就上复杂架构，循序渐进最稳妥：

• 初期（Wiki 目录下 100 个以内 Markdown 页面）：Obsidian + Markdown + Claude Code + Git（版本控制）。
• 中期（100 ~ 500 个页面）：添加 qmd（轻量搜索工具）。
• 后期（500 个以上页面）：添加 GraphRAG（强化关系检索）。

7. 进阶探索：从 Wiki 到模型微调

Karpathy 提到，当 Wiki 体量足够大（比如 1000 个以上 Markdown 页面），可以将 Wiki 内容作为合成数据，用于模型微调。当然，这需要对 Wiki 内容进行人工审核、去重、规范格式，再作为微调数据集，让模型“记住”Wiki 中的知识，减少查询时的读取成本。

实操思路（目前可落地）：

1. 用 Claude Code 提取 Wiki 中的核心内容，生成 JSONL 格式的微调数据集。
2. 使用 Anthropic Claude 3 Fine-tuning API 上传数据集进行微调。

注意：微调成本较高，个人用户可暂时不考虑，团队用户可根据需求尝试。

8. 团队协作：从个人到团队的适配

Karpathy 在推文中说，LLM Wiki 不只是个人工作流，更是一个“潜在的产品机会”——核心是解决团队知识碎片化的问题。

团队版实操配置（基于个人版扩展）：

团队版 LLM Wiki 需在个人版基础上，增加“权限管控、协作流程、多工具集成”三大核心模块。目录结构优化如下：

llm-wiki-team/
├── raw/                     # 原始素材层（团队共享，按部门/项目分类）
│   ├── department/          # 各部门专属素材
│   ├── project/             # 各项目专属素材
│   ├── public/              # 团队公共素材
│   └── sensitive/           # 敏感素材（权限管控）
├── wiki/                    # 结构化知识层（团队共享）
│   ├── overview.md          # 团队Wiki概览
│   ├── glossary.md          # 团队通用术语
│   ├── business/            # 业务模块页面
│   ├── project/             # 项目专属页面
│   ├── department/          # 部门专属页面
│   └── links.md             # 全局链接索引
├── prompt/                  # 团队专属提示词
├── diff/                    # diff文件目录（按部门/项目分类）
├── report/                  # 校验报告目录
├── AGENTS.md                # 团队版操作规则
├── permission.md            # 权限管控说明
└── README.md                # 团队Wiki使用指南

版本控制方面，用 GitHub/GitLab 托管 Wiki 仓库，核心规范：主分支（main）保护，禁止直接推送，仅允许通过 PR 合并 diff 文件。

三、不同人群的落地案例

LLM Wiki 不是只有开发者能用，设计师、产品经理、普通人都能搭。这里整理了 3 个最常见的案例，每个都有完整的目录结构和实操要点。

案例 1：开发者 - legacy 项目入职 Wiki

很多 legacy 项目的知识，都藏在 PR、故障复盘、老员工的脑子里，新人入职要花几周才能上手。用 LLM Wiki 就能解决。

核心要点：重点整理「故障复盘」和「决策记录」，新人遇到问题时，直接查询 Wiki 就能找到解决方案，不用反复问老员工。

案例 2：设计师 - 品牌/UX 研究 Wiki

设计师的灵感、参考素材，通常散在 Figma、浏览器书签、截图文件夹里，时间久了就忘了“为什么保存”。LLM Wiki 能帮你保留灵感和背后的思考。

核心要点：让 LLM 提取每张截图、每篇参考的「设计亮点」和「适用场景」，避免灵感变成“无意义的图片堆”。

案例 3：普通人 - 个人学习 Wiki

不管是学编程、学理财，还是学历史，零散的笔记、教程、书籍摘要，时间久了就会遗忘。LLM Wiki 能帮你构建系统化的知识体系。

核心要点：每天花 10 分钟，将当天的学习素材放入 raw 目录，让 LLM 整理成 Wiki 页面，长期坚持，就能形成自己的知识体系。

四、避坑指南

搭 LLM Wiki 的过程中，有几个坑比较常见，值得提前了解：

1. 让 LLM 自由发挥，不设 Schema 规则
后果是 LLM 乱建页面、内容格式混乱、引用缺失，Wiki 越搭越乱。解决方案是必须先写好 AGENTS.md 和文件模板，让 LLM 严格按照规则操作。

2. 手动编辑 Wiki 页面，破坏 LLM 维护逻辑
后果是 LLM 无法识别手动修改的内容，后续更新会覆盖手动修改，导致内容丢失。解决方案是所有修改都通过“LLM 生成 diff → 人工审核 → 回写”的流程，禁止手动编辑。

3. 忽视原始素材的溯源，导致 LLM hallucination
后果是 LLM 总结的内容没有来源，无法验证真实性。解决方案是强制要求 LLM 标注所有关键结论的来源，raw 目录保持只读。

4. 一开始就上复杂架构（GraphRAG、向量索引）
后果是运维成本高，学习曲线陡，反而影响使用积极性。解决方案是循序渐进，从 Obsidian + Claude Code 开始。

5. 不做定期校验，错误内容固化
后果是 LLM 的小错误会慢慢积累，最后 Wiki 失去参考价值。解决方案是定期执行一次 LLM 校验，人工审核校验报告。

五、工具选型汇总

下表整理了所有用到的工具，包括替代方案，按需选择：

六、总结：LLM Wiki 的核心价值

很多人看完 Karpathy 的 gist，觉得 LLM Wiki 只是“高级笔记”——其实不然，它的核心价值是「让知识从“零散碎片”变成“可进化、可复用的资产”」。

对个人而言，它是你的“第二大脑”，帮你记住所有学到的知识；对团队而言，它是“团队知识库”，帮你沉淀隐性知识，减少重复劳动。

当然，LLM Wiki 不是“一劳永逸”的，它需要你持续投入时间，上传素材、审核 diff、优化规则。但只要坚持下来，你会发现，它能帮你节省大量的时间和精力。

现在，打开你的终端，按照上面的步骤，搭一个属于自己的 LLM Wiki 吧——这可能是你 2026 年最有价值的技术投资之一。

附录：参考资料

1. Andrej Karpathy, LLM Wiki gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
2. Obsidian 官方文档: https://help.obsidian.md/
3. Microsoft GraphRAG 官方文档: https://learn.microsoft.com/en-us/graph/rag/overview
4. qmd GitHub README: https://github.com/qmd-dev/qmd
5. OWASP LLM Prompt Injection 安全指南: https://owasp.org/www-project-top-ten-for-large-language-model-applications/

来源：互联网