llm-wiki by Karpathy
编译 > 检索：让LLM构建持续增值的知识网络
📚 学习来源
| 项目名 | llm-wiki |
|---|---|
| 作者 | Andrej Karpathy — 前OpenAI创始成员、前Tesla AI总监、Stanford CS博士 |
| GitHub | https://github.com/karpathy/llm-wiki |
| 原始文档 | Gist: LLM Wiki |
| 核心定位 | 用LLM替代RAG，构建"编译 > 检索"的个人知识库模式 |
| 研究日期 | 2026-04-29 |
💡 核心洞察
Karpathy在2026年4月发推说，他发现自己的Token消耗发生了质变——不再主要用于写代码，而是转向了"manipulating knowledge"。连"vibe coding"的提出者都开始把AI的主要用途从"制造"转向"整理"了。
为什么RAG不够好？
"This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation."
想象你要研究一个需要综合5篇文档的深度问题。RAG每次都要从海量chunk里重新检索、重新拼凑。明天问同样的问题，它再做一遍同样的工作。
编译 > 检索
llm-wiki的核心理念：让大模型在后台持续构建、维护一个结构化、相互链接的本地Markdown知识库，而不是在每次提问时临时去海量原始数据里翻找。
↑ 人类收集 LLM持续维护
🏗️ 三层架构设计
整个系统没有复杂的向量数据库，没有中间件，只有三个纯文本层：
你精心挑选的原始文档集合：文章、论文、图片、数据文件。不可变——LLM从中读取但永不修改。这是你的事实来源。
LLM生成的Markdown文件目录：摘要、实体页、概念页、对比、综合分析。LLM完全拥有这一层。你读它；LLM写它。
告诉LLM wiki如何组织、有什么约定、在摄入来源/回答问题/维护wiki时要遵循什么工作流的关键配置文件。这是让LLM成为有纪律的wiki维护者而非通用聊天机器人的关键。
Wiki层特殊文件
wiki/index.md |
全局索引，每篇文章一行，按主题分组，含链接+摘要+更新日期。LLM在每次ingest时更新。 |
|---|---|
wiki/log.md |
追加式操作日志，每条记录以 ## [YYYY-MM-DD] ingest | Title 开头。只追加不编辑。 |
⚙️ 三大核心操作
1. Ingest（摄入）
你把新来源放入raw集合，告诉LLM处理它。典型流程：
- LLM阅读来源
- 与你讨论关键收获
- 在wiki中写摘要页
- 更新索引
- 更新整个wiki中受影响的相关实体页和概念页（一篇来源可能触达10-15个wiki页面）
- 向日志追加一条记录
- 合并不追加：如果新内容的核心论点与现有文章相同 → 合并到那篇文章
- 矛盾要标注：用
> CONTRADICTION: [旧主张] vs [新主张] from [来源]格式 - cascade更新：摄入后检查同一主题和其他主题的相关文章是否受影响
2. Query（查询）
你针对wiki提问。LLM搜索相关页面、阅读它们、综合生成带引用的答案。答案可以是多种格式：Markdown文档、对比表格、Marp幻灯片、Matplotlib图表。
好的答案不要让它留在聊天记录里。告诉LLM把它整理成一篇新的分析文档，归档进Wiki。这就形成了复利循环：
来源被摄入Wiki → 你的提问产生新洞察 → 最好的洞察被归档为新页面 → Wiki不仅从外部来源增长，也从你自己的探索中增长。
3. Lint（健康检查）
定期让LLM对整个Wiki进行"代码审查"：
- 检测内容自相矛盾的地方
- 找出没有被任何页面引用的"孤岛页面"
- 列出被多次提及但还没有独立页面的重要概念
- 标记被新来源取代的过时结论
- 建议值得调查的新问题和值得寻找的新来源
⚖️ llm-wiki vs RAG 对比
| 维度 | 传统RAG | llm-wiki |
|---|---|---|
| 知识处理时机 | 查询时（每次提问都重新处理） | 摄入时（每个来源只处理一次） |
| 交叉引用 | 每次查询临时发现 | 预先构建并持续维护 |
| 矛盾检测 | 可能完全不会被注意到 | 摄入时主动标记 |
| 知识积累 | 无——每次从零开始 | 复利式增长 |
| 输出格式 | 聊天回复（转瞬即逝） | 持久化的Markdown文件（可复用） |
| 维护者 | 系统黑箱 | LLM（透明、可编辑、可追溯） |
| 人类角色 | 上传文件 + 提问 | 策展信息源、探索方向、提出关键问题 |
| 技术栈 | 向量数据库 + embedding模型 | 零！就是文件夹 + Markdown |
🎯 适用场景
| 个人成长 | 追踪自己的目标、健康、心理、自我提升——归档日记条目、文章、播客笔记 |
|---|---|
| 深度研究 | 在数周或数月内深入一个主题——阅读论文、文章、报告，逐步建立综合wiki |
| 阅读书籍 | 边读边归档每一章，为角色、主题、情节线及其连接方式构建页面。读完一本，你就有了一本丰富的配套wiki |
| 团队知识库 | 由LLM维护的内部wiki，以Slack对话、会议记录、项目文档、客户电话为输入 |
| 尽调/规划 | 竞争分析、尽调、旅行规划、课程笔记——任何需要随时间积累知识并希望它有组织而非分散的场景 |
🚀 对一人公司的启发
重构MEMORY.md：上半部分写"综合判断"，下半部分append-only记录证据链。当新输入与现有判断矛盾时，显式标注冲突。
人类放弃维护知识库的根本原因是维护成本>价值。LLM让这个成本趋近于零。设计让LLM自动维护的流程，而非依赖人工更新。
不要等到查询时才发现来源冲突。在摄入时就标注，特别是对决策系统的多个来源依据，显式写出矛盾点。
有价值的查询答案应该归档回知识库，形成二次增长。知识不仅来自外部来源，也来自你自己的深度思考和提问。
定期让LLM检查知识库的连贯性、矛盾、孤立页面。这是保持知识库长期健康的必要机制。
对于中小规模，简单的index.md+log.md完全够用。不要过度工程。先跑起来，再迭代。
📎 参考资料
| Karpathy原始Gist | LLM Wiki - A pattern for building personal knowledge bases using LLMs |
|---|---|
| 社区Skill实现 | Astro-Han/karpathy-llm-wiki — 可安装的SKILL.md文件 |
| Python实现 | llmwiki on PyPI — 包含heal/lint pipeline |
| 中文解读 | LLM Wiki:让大模型替你打理知识库的完整指南 |
本页面由看宝AI研究团队于2026年4月29日深度研究产出
相关项目：gbrain by Garry Tan | 返回开源项目索引