Deep Dive · Knowledge Engineering

I. 引子：你和豆包聊了两年，它依然不认识你

不知道你有没有过这种感觉。

深夜十一点，你打开豆包，想跟它讨论一个工作上的事情。前面你已经铺了七八轮，把背景、上下文、人物关系、过往的决策一点点喂给它。聊到第二十轮，你终于有点拍到了想要的方向，关掉对话，安心睡觉。

第二天早上，你想接着昨晚的话题往下推一步。打开豆包一看 —— 历史对话还在，但你要么把昨晚那 20 轮的全部再划一遍重新让它”回忆”起来，要么你只能粘贴一段摘要，眼睁睁看着它像第一次见你一样客气地说：「好的，我来帮您分析。」

它真的不认识你。

它不知道你是产品经理还是后端工程师，不知道你公司用的是飞书还是钉钉，不知道你三个月前已经把「做一个低代码平台」这条路否掉了。每一次对话，对它来说都是 cold start —— 工程上有个准确的术语，叫 冷启动：模型没有任何关于「你」的先验信息，每次开机都从零开始。

这不是豆包的 bug，换 Kimi、通义、ChatGPT 都一样。这是当下所有大语言模型（LLM）的本质 —— 它们没有「长期记忆」，只有「会话上下文」（Context Window）。每开一个新窗口，模型就回到了刚出厂的状态。

而问题在于：你和这个东西交互的时间越长，它没有记忆这件事就越荒谬。

你的工位上贴满了便利贴，你的笔记本里写满了想法，你的脑子里有十几年积累下来的判断力 —— 这些是你之所以是「你」的全部根基。但你最亲密的工作伙伴，那个号称要重塑知识工作的 AI，对此一无所知。

过去两年，整个 AI 圈一直在试图回答这个问题。RAG（检索增强生成）、向量数据库、长上下文窗口、Agent Memory、各种「AI 第二大脑」产品如雨后春笋……方案多如牛毛，但绝大多数普通用户依然在用「开新窗口、重新解释自己」这套原始流程。

直到 Andrej Karpathy —— 这个被许多人称作「AI 教父之一」的人 —— 在过去一年里，反反复复在推特、播客、个人 blog 上提到同一件事：

你应该自己维护一个 markdown 写的、LLM 可以读懂的个人 wiki。然后把它喂给 Claude。这就是当下最朴素也最强大的「第二大脑」。

听起来简单到离谱：写 markdown 笔记，喂给 Claude。

但理解这句话背后的工程含义、为什么是 Claude 而不是 ChatGPT 或豆包这一类对话 AI、为什么是 markdown 而不是 Notion、为什么是 Obsidian 而不是印象笔记，以及 —— 最关键的 —— 普通人到底怎么把这套搭起来，远没有那么简单。

这篇文章就来把这件事彻底讲透。

II. 卡帕西到底说了什么：还原 “LLM-friendly Wiki” 的核心洞察

先简单介绍一下卡帕西

Andrej Karpathy 是谁？

斯坦福博士、OpenAI 创始团队成员之一（编号 11 号员工）、Tesla 自动驾驶项目前 AI 负责人，2023 年再次回到 OpenAI 又离开，目前以独立研究者和教育者的身份活跃在 AI 一线。他在 YouTube 上的《Neural Networks: Zero to Hero》和《Let’s build GPT》等系列教程，是全球 AI 工程师入门的事实标准。

你可以把他理解成：既懂模型底层、又懂工程实现、还擅长把复杂概念讲明白的极少数人之一。

正因为这个身份，他对「普通人应该怎么用 LLM」这个问题的判断，比绝大多数自称专家的人更具有信号量。

他反复在讲的三个判断

过去一年多的时间里，Karpathy 在不同场合反复表达过几个层层递进的观点。先用一段话给你结论，再各自展开：

判断一：LLM 即新一代操作系统 —— 模型是 CPU，需要为它配套一个持久化的「文件系统」。

判断二：Markdown 是 LLM 的母语 —— 训练数据的分布决定了这个数据格式是最优解。

判断三：隐性知识的显性化是 AI 时代的杠杆前置条件 —— LLM 放大的是你已经表达清楚的东西。

下面逐条拆。

Judgment 01 — LLM 是新一代操作系统（LLM as the new OS）

这是他 2023 年那场被广泛传播的演讲里提出的框架。他的核心比喻是：LLM 之于今天，就像 1970 年代的 CPU 之于早期计算机。LLM 是新的「中央处理单元」，但围绕它，需要长出一整套新的「操作系统」 —— 文件系统、内存、进程调度、外设接口等等。

