Karpathy 的 LLM Wiki 到底该怎么落地，用 OpenClaw 搭一套真正会生长的个人知识系统

2026-04-14

Karpathy 的 LLM Wiki 到底该怎么落地，用 OpenClaw 搭一套真正会生长的个人知识系统

这几天 Karpathy 发了一篇很短但很有后劲的东西，叫 LLM Wiki。

原文不长，甚至可以说很克制。它不是一份“完整方案”，更像一张思路草图。可真正有价值的想法，往往就是这样，字不多，但一旦想通了，你会发现很多以前分散的问题 suddenly 串起来了。

它真正提出的，不是一个新的知识管理 App，也不是一个新的 RAG 小技巧，而是一个非常重要的判断：

我们不应该只让 LLM 在提问时临时去翻资料，而应该让它持续维护一套会生长的 wiki。

这个判断听上去简单，但它其实是在挑战过去两年里很多人默认接受的一套工作方式。

过去我们更习惯这样用大模型：

这当然有用，但它有一个根本问题。

知识没有累积。

每次都像重新开始。每次都像第一次看这些材料。每次都要重新找片段，重新拼接，重新归纳。你问得浅一点，它还能糊出来。你问得深一点，尤其是要跨很多来源做综合判断的时候，这套模式就会越来越笨重。

Karpathy 提出的 LLM Wiki，本质上是在说，不要每次都让模型从原始材料重新“发明答案”，而是让它在原始材料和用户之间，维护一层持续演化的知识层。

这层知识层不是数据库，也不是 embedding 索引，而是一套由 LLM 持续写、持续修、持续交叉引用的 markdown wiki。

我觉得这是一个非常值得认真研究的方向。尤其是对已经在用 OpenClaw、Obsidian、Markdown 工作流，或者本来就有长期知识积累需求的人来说，这不是一个“未来概念”，而是一个已经可以动手做的东西。

这篇文章，我不想只是复述原文。我更想做三件事：

  1. 把 Karpathy 这篇 LLM Wiki 的核心思想讲透
  2. 结合我们现在的实际情况，解释为什么 OpenClaw 特别适合落地这个模式
  3. 给出一套可以真正开始动手的实操教程

如果你认真读完这篇，你应该不只是“理解这个概念”，而是能真的开始搭一套属于你自己的 LLM Wiki。

一，Karpathy 这篇 LLM Wiki，真正提出了什么

先把原文的核心抽出来。

Karpathy 的判断很明确：

大多数人今天对 LLM 和文档的使用方式，本质上还是 RAG。文件上传了，索引建好了，问问题时再去把相关片段召回来。这个流程当然有效，但问题在于，每次回答都像临时施工。知识并没有被编译成一个越来越成熟的中间层。

他提出的替代方案是：

这中间最关键的一句话是：

the wiki is a persistent, compounding artifact

也就是说，这不是一次性的回答系统，而是一种会不断复利的知识产物。

这个想法为什么重要？因为它正好打中了今天很多人使用 LLM 时最隐秘、也最常见的痛点。

我们并不缺回答，我们缺的是回答之后留下来的东西。

每次问出来的内容，如果只存在聊天记录里，它就很容易消失。哪怕当时很精彩，过几天就没了。你以为你已经研究过，实际上你只是和模型聊过。

而 LLM Wiki 想解决的，就是这件事。

它想让知识不只被提取，而是被沉淀、被结构化、被重新组织、被持续修正。

所以如果一定要用一句话概括 Karpathy 这篇文章，我会说：

它不是在教你怎么做一个更聪明的问答系统，而是在教你怎么让 LLM 成为一个不知疲倦的知识维护者。

二，为什么这个方向会打动这么多人

因为它碰到的是一个真实又长期存在的问题。

1. RAG 很有用，但不长记性

大多数 RAG 系统的问题不是不能回答，而是每次都要重新回答。

如果你问的是：
- 某个概念的定义
- 某篇文章说了什么
- 某份文档里有没有这段话

RAG 通常已经足够好。

