第16章：知识引擎 —— 从Skill到LLM Wiki复利系统

本章摘要​

在第 15 章，我们完成了从“构建智能体”到“封装可复用技能”的思维跃迁，产出了四个可独立运行的 Agent Skill。然而，技能的价值不在封装本身，而在被嵌入一个持续生长的知识系统中。​

​

2026 年 4 月，OpenAI 联合创始人 Andrej Karpathy 提出的 LLM Wiki 模式在 AI 社区引发广泛讨论。其核心理念是：放弃“每次查询时临时检索原始文档”的 RAG 模式，转而让 LLM 将原始资料编译为结构化、可链接、自更新的 Markdown Wiki——Obsidian 是 IDE，LLM 是程序员，Wiki 是代码库。​

​

本章将 Karpathy 的 LLM Wiki 思想与第 15 章的技能封装能力深度融合。你将学习如何将四个独立技能重组为一条 “摄取→编译→查询→反馈→体检”的全自动知识流水线，使你的 Obsidian 知识库从一个静态的笔记仓库，进化为一个具备复利效应的自我生长知识引擎。​

​

​

基础理论：从 RAG 到 LLM Wiki​

2.1 RAG 的结构性缺陷：每次查询都从零开始​

当前主流的知识管理范式是 RAG（检索增强生成）：对文档分块 → 嵌入向量数据库 → 查询时检索 Top-K 片段 → 作为上下文生成回答。NotebookLM、ChatGPT 文件上传以及大多数企业级 RAG 管线都遵循这一模式。​

​

RAG 能用，但设计中埋着一个结构性限制：LLM 在每次查询时都从零重新发现知识。一个需要综合五份文档才能回答的问题，模型每次都要实时定位、拼凑相关片段。没有任何东西积累下来，查询之间不存在持续构建的持久化结构。​

​

2.2 LLM Wiki 的核心思想：编译而非解释​

2.2.1 问题的本质：为什么“查一次算一次”不够好？​

要理解 LLM Wiki，我们先把 RAG 的工作原理想象成一个临时抱佛脚的学生：​

​

每次考试（查询）来了，这个学生才匆忙翻遍所有课本（文档库），找出几段看起来相关的文字，拼凑成答案。下次再遇到类似的题，他又得重翻一遍——昨天翻过的内容没有“长”在自己脑子里。​

​

RAG 正是如此。它每次查询都从零开始：先检索、再拼凑、最后生成。这个过程能得出答案，但没有任何知识被“记住”。一个需要综合五份文档才能回答的问题，模型每次都要实时定位、拼凑相关片段。查询之间不存在持续构建的持久化结构。​

​

这个局限不是 RAG 的实现不够好，而是它本质上就是解释器模式——即用即算，用完即弃。​

​

2.2.2 LLM Wiki 的解法：把知识“编译”进 Wiki​

图16-1：RAG 与 LLM Wiki 的范式对比​

​

​

Karpathy 用一个计算机科学的类比给这个困局开了药方：别再做解释器，改做编译器。​

编译器的工作方式是：拿到源代码（原始资料），先完整分析一遍，生成一个结构化的中间产物（比如 .o 文件）。以后每次执行程序，直接用这个预编译好的产物，不用从头解析源代码。​

​

LLM Wiki 把这个思想搬到知识管理上——把 LLM 当成知识的编译器：​

•

原始文档（文章、论文、讲义）是“源代码”；​

•

LLM 预先将它们编译为一套结构化、互链的 Markdown Wiki 页面；​

•

以后任何人提问，直接从 Wiki 中调取已编译好的知识，而不需要重新检索原始文档。​

表16-1：RAG 与 LLM Wiki 的工程范式对比​

​