这个比喻里最关键的一点是：操作系统需要持久化的文件系统。

今天的 LLM 就像一台没有硬盘的 CPU —— 每次开机都从零开始。这显然不是终极形态。

Judgment 02 — 你的「记忆」应该是 LLM 可以直接消化的格式

这是判断一的自然推论。既然 LLM 需要「硬盘」，那么这个硬盘里的内容应该是什么形态？

Karpathy 的答案非常明确：纯文本、markdown 结构、内部可链接。

他多次表达过这样的意思：你存在 Word 里、Notion 里、印象笔记里的那些笔记，其实对 LLM 都不太友好。要么格式被锁定在某家公司的私有数据库里、模型读起来要先经过转换；要么夹杂太多视觉化噪音（嵌入式块、各种 emoji、不规则的版式）；要么本身就只是为人类阅读优化的，没有结构化标记。

LLM 在训练时见过的最干净、最结构化、最容易理解的文本形态是什么？是 GitHub 上的 README、是 Wikipedia 的 wikitext、是技术文档站点的 markdown。也就是说 —— markdown 是 LLM 的母语。

所以你给 LLM 准备的「记忆」，最优解就是 markdown。

Judgment 03 — 在 LLM 时代，能把自己整理出来的人会有不公平的优势

这是他在多次访谈里都讲过的意思，原话可能略有不同，但精神是一致的：

LLM 是一个能力放大器，但它放大的是 你已经表达清楚的东西。你越能把自己关心的问题、积累的判断、做事的方法系统地写下来，LLM 就越能在你这个「个人语境」里给你提供有价值的输出。反之，如果你只是模糊地知道「我想要 X 但我不知道怎么说清楚」，那再聪明的模型也帮不了你。

所以这个 wiki 不是「为了用 LLM」才写的 —— 它本质上是 逼自己把脑子里的隐性知识显性化的工具。LLM 只是让这件事第一次有了对等的回报。

他自己的工作流（公开提到过的片段）

Karpathy 自己用 markdown 维护一组个人笔记，覆盖他在做的研究、读过的论文、思考过的问题。当他需要 LLM 帮他做某件具体的事（比如 review 一段代码、批判一个想法、起草一份说明），他会把相关的笔记片段 —— 有时候是整组 —— 粘贴或加载到 Claude 的对话里作为上下文，然后再开始问答。

他特别强调过两点：

第一，他用的是 Claude，不是 ChatGPT。理由后面我们会专门拆。

第二，这套工作流不需要任何花哨工具 —— 一个文本编辑器、一个 LLM、一些纪律性，就够了。所谓 Obsidian、所谓双向链接、所谓 MCP，都是后来社区帮他往工程化方向继续推的产物。卡帕西本人公开的 setup 极简到让很多人失望。

但正是这种「朴素到极致」的形态，才暴露出问题的本质 —— LLM 时代的知识管理，关键不在工具，在格式协议和习惯。

为什么这套思路现在突然火了

值得追问的一点是：markdown 笔记 + LLM 这个组合，技术上 2023 年初就能做了。为什么直到 2025 年，整个圈子才认认真真把它当回事？

我的观察是三个推力同时到位：

  1. Claude 把上下文窗口推到了 200K（标准版）甚至 1M（开发者版），笔记终于”装得下”。早期 GPT-4 只有 8K~32K 上下文的时候，你最多能塞进去十几篇短笔记，根本不够当 wiki 用。
  2. Anthropic 在 2024 年发布了 Claude Projects 功能，让普通用户可以把一组文件一次性挂载给 Claude 做持续上下文。这一步把「复制粘贴 markdown」这个动作工程化了。
  3. Claude Code 这种 CLI 工具的出现，把卡帕西那套「LLM 直接读你的文件系统」的设想做成了开发者能直接用的产品。后面我们会专门讲。

也就是说，2025 年这个时间点，硬件（context window）、软件（Projects）、协议（CLAUDE.md）三件套终于齐了。卡帕西讲的事，从理论上的对，变成了普通人可以真正搭起来的对。

III. 为什么是 markdown + Claude + Obsidian：技术层的深度拆解

理论讲完，接下来进入工程层。要理解为什么这个组合是当下最优解，你需要分别看清楚三个东西到底解决了什么问题。

3.1 Context Window 200K 的真实工程含义

先把这个数字翻译成人类能感知的量级。

Claude 标准版的上下文窗口是 200K tokens。中文里，一个 token 大致对应 1.5～2 个汉字（具体取决于内容）。也就是说，200K tokens 大概能装：

  • 30 万字中文文本 —— 相当于一本 800 页的书；
  • 或者 600 篇 500 字的笔记 —— 这已经是一个中度知识工作者好几年的笔记量；
  • 或者 150 万行代码注释 —— 足够装下一个中型项目的全部 README、设计文档、commit log。