但如果你问的是：
- 过去三个月我看过的这些材料之间，最关键的共同点是什么
- 某个判断在新资料出现后有没有被推翻
- 一个人物、一个概念、一个项目在不同来源里是如何逐渐被塑形的
- 这批信息里最值得保留的脉络到底是什么

传统 RAG 就会越来越吃力。

因为这不是“找片段”的问题，而是“维护结构”的问题。

2. 人类其实不擅长维护 wiki

很多人都喜欢 wiki，但很少有人真正能长期维护。

原因不是不知道 wiki 好，而是维护太累。

你读了一篇文章，要更新哪几页？
这个人物页是不是要补？
这个概念页是不是和另一页冲突了？
旧结论是不是该修？
有没有新的交叉引用要加？
是不是有一页其实已经过时了？

这些事全都很重要，但也全都很琐碎。

而人类对“重要但琐碎”的事情，天然最容易放弃。

Karpathy 的判断正好切中这一点。

LLM 不是最适合替你思考全部问题，但它非常适合替你做那些知识维护里的繁重体力活：

3. 这套模式特别适合长期研究者、内容创作者和创业者

如果你只是偶尔问几个问题，这个模式未必有那么大价值。

但如果你属于以下人群，LLM Wiki 会非常有吸引力：

因为这些人面对的不是“回答一次”的问题，而是“如何让知识随着时间越来越好用”的问题。

三，为什么我觉得 OpenClaw 特别适合落地 LLM Wiki

如果只看 Karpathy 原文，它更像在说一个通用模式，理论上你用 Claude Code、Codex、Pi、OpenCode 都能做。

但结合我们现在的实际情况，我反而觉得 OpenClaw 是一个很适合把这个模式真正落地的底座。

原因不是它最时髦，而是它和 LLM Wiki 的结构需求天然贴得很近。

1. OpenClaw 本来就是长期运行系统，不是一次性聊天框

LLM Wiki 最怕的一件事，就是你的系统只适合“临时问一下”。

因为 wiki 不是一次搭完的，它需要：
- 持续 ingest 新材料
- 持续更新旧页面
- 持续做 lint 和 health-check
- 持续接收你的问题与修正

这意味着背后的 Agent 不能只是一个开一次网页才出现的对象，它最好是长期在线、长期有记忆、长期有工作区的。

这正好是 OpenClaw 的强项。

2. OpenClaw 天然适合连接多渠道输入

Karpathy 文里提到的原始材料，其实范围很广：
- 文章
- 论文
- 图片
- 笔记
- 会议记录
- Slack threads
- 项目文档
- 客户沟通

而 OpenClaw 最大的优势之一，就是它天然适合做一个多渠道输入汇聚层。

你完全可以把这些输入分批接进来：
- Telegram 发来的链接
- 本地 markdown 文件
- RSS 情报流
- 浏览器抓下来的文章
- Obsidian 里的笔记
- 研究目录里的 PDF / 摘要
- 会议纪要和项目文档

这让 LLM Wiki 不再只是一个“知识管理想法”，而是有现实入口的知识流水线。

3. OpenClaw 已经有工作区、记忆和 Agent 规则体系

LLM Wiki 想真正跑起来，需要三层：
- 原始材料层
- wiki 层
- schema / rules 层

这和 OpenClaw 现有结构非常吻合：
- workspace 作为原始材料与 wiki 容器
- memory / knowledge / notes 作为长期上下文
- AGENTS.md / SOUL.md / 规则文件作为 schema 雏形

也就是说，OpenClaw 不是从零开始搭这个模式，而是已经天然有半套骨架了。

4. OpenClaw 很适合把“问题的答案”反向写回知识库

Karpathy 文里一个很妙的点是，query 的结果也不该只留在聊天里，而应该视情况写回 wiki。

这正是 OpenClaw 很容易做的一件事。因为它本来就习惯：
- 读文件
- 写文件
- 改文件
- 把会话产出沉淀回工作区

这比很多纯聊天界面要自然得多。