#ozBkyVXAsAka text { white-space: pre; }#ozBkyVXAsAka .fb0 { stroke: var(--N900-FG, 0.15); }#ozBkyVXAsAka .fb0 {stroke: rgba(31,35,41, 0.15)}#ozBkyVXAsAka .fx0 { stroke-miterlimit: 10; }#ozBkyVXAsAka .fx0 {stroke-miterlimit: 10}#ozBkyVXAsAka .fa1 { fill: rgb(187, 191, 196); }#ozBkyVXAsAka .fa1 {fill: rgb(187, 191, 196)}#ozBkyVXAsAka .fx1 { font: 400 12px MonospacedNumber, LarkHackSafariFont, LarkEmojiFont, LarkChineseQuote, -apple-system, BlinkMacSystemFont, "Helvetica Neue", Tahoma, "PingFang SC", "Microsoft Yahei", Arial, "Hiragino Sans GB", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"; }#ozBkyVXAsAka .fx1 {font-style: normal}#ozBkyVXAsAka .fx2 { text-anchor: middle; }#ozBkyVXAsAka .fx2 {text-anchor: middle}#ozBkyVXAsAka .fx3 { dominant-baseline: central; }#ozBkyVXAsAka .fx3 {dominant-baseline: central}#ozBkyVXAsAka .fx4 { stroke: none; }#ozBkyVXAsAka .fx4 {stroke: none}#ozBkyVXAsAka .fc0 { fill: var(--text-caption); }#ozBkyVXAsAka .fc0 {fill: #646a73}#ozBkyVXAsAka .fa2 { fill: var(--text-link-disabled); }#ozBkyVXAsAka .fa2 {fill: rgb(187, 191, 196)}#ozBkyVXAsAka .fa3 { fill: rgb(31, 35, 41); }#ozBkyVXAsAka .fa3 {fill: rgb(31, 35, 41)}#ozBkyVXAsAka .fx5 { font: 700 14px LarkHackSafariFont, LarkEmojiFont, "Microsoft YaHei", -apple-system, BlinkMacSystemFont, "Helvetica Neue", Helvetica, "Noto Sans", Tahoma, "Nimbus Sans L", Arial, "Liberation Sans", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", "Source Han Sans SC", "Source Han Sans CN", "Microsoft YaHei", "Wenquanyi Micro Hei", "WenQuanYi Zen Hei", STHeiti, SimHei, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji", system-ui; }#ozBkyVXAsAka .fx5 {font-style: normal}#ozBkyVXAsAka .fx6 { text-anchor: start; }#ozBkyVXAsAka .fx6 {text-anchor: start}#ozBkyVXAsAka .fx7 { dominant-baseline: alphabetic; }#ozBkyVXAsAka .fx7 {dominant-baseline: alphabetic}#ozBkyVXAsAka .fc1 { fill: rgb(255, 255, 255); }#ozBkyVXAsAka .fc1 {fill: rgb(255, 255, 255)}#ozBkyVXAsAka .fc2 { fill: rgb(5, 16, 26); }#ozBkyVXAsAka .fc2 {fill: rgb(5, 16, 26)}#ozBkyVXAsAka .fx8 { font: 400 14px LarkHackSafariFont, LarkEmojiFont, "Microsoft YaHei", -apple-system, BlinkMacSystemFont, "Helvetica Neue", Helvetica, "Noto Sans", Tahoma, "Nimbus Sans L", Arial, "Liberation Sans", "PingFang SC", "Hiragino Sans GB", "Noto Sans CJK SC", "Source Han Sans SC", "Source Han Sans CN", "Microsoft YaHei", "Wenquanyi Micro Hei", "WenQuanYi Zen Hei", STHeiti, SimHei, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji", system-ui; }#ozBkyVXAsAka .fx8 {font-style: normal}#ozBkyVXAsAka .fb1 { fill: var(--N900-FG, 0.15); }#ozBkyVXAsAka .fb1 {fill: rgba(31,35,41, 0.15)}#ozBkyVXAsAka .fb2 { fill: rgb(221, 221, 221); }#ozBkyVXAsAka .fb2 {fill: rgb(221, 221, 221)}#ozBkyVXAsAka .fa4 { fill: var(--bg-body); }#ozBkyVXAsAka .fa4 {fill: #fff}ABC1234567对比维度RAG（解释器模式）LLM Wiki（编译器模式）核心隐喻知识处理知识积累交叉引用矛盾处理新增材料的影响解释器——运行时重新求值一切查询时从原始文档检索片段无。每次查询独立，无持续构建临时拼凑，无预设连接难以发现跨文档的矛盾仅增加可检索的文档数量编译器——预先编译为中间表示预先将原始资料编译为结构化 Wiki 页面有。Wiki 是持久化、不断复利增长的产物编译时就已建立，Wiki 页面之间互链新内容与旧结论的矛盾被主动标记一个新材料可能触及并更新 10-15 个现有页面

​

RAG 让 AI 每次“临时翻书找答案”；LLM Wiki 让 AI 先把书“消化成自己的知识体系”，再回答问题。前者每次从零开始，后者积累一次就永久沉淀。​

​

LLM Wiki 的核心洞察由此浮现：知识被编译一次就沉淀下来，持续更新，不用每次查询时从头推导。Wiki 是一个持久的、不断复利增长的产物——交叉引用已经建好了，矛盾已经被标记了，综合判断已经反映了你读过的所有内容。把查资料从“每次都从头来过”变成“站在上一次的肩膀上”，这正是下一节要展开的关键效应。​

2.3 复利效应：为什么 LLM Wiki 越用越聪明​

