引言：为什么要动手实践

上周，我在 GitHub 上读到了 Karpathy 写的一篇 gist：原文在这。

他讨论了一个方向：在原始文档和用户之间，加入一个由 LLM 自动维护的 Wiki 中间层。

读完后我做了个决定——在自己的开发工作里把这个方案落地。今天这篇，就是我从零搭建到日常使用的完整记录。

为什么是 Wiki，而不是 RAG？

Karpathy 在原文里把 RAG 和 Wiki 两种方式做了个对比，我觉得讲得非常清楚：

RAG 是每次查询都去原始文档里找片段、拼答案。查完就走，不留下任何东西。新文档来了，加个索引就好，之前查过什么它不关心。本质上，RAG 是一次性检索的产物。

Wiki 则是让知识持续存在。新内容进来后，会反过来更新已有的页面。知识不是被"查"出来的，是自己在生长的。

这个区别很关键。用 RAG 的时候，每次提问都是一次独立的消耗。而用 Wiki，知识是累积的——每次新增的内容都在给整个知识库添砖加瓦，越久越厚。

Karpathy 管这个叫三层架构：

• 原始源：只读层，所有文档丢进去，LLM 只负责读。
• Wiki 层：LLM 自己读写的知识页面。
• Schema：告诉 LLM 这个 Wiki 该怎么管的规则。

还有个操作叫 Lint——定期检查 Wiki 有没有矛盾、有没有过时的页面、有没有互相链不上的孤立页。LLM 做这件事特别合适：它一次能改十几个文件，不会忘记更新链接，也不会觉得维护麻烦。

读完之后我就在想，这套思路能不能和我自己的笔记工具 Obsidian 结合起来。

Obsidian 的问题我一直都清楚：得自己手动整理、手动建链接。但 Karpathy 的方案恰好补上了这个缺口——Obsidian 负责呈现和浏览，LLM 负责生成和维护。两个工具不是替代关系，是互补。

目录结构

动手之前，我先定好了目录结构。这一步不复杂，但很关键——结构清晰了，后面的工作流才好写。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

my-wiki/
├── 0_原始文档/              ← 扔进去的资料，只读，不碰
├── 1_会话碎片/              ← 从会话中提取的原始记录，按日期分子目录
│   └── 2026-04-19/
│       └── ses_xxx_主题.md
├── 2_知识图谱/              ← 提炼后的持久知识，按分类分子目录
│   ├── 01_知识管理/
│   │   └── 0001_LLM-Wiki知识库架构.md
│   ├── 02_工作流/
│   │   └── 0010_项目计划审查流程.md
│   ├── 03_架构与开发/
│   │   └── 0022_依赖注入规范与常见问题.md
│   └── 04_运维与环境/
│       └── 0041_博客SFTP部署方案.md
├── index.md                  ← 入口索引，按分类列出所有页面
├── log.md                    ← 每次工作流的记录，只增不改
└── AGENTS.md               ← 规则文件，人和 LLM 一起演进

每个目录的职责很清晰：

0_原始文档 是只读层。不管是项目文档、技术文章还是参考资料，丢进去之后 LLM 只负责读，不修改。这保证了原始资料的完整性，也避免了 LLM 在"帮你还是不帮你"之间的模糊地带——它只负责读，不负责优化你的原始文档。

1_会话碎片 是原始记录的归档。每次和 LLM 的会话中，只要有值得保留的技术讨论、踩坑经验、架构决策，就提取出来存一份。按日期分子目录，避免一个目录下堆太多文件。命名规则是 session_id + 会话主题，方便以后按会话 ID 追溯。

2_知识图谱 是核心层。碎片是原始记录，知识图谱是提炼后的持久知识。每个页面有编号、有摘要、有详细内容、有 Wikilink 互相链接。按主题分四个分类子目录——01_知识管理（Wiki 架构、系统配置）、02_工作流（计划审查、执行框架）、03_架构与开发（微服务、开发规范、工具链）、04_运维与环境（部署、环境配置）。Wikilink 引用时必须带完整路径，比如 [[2_知识图谱/03_架构与开发/0022_依赖注入规范与常见问题]]。

index.md 是入口。不用向量检索，就一个 Markdown 表格，按分类列出所有知识页面，每个页面一句话摘要和标签。查东西的时候先扫一眼索引，再点到具体页面。中等规模（几十到几百页）效果非常好。

log.md 是只增不改的操作日志。每次工作流跑完都记一条：影响了哪些页面、新增了什么、有什么发现。

AGENTS.md 是规则。告诉 LLM My-Wiki 怎么运作、文件格式要求、增量更新策略。这个文件不是定好就不变的——实践中发现规则不够用的地方我就改它，改完在 log 里记一笔。

三个工作流

目录结构定好之后，我写了三个 Skill 来完成完整的工作流闭环。

my-wiki-src（摄入原始文档）：从 0_原始文档/ 里读取用户丢进去的资料，提炼知识到 2_知识图谱/。一篇文档读进去，可能会影响十多个已有的知识页面——更新、补充、建立新的维基链接。

my-wiki-talk（从会话里提取知识）：这是我最常用的。用 OpenCode 的 session API 读取历史会话，将有价值的对话内容提炼为知识碎片，整合到知识库里。具体流程是：读取会话 → 生成碎片文件 → 提炼知识页面 → 建立 Wikilink 双向链接 → 更新索引 → 追加日志。

my-wiki-think（自检）：定期跑。扫描所有知识页面，查找矛盾说法、孤立页面、遗漏的链接、修复未按照 AGENTS.md 标准执行的内容。还会发现那些"被多次提到但没独立成页"的概念，建议创建新页面。

这三个工作流对应了 Karpathy 说的三个核心操作：Ingest（摄入）、Query（查询，这里用 talk 替代了）、Lint（体检）。

