Karpathy LLM Wiki 进度条：需要补充的方向

有类型的链接和扩展限制

Andrej Karpathy 的 LLM Wiki 模式本月风靡一时。5000+ stars、3700+ forks、数十种实现。核心洞察是对的：别在每次查询时重新推导知识。把它编译一次成结构化的 wiki。让 LLM 做那些让人类放弃知识库的簿记工作。

如果你还没读过，这个模式的流程是：原始资源放进目录，LLM 处理它们成相互链接的 markdown 页面，Obsidian 充当查看器。三层、三个操作（摄入、查询、检查），LLM 维护一切。

这是个不错的起点。但如果你尝试在几百条笔记以外运行这个模式，你可能已经撞到了墙。有三个结构性的缺陷在规模扩大时会崩溃，这些不是你能用更好的 prompt 或更花哨的索引文件修复的。

以下是缺少的东西以及如何修复它。

缺陷 1：你的链接没有意义

在 Karpathy 风格的 wiki 上打开 Obsidian 的图表视图。你看到什么？一个相同灰线的网络。每个连接看起来都一样，因为每个 [[wikilink]] 只携带一位信息："这两条笔记是连接的"。

当 Karpathy 谈论 LLM "注意新数据与旧声明矛盾的地方" 和 "标记矛盾" 时，他在描述语义关系。但底层的链接格式无法表达它们中的任何一个。[[Note A]] 不会告诉你 Note A 是支持、矛盾、取代还是由当前笔记引起的。其意义隐藏在链接周围的散文中，对 Obsidian 生态中的任何工具都不可见。

这很重要，因为编译 wiki 的整个目的是让结构为你工作。如果你的图表无法区分 "这取代了那个" 和 "这与那个矛盾"，你就把一些最有价值的信息留在了非结构化的文本中，这正是你试图解决的问题。

修复方法：在 wikilink 内使用类型关系

obsidian-wikilink-types 使用 @ 语法向标准 Obsidian wikilink 添加语义关系类型：

[[Previous Analysis|The new research @supersedes the previous analysis]]
[[Redis Paper|This @supports the caching architecture in @references the Redis paper]]

在 wikilink 别名中键入 @，你会得到一个包含 24 种关系类型的自动完成下拉菜单：supersedes、contradicts、causes、supports、evolution_of、prerequisite_for 等。

保存时，插件自动将匹配的类型同步到 YAML 前置数据：

---
supersedes:
  - "[[Previous Analysis]]"
supports:
  - "[[Redis Paper]]"
references:
  - "[[Redis Paper]]"
---

就是这样。标准 YAML 前置数据。Dataview 可以查询它。什么都不会破坏。

@ 语法被刻意选择：它不与任何现有的 Obsidian 语法冲突（^ 是块引用，:: 是 Dataview 内联字段），且只在前面有空格或出现在 | 管道右边时触发自动完成。你显示文本中的 john@example.com 被保留原样。只有配置的关系类型生成前置数据。@monkeyballs 只是显示文本。

通过 BRAT 使用 penfieldlabs/obsidian-wikilink-types 安装。

有了类型链接，你的库从相同连接的纠缠变成可查询的知识图。你可以写 Dataview 查询，比如 "给我看所有与我当前假设矛盾的东西"。你可以追踪因果链。你可以一眼看出哪些笔记已被取代，哪些是最新的。

这是 Karpathy 的模式需要但没有的：承载意义的链接。

缺陷 2：你不应该手动输入每个关系

有类型链接的 wiki 比没有更有用。但在每条笔记上手动输入 @supersedes 和 @contradicts 很繁琐，你会错过不明显的连接。

LLM Wiki 的整个前提是 LLM 做簿记。那么让它也发现关系。

修复方法：AI 发现的类型关系

Vault Linker skill 与插件在同一仓库中发布。这是 AI 代理（Claude Code、OpenClaw 或任何可以读写文件的东西）的 skill 规范，分析你的库并发现笔记之间的关系。

用加载了 Vault Linker skill 的 AI 代理指向你的库

代理读取你的笔记并识别连接："这条笔记取代了那条。这条笔记与那个声明矛盾。这是由那个决定引起的。"

代理用 Wikilink Types 格式编写关系：添加 @supersedes、@contradicts 等到 wikilink，并同步前置数据

你审查并批准

人类保持在循环中以做判断。AI 做读取数百条笔记和发现连接的繁重工作，这些连接你永远不会手动发现。

LLM Wiki 模式说 LLM 应该做所有的 "总结、交叉引用、归档和簿记"。类型链接给 LLM 一个交叉引用的词汇。Vault Linker skill 给它实际执行的工作流程。

自主模式：一夜之间链接整个库

上述 skill 是交互式的：代理发现，你批准。但如果你有 500 条笔记，想在一次通过中链接整个东西呢？

该仓库包含两个 prompt，设计为协同工作：

Autonomous Vault Linking 是构建阶段。你给你的代理一个库路径，就可以走开。代理创建一个 git 分支，调查库，将笔记分类为中枢或分支，然后按优先级顺序处理它们：中枢到中枢关系优先（最高价值的连接），然后分支到中枢（大部分工作），然后横向分支到分支连接。它每 20-50 条笔记提交一次，写一个链接日志，包含统计数据和置信度，从不触及你的主分支。如果你并行运行多个代理（比如每个文件夹一个），prompt 包括协调规则：每个代理只写入其分配的笔记，在链接前验证目标文件存在，并记录任何必须跳过的内容。

