Karpathy LLM Wiki — 科研知识库

触发条件

• 建立 LLM 知识库 / Karpathy Wiki
• 管理论文、研究笔记
• 摄入（Ingest）新的论文或资料
• 对知识库提问（Query）
• 维护知识库健康（Lint）

核心思想

和传统 RAG 不同——RAG 每次提问都从零开始检索、重新拼凑答案——Karpathy 模式让 LLM 持续构建和维护一个持久化的 wiki。新资料进来后，LLM 不是简单索引它，而是提取关键信息、整合到现有 wiki 中、更新实体页、修订主题摘要、标记新旧资料之间的矛盾。知识被编译一次，然后持续保持最新，而不是每次查询都重新推导。

Wiki 是一个持久化、不断复利的产物。 交叉引用已经在那里了，矛盾已经被标记，综合摘要已经反映了你读过的所有内容。

你从不自己写 wiki 页面——LLM 写和维护所有内容。你负责提供资料、提问、引导方向。LLM 负责摘要、交叉引用、归档和簿记。

系统架构

三层结构

• Raw sources（原始资料）：你收集的论文、文章、数据文件。不可变——LLM 只读不改，这是真相来源。
• The wiki（知识库）：LLM 生成的 markdown 文件集合。LLM 全权负责这个层，你只读不写。
• The schema（配置）：你正在读的 CLAUDE.md/SKILL.md。它告诉 LLM wiki 的结构、约定和工作流。这个文件不是一成不变的——你和 LLM 随着使用共同演化它。

目录结构

research-wiki/
├── CLAUDE.md          # Schema：告诉 LLM 如何维护 Wiki
├── raw/               # 原始资料（不可变，只进不改）
│   ├── papers/        # PDF 论文
│   ├── articles/      # Markdown/Web 文章
│   ├── images/        # 图片资源
│   └── data/          # 数据文件
├── wiki/              # LLM 维护的 Wiki（LLM 全权负责）
│   ├── index.md       # 内容目录（每个页面 + 一行摘要）
│   ├── log.md         # 操作日志（只追加）
│   ├── overview.md    # 研究主题概述
│   ├── entities/      # 研究实体页
│   ├── concepts/      # 核心概念页
│   ├── papers/        # 论文摘要页
│   └── synthesis/     # 综合分析（Query 产物存回）
└── assets/            # 图片附件

页面格式和目录结构只是起点，不是铁律。根据你的研究领域和偏好，和 LLM 一起调整。

核心操作

1. Ingest（摄入新资料）

当用户提供论文、文章或其他资料时：

1. 将资料保存到 raw/ 对应子目录
2. 读取资料内容，与用户讨论关键要点
3. 在 wiki/papers/ 创建论文摘要页
4. 在 wiki/concepts/ 更新或创建相关概念页
5. 在 wiki/entities/ 更新或创建相关实体页（学者、机构、方法名等）
6. 更新 wiki/index.md 添加新页面索引
7. 追加 wiki/log.md 记录本次摄入（格式：## [YYYY-MM-DD] ingest | 论文标题）。文件引用使用 Markdown 标准链接 [文件名](路径)，确保 VSCode Markdown Preview 中可点击
8. 向用户汇报：触及了多少个 Wiki 页面

一篇资料可能触及 10-15 个 wiki 页面。建议逐篇摄入、保持参与——阅读摘要、检查更新、引导 LLM 强调重点。当然也可以批量摄入，取决于你的工作风格。

2. Query（对知识库提问）

当用户提出问题：

1. 先读 wiki/index.md 找到相关页面
2. 深入阅读相关 Wiki 页面
3. 综合回答，引用具体来源
4. 如果回答有持续价值（对比分析、主题梳理、新发现），存回 wiki/synthesis/ 作为新页面——你的探索也在为知识库积累知识，不应消失在聊天记录里
5. 追加 wiki/log.md 记录本次查询

Query 产物可以是多种格式：markdown 页面、对比表、演示文稿（Marp）、图表（matplotlib）。好的分析应该像 ingested sources 一样复利增长。

3. Lint（健康检查）

当用户要求维护或定期检查：

