llm-wiki

Karpathy 的 LLM Wiki

将知识整理成相互链接的 Markdown 文件，构建并维护一个持久、不断积累的知识库。 基于 Andrej Karpathy 的 LLM Wiki 模式。

与传统 RAG（每次查询都从头重新发现知识）不同，Wiki 只需编译一次知识，并持续更新。交叉引用已经就位。 矛盾之处已经标出。综合分析会反映所有已摄取的内容。

分工： 人负责整理来源并指导分析。Agent 负责总结、交叉引用、归档并维护一致性。

此技能的触发条件

在用户出现以下需求时使用此技能：

• 想研究某个主题（如果尚无 Wiki，则自动创建 Wiki，然后继续研究）
• 要求创建、构建、启动或规划新的 Wiki、笔记系统或知识库
• 要求将某个来源摄取、添加或处理到其 Wiki 中
• 提出问题，且已有 Wiki
• 要求检查、审计或健康检查其 Wiki
• 在研究语境中提及其 Wiki、知识库或“笔记”

Wiki 是研究基础设施，而不是最终目标。 用户想要的是研究结果；Wiki 是让研究不断积累并持久保存的机制。 当用户说“帮我研究 X”，而又没有 Wiki 时，请创建 Wiki 并继续研究。

Wiki 位置

Wiki 只是一个 Markdown 文件目录——可以用 Obsidian、VS Code 或 任何编辑器打开。无需数据库，也不需要特殊工具。

路径解析

1. 用户指定路径——直接使用。
2. 未提供路径——分析上下文并提出路径建议：
   • 用户在研究什么？什么样的目录名适合这个主题？
   • 当前工作目录（CWD）的目录结构是什么样的？是否有现有目录体现了命名惯例？
   • 提出 2-3 个符合上下文的选项，然后让用户确认或提供自己的路径。
3. 绝不扫描 ~/——不要搜索主目录来查找现有 Wiki。
4. 绝不假设默认路径——始终明确解析路径。

User provides path → use it
    ↓ (no path)
Analyze context (topic, CWD structure, existing dirs)
    ↓
Suggest 2-3 fitting options → user confirms or gives own path
    ↓
Use confirmed path for all subsequent operations

架构：三层

wiki/
├── SCHEMA.md           # Conventions, structure rules, domain config
├── index.md            # Global catalog: topics + cross-topic pages
├── log.md              # Chronological action log (append-only, rotated at 500 entries)
├── raw/                # Layer 1: Immutable source material
│   ├── articles/       # Web articles, clippings
│   ├── papers/         # PDFs, arxiv papers
│   ├── transcripts/    # Meeting notes, interviews
│   └── assets/         # Images, diagrams referenced by sources
├── topics/             # Layer 2: Per-research-topic grouping
│   ├── {topic-slug}/
│   │   ├── concepts/   # Concepts specific to this topic
│   │   ├── entities/   # Entities specific to this topic
│   │   ├── comparisons/ # Comparisons specific to this topic
│   │   └── index.md    # Topic-level catalog
│   └── ...
├── concepts/           # Layer 2: Cross-topic concept pages
├── entities/           # Layer 2: Cross-topic entity pages
├── comparisons/        # Layer 2: Side-by-side analyses
└── queries/            # Layer 2: Filed query results worth keeping

第 1 层——原始来源： 不可变。Agent 可以读取，但绝不修改。 第 2 层——Wiki： 由 Agent 管理的 Markdown 文件。由 Agent 创建、更新并交叉引用。 按研究主题组织。 第 3 层——架构规范： SCHEMA.md 定义结构、惯例和标签分类体系。

主题分组规则

每个研究主题都在 topics/ 下拥有自己的子目录。摄取内容时：

• 单主题页面（仅与一个研究领域相关）→ topics/{topic}/concepts/、topics/{topic}/entities/ 或 topics/{topic}/comparisons/
• 跨主题页面（与 2 个或更多研究领域相关）→ 全局 concepts/、entities/ 或 comparisons/
• 主题页面使用 [[wikilink]] 引用全局页面，反之亦然