Karpathy 反复提到 compounding（复利） 一词，这是理解 LLM Wiki 价值的钥匙。​

​

在标准个人知识管理工作流中，信息的增长充其量是线性的。收藏 200 篇文章，190 篇原封不动地躺着，知识不会自己相互关联。​

​

LLM Wiki 改变了这一点。模型不只是写一个摘要页面，它会通读整个现有 Wiki，找出新内容与已有实体页面、概念页面和主题摘要的交集，然后更新所有相关内容。每一个新输入都被整合进现有知识结构，而非堆叠在上面。​

​

图16-2：LLM Wiki 的复利效应示意​

​

​

复利效应的实质：摄入的内容越多，新材料被解读时所处的上下文就越丰富。第 100 个来源的处理建立在一个已经蒸馏了前 99 个来源知识的 Wiki 之上，不会从零起步。在 Obsidian 仓库里，添加第 100 条笔记不会让第 50 条笔记变得更聪明；LLM Wiki 模式下会。​

2.4 LLM Wiki 的五步工作流​

*图16-3：LLM Wiki 工作流示意图​

​

​

Karpathy 将 LLM Wiki 的持续生长过程抽象为五个紧密衔接的步骤，形成一个自增强闭环：​

摄取（Ingest）：把原始资料（论文、文章、讲义等）放入 raw/ 目录。LLM 通读这些只读素材，提取关键实体、概念与论断，生成结构化的中间表示——这一步是编译器模式的“词法与语法分析”。​

编译（Compile）：基于中间表示，LLM 在 wiki/ 目录中创建、更新原子化页面，并自动注入双向链接与元数据。新概念被嵌入现有知识网络，矛盾与支持关系被显式标注。编译是 Wiki 复利效应的核心环节。​

浏览（View）：在 Obsidian 等工具的图谱视图中，人类可以直观地看到知识节点的连接态势。枢纽节点、知识孤岛与主题群落一目了然，为后续查询和健康检查提供方向感。​

查询（Query）： 用户既可以通过 Dataview 等工具进行结构化检索，也可以直接用自然语言向 LLM 提问。因为知识已经预编译为 Wiki 页面，回答不再依赖实时检索原始文档，回答质量随 Wiki 的累积而提升。​

反馈与体检（Feedback & Lint）： 每次查询后的新发现、修正或补充，都会被归档回 Wiki 页面。同时，LLM 定期执行“健康检查”，扫描断链、矛盾、缺失信息，并生成改进建议。这一步将“使用”变成“贡献”，使 Wiki 因使用而不断自愈与生长。​

​

这五个步骤不是一次性流水线，而是一个循环迭代的引擎：每一次反馈和体检的结果都会触发新的编译，而每一次编译又为下一次查询提供了更丰富的上下文。​

​

架构设计：LLM Wiki 三层架构​

3.1 LLM Wiki架构说明​

在理解了 LLM Wiki 的“编译器模式”之后，我们现在打开这个编译器的内部构造。Karpathy 为 LLM Wiki 定义了一个严格而优雅的三层架构——它将知识的生命周期划分为三个物理隔离、逻辑单向流动的层次。这三层如同一个“知识工厂”的生产流水线：原料车间（只进不出）、加工车间（持续产出）、调度中心（全局追踪）。​

第一层：原始素材（raw/） —— 不可变。文章、论文、PDF、网页剪藏等，永不被修改，LLM 只读。​

第二层：Wiki（wiki/） —— 由 LLM 操作。包含实体页面、概念页面、主题摘要、索引文件。​

第三层：索引与日志（index.md + log.md） —— Wiki 的“符号表”和“构建日志”，帮助 LLM 定位信息和追踪变更。​

​

图16-4：LLM Wiki 三大核心页面模板规范​

​

​

3.1.1 第一层：原始素材层（raw/）—— 知识的“事实地基”​

​

代码块​

Plain Text

raw/ # 只读目录，绝不修改​

├── papers/ # 学术论文 PDF 的 Markdown 转录​

├── articles/ # 网页剪藏、博客文章​

├── transcripts/ # 视频/播客转录稿​

└── module-notes/ # 课程讲义（本章的起点材料）​

​

设计原理：知识管理的第一铁律是“事实不能被修改”。raw/ 目录中存放所有原始资料，LLM 只有读取权限，绝不写入或修改。这一层的文件一旦放入就应当视为不可变——就像源代码管理中的 Git 历史，即使发现错误，修正也应体现在 Wiki 层的页面中，而非涂抹原始记录。​

​

为什么必须不可变？​

•

可追溯：当 Wiki 中的某个结论被质疑时，可以回溯到 raw/ 中的原始材料验证。​

•