1. 扫描所有 Wiki 页面，查找：
   • 页面间的矛盾或不一致
   • 过时声明（被新论文/来源推翻的旧观点）
   • 孤立页面（没有入站链接）
   • 文中提到但未建立页面的重要概念
   • 缺失的交叉引用
   • 可以填补的数据缺口
2. 自动修复能发现的问题
3. 报告需要人工判断的问题
4. 建议值得追问的新问题和值得补充的新来源
5. 追加 wiki/log.md 记录维护结果

页面格式规范

以下格式是建议起点，可根据领域调整。

论文摘要页（wiki/papers/）

---
title: "论文完整标题"
authors: ["作者1", "作者2"]
year: 2024
venue: "会议/期刊名"
tags: [标签1, 标签2]
ingested: 2026-04-21
---

## 核心问题
本文要解决什么问题？

## 方法
核心方法是什么？

## 关键发现
- 主要结果1
- 主要结果2

## 与Wiki的关系
[[相关概念页]]
[[其他相关论文]]

## 笔记
任何额外的观察和笔记

概念页（wiki/concepts/）

---
topic: 概念名称
tags: [类别标签]
created: 2026-04-21
---

## 定义
这个概念是什么？

## 关键要点
- 要点1
- 要点2

## 相关论文
[[论文1]]
[[论文2]]

## 相关概念
[[相关概念]]

## 笔记
补充信息

index.md 和 log.md

index.md 是内容导向的目录——列出 wiki 中每个页面的链接和一行摘要，按类别（论文、概念、实体、综合分析）组织。LLM 在每次 ingest 时更新它。查询时 LLM 先读 index 找相关页面，再深入阅读。在中等规模（~100 篇论文，几百个页面）效果很好，不需要 embedding-based RAG 基础设施。

log.md 是时间线日志——追加记录发生了什么（ingest、query、lint）。每条以一致前缀开头（如 ## [YYYY-MM-DD] ingest | 标题），可以用简单 unix 工具查询：grep "^## \[" log.md | tail -5 得到最近 5 条记录。log.md 在 wiki/ 目录下，文件链接使用相对于 wiki/ 的路径：[文件名](concepts/xxx.md)、[文件名](papers/xxx.md)、[文件名](../raw/papers/xxx.pdf)。

Bundled Scripts

scripts/search-agent-papers.sh

搜索 arXiv 最新的智能体方向论文并下载 PDF 到 raw/papers/。 用法：bash scripts/search-agent-papers.sh [output_dir] [max_papers]

• 自动查询 arXiv API，按提交日期排序
• 默认取 5 篇，输出到 raw/papers/
• 去重 + 跳过 2025-04-01 之前的论文
• 下载后可直接触发 Ingest 流程

可选工具生态

随着 wiki 增长，你可能需要这些配套工具：

• qmd — 本地 markdown 搜索引擎（BM25 + 向量混合 + LLM 重排序）。wiki 页面多时比 index.md 更高效。有 CLI（LLM 可 shell 调用）和 MCP server。
• Marp — markdown 转演示文稿。可以直接从 wiki 内容生成幻灯片。
• Dataview — Obsidian 插件，对页面 frontmatter 跑查询，生成动态表格和列表。
• 本地图片管理 — 下载文章图片到 assets/，让 LLM 能直接查看和引用图片，而不是依赖可能失效的 URL。
• Wiki 本质上是 git repo，免费获得版本历史、分支和协作能力。

为什么有效

维护知识库最烦的部分不是阅读和思考——而是簿记。更新交叉引用、保持摘要最新、标记新旧矛盾、维持几十页的一致性。人类放弃 wiki 是因为维护负担增长比价值还快。LLM 不会厌倦、不会忘记更新交叉引用、一次可以改 15 个文件。wiki 能保持维护是因为维护成本接近零。

人的工作是筛选资料、引导分析、提出好问题、思考这一切意味着什么。LLM 的工作是剩下的所有事。

本文档基于 Andrej Karpathy 的 LLM Wiki 方法论改编，原始 gist：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f 该文档发布于 2026 年 4 月，获得 88,000+ 收藏。本 skill 将其适配为中文科研场景。

这个理念可以追溯到 Vannevar Bush 1945 年的 Memex 构想——一个私人的、主动策展的知识库，文档之间的关联路径和文档本身一样有价值。他没能解决的问题是：谁来做维护？LLM 回答了这个问题。