在大语言模型应用领域，Andrej Karpathy 提出了一种全新的知识管理范式 —— 将 LLM 本身作为知识库的编译器和维护者，而非仅仅作为检索工具。这种被称为「LLM Wiki」或「Idea File」的方法，正在改变开发者和技术研究者组织和维护知识的方式。与传统的 RAG（检索增强生成）系统不同，LLM Wiki 强调构建一个结构化、可导航且可编辑的知识图谱，而非依赖向量嵌入的模糊匹配。本文将深入剖析其核心架构，提供可直接落地的工程模板。
三层架构设计原理
Karpathy 的 LLM Wiki 采用了经典的三层架构：原始数据层（Raw）、知识维基层（Wiki）和模式定义层（Schema）。这种分层设计的核心理念是将数据的不可变性、生成内容的可塑性与系统行为的可配置性完全分离。Raw 层存放所有摄入的原始文档，这些文件一旦进入系统便不再修改，确保了知识溯源的可靠性。Wiki 层是 LLM 根据 Raw 层内容编译生成的产物，包括概念条目、索引文件和反向链接图谱。Schema 层则定义了 LLM 在执行摄入、查询和检查操作时的行为约束与格式规范。
这种架构的优势在于其天然支持版本控制和审计追踪。由于 Raw 层完全不可变，任何对知识库内容的质疑都可以回溯到原始来源进行验证。同时，Wiki 层的生成性质意味着整个知识库可以根据更新后的 Schema 重新编译，从而实现系统性的批量更新而非零散的修补。Schema 层的存在则将「如何维护知识库」的决策从代码逻辑中抽离出来，使得非技术人员也能通过修改配置来调整系统的行为模式。
目录结构与文件组织
一个完整的 LLM Wiki 项目应当遵循统一的目录结构，这不仅便于 LLM 理解和导航，也是维护工作流得以自动化的基础。建议采用以下文件树组织方式：
project-root/
├── CLAUDE.md # Claude Code 的行为模式定义
├── AGENTS.md # 通用 Agent 的操作指南
├── raw/ # 原始不可变文档
│ ├── papers/ # 学术论文（PDF 转换为 Markdown）
│ ├── articles/ # 博客文章和网络内容
│ └── notes/ # 个人笔记和会议记录
├── wiki/ # LLM 生成的维基内容
│ ├── INDEX.md # 顶层主题索引
│ ├── concepts/ # 概念条目目录
│ │ ├── transformer.md
│ │ ├── attention.md
│ │ └── ...
│ └── backlinks/ # 反向链接索引
├── scripts/ # 辅助脚本
│ ├── ingest.py # 文档摄入脚本
│ ├── lint.py # 质量检查脚本
│ └── query.py # 查询接口脚本
└── log.md # 操作日志（追加写入）
INDEX.md 是整个知识库的入口点，它应当按照主题层级组织，呈现从宏观到微观的知识结构。每个顶级主题对应一组相关的概念条目，条目之间通过 Wiki 链接（[[概念名称]] 格式）相互关联。backlinks 目录则系统性地记录了每个概念被哪些其他条目引用，从而构建出隐式的知识图谱。这种双向链接机制使得查询时不仅能够定位直接相关的概念，还能顺藤摸瓜地发现潜在的关联知识。
模式定义文件详解
CLAUDE.md 和 AGENTS.md 是 LLM Wiki 的核心配置文件，它们分别针对特定 Agent 工具的行为进行约束。这两个文件的存在使得同一个知识库可以被不同的 Agent 以不同的方式操作，或者同一个 Agent 在不同的上下文时期遵循不同的规则。
CLAUDE.md 通常包含以下关键部分：项目概述（说明这个 Wiki 的主题范围和目标用户）、操作约束（明确什么操作是允许的、什么操作是禁止的）、摄入流程（定义新文档如何被处理和整合）、查询协议（说明如何解释用户问题并定位相关概念）、维护要求（定期检查的频率和检查项）。一个典型的 CLAUDE.md 开头可能如此定义：「此知识库专注于大语言模型架构研究，Agent 对 raw/ 目录只有读取权限，对 wiki/ 目录有写入权限但需遵循概念唯一性原则。」
AGENTS.md 则更侧重于技术细节的说明，包括依赖项列表、脚本使用方法、测试验证流程以及代码风格约定。对于维护工作流而言，AGENTS.md 应该明确定义何时触发摄入操作（是手动触发还是定时任务）、lint 检查的具体标准是什么（链接完整性？内容长度？格式一致性？）、以及发现问题时向人类维护者报告的机制。值得注意的是，这两个模式文件本身也是 Wiki 的一部分，它们应该随着实践经验的积累而不断迭代优化。
标签系统与元数据设计
标签系统是实现精细化知识组织的关键组件。在 LLM Wiki 中，标签不仅用于分类，更用于表达概念之间的关系维度和属性特征。建议采用层次化标签体系：第一层标签表示主题领域（如「模型架构」「训练技术」「应用场景」），第二层标签表示概念类型（如「基础概念」「进阶概念」「前沿探索」），第三层标签表示状态标记（如「待验证」「已审查」「需更新」）。
每个概念条目应当包含标准化的元数据头部，这既便于后续的自动化处理，也为人类阅读提供了快速的上下文了解。元数据至少应包含：标题、创建日期、最后修改日期、来源引用、相关标签以及反向链接列表。以下是一个概念条目的示例结构：
---
title: "Transformer 注意力机制"
created: "2026-01-15"
updated: "2026-03-28"
sources: ["raw/papers/attention-is-all-you-need.md"]
tags: ["模型架构", "核心机制", "基础概念"]
related: ["self-attention", "multi-head-attention", "positional-encoding"]
---
# Transformer 注意力机制
## 定义
注意力机制是...（正文内容）
## 关键组件
- **Query**: ...
- **Key**: ...
- **Value**: ...
## 相关概念
- [[self-attention]] - 自我注意力的详细解释
- [[multi-head-attention]] - 多头注意力的实现细节
维护工作流与质量保障
LLM Wiki 的长期健康运转依赖于系统化的维护工作流。维护工作主要分为三个维度：内容摄入、链接维护和质量检查。内容摄入是将新的原始文档转换为 Wiki 条目的过程，这个过程应当是增量式的而非全量式的，每次摄入后都需要更新 INDEX.md 和相关条目的反向链接。链接维护是确保所有 Wiki 链接指向有效目标的过程，这包括检查概念名称的拼写一致性以及识别孤儿条目（即没有被任何其他条目引用的概念）。
质量检查脚本（lint.py）应当自动化执行以下检查项：broken-link-check（检查所有 Wiki 链接是否有效）、orphan-check（识别未被引用的概念条目）、freshness-check（检查哪些条目超过指定时间未更新）、consistency-check（验证元数据字段的完整性和格式一致性）。建议将质量检查集成到持续集成流程中，每次向 Wiki 提交变更时自动触发检查，并在发现问题时阻止合并。
维护的频率取决于知识库的活跃程度。对于个人使用的研究型 Wiki，建议每周进行一次增量摄入和基本的链接检查；对于团队协作的企业级知识库，则可能需要每日摄入和持续的质量监控。无论频率如何，保持一份操作日志（log.md）记录所有的维护活动，这对于追溯问题和理解知识库的演变历史非常有价值。
落地实践参数清单
要将上述设计理念转化为可运行的知识库系统，需要关注以下关键参数的配置。上下文窗口方面，建议将单次编译任务的上下文限制在十万 tokens 以内，这意味着每个批次摄入的原始文档总量应当控制在这个范围内，如果文档过大则需要先进行摘要提取。概念粒度方面，每个 Wiki 条目的理想长度为 500 到 2000 字，这个范围既能保证内容的深度，又不会因为过长而导致读取和更新的困难。
标签数量方面，强烈建议将单个条目的标签数量控制在五个以内，过多的标签会导致分类模糊和维护负担。反向链接方面，每个概念条目至少应该被三个其他条目引用，否则说明该概念可能过于边缘化或者需要重新调整分类体系。编译轮次方面，对于一个全新的知识库，初始编译通常需要 3 到 5 轮的迭代调整才能达到满意的结构质量，之后每轮增量摄入通常只需要 1 到 2 轮的微调。
维护提醒方面，建议设置以下时间阈值：超过 90 天未更新的条目标记为「可能过时」，超过 180 天未更新的条目标记为「需审查」，超过 365 天未更新的条目应该考虑归档或删除。这些阈值可以根据具体的领域特性进行调整，但原则是保持知识库的时效性和可靠性。
资料来源
本文关于 Karpathy LLM Wiki 架构的阐述主要参考了 Antigravity Codes 的系列博客文章、DAIR.AI Academy 的知识库指南，以及 GitHub 关于 agents.md 最佳实践的总结。这些来源提供了从概念原理到工程实现的完整视角，为构建自己的知识库系统提供了坚实的参考基础。