Karpathy 的 LLM Wiki：一种将 RAG 从「解释器模式」升级为「编译器模式」的革命性架构

引言：当向量数据库遭遇中年危机

2026年4月3日，前OpenAI联合创始人、特斯拉前AI总监Andrej Karpathy在X上发布了一条推文，展示了他的"第二大脑"方案。短短48小时内，这条内容获得了1600万次浏览，连Twitter联合创始人Jack Dorsey都称之为"伟大的创意文件"。

这个方案之所以引发轰动，是因为它从根本上颠覆了我们对AI知识库的认知——不是用向量数据库"喂"给AI，而是让AI自己来构建和管理知识库。

本文将深度剖析Karpathy提出的LLM Wiki架构，从算法原理、工程实现、代码实战三个维度，彻底讲清楚这个"编译器模式"到底比传统RAG强在哪里，以及如何用它打造真正能"进化"的个人AI知识库。

一、传统RAG的结构性困境：为什么你的知识库总是不够聪明

1.1 RAG的工作原理与三大原罪

在讲LLM Wiki之前，必须先正视传统RAG系统的深层问题。

RAG（检索增强生成）的标准流程：

1. 数据摄入阶段：把文档切分成小块（chunk），每个chunk通过Embedding模型转成高维向量，存入向量数据库
2. 查询阶段：用户提问 → 将问题转成向量 → 在向量数据库中做Top-K相似度检索 → 把检索到的chunks作为上下文喂给LLM → LLM生成回答

这个流程看起来逻辑清晰，但在实际使用中会遇到三个致命问题：

原罪一：O(N)检索的全局推理困境

当你问"总结一下过去三年我们公司的技术架构演进历程"时，这个问题涉及跨时间维度、跨数十个文档的宏观推理。向量数据库的Top-K检索是基于单点相似度的——它能找到"最像这个问题"的几个片段，但无法理解这些片段之间的因果关系和演进脉络。

举个例子：假设你的向量数据库里有三个文档片段：

• 片段A："2019年，我们采用单体架构部署在单一服务器上"
• 片段B："2021年，引入了微服务架构，使用Docker容器化"
• 片段C："2023年，我们迁移到了Kubernetes集群"

当用户问"技术架构如何演进"时，Top-K检索可能只返回片段C（因为它的向量和"架构演进"这个关键词最相似），而丢失了关键的上下文链条——你不知道演进的前提和过程。

原罪二：拓扑结构的丧失

机械分块（chunking）会切断知识实体之间的上下文纽带。想象一篇技术文档讲的是"如何用Gin框架构建RESTful API"，其中"中间件"、"路由"、"参数绑定"都是相互关联的概念。但分块后，这些概念被切割成独立的向量存进数据库。

当LLM检索到这些chunks时，它看到的是一堆碎片化的知识点，缺乏语义拓扑（Semantic Topology）的支撑，导致回答时常常出现"拼接幻觉"——把不相关的内容硬凑在一起。

原罪三：零复利——每次查询都是从头开始

这是最被忽视但影响最深的问题。假设你昨天问LLM："这个项目的主要模块有哪些？"LLM花了10秒检索了20个chunks，生成了一个完美的答案。今天你再问同样的问题，整个系统依然需要重新执行：向量检索 → 上下文组装 → LLM推理。

那些昨天花大力气总结出来的"主要模块分析"，没有任何复利积累。知识的价值在第一次查询后就被丢弃了。

1.2 企业级RAG的成本陷阱

从工程视角看，传统RAG的成本结构也有问题：

当你的知识库规模超过1000篇文档时，这些成本会呈指数级增长。

二、LLM Wiki的核心哲学：从"查询时检索"到"摄入时编译"

2.1 编译器 vs 解释器：一场范式革命

Karpathy的LLM Wiki方案的革命性，在于它将知识处理从"JIT（Just-In-Time，解释器模式）"升级为"AOT（Ahead-Of-Time，编译器模式）"。

这个类比来自计算机科学：

解释器模式（JIT）：Python、JavaScript这类解释型语言，每行代码执行时都需要"翻译"成机器码。优点是启动快、交互灵活；缺点是每次执行都要重复翻译，效率低。