判断标准： 新实体或概念出现在来源中时，检查它是否已在其他主题中被引用。若是 → 全局。若否 → 放在当前主题中。

两级索引

• 全局 index.md——列出所有研究主题（链接到各自的索引）以及跨主题页面
• 主题 index.md——列出该主题中的所有页面

笔记规范（Zettelkasten）

Wiki 页面遵循 Zettelkasten（卡片盒笔记法）规范——完整方法请参阅 zettelkasten 技能。对应关系如下：

• 概念页和实体页是卡片——一页 = 一个独立的想法/实体。 按想法数量拆分，而不只是看行数。
• 全局/主题 index.md 是结构笔记——用于导航，不适用原子性要求。结构笔记的作用完全由两级索引承担：不要在 wiki 中创建单独的结构笔记文件。例外：拆分后留下的页面（“摘要 + 链接”，Zettelkasten 拆分流程第 4 步）是小型概念类页面，不违反结构笔记规则。
• 比较页和查询页是综合笔记——它们用于组合卡片，因此不适用原子性要求，但链接规则仍然适用。在综合页中产生且能独立成立的想法必须提升为概念页（参见页面阈值）——不得让综合页成为逃避原子性要求的避风港。
• raw/ 承担文献笔记的作用——来源保持不变；wiki 页面用自己的措辞重述观点，并注明出处。

**每次创建或更新页面时，都要在写入前执行此检查清单。**包含完整拆分标准和案例的权威版本：zettelkasten 技能（references/02-split-and-checklist.md）；技能不可用时，以以下核心规则为准：

1. 原子性——此次新增内容是否是一个单一想法（实体页：一个实体）？
2. 拆分判断——符合任一条件时就拆分：标题需要用“和”才能涵盖内容；某段内容可以脱离上下文独立引用；页面回答了多个问题；不同部分的更新频率不同；入站链接无法明确指出它们指向哪一点。若各部分会失去自成一体的特性、始终只会一起引用，或仅仅是同一想法的改述或示例，则不要拆分。长度（约 200 行）是应执行这些标准的警示，而不是拆分的理由。
3. 重复与冲突检查——先搜索。已有对应想法 → 更新该页面。信息冲突 → 不要合并覆盖；遵循更新政策（记录双方观点，标记 contradictions/contested，并双向链接）。
4. 链接——在文本提及相关术语的位置添加链接（1–2 个实际出站链接）；文本中未自然提及的关系放在带标签的末尾章节；检查被链接的页面是否需要添加反向链接。编辑反向链接不会递归触发检查：修复反向链接不会触发对该页面运行检查清单。
5. 结构/索引——在主题/全局索引中新增或更新该页面对应的行。
6. 自成一体——不依赖来源上下文，页面也能独立成立。
7. 用自己的措辞——重述，不要粘贴；注明出处。

这是每次写入时都要遵循的规范，而不是 lint 阶段的清理工作。

**遵从原则：**此规范适用于 llm-wiki wiki。若在非 llm-wiki 的笔记仓库中工作（没有 SCHEMA.md/index.md），请遵循该仓库自身的惯例——与 zettelkasten 技能中的“沿用现场”原则一致。

恢复现有 Wiki（关键——每次会话都要执行）

当用户已有 Wiki 时，始终先了解其情况，再进行任何操作：

① 阅读 SCHEMA.md——了解领域、约定和标签分类体系。 ② 阅读 index.md——了解有哪些页面及其摘要。 ③ 浏览近期的 log.md——阅读最近 20-30 条记录，了解近期活动。 ④ 快速一致性检查（开销低，可在问题累积前发现偏差）： 将实际页面数与索引标题中的“总页面数”进行比较；并 抽查 Wiki 的 SCHEMA.md，确认其中是否存在已被当前技能规范取代的规则 （例如，将“在 200 行处分拆”作为判断标准、“至少 2 个链接”的要求，以及缺少 比较/查询豁免条款）。如果任一项检查未通过，建议先运行 lint 或更新 SCHEMA.md，再开始写入。