可重编译：如果 Wiki 编译规则升级，可以从原始素材重新生成整个 Wiki，而不丢失任何信息。​

•

防幻觉污染：一旦 LLM 可以修改“原材料”，错误会像病毒一样随着每次编译扩散。​

命名约定：raw/ 是推荐名称，但你可以根据项目习惯使用 sources/、originals/ 等。关键不是名字，而是所有技能和系统指令中对这一目录的路径引用必须统一。​

​

​

3.1.2 第二层：Wiki 层（wiki/）—— 知识的“结构化产物”​

​

代码块​

Python

wiki/ # 由 LLM 创建和维护​

├── concepts/ # 概念页面：定义原子知识单元​

├── entities/ # 实体页面：人物、框架、协议等具体事物​

├── summaries/ # 摘要页面：阶段性综合视图​

├── syntheses/ # 跨章节综合主题（实验三引入）​

​

这是 LLM Wiki 的核心——所有编译产出都存放在此。与 raw/ 的只读不同，wiki/ 由 LLM 全权创建、更新和维护。它内部的子目录按页面类型组织，每种类型承担不同的知识表达功能：​

​

概念页面（concepts/）—— 原子知识单元​

概念页面是 Wiki 的最小知识单位。一个概念页面定义一个核心概念：它是什么（一句话定义）、它的要点（核心要素）、它与谁相关（双向链接）。YAML Frontmatter 中 type: concept 使其可被 Dataview 按类型筛选。​

​

​

示例：MCP协议.md、S.C.O.R.E.模型.md、ReAct范式.md​

​

​

** 实体页面**（entities/）—— 具体事物描述​

实体页面描述一个具体存在的人、组织、框架、协议或工具。与概念页面不同，实体页面回答“这个人/物是谁/是什么”而非“这个概念怎么理解”。YAML 中 type: entity，可按 category 字段细分为人物、框架、协议等。​

​

​

示例：Andrej Karpathy.md（人物）、ModelContextProtocol.md（协议）​

​

3.1.3 第三层：索引与日志（index.md + log.md）—— 知识的“全局操作系统”​

​

代码块​

Plain Text

wiki/​

├── index.md # 全局索引：Wiki 的“符号表”​

└── log.md # 构建日志：Wiki 的“Git 历史”​

​

第三层只有两个文件，却是整个 Wiki 的导航中枢和时间记录仪。它们不存放知识本身，而是关于 Wiki 的知识（元知识）。​

index.md —— Wiki 的“符号表”​

在编程语言编译器中，“符号表”记录了程序中所有变量、函数及其位置。对 LLM 而言，index.md 承担同样的角色：它告诉 LLM Wiki 中有哪些页面、它们在哪里、核心枢纽是谁、常用入口有哪些。​

当 LLM 需要回答一个问题时，它首先查阅 index.md，快速定位到相关的概念页面和实体页面，而不是盲目扫描整个 wiki/ 目录。这是 LLM Wiki 不需要传统向量检索就能高效问答的关键机制。​

一个维护良好的 index.md 包含：​

•

目录结构概览（各子目录及页面数量）​

•

核心枢纽节点 Top 5（按被引次数排列）​

•

综合主题列表（链接到 syntheses/ 下的页面）​

•

常用查询面板入口​

•

最新健康报告链接​

log.md —— Wiki 的“构建日志”​

log.md 记录每一次 Wiki 操作，格式为：​

​

代码块​

Plain Text

| 时间 | 操作 | 源文件 | 影响页面数 | 备注 |​

​

它如同 Git 的 commit 历史，让人类和 LLM 都能追踪 Wiki 的演进轨迹——什么时候新增了材料、哪次编译影响了哪些页面、健康检查发现了什么问题。在自动化触发流水线中，log.md 还是判定“是否需要重新编译”的依据。​

3.1.4 三层架构的单向数据流​

三层之间的数据流动是严格单向的：​

​

代码块​

Plain Text

raw/ ──（只读读取）──► LLM ──（创建/更新）──► wiki/​

│​

└──（维护）──► index.md + log.md​

​

•

raw/ → LLM：只读。原始素材是知识的唯一入口，绝不反向写入。​

•

LLM → wiki/：写入。所有编译产物统一输出到此，目录结构固定，页面类型规范。​

•

LLM → index.md + log.md：维护。每次操作后自动更新全局索引和操作日志。​

这个单向数据流保证了知识工厂的“原料纯度”——原始材料永不污染，编译产物可随时从 raw/ 重新生成，整个系统的状态通过 log.md 完全可审计。三层合作，构成了一套严谨、可维护、能自生长的知识系统工程。​

​

3.2 技能（第15章）映射详解​

