LLM Wiki

LLM Wiki

Karpathy 提出的个人知识库模式：让 LLM 不是每次查询时重新从原始材料里 RAG 拼答案，而是持续维护一个持久、互链、可版本化的 Markdown wiki。人在前端负责选题、选源和判断，LLM 在后端负责摘要、归档、交叉链接、冲突标注和索引维护。

核心思想

传统 RAG/文件上传的工作方式是“查询时再发现”：模型在每次问题里检索 chunk，再临时拼接答案。它能回答问题，但不会自动把上一次综合出的结构沉淀下来；需要跨 5 份材料的微妙问题，下次还要重新找、重新拼。

LLM Wiki 的工作方式是“摄入时编译”：每加入一个来源，LLM 先读原始材料，再把关键事实、概念、实体和矛盾整合进已有 wiki。这样知识不是停留在 raw documents 里，而是被编译成一个随时间增长的中间层：交叉引用已经建好，矛盾已经标出来，综合页已经反映最新材料。

三层架构

1. Raw sources：文章、论文、图片、数据文件等原始材料。它们是 source of truth，原则上只读不改。
2. The wiki：LLM 生成和维护的 Markdown 页面，包括来源摘要、实体页、概念页、比较页和综合页。用户主要阅读这一层，LLM 负责更新。
3. The schema：告诉 agent 如何维护 wiki 的规则文件，例如目录结构、frontmatter、标签、摄入/查询/lint 工作流。对 Claude Code 可以是 CLAUDE.md，对 Codex/Hermes 可以是 AGENTS.md 或 skill。

三个基本操作

为什么它比普通 RAG 更适合长期学习

LLM Wiki 的关键价值不是“搜索更准”，而是知识会复利：每次摄入、每次高价值提问都会改变知识库本身。下一次回答时，agent 不是从一堆 chunk 里临时恢复上下文，而是站在已经维护过的结构上继续思考。

这也解释了为什么它天然适合 Knowledge-as-Code：wiki 是一组可 diff、可回滚、可审计的 Markdown 文件；agent 像程序员维护代码库一样维护知识库；Obsidian/VS Code 是 IDE，wiki 是 codebase，LLM 是主要维护者。

对 Hermes / 本知识库的启发

• skill 就是 schema 的一部分：llm-wiki skill 承担了 Karpathy 文中 schema 的角色，把“如何摄入、查询、lint”固化成可复用流程。
• index + log 是导航骨架：_index.md 提供当前结构，log.md 提供时间线；每次入库前先读这两者，能避免重复建页。
• query 也应该回写：如果一次问答形成了新的比较、判断或框架，就不应只留在聊天记录里，而应沉淀到 queries/、comparisons/ 或相关概念页。
• lint 是增长后的必要维护：随着页面变多，断链、孤儿页、重复概念、低置信度内容会自然出现；定期 lint 是让 wiki 不退化成“漂亮的文件堆”的关键。

适用场景

Karpathy 列举的典型场景包括：个人目标/健康/心理记录，长期研究主题，逐章读书，团队内部知识库，竞品分析、尽调、旅行规划、课程笔记和兴趣深潜。共同点是：材料会持续累积，而且你希望它们被组织、链接、复用，而不是散落在聊天记录或临时 RAG 索引里。

与相关概念的关系

• Knowledge-as-Code：LLM Wiki 是个人/研究场景里的 Knowledge-as-Code 实践；企业场景可以扩展为团队级知识工程。
• Context-Engineering：wiki 为 agent 提供稳定、可检索、可维护的长期上下文，减少每次任务重新解释背景。
• Agentic-Engineering：人在 loop 中负责方向、验收和源头质量；agent 负责高频维护动作。
• Karpathy：该模式来自 Karpathy 2026 年 gist，和他近期对 agentic engineering、nanochat、autoresearch 的关注一致：把 LLM 用作可持续工作的工程组件，而不是一次性聊天界面。

写入记录

• 2026-07-01 09:13 CST：根据 Karpathy 原始 gist 重写 LLM Wiki 概念页，补充三层架构、Ingest/Query/Lint、RAG 对比、对 Hermes 知识库的实践启发。