一个可复用的 Agent Skill，用于在 Claude Code、Cursor、Codex 及其他 Agent Skills 工具中构建 Karpathy 风格的 LLM 知识库。
karpathy-llm-wiki 将 Karpathy 的 LLM Wiki 构想 打包为一个可安装的Agent Skills技能。你的Agent把来源摄入 raw/，把持久的知识页面编译到 wiki/，带引用地回答问题，并检查知识库的一致性。
LLM Wiki 是一种知识系统：由 LLM 维护结构化的 wiki 页面，而不是每次提问都重新检索原始文档。新来源被编译为持久的 markdown 页面，交叉引用随时间更新，答案会引用已经包含综合知识的 wiki 页面。
该技能提供三种操作：
| 操作 | 作用 | 输出 |
|---|---|---|
| 摄入 | 把来源收集到 raw/，归类，然后创建或更新 wiki 条目；没有新内容时只记日志 |
新建或更新的 wiki 页面 |
| 查询 | 搜索知识库并带引用作答 | 链接到 markdown 页面的有据答案 |
| 检查 | 检查索引完整性、链接和知识库健康度 | 自动修复外加问题报告 |
完整技能规范见 SKILL.md。
| 方案 | 知识存放位置 | 综合时机 | 适合 |
|---|---|---|---|
| RAG | 原始分块和向量 | 查询时 | 大规模语料的广泛检索 |
| LLM Wiki | 经过整理的 markdown 页面 | 摄入和维护时 | 累积知识、摘要、持久的交叉链接 |
本技能针对 wiki 模型优化：知识随时间改进，而不是每次查询都重新推导关系。
基于一个自 2026 年 4 月起每日维护的生产知识库：
- 94 个 wiki 条目，分布在 13 个主题目录
- 99 份已摄入的来源材料
- 最近 7 天 87 条操作日志记录
示例 wiki 页面、来源文件和操作日志见 examples/。
npx add-skill Astro-Han/karpathy-llm-wiki适用于任何支持 Agent Skills 标准的工具。
给技能一个 URL、文件或粘贴的文本：
技能把来源存入 raw/，然后在 wiki/ 中编译或更新相应的知识页面。
“关于注意力机制我知道什么？”
技能搜索知识库并给出带引用、链接回你的 markdown 页面的答案。
“检查我的知识库”
检查损坏链接、缺失的索引条目、过期的交叉引用等相关问题。
Karpathy 的核心思路：LLM 维护知识库，人类专注于选择来源和提出好问题。
your-project/
├── raw/ ← 不可变的来源材料
│ └── topic/
│ └── 2026-04-03-source-article.md
├── wiki/ ← 由 LLM 维护的编译知识页面
│ ├── topic/
│ │ └── concept-name.md
│ ├── index.md ← 全局目录
│ └── log.md ← 只追加的操作日志
每个新来源都可以更新多个页面、加强交叉引用并记录矛盾。这正是知识库随时间累积的原因。
本技能遵循 agentskills.io 开放标准：
| 工具 | 安装方式 |
|---|---|
| Claude Code | npx add-skill Astro-Han/karpathy-llm-wiki |
| Cursor | npx add-skill Astro-Han/karpathy-llm-wiki |
| Codex CLI | 复制到 .agents/skills/karpathy-llm-wiki/ |
| OpenCode | npx add-skill Astro-Han/karpathy-llm-wiki |
| 其他工具 | 把 SKILL.md、references/ 和 scripts/ 复制到该工具的技能目录 |
LLM Wiki 由模型维护。新材料到来时，它会更新摘要、交叉链接、索引条目和矛盾记录。普通个人 wiki 依赖手动编辑。
网页、论文、博客文章、PDF、markdown 文件、文本文件和粘贴的文本。技能会把所有内容转换成 raw/ 下的 markdown，并编译到 wiki/。
该工作流基于一个真实的知识库：自 2026 年 4 月起每日维护，包含 94 个条目和 99 份来源。仓库包含示例、模板和设计规范。
经过三个月生产日志和生态调研（LLM Wiki v2、llm-wiki-compiler、OKF、agent-memory 文献），刻意不做以下内容：
- 来源哈希新鲜度跟踪 — raw/ 不可变，哈希只能防范不可能发生的事件。真正的新信息会作为新来源通过正常摄入进入。
- 持久化行号引用 — 观察到的每个保真度错误都是“值不在来源中”，整文件 grep 就能抓住。锚点只能消除一个从未出现过的失败模式，而且标注摩擦会让代理跳过规则。
- 数字置信度或质量评分 — 没有校准支撑的虚假精确度。证据强度应该写在正文里。
- 逐条目审查日期 — 没有人能在编译时预测一个领域变化多快。维护由全库检查驱动，而不是页面级计时器。
- 基于访问量的衰减 — 问得多不等于真。
- 撤回/坏来源机制 — 至今没有发生过。在发生之前手动处理。
- 自动钩子和定时运行 — 那属于代理宿主，不属于一个与工具无关的技能。
- 向量或图搜索 — 在 5 万到 10 万 token 的整理知识库规模下，grep 和阅读更可靠。只有当召回率实测下降时才添加搜索工具。
- 类型化关系本体 — 链接语义就在链接周围的正文里。
- OKF 一致性 — 该规范还是 v0.1 草案，工具生态很小。持续跟踪，未来再评估。
- MCP 服务器、UI、输出子系统 — 超出与工具无关的技能边界。
Karpathy 的 LLM Wiki 构想 的非官方社区实现。价值在于可复用的工作流、提示结构和经过实战检验的知识编译规则。
另见：lucasastorian/llmwiki、atomicmemory/llm-wiki-compiler。我们正在跟踪 Google 的 Open Knowledge Format 草案，待规范和工具成熟后评估兼容性。