使用 LLM 构建了一个会自我维护的个人 Wiki

一个会随资料增长持续维护的知识库。

参考实现：Personal-Auto-Wiki

目录

1. 动机

知识工作者每天面对大量信息。文章、论文、报告、会议笔记。如何处理这些信息，是个老问题。

方案一：存起来

最常见的做法是用 Obsidian、Notion、Bear 或 Apple Notes 建一个文件夹结构，把资料分门别类存进去。整理的时候感觉不错。过几个月再想找某个具体的观点，往往记不清它藏在哪个文件夹的哪个文件里。整理没有产生理解，只是把信息换了个位置。

更大的困难在于知识本身在变化。同一个概念在不同文章里有不同的表述。不同来源对同一件事的描述可能互相矛盾。一个领域的方法论可能被另一个领域重新发明。要发现这些关联和矛盾，需要同时记住所有资料的内容。这超出了人脑的能力。

方案二：RAG 检索

RAG（检索增强生成）解决了找不到的问题。把文档存入向量数据库，提问时检索相关片段，让 LLM 综合回答。但 RAG 每次查询都从原始文档重新开始，而不是一个已经被消化过的知识。它假设原始文本就是知识的最佳载体，但事实并非如此。原始文档有冗余、有偏见、有过时的信息、有作者个人的表达方式。上周回答过的观点，这周要重新发现。两篇文章之间的矛盾，RAG 会同时呈现出来，不会主动标注。

第三种思路

Andrej Karpathy 在 LLM Wiki 中提出了一个不同的方向：

让 LLM 像维基百科的编辑团队一样，持续维护一个持久化的 Wiki。

新资料进来后，LLM 阅读、理解、提取概念和实体，更新已有页面，标注矛盾，维护交叉引用。查询时，LLM 检索的是这个 Wiki，而非原始文档。这个方案的核心理解是：LLM 真正擅长的是理解、综合和生成文本，而不是在查询瞬间检索和重组碎片。把理解的工作前置到摄取阶段，查询阶段只需要检索已经被结构化的知识，效率和准确度都会大幅提升。

我参考 Karpathy 的方案，构建了自己的 LLM Wiki 工作流，并做了大量定制。下面从架构、工作流、技术细节到设计哲学，完整说明我做了什么，以及为什么这么做。

2. 架构设计

整个系统由三层组成，职责清晰分离：

PersonalAutoWiki/
├── ObsidianRaw/          # 原始资料（只读，由人类策展）
│   ├── 00_Inbox/         # 临时收件箱，待分类
│   ├── 01_Projects/      # 当前项目，行动导向，有时效性
│   ├── 02_Areas/         # 持续责任区域，需主动维护
│   ├── 03_Resources/     # 可复用的参考资料 ← LLM 唯一摄取源
│   └── 04_Archive/       # 历史记录
├── Wiki/                 # 知识库（由 LLM 全权维护）
│   ├── Index.md          # 自动维护的目录
│   ├── Log.md            # 可解析的操作日志
│   ├── Concepts/         # 概念页面（方法论、理论框架）
│   ├── Entities/         # 实体页面（人物、组织、项目）
│   ├── Sources/          # 原始资料摘要
│   └── Outputs/          # 查询产出（高价值分析的回填）
├── .claude/skills/       # Claude Skills 定义（工作流的代码化）
├── AGENTS.md             # 给 LLM 的"员工手册"（完整协作规范）
└── CLAUDE.md             # 引用 AGENTS.md

2.1 第一层：原始资料（Raw Sources）

我的知识库采用 PARA 方法组织。PARA 将信息分为四类：Projects（项目）、Areas（领域）、Resources（资源）、Archive（归档），加上一个 Inbox（收件箱）作为临时入口。

这五类信息的性质截然不同：

关键：LLM 只从 Resources 目录摄取。

这是我对 Karpathy 方案的第一个定制。LLM 只从 Resources 目录摄取。Karpathy 原文没有明确这个约束。