编译器模式（AOT）：C、C++这类编译型语言，代码在运行前就编译成机器码。缺点是编译时间长；优点是运行时零翻译开销，执行效率极高。

映射到知识管理领域：

在LLM Wiki中，知识在摄入时就完成了"编译"——LLM作为"知识编译器"，把原始资料咀嚼、去重、交叉验证，生成结构化的Markdown维基百科。查询时，LLM直接读取这些"编译好的知识"，无需再做昂贵的向量检索和上下文组装。

2.2 Karpathy的核心洞察：让AI来管理知识库

Karpathy方案的另一个颠覆性在于：把AI从"被动的问答者"变成"主动的知识库管理员"。

传统知识管理工具（Notion、Obsidian等）的范式是"人写，AI查"：

• 人来写内容
• 人来维护结构、标签和链接
• AI只是做检索、摘要的插件

Karpathy的设想完全反过来：

• 人只负责"扔原材料"（原始笔记、代码、文档、聊天记录）
• AI负责"整理和编译"（生成结构化Wiki、建立链接、自我修复）
• AI Agent负责"使用知识"（回答问题、生成代码、辅助决策）

这个范式转变的意义深远：当AI成为知识库的"主人"，它可以做到人类无法做到的事情——持续自我更新、自我检查和自我修复。

三、三层架构深度解析：Raw Sources / Wiki / Schema Rules

3.1 第一层：Raw Sources（不可变的原始事实层）

Raw Sources是LLM Wiki的"地基"，存储用户的原始资料。

包含内容：

• 笔记、日志、灵感记录
• 代码片段、API文档
• 项目需求文档、技术方案
• 历史聊天记录、邮件摘要
• 任何你认为有价值的原始信息

核心设计原则：不可变性（Immutability）

Raw Sources应该被视为"历史真实记录"，遵循以下原则：

• 不重写：不反复编辑已存储的内容
• 只追加（Append-Only）：新内容追加到末尾
• 可追溯：任何时候都能追溯到原始来源

这种设计的价值：

1. 降低幻觉风险：给LLM提供真材实料，减少"脑补"
2. 形成统一的事实源：避免多版本导致的混淆
3. 支持审计：可以随时回溯"这个结论是从哪来的"

目录结构示例：

data/
  raw/
    2026-01-15-project-kickoff.md
    2026-02-20-architecture-discussion.md
    2026-03-10-api-spec.md
    2026-04-01-code-review-notes.md
    2026-04-15-bug-fix-log.md

3.2 第二层：Wiki（LLM生成的知识视图层）

Wiki是LLM Wiki的"灵魂"，由LLM从Raw Sources中主动生成和维护。

表现形式：

• 大量Markdown文件（index.md、project_X.md、concept_Y.md等）
• 每个文件对应一个"实体"：概念、人物、项目、组件、API等
• 文件之间通过双向链接（Markdown链接）形成知识图谱

生成方式：

LLM读取Raw Sources中的原始资料，执行以下操作：

1. 信息抽取：提取关键实体、概念、事件
2. 结构化：按统一格式组织内容（背景 / API / 使用示例 / 参考）
3. 建立链接：发现相关实体，自动添加Markdown链接
4. 持续演化：当新的Raw Sources加入时，LLM会更新Wiki

核心能力（LLM作为知识库管理员）：

┌─────────────────────────────────────────────────────────┐
│                    LLM Wiki 管理员                      │
├─────────────────────────────────────────────────────────┤
│  ✓ 检测矛盾：发现两个页面对同一概念描述不一致           │
│  ✓ 补齐链接：发现可以互相链接但尚未连接的实体           │
│  ✓ 重写摘要：把冗长的原始笔记压缩成精炼的概述           │
│  ✓ 自我修复：定期对Wiki进行"体检"（lint）              │
│  ✓ 知识演进：随着新资料加入，Wiki持续更新和优化         │
└─────────────────────────────────────────────────────────┘

为什么Wiki比向量更利于推理？

当LLM Agent需要回答问题时，它面对的是：

• 传统RAG：一堆相似度高的碎片化chunks，需要自己拼凑关系
• LLM Wiki：结构清晰的维基百科，每个实体有独立页面、明确归属、相互链接

想象你要了解"这个项目的认证模块"：

