Skills中心

LLM 知识百科

2026-05-22 · Skills中心

LLM 知识百科

Karpathy 的 LLM Wiki：构建/查询互联 Markdown 知识库

Karpathy 的 LLM Wiki

构建并维护一个持久的、具有复利效应的知识库，以互联的 Markdown 文件形式呈现。

基于 Andrej Karpathy 的 LLM Wiki 模式。

与传统的 RAG（每次查询都从头开始重新发现知识）不同，wiki

一次性编译知识并保持其时效性。交叉引用已经存在。

矛盾之处已被标记。综合结果反映了所有已摄入的内容。

分工：人类策划来源并指导分析。代理负责

摘要、交叉引用、归档和维护一致性。

此技能激活时机

当用户执行以下操作时，使用此技能：

要求创建、构建或启动 wiki 或知识库

要求摄入、添加或处理某个来源到其 wiki 中

提出问题，且在配置的路径上存在现有 wiki

要求对其 wiki 进行 lint、审计或健康检查

在研究上下文中引用其 wiki、知识库或"笔记"

Wiki 位置

位置：通过 WIKI_PATH 环境变量设置（例如在 ~/.hermes/.env 中）。

如果未设置，默认为 ~/wiki。


WIKI="${WIKI_PATH:-$HOME/wiki}"

Wiki 只是一个 Markdown 文件目录——可以在 Obsidian、VS Code 或

任何编辑器中打开它。无需数据库，无需特殊工具。

架构说明：三层


wiki/
├── SCHEMA.md           # 约定、结构规则、领域配置
├── index.md            # 带单行摘要的分段内容目录
├── log.md              # 按时间顺序的操作日志（仅追加，每年轮换）
├── raw/                # 第1层：不可变源材料
│   ├── articles/       # 网络文章、剪报
│   ├── papers/         # PDF、arxiv 论文
│   ├── transcripts/    # 会议记录、访谈
│   └── assets/         # 源文件引用的图片、图表
├── entities/           # 第2层：实体页面（人物、组织、产品、模型）
├── concepts/           # 第2层：概念/主题页面
├── comparisons/        # 第2层：并排分析
└── queries/            # 第2层：值得保留的已归档查询结果

第1层 — 原始来源：不可变。代理读取但从不修改这些内容。

第2层 — Wiki：代理拥有的 Markdown 文件。由代理创建、更新和

交叉引用。

第3层 — 模式： SCHEMA.md 定义结构、约定和标签分类法。

恢复现有 Wiki（关键——每会话必做）

当用户拥有现有 wiki 时，在执行任何操作之前务必先熟悉环境：

① 读取 SCHEMA.md——了解领域、约定和标签分类法。

② 读取 index.md——了解存在哪些页面及其摘要。

③ 扫描最近的 log.md——读取最后 20-30 条记录以了解最近的活动。


WIKI="${WIKI_PATH:-$HOME/wiki}"
# 会话开始时熟悉环境
read_file "$WIKI/SCHEMA.md"
read_file "$WIKI/index.md"
read_file "$WIKI/log.md" offset=<最后30行>

只有在熟悉环境之后，才应进行摄入、查询或 lint。这可以防止：

为已存在的实体创建重复页面

遗漏与现有内容的交叉引用

与已记录的工作重复

对于大型 wiki（100+ 页面），在创建任何新内容之前，还应对

当前主题运行快速 search_files。

初始化新 Wiki

当用户要求创建或启动 wiki 时：

确定 wiki 路径（来自 $WIKI_PATH 环境变量，或询问用户；默认为 ~/wiki）

创建上述目录结构

询问用户 wiki 涵盖哪个领域——要具体

编写针对该领域定制的 SCHEMA.md（参见下方模板）

编写带分段标题的初始 index.md

编写带创建条目的初始 log.md

确认 wiki 已就绪，并建议首批要摄入的来源

SCHEMA.md 模板

根据用户的领域进行调整。模式约束代理行为并确保一致性：


# Wiki 模式