Projects 和 Areas 的内容具有行动属性，需要人去执行，不属于 LLM 应该自动处理的知识。Inbox 是临时的，需要先经人工筛选再移入 Resources。Archive 是历史的，可能仍有价值但优先级低。不加限制的话，项目笔记、临时想法都可能被喂给 LLM，Wiki 里会混入行动项和个人工作日志。Wiki 的目标是构建可复用的知识图谱。Resources 的定义是”未来可能有用的参考资料”。两者定位一致。

2.2 第二层：Wiki（知识层）

这是系统的核心。Wiki 由四类页面组成，每类有明确的职责和命名规范：

2.2.1 Sources（来源）

每摄取一份原始资料，就在 Wiki/Sources/ 下创建一个摘要页面。页面包含：

• 原始资料的标题、作者、来源
• 核心论点的精炼摘要
• 关键概念和实体的提取
• 与其他 Sources 的交叉引用

Sources 是知识层的入口。原始文档经过理解后被压缩为结构化摘要，冗余和噪声被过滤。追踪机制是 Sources 页面的独特设计。每个 Sources 页面的 frontmatter 中包含三个追踪字段：

---
title: 韧性
created: 2026-04-08
updated: 2026-04-08
type: source
tags: [系统理论, 生态学, 韧性研究]
source_path: Academic/Research Notes/Theory/名词概念/韧性.md
source_hash: a1b2c3d4
source_mtime: 2026-04-08T17:30:00Z
---

这三个字段让 Wiki 能自动检测原始资料的变更。原始文件被修改后，系统通过对比 hash 值发现差异，提示重新摄取。

2.2.2 Concepts（概念）

Wiki/Concepts/ 存储抽象概念和方法论，比如”韧性”、“渗流理论”、“前景理论”。概念页面的特征是：

• 定义来自多个 Sources 的共识
• 当不同来源对同一概念有不同定义时，标注矛盾
• 概念的定义随新 Sources 的摄取而演进
• 每个概念页面列出所有提及它的 Sources

Concepts 是知识图谱的抽象节点，指向思想。单一来源对概念的描述往往片面。多个来源的叠加才能逼近完整理解。

2.2.3 Entities（实体）

Wiki/Entities/ 存储具体的实体：人物、组织、项目、工具、地点。与 Concepts 的区别在于：Entities 指向具体的事物，Concepts 指向抽象的思想。

实体页面包含：

• 实体的基本信息
• 与 Concepts 的关联（该实体涉及哪些概念）
• 与 Sources 的关联（哪些来源提及了该实体）
• 与其他 Entities 的关系（合作、从属、竞争等）
• 时间线（如适用）

Entities 是知识图谱的具体节点，它们让抽象的概念落地到具体的情境中。

2.2.4 Outputs（产出）

Wiki/Outputs/ 是查询和分析的副产品。当一次查询产生了跨多个来源的综合分析、对比表或洞察时，结果可以回填保存为 Output 页面。

回填标准：不是所有查询都值得保存。值得保存的结果类型：

• 综述：跨多个来源的综合分析
• 对比：概念、实体、方法的对比表
• 分析：发现隐藏的联系或洞察
• 结论：需要记录的推理结果

而简单的信息检索（“某某框架的三维度是什么？“）不值得保存：答案已经存在于 Sources 和 Concepts 中，重复存储没有价值。

Outputs 是知识图谱的合成层：它不是原始信息的再现，而是经过推理后产生的新知识。好的分析本身就是有价值的知识资产，值得持久化。

2.2.5 Index.md 和 Log.md

Index.md 是所有页面的目录，按类型组织，每个页面附一句话摘要。它的作用是控制规模：当 Wiki 增长到几十上百个页面时，没有索引就无法导航。

Log.md 是操作日志，采用可解析的格式：

## [2026-04-08] ingest | 韧性评估

- **来源**: ObsidianRaw/03_Resources/resilience-framework.md
- **影响**:
  - **Sources**: 框架摘要.md
  - **Concepts**: 韧性.md
  - **Entities**: 某机构.md
  - **Index.md**, **Log.md**