• 在RAG中：检索到5个包含"认证"的片段，你需要自己拼出整体图景
• 在Wiki中：直接打开auth-module.md，里面有完整的架构说明、依赖关系、API文档、使用示例

3.3 第三层：Schema Rules（给LLM的知识工程规范）

Schema Rules是LLM Wiki的"宪法"，定义了Wiki应该如何组织和管理。

本质：

• 一个约束文档 + Prompt模板
• 告诉LLM如何"正确地"维护知识库

包含内容：

# LLM Wiki Schema Rules

## 命名规范
- 页面文件名：使用 kebab-case，如 `auth-module.md`
- 页面标题：简洁明确，如 `## 认证模块`
- 链接文本：使用描述性文字 + 括号内路径

## 结构规范
每个Wiki页面必须包含以下章节：
1. 背景（Background）
2. 关键信息（Key Information）
3. 相关实体链接（Related Entities）
4. 示例（Examples）
5. 参考（References）

## 链接规则
- 人物 → 项目
- 项目 → 组件
- 组件 → API
- 概念 → 具体实现

## 更新策略
- 新实体：加入index总目录
- 合并实体：保留更完整的版本，删除冗余
- 废弃信息：标记为 `[DEPRECATED]`，不删除

## Lint（健康检查）规则
- 检查矛盾描述
- 标记缺失链接（用 TODO:）
- 优化重复内容

为什么Schema Rules重要？

没有Schema，LLM生成的Wiki会像不同人写的笔记——风格不一、结构混乱。有了Schema，LLM从"随缘写Wiki"变成"在统一规范下维护项目文档"，确保知识的一致性和可维护性。

四、Ingest-Compile-Lint闭环：LLM Wiki的工作流引擎

4.1 三阶段工作流

LLM Wiki的运行机制可以概括为一个闭环的三个阶段：

┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   Ingest    │ -> │   Compile   │ -> │    Lint    │
│   数据摄入   │    │    编译     │    │   健康检查  │
└─────────────┘    └─────────────┘    └─────────────┘
       ^                                      │
       └──────────────────────────────────────┘
                     持续迭代优化

阶段一：Ingest（数据摄入）

# 将原始资料放入raw目录
raw_dir = Path("data/raw")
new_notes = raw_dir.glob("*.md")
# LLM读取所有原始文件，提取信息

阶段二：Compile（编译）

# LLM读取raw目录 → 生成/更新Wiki
# 关键：不是"检索"，而是"主动整理"
compiled_wiki = llm_compile(raw_sources, schema_rules)

阶段三：Lint（健康检查）

# LLM对当前Wiki进行全面体检
# - 检测矛盾
# - 补充缺失链接
# - 优化结构
refined_wiki = llm_lint(current_wiki, schema_rules)

4.2 为什么这个闭环能实现"知识复利"？

传统的RAG：Query → Retrieve → Generate → 丢弃中间结果
LLM Wiki：Ingest → Compile → Lint → Wiki持久化 → 下次直接读

关键差异在于"编译结果是否被保留"：

在LLM Wiki中，LLM花大力气总结出的"项目模块分析"，会被固化为modules/project-analysis.md。下次有类似问题时，Agent直接读取这个文件，零重复计算。

更重要的是，这个Wiki会持续演化：

• 新资料加入 → 自动更新相关页面
• 发现错误 → 自动修正
• 链接缺失 → 自动补齐

随着时间推移，你的LLM Wiki会变得越来越"聪明"，而不是每次都从零开始。

五、代码实战：从零搭建一个自进化知识库

5.1 项目结构

llm-wiki-demo/
├── data/
│   ├── raw/           # 原始资料目录
│   │   ├── project-kickoff.md
│   │   ├── architecture.md
│   │   └── api-spec.md
│   └── wiki/          # Wiki输出目录
│       ├── schema.md  # Schema Rules
│       └── index.md   # 主索引（LLM生成）
├── src/
│   └── wiki_engine.py # 核心引擎
└── requirements.txt

5.2 核心代码实现

"""
LLM Wiki 核心引擎
实现了：Ingest-Compile-Lint 闭环
"""

import os
from pathlib import Path
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

