Andrej Karpathy在GitHub上发布了一份名为LLM Wiki的文档引起了巨大的关注，一派认为"这不就是多绕了几步的RAG"，另一派已经打开编辑器着手搭建测试。
文档里没有新模型、新算法、新硬件。它描述的无非是一套流程：把原始素材喂给LLM，让它生成结构化的Markdown wiki，再基于这个wiki做检索、问答和持续更新。
其实我们值得关注的是它背后的架构思想：思路从"需要时去检索源文本"变成了"将原始素材编译成结构化中间表示，后续推理都基于这个产物展开"。
解释器 vs. 编译器
传统RAG的流程清晰：对文档分块，将分块嵌入向量数据库，查询时检索最相关的top-k分块，作为上下文传递给LLM，生成回答。
NotebookLM、ChatGPT文件上传以及大多数生产环境的RAG管线都遵循这一模式，能用，也能扩展到企业级场景。
但设计中埋着一个结构性限制：LLM在每次查询时都从头重新发现知识。一个需要综合五份文档才能回答的问题，模型每次都要实时定位、拼凑相关片段。没有任何东西积累下来，查询之间不存在持续构建的持久化结构。
Karpathy引用了一个计算机科学的类比，RAG表现得像解释器——运行时重新求值一切；LLM Wiki更像编译器，预先将源材料处理成结构化中间表示（即wiki），后续工作针对编译产物展开，而非反复阅读原始材料。
Wiki充当中间表示，index.md充当符号表，log.md充当构建日志，LLM agent充当编译器进程。
原始素材输入一次，被编译成带有交叉引用、实体页面和综合摘要的结构化Markdown页面，之后所有推理都基于这些编译输出展开。
"复利效应"在实践中到底意味着什么
Karpathy反复提到compounding（复利）一词，它在这里承担的是真正的概念工作，不是包装话术。
标准PKM（个人知识管理）工作流中，信息的增长充其量是线性的。收藏了200篇文章，190篇原封不动地躺着，记得住的10篇是读过两遍的。知识不会自己相互关联，每次需要用到时，结构都得手动搭建。
LLM Wiki改变了这一点。模型不只是写一个摘要页面，它会通读整个现有wiki找出新内容与已有实体页面、概念页面和主题摘要的交集，然后更新所有相关内容，一个新来源可能触及10到15个现有页面。
每一个新输入都被整合进现有知识结构，而非堆叠在上面。矛盾被标记，交叉引用被添加，综合页面被修订。
这就是复利效应的实质：摄入的内容越多，新材料被解读时所处的上下文就越丰富。第100个来源的处理建立在一个已经蒸馏了前99个来源知识的wiki之上，不会从零起步。
跟常规笔记方式的对比很鲜明。在Notion、Roam或普通的Obsidian仓库里，添加第100条笔记不会让第50条笔记变得更聪明。LLM Wiki模式下会，这是因为wiki本身是被持续更新的产物，也是所有后续推理的依据。
使其真正模块化的三层架构
从软件工程角度看，这个设计站得住脚的原因在于它将大多数笔记工具混为一谈的三个问题清晰拆开了。
第一层是原始素材，不可变。文章、论文、PDF、网页剪藏、代码文件、图片，统一进入
raw/
目录，永不被修改。LLM可以读取但没有写入权限。这是事实基准——如果wiki出了问题，可以从原始素材重建。来源的可追溯性得以保留。
第二层是wiki，由LLM操作。一个Markdown文件目录，包含实体页面（人物、公司、论文）、概念页面（思想、方法、框架）、主题摘要、对比表格和综合概述。LLM创建、更新、维护全部内容，人来阅读。这就是编译产物。
第三层是schema，即CLAUDE.md或AGENTS.md。一份配置文档，告诉LLM wiki的结构规范、约定和工作流。Karpathy称之为关键配置文件。主要是通过这个文件把LLM从一个通用聊天机器人转变为有纪律的wiki维护者。
分层的意义在于每层可以独立替换。任何Markdown阅读器都能替代Obsidian，Claude Code可以换成OpenAI Codex，schema可以随领域演进而调整。原始素材始终不动。Wiki只是git仓库中的文件，版本历史、差异追踪和分支功能天然具备。
多数"AI笔记应用"产品把存储、组织和展示纠缠在一个不可拆分的层中，这是它们与LLM Wiki设计之间的根本区别。
摄入→查询→检查 操作循环
运行模型的三个核心操作需要说明清楚。
摄入：将新来源放入
raw/
，指示LLM处理。LLM读取内容，如有需要与你讨论关键要点，然后编写摘要页面、更新索引、更新相关实体和概念页面、追加日志条目。一个来源进去，一次操作更新多个页面。
查询：提出问题，LLM先读
index.md
定位相关页面，再深入具体页面，跨页面综合信息，生成带引用的答案——引用指向wiki页面，wiki页面又指回原始素材。关键之处在于，好的答案可以作为新页面归档回wiki。你要求的分析、你需要的对比、你发现的关联，不会沉没在聊天记录里，而是成为持续积累的产物的一部分。
检查：定期运行wiki健康检查，让LLM识别页面之间的矛盾、被更新来源取代的过时内容、没有入站链接的孤立页面、被提及但缺少独立页面的重要概念，以及缺失的交叉引用。这类维护工作人往往会跳过，LLM则不会。
摄入操作的实现框架如下：
# llm_wiki_ingest.py — minimal ingest operation pattern
import os
from pathlib import Path
from datetime import datetime
RAW_DIR = Path("raw/")
WIKI_DIR = Path("wiki/")
LOG_FILE = WIKI_DIR / "log.md"
INDEX_FILE = WIKI_DIR / "index.md"
SCHEMA_FILE = Path("CLAUDE.md") # or AGENTS.md for Codex
def ingest_source(source_path: str, llm_client) -> dict:
"""
将单个原始来源摄入wiki。
返回更新/创建的页面字典。
"""
source = Path(source_path)
assert source.exists(), f"Source not found: {source}"
# 读取schema以便LLM了解wiki约定
schema = SCHEMA_FILE.read_text()
# 读取当前索引以便LLM了解现有页面
index = INDEX_FILE.read_text() if INDEX_FILE.exists() else "# Index\n"
# 读取来源内容
content = source.read_text()
prompt = f"""
You are maintaining a personal wiki following this schema:
{schema}
Current wiki index:
{index}
New source to ingest:
--- BEGIN SOURCE: {source.name} ---
{content}
--- END SOURCE ---
Tasks:
1. Write a summary page for this source (wiki/sources/{source.stem}.md)
2. Identify all entities (people, papers, projects, companies) mentioned
3. For each: update or create their entity page with new information
4. Identify all concepts/topics and update their concept pages
5. Note any contradictions with existing wiki content
6. Update index.md with any new pages
7. Append to log.md: ## [{datetime.now().strftime('%Y-%m-%d')}] ingest | {source.name}
Return a JSON list of all files modified with their full content.
"""
response = llm_client.chat(prompt)
pages_updated = parse_file_updates(response)
# 将所有更新写入磁盘
for filepath, file_content in pages_updated.items():
full_path = WIKI_DIR / filepath
full_path.parent.mkdir(parents=True, exist_ok=True)
full_path.write_text(file_content)
return pages_updated
def lint_wiki(llm_client) -> list:
"""
对wiki进行健康检查。返回发现的问题列表。
"""
all_pages = list(WIKI_DIR.rglob("*.md"))
page_contents = {
p.relative_to(WIKI_DIR): p.read_text()
for p in all_pages[:50] # 分批处理以控制在上下文窗口内
}
prompt = f"""
Review these wiki pages for quality issues:
{format_pages(page_contents)}
Identify:
- Contradictions between pages
- Orphan pages (no inbound links from other pages)
- Concepts mentioned but lacking their own page
- Claims that seem stale or need verification
- Missing cross-references that should exist
Return a structured list of issues with page names and descriptions.
"""
return llm_client.chat(prompt)
Schema文件（
CLAUDE.md
）使整套流程具备纪律性：
# Wiki Schema — Personal Research: [Your Domain]
## Directory Structure
wiki/
index.md # master catalog, updated on every ingest
log.md # append-only chronological record
overview.md # evolving synthesis of the whole domain
sources/ # one page per raw source ingested
entities/ # people, papers, projects, companies
concepts/ # ideas, methods, frameworks, terms
comparisons/ # structured comparisons between entities/concepts
## Conventions
- Every page has YAML frontmatter: title, tags, source_count, last_updated
- Cross-references use [[wiki-link]] syntax (Obsidian-compatible)
- When new info contradicts existing content, add a ⚠️ Contradiction section
- Orphan prevention: every new page must link from at least one existing page
- Log entries format: ## [YYYY-MM-DD] operation | description
## Ingest Workflow
1. Read source fully
2. Write sources/[name].md summary
3. Update entities/ pages for all named entities
4. Update concepts/ pages for all key ideas
5. Update overview.md synthesis if thesis evolves
6. Update index.md catalog
7. Append log.md entry
8. Report: X pages created, Y pages updated, Z contradictions flagged
Obsidian作为IDE
Karpathy对自己实际工作流的描述，是整篇文档中最有实操价值的段落：
"实际操作中，我一边打开LLM agent，另一边打开Obsidian。LLM根据对话进行编辑，我实时浏览结果——跟随链接、查看图谱视图、阅读更新后的页面。Obsidian是IDE；LLM是程序员；wiki是代码库。"
这描述的是一个真实的反馈循环：LLM写入，你阅读；你浏览图谱视图，注意到哪里缺少链接、哪些页面还很单薄；你追问，LLM继续更新页面；你再读一遍。
这个交互循环把它和"批量处理文档生成知识库"区分开来。这是一个实时的、迭代式的系统，人的角色是导航、策展和判断，不是写作和归档。
IDE类比之所以精准，在于IDE不是被动的文本编辑器。它提供语法高亮、跳转到定义、引用追踪、错误指示,还能在整个代码库范围内一次完成重构。Obsidian的图谱视图在知识领域扮演了类似角色：展示哪些概念是枢纽，哪些页面是孤岛，哪些主题之间密集互联，哪些研究方向尚待深入。
LLM负责写入，Obsidian负责导航，两者的组合产生了各自单独无法达到的效果。LLM看不出图谱中缺了什么；你无法在一次操作中更新15个相互引用的页面。配合起来，这个空白就被填上了。
硬性限制
维护成本与语料库规模一同增长，比如说20个来源时wiki还好管理，但是200个来源时就变成了一项治理工程。
LLM传播的不只是事实错误，还有结构性错误。RAG中一个错误的答案只是一次性的偏差，再问一次可能就对了。LLM Wiki模式下，如果模型在摄入过程中错误关联了两个概念，这条错误链接会在多个页面中被反复强化，后续摄入在错误关系的基础上继续叠加。错误不再孤立，而是被编织进结构。事后检测和纠正需要专门的审计，重新查询解决不了。
Schema也是薄弱的一环。Wiki的质量上限取决于CLAUDE.md schema的质量。约定模糊或前后不一致，LLM在不同摄入会话中就会做出矛盾的决策。这不是模型能力的问题，这是规格说明的问题。Schema必须明确、具体，并随发现的边界情况持续修订。
上下文窗口限制在规模化时不可忽视。索引优先的方法在约100个来源、几百个页面时运作良好，超过这一规模就需要正式的搜索基础设施。Karpathy提到了
qmd
——一个用于Markdown文件的本地混合BM25/向量搜索引擎，带有MCP服务器接口。缺少类似工具的话，LLM花在读索引上的开销增加，查询延迟随之上升。
为什么这是个人工具，不是组织工具
大多数人跳过了这一点，但对任何考虑将此模式推广到团队或公司的人来说，它至关重要。
个人知识系统和组织知识系统的差异不在数据量，在问责结构。
个人系统中，你是唯一的质量关卡。哪些来源可信、哪些结论是暂定的、哪些页面需要重新审视，这些判断全由你做。你容忍不完美，因为所有后果自己承担。Wiki虚构了两个概念之间的关系，发现它的是你，从中学到教训的也是你。
团队系统中，四个问题会立刻浮现，而且没有纯技术解决方案。谁来判断来源质量——多人同时摄入来源，质量差异马上显现。谁的schema说了算——不同贡献者对概念组织方式有各自的心智模型。谁负责矛盾解决——页面A说X，页面B说非X，总得有人拍板。谁来审计虚构的关系——LLM生成的交叉引用看上去合理但实际上错了，没读过原始来源的人根本察觉不到。
缺少明确的治理机制——审查流程、版本控制纪律、每个页面类别的责任人——AI非但不会减缓错误传播，反而会加速。Wiki变得"权威"的速度会快过人工审查验证的速度。
Karpathy的gist简短提及了企业/团队场景，说的是"可能让人类参与审查更新"。这句话背后的分量很重。对组织wiki来说，"人类参与"不是锦上添花，它就是那个组织几十年来一直没能解决的治理难题——无论有没有AI。
这个模式对个人有用。作为团队模板去推广，需要一整套独立的流程设计层。Karpathy的文档明确没有涉及这部分。
最现实的采用方式：从小处起步
读到这里就想立即搭建的人，最容易犯的错误是：试图在一次会话中导入全部现有研究资料，并把输出当作权威结论。
这不是它的用法。系统面向增量成长，不是批量初始化。
一个可行的路径：1、为一个聚焦的领域编写CLAUDE.md schema（不要试图覆盖"所有知识"），摄入5到10个来源，逐页阅读LLM生成的内容，遇到不一致就修正schema。2、每次会话添加两三个来源，每周跑一次检查，留意哪些类型的页面始终单薄或出错，相应调整schema。3、当你提出一个需要综合20个以上来源的问题，拿到的答案引用了你三周前通过LLM写成的某个页面——wiki开始产生真正的回报。
复利效应需要时间积累。一次性设置不够，它是一个随每次会话质量提升的系统，前提是schema保持干净、检查操作持续执行。
Wiki是Markdown文件组成的git仓库，版本历史和分支功能天然具备。用好它——每次摄入会话后提交。如果LLM犯了一个扩散开来的结构性错误，可以查看差异并回滚。
总结
Karpathy没有发明新技术，他在清晰阐述一个工作流模式，让LLM天生擅长的事——快速阅读、综合、交叉引用、一致地遵循约定——去接替人类一直需要但从未能持续做好的工作。
核心洞察不是"用LLM充当知识库"。知识工作中最乏味的那些事——归档、交叉引用、更新、保持一致性——恰恰是LLM可以长期执行而不退化的部分。
良好的来源筛选、精心维护的schema、定期的健康检查，以及在结构性错误扩散之前捕捉和修正它们的判断力。系统负责记账，思考仍然是你的事。
https://avoid.overfit.cn/post/aa66818e5918471ea5545161f3d1a932
by JIN
