那篇文章戳到了什么
前几天 Andrej Karpathy 在 GitHub 上发了一篇叫 LLM Wiki 的短文。我读完之后坐在椅子上想了大概十分钟。
不是因为他讲了什么新技术，而是因为他把一个我一直在做但从来没想清楚的事情，说得太透了。
我的笔记散落在 Obsidian、Notion、飞书文档、微信收藏夹和各种聊天记录里。每隔一段时间我就会花一下午整理，把某个主题的笔记归拢到一起。但过不了两周，这些笔记又会落灰。
核心矛盾其实就一个：我愿意读、愿意想，但不愿意做整理的苦力活。 写摘要、建交叉引用、更新旧页面、标注矛盾——这些事每一件都有价值，但每一件都足够无聊到让我放弃。
AK 的方案一针见血：这些苦力活全部交给 LLM。你只管读、想、问。
为什么是 Obsidian + Claude Code
我手里有不少 LLM 工具——Claude Code、Codex、OpenClaw、Cursor，还有各种 Web 端的聊天界面。在这个场景下选谁，取决于一个核心能力：能不能直接、稳定地读写本地文件。
筛选完之后剩下的其实就两个：Claude Code 和 Codex。
我选了 Claude Code，理由有三个：
第一，CLAUDE.md 天然就是 Schema 文件。 AK 架构里的"第三层"——那个告诉 LLM 如何维护 Wiki 的配置文件——在 Claude Code 里有现成的约定。你在项目根目录放一个 CLAUDE.md，Claude Code 每次启动都会读它。不用任何额外设置。
第二，文件操作是一等公民。 Claude Code 可以直接创建、读取、编辑、删除 Markdown 文件。你说"把这篇文章摄入 Wiki"，它就真的去读源文件、写摘要页、更新索引、改关联页面。整个过程你在 Obsidian 里实时看到文件变化。
第三，上下文窗口够长。 摄入一份资料时，LLM 需要同时理解源文件内容和 Wiki 的现有结构。上下文太短的话，这个任务做不好。Claude Code 在这方面目前没什么问题。
Codex 用 AGENTS.md 也能做类似的事。如果你是 OpenAI 生态的重度用户，Codex 也可以。核心逻辑是一样的。
至于 Cursor、OpenClaw 这些——它们更偏向代码编辑场景，文件操作能力有，但"以一个 Markdown 项目为工作对象持续对话"这个工作模式并不是它们的强项。也不是说不能用，就是会别扭。
动手搭建：从零到能用
接下来我把我自己搭建的过程完整走一遍。你跟着做的话，大概半小时能跑起来。
第一步：在 Obsidian 里建目录结构
打开你的 Obsidian vault（或者新建一个），创建三个顶层目录：
my-wiki/
├── raw/ # 原始资料，LLM 只读不改
├── wiki/ # LLM 生成和维护的知识页面
└── CLAUDE.md # Schema 配置文件
raw/ 是你的资料库。往里面扔文章、论文、笔记、任何你想让 LLM 处理的东西。
wiki/ 是 LLM 的地盘。你浏览，它写作。
CLAUDE.md 是规则手册。
第二步：写 Schema
这一步最关键。CLAUDE.md 的质量直接决定 Wiki 的质量。
我贴一个我实际在用的版本（做了简化），你可以在这个基础上改：
# Wiki 维护规范
## 角色
你是这个知识库的维护者。你负责 wiki/ 目录下所有内容的创建和更新。
你永远不修改 raw/ 目录下的文件。
## 页面类型
- **source-summary**：某份原始资料的摘要，放在 wiki/sources/
- **entity**：人物、公司、项目的专属页面，放在 wiki/entities/
- **concept**：技术概念或理论框架，放在 wiki/concepts/
- **analysis**：对比分析或综合判断，放在 wiki/analysis/
## 摄入流程
当用户要求摄入一份新资料时：
1. 读完整份资料
2. 在 wiki/sources/ 创建摘要页，文件名格式：YYYY-MM-DD-标题.md
3. 更新 wiki/index.md，添加新条目
4. 检查 wiki/ 中是否有相关的实体页或概念页需要更新
5. 如果发现与已有内容的矛盾，在相关页面标注
6. 在 wiki/log.md 追加一条记录
## 页面格式
每个页面开头使用 YAML frontmatter：
- tags: 页面标签
- sources: 引用的原始资料
- updated: 最后更新日期
- status: draft / reviewed
## 链接规范
使用 Obsidian 双链格式 [[页面名称]]
## 查询回答
回答问题时：
1. 先读 wiki/index.md 定位相关页面
2. 读取相关页面
3. 综合回答，附上 [[页面链接]] 引用
4. 如果回答有价值，建议是否存为新的 analysis 页面
你看，这份文件做的事情就是告诉 Claude Code：你的工作空间长什么样、该怎么建页面、该怎么命名、该怎么组织。把这些规则写清楚之后，后续的对话就会非常省心。
第三步：创建索引和日志
手动创建两个文件：
wiki/index.md：
# 知识库索引
## 资料摘要
（新摄入的资料会在这里自动添加）
## 实体
（人物、公司、项目的专属页面）
## 概念
（技术概念和理论框架）
## 分析
（对比分析和综合判断）
wiki/log.md：
# 操作日志
（所有操作记录按时间倒序排列）
这两个文件一开始是空壳子，随着你摄入资料会慢慢长出内容来。
第四步：用终端启动 Claude Code
cd 到你的 vault 根目录，启动 Claude Code：
cd /path/to/my-wiki
claude
Claude Code 会自动读取 CLAUDE.md，了解整个项目结构。
现在你可以开始第一次摄入了。
第一次摄入：感受"活的 Wiki"
假设你在 raw/ 下放了一篇关于 Transformer 架构的文章。
你在 Claude Code 里说：
请摄入 raw/transformer-explained.md
接下来你会看到 Claude Code 做这些事：
- 读
raw/transformer-explained.md的完整内容 - 在
wiki/sources/下创建一个摘要页 - 检查是否需要创建新的概念页（比如
wiki/concepts/attention-mechanism.md） - 更新
wiki/index.md - 在
wiki/log.md追加条目
你在 Obsidian 里会实时看到这些文件出现和变化。点开图谱视图，新页面之间的链接关系一目了然。
第一次看到这个过程的时候我是有点震撼的。就好像你雇了一个全职的研究助理，你把一篇论文丢给他，他不光写了读书笔记，还帮你更新了所有相关的知识卡片。
摄入第二份资料时的魔法
摄入第一份资料还看不出什么特别。有意思的是第二份、第三份、第四份。
因为从第二份开始，Claude Code 做的就不光是"写摘要"了——它还会去检查新资料跟已有内容的关系。
比如你第二份资料是一篇讲 BERT 的文章。Claude Code 会发现 BERT 也用了 Attention 机制，于是它会：
- 更新
wiki/concepts/attention-mechanism.md，补充 BERT 的用法 - 在 BERT 的摘要页里加上指向 Transformer 摘要页的链接
- 可能会创建一个对比分析页面
这就是 AK 说的"复利效应"——每一份新资料进来，不是孤立地存在，而是跟已有的知识网络产生化学反应。
日常使用：三个高频操作
搭建完之后，你的日常工作流非常简单，就三个动作。
喂资料
看到好文章？Obsidian Web Clipper 一键剪藏到 raw/ 目录。然后在 Claude Code 里说一句"摄入这篇"。
我通常一天摄入 2-3 篇。不用多，关键是持续。
问问题
有任何疑问，直接在 Claude Code 里问。它会基于 Wiki 的内容回答，带引用。
比如"Attention 机制在 BERT 和 GPT 中的使用有什么区别？"——如果 Wiki 里有相关内容，它会给你一个基于已有知识的综合回答。如果信息不够，它会告诉你还缺什么。
好的回答记得让它存回 Wiki。这一点很容易忘，但非常重要。你的每次提问都可以为 Wiki 增值。
定期巡检
大概每周做一次。你跟 Claude Code 说：
检查一下 Wiki 的健康状况
它会扫一遍所有页面，告诉你：
- 哪些页面已经过时了
- 哪些页面没有入链（可能是被遗忘的孤岛）
- 哪些概念被多次提到但还没有独立成页
- 有没有明显的矛盾
然后你决定哪些要修、哪些要补。
几个我踩过的坑
Schema 不要一开始就写太细
我第一版 CLAUDE.md 写了将近一百行，规定了各种格式、各种异常处理。结果 Claude Code 经常在遵守规则上花太多精力，反而影响了摘要质量。
后来我砍到三十行左右，只保留最核心的约定。效果好很多。
经验：Schema 应该像好的代码架构一样——简洁、清晰、只规定必要的事情。 你可以随着使用逐步迭代，但一开始宁简勿繁。
不要批量摄入
前十份资料建议一份一份来。每份都认真看看 Claude Code 生成了什么，感觉不对就纠正。这个阶段你在"训练"整个系统——你的反馈会影响后续所有摄入的质量。
我有一次贪快，一口气丢了二十篇进去让它自己处理。结果因为早期的一个分类错误，后面十几篇的分类都歪了。花了更长时间返工。
图谱视图不是装饰品
Obsidian 图谱视图是你的"知识地图"。定期看看它长什么样。
如果你看到一个明显的聚类中心（很多页面都指向它），说明这个概念在你的知识体系里很重要——可能值得让 Claude Code 写一篇专门的综述。
如果你看到一堆零散的孤岛页面，说明这些知识还没有被整合进网络——可能需要一次巡检。
Git 版本控制一定要用
你的 Wiki 就是一堆 Markdown 文件。初始化一个 Git 仓库，定期 commit。
Claude Code 偶尔会改错东西（比如把某个页面的关键结论改了）。有 Git 的话，一个 git diff 就能看到它改了什么，一个 git checkout 就能回滚。没有 Git 的话，你连它改了啥都不知道。
不同工具的适用场景
虽然我主力用 Claude Code，但不同的 LLM 工具确实各有长处。简单说说：
工具
适合场景
备注
Claude Code
重度知识库维护
长上下文 + 文件操作 + CLAUDE.md 原生支持
Codex
相同场景的 OpenAI 方案
AGENTS.md，能力类似
Cursor
偏代码项目的知识管理
文件操作能力有，但 Markdown 项目不是它的主场
ChatGPT / Claude Web
临时查询补充
没法直接操作本地文件，但可以辅助思考
我的组合是：日常维护用 Claude Code，偶尔用 ChatGPT 做一些独立的头脑风暴，好的想法再手动喂回 Wiki。
两周之后
我用这套方案跑了两周，Wiki 里积累了大约 40 份资料和 80 多个页面。感受最强烈的一点是：我的"知识焦虑"减轻了很多。
以前看到一篇好文章，心态是"赶紧收藏，以后再看"——然后就再也没看过。现在的心态是"Clip 一下丢进去让 Claude Code 处理"。我知道这篇文章的核心内容会被提取出来，跟我已有的知识产生关联。即使我自己没时间细读，知识也不会丢。
另一个变化是提问变多了。以前的自己基本不会主动去"检索"已有的知识，因为检索成本太高——翻笔记、找文件、回忆哪篇写的什么。现在的成本接近于零——问一句就行了。
我不确定这是不是 AK 设想的那种理想状态，但至少对我来说，它是目前我用过的最舒服的知识管理方案。
工具在变，模式不变
最后说一个感受。
Claude Code、Codex、OpenClaw——这些工具几个月后可能就迭代了一轮，会有更好的选择出现。但 AK 在那篇短文里描述的这个模式——原始资料、结构化 Wiki、Schema 配置、三大操作——这个模式不会过时。
它的本质是把"人擅长做的事"和"机器擅长做的事"做了一次干净的切割。你做判断、做决策、做方向选择。机器做记录、做关联、做维护。
在这个分工关系里，你不需要焦虑 LLM 会不会替代你。它就是你的笔记员、你的图书管理员、你的研究助理。你是老板。
动手试试吧。半小时搭好骨架，两周建立习惯，一个月之后你会发现自己学过的东西真的开始长在一起了。