# ============================================================
# 配置
# ============================================================
API_KEY = os.getenv("XUEDINGMAO_API_KEY", "")
BASE_URL = "https://xuedingmao.com/v1"
MODEL = "claude-sonnet-4-6"

DATA_DIR = Path(__file__).parent.parent / "data"
RAW_DIR = DATA_DIR / "raw"
WIKI_DIR = DATA_DIR / "wiki"
SCHEMA_FILE = WIKI_DIR / "schema.md"
INDEX_FILE = WIKI_DIR / "index.md"


# ============================================================
# LLM 调用封装
# ============================================================
def create_client():
    """创建OpenAI兼容客户端"""
    if not API_KEY:
        raise RuntimeError("请设置 XUEDINGMAO_API_KEY 环境变量")
    return OpenAI(api_key=API_KEY, base_url=BASE_URL)


def call_llm(client: OpenAI, system_prompt: str, user_prompt: str) -> str:
    """
    通用LLM调用
    
    Args:
        client: OpenAI兼容客户端
        system_prompt: 系统提示词
        user_prompt: 用户提示词
    
    Returns:
        LLM生成的文本
    """
    response = client.chat.completions.create(
        model=MODEL,
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.2,  # 低温度保证一致性
        max_tokens=4096
    )
    return response.choices[0].message.content


# ============================================================
# Ingest：读取原始资料
# ============================================================
def read_all_raw_sources() -> str:
    """
    读取raw目录下所有.md文件，拼接为一个完整文本
    这是"不可变事实层"的读取操作
    """
    if not RAW_DIR.exists():
        raise RuntimeError(f"Raw目录不存在: {RAW_DIR}")
    
    files = sorted(RAW_DIR.glob("*.md"))
    if not files:
        raise RuntimeError("Raw目录为空，请先添加原始资料")
    
    content_parts = []
    for f in files:
        content_parts.append(f"# FILE: {f.name}\n\n")
        content_parts.append(f.read_text(encoding="utf-8"))
        content_parts.append("\n\n")
    
    return "".join(content_parts)


# ============================================================
# Compile：生成/更新Wiki
# ============================================================
DEFAULT_SCHEMA = """# LLM Wiki Schema Rules

## 目标
为AI编码代理提供结构化、可链接、可扩展的知识库视图。
所有内容以Markdown组织，使用标题、列表和代码块。

## 页面命名规范
- 文件名：kebab-case（如 `auth-module.md`）
- 标题：简洁明确的中文描述

## 必需章节
每个Wiki页面应包含：
1. **背景**：这是什么，为什么重要
2. **关键信息**：核心概念、API、设计决策
3. **相关链接**：使用Markdown链接引用相关实体
4. **示例**：可运行的代码示例
5. **参考**：原始资料来源

## 链接规则
- 使用 `[实体名](#文件路径)` 格式
- 相关实体之间必须建立双向链接
- 链接文本要描述性，不要只写"点击这里"

## 更新策略
- 新实体：加入index总目录
- 矛盾信息：保留更完整的版本，标注差异
- 废弃信息：标记 `[DEPRECATED]`，不删除

## Lint规则
- 检查矛盾描述（同一概念的不同说法）
- 标记缺失链接（用 `TODO:`）
- 优化冗余内容
"""


def ensure_schema():
    """确保Schema文件存在"""
    WIKI_DIR.mkdir(parents=True, exist_ok=True)
    if not SCHEMA_FILE.exists():
        SCHEMA_FILE.write_text(DEFAULT_SCHEMA, encoding="utf-8")
        print(f"✅ 已创建 Schema: {SCHEMA_FILE}")