第一次运行

Skill 写完后，首次触发了 /my-wiki-talk。它把我从今年 1 月到 4 月的历史会话全扫了一遍。

读取 15 个会话，生成 15 个碎片文件，提炼出 8 个初始知识页面。

这 8 个页面覆盖了当时的核心话题：LLM-Wiki 架构本身、系统配置规范、企业级知识库构建经验、计划审查流程、E2E 测试概念、思考语言配置、运维工具选型。

后面又陆续跑了几次，从不同专题的会话里继续提取。不同项目的迁移策略、服务搬迁的踩坑经验、CI/CD 构建问题修复、依赖注入的类型匹配规则、微服务的分层架构设计——全都有条不紊地沉淀到了知识图谱里。

每次跑完我都会检查输出。碎片文件的 YAML 头部信息对不对、知识页面的摘要是否准确、Wikilink 有没有指向不存在的页面——这些都是要确认的。不是完全放养，还是得有人看一眼。

知识页面从最初的 8 个涨到了 43 个。

实践方法论

整个实践走通一遍之后，我总结出了几条方法论。不是什么新理论，就是我自己踩过坑之后觉得值得记住的东西。

知识不是采集出来的，是累积出来的

这一点是最本质的转变。以前我的习惯是碰到问题搜资料、解决了就忘。下次遇到同样的问题，又从头搜一遍。

现在不一样了。每个踩坑经验一旦确认有复用价值，就提炼成知识页面存下来。关键是不怕重复——同一个概念可能在不同的项目会话里出现多次，每次出现都是新的角度、新的上下文。会话碎片保留原始记录，知识图谱提炼共性。

比如某个技术点的处理，在好几个项目的会话里都出现过。第一次记录的是基础配置规则，第二次是某种特殊场景下的坑，第三次是类型不匹配的错误修复。这三条碎片分别归档，知识图谱里则整合成一篇完整的使用规范，标注来源。下次再遇到类似的问题，不用翻几百条会话记录，直接查对应的页面就行了。

分层隔离，减少连锁反应

0_原始文档 不碰，1_会话碎片 按日期归档不变，2_知识图谱 可以随意增改。这个分层在实践中非常有用：

• 原始文档是只读层。不管丢进去什么资料，LLM 只读不改。保证原始资料完整性。
• 会话碎片是归档层。按日期分子目录，每个文件用 session_id 加主题命名。session_id 唯一不会冲突，日级目录避免一个目录堆几百个文件。这些碎片文件就像 git 的 commit log，是原始记录，不轻易改动。
• 知识图谱是可读写层。LLM 可以增删改查。批量更新某个概念的描述，只需要改知识图谱里的页面，不需要翻碎片文件。
• **规则文件（AGENTS.md）**独立维护。实践中发现流程缺了一步或格式约定不够清晰，直接改 AGENTS.md。规则变了，下次跑工作流 LLM 就按新规则来。改完在 log.md 里记一笔，可以追溯。

自检是必选项，不是可选项

一开始我以为知识图谱建好了就能一直用下去，不需要维护。事实完全不是这样。

知识页面越长越多，链接关系会越来越复杂。有些页面可能只在索引里出现过，但从来没有被其他知识页面引用到——这就是孤立页面。有些概念可能在好几个页面里被反复提到，但一直没人给它独立建页。有些 Wikilink 指向的文件名变了，链接就断了。

所以我每次批量添加新知识后，都会跑一次 /my-wiki-think。它扫一遍所有页面，告诉我哪些地方有问题。确认之后，我决定怎么处理——合并重复内容、补建遗漏页面、修复断链。

这有点像代码审查。你写代码的时候觉得没问题，跑了一遍 linter 之后才发现变量名拼错了、某个 import 没用到、两个函数的逻辑互相覆盖。知识图谱也一样，不检查的话问题会一直累积。

人的角色是架构师，不是编辑

它执行，我决定。

LLM 能做的事：读取、生成、链接、修复、编号、更新索引。

LLM 不能做的事：判断哪些知识值得沉淀、哪些重复内容该合并、哪些新概念该独立成页、遇到冲突时该保哪个。

这一点和 Karpathy 说的分工完全一致。人在整个系统里的角色不是变轻了，而是从"写文档的人"变成了"管文档的人"——筛选来源、引导分析、提出好问题、思考这些知识意味着什么。剩下那些机械的活，交给 LLM 去干。

Obsidian 的定位

My-Wiki 建好之后，Obsidian 的角色变成了浏览和编辑界面。

知识图谱里的页面是纯 Markdown 文件，Obsidian 可以直接打开。Wikilink 用的是 [[页面标题]] 格式，Obsidian 能正常识别和跳转。打开 Obsidian 的图谱视图，能看到所有知识页面之间的链接关系——哪个页面是核心、哪些边缘，一目了然。

Obsidian 负责呈现、搜索、手动编辑，LLM 负责生成和维护。

数据同步

知识图谱全部是纯 Markdown 文件，天然适合版本管理和同步。我用 ZeroTier 组网，通过 Syncthing 在不同设备之间实时同步整个 my-wiki 目录。不管是在公司电脑、家里的 Mac，还是笔记本上，都能读到最新的知识页面，不用担心数据只存在某一台机器上。

现在的状态

打开 Obsidian 的图谱视图，整个 my-wiki 目录的关系网一目了然。知识图谱按模块分组编号：知识库与系统、计划和工作流、微服务和架构、开发和工具链、运维和环境。每个页面都有摘要、有标签、有来源追溯。

哪个页面引用了哪个、哪个概念被哪些项目用到、从哪个会话碎片提炼的——通过图谱视图的节点连线，全部可视化呈现。知识不是散落在各处的碎片，而是有结构、有关联、会生长的有机体。