# Orientation reads at session start (replace <wiki> with the resolved path)
read_file "<wiki>/SCHEMA.md"
read_file "<wiki>/index.md"
read_file "<wiki>/log.md" offset=<last 30 lines>

只有完成初步了解后，才能摄取、查询或运行 lint。这可以避免：

• 为已有实体创建重复页面
• 遗漏指向现有内容的交叉引用
• 与架构约定相矛盾
• 重复已记录的工作

对于大型 Wiki（100 个以上页面），创建新内容前，还要针对相关主题快速运行一次 search_files。

初始化新 Wiki

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

1. 确定 Wiki 路径（参见上文“路径解析”）
2. 创建上述目录结构
3. 询问用户 Wiki 涵盖的领域——具体说明
4. 询问用户计划研究的主题（据此创建 topics/ 子目录）
5. 编写针对该领域定制的 SCHEMA.md（参见下方模板）
6. 编写初始 index.md，列出主题
7. 编写初始 log.md，记录创建条目
8. 确认 Wiki 已就绪，并建议首先摄取哪些来源

SCHEMA.md 模板

根据用户的领域进行调整。架构会约束 Agent 的行为并确保一致性：

# Wiki Schema

## Domain
[What this wiki covers — e.g., "AI/ML research", "personal health", "startup intelligence"]

## Topics
[List research topics. Each gets a subdirectory under `topics/`.]
- topic-slug: [description]
- topic-slug: [description]

## Topic Grouping Rules
- Each research topic = `topics/{topic-slug}/` with its own `concepts/`, `entities/`, `comparisons/`, `index.md`
- Only appears in one topic → place in that topic's subdirectory
- Appears in 2+ topics → place in global `concepts/` or `entities/`
- When unsure, check existing pages across topics before placing
- Cross-topic pages should link back to all relevant topics via `[[wikilink]]`