- **备注**: 新增系统性能的韧性定义

格式的设计目标是可以用 Unix 工具直接查询：

grep "^## \[" Log.md | tail -5        # 最近5条记录
grep "| ingest" Log.md                 # 所有摄取操作
grep "| 矛盾" Log.md                   # 所有矛盾标注
grep "韧性" Log.md                     # 所有与"韧性"相关的操作

Wiki 的操作日志应该像 Git log 一样可查询、可过滤、可统计。

2.3 第三层：Schema 和 Skills（给 LLM 的指令）

2.3.1 AGENTS.md / CLAUDE.md

AGENTS.md / CLAUDE.md 是一份完整的操作手册，覆盖了：

• 目录结构和每个目录的职责
• 四个核心工作流的详细步骤
• 文件格式、命名规范、引用约定
• 关联影响分析的策略
• 矛盾检测和处理的方法
• 搜索工具的调用方式和优先级
• 响应风格的要求

LLM 在每次对话开始时读取这个文件，就知道自己扮演什么角色、遵循什么规则、每个操作执行什么步骤。在对话中给指令会随上下文被截断、被后续对话覆盖。文件不变，LLM 的行为就不变。

2.3.2 Skills

AGENTS.md 定义了规则，而 .claude/skills/ 目录中的 Skill 文件则是规则的可执行封装。每个 Skill 是一个独立模块，包含完整的触发条件、执行步骤、输出格式和边界情况处理：

每个 Skill 由 SKILL.md（触发条件、执行步骤、输出格式、边界情况）和 reference/ 目录（页面模板、frontmatter 格式、查询模式、检查清单等详细参考）组成。Claude Code 会自动识别 Skills 目录，无需手动指定。修改 Skill 文件就修改了 LLM 的行为，不需要修改 AGENTS.md 的核心规范。

3. 五个核心工作流

3.1 工作流零：完整同步（Syncing Wiki）

完整同步是日常维护的推荐入口。一个命令完成从检测到处理的全部步骤。

当我说”同步并处理”时，LLM 执行六阶段工作流：

阶段 1：检测同步状态
        扫描 Resources 目录和 Wiki/Sources，三路比对
        ↓
阶段 2：确认处理范围
        展示待处理文件列表，标注跳过文件，询问用户是否继续
        ↓
阶段 3：执行处理
        调用 ingesting-resources 批量摄取（>10 个文件时分批，每批 5 个）
        ↓
阶段 4：验证结果
        检查 Sources 页面创建、frontmatter 完整性、Index.md 更新、qmd 索引更新
        ↓
阶段 5：记录日志
        在 Wiki/Log.md 写入结构化操作记录
        ↓
阶段 6：输出报告
        生成处理统计和验证结果

设计考虑：

• 分批处理：文件数超过 10 时自动分批，每批 5 个，避免单次处理过长导致上下文丢失
• 容错机制：单个文件出错时记录错误并继续，不阻塞整体流程
• 强制日志：阶段 5 必须写入 Log.md，不允许跳过
• 组合执行：内部调用 detecting-resources-sync（阶段 1）和 ingesting-resources（阶段 3），不需要重复编写逻辑

syncing-wiki 将原来需要手动串联的四个步骤合并为一个原子操作。用户只需确认处理范围，其余步骤自动完成。

3.2 工作流一：同步检测（Detecting Resources Sync）

同步检测解决的问题很直接。原始资料变了，Wiki 怎么知道？

没有同步检测，摄取流程只能在人类明确告诉 LLM”处理这个文件”时才触发。原始资料经常被修改。修正错误、补充内容、调整结构。没有自动检测机制，Wiki 很快就会与原始资料不同步。

工作流程：

Step 1: 扫描 ObsidianRaw/03_Resources/ 目录
        对每个文件记录相对路径、内容哈希（SHA256 前 8 位）、修改时间
        ↓