第 15 章产出的四个技能，恰好可以承担 LLM Wiki 工作流中的不同职责：​

表16-2：第 15 章技能在 LLM Wiki 三层架构中的角色映射​

​

​

图16-5：第 15 章技能在 LLM Wiki 三层架构中的映射关系​

​

​

摄取层（raw/ → wiki/）：course-summarizer 扮演编译器的“第一遍扫描”角色。它读取 raw/ 目录下的原始讲义，提取每章的核心概念与一句话摘要，生成结构化的摘要表格。这个表格是后续原子化切片的“索引清单”。​

编译层（wiki/ 构建）：note-atomizer 是核心编译引擎。它读取摘要表格，将每个核心概念拆分为独立的 .md 文件，注入 YAML Frontmatter 元数据，并建立双向链接 [[概念名]]。这正是 Karpathy 所描述的“LLM 创建、更新、维护 Wiki 全部内容”的具象化实现。​

查询层（wiki/ 查询）：dataview-query-generator 将自然语言查询需求转化为 Dataview 代码，使 Wiki 具备结构化检索能力。Karpathy 指出，当 Wiki 达到一定规模后，可以直接围绕整个 Wiki 提出复杂问题，而不依赖传统 RAG。​

体检层（wiki/ 健康检查）：knowledge-network-analyzer 对应 Karpathy 描述的“定期进行健康检查”——识别数据不一致、补全缺失信息、探索跨概念关系。​

​

实战演练：构建端到端 LLM Wiki 知识流水线​

4.1 实验场景总览​

​

目标：将 raw/ 目录下的 14 章课程讲义，通过两个阶段的实验，逐步构建为一个可查询、可体检、可自生长的 LLM Wiki。​

•

实验一（最小闭环）：仅依赖一个 SKILL.md 技能文件，跑通“摄取 → 编译 → 浏览 → 查询 → 反馈体检”五步流水线，产出可用的 Wiki 雏形。​

•

实验二（能力扩展）：在实验一基础上，引入页面模板、健康检查规则清单等辅助文件，让 Wiki 的生成更稳定、分析更细致，并尝试类型化链接的雏形。​

两个实验共享同一套目录结构，均使用 Cherry Studio 作为与 LLM 交互的主界面。​

4.2 实验前置准备​

在你的 Obsidian 知识库根目录（例如 MyVault/）下创建如下结构。​

​

​

代码块​

Python

📂 MyWiki/​

├── 📂raw/ # 第一层：原始素材（不可变）​

│ └── 📂gen-thinking-notes/ # 14 章课程讲义 .md 文件​

├── 📂wiki/ # 第二层：编译后的 Wiki（LLM 维护）​

│ ├── 📂concepts/ # 概念页面（原子笔记）​

│ ├── 📂entities/ # 实体页面（人物/框架/协议）​

│ ├── 📂summaries/ # 主题摘要页面​

│ ├── 📂queries/ # Dataview 查询面板​

│ └── 📂reports/ # 网络健康报告​

├── index.md # 第三层：全局索引（Wiki 的“符号表”）​

└── log.md # 构建日志（追踪每次编译）​

​

初始情况下，index.md 和 log.md 可以留空文件，其余 wiki/ 子目录全部为空。raw/gen-thinking-notes/ 中放入实际讲义文件。​

​

​

⚠️ 第一层原始素材的目录名称不强制叫 raw/，也允许使用 sources/、originals/ 等，但后续的系统指令中需要对应保持一致。本实验统一以 raw/ 为例。​

​

​

4.3 实验一：最小闭环——用一个 SKILL.md 跑通 LLM Wiki​

​

💡核心思想：最精简的 LLM Wiki 维护者只需一个系统指令文件。我们将它实现为 Cherry Studio 的一个技能（助手），立刻验证五步工作流的可行性。​

​

​

4.3.1 创建 llm-wiki-maintainer 技能​

SKILL.md 内容（既包含技能元数据，也包含完整系统指令）：​

​

代码块​

YAML

---​

name: llm-wiki-maintainer​

description: LLM Wiki 的专职维护者，负责读取 raw/ 目录下的原始资料，将其编译为结构化的 wiki/ 页面，并持续维护 index.md 与 log.md，支撑知识引擎的复利生长。​

version: 0.1.0​

author: Gitconomy Reserch-郭晧​

license: MIT​

---​

# LLM Wiki Maintainer — 系统指令​

​

## 1. 核心身份​

你是一个 LLM Wiki 的专职维护者。你的职责是读取 raw/ 目录下的新资料，将其编译到 wiki/ 目录中，并维护 index.md 和 log.md。​

​

## 2. 三层架构规范​

- raw/：只读。绝不修改此目录下的任何文件。​