def compile_wiki():
    """
    核心编译函数：将Raw Sources编译为Wiki
    
    关键思路：
    1. 读取Schema Rules作为约束
    2. 读取当前Wiki（如果存在）
    3. 读取新Raw Sources
    4. LLM在保持结构的前提下增量更新Wiki
    """
    ensure_schema()
    client = create_client()
    
    schema_rules = SCHEMA_FILE.read_text(encoding="utf-8")
    raw_sources = read_all_raw_sources()
    
    # 读取当前Wiki（如果有）
    if INDEX_FILE.exists():
        current_wiki = INDEX_FILE.read_text(encoding="utf-8")
        wiki_context = f"--- 当前 index.md 内容 ---\n{current_wiki}\n\n请在此基础上增量更新，不要完全推翻重写。"
    else:
        current_wiki = ""
        wiki_context = "这是首次构建Wiki，请创建一个完整的结构化索引。"
    
    system_prompt = f"""你是一个"知识工程师"，负责维护LLM驱动的知识库。

关键原则：
- 不修改原始事实，只在Wiki层做结构化抽象
- 所有内容必须可追溯到Raw Sources
- 使用简洁中文，但保留英文技术术语

以下是Schema规则，请严格遵守：

{schema_rules}
"""
    
    user_prompt = f"""请基于以下"原始资料"构建/更新Wiki的index.md。

要求：
1. 提取重要实体（项目、组件、API、概念等），建立清晰的小节结构
2. 为相关实体添加Markdown双向链接
3. 每个实体的描述要精炼，包含"是什么"和"与其他实体的关系"
4. 如果已有Wiki，请在原有结构上增量更新
5. 输出完整的index.md内容

{wiki_context}

--- Raw Sources（只读原始资料）---
{raw_sources}
"""
    
    print("⏳ LLM正在编译Wiki...")
    new_wiki = call_llm(client, system_prompt, user_prompt)
    
    INDEX_FILE.write_text(new_wiki, encoding="utf-8")
    print(f"✅ Wiki已更新: {INDEX_FILE}")
    
    return new_wiki


# ============================================================
# Lint：健康检查与自我修复
# ============================================================
def lint_wiki():
    """
    Wiki健康检查函数
    
    让LLM对当前Wiki进行全面审查：
    - 检测矛盾
    - 补充缺失链接
    - 优化结构
    """
    ensure_schema()
    client = create_client()
    
    if not INDEX_FILE.exists():
        raise RuntimeError("index.md不存在，请先运行compile_wiki()")
    
    schema_rules = SCHEMA_FILE.read_text(encoding="utf-8")
    current_wiki = INDEX_FILE.read_text(encoding="utf-8")
    
    system_prompt = f"""你是一个"知识库体检医生"，负责对Wiki进行健康检查和优化。

目标：在不改变事实的前提下，提升Wiki的一致性、连贯性和可用性。

Schema规则：

{schema_rules}
"""
    
    user_prompt = f"""请对以下Wiki/index.md进行全面审查和改进。

检查项目：
1. **矛盾检测**：同一概念在不同页面中的描述是否一致？
2. **链接完整性**：相关实体之间是否都有双向链接？
3. **结构优化**：章节是否清晰，内容是否冗余？
4. **缺失标注**：用 `TODO:` 标记需要补充的内容

对于发现的问题：
- 小问题：直接修正
- 矛盾问题：保留更完整的版本，注释差异
- 缺失信息：添加 `TODO:` 标注

输出改进后的完整index.md。

--- 当前Wiki内容 ---
{current_wiki}
"""
    
    print("⏳ LLM正在进行Wiki健康检查...")
    refined_wiki = call_llm(client, system_prompt, user_prompt)
    
    INDEX_FILE.write_text(refined_wiki, encoding="utf-8")
    print("✅ Wiki lint完成（已自我修复）")
    
    return refined_wiki


# ============================================================
# Query：基于Wiki回答问题
# ============================================================
def answer_with_wiki(question: str) -> str:
    """
    示例：基于Wiki回答问题
    
    在真实项目中，可以替换为完整的"代码Agent"
    - 让Agent在回答前先"查表"（读Wiki相关章节）
    - 基于Wiki中的约束来生成回答
    """
    client = create_client()
    
    if not INDEX_FILE.exists():
        raise RuntimeError("Wiki不存在，请先构建知识库")
    
    wiki_content = INDEX_FILE.read_text(encoding="utf-8")
    
    system_prompt = """你是一个AI编码助手，善于阅读项目知识库（Wiki）并基于此回答问题。

原则：
- 优先使用Wiki中的内容
- 不要凭空捏造不存在的API或模块
- 如果Wiki信息不足，明确说明"不确定"
- 指出可能需要补充的原始资料类型
"""
    
    user_prompt = f"""以下是当前项目的Wiki索引（可视为整个知识库的导览）：

--- WIKI INDEX START ---
{wiki_content}
--- WIKI INDEX END ---

现在请基于Wiki，回答用户问题：

{question}
"""
    
    return call_llm(client, system_prompt, user_prompt)