如果你用的是 Claude Code 这种开发者版本，上下文可以拉到 1M tokens —— 也就是 150 万字中文。这是什么概念？整套《资治通鉴》中华书局点校本是 300 万字左右，1M 上下文相当于半部《资治通鉴》一次性塞给模型，让它在这个上下文里跟你对话。

为什么这个数字至关重要？

因为它决定了 你的整个 wiki 是不是能一次性出现在模型的「视野」里。

RAG 是另一种思路：把笔记切片、做向量嵌入、按问题相似度检索、只把相关片段喂给模型。这种方案在 context window 还很小的时代是必需的，但它有两个致命问题：

一是 切片必然丢失上下文。一篇笔记里靠后的部分往往依赖前面的设定，被单独切出来的段落很容易被模型误读。

二是 向量检索本质上是基于「语义相似」，但真正有用的关联往往是「逻辑相邻」。比如你问「那个跟我们 Q3 那个失败的合作有关的事」，向量检索找不到，因为它不知道哪些笔记是「那个合作」的上下文链。

而当上下文窗口足够大的时候，最朴素的方案反而最强：把整个 wiki 全部丢进去，让模型自己看。这种做法在工程圈有个直接的叫法 —— 暴力上下文（brute-force context）。Karpathy 反复强调的就是这一点：在 LLM 能力强到一定程度后，工程上的精巧反而不如暴力上下文。

为什么「暴力」反而胜过「精巧」？ 关键在 Transformer 模型的 全局注意力机制（Global Attention） —— 只要内容进入了上下文窗口，模型每一次推理时所有 token 之间都会两两计算关联权重。换句话说，整个 wiki 同时出现在上下文里，意味着 Claude 在回答「我应该接受这个 offer 吗」这种问题时，是 同时考虑 你写过的所有职业笔记、决策框架、过去类似选择的反思，而不是只读到检索器认为「相似」的那 3 段。

这是 RAG 切片式喂养永远做不到的 —— 它本质上是「局部最优」，而全局注意力下的暴力上下文是「全局推理」。模型能力升级到 200K+ 上下文之后，这条工程权衡的天平就开始倾斜了。

3.2 Markdown 的 Token 经济学

第二件事是格式。

很多人会问：我已经有 Notion 了，为什么要换成 markdown？我的笔记导出成 PDF 喂给 Claude 不也能用吗？

答案藏在 token 的计费机制里。

LLM 接收的所有文本都会先被一个叫 tokenizer 的东西拆成 token。同样一句话，编码方式不同，消耗的 token 数差异可以非常大。

我们做个粗略对比（数字是大致估算，受具体内容影响）：

格式1000 字 token 数理解质量工程评估
纯 markdown（标题/列表/链接）1500～1800极高结构化标记 ## [[]] 高度契合训练分布
Word/DOCX 导出 plain text1500～1800中剥离了排版，也丢失了章节级联等逻辑结构
Notion 导出 markdown1800～2200中包含大量私有 block ID、metadata 噪音
PDF 提取文本2000～3000低物理排版被压扁，伴随换行错乱、断句识别错误
HTML 网页源码3000～5000极低夹杂 DOM 标签、CSS 样式、脚本，信噪比极差

注意右边这两列 —— 这才是真正决定方案的部分。

Token 数只是表面的成本：同样的信息量，markdown 让你在固定上下文窗口里能多装 30%~50% 的内容。但更致命的是 信噪比（Signal-to-Noise Ratio） —— 你想传达的信息和模型必须先剥离的噪音之间的比值。HTML 表面看是文本，实际上 80% 是 <div class="x"> 之类的标签，模型要先”洗掉”才能看到你写的东西，而每一次洗都会损失理解精度。

为什么 markdown 的「理解质量」是极高？LLM 是在巨量文本上训练出来的，它见过的最规范、最高质量的结构化文本就是 markdown —— GitHub 上的项目文档、技术博客、Wikipedia 的源码。对模型而言，看到 ## 二、卡帕西到底说了什么 这种标题，它 瞬间 就知道这是一个二级章节、是文档的逻辑节点；看到 [[某概念]] 这种 wiki 链接，它知道这是一个内部引用。这些识别不需要「推理」，是模式匹配级别的反射。

所以选 markdown 不是审美选择，是 对 LLM 训练分布的工程妥协 —— 你在用模型最熟悉的「母语」跟它对话，而不是逼它把你的方言翻译成母语再理解。