- wiki/：由你创建、更新、维护。所有输出必须写入此目录。​

- index.md：每次编译后必须更新，记录 Wiki 的全局结构。​

- log.md：每次操作必须追加一条日志，记录时间、操作类型、影响页面。​

​

## 3. 页面类型规范​

- 概念页面（concepts/）：定义一个核心概念，YAML 中包含 type: concept​

​

4.3.2 执行五步工作流​

打开与 wiki-maintainer 的对话，依次执行以下指令。建议每步观察输出是否符合预期，再进行下一步。​

第1步：数据摄取（Ingest）​

​

代码块​

Plain Text

​

第2步：Wiki 编译（Compile）​

​

代码块​

Plain Text

读取 wiki/summaries/chapter-summary.md，将表格中每一个核心概念拆分为独立的原子笔记，保存到 wiki/concepts/ 目录。对于人物、框架或协议类概念，同步创建 wiki/entities/ 下的实体页面。​

所有页面必须：​

- 包含 YAML Frontmatter（type 字段为 concept 或 entity）​

- 使用 [[页面名]] 建立双向链接​

- 若新内容与已有页面存在矛盾或支持关系，用 @contradicts 或 @supports 语法标注​

完成后更新 index.md 和 log.md。​

​

第 3 步：可视化浏览（View）​

在 Obsidian 中打开知识库，切换到图谱视图。观察：​

•

哪些节点成为了链接密集的枢纽（如 MCP 协议、S.C.O.R.E. 模型）？​

•

有没有完全孤立的页面（可能是漏掉了链接的概念）？​

•

是否已初步形成几个自然的主题聚类？​

​

第 4 步：查询与问答（Query）​

​

生成查询面板​

a.

生成一个 Dataview 查询面板，列出 wiki/concepts/ 中所有 type 为 protocol 的页面，按来源章节排序，保存到 wiki/queries/protocol-concepts.md。​

直接向 Wiki 提问​

a.

基于我的 wiki/concepts/ 和 wiki/entities/ 目录下的知识，回答：MCP 协议与传统的 API 调用方式有什么本质区别？‘​

​

​

第 5 步：反馈归档与健康检查（Feedback & Lint）​

​

归档问答结果​

a.

将刚才关于 MCP 协议的问答结论，整合回 wiki/concepts/MCP协议.md，新增“与传统 API 的区别”小节，保持双向链接规范。​

执行健康检查​

a.

分析 wiki/ 目录下的所有页面，生成网络健康报告，保存到 wiki/reports/network-health-2026-04-21.md。报告需包含：核心枢纽节点 Top 5、知识孤岛列表、主题聚类概览、健康度简评。​

​

4.3.3 实验一小结​

完成后，你应该获得：​

•

一个可浏览、可查询的结构化 Wiki（wiki/concepts/ 和 wiki/entities/ 中的页面）。​

•

一张章节摘要总表。​

•

几份 Dataview 查询面板。​

•

一份网络健康报告。​

•

持续更新的 index.md 和 log.md。​

​

​

💡核心收获：你不必编写任何代码，仅用 Cherry Studio 中的一个系统指令文件，就让 LLM 完成了从原始讲义到结构化 Wiki 的“编译”全流程。​

​

​

4.4 实验二：能力扩展——用模板与规则提升 Wiki 质量​

实验一虽然跑通了流程，但可能存在两个不足：​

页面格式不统一：每个概念页面的结构可能略有不同，YAML 字段偶尔缺失。​

健康检查较粗放：目前只给出枢纽与孤岛，难以量化矛盾链接数量、缺失信息密度等。​

​

实验二将引入两种辅助文件（不修改 SKILL.md 的核心逻辑），使 llm-wiki-maintainer 的执行更稳定、更精细。​

4.4.1 扩展一：引入页面模板，统一 Wiki 格式​

在 wiki/ 目录下新建 templates/ 子文件夹，创建两个模板文件：​

​

wiki/templates/concept-page.md​

​

代码块​

YAML

​

wiki/templates/entity-page.md​

​

代码块​

YAML

---​

type: entity​

aliases:​

- ​

​

修改 Cherry Studio 中的系统指令​

在 llm-wiki-maintainer 的系统提示末尾增加一段模板引用规则：​

​

代码块​

Plain Text

​

4.4.2 扩展二：引入健康检查规则清单，细化分析​

在 wiki/ 目录下新建 rules/health-check-rules.md：​

​

代码块​

Markdown

# Wiki 健康检查规则​

​

## 1. 枢纽节点识别​

- 至少被 3 个其他页面链接的页面才能进入枢纽候选​

- 按被引次数降序排列，列出 Top 5​