所以如果你真的想把 LLM Wiki 做成一个活系统，而不是一个概念，我会非常推荐用 OpenClaw 去做底座。

四，Karpathy 这个模式的 3 层结构，怎么理解最清楚

原文里讲了三层，我这里用更接地气的话展开一下。

1. Raw sources，原始材料层

这层就是“你真正读过、看到、收集到的东西”。

比如：
- 一篇关于 agent 的文章
- 某个播客转录
- 一份会议纪要
- 一组客户访谈
- 一本书的章节摘要
- 你自己的日记和笔记
- 行业日报

这层最重要的原则是：

原始材料尽量保持不动。

它们是 source of truth，不要让 LLM 回写污染它们。

一个很好的目录结构大概会是：

my-wiki/
  raw/
    articles/
    meetings/
    books/
    podcasts/
    screenshots/
    assets/

2. Wiki，中间知识层

这层才是 LLM 真正大显身手的地方。

它不是简单把原文 copy 一份，而是把信息转译成结构化、可交叉引用、可长期维护的知识页面。

它可能包括：
- 人物页
- 概念页
- 项目页
- 时间线页
- 比较页
- 主题综述页
- 问题清单页
- 有争议观点页

例如你在做 OpenClaw 研究，这层可能会长成：

wiki/
  index.md
  log.md
  concepts/
    agent-orchestration.md
    memory-systems.md
    execution-layer.md
  people/
    karpathy.md
    guillermo-rauch.md
  products/
    openclaw.md
    claude-code.md
  themes/
    ai-native-workflows.md
    the-agent-is-the-computer.md
  comparisons/
    openclaw-vs-traditional-rag.md

3. Schema，规则层

这是最容易被忽略、却最决定成败的一层。

如果没有规则，LLM 很快就会把 wiki 写得越来越乱。

你需要明确告诉它：
- 页面怎么命名
- 哪些页面类型允许存在
- ingest 一篇新材料时要更新哪些地方
- 每次都要不要更新 index 和 log
- 如何处理冲突观点
- 什么情况下新建页面，什么情况下只更新旧页
- frontmatter 要不要统一
- 页面之间怎么加链接

这层在 OpenClaw 里，其实就很适合写进：
- AGENTS.md
- 某个专门的 SCHEMA.md
- 或者知识库根目录的 CLAUDE.md / README.md

如果只让我给一个建议，那就是：

不要急着先写很多页，先把 schema 想清楚。

因为 wiki 最怕的不是慢，而是越长越乱。

五，LLM Wiki 最关键的 3 个操作，怎么做才不容易烂尾

Karpathy 说了三个操作：
- ingest
- query
- lint

我觉得这三个词特别重要，因为它们其实定义了这套系统是不是“活的”。

1. Ingest，不只是存进去，而是整合进去

绝大多数人做知识库，最容易把 ingest 变成“存档”。

看到一篇文章，丢进去。保存一个链接。存一个 markdown。然后结束。

这不叫 LLM Wiki，这叫仓库。

真正的 ingest 应该至少包含：
- 读取原始材料
- 提炼关键结论
- 生成一篇 source summary
- 更新相关的主题页
- 更新可能受影响的人物页 / 概念页 / 项目页
- 记录这次 ingest 改了什么
- 更新 index
- 写入 log

也就是说，一篇材料进来，不是多了一个文件，而是可能影响整片知识结构。

这也是为什么 Karpathy 说，一次 ingest 可能改动 10-15 个页面。这个说法非常准确。

一个适合 OpenClaw 的 ingest 流程

比如你给 OpenClaw 发一个链接：

“请把这篇文章纳入我的 LLM Wiki。”

一个理想流程应该是：

  1. 把原文抓到 raw/articles/
  2. 生成 sources/2026-04-14-article-title.md
  3. 更新相关主题页
  4. 更新 index.md
  5. 在 log.md 追加记录
  6. 让你看这次有哪些页面被改动

这样你看到的不是一个“处理完成”提示，而是一套真实发生的知识变化。