## 领域
[本 wiki 涵盖的内容——例如"AI/ML 研究"、"个人健康"、"创业情报"]

## 约定
- 文件名：小写字母、连字符，无空格（例如 `transformer-architecture.md`）
- 每个 wiki 页面以 YAML 前置元数据开头（见下方）
- 使用 `[[wikilinks]]` 在页面之间链接（每页至少 2 个出站链接）
- 更新页面时，始终更新 `updated` 日期
- 每个新页面必须添加到 `index.md` 的正确分段下
- 每个操作必须追加到 `log.md`
- **来源标记：** 在综合了 3 个以上来源的页面上，在段落末尾追加 `^[raw/articles/source-file.md]`，
  该段落的主张来自特定来源。这让读者可以追溯每个主张，
  而无需重新阅读整个原始文件。在单来源页面上可选使用，
  此时 `sources:` 前置元数据已足够。

## 前置元数据

---
title: 页面标题
created: YYYY-MM-DD
updated: YYYY-MM-DD
type: entity | concept | comparison | query | summary
tags: [来自下方的分类法]
sources: [raw/articles/source-name.md]
# 可选质量信号：
confidence: high | medium | low        # 主张得到支持的程度
contested: true                        # 当页面存在未解决的矛盾时设置
contradictions: [other-page-slug]      # 与此页面冲突的其他页面
---

`confidence` 和 `contested` 是可选的，但建议用于主观意见较多或
快速变化的主题。Lint 会列出 `contested: true` 和 `confidence: low` 的页面以供审查，
这样薄弱的主张不会悄然固化为公认的 wiki 事实。

### raw/ 前置元数据

原始来源也获得一个小的 前置元数据块，以便重新摄入时可以检测漂移：

---
source_url: https://example.com/article   # 原始 URL（如适用）
ingested: YYYY-MM-DD
sha256: 
---

`sha256:` 让未来对同一 URL 的重新摄入在内容未更改时跳过处理，
并在内容更改时标记漂移。仅对正文（结束 `---` 之后的所有内容）计算，
而不是前置元数据本身。

## 标签分类法
[为领域定义 10-20 个顶级标签。在使用它们之前先在此添加。]

AI/ML 示例：
- 模型：model, architecture, benchmark, training
- 人物/组织：person, company, lab, open-source
- 技术：optimization, fine-tuning, inference, alignment, data
- 元数据：comparison, timeline, controversy, prediction

规则：页面上的每个标签必须出现在该分类法中。如果需要新标签，
先在此添加，然后再使用。这可以防止标签蔓延。

## 页面阈值
- **创建页面** 当实体/概念出现在 2 个以上来源中，或对某个来源至关重要时
- **添加到现有页面** 当某个来源提及已涵盖的内容时
- **不要创建页面** 对于顺带提及、次要细节或领域之外的事物
- **拆分页面** 当其超过约 200 行时——用交叉链接分解为子主题
- **归档页面** 当其内容完全被取代时——移动到 `_archive/`，从索引中移除

## 实体页面
每个值得注意的实体一个页面。包括：
- 概述 / 它是什么
- 关键事实和日期
- 与其他实体的关系（[[wikilinks]]）
- 来源参考

## 概念页面
每个概念或主题一个页面。包括：
- 定义 / 解释
- 知识的当前状态
- 开放性问题或辩论
- 相关概念（[[wikilinks]]）

## 比较页面
并排分析。包括：
- 正在比较的内容及原因
- 比较维度（优先使用表格格式）
- 结论或综合
- 来源

## 更新策略
当新信息与现有内容冲突时：
1. 检查日期——较新的来源通常取代较旧的来源
2. 如果确实矛盾，用日期和来源注明两种立场
3. 在 前置元数据中标记矛盾：`contradictions: [page-name]`
4. 在 lint 报告中标记以供用户审查

index.md 模板

索引按类型分段。每个条目占一行：wikilink + 摘要。


# Wiki 索引

> 内容目录。每个 wiki 页面按其类型列出，附一行摘要。
> 首先阅读此文件以找到与任何查询相关的页面。
> 最后更新：YYYY-MM-DD | 总页数：N