3.3 Obsidian 为什么是这件事的最佳载体

OK，假设你接受了 markdown 这个协议。那么用什么工具来写 markdown？

VS Code？Typora？Bear？iA Writer？

候选很多，但要满足「个人 LLM wiki」这个具体需求，Obsidian 几乎是不可替代的，原因有四个：

第一，本地优先（local-first）

你的所有笔记都是普通的 .md 文件，直接存在你硬盘的一个文件夹里（Obsidian 把它叫做 “vault”）。Obsidian 本身只是一个查看和编辑器，没有任何云端锁定。

这点对 LLM wiki 至关重要 —— 因为下一步你要让 LLM 程序（无论是 Claude Code 还是 MCP 服务器）直接读你的 vault 目录。如果你的笔记被锁在 Notion 的云数据库里、印象笔记的专有格式里，这个动作就做不了。

第二，双向链接（backlinks / [[wiki-link]]）

Obsidian 原生支持 [[笔记名]] 这种语法 —— 你在 A 笔记里写 [[B 笔记]]，B 笔记会自动反向出现一条「被 A 引用了」的回链。这是从 Roam Research 起家的范式，本质上把一组扁平的笔记变成了 知识图谱。

为什么这对 LLM 友好？因为当 Claude 读到 [[Karpathy 的 LLM OS 演讲]] 这种链接时，它能立刻判断这是一个内部概念引用，并在 vault 范围内自动找到对应笔记，把相关上下文一并纳入推理。这相当于 免费给模型加了一层「语义索引」，而你只需要写一对方括号。

第三，插件生态极其活跃

Obsidian 有一个开放的 plugin 体系，社区已经做出了几百个跟 LLM 集成相关的插件：直接在编辑器里调 Claude API、自动给笔记加 frontmatter、根据当前笔记搜索相关上下文、自动生成知识图、自动同步到 GitHub 做版本控制……

这些都不是 Obsidian 自己做的，是社区基于它的开放架构做的。这种生态意味着：未来不管 LLM 工作流怎么演化，你的工具栈不会被锁死。

第四，文件就是文件

最后这一点听起来很玄但其实最重要 —— 你的 vault 是一组普通的 markdown 文件，存在你硬盘上。它可以被 Git 版本管理、被 rsync 同步、被任何文本编辑器打开、被任何脚本批量处理、被任何 LLM 直接消化。

二十年后，无论 Obsidian 这家公司还在不在、Claude 这个产品还在不在、AI 行业变成什么样，你的笔记 永远是你的。这是 markdown + 本地文件这条路径相比所有 SaaS 笔记应用最根本的护城河。

3.4 为什么是 Claude 而不是 ChatGPT

最后说说为什么这套方案专门绑定 Claude。

公平地说，ChatGPT 也能做 personal knowledge base 这件事，OpenAI 的 GPTs 也能上传文件。但 Karpathy 公开站队 Claude，并不是无来由的偏好，背后有几个相对明确的工程理由：

第一，上下文窗口的代际差异

Claude 标准版 200K，长版本 1M。ChatGPT 标准版 128K（注：以发文时为准，具体数字会随版本更新）。在「装下你整个 wiki」这件事上，Claude 现阶段领先一个身位。

第二，对长文档和结构化文本的理解质量

这是无法用单一数字衡量的差异，但在实际使用中非常明显。Claude 对长 markdown 文档的「全局把握」能力 —— 比如你扔进去一组 100 篇笔记让它给你做综述、找矛盾、抽取主题 —— 往往比 GPT-4 更稳。Anthropic 在长上下文检索（Needle in a Haystack）测试上的指标也长期领先。

第三，Claude Projects 和 Claude Code 把「持续上下文」工程化了

Claude Projects 让你可以把一组文件一次性挂载，之后每次对话这些文件都自动出现在上下文里 —— 你不用反复粘贴。

Claude Code 更进一步：它是一个跑在你本地终端的 CLI 工具，可以直接读写你的文件系统、自动维护 CLAUDE.md 这种 project memory，跨会话持久化你和它的所有约定。这就是 Karpathy 那套「LLM 直接读 wiki」思路的事实标准实现。

OpenAI 也有类似产品（Codex CLI、Custom GPTs），但 Claude 生态在「个人 wiki + LLM」这个具体场景上的成熟度，现阶段确实领先半年到一年。

3.5 三者的化学反应

把上面三件事放到一起，你会发现它们不是简单的「工具拼盘」，而是一个 完整的协议栈（Protocol Stack） —— 每一层有清晰的职责、清晰的边界、可以被独立替换：