Step 2: 读取 Wiki/Sources/ 所有页面的 frontmatter
        提取追踪字段（source_path, source_hash, source_mtime）
        ↓
Step 3: 三路比对
        ├─ 新增：Resources 有，Sources 无 → 待摄取
        ├─ 变更：path 相同，hash 不同 → 待重新摄取
        ├─ 删除：Sources 有，Resources 无 → 待处理
        └─ 同步：path 和 hash 都相同 → 无需操作
        ↓
Step 4: 生成同步状态报告

输出格式：

## Resources 同步状态 [2026-04-08 10:30]

### 新增文件 (2)

| 路径                   | 修改时间         | 大小  |
| ---------------------- | ---------------- | ----- |
| `Academic/NewTopic.md` | 2026-04-08 09:00 | 2.5KB |

### 已变更 (1)

| 路径                      | 旧哈希   | 新哈希   | 修改时间         |
| ------------------------- | -------- | -------- | ---------------- |
| `Academic/Theory/韧性.md` | a1b2c3d4 | e5f6g7h8 | 2026-04-08 08:30 |

### 已同步 (43)

共 43 个文件处于同步状态。

设计考虑：

• source_mtime 作为快速筛选。避免每次都计算全量文件的 SHA256。只有当 mtime 变化时才计算 hash
• SHA256 前 8 位足够检测变更。同时保持 frontmatter 简洁
• 文件重命名被识别为”删除 + 新增”，需用户确认

同步检测是系统的变化感知器。没有它，Wiki 是静态快照。有了它，Wiki 持续同步。

3.3 工作流二：摄取（Ingesting Resources）

同步检测发现新文件或变更后，触发摄取流程。当我说”处理这篇文章”时，LLM 执行多步骤的理解-关联-更新过程：

Step 1: 读取原始文件，识别结构：标题层级、章节划分、列表和表格、代码块
        ↓
Step 2: 在 Wiki/Sources/ 创建摘要页面
        - 1-3 句话核心摘要
        - 按原文结构提炼关键内容
        - 提取关键概念和相关实体
        - 写入追踪字段
        ↓
Step 3: 提取概念
        ├─ Concepts/ 中已有 → 更新：添加新引用来源、补充定义
        ├─ 没有 → 创建新概念页面
        └─ 新定义与现有定义矛盾 → 标注矛盾
        ↓
Step 4: 提取实体
        ├─ Entities/ 中已有 → 更新：添加关系、事件、属性
        ├─ 没有 → 创建新实体页面
        └─ 建立与其他实体和概念的关系
        ↓
Step 5: 关联影响分析
        ├─ 是否有 Sources 需要更新交叉引用？
        ├─ 是否有 Concepts 的定义需要修订？
        ├─ 是否有 Entities 的关系需要调整？
        └─ 是否有矛盾需要标注？
        ↓
Step 6: 更新 Wiki/Index.md
        ↓
Step 7: 在 Wiki/Log.md 记录操作
        ↓
Step 8: 执行 qmd update && qmd embed 更新搜索索引

关键是 Step 5 的关联影响分析。一份新资料很少只影响一个页面。以一篇关于”基础设施韧性评估”的论文为例：

• 定义了”韧性”的模型 → 更新 Concepts/韧性.md
• 提到了某个研究机构 → 更新或创建 Entities/该机构.md
• 引用了另一篇已摄取的论文 → 在两个 Sources 页面之间建立交叉引用
• 对”韧性”的定义与已有来源不同 → 在 Concepts/韧性.md 中标注矛盾

不做关联影响分析，摄取就退化为简单的摘要生成。每个 Sources 页面孤立存在，Concepts 和 Entities 不会更新，知识图谱不会增长。关联影响分析让每次摄取成为一次全局更新。

LLM 在这一步有优势。人类阅读一篇新论文时，很难同时想起它与自己知识库中已有的5个概念、3个实体、2个来源的关系。LLM 持有整个 Wiki 的上下文，可以系统性地进行关联分析。

3.4 工作流三：查询（Querying Wiki）

当用户提出问题时，LLM 执行以下流程：

