karpathy-llm-wiki：把 Karpathy 的 LLM Wiki 打包成一个 Agent Skill
Agent Skills-compatible LLM wiki for Claude Code, Cursor, and Codex. Build a Karpathy-style knowledge base from raw sources, citations, and linting.
秒懂
- 它是什么？
- 它把「让模型维护 markdown 知识库」这件事固化成 ingest、query、lint 三个操作，装进 Claude Code、Cursor、Codex。适合愿意长期喂养同一份 wiki 的人，不适合想一次性导入一堆 PDF 就自动出答案的人。
- 适合谁用？
- 如果你的知识来源是持续流入的论文、博客和网页，而且你愿意接受「先编译成页面、再回答问题」的节奏，这个 skill 值得装一次试跑，安装命令是 npx add-skill Astro-Han/karpathy-llm-wiki。如果你的需求是拿一个已有的大规模语料库做检索问答，或者你希望系统自动判断某条知识该不该废弃，它明确不提供这些能力，README 的设计边界一节把向量检索、置信度评分、来源哈希追踪都列为刻意不做的项。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 54 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是「每次提问都重新读原文」这件事
RAG 把知识切块、向量化，查询时再检索拼装。每一次提问，模型都要重新推导一遍概念之间的关系。karpathy-llm-wiki 走的是另一条路：知识在 ingest 阶段就被合成为 markdown 页面，之后的问题直接落在这些页面上。README 的对比表把差别写得很直白，RAG 的知识存在于原始分块与向量中，合成发生在查询时；LLM Wiki 的知识存在于策展过的 markdown 页面里，合成发生在 ingest 与维护阶段。目标读者是那些长期跟踪某个领域、希望知识随来源积累而变得更厚的人，比如持续读论文或技术博客的工程师。它假设你有一个稳定的 agent 工具，并且愿意反复使用同一个知识库，而不是临时问几个问题。
raw/ 与 wiki/ 的双层目录，以及三个操作的分工
仓库给出的目录结构很清楚。raw/ 存放不可变的原始材料，按主题分目录，文件名带日期，例如 raw/topic/2026-04-03-source-article.md。wiki/ 存放由模型维护的编译结果，同样按主题分目录，另有 index.md 作为全局目录、log.md 作为只追加的操作日志。三个操作在这个结构上分工：ingest 把来源收进 raw/，做一次分诊，然后新建或更新 wiki 页面，如果判断没有新信息就只写日志；query 在 wiki 里检索并用引用作答，引用指向具体的 markdown 页面；lint 检查索引完整性、链接和整体健康度，能自动修的自动修，剩下的报告出来。README 强调一次 ingest 可能更新多个页面、加强交叉引用、记录矛盾之处，这是「wiki 随时间复利」这一说法在机制层面的落点。
安装与第一次 ingest 的实际路径
标准安装是一条命令：npx add-skill Astro-Han/karpathy-llm-wiki。README 的工具兼容表列出 Claude Code、Cursor、OpenCode 都用这条命令，Codex CLI 则要求手动把内容复制到 .agents/skills/karpathy-llm-wiki/，其他工具需要把 SKILL.md、references/、scripts/ 三个部分放进该工具自己的 skill 目录。装好之后的使用方式不是敲 CLI 子命令，而是对 agent 说自然语言。README 的 Quick Start 给了三个例子：说「Ingest this article: https://example.com/attention-is-all-you-need」触发收录，说「What do I know about attention mechanisms?」触发带引用的问答，说「Lint my wiki」触发健康检查。这里没有配置文件、没有环境变量、没有数据库连接串，所有状态就是文件系统里的那两个目录。这一点降低了上手成本，也意味着版本管理、备份、冲突处理全部由你自己负责。
设计边界里最有争议的几条
README 专门有一节列出「刻意不做」的功能，理由来自三个月的生产日志和对 LLM Wiki v2、llm-wiki-compiler、OKF 等项目的调研。其中两条值得单独看。第一，不做来源哈希的新鲜度追踪，理由是 raw/ 不可变，哈希只能防住不会发生的事，真正的新信息会以新来源的形式通过正常 ingest 进来。这个论证成立的前提是 raw/ 真的不被改写，如果使用者手动编辑了已收录的源文件，这套假设就破了，而仓库没有提供检测这种改动的机制。第二，不做持久化的行号引用，理由是观察到的保真度错误都是「值在来源里根本不存在」，整文件 grep 就能抓到，而标注锚点的摩擦会让 agent 干脆跳过这条规则。这是一个基于实际失败模式的取舍，不是偷懒，但它也意味着当错误类型变成「值存在但被归到了错误的段落」时，现有手段抓不住。
不引入向量检索，靠 grep 撑到什么时候
README 明确写了不加向量或图检索，理由是策展过的 wiki 在 50K 到 100K token 规模时，grep 加直接阅读比检索更可靠，只有当召回率可测量地下降时才该引入搜索工具。这个判断有具体的数字边界，比笼统地说「小规模够用」要诚实。它同时也是一个需要使用者自己监控的临界点：仓库没有提供召回率测量工具，也没有在 lint 里检查「提问是否找不到对应页面」。也就是说，从 grep 退化到需要向量检索的那一刻，系统不会主动告诉你。同节还列了不做数值化的置信度或质量评分，理由是缺乏校准的假精确，证据强度应该写在正文里。这条对写作者要求更高，因为读者必须靠读文字判断可信度，而不是看一个分数。
和纯手工个人 wiki、以及 RAG 工具链的差别
README 的 FAQ 把 LLM wiki 和普通个人 wiki 的区别归结为谁在维护：LLM wiki 由模型更新摘要、交叉链接、索引条目和矛盾记录，普通个人 wiki 依赖手工编辑。这个差别在机制上是真实的，因为 ingest 一次可以触及多个页面，手工维护很难保持这种一致性。和 RAG 工具链相比，差别不在检索算法，而在知识何时被固化：RAG 每次查询都重新推导关系，这个 skill 在 ingest 时就把关系写进页面。代价是 ingest 更慢、更贵，而且一旦合成写错，错误会沉淀在页面里被后续查询反复引用。RAG 的错误通常只影响单次回答。这是一个明确的权衡，README 没有回避，但也没有给出检测合成错误的专门手段，lint 检查的是索引、链接和交叉引用，不是内容是否正确。
许可、维护成本与需要你自己盯的部分
仓库采用 MIT 许可，README 顶部有对应的徽章和 LICENSE 文件。MIT 允许商用和修改，具体义务以 LICENSE 原文为准，这里不构成法律意见。维护成本方面，README 给出的 Usage Stats 显示，一个自 2026 年 4 月起每日维护的生产知识库有 94 篇文章、13 个主题目录、99 份来源材料、最近 7 天 87 条操作日志。这组数字说明日常操作量不小，也说明这个模式确实被持续使用过，但它同时暴露了一个维护负担：wiki 的质量取决于你多久做一次 lint、多久喂一次新来源。仓库没有发布 release，README 提到 OKF 一致性仍在跟踪、未来可能重新评估，所以升级路径目前只能靠跟进 main 分支。另外，README 明确说自动 hook 和定时运行不属于这个 skill，那属于 agent harness 的职责，这意味着调度、触发、失败重试都要你在宿主工具里自己搭。
编辑结论
如果你的知识来源是持续流入的论文、博客和网页，而且你愿意接受「先编译成页面、再回答问题」的节奏，这个 skill 值得装一次试跑，安装命令是 npx add-skill Astro-Han/karpathy-llm-wiki。如果你的需求是拿一个已有的大规模语料库做检索问答，或者你希望系统自动判断某条知识该不该废弃，它明确不提供这些能力，README 的设计边界一节把向量检索、置信度评分、来源哈希追踪都列为刻意不做的项。上手前先确认两件事：你的 agent 工具是否支持 agentskills.io 标准（Codex CLI 需要手动复制到 .agents/skills/karpathy-llm-wiki/），以及 SKILL.md 里 ingest 的具体判定规则是否贴合你的领域，因为「没有新信息就只记日志」这条策略在快速变化的领域里可能漏掉需要更新的旧页面。
社区笔记