2. Query，不只是回答问题，而是把好问题沉淀下来

Karpathy 这里有一个非常值得抄的点。

他认为 query 的结果，有价值时应该反向写回 wiki。

我非常认同。

因为很多真正好的问题，本身就在创造知识结构。

比如：
- OpenClaw 和传统 RAG 最大的差异到底是什么
- 为什么 agent 产品的竞争开始从模型层转向执行系统层
- Karpathy 的 LLM Wiki 和 Obsidian 普通笔记法到底差在哪

这些问题如果只是答完就结束，太可惜了。因为它们本身已经是很好的“比较页”“分析页”“专题页”。

一个很好用的规则

你可以在 schema 里写：

这样 LLM Wiki 就不会只是越存越多的材料库，而会逐渐长出“思考层”。

3. Lint，不做体检，wiki 很快就会失控

这是原文里一个非常强、但很多人第一次读会低估的操作。

lint 不是代码世界才有的事。知识系统一样需要 lint。

你必须定期让 LLM 去做体检：
- 有没有过时观点没更新
- 有没有孤儿页没人链接到
- 有没有概念在很多地方被提到，却没有自己的页面
- 有没有两页之间存在直接冲突
- 有没有新的材料已经推翻旧结论
- 有没有哪几个主题其实该合并或重构了

这一层极其重要，因为它让 wiki 不只是越长越多，而是越长越健康。

我甚至觉得，很多知识系统之所以后来变成垃圾堆，不是因为 ingest 不够多，而是因为根本没有 lint。

六，index.md 和 log.md，为什么这两个文件比你想象得更关键

Karpathy 专门强调了两个特殊文件：
- index.md
- log.md

这不是装饰，这是导航系统。

1. index.md，是内容地图

它不是简单的目录，而是整个 wiki 的路标。

一个好的 index.md 应该告诉 LLM 和你：
- 这个 wiki 里有哪些页面
- 它们分别讲什么
- 哪些是核心页
- 哪些是分类入口

如果 wiki 规模还不大，index 就是最简单有效的“搜索引擎”。

我很认同 Karpathy 的一点：
在 moderate scale 下，不一定要一上来就搞 embedding infra，index 本身就非常能打。

2. log.md，是演化时间线

它的作用不是帮你找内容，而是帮你理解：
- 最近做了什么 ingest
- 哪个问题被分析过
- 哪次 lint 发现了什么
- 这个 wiki 是怎么一步步长出来的

这对于长时间项目太重要了。

尤其是像我们这种会跨多天、多周推进同一主题的人，log 会成为一个非常强的“记忆压缩层”。

你甚至可以用 Karpathy 提到的那种格式：

## [2026-04-14] ingest | Karpathy LLM Wiki
## [2026-04-14] query | LLM Wiki 与传统 RAG 的区别
## [2026-04-15] lint | orphan pages and stale claims

这样不仅人能读，LLM 也很容易 parse。

七，如果你想真的开始搭，最小可行版本该怎么做

这里给一个我认为最务实的 MVP。

第一步，先建目录，不要先想全做完

llm-wiki/
  raw/
    articles/
    notes/
    assets/
  wiki/
    index.md
    log.md
    topics/
    people/
    concepts/
    sources/
  SCHEMA.md

这个结构非常朴素，但足够开始。

第二步，写 SCHEMA.md

至少写清楚：

页面类型

ingest 规则

query 规则

lint 规则

第三步，先选一个小主题开始

不要一上来就想做“我的整个人生知识库”。

最好的起点通常是这几种：
- 一门正在深度研究的主题
- 一本正在读的书
- 一个正在推进的项目
- 一个正在跟踪的行业方向
- 一个准备长期写作的专题

比如你完全可以先做：
- AI Agent 商业化 wiki
- OpenClaw 深度研究 wiki
- 创业判断日志 wiki
- Claude Code 源码阅读 wiki

第四步，先人工参与 ingest，不要急着全自动

Karpathy 原文里我很喜欢的一点，是他明确说自己更喜欢一次 ingest 一个 source，并且保持参与。