Step 1: 使用 qmd 工具搜索 Wiki 中的相关页面
        ├─ 词汇匹配（lex）：精确匹配关键词
        └─ 向量语义匹配（vec）：捕捉语义相关的不同表述
        ↓
Step 2: 阅读检索结果，综合形成回答
        ↓
Step 3: 用 [[wiki-links]] 标注来源
        ↓
Step 4: 评估结果价值，是否建议回填到 Outputs/？

查询与 RAG 的根本区别在于检索的对象。RAG 检索原始文档。Wiki 查询检索的是已经被理解过的知识层。搜索结果已经是精炼后的概念定义和实体信息。矛盾已经被标注。概念的定义是跨文档综合后的版本。实体关系已经被建立。

结果回填机制处理高价值查询。一次查询产生了以下类型的结果时，建议保存到 Wiki/Outputs/：

• 综述：比如”总结所有关于基础设施韧性的评估方法”，综合了多个 Sources 和 Concepts 的分析
• 对比：比如”对比 A 框架和 B 框架的异同”，结构化的对比表
• 分析：比如”这些方法论之间有什么隐藏联系”，发现了之前未被注意到的关联
• 结论：比如”基于现有资料，某论断的证据强度如何”，推理结论

回填的决策权在人类手中。LLM 会评估并建议，最终由人类决定是否保存。Outputs/ 的质量因此得到保证。

Skill 的 reference/query_patterns.md 定义了五种常用查询模式及其最佳实践。每种模式都规定了 lex/vec 的查询词构造方式、intent 消歧义策略和 limit 数量：

// 概念定义查询
mcp__qmd__query({
  searches: [
    { type: "lex", query: "概念名 定义" },
    { type: "vec", query: "什么是概念名，概念名的含义和解释" },
  ],
  intent: "概念定义",
  limit: 3,
});

// 对比查询
mcp__qmd__query({
  searches: [
    { type: "lex", query: "概念A 概念B 对比 区别" },
    { type: "vec", query: "概念A和概念B的区别与联系" },
  ],
  intent: "概念对比",
  limit: 5,
});

3.5 工作流四：健康检查（Checking Wiki Health）

Wiki 随时间增长。页面越来越多，关联越来越复杂。旧的信息没有更新、不同来源的矛盾没有被发现、一些页面变成了”孤儿”、概念被频繁提及但没有对应的概念页面。这些问题都会出现。

健康检查定期扫描整个 Wiki，生成报告：

检查项          | 检测什么                     | 修复建议             | 优先级
───────────────┼──────────────────────────────┼──────────────────────┼──────
未同步文件      | Resources 中新增或变更的文件    | 调用摄取流程          | P0
概念缺口        | 被引用但目标页面不存在的链接     | 创建缺失页面          | P1
矛盾标注        | > [!warning] 矛盾标注         | 人工审核解决          | P1
未索引页面      | 存在但未被 Index.md 列出的页面   | 更新 Index.md        | P2
孤立页面        | 没有入链的页面                  | 评估后添加引用或删除    | P3

健康检查报告采用结构化格式：

# Wiki 健康检查报告

日期：2026-04-08

## 统计

| 类型     | 数量    |
| -------- | ------- |
| 概念页面 | 54      |
| 实体页面 | 34      |
| 来源页面 | 45      |
| 产出页面 | 0       |
| **总计** | **133** |

## 问题列表

### 概念缺口 (2)

- [[Concepts/自适应治理]] — 被 [[Sources/韧性框架]] 引用但不存在
- [[Concepts/社会生态]] — 被 [[Entities/某机构]] 引用但不存在

### 矛盾标注 (1)

- [[Concepts/韧性]] 与 [[Sources/另一框架]] 存在维度定义差异

## 建议操作

1. 摄取 Concepts/自适应治理 和 Concepts/社会生态 的概念页面
2. 人工审核韧性概念的矛盾标注