┌────────────────────────────────────────────┐
│  推理层  Claude                             │ ← 200K 上下文 + 全局注意力
├────────────────────────────────────────────┤
│  协议层  Markdown                           │ ← LLM 母语 + 高信噪比
├────────────────────────────────────────────┤
│  管理层  Obsidian                           │ ← 本地优先 + 双向链接 + 插件
├────────────────────────────────────────────┤
│  持久层  你的本地硬盘 (+ Git)               │ ← 永远归你 + 可版本控制
└────────────────────────────────────────────┘

把这个图和 Karpathy 那个「LLM 即新一代操作系统」的比喻对照一下，对位非常工整：

  • 推理层 Claude = CPU：负责所有计算和推断
  • 协议层 Markdown = 文件格式标准（类似 Unix 上的 plain text）：所有数据的通用编码
  • 管理层 Obsidian = 文件管理器（类似 macOS 的 Finder）：让你能看、能改、能组织
  • 持久层 硬盘 + Git = 文件系统 + 版本控制：你资产的最终归属

每一层都可以独立替换：今年用 Claude，明年可能切到某个更强的模型；今年用 Obsidian，明年可能切到 LogSeq、Reflect 或别的工具。但只要中间的「markdown 协议层」和「本地文件持久层」这两层不变，你的全部资产都是 完全可迁移的。

这种 架构解耦 —— 而不是任何单一工具 —— 才是这套方案能跑得长远的根本原因。它跟 Unix 哲学的精神一脉相承：每个组件只做一件事，组件之间用最朴素的协议（文本流）通信，整个系统因此可以无限演化。

IV. 普通人的搭建路径：基础版（5 步）和进阶版（3 步）

理论部分到此结束。这一节给你两条可以直接照做的路径。

第一条面向 所有读者：完全用 Obsidian + Claude.ai 网页版的 Projects 功能搭建，5 步走完即可上手。

第二条面向 开发者或重度用户：用 Claude Code CLI 实现卡帕西原版思路，让 LLM 直接读写你的 vault，效果更接近「AI 长期记忆」。

4.1 基础路径：Obsidian + Claude Projects（5 步）

第 1 步：装 Obsidian 并建立你的第一个 vault

去 obsidian.md 下载，全平台都有，免费版完全够用。装好后第一件事是创建一个 vault —— 它本质上就是你硬盘上的一个文件夹，里面所有 .md 文件都会被 Obsidian 识别。

新手建议：vault 起一个简单的名字比如 MyKnowledge，路径放在你能找得到的地方（不要放在 iCloud Drive 这种自动同步目录里，会有同步冲突问题）。

第 2 步：决定你的笔记结构

这一步最容易被忽略，也最影响后期体验。

常见的几套笔记组织法：

  • PARA（Projects / Areas / Resources / Archives）—— 适合事务型工作者；
  • Zettelkasten（卡片盒笔记法）—— 适合学术研究者；
  • 简版三件套（Inbox / Notes / Maps）—— 适合刚开始的人。

我推荐绝大多数人从 简版三件套 起步：

MyKnowledge/
├── Inbox/        ← 随手记，未整理的碎片
├── Notes/        ← 正式的、单一主题的笔记
└── Maps/         ← 主题索引页（MOC：Map of Content）

Inbox 里你怎么乱写都没关系，关键是定期（一周一次）把里面的东西消化成 Notes/ 里的正式笔记。Maps/ 里放几个「主题门户页」，比如 Maps/我对 AI 的思考.md，里面用 [[link]] 链接到 Notes/ 下相关的所有笔记。

第 3 步：写 10～50 个起步笔记

这一步是门槛。

很多人装完 Obsidian 兴致勃勃，写了三天就放弃了。原因往往是 没有切入点 —— 不知道写什么。

给你一个具体的起手式：从 你最近三个月里跟人解释过 3 次以上的事 开始写。

比如：

  • 你给三个不同的人解释过你为什么从 A 行业跳到 B 行业；
  • 你给同事讲过两次某个项目的来龙去脉；
  • 你跟豆包反复讨论过同一个问题。

把这些「反复在脑子里跑的内容」先各自写成一篇 500～1500 字的笔记。10 篇这样的笔记到位，你的 vault 就活了。

写的时候注意三件事：

  1. 加 frontmatter —— 文件最上面用 --- 包起来一组 YAML，至少写 title 和 tags，让 LLM 之后能更快定位；
  2. 写完做 [[link]] —— 任何一个概念、人名、项目名，如果你预期之后还会再聊到，都立刻用 [[]] 包起来；
  3. 写完看一遍 —— 确认自己一周以后回来看还能看懂，不能看懂就补充上下文。