​

## 2. 知识孤岛​

- 出度为 0 且入度 ≤ 1 的页面视为孤岛​

- 列出所有孤岛，并建议与其最相关的 2 个已有页面建立链接​

​

## 3. 矛盾检测​

- 扫描所有包含 @contradicts 的链接​

- 统计矛盾数量，并判断是否存在冲突三方（A 矛盾 B，B 矛盾 C，A 支持 C）​

​

## 4. 主题聚类​

- 根据页面间的链接密度，尝试给出 2-3 个自然聚类的主题标签​

​

## 5. 覆盖率评估​

​

修改健康检查指令：​

当需要执行体检时，不再使用实验一的简单指令，而是：​

​

代码块​

Plain Text

严格按照 wiki/rules/health-check-rules.md 中的规则，分析 wiki/ 目录下所有页面，生成健康报告并保存到 wiki/reports/network-health-2026-04-24.md。​

​

4.4.3 实验二操作流程​

​

在 wiki/ 中创建 templates/ 和 rules/ 目录，并放入上述文件。​

更新 Cherry Studio 中 wiki-maintainer 的系统提示（添加模板规则）。​

重新运行一次完整编译（可先清空 wiki/concepts/ 和 wiki/entities/，保留 raw/ 和摘要表格），观察新生成的页面是否格式统一。​

再次执行健康检查，对比实验一的报告，看是否增加了矛盾数量、死链检测等更细粒度的分析。​

在 log.md 中记录本次扩展操作。​

​

4.4.4 实验二小结​

通过引入页面模板和健康检查规则，llm-wiki-maintainer 从一个“能跑”的原型进化为一个“可几用”的 Wiki 维护助手。模板保证了产出的规范性与一致性，规则文件使健康检查从泛泛而谈变为可量化的质量把关。​

​

4.5 实验三：跨章节主题合成——让知识纵向生长​

​

•

实验一、二解决了“原子化”与“整洁度”的问题，但知识依然散落在各个孤立的页面中。LLM Wiki 的复利效应还体现在：能自动识别跨章节的宏观主题，生成纵向的综合页面，让原子笔记编织成网。​

•

实验三将扩展 llm-wiki-maintainer 的系统指令，赋予它主题合成能力。​

​

​

4.5.1 再次升级系统指令​

在 wiki-maintainer 的系统提示末尾继续追加以下内容：​

​

代码块​

Markdown

## 8. 跨章节主题合成规则​

你可以根据用户要求，或主动识别 wiki/ 中反复出现的核心主题，生成跨章节综合页面，存入 wiki/syntheses/ 目录。​

​

### 合成触发条件​

- 用户明确请求“生成某个主题的综合页面”​

- 当某个主题被至少3个不同章节的概念页面引用，而 wiki/syntheses/ 中尚不存在该主题的综合页面时，你可以在健康检查后主动建议合成​

​

### 合成页面结构​

每个综合页面需包含：​

- YAML 元数据：type: synthesis，主题名称，涉及的章节列表，主要关联概念列表​

- 标题：# {{主题名}} —— 跨章节综合​

- 主题概述（2-3句）​

- 各章节核心观点摘要（从相关概念页面自动提取）​

- 观点演化脉络（若有时间线或逻辑演进）​

- 矛盾与争议（若不同章节观点冲突，使用 @contradicts 标注）​

- 与其它综合主题的链接（如 [[另一个综合页面]]）​

​

保存系统指令修改。​

4.5.2 执行首次跨章节主题合成​

在 llm-wiki-maintainer 对话中输入以下指令（示例）：​

​

代码块​

Plain Text

请根据当前 wiki/ 中所有概念和实体页面的内容，自动识别出至少两个跨越3个以上章节的重要主题，为它们生成综合页面，保存到 wiki/syntheses/ 目录，并更新 index.md 和 log.md。​

​

LLM 可能会生成诸如“MCP协议的演进与对比”、“智能体认知框架的演变”（S.C.O.R.E.、PEAR、ReAct等）等综合页面。观察每个综合页面是否按规则包含了演化脉络、矛盾标注、交叉链接。​

你也可以手动指定主题：​

​

代码块​

Plain Text

请生成综合页面：“从ReAct到S.C.O.R.E.：智能体决策模型的演进”，保存到 wiki/syntheses/agent-decision-models.md。​

​

4.5.3 验证合成效果​

​

打开新生成的综合页面，检查是否使用了 [[概念页面]] 建立了双向链接，是否引用了不同章节的来源。​

浏览 index.md，确认多出了“🧩 综合主题”板块。​

回到 Obsidian 图谱视图，观察综合页面是否成为了新的枢纽节点，连接了原本松散的聚类。​