## Conventions
- **Markdown formatting:** Wiki pages use Obsidian Flavored Markdown. For wikilinks, embeds, callouts, frontmatter properties, and other Obsidian-specific syntax, refer to the `obsidian-markdown` skill.
- **Academic sources:** For arXiv paper search, Semantic Scholar citations, and BibTeX generation, refer to the `arxiv` skill.
- **Note discipline:** Every page write runs the full seven-item Zettelkasten change checklist (atomicity, split, duplicate, links, structure/index, self-contained, own words) — refer to the `zettelkasten` skill for split criteria and linking rules.
- File names: title as filename — English content: lowercase, hyphens, no spaces (e.g., `transformer-architecture.md`); Chinese content: use the Chinese title directly (e.g., `間隔重複比集中複習有效.md`), per the `zettelkasten` skill's naming convention
- Every wiki page starts with YAML frontmatter (see below)
- Use `[[wikilinks]]` to link between pages (at least 1-2 real outbound links per page — link where the text mentions them, don't pad to hit a quota)
- When updating a page, always bump the `updated` date
- Every new page must be added to `index.md` under the correct section
- Every action must be appended to `log.md`
- **Provenance markers:** On pages that synthesize 3+ sources, append `^[raw/articles/source-file.md]`
  at the end of paragraphs whose claims come from a specific source. This lets a reader trace each
  claim back without re-reading the whole raw file. Optional on single-source pages where the
  `sources:` frontmatter is enough.

## Frontmatter
  ```yaml
  ---
  title: Page Title
  created: YYYY-MM-DD
  updated: YYYY-MM-DD
  type: entity | concept | comparison | query
  tags: [from taxonomy below]
  sources: [raw/articles/source-name.md]
  # Optional quality signals:
  confidence: high | medium | low        # how well-supported the claims are
  contested: true                        # set when the page has unresolved contradictions
  contradictions: [other-page-slug]      # pages this one conflicts with
  ---

confidence 和 contested 为可选项，但对于观点较多或变化迅速的主题，建议使用。Lint 会标记 contested: true 和 confidence: low 的页面以供审核，避免薄弱论断悄然固化为 Wiki 中公认的事实。

类型治理：添加新的 type 值时，必须同时具备以下三项——一行定义、标题约定和 lint 映射。切勿只添加枚举值。

raw/ Frontmatter

原始来源也需要添加一个简短的 frontmatter 块，以便重新摄取时检测变动：

---
source_url: https://example.com/article   # original URL, if applicable
ingested: YYYY-MM-DD
sha256: <hex digest of the raw content below the frontmatter>
---

sha256: 可让之后对同一 URL 重新摄取时，在内容未变的情况下跳过处理；若内容已更改，则标记出变化。仅对正文计算哈希（即结束的 --- 之后的所有内容），不要对 frontmatter 本身计算。

标签分类体系

[为该领域定义 10-20 个顶级标签。使用新标签前，先在此处添加。]

AI/ML 示例：

• 模型：model、architecture、benchmark、training
• 人员/组织：person、company、lab、open-source
• 技术：optimization、fine-tuning、inference、alignment、data
• 元信息：comparison、timeline、controversy、prediction

规则：页面上的每个标签都必须出现在此分类体系中。如需新标签，先在此处添加，再使用该标签。这样可以避免标签泛滥。

页面阈值

• 当某个实体／概念出现在 2 个或更多来源中，或是某个来源的核心内容时，创建页面
• 当来源提及已有内容时，添加到现有页面
• 不要为一带而过的提及、次要细节或领域外的内容创建页面
• 提升综合分析中产生的观点——当比较／查询页面得出的主张本身具有独立价值（某种机制、可泛化的结论）时，为其创建概念页面，并在原处链接；Wiki 内部的内容也计入页面创建依据，不仅限于来源中的出现次数
• 当页面涵盖 2 个或更多不同观点时拆分页面（Zettelkasten 原子性原则——参见 zettelkasten 技能中的拆分标准）——拆分为原子页面，并添加交叉链接。篇幅长只是警示，不是判断标准：对超过约 200 行的页面执行拆分标准，但涵盖单一观点的长页面应保持完整。比较、查询和索引页面不受原子性要求限制
• 当页面内容已完全过时时，将页面归档——移至 _archive/，并从索引中移除

实体页面

每个值得关注的实体创建一个页面。包括：

• 概述／实体介绍
• 关键事实和日期
• 与其他实体的关系（[[wikilinks]]）
• 来源引用

概念页面

每个概念或主题创建一个页面。包括：

• 定义／说明
• 当前认知
• 未决问题或争议
• 相关概念（[[wikilinks]]）

比较页面

并列分析。包括：

• 比较对象及比较原因
• 比较维度（优先使用表格）
• 结论或综合分析
• 来源

更新政策

当新信息与现有内容冲突时：

1. 检查日期——较新的来源通常优先于较旧的来源
2. 如果确实存在矛盾，注明双方立场及日期和来源
3. 在 frontmatter 中标记矛盾：contradictions: [page-name]
4. 在 lint 报告中标记，供用户审核
5. 当矛盾得到解决（用户裁定或决定性来源）：更新两个页面，清除 contested，从 contradictions: 中移除该页面对，将被取代的主张归档或标记，并记录解决情况

### index.md Template

Two levels: global index (wiki root) and topic index (each topic subdirectory).

**Global index.md:**

```markdown
# Wiki Index

> Global catalog. Research topics and cross-topic pages.
> Last updated: YYYY-MM-DD | Topics: N | Total pages: N

## Topics

| Topic | Pages | Index |
|-------|-------|-------|
| [topic name] | N | [[topics/{slug}/index|→ index]] |

## Cross-Topic Concepts

| Page | Summary | Topics |
|------|---------|--------|
| [[page-name]] | One-line summary | topic-a, topic-b |

## Cross-Topic Entities

| Page | Summary | Topics |
|------|---------|--------|

## Comparisons

| Page | Summary |
|------|---------|

## Queries

| Page | Summary |
|------|---------|

主题 index.md（topics/{slug}/index.md）：

# {Topic Name} — Index

> Pages: N | Last updated: YYYY-MM-DD

## Concepts

| Page | Summary |
|------|---------|

## Entities

| Page | Summary |
|------|---------|

## Comparisons

| Page | Summary |
|------|---------|

扩展规则： 当任一分区超过 50 个条目时，将其拆分为子分区。

log.md 模板

# Wiki Log

> Chronological record of all wiki actions. Append-only.
> Format: `## [YYYY-MM-DD] action | subject`
> Actions: ingest, update, query, lint, create, archive, delete
> When this file exceeds 500 entries, rotate: rename to log-YYYY-MM.md (year-month of rotation), start fresh.

## [YYYY-MM-DD] create | Wiki initialized
- Domain: [domain]
- Structure created with SCHEMA.md, index.md, log.md

核心操作

1. 摄取

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

① 捕获原始来源：

• URL → 使用 defuddle（运行 npx defuddle <url>）提取干净的 Markdown；如果 defuddle 失败或不可用，则回退到 web_extract
• PDF → 使用 defuddle（原生支持 PDF）；回退方案为 web_extract
• 粘贴文本 → 保存到合适的 raw/ 子目录
• 为文件取一个描述性名称：raw/articles/karpathy-llm-wiki-2026.md
• 添加原始 frontmatter（source_url、ingested、正文的 sha256）。 重新摄取同一 URL 时：重新计算 sha256，并与已存储的值比较 — 如果一致则跳过；如果不同，则标记内容变更并更新。每次重新摄取都进行此检查成本很低， 还能发现来源悄然发生的变化。

② 与用户讨论要点 — 哪些内容有意思，哪些对该领域很重要。（在自动化/cron 场景中跳过此步骤 — 直接继续。）

③ 检查已有内容 — 搜索 index.md，并使用 search_files 查找已存在的相关实体/概念页面。这是不断扩展的知识库与重复内容堆积的区别所在。

④ 创建或更新知识库页面：

• Zettelkasten 检查（每次编写页面时）： 运行 zettelkasten 技能中的完整七项变更清单（原子性 → 拆分 → 重复 → 链接 → 结构 → 自包含 → 用自己的话表述）。页面现在是否涵盖了 2 个或更多不同想法 → 拆分为相互链接的原子页面，修复指向该页面的链接，并更新索引。
• 新实体/概念： 只有满足 SCHEMA.md 中的页面门槛时才创建页面（在 2 个或更多来源中提及，或是单一来源的核心内容）
• 已有页面： 添加新信息、更新事实，并更新 updated 日期。当新信息与现有内容矛盾时，遵循更新政策。
• 交叉引用： 每个新建或更新的页面都必须通过 [[wikilinks]] 链接到至少 1-2 个其他页面，并将链接放在文本提及相关内容的位置 — 只添加真实存在的关联。检查已有页面是否反向链接。
• 标签： 仅使用 SCHEMA.md 分类体系中的标签
• 来源溯证： 对于综合 3 个或更多来源的页面，在论据可追溯到特定来源的段落末尾添加 ^[raw/articles/source.md] 标记。
• 置信度： 对于观点性较强、变化迅速或仅有单一来源支撑的论据，在 frontmatter 中设置 confidence: medium 或 low。只有论据得到多个来源充分支持时，才标记为 high。

⑤ 更新导航：

• 将新页面按字母顺序添加到 index.md 的正确章节下
• 更新已有页面时，如果内容含义发生了实质性变化，则更新其在索引中的单行摘要
• 更新索引页眉中的“总页面数”和“最后更新”日期
• 在 log.md 中追加：## [YYYY-MM-DD] ingest | Source Title
• 在日志条目中列出每个新建或更新的文件
• 在日志条目中记录 split_decisions：拆分的页面（触发的标准）以及判断无需拆分的边界案例页面（原因）— 这会将 Zettelkasten 输出约定保存在知识库中，方便下一次会话检查已完成的评估
• 记录 links_updated：新增的反向链接，以及因特定原因而决定不添加的反向链接（lint 的对称性检查会跳过已记录的未添加链接对）

⑥ 报告变更内容 — 列出每个新建或更新的文件，以及 split_decisions 和 links_updated 记录。如果本次摄取涉及 10 个或更多页面，建议在结束会话前运行一组轻量 lint 检查（损坏链接、索引完整性、日志核对）。

单个来源可能触发对 5-15 个知识库页面的更新。这很正常，也正是我们期望的 — 这就是累积效应。

学术来源（arXiv + Semantic Scholar）

对于学术论文，使用 arxiv 技能进行搜索和获取：

1. 搜索：python arxiv/scripts/search_arxiv.py "topic" --sort date --max 10
2. 影响力检查：通过 Semantic Scholar API 查询引用次数

   curl -s "https://api.semanticscholar.org/graph/v1/paper/arXiv:ID?fields=citationCount,influentialCitationCount"
   

3. 阅读：npx defuddle https://arxiv.org/pdf/ID（备用方案：web_extract）
4. 摄取，与通常流程相同——原始来源存放在 raw/papers/，wiki 页面遵循标准工作流

对于论文的 wiki 页面，可添加以下可选的 frontmatter 字段：

arxiv_id: "2402.03300"
citation_count: 150
influential_citations: 12

2. 查询

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

① 阅读 index.md，确定相关页面。 ② 对于页面数量达到 100 个或以上的 wiki，还要使用 search_files 搜索所有 .md 文件中的关键词——仅靠索引可能会遗漏相关内容。 ③ 使用 read_file 阅读相关页面。 ④ 根据汇总的知识综合答案。注明所依据的 wiki 页面：“基于 [[page-a]] 和 [[page-b]]……” ⑤ 将有价值的答案归档——如果答案是深入的比较、深度分析或新颖的综合内容，就在 queries/ 或 comparisons/ 中创建页面。不要归档简单查询结果，只归档那些之后重新推导起来会很费力的答案。 ⑥ 在 log.md 中更新日志，记录查询内容以及是否已归档。

3. 检查

当用户要求检查、健康检查或审计 wiki 时（如果一次摄取涉及 10 个或更多页面，也要主动建议此操作——参见摄取 ⑥）。标记为 (语义判断，由 Agent 执行) 的项目属于基于判断的候选报告，而非机械检查——可能出现误报，请仅报告：

① **孤立页面：**找出没有其他页面通过 [[wikilinks]] 链入的页面。

# Use execute_code for this — programmatic scan across all wiki pages
import os, re
from collections import defaultdict
wiki = "<wiki>"  # replace with resolved wiki path
# Scan all .md files in entities/, concepts/, comparisons/, queries/
# Extract all [[wikilinks]] — build inbound link map
# Pages with zero inbound links are orphans

② **失效的 wikilink：**找出指向不存在页面的 [[links]]。

③ **索引完整性：**每个 wiki 页面都应列在 index.md 中。对照文件系统和索引条目。

④ **Frontmatter 验证：**每个 wiki 页面都必须包含所有必需字段（title、created、updated、type、tags、sources）。Tags 必须符合分类体系。

⑤ **内容过时：**找出 updated 日期比最近一次提及相同实体的来源早 90 天以上的页面。

⑥ **矛盾：**找出同一主题中存在相互冲突主张的页面。检查标签或实体相同但陈述事实不同的页面。列出所有带有 contested: true 或 contradictions: frontmatter 的页面，供用户审核。

⑦ **质量信号：**列出 confidence: low 的页面，以及仅引用单一来源但未设置 confidence 字段的页面——这些页面可能需要寻找佐证，或将 confidence 下调为 medium。

⑧ **来源漂移：**对于 raw/ 中带有 sha256: frontmatter 的每个文件，重新计算哈希并标记不匹配项。不匹配表明原始文件被编辑过（不应发生——raw/ 是不可变的），或该文件来自一个后来发生变化的 URL。这不属于严重错误，但值得报告。

⑨ **页面大小与原子性：**标记涵盖 2 个或更多不同观点的页面——根据 zettelkasten 技能的拆分标准，这些页面可能需要拆分。超过约 200 行的页面只是需要运行这些标准的警告，不应仅因长度而拆分。跳过索引页面。对于比较／查询页面，将原子性检查替换为晋升抽查 (语义判断，由 Agent 执行)：找出只存在于综合页面中、从未晋升为概念页面的独立观点（参见页面阈值）。

⑩ **标签审计：**列出所有正在使用的标签，并标记任何不符合 SCHEMA.md 分类体系的标签。

⑪ **日志轮换：**如果 log.md 超过 500 条记录，则进行轮换。

⑫ **日志核对：**将近期页面的 updated 日期与日志条目进行比较——标记已更改但没有日志记录的页面（绕过规范的写入）。 ⑬ **链接对称性：**构建双向链接映射；报告 B 未反向链接到 A 的 A→B 边，但排除日志（摄入 ⑤）中已记录不添加反向链接决定的链接对。反向链接属于整理判断——应报告以供审核，不要自动修复。例外：contradictions frontmatter 必须相互对应（A 列出 B ⇒ B 列出 A）——此处不对称属于严重错误。

⑭ **Frontmatter 链接字段：**验证 contradictions: 中的每个 slug（以及其他引用页面的 frontmatter 字段）都能解析到现有页面——重命名和归档会悄无声息地留下悬空引用，因为这些引用不是 [[wikilinks]]，也没有其他检查会覆盖它们。

⑮ **错置与提升：**查找被 2 个或更多主题引用的 topics/{t}/ 页面——这些页面可能适合提升为全局页面。提升 = 移动文件并保留文件名（基于文件名的 [[wikilinks]] 仍然有效），修正任何路径形式的链接，更新两个索引，并记录此次移动。

⑯ 重复页面检测（语义检查，由 Agent 运行）：检测标题近似或共享标签／实体的页面之间内容高度重叠的情况。

⑰ 逐字复制检查（语义检查，由 Agent 运行）：查找段落与 raw/ 内容近乎逐字相同的 wiki 页面——实体事实、数据和来源标记会合理地重复，因此只将其列为候选项。

⑱ 标题形式 ↔ 类型抽查（语义检查，由 Agent 运行）：抽查页面——概念页面的标题应为陈述句形式，实体页面的标题应为名称形式。

⑲ **索引摘要过时：**抽查索引条目与当前页面内容——标记过时的单行摘要。

⑳ 报告发现的问题，附上具体文件路径和建议操作，并按严重程度分组（损坏的链接 > 孤立页面 > 悬空的 frontmatter slug > 来源漂移 > 有争议的页面 > 过时内容 > 风格问题）。

㉑ 追加到 log.md： ## [YYYY-MM-DD] lint | N issues found

使用 Wiki

搜索

# Find pages by content (replace <wiki> with resolved path)
search_files "transformer" path="<wiki>" file_glob="*.md"

# Find pages by filename
search_files "*.md" target="files" path="<wiki>"

# Find pages by tag
search_files "tags:.*alignment" path="<wiki>" file_glob="*.md"

# Recent activity
read_file "<wiki>/log.md" offset=<last 20 lines>

批量摄入

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

1. 先阅读所有来源
2. 识别所有来源中的实体和概念
3. 检查这些实体和概念是否已有页面（一次搜索，而非 N 次）
4. 一次性创建／更新页面（避免重复更新）
5. 最后更新一次 index.md
6. 随批次推进追加日志条目——不要等到最后再一次性追加 （这样可以避免中断窗口）；包含每页的 split_decisions 和 links_updated
7. 将反向链接决定推迟到批次末尾统一处理（一次处理，而非 N 次—— 与第 3 步的原则相同）

归档

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

1. 如果 _archive/ 目录不存在，则创建该目录
2. 将页面移动到 _archive/，并保留其原始路径（例如，_archive/entities/old-page.md）
3. 从 index.md 中移除该页面
4. 更新所有链接到该页面的页面——将 wikilink 替换为纯文本 + “（已归档）”； 同时移除或改写任何引用该页面的 contradictions: 或其他 frontmatter 字段中的 slug
5. 记录归档操作

Obsidian 集成

Wiki 目录开箱即用，可作为 Obsidian 库：

• [[wikilinks]] 会渲染为可点击的链接
• Graph View 可视化知识网络
• YAML frontmatter 支持 Dataview 查询
• raw/assets/ 文件夹存放通过 ![[image.png]] 引用的图片

为获得最佳效果：

• 将 Obsidian 的附件文件夹设为 raw/assets/
• 在 Obsidian 设置中启用 “Wikilinks”（通常默认开启）
• 安装 Dataview 插件，以运行 TABLE tags WHERE type = "entity" AND contains(tags, "company") 等查询——按 frontmatter type 查询，而不是按文件夹查询：FROM "entities" 会漏掉 topics/*/entities/

如果同时使用 Obsidian 技能，请将 OBSIDIAN_VAULT_PATH 设为与 wiki 路径相同的目录。

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

在没有显示屏的机器上，请使用 obsidian-headless，而不是桌面应用。 它通过 Obsidian Sync 同步知识库，无需 GUI——非常适合在服务器上运行、会写入 wiki 的 Agent，同时 Obsidian 桌面应用在另一台设备上读取内容。

设置：

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

# Login (requires Obsidian account with Sync subscription)
ob login --email <email> --password '<password>'

# Create a remote vault for the wiki
ob sync-create-remote --name "LLM Wiki"

# Connect the wiki directory to the vault
cd <wiki>
ob sync-setup --vault "<vault-id>"

# Initial sync
ob sync

# Continuous sync (foreground — use systemd for background)
ob sync --continuous

通过 systemd 持续后台同步：

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

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

[Install]
WantedBy=default.target

systemctl --user daemon-reload
systemctl --user enable --now obsidian-wiki-sync
# Enable linger so sync survives logout:
sudo loginctl enable-linger $USER

这样，Agent 就可以在服务器上向 wiki 写入内容，而你可以在笔记本电脑或手机上的 Obsidian 中浏览同一个知识库——更改会在几秒内显示。

注意事项

• 切勿修改 raw/ 中的文件——源文件不可变。修正内容应写入 wiki 页面。
• 务必先了解情况——在新会话中执行任何操作前，先阅读 SCHEMA、索引和近期日志。 跳过此步骤会导致重复内容和遗漏交叉引用。
• 务必更新 index.md 和 log.md——跳过此步骤会使 wiki 逐渐退化。这两者是导航的核心。
• 不要为一带而过的提及创建页面——遵循 SCHEMA.md 中的页面门槛。一个名字只在脚注中出现一次，并不足以创建实体页面。
• 不要创建没有交叉引用的页面——孤立页面不会被发现。每个页面都必须通过真实关系链接到至少 1-2 个其他页面，而不是为了凑数。
• 必须添加 Frontmatter——它支持搜索、筛选和过时检测。
• 标签必须来自分类体系——随意添加的标签会逐渐沦为噪音。先在 SCHEMA.md 中添加新标签，再使用它们。
• 让页面便于快速浏览——wiki 页面应能在 30 秒内读完。涵盖 2 个或更多不同主题的页面应拆分；篇幅（约 200 行）是执行拆分标准的警示信号，而不是单独的拆分理由。将详细分析移至专门的深度分析页面。
• 每次编写页面时都要执行 Zettelkasten 检查清单——原子性和拆分决策应在编写时完成，而不仅仅是在 lint 时进行。参见 zettelkasten 技能。
• 大批量更新前先征求确认——如果一次摄取会影响 10 个或更多现有页面，请先与用户确认范围。
• 轮换日志——当 log.md 超过 500 条记录时，将其重命名为 log-YYYY-MM.md 并重新开始。Agent 应在 lint 时检查日志大小。
• 明确处理矛盾——不要悄悄覆盖。注明双方说法及日期，在 Frontmatter 中标记，并标记为待用户审核。

相关工具

llm-wiki-compiler 是一个 Node.js CLI，可将源资料编译为概念 wiki，其灵感同样来自 Karpathy。它兼容 Obsidian，因此希望使用定时或 CLI 驱动的编译流程的用户，可以让它处理此技能维护的同一个知识库。权衡之处：它负责生成页面（取代 Agent 对页面创建的判断），并针对小型语料库进行了调优。若需要 Agent 参与整理，请使用此技能；若要批量编译某个源目录，请使用 llmwiki。