Wiki 增长到几十个页面后，靠人工维护所有关联和一致性不现实。LLM 定期扫描，自动发现结构性问题。人类只需要处理 LLM 标记的异常。

4. 典型工作流场景

五个工作流可以组合成完整的使用场景。

场景 1：首次使用

运行 syncing-wiki 完成初始化：

同步并处理

系统将自动：检测变更 → 确认处理 → 摄取更新 → 验证结果 → 记录日志 → 输出报告

场景 2：日常维护

定期运行 syncing-wiki 检测并处理变更：

同步并处理

每周运行健康检查：

健康检查

场景 3：仅检测不处理

检测新文件

输出同步状态后询问是否继续处理。

场景 4：知识查询

韧性理论有哪些发展阶段？

系统自动检索并回答，如有长期价值建议保存到 Outputs/。

5. 其他说明

5.1 本地搜索：qmd

Wiki 的检索依赖 qmd，一个本地 Markdown 搜索引擎。

混合检索：词汇 + 向量

mcp__qmd__query({
  searches: [
    { type: "lex", query: "critical infrastructure" }, // 精确匹配
    { type: "vec", query: "如何评估基础设施的韧性" }, // 语义匹配
  ],
  intent: "学术研究方法论", // 消歧义
  limit: 5,
});

Wiki 中使用了不同的表述时，纯词汇匹配检索不到。纯向量检索可能返回语义相关但主题不精确的结果。混合检索兼顾两者。词汇匹配保证精确度，向量检索保证召回率。

intent 参数帮助消歧义。查询包含多义词时，intent 让搜索引擎理解用户真正关心的是什么。

选择 qmd 的其他原因：所有数据留在本地，不发送到外部 API。通过 MCP（Model Context Protocol）暴露为工具，LLM 可以直接调用。支持按路径、docid、glob 模式等多种获取模式。

5.2 矛盾标注

新摄取的资料与现有内容冲突时，LLM 不会自行裁决。在页面中显式标注：

> [!warning] 矛盾标注
> 本页面与 [[Sources/另一框架]] 存在矛盾：
>
> - 本页面观点：韧性包含三个维度（工程、生态、社会）
> - 另一来源观点：韧性包含五个维度（增加了经济和治理）
> - 差异原因可能是应用领域不同（自然灾害 vs 城市基础设施）

设计考虑：

1. LLM 不是领域专家，自行裁决可能引入错误。显式标注让矛盾透明化，由人类做最终判断
2. 矛盾往往不是”谁对谁错”。是定义范围、应用场景、理论框架的不同。保留双方信息比选择一方更有价值
3. 好的矛盾标注会尝试分析为什么有冲突。不同的定义、不同的应用场景、不同的时间。这本身就是有价值的分析
4. 使用 Obsidian 的标准警告格式 > [!warning]，在 Obsidian 中会以醒目的样式渲染

5.3 操作日志

Log.md 的格式参考了软件工程中日志的最佳实践：

## [2026-04-08] ingest | 基础设施韧性评估框架

- **来源**: ObsidianRaw/03_Resources/resilience-framework.md
- **影响**:
  - **Sources**: 框架摘要.md
  - **Concepts**: 韧性.md
  - **Entities**: 某机构.md
  - **Index.md**, **Log.md**
- **备注**: 新增韧性三维度定义

设计原则：

1. 可解析：每行以 ## [日期] 类型 | 标题 开头，可以用正则表达式精确匹配
2. 可追溯：每条记录包含来源和影响，可以追溯每个页面的变更历史
3. 可统计：通过 grep | wc -l 可以统计某类操作的频率
4. 可读：格式对人类友好，不需要工具就能阅读

操作日志是 Wiki 的 Git history。没有日志，Wiki 是黑盒。存了东西但不知道什么时候变的、为什么变的。有了日志，Wiki 的整个生命周期可追溯、可审计。

5.4 页面模板

每个 Skill 的 reference/ 目录中包含了详细的页面模板，确保 LLM 生成的页面格式一致：