## 实体


## 概念

## 比较

## 查询

扩展规则：当任何分段超过 50 个条目时，按首字母或子域将其拆分为子分段。

当索引总共超过 200 个条目时，创建一个 _meta/topic-map.md，

按主题对页面进行分组，以便更快导航。

log.md 模板


# Wiki 日志

> 所有 wiki 操作的时间顺序记录。仅追加。
> 格式：`## [YYYY-MM-DD] action | subject`
> 操作：ingest, update, query, lint, create, archive, delete
> 当此文件超过 500 个条目时，轮换：重命名为 log-YYYY.md，重新开始。

## [YYYY-MM-DD] create | Wiki 初始化
- 领域：[domain]
- 已创建带 SCHEMA.md、index.md、log.md 的结构

核心操作

1. 摄入 (Ingest)

当用户提供来源（URL、文件、粘贴文本）时，将其整合到 wiki 中：

① 捕获原始来源：

URL → 使用 web_extract 获取 Markdown，保存到 raw/articles/

PDF → 使用 web_extract（可处理 PDF），保存到 raw/papers/

粘贴文本 → 保存到适当的 raw/ 子目录

描述性地命名文件：raw/articles/karpathy-llm-wiki-2026.md

添加原始前置元数据（source_url、ingested、正文部分的 sha256）。

重新摄入同一 URL 时：重新计算 sha256，与存储的值比较——

如果相同则跳过，如果不同则标记漂移并更新。这成本足够低，

可以在每次重新摄入时执行，并能捕获静默的来源更改。

② 与用户讨论要点——什么有趣，对领域有什么重要性。

（在自动化/定时任务上下文中跳过此步骤——直接继续。）

③ 检查已存在的内容——搜索 index.md 并使用 search_files 查找

提及的实体/概念的现有页面。这是不断增长的 wiki 和

重复堆积之间的区别。

④ 编写或更新 wiki 页面：

新实体/概念：仅在满足 SCHEMA.md 中的页面阈值时才创建页面

（2 个以上来源提及，或对某个来源至关重要）

现有页面：添加新信息，更新事实，更新 updated 日期。

当新信息与现有内容冲突时，遵循更新策略。

交叉引用：每个新页面或更新页面必须通过 [[wikilinks]] 链接到至少 2 个其他

页面。检查现有页面是否链接回来。

标签：仅使用 SCHEMA.md 分类法中的标签

来源标记：在综合了 3 个以上来源的页面上，将 ^[raw/articles/source.md]

标记追加到主张可追溯至特定来源的段落。

置信度：对于主观意见较多、快速变化或单来源的主张，在前置元数据中设置

confidence: medium 或 low。不要标记 high，除非

该主张在多个来源中得到充分支持。

⑤ 更新导航：

将新页面按字母顺序添加到 index.md 的正确分段下

更新索引头部中的"总页数"计数和"最后更新"日期

追加到 log.md：## [YYYY-MM-DD] ingest | 来源标题

在日志条目中列出创建或更新的每个文件

⑥ 报告更改内容——向用户列出创建或更新的每个文件。

单个来源可能触发跨 5-15 个 wiki 页面的更新。这很正常，

也是期望的效果——这就是复利效应。

2. 查询 (Query)

当用户询问有关 wiki 领域的问题时：

① 读取 index.md以识别相关页面。

② 对于 100+ 页面的 wiki，还对所有的 .md 文件使用 search_files

搜索关键术语——仅索引可能会遗漏相关内容。

③ 使用 read_file 读取相关页面。

④ 从编译后的知识综合答案。引用你参考的 wiki 页面：

"基于 [[page-a]] 和 [[page-b]]..."

⑤ 将有价值的答案归档——如果答案是实质性的比较、

深度探讨或新颖的综合，在 queries/ 或 comparisons/ 中创建一个页面。

不要归档简单的查找——仅归档那些重新推导会很痛苦的答案。

⑥ 使用查询和更新日志更新 log.md。

