夜雨聆风十几年来，云笔记用过有道云 -> 印象笔记 -> 语雀，这些笔记各有千秋都很好，但是在 AI 时代，笔记不仅仅只给自己看，还要给 AI 读，让 AI 基于自己记录的信息来辅助思考、决策和创作。于是前段时间，我把笔记软件改为了 Obsidian，方式上参考 LLM Wiki 形式。
背景是这样的：
2026 年 4 月，AI 领域最知名的研究者之一 Andrej Karpathy（OpenAI 联合创始人、特斯拉 AI 总监）在 GitHub 上发了一个 Gist，短短几天超过 5000 Stars+。
他提出了一个叫做 LLM Wiki 的概念——它不是什么新工具、新产品，其实就是一种用 AI 构建个人知识库的新的工作方式。
这种工作方式解决以下问题：
好知识读了之后留不住，留住了之后找不到，找到了之后用不起来
读了一篇好文章，觉得很有收获，收藏了然后就再也没打开过
用 ChatGPT 上传了一堆文档，每次问问题都要重新找半天
上次 AI 给出的那个绝妙回答，这次完全不记得了
如果你也有这样的经历，LLM-WIKI这套方案值得尝试。
我把这份原文完整读了三遍，做了深度解读，结合自己用 Claude Code 实际操作的经验，整理成了这篇教程。
如果你是研究者、深度阅读爱好者、开发者，或者任何需要长期积累知识的人，这篇文章值得认真读完。
COMPLETE BEGINNER'S GUIDE · 完全新手指南
LLM-Wiki
完全新手指南 + 深度解读
用 AI 构建你的个人知识库 — Andrej Karpathy 方法论
含原文逐段解读 · 本质分析 · 社区评论精选
原作者 Andrej Karpathy | 发布时间 2026 年 4 月 4 日 | GitHub Stars 5,000+ | 适合人群 零基础新手 |
gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
目录
01什么是 LLM Wiki？ 核心概念与背景，原文导读 02核心原理：知识的累积 与传统 RAG 的根本差异 03原文逐段精读与解读 Karpathy 每段话背后的深意 04三层架构详解 Raw Sources · Wiki · Schema 05三种核心操作 导入 · 查询 · 维护 06索引与日志管理 index.md 与 log.md 的设计哲学 07可选 CLI 工具 qmd 搜索引擎与效率增强 | 08实用技巧与工具推荐 Obsidian · Marp · Dataview · Git 09本质分析：为什么这个方法有效 人机分工的哲学 · Memex 历史渊源 10社区反应与批评性解读 5000+ Stars 背后的真实讨论 11适用场景与边界 何时用 · 何时不用 12快速上手实战指南 从零搭建你的第一个 LLM Wiki |
CH 01
什么是 LLM Wiki？
LLM Wiki 是 AI 领域知名研究者 Andrej Karpathy 于 2026 年 4 月提出的个人知识库构建模式。用一句话概括：让 AI 大模型替你写和维护一个持续增长的结构化知识百科，而非每次从头检索原始文档。
这份原始文档发布于 GitHub Gist，截至 2026 年 5 月已获得 5000+ Stars 和 5000+ Forks，引发了全球开发者、研究者、知识工作者的广泛关注与二次创作。
Karpathy 其人
Andrej Karpathy 是斯坦福大学 CS 博士，曾任 OpenAI 研究科学家，后加入特斯拉担任 AI 总监，是 AI 领域最有影响力的技术布道者之一。他的 YouTube 频道「Neural Networks: Zero to Hero」被数百万开发者奉为入门圣经。这份 LLM Wiki 文档，是他在 AI 工具使用上真实个人工作流的分享。
为什么值得关注？
•不是工具，是模式：LLM Wiki 不是一个软件，而是一套可以用任何 LLM Agent 实现的工作模式
•解决真实痛点：知识库难以维护是每个知识工作者的共同困境，这个方案找到了核心突破口
•极低门槛：不需要会编程，只需要 Obsidian + 任何支持文件操作的 LLM Agent 即可开始
•启发了生态：一周内 GitHub 上涌现出 Kompl、SwarmVault、ΩmegaWiki 等十余个衍生项目
CH 02
核心原理：知识的累积
理解 LLM Wiki 的关键，在于理解它与传统 RAG 的根本差异：一个是每次重新发现知识，一个是持续编译和积累知识。这个区别，改变了 AI 辅助知识管理的整个逻辑。
传统 RAG 的本质缺陷
RAG（检索增强生成）是目前主流的 AI 文档问答方案，ChatGPT 文件上传、NotebookLM 都属于这类。其工作流程是：
1.分块（Chunking）：将文档切成若干小段落
2.向量化（Embedding）：将每段落转为数字向量存入数据库
3.检索（Retrieval）：用户提问时，找出最相关的几段
4.生成（Generation）：AI 根据检索结果即时回答，对话结束即消失
⚠ RAG 的根本问题 每次问答都是「从零开始」。无论你问过多少次，AI 都要重新寻找和拼凑答案。知识没有积累，没有沉淀，没有学习。这一次的优质回答，下次问类似问题时完全不会被记住。 |
LLM Wiki 的核心机制：预编译知识
LLM Wiki 的思路是：不在查询时才去理解原始文档，而是在导入时就让 AI 将知识「编译」成结构化的 Wiki 页面，永久保存，持续更新。
这就像软件编译的逻辑：源代码（原始文档）→ 编译（AI 整理）→ 可执行程序（Wiki）。每次运行（查询）都直接用编译好的结果，不用每次重新编译。
对比维度 | 传统 RAG | LLM Wiki |
知识处理时机 | 查询时即时处理 | 导入时预先编译 |
知识积累效果 | ❌ 无积累，每次重来 | ✅ 持续累积，越用越深 |
跨文档综合 | 弱，临时拼凑 | 强，已预建关联网络 |
矛盾处理 | ❌ 基本忽略 | ✅ 主动标注冲突 |
维护成本随规模 | 指数级增长 | 接近线性，LLM 负担 |
适合场景 | 大规模文档库检索 | 精心策划的深度研究 |
CH 03
原文逐段精读与解读
Karpathy 的原文极其简洁，但每段话背后都有深刻含义。本章对原文的关键段落进行逐段解读，帮助你真正理解他在说什么、为什么这样说。
原文段落一：定义核心差异
📜 Karpathy 原文 Most people's experience with LLMs and documents looks like RAG... This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. |
解读：他在批判什么？
Karpathy 没有说 RAG 是错的，他说的是「没有积累（no accumulation）」。这才是核心批判。RAG 对于「检索」是有效的，但它无法做到「学习」。每次对话，AI 对你的文档库的理解归零。这在短期项目里无所谓，但在长期研究中，这意味着你每次都在浪费 AI 的潜力。
原文段落二：Wiki 是「持续增长的复合制品」
📜 Karpathy 原文 The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add. |
解读：「compounding artifact」是关键词
「Compounding」（复利）是这里最重要的词。就像巴菲特谈复利投资，知识也存在复利效应。每新增一篇资料，不仅增加了一个新页面，还丰富了 10-15 个已有页面的内容，并建立了新的交叉引用。知识不是线性增长，而是指数级深化。
原文段落三：人机分工的精准定义
📜 Karpathy 原文 You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You're in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work. |
解读：「grunt work」是人类知识管理的真正痛点
「Grunt work」是「枯燥苦力活」的意思。Karpathy 精准指出了人类维护知识库失败的真正原因：不是没有能力，是没有意愿长期做枯燥的维护工作。更新交叉引用、保持摘要一致、标注矛盾——这些工作机械重复，人类坚持不了，但 LLM 永远不会厌倦。
原文段落四：工作场景描述
📜 Karpathy 原文 In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase. |
解读：IDE/程序员/代码库的比喻意义深远
这个比喻非常精准。对一个程序员来说：你（PM/产品经理）提需求，LLM（程序员）写代码，Wiki（代码库）是产出物。你负责方向和判断，AI 负责执行。这是软件工程协作模式在知识管理领域的完美迁移。
原文段落五：Schema 是核心配置文件
📜 Karpathy 原文 The schema... is the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain. |
解读：Schema 决定 LLM 是「工匠」还是「闲聊者」
没有 Schema，LLM 是万能聊天机器人，每次对话风格不一。有了 Schema，LLM 成为遵守纪律的 Wiki 维护者，知道该建什么文件、该怎么命名、该更新哪些页面。「co-evolve」这个词也值得注意——Schema 不是一次性配置，而是你和 AI 在实践中共同演进的「工作协议」。
CH 04
三层架构详解
LLM Wiki 由三个职责清晰的层次构成。理解每层的边界和规则，是正确使用这套系统的基础。
第三层 | 📋 Schema（规范文件） | CLAUDE.md / AGENTS.md — 定义 Wiki 的结构规范、操作流程、工作协议 |
第二层 | 📖 Wiki（知识库） | LLM 生成的 Markdown 文件目录：摘要页 · 实体页 · 概念页 · 综合页 · 索引 · 日志 |
第一层 | 📁 Raw Sources（原始素材） | 你精选的原始文档：文章 · 论文 · 图片 · 数据文件 — 只读，是唯一真相来源 |
第一层：Raw Sources — 原始素材（只读）
这是你精心策划的原始内容集合，是整个知识库的「源代码」。文章、学术论文、图片、数据文件都可以放入这里。
📌 最重要的规则：原始素材永远只读 LLM 只能读取，绝不能修改原始素材。这是整个系统的信任基础。一旦原始素材被 AI 改写，你就失去了知识的权威来源，无法追溯任何信息的原始出处。 |
my-wiki/
├── raw/← 原始素材（只读，唯一真相来源）
│├── articles/← 文章、网页剪藏
│├── papers/← 学术论文
│└── assets/← 图片等资源
├── wiki/← LLM 维护的知识库（见第二层）
└── CLAUDE.md← Schema（见第三层）
第二层：Wiki — 知识库（LLM 专属写入区）
Wiki 是整个系统的核心产物。规则同样清晰：你只读不写，LLM 只写不停。这个角色分工确保了 Wiki 的一致性——所有内容都由同一套 Schema 约束的 LLM 生成，风格统一，格式规范。
Wiki 中通常包含以下几类页面：
•摘要页（Source Pages）：每篇原始素材对应一个摘要，提取关键信息和核心观点
•实体页（Entity Pages）：关于某个人、机构、产品的汇总页面，聚合所有来源中的信息
•概念页（Concept Pages）：解释某个专业概念，汇聚相关资料，标注不同来源的异同
•综合页（Synthesis Pages）：跨资料的主题分析，AI 主动推断的结论和观点
•索引页（index.md）：所有页面的目录，LLM 查询前的导航地图
•日志页（log.md）：操作历史记录，只追加不修改的时间线档案
第三层：Schema — 工作协议（最被低估的层）
Schema 是一个配置文档，对 Claude Code 命名为 CLAUDE.md，对 OpenAI Codex 命名为 AGENTS.md。它的作用是将 LLM 从「万能聊天机器人」改造为「有纪律的 Wiki 维护者」。
一个完整的 Schema 应该告诉 LLM：目录结构是什么、各类页面的格式规范是什么、导入新资料时的完整流程、查询时的检索策略、维护时的健康检查标准。
# Wiki Schema (CLAUDE.md 示例)
## 目录结构
- raw/：原始素材，只读，任何情况下不能修改
- wiki/：LLM 维护的知识库
-index.md：全局目录，每次导入后更新
-log.md：操作日志，只追加
-sources/：原始素材摘要页
-entities/：实体页（人物、机构、产品）
-concepts/：概念页（技术术语、方法论）
## 摘要页格式
# [资料标题]
来源：[文件路径]日期：[导入日期]
## 核心观点（3-5 条）
## 关键数据
## 相关页面（内部链接）
## 导入新资料的完整流程
1. 阅读原始素材，理解核心内容
2. 与用户讨论关键收获和重点
3. 在 wiki/sources/ 写摘要页
4. 更新相关实体页和概念页
5. 更新 wiki/index.md
6. 在 wiki/log.md 追加记录
CH 05
三种核心操作
LLM Wiki 的日常工作围绕三个操作展开：导入（Ingest）、查询（Query）、维护（Lint）。掌握这三种操作，就掌握了这套系统的日常使用节奏。
操作一：导入（Ingest）
📥 触发时机 每当你找到一篇想纳入知识库的文章、论文或资料，执行导入操作。Karpathy 建议一次导入一篇，保持参与感。 |
典型的导入流程：
5.将新资料放入 raw/ 目录，告诉 LLM 处理它
6.LLM 阅读资料，主动与你讨论关键收获（这步很重要，不要跳过）
7.LLM 在 wiki/sources/ 写摘要页
8.LLM 更新相关实体页和概念页（可能涉及 10-15 个页面）
9.LLM 更新 index.md，在 log.md 追加记录
💡 新手建议 不要批量导入大量素材。一次一篇，读完 AI 生成的摘要，确认方向正确再继续。你对导入过程的参与度，直接决定了 Wiki 的质量。AI 是执行者，你是方向的把控者。 |
操作二：查询（Query）
查询是向已建立的 Wiki 提问，获取综合性回答。LLM 的查询流程：
1.先读 index.md，定位相关页面
2.深入阅读相关页面，跨页面综合分析
3.生成带有 Wiki 内部引用的回答
💡 查询的复利效应 好的回答本身就是有价值的知识——可以将其存回 Wiki 作为新的综合页！一次精彩的比较分析、一个重要发现，都不应该消失在聊天记录里。每一次探索，都是对知识库的一次丰富。 |
查询的输出形式可以多种多样：Markdown 分析页、比较表格、Marp 幻灯片、Matplotlib 数据图表，取决于你的需求。
操作三：维护（Lint）
随着 Wiki 增长，定期进行健康检查是必要的。LLM 在维护时检查：
•矛盾检测：找出不同页面之间的冲突观点，标注待核实项
•过时内容：标注已被新资料推翻的旧结论
•孤儿页面：找出没有被任何页面链接的孤立页面
•缺失页面：识别被多次提及但还没有专属页面的概念
•断裂链接：修复指向不存在页面的内部链接
•知识空缺：发现可以通过网络搜索来填补的数据缺口，建议新的研究方向
CH 06
索引与日志管理
随着 Wiki 规模扩大，两个特殊文件变得至关重要：index.md 和 log.md。前者是「内容地图」，后者是「历史档案」。Karpathy 专门用一个章节讲述这两个文件，足见其重要性。
index.md — 内容导航地图
index.md 是面向内容的目录，按类别（实体、概念、来源等）组织所有页面的链接和一句话摘要，可选包含日期和来源数量等元数据。LLM 在每次导入后更新它，在回答查询时先读它。
🔑 index.md 的妙处：无需向量数据库 在中等规模（约 100 个来源、数百个页面）下，LLM 先读 index.md 再深入相关页面的方式，效果出奇地好，而且完全不需要复杂的向量数据库基础设施。这是 LLM Wiki 与传统 RAG 的另一个关键差异。 |
# Wiki Index
## 概念页
- [[rag]] — 检索增强生成，传统知识库查询模式 · 3 sources
- [[llm-wiki]] — Karpathy 的持续编译知识库模式 · 5 sources
- [[knowledge-graph]] — 图结构知识表示方法 · 2 sources
## 实体页
- [[andrej-karpathy]] — AI 研究者，OpenAI 前研究科学家 · 8 sources
## 来源摘要
- [[sources/llm-wiki-gist]] — Karpathy LLM Wiki 原始 Gist · 2026-04-04
log.md — 时间线历史档案
log.md 是只追加、不修改的操作日志，记录 Wiki 的完整演进历史。Karpathy 建议每条记录以固定前缀开头，方便用简单命令行工具解析：
## [2026-04-10] ingest | LLM Wiki by Karpathy
- 新增摘要页：wiki/sources/llm-wiki-gist.md
- 更新概念页：llm-wiki, rag, knowledge-base, obsidian
- 新增实体页：andrej-karpathy
## [2026-04-12] query | LLM Wiki vs RAG 的核心区别
- 生成比较分析，已存为 wiki/concepts/llm-wiki-vs-rag.md
## [2026-04-15] lint | 健康检查 #1
- 孤儿页面 2 个：transformer, bert（已建立链接）
- 矛盾标注：rag.md 与 llm-wiki.md 关于积累效应的描述
命令行快速查看：grep "^## \[" log.md | tail -5（查看最近 5 条操作记录）
CH 07
可选 CLI 工具
当 Wiki 规模增长到 index.md 不够用时，可以引入专门的搜索工具。Karpathy 的建议是「按需升级」：先从简单的 index.md 开始，出现问题了再考虑引入搜索引擎。
推荐工具：qmd
qmd 是 Karpathy 在原文中明确推荐的本地 Markdown 搜索引擎，具备以下特点：
•混合搜索：同时支持 BM25 关键词搜索和向量语义搜索，并用 LLM 重新排序结果
•全本地运行：所有搜索在本机完成，数据不离开本地，隐私友好
•双接口：提供 CLI 接口（LLM 可以 shell out 调用）和 MCP 服务器（LLM 原生工具调用）
•Markdown 原生：专为 Markdown 文件设计，理解 Wiki 链接和文件结构
💡 Karpathy 的务实建议 你也可以让 LLM 帮你「vibe-code」（直觉式编写）一个简单的搜索脚本。不要过度工程化——从最简单的方案开始，等真正遇到规模问题时再升级。这是 LLM Wiki 整体设计哲学的缩影。 |
CH 08
实用技巧与工具推荐
Karpathy 在原文中分享了来自亲身实践的具体技巧，每一条都值得认真对待——因为这不是理论建议，而是他真实工作流的提炼。
内容采集：Obsidian Web Clipper
这是一个浏览器扩展，能将网页文章一键转换为 Markdown 格式并保存到 Obsidian vault（即你的 raw/ 目录）。这是将网络内容快速引入知识库的最佳方式。
🖼️ 图片本地化的重要性与技巧 步骤：Obsidian 设置 → 文件与链接 → 附件文件夹路径设为 raw/assets/。设置 → 快捷键 → 搜索「Download」→ 绑定「Download attachments for current file」。剪藏后按快捷键，所有图片下载到本地。好处：LLM 可以直接访问本地图片，不依赖可能失效的外部 URL。 |
浏览器：Obsidian 作为核心 IDE
Karpathy 的实际工作方式：一侧打开 LLM Agent，另一侧打开 Obsidian，LLM 做编辑，他实时浏览结果。
•图谱视图（Graph View）：可视化 Wiki 的连接结构，快速发现「枢纽页面」和「孤儿页面」
•Marp 插件：从 Wiki 内容直接生成 Markdown 幻灯片，无需 PowerPoint
•Dataview 插件：对页面 YAML 前置元数据进行动态查询，生成实时数据表格
版本控制：Git 原生支持
Wiki 本质上就是一个 Markdown 文件的 Git 仓库。这意味着你免费获得：
•完整版本历史，随时回滚到任意状态
•分支功能，可以探索性地实验不同的知识库结构
•多人协作，团队共同维护一个知识库
•清晰的 Diff，查看每次 LLM 对 Wiki 做了哪些修改
•多设备同步：通过 GitHub push/pull 在不同机器间同步 Wiki
CH 09
本质分析：为什么这个方法有效？
Karpathy 的原文最后一章「Why this works」是整篇文章最有深度的部分。我们在此基础上做进一步的本质分析，帮你真正理解这个方法的底层逻辑。
核心洞见：维护成本是知识库的真正杀手
人们在维护知识库时面临的真正困境不是「没时间读书」，而是「读完之后无法有效整理」。整理的本质问题是繁琐的书务工作（bookkeeping）：
•更新 30 个相关页面里的交叉引用
•保持所有摘要与最新信息一致
•发现新旧数据之间的矛盾并标注
•确保同一个概念在整个 Wiki 中定义一致
人类在这类工作上不是能力不足，而是心理上难以长期坚持。维护负担随 Wiki 规模的增长而急剧上升，最终超过价值产出，人们就放弃了。这就是绝大多数个人知识库半途而废的根本原因。
🤖 LLM 的天然优势 LLM 不会感到厌倦，不会忘记更新交叉引用，可以在一次操作中同时修改 15 个文件。维护成本接近于零——这才是 LLM Wiki 最根本的创新所在。不是 AI 更聪明，而是 AI 无限耐心。 |
人机分工的哲学：各做最擅长的事
维度 | 👤 人类负责 | 🤖 LLM 负责 |
认知强项 | 方向判断、价值评估、批判思考 | 大规模文本处理、模式识别、一致性维护 |
具体工作 | 策划信息来源、提出深度问题 | 读取摘要、建立交叉引用、更新页面 |
失败原因 | 对重复性工作失去耐心 | 无法判断什么知识「重要」 |
互补关系 | 提供判断力和方向 | 提供执行力和耐心 |
历史渊源：Vannevar Bush 的 Memex（1945）
Karpathy 在原文中提到了 Vannevar Bush 在 1945 年提出的 Memex 构想。Bush 设想了一种个人、精心策划的知识存储设备，核心是文档之间的「关联轨迹（associative trails）」——这些连接本身比文档内容更有价值。
Bush 的 Memex 与维基百科的方向不同：私人的、主动策划的、连接与内容同等重要。但他没有解决的问题是：谁来做维护工作？
80 年后，LLM 解决了这个问题。LLM Wiki 是 Memex 愿景的第一个真正可行的实现。
「编译」视角：知识也需要预处理
从软件工程的视角来看，LLM Wiki 做的是「知识的预编译」：
•源代码：原始素材（raw/）
•编译器：LLM + Schema
•可执行文件：Wiki 知识库
•运行时：查询（Query）操作
就像软件编译将高层代码转为机器可直接执行的指令，LLM Wiki 将原始文档转为「思维可直接调用」的结构化知识。每次查询，不需要重新「理解」原始文档，直接从已编译的 Wiki 中取用。
CH 10
社区反应与批评性解读
5000+ Stars 背后，社区的真实反应复杂而有价值。既有热情的追随者和衍生项目，也有理性的批评声音。了解这些声音，能帮助你更客观地使用这个方法。
批评性声音：来自 a-a-k 的理性质疑
📝 评论摘要（a-a-k） 「LLM Wiki 是有损压缩。你把原始文档改写成衍生的 Wiki 页面，这可能丢失细节、日期、少数观点、精确措辞。一旦人们开始查询 Wiki 而非原始材料，摘要中的错误就成了知识库的一部分。」这个批评切中要害：Wiki 不是原始文档的等价物，而是有选择的解读。 |
这个批评完全正确，也是为什么：
•原始素材必须保持只读（raw/ 层永远存在）
•对精确细节敏感的领域需要谨慎（法律、医疗等）
•Wiki 是「工作摘要」而非「原始档案」的替代品
衍生项目：启发了真实生态
一周内，Karpathy 的 Gist 启发了多个衍生项目：
项目 | 核心特点 | 地址 |
Kompl | Hegel 式「正题-反题-合题」设计，支持 URL/文件/书签 | github.com/tuirk/Kompl |
SwarmVault | 多平台支持（48 个 Agent 工具），本地优先，离线可用 | github.com/swarmclawai/swarmvault |
ΩmegaWiki | 23 个 Claude Code Skills，支持中英双语，打字知识图谱 | github.com/skyllwt/OmegaWiki |
link-mcp | Python 实现，提供 MCP 服务器接口，带 web 图形界面 | github.com/gowtham0992/link |
VLM-wiki | 扩展支持图片/视频/音频的多模态版本 | github.com/VeniVeci/VLM-wiki |
最简实现：最接近 Karpathy 原意的方案
💻 社区最简实现（zhurudong） 「只有两层（raw/ 不可变 + wiki/ LLM 编译），一个 CLAUDE.md 文件作为整个「程序」，没有向量数据库或导入管道。同一个文件通过软链接到 AGENTS.md，无需迁移即可跨工具使用。」这才是 Karpathy 真正想传达的东西：简单、模块化、按需升级。 |
CH 11
适用场景与边界
LLM Wiki 是一个极具价值的模式，但它不是万能的。清楚地理解它的适用边界，能帮助你在正确的场景下正确地使用它，避免踩坑。
最适合的场景
•规模适中的深度研究：几十到几百篇来源，几百个 Wiki 页面，不是万亿级文档库
•内容变化缓慢：不需要每天大规模更新的知识领域
•人工精心策划：你亲自选择和审查每份纳入的资料，而不是自动爬取
•单人或小团队：不涉及复杂的多用户权限管理
•需要长期积累的主题：研究课题、读书笔记、个人成长追踪
适用性全景对比
场景 | 是否适合 | 核心原因 |
个人深度研究（论文/书籍） | ✅ 非常适合 | 正是核心使用场景 |
读书笔记积累 | ✅ 非常适合 | 正是核心使用场景 |
技术学习（某框架/语言） | ✅ 适合 | 知识有结构，交叉引用价值高 |
竞品分析/商业研究 | ✅ 适合 | 需要跨来源综合判断 |
大规模企业知识库 | ⚠️ 需要谨慎 | 权限、合规、并发问题尚未解决 |
快速变化的新闻资讯 | ❌ 不太适合 | 维护成本高，信息过期快 |
需要精确原文的场景 | ⚠️ 需要谨慎 | Wiki 是有损压缩，可能丢失细节 |
法律/医疗精确文献管理 | ❌ 不建议 | 对精确措辞要求极高的场景 |
CH 12
快速上手实战指南
从零开始搭建你的第一个 LLM Wiki。整个过程不需要任何编程知识，只需要 Obsidian 和一个支持文件操作的 LLM Agent（Claude Code 或 OpenAI Codex CLI）。
第一步：准备工作（5 分钟）
1.安装 Obsidian（obsidian.md），这是你的 Wiki 浏览器和编辑环境
2.安装 Claude Code，这是你的 LLM Agent
3.确定主题：选一个你正在研究或学习的具体领域，越聚焦越好
第二步：建立目录结构（5 分钟）
mkdir my-llm-wiki && cd my-llm-wiki
mkdir -p raw/articles raw/papers raw/assets
mkdir -p wiki/sources wiki/entities wiki/concepts
touch wiki/index.md wiki/log.md
然后在 Obsidian 中打开这个文件夹：Obsidian → 打开其他 Vault → 打开文件夹。
第三步：写第一个 CLAUDE.md（10 分钟）
在项目根目录创建 CLAUDE.md，这是你和 AI 的工作协议，从最简单的版本开始：
# My LLM Wiki Schema
## 目录结构
- raw/：原始素材，只读，任何情况不能修改
- wiki/：LLM 维护的知识库
-index.md：全局目录，每次导入后必须更新
-log.md：操作日志，只追加，不修改
-sources/：每篇原始素材的摘要页
-entities/：人物/机构/产品页
-concepts/：技术概念/方法论页
## 摘要页格式（wiki/sources/ 下的文件）
# [资料标题]
**来源**：[文件路径]**日期**：[导入日期]
## 核心观点（3-5 条）
## 关键数据或引用
## 相关页面（Obsidian 内部链接格式）
## 导入新资料时的完整流程
1. 阅读 raw/ 中的新文件，理解核心内容
2. 与用户讨论：这篇资料最重要的 3 个收获是什么？
3. 在 wiki/sources/ 创建摘要页
4. 更新相关的实体页和概念页
5. 在 wiki/index.md 添加新页面的链接和摘要
6. 在 wiki/log.md 追加：## [日期] ingest | 资料标题
## 查询时的规则
- 先读 wiki/index.md 找到相关页面
- 引用具体 Wiki 页面作为来源
- 有价值的分析可以整理为新的综合页
第四步：导入第一篇资料（15 分钟）
1.将第一篇文章保存到 raw/articles/ 目录（建议从你熟悉的文章开始）
2.打开终端，在项目目录运行 claude（启动 Claude Code）
3.输入：请按照 CLAUDE.md 的规范，处理 raw/articles/[文件名] 这篇文章
4.在 Obsidian 中查看结果，检查摘要页质量和 index.md 更新
5.给反馈并迭代：如果不满意，告诉 AI 修改，同时更新 CLAUDE.md
🚀 最重要的一条建议 从极简开始。一个 CLAUDE.md，三个目录，两个特殊文件。先用 5 篇资料跑通整个流程，再根据实际遇到的问题扩展系统。过度设计是 Wiki 项目失败的首要原因——Karpathy 本人也强调这个系统是「按需升级」的。 |
关注程序员康健
如果这份深度解读对你有帮助，欢迎关注我的内容频道。我持续分享 AI 编程、Claude Code、Agent 开发等一手实践经验，都是真实项目中踩过坑后的干货总结。
扫码关注后，可获取更多教程指南
📹 视频号 程序员康健 AI 编程和职业破局心法 |
📱 公众号 程序员AI破局指南 深度 AI 编程教程，实战干货 |
内容定位：直接、实用、反焦虑、反说教——基于真实项目经验，不追热点，只分享真正有用的 AI 编程实践。
期待在 AI 编程的探索之路上与你同行！
📚 相关阅读