你有没有发现：把 PDF 丢进对话框、每次问答临时捞几段——听起来很省事，但一年以后，你的「知识」往往还停留在 聊天记录和向量索引 里：能答，却难长成一棵越用越壮的知识树。Andrej Karpathy 在 gist LLM Wiki 里换了一个主语：让模型像维护代码一样维护维基——持续把 raw 编译成可互链、可修订、可标矛盾的 Markdown，让知识成为 「persistent, compounding artifact」（持久、持续复利的产物），而不是每次从零检索。
我按同一条「编译—沉淀—体检—回流」的思路 复现并开源 CRATE（Python CLI、vault 契约、兼容 OpenAI 多平台），并配上 Agent Skill（crate-vault） 与 Obsidian 插件说明。下文顺序是：先读总览图（知识树 + 三层 + RAG 对照） → 再看主流程图（三层 + 运营闭环 + index/log） → 展开 gist 在说什么 → CRATE 做什么、怎么用 → Skill 与 Obsidian 各管哪一段（含「是不是官方 Obsidian 插件」的边界）。
一、先看总览：「知识树」、三层与「传统 RAG vs LLM Wiki」
LLM Wiki是如何实现AI知识管理新模式的？我用NotebookLM画了张图，如下，把同一套 idea 收成一棵树：底下是 原始资料，中间是 模型写出来的维基，顶层是 Schema（规则与流程） 当「方向盘」。我读它的方式很简单：复利不是多存了几份 embedding，而是每一次进料、每一次好问答，都会回头改写整片笔记网络——这和「只检索、不维护」是两种世界观。
gist的三层与图内容对齐：
| 层级 | 在图里像什么 | 在 gist / 工程里是什么 |
|---|---|---|
| 原始资料层（Raw） | 树根下的书与 PDF | 剪藏、论文、网页快照等 尽量不可变的一手来源；真理感以这里为锚。 |
| 维基层（Wiki） | 树干与分枝上的 .md | 模型生成并维护的 实体页、概念摘要、互链；人 读，模型 写。 |
| 模式架构层（Schema） | 齿轮/控制台 | 目录、命名、ingest/query/lint 的 契约（常与 AGENTS.md / CLAUDE.md 共演进）。 |
下面这张把 Raw 只读 / Schema 控场 / Wiki 由模型写 的分工画成「三层栈」，与上表同构，可作 手机横滑阅读 时的对照图。
三件循环动作：
- Ingest（增量摄取） ：新资料进来，不是「只塞进索引」，而是 牵动多篇相关笔记一起改——常见产品叙事会写成「一次进料联动约十来个页面并记变更日志」；具体页数取决于实现，要点是 多页联动 + 可追溯，不是单条切片。
- Query（闭环查询） ：高质量问答 别只停在聊天窗；gist 主张 回灌成新页，形成 闭环沉淀，否则知识库厚度追不上你的提问速度。
- Lint（智能巡检） ：周期性扫 矛盾、断链、过时论断、缺口——wiki 才不会长成「看起来很真的幻觉集合」。
一句话对照：传统 RAG vs LLM Wiki：
| 维度 | 传统 RAG 系统（常见体感） | LLM Wiki 模式（gist 主张） |
|---|---|---|
| 知识怎么处理 | 临时捞片段；每次提问像 重新发现 该读哪几段。 | 更像 一次性编译 + 跨文档深综合：交叉引用与矛盾标注 会累积。 |
| 维护成本 | 表面「零维护」，代价常常是 信息堆肥、难复核。 | 维护交给 自动补全与巡检（仍要人做主编——见后文边界）。 |
| 长什么样 | 藏在 向量库/索引 里的黑箱。 | 人类可读、可版本控制 的 Markdown 仓库（git diff 友好）。 |
同一组对比也可以用 「无状态碎片 → 有状态维基」 的示意图扫一眼（与上表互补，不必重复细读）。
二、主流程图：三层架构 + 运营闭环（index / log）
下面这张是 总览流程图（标题 The LLM Wiki: Building a Compounding Knowledge Base）：左侧 Raw Sources（immutable）/ The Wiki（LLM-owned Markdown 互链）/ The Schema（config） ，中间是 知识网络，右侧 Operational Loop 串起 Incremental Ingestion（新源联动多篇既有页）、Compounding Queries（复杂问答回灌为永久页）、Automated Linting（矛盾、过时、断链）；图中还有 index.md（内容型目录）与 log.md（审计时间线） 与 gist 一致。与第一节中文信息图 叠着看：第一节偏「对照与扫读」，本节偏 gist 标准骨架 + 闭环。
若你更习惯 中文工程视角（数据源 → LLM Engine → Markdown Wiki 网络 → 检索与界面），可以看下面这张 「Karpathy LLM 知识库流水线」 总览；与上图 同一套理念，画法偏 落地架构。
知识的动态生命周期（吸收 → 查询回灌 → 审查）也可收成 一环三节点，与 gist 的 Ingest / Query / Lint 一一对应：
读图要点：
- Raw：剪藏、PDF、随手 md——尽量当一手来源、少被模型改写的输入层；gist 强调 raw immutable，模型 只读。
- Vault：单一根目录里同时放 raw 与编译结果，便于 git diff、版本回溯；CRATE 把这一层叫 vault，Obsidian 也是 打开同一文件夹当库。
- Wiki 编译：不是「切片进向量库就完事」，而是 增量写出 摘要、实体/概念页、互链、目录；新来源进来要 更新旧页、标矛盾——这才是「复利」。
- Query / 工具环：gist 说问答时 先 index 再钻页；好答案应 回灌成新页（否则全进聊天历史，知识库不增厚）。
- Lint / 健康检查：矛盾、断链、过时论断、缺口——周期性跑，wiki 才不会长成「看起来很真的幻觉集合」。
可选细读：三件事的中文「信息流」
下列三图把 Ingest / Query / Lint 再拆成可执行的步骤或检查项；与 CRATE 的具体子命令 不必逐箭头对齐，当作 心智模型 即可。
Ingest：从「用户放入新文献」到 多节点更新、再 同步 index.md / log.md 的一条横轴。
Query：先 查目录、再 综合回答；关键是 文件反向归档——高价值解答要落成独立 Markdown 页，否则「复利」缺一半。
Lint：在图网络上跑 扫描束，标 孤儿页、过时断言、缺互链 等；落地时可 先建议、再按 Schema 权限 Auto-fix。
三、gist 在反对什么、主张什么（idea 展开）
第一节用 信息图 + 中文对照表 把「知识树 / 三层 / RAG vs Wiki」说了一遍；这里我按 gist 原文 再落一遍术语，方便你对照英文段落与链接。
反对的默认形态：NotebookLM、文件上传、典型 RAG——每次提问重新发现该读哪几段，交叉引用与矛盾标注不会自动累积。
主张的核心：在中间插一层 由模型维护的维基——结构化、互联、可持续修订。新源进来时：读入 → 抽要点 → 更新实体/综述 → 记下与旧说的冲突。知识像被编译进 repo，而不是每次问答现场拼装。
三层架构（gist · Architecture）：
| 层级 | 角色 |
|---|---|
| Raw sources | 你策展的来源；不可变；真理感以这里为锚。 |
| The wiki | 模型生成并维护的 .md 树；你 读，模型 写。 |
| The schema | 目录、命名、ingest/query/lint 的契约（常与 AGENTS.md / CLAUDE.md 共演进）。 |
三件事：Ingest（进料并波及多页）、Query（先目录后正文；有价值的问答结果应归档进 wiki）、Lint（健康度与缺口）。
两个导航文件：index.md （内容型目录）、 log.md（append-only 时间线）——gist 认为在中等规模下 index-first 往往够用，不必一上来就上全套向量工程。
极简导航在图里常被画成：Index = 空间映射（按实体 / 概念 / 数据源分类的全局地图） ，Log = 时间轴审计（append-only、可 grep） ——与「重向量、轻文本」的路线形成对照。
分工画面（gist 原话意境）：一边开 Agent，一边开 Obsidian——Obsidian 像 IDE，LLM 像程序员，维基像 codebase。
四、为什么我做了 CRATE：把「编译器」落成可跑的命令行
gist 故意抽象，不写死你的目录结构。我的工程诉求是：本地优先、文件可 diff、增量可重复、能进脚本、能给 Agent 当工具调——于是有了 CRATE（Compile Raw Archives, Tracked in the vault, into Encyclopedic wiki）。
**
**释义：CRATE = 把散落在各处的 raw，以 vault 为单一事实来源，增量编译成可互链的 wiki（百科全书式知识库）。
上游把设计动机写得很直白：file-first personal knowledge compiler；灵感来自 把 LLM 当编译器、Karpathy LLM Wiki gist；与 gist 流程的 逐条对照 见 docs/usage.md §7.5，架构与目录见 technical-design.md。
4.1 设计取向（Why）
- Local-first：Markdown 树，而不是黑盒 SaaS 资料库。
- Incremental：raw 变了就 短周期再编译，不必每次全量重跑（也支持
--full全量）。 - Inspectable：wiki 页、幻灯/图表等产出可 像代码一样审。
- Agent-ready：问答层尽量读 相关页，而不是把整库塞进上下文。
4.2 能力边界（What's in scope）
| 阶段 | 意图 |
|---|---|
| Raw ingest | 剪藏、仓库快照、PDF、图片等进入流水线的入口。 |
| Vault | 版本化、可观察：raw 与编译产物同仓，可追溯。 |
| Wiki compile | 由 LLM 结构化：摘要、概念、回链、目录树。 |
| Outputs | Markdown、可选 Marp 等——你定义的「发布物」。 |
| Health / lint | 一致性、缺口、新术语、可选全库体检。 |
| Enrich loop | 把产出或 lint 结果 喂回 下一轮编译。 |
非目标（上游写明） ：不做全能 PKM（日历/任务/间隔重复等）；不做 多租户云端——你的 vault、你的工具链。
4.3 CLI 功能分层（M0 / M1 / M2 / M3，便于按需记忆）
以下与上游 README · CLI 对齐；密钥与多厂商 见 docs/providers.md（CRATE_LLM_PROVIDER 等）。
M0 — 库契约与编译、体检、图与报告
crate init：在 vault 根生成raw/、wiki/、meta/等树。crate compile：raw/**/*.md、**/*.pdf→ wiki；默认增量；--full全量重编。crate ingest：按会话清单对 显式 raw 子集 编译（绕过增量跳过）。crate watch：监听raw/，安静一段时间后 自动 compile（可选watchdog、--native）。crate lint：检查 wiki；可选--json、--wikilinks、--raw、外部 URL 可达性等。crate serve-search：本地 HTTP/search?q=…（crate index后可&semantic=1）。crate wiki graph：生成meta/wiki_body_graph.json等。crate report raw-wiki、crate wiki index-extend：覆盖率与扩展索引。
M1 — 问答与回流
crate ask：工具环（读 vault、搜索、可选语义搜索、写输出）；默认把答案写入wiki/outputs/，并可将一行摘要 追加到wiki/_index/RECENT.md（--no-feedback可关）。- 与
compile/ask共用 同一套 OpenAI 兼容聊天配置。
M2 — 检索、统计、语义索引
crate search、crate stats、crate doctor。crate index：语义索引（需嵌入 API / 环境变量，见 providers）。- 大规模时 stderr 可出现 scale-gate 提示（除非
--quiet-gate）。
M3 — 临时会话 wiki
crate ephemeral init→crate ask --session …→finalize/clean。
更细的子命令与参数以上游 README / usage.md 为准。
五、Skill：crate-vault 解决「Agent 每次从零猜习惯」
gist 强调 schema 与流程；在 Cursor / Claude Code 等环境里，最省心的做法是把约定 固化成 Skill。
- Skill 正文：agent-skills/crate-vault/SKILL.md
- 安装与路径：docs/agent-skill.md
我怎么用：让 Agent 先读 vault 契约、再动 raw//wiki/，减少「随手写飞目录结构」；和终端里的 crate …同一套语义，适合 人机并排：终端跑编译，编辑器里改 raw、审 wiki。
六、Obsidian：不是「CRATE 官方插件」，而是「同一库、两套 UI」
这里先把预期说清：CRATE 没有捆绑一款必须在 Obsidian 里安装的「官方 CRATE 插件」；官方文档描述的是 Obsidian 与 vault 根目录对齐 的协作方式——Obsidian 负责浏览、双链、图谱；CRATE 负责在终端里 compile / ask / index。
- 必读：docs/obsidian.md
关系一句话：
| 工具 | 做什么 |
|---|---|
| Obsidian | 打开 vault 根，读 wiki/、写 raw/ 或随手记；图谱与 [[wikilink]]。 |
| CRATE | 在同一文件夹执行 compile / ask / search / index；产出落在 wiki/、meta/。 |
推荐日常流（压缩版） ：材料进 raw/ → 终端 crate compile → 在 Obsidian 看 wiki/notes/ → crate ask "…" → 打开 wiki/outputs/ → 可选 crate index 后做语义检索。可固定收藏 wiki/_index/TOPICS.md 、 RECENT.md 、 LOG.md 等入口（详见上游 obsidian.md）。
可选社区插件：上游举例 Dataview——对带 front matter 的概念页做表格查询；[[双链]] 与 CRATE lint 检查的 Markdown 相对路径 可能不一致，需要「可脚本校验的链接」时，关键导航页可 兼用相对路径（obsidian.md 第 5 节有说明）。
下图仍是 compile 产出在 Obsidian 里长什么样 的示例（kind: compile_run、sources、Synthesis），便于把抽象流水线 落到一页笔记上。
七、最小可跑路径（复制即用）
git clone https://github.com/GuiminChen/crate.git
cd crate
python3 -m venv .venv && source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -e ".[dev]"
在 你的知识库根目录（或与 Obsidian 库根一致）：
crate init [--vault PATH]
crate compile [--vault PATH]
crate ask [--vault PATH] "你的问题……"
crate lint [--vault PATH]
需要语义搜索时：配置嵌入相关环境变量后 crate index，再 crate search --semantic "…"。Conda、Dev Container、doctor 自检 等见上游 README。
八、边界（高 stakes 必读）
- 维基是二手综述：重要结论应能 回链 raw；人要做 主编，不是盲信编译输出。
- 规模变大：index-first 仍可能不够，需 search / semantic index——gist 与 CRATE 都留了这一刀。
- 版本：CLI 与文档以 GuiminChen/crate 默认分支为准。
参考链接
- Karpathy · LLM Wiki（gist）：gist.github.com/karpathy/44…
- CRATE：github.com/GuiminChen/…
- Karpathy-X：x.com/karpathy/st…