第 4 步：开 Claude Pro，建一个 Project

去 claude.ai 注册账号，开 Pro 订阅（约 20 USD/月）。Pro 版本才有 Projects 功能。

建一个新 Project，起名比如「我的知识助手」。然后做两件事：

a) 上传 vault

把你整个 vault 文件夹打包成 zip，或者把里面的 .md 文件批量拖进 Project 的 Knowledge 区域。Claude Projects 当前对 Knowledge 总量有上限（撰文时约 200K tokens 等价的文件量，会随时间放宽），所以早期不用担心装不下。

进阶技巧：用一个简单脚本把你的 vault 里所有 .md 文件 合并成一个大文件 再上传，这样 Claude 能更连贯地把握内容关系。

mac/linux 上一行命令：

find /path/to/vault -name "*.md" -exec cat {} \; > vault_concat.md

b) 写 System Prompt

在 Project 的 Instructions 里，告诉 Claude 怎么用你这堆笔记。一个起步模板：

你是我的个人知识助手。我会把我的全部 markdown 笔记作为
context 给你。在我提问时，请：

1. 先快速 scan 我笔记里相关的内容，把相关笔记的标题列出来；
2. 基于我笔记里的观点、判断、上下文来回答，不要自由发挥；
3. 如果笔记里有冲突或不一致，明确指出；
4. 我笔记里没有覆盖的内容，可以基于你的通用知识回答，
   但要明确标注「这部分超出了你的笔记范围」；
5. 保持简洁，不要复述我已经知道的事；
6. 回答里引用具体笔记时，用 [[笔记名]] 格式让我能跳回去看。

这个 prompt 是核心。它把 Claude 从「百科全书」切换成「我的助手」模式 —— 一字之差，体验天壤之别。

第 5 步：建立「双向更新」的习惯

最后一步是把这件事变成一个 闭环系统 而不是一次性 setup。

具体做法：

  • 每周一次：把 Inbox 里的碎片整理进 Notes，新增的 .md 文件批量 re-upload 到 Project；
  • 每月一次：让 Claude 自己 review 你的 vault，找出「过时的」「内部矛盾的」「应该被合并的」笔记，你照它的建议做整理；
  • 重要对话沉淀：每当你跟 Claude 有一段特别有价值的对话，把它整理成一篇笔记放回 vault —— 人 + AI 共同产出的内容必须回流到知识库，否则就浪费了。

到这一步，你已经有一个真正能用的「LLM-friendly 个人 wiki」了。

4.2 进阶路径：Claude Code + memory.md（3 步）

如果你是开发者、或者愿意用一点命令行 —— 那么你可以走 Karpathy 真正在用的那条路：让 Claude 直接读写你的文件系统。

这条路的核心工具是 Claude Code —— Anthropic 官方的 CLI 工具，可以理解成「会写代码会维护文件的 Claude」。它不是给你写代码用的（虽然它的本职工作是），它的设计思想其实更接近 「一个常驻在你本地的 LLM agent」。

第 1 步：装 Claude Code

npm install -g @anthropic-ai/claude-code
# 或者用其他你习惯的方式：brew、独立安装包等

装好后在终端跑 claude，第一次会引导你登录 Anthropic 账号。

第 2 步：在你的 vault 根目录创建 CLAUDE.md 和 memory/MEMORY.md

进入你的 vault 目录：

cd /path/to/MyKnowledge

创建一个 CLAUDE.md 文件，放在 vault 根目录。这个文件是 Claude Code 的「会话级 system prompt」 —— 每次你在这个目录下启动 claude，它都会自动加载这个文件作为基础上下文。

CLAUDE.md 里放什么？放你希望 Claude 在这个 vault 里始终知道的内容：

# 我的知识库使用规则

这是我的个人 markdown 笔记库。请遵守以下规则：

## 关于我
- 我是 [职业/角色]，主要关心 [话题领域]
- 我的笔记按 PARA 法组织（详见 Maps/_index.md）
- 我用 [[wiki-link]] 做内部链接

## 你可以怎么帮我
- 帮我整理 Inbox/ 下的碎片到 Notes/
- 帮我找笔记之间的矛盾或重复
- 帮我基于已有笔记起草新内容
- 提醒我哪些笔记「过时了」（基于 frontmatter 的 date）

## 你不要做的事
- 不要主动修改 Notes/ 里的现有笔记，先跟我确认
- 不要捏造引用，只能引用 vault 里真实存在的内容
- 不要用 emoji