# ============================================================
# 主流程
# ============================================================
if __name__ == "__main__":
    import sys
    
    print("=" * 60)
    print("LLM Wiki 引擎 - 自进化知识库")
    print("=" * 60)
    
    # Step 1: 添加原始资料
    print("\n📁 请将你的原始资料放入:", RAW_DIR)
    print("   支持.md格式的文件")
    
    # Step 2: 编译Wiki
    print("\n" + "=" * 60)
    print("Step 1: 编译Wiki")
    print("=" * 60)
    compile_wiki()
    
    # Step 3: Lint健康检查
    print("\n" + "=" * 60)
    print("Step 2: Wiki健康检查")
    print("=" * 60)
    lint_wiki()
    
    # Step 4: 示例问答
    print("\n" + "=" * 60)
    print("Step 3: 示例问答")
    print("=" * 60)
    demo_question = "请总结这个项目的主要模块，并给出新开发者的上手建议"
    print(f"\n❓ 问题: {demo_question}\n")
    answer = answer_with_wiki(demo_question)
    print("📖 回答:")
    print(answer)

5.3 使用方法

第一步：准备原始资料

在data/raw/目录下添加Markdown文件：

# 2026-01-15-项目启动会议.md

## 参会人
- 张三（产品负责人）
- 李四（技术负责人）
- 王五（后端开发）

## 讨论要点

### 技术选型
决定使用Go语言作为后端主语言，原因：
1. 高并发支持好（goroutine）
2. 部署简单（编译成单一二进制）
3. 团队熟悉度

### 架构设计
采用微服务架构，核心模块：
- 用户服务（auth-service）
- 订单服务（order-service）
- 支付服务（payment-service）

### 时间线
- 1月底：完成技术验证
- 2月中：MVP上线
- 3月：正式版本发布

第二步：运行引擎

pip install openai python-dotenv
export XUEDINGMAO_API_KEY='your-api-key'

python src/wiki_engine.py

第三步：查看生成的Wiki

# 项目知识库索引

## 核心模块