这非常对。

因为早期阶段最重要的不是速度，而是你和 LLM 一起校准什么是“这个 wiki 的写法”。

太早全自动，最容易长歪。

第五步，配合 Obsidian 使用

这也是原文里最打动我的一句：

Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

这句非常妙，而且几乎是这个模式最好的心智模型。

一旦想通这一层，整个模式就会顺很多。

八，结合我们自己的情况，最适合先做哪三种 LLM Wiki

如果从理论切回现实，我其实更关心这个模式在我们这里怎么先跑起来。

我会优先推荐这三种。

1. AI / SaaS 行业情报 Wiki

这是最适合我们的。

原始材料来自：
- builder digest
- daily brief
- 博客与文章
- 播客摘要
- 真正赚钱的 AI 产品研究

wiki 层则不断维护：
- 人物页
- 产品页
- 趋势页
- 商业模式页
- 高价值判断页

这会比单纯日报更有复利。

2. OpenClaw / Agent 系统研究 Wiki

这也很适合，因为我们本来就在持续研究：
- OpenClaw 场景
- 多 Agent 协作
- 记忆系统
- MCP 工具接入
- 执行系统与基础设施

如果这些只散在文章和聊天里，后面会越来越难接。做成 wiki，后面无论是写文章、做产品判断，还是对外分享，都会轻很多。

3. 创业判断与项目推进 Wiki

这个方向其实最有潜力。

因为很多创业过程里的关键东西，不是资料，而是不断演化的判断：
- 为什么现在做这个方向
- 为什么当时否掉另一个方向
- 某个项目到底卡在哪
- 哪个风险已经出现过三次
- 哪些原则已经反复证明有效

如果这些东西都能沉淀成结构化 wiki，它对个人和团队都会极其值钱。

九，Karpathy 这个想法最让我兴奋的地方，不是又多了一个知识管理方法，而是它真的让“知识会长大”这件事第一次变得现实

写到这里，我其实最想说的，不是这套模式有多优雅。

而是它终于让我对一件事有了现实感。

过去很多人都说想做“第二大脑”，想做“个人知识库”，想把思考沉淀下来。可绝大多数人最后都卡在同一个地方：

知识库会越来越大，但不会越来越活。

资料越来越多，结构越来越松，连接越来越少，最后变成一个巨大的存档柜。你知道里面有很多好东西，但你已经不太愿意走进去。

Karpathy 这篇 LLM Wiki 的真正力量，是它第一次非常明确地告诉我们：

知识系统之所以死掉，不是因为人不愿意思考，而是因为维护成本太高。

而 LLM 正好可以把这部分维护成本接过去。

它不一定替你做判断本身。
但它可以替你做让判断有地方安放、能被继续调用、能和后续材料不断连接起来的那些繁重工作。

这听上去像一个小变化，但其实不是。

因为一旦这件事成立，知识就不再只是“被保存”，而是开始“被生长”。

而我觉得，这才是 Karpathy 这篇短文里最有后劲的地方。

它不是给了我们一个知识管理新花样。

它给的是一种很久以来大家都想要、但一直没有真正低成本做到的能力：

让你的知识，不只是积累，而是真的会长大。

十，最后一句实话

如果你读完原文以后，最大的感受只是“这个想法很酷”，那你可能只看到了它表面那层。

如果你真正开始把它和自己的工作流连起来，你会发现它最有价值的地方不是酷，而是踏实。

它不是又一个让你短时间更兴奋的 AI 技巧。

它更像一套能陪你长期做研究、做项目、做写作、做判断的慢系统。

而这样的系统，一旦真的跑起来，价值往往不是一天两天能看出来的。

它会在很多个你原本已经习惯遗忘、习惯散掉、习惯重新来过的地方，慢慢把东西留住。

我觉得，这才是 LLM Wiki 最迷人的地方。

它不是替你知道更多。

它是在帮你，让那些你已经认真读过、认真想过、认真做过的东西，不要再轻易消失。