然后再建一个 memory/MEMORY.md，这是 Claude Code 的「长期记忆索引」。它会自动维护 —— 每次会话里你告诉它的新事实、新偏好、新决策，它会自己整理成笔记存进 memory/ 子目录下，并在 MEMORY.md 里更新索引。

这就是真正的 「AI 长期记忆」 —— 跨会话、可读可写、版本可控（你完全可以 git init 整个 vault）。

第 3 步：用对话训练你的 wiki

接下来的用法就极其自然了。在 vault 目录里跑 claude，然后正常对话：

> 我想梳理一下我对「知识工作者杠杆」这个话题的所有零散想法

Claude 会扫描你的 vault，列出所有跟「杠杆」相关的笔记，
做一个 cross-reference，告诉你你的几个观点之间的关联和矛盾。

> 我觉得我在 Notes/leverage-1.md 里说的那个不太对，
> 应该改成「杠杆的代价是表达成本」

Claude 会问你要不要直接改文件、要不要在 memory 里
记一笔「我对杠杆的最新理解」。

这种工作流里，你的 vault 在被你和 Claude 共同维护。你每次的 thinking 都自动沉淀回知识库，下次开新会话，Claude 还认识你。

这就是 Karpathy 那句「在 LLM 时代能把自己整理出来的人会有不公平优势」的具体形态 —— 你和 LLM 之间有了共享的记忆地基。

4.3 两条路径的选择建议

简单总结：

维度基础路径（Claude.ai Projects）进阶路径（Claude Code）
上手难度简单，全图形界面需要命令行
自动化程度手动 re-upload自动读写，跨会话持久
适合人群知识工作者、非技术开发者、深度用户
月成本Claude Pro ~20 USDClaude Pro/Max + API
最大短板Knowledge 容量上限学习曲线
接近卡帕西原版的程度70%95%

绝大多数人从基础路径开始，跑顺了再考虑要不要升级。

V. 进阶玩法、局限与未来

最后一节，把这套方案的边界、能往哪走、不能解决什么，老实说清楚。

5.1 进阶玩法：MCP 让一切自动化

如果你走到了 Claude Code 这一步，下一个会自然进入视野的概念是 MCP（Model Context Protocol）—— Anthropic 在 2024 年底开源的一个协议，目的是让 LLM 能用统一的方式连接到外部数据源和工具。

跟我们这个话题最相关的，是 Obsidian MCP Server —— 一个跑在你本地的小服务，让 Claude（无论是网页版还是 Code 版）可以 直接读写你的 Obsidian vault，而不需要你手动上传或粘贴。

装好之后的效果：你跟 Claude 说「帮我看看 Notes/AI/ 下面所有笔记的最近修改情况」，它真的会去你硬盘上扫一遍然后告诉你。说「在 Inbox 里新建一篇笔记叫 X，内容是 Y」，它真的会建。

这一步走完，你的 wiki 和 Claude 之间的 「操作摩擦」基本为零。

类似的 MCP server 还有几十个：连 GitHub 的、连 Notion 的、连 Linear 的、连 Slack 的、连你的日历的……都可以挂载给 Claude。但 不要一上来就装一堆 —— 先把 markdown wiki 这条主线跑顺，再按需扩展。

5.2 局限：这套方案不能解决什么

诚实地说，「Claude + Obsidian wiki」不是银弹。把四条工程局限说清楚：

第一，隐私边界（Data Boundary）

只要你用 Claude.ai 或 Claude Code，你的笔记都会经过 Anthropic 的服务器。Anthropic 的政策是默认不用用户数据训练，但 你的笔记物理上会出现在他们的网络里。

如果你的笔记涉及商业机密、客户隐私、法律敏感内容，这个方案不适合你。降级方案：本地跑 Llama 3 / Qwen 等开源模型 + Obsidian Local LLM 插件，完全离线，但会牺牲一截推理质量和长文召回能力。

第二，物理容量天花板（Context Ceiling）

200K 上下文听起来很大，但当你的 vault 累积到几千篇笔记之后还是会击穿。届时架构要演进 —— 要么用 Claude Code 让模型按需读文件（不需要全量加载），要么回到 RAG 作为前置召回（先 top-k 检索再喂全文）。本质上是从「全量上下文」切换到「agent 按需读取」模式。

第三，模型理解 ≠ 模型行动

Claude 能读懂你的笔记不代表它能替你做决策。它会基于你的笔记给你建议，但 最后做决定的还是你。这套系统的目标是把你的思考效率放大 10 倍，不是把你的思考替代掉。

第四，输入质量守恒（Garbage In, Garbage Out）