### [用户服务 (auth-service)](#auth-service)
- **状态**: 开发中
- **技术栈**: Go, JWT, Redis
- **主要功能**: 用户注册/登录/认证
- **相关链接**: [订单服务](#order-service) 需要认证

### [订单服务 (order-service)](#order-service)
- **状态**: 开发中
- **技术栈**: Go, PostgreSQL, gRPC
- **主要功能**: 订单创建/查询/取消
- **依赖服务**: [支付服务](#payment-service), [用户服务](#auth-service)

### [支付服务 (payment-service)](#payment-service)
- **状态**: 设计阶段
- **技术栈**: Go, Stripe API
- **主要功能**: 支付处理
- **被依赖**: [订单服务](#order-service)

## 项目时间线
- 2026-01-15: 项目启动
- 2026-01-31: 技术验证完成
- 2026-02-15: MVP上线
- 2026-03: 正式版本发布

## 关键技术决策
1. 使用Go语言（高并发、简单部署）
2. 微服务架构（独立部署、独立扩展）
3. gRPC服务间通信（高性能）

六、与传统RAG的深度对比

6.1 算法复杂度对比

6.2 适用场景分析

LLM Wiki更适合的场景：

• 需要跨文档的全局推理（如"总结三年架构演进"）
• 知识库规模大且持续增长
• 对回答质量要求高，需要可追溯
• AI Agent需要"记住"历史交互

传统RAG更适合的场景：

• 快速原型验证
• 文档规模较小（<100篇）
• 查询相对简单（单文档问答）
• 需要实时更新（流式数据）

6.3 Token成本实测对比

假设场景：知识库有1000篇文档，用户每天问10个问题，连续使用30天。

传统RAG成本：

• 每次查询：Embedding + Top-K + LLM推理
• 总Token：10次/天 × 30天 = 300次查询
• 每次平均：~5000 Token输入
• 总计：~1,500,000 Token/月

LLM Wiki成本：

• 编译阶段：一次性 ~100,000 Token
• 查询阶段：直接读文件 ~500 Token/次
• 总计：~115,000 Token/月

节省比例：约92%

七、工程实践建议与最佳实践

7.1 如何减少幻觉

核心原则：事实层和视图层解耦

# ✅ 正确做法
Raw Sources = 只保存事实（日志、Spec、代码）
Wiki = LLM的"观点层"，可以不断重写，但必须可追溯到Raw Sources

# ❌ 错误做法
让LLM在Wiki中"脑补"不存在的事实

Schema Rules中的约束：

## 事实约束
- 不要凭空增加新的API、模块或功能描述
- 每个结论必须有Raw Sources作为依据
- 不确定的信息用 `[?]` 标记

7.2 Token成本优化策略

问题：Raw Sources规模很大时，不能一次性全部喂给LLM

解决方案：分片 + 召回

def smart_compile(raw_sources: list[str]) -> str:
    """
    智能编译：分片处理大规模Raw Sources
    
    策略：
    1. 按时间/主题分组
    2. 每次编译一个分组
    3. 最终合并所有分组的Wiki
    """
    # 分组策略：按文件时间排序，每50个文件为一组
    chunks = [raw_sources[i:i+50] for i in range(0, len(raw_sources), 50)]
    
    partial_wikis = []
    for i, chunk in enumerate(chunks):
        print(f"编译第 {i+1}/{len(chunks)} 批...")
        wiki = compile_chunk(chunk)
        partial_wikis.append(wiki)
    
    # 合并所有分Wiki
    return merge_wikis(partial_wikis)

7.3 自进化流程自动化

推荐将以下步骤集成到CI/CD：

# .github/workflows/wiki-evolution.yml
name: Wiki Evolution

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 2 * * *'  # 每天凌晨2点自动更新

jobs:
  update-wiki:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: 更新Raw Sources
        run: |
          # 从代码库、文档更新同步原始资料
          git diff --name-only HEAD~1 > changes.txt
          for file in $(cat changes.txt); do
            cp "$file" data/raw/ 2>/dev/null || true
          done
      
      - name: 编译Wiki
        run: python src/wiki_engine.py --compile
      
      - name: Lint检查
        run: python src/wiki_engine.py --lint
      
      - name: 提交Wiki更新
        run: |
          git config user.name "Wiki Bot"
          git config user.email "wiki-bot@example.com"
          git add data/wiki/
          git diff --staged --quiet || git commit -m "Auto-update Wiki"
          git push

八、未来展望：LLM Wiki的演进方向

8.1 当前局限

• 编译成本高：首次构建需要对所有原始资料进行LLM处理
• Schema设计依赖人工：需要经验丰富的工程师定义Schema Rules
• 多语言支持：当前主要针对Markdown，未来可扩展到代码、知识图谱等

8.2 可能的演进方向

方向一：Schema自动生成

让LLM自动从Raw Sources中推断Schema Rules，而不是人工定义。这将大幅降低使用门槛。

方向二：多模态Wiki

除了文本，支持图片、图表、代码片段的直接索引和检索。

方向三：主动学习

Wiki不仅被动接收Raw Sources，还能主动从外部（如GitHub、论文库）抓取相关信息。

九、总结：为什么LLM Wiki是知识管理的未来

Karpathy的LLM Wiki方案，本质上是将"编译器思维"引入知识管理：

当你的AI知识库能够：

• 自我更新：新资料自动整合
• 自我修复：矛盾自动检测
• 自我进化：随着使用越来越聪明

它就不再是一个"工具"，而是一个真正的"第二大脑"。

这也呼应了Karpathy的核心观点：在Agent时代，知识库不需要人来维护，而需要AI来管理。我们只需要做一件事——持续向Raw Sources中投入原材料，让AI来完成剩下的工作。

参考资源

• Karpathy原始方案：gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• second-brain开源项目：github.com/sephora-ai/second-brain
• LLM Wiki实现流程参考：CSDN - LLM Wiki实现流程

Tags: LLM Wiki, RAG, 知识库, AI Agent, Karpathy, 自进化知识库, 第二大脑

Keywords: LLM Wiki|RAG替代方案|知识编译器|向量数据库局限|Karpathy第二大脑|自进化知识系统|Ingest-Compile-Lint|AI知识管理|AOT编译模式|解释器vs编译器