先把第二大脑搭起来
如果你还没有自己的第二大脑，下面这套流程五分钟就能跑通。
- 下载安装 Claude Code（Codex、OpenClaw、Hermes、OpenCode、Cursor 都行，后文统称 Claude Code）
- 下载安装 Obsidian
- 打开 Obsidian 新建一个 Vault
- 在该目录下创建
Claude.md，把 Andrej Karpathy 那份 LLM Wiki 的规则粘贴进去 - 在该目录下打开 Claude Code，对它说「帮我按规则配置好这个知识库」
它会自动建好整套目录结构：
raw/：原始材料，文章、对话、视频字幕直接扔进来wiki/：编译后的笔记，按主题或概念组织index.md：手写的入口页，记录你的知识地图log.md：所有历史更改的记录
这套系统是怎么工作的
你扔一篇原文进 raw，它先写一份总结，再把里面提到的概念、人物、工具、方法各自抽出来建独立页面，最后更新 index.md，把新页面登记进去。
之后你只要把 wiki/index.md 的地址丢给任何一个 AI，它就自动接入了你的知识库——问什么问题都先从你这里找答案，而不是去互联网上漫无目的地搜。换句话说，AI 不是凭空回答，而是基于你过去攒下来的东西在回答。
更妙的一点是，你录入自己想法和日常思考越多，AI 就越懂你。让它写东西时它知道你的语气，让它做判断时它知道你的过去，用得越久越顺手。而且因为是分级查询——先读 index 找到相关页面，再去读具体内容——不需要把所有笔记一股脑塞进上下文，token 省得多。
之后看到任何好内容、日记、想法、录音，全部丢进 raw，只要说一句「帮我录入」，wiki 就会自动多出来 5-10 篇结构化笔记。
wiki + index 的三个天花板
这套系统看上去自洽，但跑半年之后会撞上三个具体的极限场景。
场景一：index 变长之后，定位精度反而下降
按 Karpathy 的 schema，每 ingest 一篇 raw 通常产出或更新 5-10 个 wiki 页。一个 vault 跑半年，wiki 上百是常态，index.md 自己就膨胀到几百行。它是 agent 每次查询的第一站，每次都要先把这几百行读进上下文。token 没省下来，定位精度还下降——分类越细，agent 越要在七八个相近的概念页之间纠结。原本「读 index → 读 wiki」的两跳路径，变成「读 index → 翻 3-5 个 wiki 都不对 → 再回去看 index」。
场景二：跨分类的语义搜索 index 帮不上
Karpathy 的 schema 把 wiki 分成 Concept、Entity、Synthesis、Self-analysis、Comparison 等多类，每类按主题分到各自文件。但你的真实查询往往是跨类的。
比如你想找回「独立开发心态怎么变了」——这个问题可能横跨 self-analysis 页（你两年前的复盘）、synthesis 页（你对独立开发的整体看法）、raw 里某段你跟朋友的对话残片。index 是按「页是什么类型」分类的，不是按「什么概念出现在哪里」分类的，这种跨类搜索它根本帮不上。Claude Code 自带的 grep 也帮不上，因为「心态变化」四个字可能一次都没出现。
场景三：raw 里的细节丢失
这是最隐蔽、也最致命的一条。
按 Karpathy 的 SOP，raw 被 ingest 之后产出的是 wiki 综述页——概念、实体、对比、自我分析。这是设计上的取舍：wiki 页只保留主题骨架，不保留 raw 里的具体细节、原话、例子、数字。
举个例子。你 raw 里塞了一个 30 篇的 AI 课程笔记系列，ingest 之后被压成了 2 个 wiki 页（一个课程地图、一个方法清单）。这两页能告诉 agent「这门课的整体框架和核心方法」，但第 5 课讲的那个调试技巧、第 8 课那个具体的例子、第 14 课那段的原话，全在 raw 里，没进 wiki。raw 里几百篇文件，每一篇都可能藏着你后来想找回的某段具体话——但 ingest 把它们全压扁成了综述，原文进不了 agent 的检索路径。
这三件事的共同根因不是「wiki 模式错了」，而是 wiki 模式擅长「已编译知识」，但整个 vault 还需要一层全文语义检索，覆盖那些没编译进 wiki 的内容、跨分类的查询、和 index 自己膨胀到看不过来的情况。替代方案也不能是「让 agent 把整个 raw 全读一遍」——那样 token 会爆炸。你需要的，是一个能精准定位、只返回相关片段、顺带把 token 省下来的工具。
2026 年做这件事最佳的选择是 QMD。
RAG 补上 wiki 模式的缺口
RAG 的全称是 Retrieval-Augmented Generation，中文叫「检索增强生成」。本质就一句话：你问 AI 之前，先去你的知识库里搜出最相关的几段，再让 AI 根据这些片段回答。答案里出现的事实、引用、细节，全是从你的知识库里来的。
注意：RAG 不是要替代 wiki + index，两者解决的不是同一个问题。wiki + index 解决「把已经知道重要的东西编译成结构化知识」；RAG 解决「在整片 vault 里找跟当前 query 最相关的零散片段」。一个管编译，一个管搜索，互补。
再进一步，混合检索
向量搜索能找到「意思像但字面不像」的内容。你搜「独立开发心态变化」，它能命中你两年前 raw 里某段播客笔记里写的「独立开发的尽头是无聊」——一个字都没重复，意思走到了一起。
那是不是有了向量搜索就够了？不够。向量搜索有自己的死穴：无法精确检索。你搜「qmd v2.1.0」，它可能给你返回 v2.0、v1.9 的相关内容，因为它们语义上太像了。但你要的是那个确切的版本号。
这种时候 BM25（基于关键词频率的精确匹配算法）反而完胜。所以真正靠谱的检索方案是混合检索：BM25 抓精确，向量抓语义，再用一个小模型做重排，把两路结果按相关性重新排一遍，把最好的几个挑出来。QMD 全部做到了。
为什么是 QMD
架构正确，效果好
QMD 的检索流程跟 Google 搜索和 Anthropic Claude 内部检索系统是同一个套路：用户搜索进来，先用一个 fine-tune 过的小模型做 query expansion，每个变体并行跑 BM25 和向量搜索，所有结果用 RRF 合并排序，再扔给 qwen3-reranker 做最终重排，最后按位置加权出最相关的几条。
这套流程在 2020 年之后的学术 IR 论文里被反复验证。QMD 只是把它打包了：以前你要写几万行代码，现在自动装好。
完全本地，免费，使用简单
这是个人 RAG 与企业 RAG 的根本分水岭。企业级 RAG 烧钱在两件事上：托管向量数据库（Pinecone、Weaviate）每月几百美金，调用 embedding API（OpenAI text-embedding-3）按 token 计费。QMD 把这两件都本地化了。
阿里在这件事里贡献最大。Qwen3 是中文用户能在本地跑出商业级检索质量的基础。如果没有 Qwen3，个人 RAG 这件事在中文场景下还得多等一年。换句话说，QMD 本质上是个日用工具，应该跟 grep、ripgrep 一样免费，跟你的操作系统、跟你的笔记软件一样属于基础设施。
还帮你省一大笔 token
QMD 一个隐性好处：让 Claude Code 调用第二大脑时的 token 用量暴降。
原理简单：以前 agent 用 grep 找东西，命中几个文件就要全文读完，一次问答轻松烧两万 token。装了 qmd 之后，agent 直接 query 拿回 3-5 段最相关的片段，每段几百 token，加起来不到一千。
实测参考：Andrew Levine 公开过他的 600+ notes Obsidian vault 数据——没装 qmd 时一次问答烧 15000 token，装上之后同样查询只用 500 token，省 96%。他说从下载到能用花了 5 分钟。如果你正在为 Claude 的 token 用量心疼（尤其是用 API 计费、不是订阅），这件事比免费还实际。
Tobi 和 Karpathy 共同推荐
QMD 的作者是 Tobias Lütke，Shopify 创始人兼 CEO。他 2026 年 3 月连发推说自己在睡前调 query-expansion 模型，GitHub 上 qmd 的 repo 现在已经 25000+ stars。
一个公司估值数百亿美金的 CEO，深夜不睡觉去写一个个人 markdown 检索工具，说明的事情很简单：他自己被同样的问题烦到了。他维护的笔记规模和你我一样会撞上检索瓶颈，他选择自己写一个。
Karpathy 在 llm-wiki Gist 的「Optional: CLI tools」章节原话写：
A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option.
翻译过来：wiki 还小的时候 index 文件索引就够，但 wiki 长大之后你需要真正的搜索——qmd 是个好选择。
装 QMD：一个提示词搞定
cd 到你的第二大脑目录，启动 Claude Code，把下面的内容粘贴给它：
帮我装一下 qmd，把当前目录接进来做检索，我是中文笔记。
npm install -g /qmd # 装 qmd CLI 本体
claude plugin marketplace add tobi/qmd && claude plugin install qmd
# 装 plugin（自动注册 MCP server + 配套 skill）
qmd collection add . --name brain # 把当前目录配置为知识库
切到 Qwen3-Embedding-0.6B 多语言模型（中文知识库必做）
qmd pull # 拉取 qmd query 所需的本地小模型
qmd embed -f # 生成向量索引
第一次会下载约 2.4GB 的本地模型，等几分钟。下载完之后所有 embedding 都在你电脑本地跑，不联网，不烧 API。
为什么要切 Qwen3：QMD 默认 embedding 模型是英文优化的，中文知识库切到 Qwen3-Embedding-0.6B 能大幅提升检索质量。这一步在英文教程里没人讲。
之后 Claude Code 调用第二大脑时会自动走 qmd，你不用做任何事。新增笔记只要偶尔跑一下 qmd update 增量索引就行。
什么时候该动手
要不要立刻装，Karpathy 在 llm-wiki Gist 里给了判断标准：「index 模式在大约 100 个文件、数百页 wiki 的规模下非常好用。但随着 wiki 长大，你需要真正的搜索——qmd 是个好选择。」
按这个标准对照你自己的第二大脑：
- 一百个文件、几百个 wiki 以内：可以先继续用 index，以后再考虑 qmd
- 已经感觉 agent 搜索效果变差，或 wiki 数量近千：尽快上 qmd，搜索效果和 token 账单一起改善
如果你希望你的第二大脑可以长久地运作下去，QMD 是当下最值得动手装的那块拼图。早装早省 token，晚装也比不装强。