​

​

4.5.4 与健康检查联动​

再次运行健康检查（使用实验二的增强指令），报告中可能会提及综合页面的链接密度或新的聚类情况，这将反映知识网络的纵向生长效果。​

​

4.5.5 实验三小结​

跨章节主题合成让 LLM Wiki 从“概念索引”跃升为“深度知识体”。它不再只是提取已有知识，而是主动建立更高层次的认知结构，这正是 Karpathy 所说“第 100 条资料的处理建立在已蒸馏前 99 条资料的 Wiki 之上”的具象表现。​

​

4.6 构建 Wiki 首页（index.md）​

完成三个实验后，你的 Wiki 已包含概念、实体、查询面板、健康报告和综合主题页面。最后，让 wiki-maintainer 重新生成一份完整的 index.md：​

​

代码块​

Plain Text

请根据当前 wiki/ 的完整内容，重新生成 index.md，要求包含目录结构、核心枢纽节点Top5、综合主题列表、常用查询面板入口和最新健康报告链接。​

​

生成结果应类似：​

​

代码块​

Plain Text

​

LLM Wiki 与第 15 章技能的协同价值​

5.1 技能如何支撑“编译而非解释”的范式​

第 15 章的四个技能，恰好构成了 LLM Wiki 编译流水线的完整工具链：​

​

​

​

5.2 从“一次性技能调用”到“持续生长系统”​

第 15 章的技能是“离散的”——每次调用独立完成一个任务。LLM Wiki 框架将这些离散技能串联为一个持续运行的系统：​

•

增量更新：每次向 raw/ 添加新资料，技能流水线自动触发，Wiki 增量生长​

•

复利积累：第 100 次编译建立在前 99 次编译产出的 Wiki 之上，知识网络越来越密​

•

自我修正：健康检查定期发现矛盾和不一致，触发修正操作​

•

使用即增强：每次问答的结果被归档回 Wiki，知识库因使构建持续生长的知识引擎用而变强​

这正是 Karpathy 所描述的愿景：“每添加一个新资料源、每提出一个新问题，Wiki 都在变得更丰富”。​

​

工程要点与优化方向​

6.1 当前方案的工程局限​

对照 LLM Wiki 的完整愿景，当前基于第 15 章技能的实现还存在以下差距：​

​

​

​

6.2 拓展方向：类型化链接（Typed Links）​

一篇关于 LLM Wiki 不足之处的分析文章指出，标准 [[wikilink]] 只能表达“这两个笔记是连接的”，无法表达连接的具体语义（支持、反驳、取代、导致等）。​

社区已有解决方案，如 obsidian-wikilink-types 插件，使用 @ 语法在链接中嵌入关系类型：​

​

代码块​

Plain Text

[[Redis Paper|The new research @supersedes the previous analysis]]​

[[MCP协议|GraphRAG @supports 知识图谱检索]]​

​

这类关系类型可以被 Dataview 查询，使 Wiki 的网络结构具备更丰富的语义维度。​

​

本章总结​

本章将 Karpathy 的 LLM Wiki 思想与第 15 章的技能封装能力深度融合，构建了一个端到端的自生长知识引擎。核心收获如下：​

范式跃迁：从 RAG 的“解释器模式”升级为 LLM Wiki 的“编译器模式”——知识被编译一次就沉淀下来，越用越聪明。​

技能映射：第 15 章的四个技能分别承担摄取、编译、查询、体检四个关键环节，构成了完整的 Wiki 维护流水线。​

五步工作流：数据摄取 → Wiki 编译 → 可视化浏览 → 查询问答 → 输出反馈与健康检查，形成闭环。​

复利效应：Wiki 是持久化、不断复利增长的产物——每一个新输入都被整合进现有结构，而非堆叠其上。​

💡 RAG 让 AI “临时翻书”；LLM Wiki 让 AI “帮你出百科全书”。​

​

​

课后思考​

类型化链接的实现：当前技能生成的 [[双向链接]] 只表达了“连接”这一种语义。如何修改 note-atomizer 的 Prompt，使其在生成链接时自动识别关系类型（如 @supports、@contradicts、@extends）？​

自触发流水线：当前需要人工输入指令触发技能。如何利用 Obsidian 的 Templater 插件或操作系统级文件监听（如 Python watchdog），实现“将文件放入 raw/ 即自动触发整个流水线”？​

主题综合页面：当前 course-summarizer 生成的是章节级摘要。如何设计一个新的 theme-synthesizer 技能，使其能跨越多个章节，自动生成“MCP 协议全景”、“提示工程方法论”等主题综合页面？​

​

​

附录：LLM Wiki 核心概念术语表​

​

​

​