架构无法修复低质数据。如果你只是把朋友圈、微博、随手记往里堆，LLM 也只能输出朋友圈级别的洞察。模型输出的逻辑深度，严格受限于笔记本身的结构化水平 —— 这点跟卡帕西的判断三完全呼应：wiki 是逼自己结构化思考的工具，不是逼自己多记几条信息的工具。

5.3 跟 RAG、Agent Memory、向量数据库的关系

最后说说这套方案在整个 AI 生态里的位置。

vs. RAG：RAG 不是这套方案的对立面，是它的扩展。当 wiki 大到上下文装不下时，RAG 可以作为检索前置 —— 先用向量找出 top-k 篇相关笔记，再把这些笔记的全文塞进 context 让 Claude 推理。Claude Code 内部其实就在做类似的事。

vs. Agent Memory（如 MemGPT、各种 LangChain Memory）：这些是给 LLM 做「自动记忆」的工程方案。它们的优势是无感、自动；劣势是不可控、不可读。Karpathy 这套方案的关键差异是 —— 记忆是人类可读可改的 markdown 文件。你随时能打开看，随时能改，随时能版本管理。这个透明度在生产场景里非常重要。

vs. 向量数据库（Pinecone / Weaviate / Chroma）：这是 RAG 的基础设施层。对普通用户来说，你 不需要 直接接触这一层。Obsidian 的「插件版 RAG」（比如 Smart Connections、Copilot for Obsidian）已经把这件事封装好了。

vs. 个人 fine-tune 一个模型：这是更激进的路线 —— 把你的笔记和过往对话喂给一个开源模型做微调，得到一个「你的私人模型」。理论上是终极方案，但当前成本高、效果不稳，对绝大多数人来说不如 wiki + Claude 这条路实在。

5.4 未来会怎样

最后做一点判断。

未来 1～2 年，这件事的演化方向我大致预期是：

  1. 上下文窗口会继续扩大，但增长边际递减。10M 上下文可能在 2027 年成为标配，但成本和延迟也会涨，所以「按需读文件」的 agent 模式会成为主流，不是把所有东西硬塞进 context。
  2. MCP 这类协议会标准化。你的 wiki 会通过统一的协议连接到所有 LLM —— 今天是 Claude，明天可能是 Gemini Ultra、可能是某个开源模型，但接口不变。
  3. 笔记格式会出现「LLM-native」的微进化。比如 frontmatter 会标准化（加上 last_reviewed、confidence、outdated_at 这些字段），让 LLM 能自动管理知识的时效性。
  4. 「个人 wiki + 个性化模型」会成为知识工作者的标配。就像今天每个工程师都有自己的 dotfiles 和 GitHub repo 一样，未来每个严肃的知识工作者都会有自己的 vault 和 system prompt。

但是 ——

这些都不需要你等。

卡帕西反复强调的核心是：这套思路今天就能用，明天还能用，十年后基础形态也不会变。markdown 不会过时，本地文件不会过时，「让 LLM 读你写的东西」这个根本模式不会过时。

变的只是 LLM 越来越强、工具越来越顺手。但只要你今天开始建你的 wiki，你就在为所有这些未来红利做准备。

尾声

写到这里，差不多 10000 字。

如果你只想从这篇文章里带走一句话，那就是 Karpathy 那个判断的简化版：

在 LLM 时代，把自己整理出来的人有不公平的优势。

而 markdown + Claude + Obsidian，是当下成本最低、上手最快、长期价值最高的整理工具组合。

工具会迭代，模型会更新，但 「用结构化文本管理自己的知识」这件事，本身就值得做 —— 哪怕未来某天 LLM 进化到了我们今天想象不到的形态，你写下的那些笔记依然是你的。

行动清单

如果你想立刻开始 ——

  1. 今晚装一个 Obsidian，建一个 vault，叫 MyKnowledge；
  2. 写 3 篇笔记，主题就是你最近反复跟人解释的事；
  3. 用 [[]] 把它们之间相关的概念互相链接起来；
  4. 周末开一个 Claude Pro 账号，把 vault 上传到一个 Project；
  5. 用本文 4.1 第 4 步的 system prompt 问它第一个问题：「基于我的笔记，你能看出我最近在思考什么主线问题？」

第一次看到 Claude 真的基于你写的东西做出有意义的回应时，你会理解 Karpathy 说的「不公平优势」是什么意思。

本文不推荐任何商业产品。文中提到的工具均可独立使用，互不依赖。 卡帕西原始观点的具体出处推荐自行检索：YouTube “Andrej Karpathy”、Twitter @karpathy、个人 blog karpathy.ai。