Karpathy LLM 知识库

先解决什么

个人知识库很容易烂尾。原文丢进 Markdown 文件夹后，很少有人持续做三件事：给来源按主题归类、把零散来源合并成结构化文章、在引用时核对每个关键数字和日期。结果常见状态是：目录越堆越乱，index.md 记录的是文件系统时间而不是最后更新时间，某些结论又和手头来源不一致。

这个技能把知识库写成一个由 LLM 持续维护的产物，而不是一次性摘要。核心定位来自 Karpathy 的两句概括：LLM 负责写和维护 wiki，人类负责读和提问；wiki 是会复利积累的产物。

工作方式

整个结构都在项目根目录下，主要分三层：

• raw/：不可变来源。按主题分子目录，例如 raw/machine-learning/。只读取，不改写观点，不重写事实。
• wiki/：编译后的知识文章。按主题分子目录，只保留一级子目录；另有两个全局文件：wiki/index.md 做全局索引，wiki/log.md 只追加操作日志。
• SKILL.md：Schema 层。负责定义结构和工作流规则，模板放在同级 references/ 下，需要精确格式时读取。

常规入口是 Ingest。流程先抓取来源并存入 raw/，文件名形如 raw/topic/YYYY-MM-DD-descriptive-slug.md；若发布日期未知，文件名省略日期前缀。随后做 Triage：在 wiki/ 中用关键实体和同义词检索，判断是新增文章、合并进现有文章、与其他内容冲突，还是没有实质新增。没有新材料时仍然保留 raw，并按日志格式记录后停止。

Compile 时会确定内容归属：与已有文章同主题则合并；是新概念则按概念命名新文章；跨主题时放在最相关目录，并用 See Also 做交叉引用。关键约束是 Source fidelity：任何数字、日期和直接引用都要先在 raw 中定位，再按原文形式写入。来源写 42K 就保留 42K，不改写为 42,000。派生值也要保留计算成分，保证每个组成都能在 raw 中找到。

另一个核心机制是 Grounding Invariant。wiki/ 里每个承重事实都必须在文章 Raw 字段指向的 raw 文件中逐字存在。Compile 通过 locate-before-write 建立这个约束；Lint 再通过 python3 /scripts/check_evidence.py 复查高信号字面量。因为 raw 不可变，一旦校验通过，文章也能保持可信。

Query 只读不写。先读 wiki/index.md 定位候选文章，再用主题关键词和同义词做全文搜索；两者都为空才说明 wiki 中没有相关内容。回答优先使用 wiki 内容，并用 Markdown 链接标注引用来源。只有用户明确要求时才把回答归档为新的 wiki 页面，归档页格式不同：不设 Raw 字段，Summary 前缀写 [Archived]，且归档页不参与级联更新。

级联更新也很重要。主文章完成后还要检查全文中的别名和受影响断言，更新所有真正受影响的非归档文章，并刷新元数据里的 Updated 日期。结论被更新或反驳时，旧结论不能直接抹掉，要通过 Status 块标记为 Outdated 或 Disputed。

适用边界

它适合做长期、可持续维护的技术或个人知识库，前提是你能接受“先落 raw，再编译”的节奏。Multi-source research 只在用户明确要求调研时使用，并且搜索可以并行，但编译必须串行，因为索引、日志和级联更新是共享状态。

运行 Lint 时要区分三类问题。索引一致性、内部链接、Raw 引用和 See Also 可在证据充分时自动修正；check_evidence.py 输出属于机械报告，需要结合 raw 上下文判断，脚本不负责改事实；跨文章冲突、旧结论缺少状态块、缺少交叉引用等问题只报告，不静默修复。