Verify and Repair 是清理阶段。在构建完成后，你在同一分支上运行它。它构建完整的文件索引，扫描每条笔记以查找断开的链接（正确排除代码块和标注），修复能修复的（近似匹配解析、平行代理伪影移除），检查前置数据和内联 @type 链接一致，移除重复项，分类孤立笔记，并验证所有 YAML。输出是一个验证报告，告诉你确切地修复了什么以及什么仍需要人类判断。只有在验证通过后，你才合并。

两阶段设计是刻意的：构建阶段针对吞吐量优化，验证阶段针对正确性优化。两者都是幂等的。在已链接的库上重新运行会产生零变化。

缺陷 3：你的知识被困在一台机器上

这是大多数实现未解决的缺陷。

LLM Wiki 将所有内容存储为纯 markdown。你可以用 git 同步这些文件，指向多个工具指向同一目录，从任何地方访问它们。文件不是问题。

代理的理解是。

每次你开始新会话时，LLM 读取你的索引文件，重新解析 wiki 结构，重新发现它上次会话已知的内容。内存中没有持久图。无法查询 "什么与我关于 X 的假设矛盾？" 而不让 LLM 重新读取每个相关页面。没有可以在数百条笔记中遍历类型关系的图遍历。index.md 目录在小规模下工作，但它是平面文件，不是查询引擎。

Git 给你文件可移植性。它没有给你的是代理级内存、关系感知搜索或任何工具无需从头重新解析一切就能查询的持久知识图。

修复方法：持久知识图后端

Penfield 是 AI 代理的持久内存和知识图系统。它在通过 MCP（模型上下文协议）从任何兼容客户端访问的后端中存储记忆、制品和类型关系。

相关功能：

混合搜索：BM25（关键词）+ 向量（语义）+ 图遍历，融合在一起。不是 "选一个"。全部三个，加权并合并。

类型关系：wikilink-types 中的相同 24 种关系类型对 Penfield 的图是本地的。supersedes、contradicts、causes，全部。词汇完全匹配。

跨平台访问：从 Claude Code、Claude.ai、OpenClaw、Cursor、Gemini CLI 或任何其他会说 MCP 的东西连接。相同知识图，相同关系，无论你使用哪个工具。

跨会话持久性：当你关闭标签页时图不会消失。记忆、关系和制品无限期存活。开始新会话并从你离开的地方继续。

管道：Obsidian 到 Penfield

penfield-import 是桥梁。它读取 Obsidian 库（或任何 markdown 文件集合）并将所有内容作为记忆、关系和制品导入 Penfield。

该工具用七个阶段和崩溃安全检查点运行：

Parse：读取所有 .md 和 .txt 文件，提取 YAML 前置数据和类型关系

Memories：每条笔记创建一个 Penfield 记忆

Artifacts：为超过 10K 字符内存限制的笔记上传完整内容

Exported Artifacts：上传预先存在的制品文件

Documents：上传文档（PDF、代码文件等）

Relationships：批量创建记忆之间的关系，批次为 100

Verify：确认导入计数匹配

# Install
pip install .

# Authenticate (opens browser, takes 2 seconds)
penfield-import --login

# Preview what will be imported
penfield-import /path/to/your/vault --dry-run

# Run the import
penfield-import /path/to/your/vault

如果你的库有来自 obsidian-wikilink-types 的类型关系，它们作为图边进入 Penfield。如果没有，你仍然获得所有笔记作为可搜索的记忆。类型链接使导入更丰富，但不是必需的。

我们已经以超过 4000 条笔记和超过 20000 条关系在单个自主运行中导入的规模运行了这个。检查点系统意味着如果某些东西在阶段 5 崩溃，它从阶段 5 恢复，而不是从头开始。

完整管道

以下是完整工作流程的样子，无论你是升级现有库还是从头开始：

路径 A：你已经有一个 Obsidian 库

在你的库中安装 obsidian-wikilink-types

用 Claude Code 或 OpenClaw 运行 Vault Linker skill，在你现有的笔记中发现关系

审查并批准 AI 建议的关系

运行 penfield-import 将所有内容推送到 Penfield

从任何 MCP 兼容的 AI 工具，在任何设备上访问你的知识

路径 B：从 LLM Wiki 模式开始全新

遵循 Karpathy 的模式：收集资源，让 LLM 编译一个 wiki

但从一开始就使用 obsidian-wikilink-types。当 LLM 创建交叉引用时，让它使用 @ 语法，所以关系从一开始就是类型化的

定期运行 Vault Linker skill，抓住 LLM 错过的关系

当你的 wiki 足够丰富时，导入 Penfield 以获得持久的、跨平台的访问

你获得的对比你拥有的

本文提到的所有内容现在都可用：

obsidian-wikilink-types：Obsidian 插件。wikilink 中的类型 @ 关系，自动同步到 YAML 前置数据。包括 AI 发现关系的 Vault Linker skill。AGPL-3.0。

penfield-import：Obsidian 库和其他 markdown 集合的导入工具。七阶段管道，带崩溃安全检查点。AGPL-3.0。

Penfield：AI 代理的持久内存和知识图。免费试用在 portal.penfield.app/sign-up。MCP 服务器设置在 github.com/penfieldlabs/penfield-mcp。

Karpathy 的 LLM Wiki 模式是坚实的基础。类型关系、AI 发现的连接和持久后端是把它从聪明笔记记录技巧变成实际上复合的知识系统的东西。

如果你有问题或想贡献，在上述任何仓库上开一个 issue，或在 @penfieldlabs 找到我们。

查看后续文章：We Fixed Karpathy's LLM Wiki - PENgram Is the Typed Knowledge Graph Pipeline Everyone Asked For