终于抽出时间读了 Karpathy 的 LLM Wiki gist（没错，赶潮流迟到了 XD）。
说实话，整个想法归结起来很简单：「可更新的 RAG」。
1. 问题所在
LLM 处理文档时，没有任何积累。每次查询——模型检索片段、从头综合、然后遗忘。知识从未编译。而且在我看来，更关键的是：对话本身几乎没提取出什么有用信息。
RAG 能部分解决（广义上，一个 .md 文件文件夹也算是 RAG），但标准流程（每个人都在用的）没有内置的更新、蒸馏或自清理机制。知识一旦被索引，就闲置在那里。这个缺口正是 LLM Wiki 要填补的。
Karpathy 的逆向思维：在原始资料和你之间，放一个 Agent 逐步撰写和维护的 Markdown 维基。一次性编译，持续更新。
2. 架构：3 层
- raw/ - 来源，不可变。Agent 不会在这里写入。
- wiki/ - 系统的核心；LLM 自行撰写并交叉链接的 Markdown 页面（实体、概念）。本质上是图状知识。
- CLAUDE.md - 仅作为 LLM Wiki 的操作手册。包含：页面格式、链接约定、导入流程、lint 规则。正是这个东西把 Claude 从聊天机器人变成有纪律的维基维护者。
足以支撑数百个页面，无需额外微调：
3. 操作
三种操作——你马上就想把它们画成 API 函数：
- Ingest -> add(source: file | list[file])。放入来源 -> Agent 读取 -> 与你讨论 -> 撰写摘要 -> 更新索引 -> 编辑相关实体页面 -> 追加到日志。一个来源会接触 10-15 个页面。
- Query -> search(prompt: str)。最重要的操作。回答你的问题 + （关键部分）自动将综合结果作为新页面归档回维基。探索会积累，而不是死在聊天历史里。底层其实就是 add(source=dialogue)。
- Lint -> lint()。无参数。定期遍历维基：矛盾、孤立页面、过期事实、缺失交叉引用。触发条件：每 N 条用户消息，或变更行数计数器。容易挂到 /schedule 上。
强烈让我想起 Claude Dreaming——我觉得 Dreaming 部分受这个模式启发（虽然它的功能集略有不同）。
4. 索引
两个特殊文件让维基可导航：
- index.md - 当前状态。每个页面的目录，附一行描述。Agent 在任何查询时先读它——这是「这个维基里到底有什么」的最小上下文。
- log.md - 所有事件的日志，自由格式。追加式时间线。如果行遵循一致格式（例如
## [YYYY-MM-DD] ingest | title），就可以用纯 Unix 工具轻松 grep 日志——方便审计。
index.md 还可以进一步扩展（向量索引、BM25、GraphDB……）——我将在另一篇文章中介绍。
5. 要点
我的总结是这样的：这不是 RAG 和 LLM Wiki 之间的选择——它们是同一个「累积记忆」轴上的两个点。
RAG 不一定非得是向量数据库——一个 Markdown 文件文件夹也是 RAG。
所以你可以把 LLM Wiki 重新定义为 RAG 加上三样东西：
- 一个摘要层。
- （几乎）自由地在该摘要层上编写结构。
- 定期的结构审计 + 自我改进（CRON）。