3. Lint

当用户要求 lint、健康检查或审计 wiki 时：

① 孤立页面：查找没有其他页面传入 [[wikilinks]] 的页面。


# 为此使用 execute_code——跨所有 wiki 页面进行程序化扫描
import os, re
from collections import defaultdict
wiki = ""
# 扫描 entities/、concepts/、comparisons/、queries/ 中的所有 .md 文件
# 提取所有 [[wikilinks]]——构建入站链接地图
# 零入站链接的页面是孤立页面

② 损坏的 wikilinks：查找指向不存在页面的 [[links]]。

③ 索引完整性：每个 wiki 页面应出现在 index.md 中。比较

文件系统与索引条目。

④ 前置元数据验证：每个 wiki 页面必须包含所有必填字段

（title、created、updated、type、tags、sources）。标签必须位于分类法中。

⑤ 陈旧内容：页面的 updated 日期比提及相同实体的最

新来源旧 90 天以上。

⑥ 矛盾：关于同一主题但主张冲突的页面。查找

共享标签/实体但陈述不同事实的页面。列出所有

带有 contested: true 或 contradictions: 前置元数据的页面以供用户审查。

⑦ 质量信号：列出带有 confidence: low 的页面，以及任何仅引用

单个来源但未设置置信度字段的页面——这些是需要

找到佐证或降级为 confidence: medium 的候选者。

⑧ 来源漂移：对于 raw/ 中每个带有 sha256: 前置元数据的文件，重新计算

哈希并标记不匹配。不匹配表示原始文件被编辑过

（不应该发生——raw/ 是不可变的）或从此后已

更改的 URL 摄入。不是严重错误，但值得报告。

⑨ 页面大小：标记超过 200 行的页面——拆分候选者。

⑩ 标签审计：列出所有正在使用的标签，标记任何不在 SCHEMA.md 分类法中的标签。

⑪ 日志轮换：如果 log.md 超过 500 个条目，对其进行轮换。

⑫ 报告发现，附上具体的文件路径和建议操作，按严重性分组

（损坏的链接 > 孤立页面 > 来源漂移 > 争议页面 > 陈旧内容 > 样式问题）。

⑬ 追加到 log.md： ## [YYYY-MM-DD] lint | 发现 N 个问题

使用 Wiki

搜索


# 按内容查找页面
search_files "transformer" path="$WIKI" file_glob="*.md"

# 按文件名查找页面
search_files "*.md" target="files" path="$WIKI"

# 按标签查找页面
search_files "tags:.*alignment" path="$WIKI" file_glob="*.md"

# 最近活动
read_file "$WIKI/log.md" offset=<最后20行>

批量摄入

一次摄入多个来源时，批量更新：

先读取所有来源

识别所有来源中的全部实体和概念

对它们全部检查现有页面（一次搜索，而非 N 次）

在一次传递中创建/更新页面（避免冗余更新）

最后一次性更新 index.md

写入涵盖该批次的单个日志条目

归档

当内容完全被取代或领域范围发生变化时：

如果 _archive/ 目录不存在，则创建它

将页面移动到 _archive/ 并保留其原始路径（例如 _archive/entities/old-page.md）

从 index.md 中移除

更新链接到它的所有页面——用纯文本 + "(已归档)" 替换 wikilink

记录归档操作

Obsidian 集成

Wiki 目录可以开箱即用地作为 Obsidian 库使用：

[[wikilinks]] 呈现为可点击的链接

图谱视图可视化知识网络

YAML 前置元数据为 Dataview 查询提供支持

raw/assets/ 文件夹保存通过 ![[image.png]] 引用的图像

为获得最佳效果：

将 Obsidian 的附件文件夹设置为 raw/assets/

在 Obsidian 设置中启用"Wikilinks"（默认通常已启用）

安装 Dataview 插件以使用诸如 TABLE tags FROM "entities" WHERE contains(tags, "company") 的查询

如果与此技能一起使用 Obsidian 技能，请将 OBSIDIAN_VAULT_PATH 设置为与

