Karpathy 的 LLM 知识库想法，我自己搭了一遍

读了 Karpathy 一篇 gist 之后，我想在自己身上试一把：让 LLM 帮我维护一个 Obsidian Wiki。

这篇文章介绍我的思路和流程，细节也会点到。每个人的工作流不一样，这篇不保证你能直接照抄，但希望能给你一些参考，少走一点弯路。

下面是我怎么想的、怎么做的。

obsidian图谱

目录怎么定

my-wiki/
├── 0_原始文档/         ← 只读
├── 1_会话碎片/         ← 历史会话归档
├── 2_知识图谱/         ← 提炼后的持久知识（按主题分 4 个子目录）
├── index.md            ← 入口索引
├── log.md              ← 只追加的操作日志
└── AGENTS.md           ← 规则文件

分三层是我踩过一次坑之后定的。

早期我试过只有「原始文档 → 知识」的两层结构，结果知识页的"原始素材"丢了——某条知识我想追回去看它来自哪次会话，翻不到。加了 1_会话碎片 这一层之后，碎片保留原始上下文（包括问题冒出来的来龙去脉、讨论的来回、否决掉的方案），知识图谱只存提炼后的结论。

这样设计的好处是：知识页可以随便合并、重写，不怕丢背景；背景在碎片里不会散。另外 LLM 只碰 1 和 2，0_原始文档 永远只读，保证原始资料不被"优化"掉。

知识页面按分类 + 4 位编号命名，比如 0022_Wire依赖注入规范与常见问题.md。编号按分类占一段区间，方便定位。

三层架构示意图

三个 Skill

目录定下来，我让AI帮我写了三个 Skill 完成完整流程。

my-wiki-src：吃外面扔进来的资料

给定一个路径（文件或者目录），把它读进去，提炼出知识写进图谱。新知识按分类归进去，已有页面就合并补充、标注来源。每个知识页用 wikilink 连回原始文档，保证可追溯。

跑完之后自动梳理 wikilink 关系、增量更新索引和日志。已处理过的文件靠状态标记跳过，只处理增量。

my-wiki-talk：从历史会话里挖

这个我自己用得最多，几乎每次大工作量之后都跑。

做法是：拿 OpenCode 的会话历史，按 session_id 去重，每个会话生成一个碎片文件，放到 1_会话碎片/{日期}/ 下。然后从这些碎片里提炼知识——新知识点建页面，已有知识点合并到旧页面，标注来源。

一个关键约束：每个知识页的 来源 字段必须指向对应的碎片文件，这样任何一条知识都能追溯到「哪次会话、什么场景」。

流程最后会自动补 wikilink、更新索引、追加日志。我后来加了一步让 LLM 跑完再自检一遍文件真的生成了——一开始没这步，出问题才发现。

my-wiki-think：跑体检

每次 talk 跑完我都会跟一次 think。

它扫图谱找矛盾，找那些只在 index.md 里被提过、没被别处链接的页面，找被反复提到但还没独立成页的概念。发现新关联就建新页。

这一步我故意不写死算法——矛盾长什么样、什么概念值得独立成页，交给 LLM 根据当前图谱自己判断。手动触发，频率我自己控制。

三个skill工作流程

踩过的坑

1. 同时跑多个 Skill，文件互相踩

并行跑 my-wiki-src 、 my-wiki-talk 、 my-wiki-think，三个 Skill 同时改 index.md 和 log.md，写入冲突，数据全乱。

AGENTS.md 加约束：三个 Skill 必须串行，一个跑完再跑下一个。

2. 知识页没写 来源 字段，无法追溯

跑一段时间后想查某条知识怎么来的，翻不到原始会话。

改 AGENTS.md：每个知识页必须写 来源，且指向 1_会话碎片/ 的具体文件。

3. LLM 自己改文件名，链接全断

LLM 觉得标题不够准，自己改了名，index.md + 所有引用全成死链。

改 AGENTS.md：不允许改已有文件名。要合并/改名就走「新建 + 旧页清空并链向新页」的路径。

4. 一次扫太多历史，提炼质量掉

第 3 个月历史会话上百，LLM 一次全读，开始漏细节、概念乱合并。

改成增量模式，只扫上次之后新增的会话。

5. 改了规则，旧页面全标「不符合规范」

规则一改，前面已经写好的页面全被 think 标出问题。不过在 think 时，一般大模型会询问你，请你澄清，规则矛盾的时候，选择谁，忽略谁。

规则改了之后，要么批量补全旧页面，要么写「新规则只对新增页面生效」，二选一。

AGENTS.md 是系统的底座

现在的核心约束：

0_原始文档/ 只读，LLM 不碰
wikilink 必须带完整路径
每个知识页必须有 来源 字段
不允许改已有文件名
index.md 只增量，log.md 只追加
不删旧内容，只合并并标注新来源

这个文件不是一开始就写对的——每踩一次坑就加一条。它是系统真正的契约。

工具链

整套系统用的都是本地工具：

Obsidian 是界面。浏览、搜索、手动编辑知识页都在这，图谱视图一眼能看出哪些页面是核心、哪些是孤立点。
OpenCode 是 Skill 的执行环境，同时也提供会话历史的 API，是 my-wiki-talk 的数据来源。
ZeroTier + Syncthing 负责多设备同步，公司电脑、家里 Mac、笔记本上都能读到最新的知识页面。你可以查看这篇文章来搭建【自建 Syncthing 多设备同步：完整搭建指南】

成本只有大模型的token。

如果想复刻，建议这个顺序

描述你的思路，让AI帮你编写，你做审核

先建目录和编号规则，别急着写 Skill。把 my-wiki/ 的三层结构和分类编号定下来，手动建几个知识页面，熟悉一下 wikilink 怎么走。
写 AGENTS.md。命名规范、wikilink 格式、来源字段要求，这些都可以让 LLM 帮你写。这份文件是整个系统的契约。
写 my-wiki-talk。三个 Skill 里这个用得最多，也是最容易验证效果的。跑一次 /my-wiki-talk，看它能不能正确生成碎片和知识页。
跑一次 my-wiki-think。把第一次生成的页面过一遍，修掉孤立页、断链、缺字段。
最后写 my-wiki-src。等你已经习惯了 talk + think 的节奏，再加 src 来处理外部文档。