• Sources 模板：摘要 → 核心内容 → 关键概念 → 相关实体 → 参考文献
• Concepts 模板：定义 → 核心特征 → 相关概念 → 来源
• Entities 模板：简介 → 基本信息表 → 相关概念 → 来源
• Outputs 模板：问题 → 回答 → 来源 → 相关概念

模板的价值在于可预测性。所有页面遵循相同的结构时，人类浏览 Wiki 时知道在哪里找什么信息。LLM 处理页面时有明确的格式预期。自动化脚本可以可靠地解析页面内容。

6. 我对 Karpathy 方案的系统性微调

arpathy 的 gist 提出了核心框架：Raw Sources → Wiki → Schema 的三层架构，以及 Ingest / Query / Lint 三个工作流。我的定制主要在这个框架内做工程化增强：

Karpathy 的 gist 像 design doc。提出方向，留给读者自由发挥。我的 AGENTS.md + Skills 像 runbook + 程序模块。每个步骤都有详细的操作指南、异常处理、质量标准。可以通过修改 Skill 文件直接调整 LLM 的行为。Karpathy 写的是”做什么”。我需要的是”怎么做”和”怎么改”。

7.设计哲学

7.1 LLM 是知识管理的”簿记员”

维护知识库最累的部分是那些琐碎的”簿记”工作：

• 读了新文章后，更新之前相关的概念定义
• 发现两篇文章说法不同，去标注矛盾
• 有人问了个好问题，把回答整理成可复用的格式
• 定期检查有没有过时的页面需要更新
• 追踪原始资料是否发生了变更

这些工作消耗时间和精力，不需要判断力和创造力。LLM 可以同时检索所有相关页面、比对所有定义、标注所有矛盾。人类的时间用在决定什么资料值得摄取、提出好的问题、对矛盾做最终判断。

7.2 知识是演进的

传统的笔记系统假设知识是”写一次，存永久”。真实的知识在演进：

• 新概念出现时，旧概念的定义可能需要修正
• 新证据出现时，旧的结论可能需要推翻
• 不同领域的交叉可能产生新的理解
• 同一个概念在不同语境下有不同的含义

Wiki 的设计承认这种演进性。矛盾标注允许不同观点共存。关联影响分析允许知识随新信息更新。同步检测允许原始资料的变更被追踪。健康检查允许发现问题并修复。

7.3 约束创造价值

AGENTS.md 和 Skills 中充满了约束：只处理 Resources 目录、页面必须遵循统一的格式、链接必须用 [[wiki-links]] 格式、矛盾不能自行裁决必须显式标注、回填需要满足标准、追踪字段必须写入 frontmatter。

这些约束引导 LLM 的能力用在正确的地方。没有摄取范围的限制，LLM 会把垃圾也处理掉。没有格式约束，页面风格五花八门，后续解析和浏览都困难。没有回填标准，Outputs 会充斥低价值内容。没有追踪字段，Wiki 无法检测原始资料的变更。

牺牲灵活性，换取一致性、质量和可维护性。

7.4 人机分工要清晰

7.5 工作流应该可组合、可修改

Skills 让工作流从线性流程变成工具集：

• syncing-wiki 是日常维护的推荐入口，内部组合了检测和摄取，一键完成
• detecting-resources-sync 可以独立运行，也可以作为 syncing-wiki 或 checking-wiki-health 的一部分
• ingesting-resources 可以被手动触发，也可以被 syncing-wiki 自动调用
• querying-wiki 的结果可以即时回答，也可以回填为永久资产
• checking-wiki-health 可以在摄取后验证，也可以定期独立运行

人类根据需要选择使用哪些工具，以什么顺序使用。每个 Skill 内部的步骤、容错、输出格式都已固化，不需要每次重新编排。

8. 工具链

参考

• Karpathy: LLM Wiki — 原始灵感，三层架构和工作流设计
• PARA Method — 知识组织框架，用于原始资料管理
• Obsidian — 本地 Markdown 知识库工具，用于资料存储和 Wiki 浏览
• qmd — 本地 Markdown 搜索引擎