wiki 路径相同的目录。

Obsidian Headless（服务器和无头机器）

在没有显示器的机器上，使用 obsidian-headless 代替桌面应用程序。

它通过 Obsidian Sync 同步库，无需 GUI——非常适合在服务器上运行、

写入 wiki，同时在另一台设备上通过 Obsidian 桌面版读取的代理。

设置：


# 需要 Node.js 22+
npm install -g obsidian-headless

# 登录（需要带有 Sync 订阅的 Obsidian 帐户）
ob login --email  --password ''

# 为 wiki 创建远程库
ob sync-create-remote --name "LLM Wiki"

# 将 wiki 目录连接到库
cd ~/wiki
ob sync-setup --vault ""

# 初始同步
ob sync

# 连续同步（前台——后台使用 systemd）
ob sync --continuous

通过 systemd 实现连续后台同步：


# ~/.config/systemd/user/obsidian-wiki-sync.service
[Unit]
Description=Obsidian LLM Wiki 同步
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/path/to/ob sync --continuous
WorkingDirectory=/home/user/wiki
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target


systemctl --user daemon-reload
systemctl --user enable --now obsidian-wiki-sync
# 启用 linger 以便同步在注销后继续：
sudo loginctl enable-linger $USER

这让代理可以在服务器上写入 ~/wiki，而您可以在笔记本电脑/手机上的

Obsidian 中浏览同一个库——更改在几秒内出现。

常见陷阱

永远不要修改 raw/ 中的文件——来源是不可变的。更正内容进入 wiki 页面。

始终先熟悉环境——在新会话中执行任何操作之前，先读取 SCHEMA + 索引 + 最近日志。

跳过此步骤会导致重复和遗漏交叉引用。

始终更新 index.md 和 log.md——跳过此步骤会使 wiki 退化。这些是

导航骨干。

不要为顺带提及创建页面——遵循 SCHEMA.md 中的页面阈值。一个名称

仅在脚注中出现一次并不保证有资格获得实体页面。

不要创建没有交叉引用的页面——孤立的页面是不可见的。每个页面必须

链接到至少 2 个其他页面。

前置元数据是必需的——它支持搜索、过滤和陈旧性检测。

标签必须来自分类法——自由格式的标签会退化为噪音。先将新标签添加到 SCHEMA.md，

然后再使用它们。

保持页面可扫描——wiki 页面应能在 30 秒内读完。拆分超过

200 行的页面。将详细分析移至专用的深度探讨页面。

在大量更新之前询问——如果摄入会涉及 10 个以上现有页面，先与用户确认

范围。

轮换日志——当 log.md 超过 500 个条目时，将其重命名为 log-YYYY.md 并重新开始。

代理应在 lint 期间检查日志大小。

显式处理矛盾——不要静默覆盖。用日期注明两种主张，

标记在前置元数据中，标记以供用户审查。

LLM 知识百科

LLM 知识百科

Karpathy 的 LLM Wiki

此技能激活时机

Wiki 位置

架构说明：三层

恢复现有 Wiki（关键——每会话必做）

初始化新 Wiki

SCHEMA.md 模板

index.md 模板

log.md 模板

核心操作

1. 摄入 (Ingest)

2. 查询 (Query)

3. Lint

使用 Wiki

搜索

批量摄入

归档

Obsidian 集成

Obsidian Headless（服务器和无头机器）

常见陷阱

相关工具

评论区

发表评论取消回复

欢迎回来

创建账号

LLM 知识百科

LLM 知识百科

Karpathy 的 LLM Wiki

此技能激活时机

Wiki 位置

架构说明：三层

恢复现有 Wiki（关键——每会话必做）

初始化新 Wiki

SCHEMA.md 模板

index.md 模板

log.md 模板

核心操作

1. 摄入 (Ingest)

2. 查询 (Query)

3. Lint

使用 Wiki

搜索

批量摄入

归档

Obsidian 集成

Obsidian Headless（服务器和无头机器）

常见陷阱

相关工具

评论区

发表评论 取消回复

发表评论取消回复