**副标题**：如何把每一份笔记，通过 llm-wiki-sync 自动分析与提炼成结构化的页面、实体与概念，以便长期检索与复用。

---

## 前言与来源说明

本方案借鉴并整合了几条重要线索：
- Andrej Karpathy 对“LLM Wiki”理念的阐述（将知识以可被大模型直接消费的结构化方式保存）：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- 我们的实现基于开源项目 SamurAI 的 llm-wiki-agent（https://github.com/SamurAIGPT/llm-wiki-agent），在其基础上扩展了企业化的 ingest 流程、Cron 调度与 Hermes skill（llm-wiki-sync）。
- 最终静态化展示使用 Quartz（https://github.com/jackyzha0/quartz），把生成的 wiki 内容导出为可浏览、可分享的静态站点。

下面重点介绍 llm-wiki-sync 如何把一篇笔记做结构化分析与提炼，并用仓库中的实例（wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery）作为逐项说明。

---

## llm-wiki-sync 的目标与核心能力

核心目标：把原始文档（raw/）自动转成结构化的 wiki source 页面，抽取关键要素（Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections），并记录 ingest 日志、差异与审计信息，供后续检索、合成与内容再生产使用。

关键能力：
- 文本解析与语义压缩：把长文本压缩为 2–4 句高密度 summary。
- 声明抽取（claim extraction）：识别文中明确的结论与可验证断言。
- 实体与概念抽取（NER + linking）：识别人名/公司/工具/概念，并把它们标准化为 wiki 实体页（[[Name]]）。
- 关系发现（connections）：把句子级别的语义关系转成图边（A → depends_on → B）。
- 模板化输出：固定页面头（frontmatter）+ 标准段落（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
- 审计与可回滚：每次 ingest 都写入 wiki/log.md，并可通过 git/checkpoint 回滚变更。

实现技术栈要点：Hermes（skill 调用）、Claude Code / agent（可选）、llm-wiki-agent 基础脚本、以及最终的静态化工具 Quartz。

---

## 从笔记到 Source Page

仓库中的源页面：wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery.md 

下面逐项展示 llm-wiki-sync 针对该文档所做的提取结果（摘自生成的 source 页面）：

1) Summary（Summary）
- 核心主题：RTO（恢复时间目标）与 RPO（恢复点目标）的定义、区别及在现代持续交付中的应用
- 问题域：灾难恢复规划、发布风险管控
- 方法/机制：通过 Feature Flag 实现秒级 RTO 和低 RPO
- 结论/价值：预防优于恢复，Feature Flag 将部署事故从灾难转为非事件

说明：Summary 由模型将整篇文章的主旨、问题背景、关键方法与结论压缩为 2–4 条，便于快速检索与索引。

2) Key Claims（断言提取）
- RTO 衡量系统恢复速度：允许的最大停机时间
- RPO 衡量数据保护：可接受的最大数据丢失量
- 传统灾备聚焦硬件故障，现代风险更多来自代码变更（部署 bug、数据库迁移、AI 模型更新等）
- Feature Flag 将 RTO 从小时级降至秒级，同时保护 RPO
- 应用分层策略（Critical / Important / Nice-to-have）对应不同的 RTO/RPO 指标

说明：断言提取用于建立事实层（fact layer），后续可自动化做一致性检查与冲突检测（Contradictions 段）。

3) Key Quotes（关键引用）
- “RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose.”
- “Deploy != Release. Feature flags change this. You can deploy code to production without releasing it to users.”

说明：保留可引用原句，便于在后续合成（如写作、演讲稿）中引用来源。

4) Key Concepts（概念抽取）
- RTO（Recovery Time Objective）
- RPO（Recovery Point Objective）
- Feature Flag（特性开关）
- Kill Switch（紧急关闭机制）
- 渐进式发布（Gradual Rollout）

说明：概念会被标准化为 wiki 的 concept 页面（wiki/concepts/），用于聚合所有提到该概念的 source 页面。

5) Key Entities（实体抽取）
- LaunchDarkly（Feature Flag 管理平台）
- HP（示例企业）
- Christian Dior（示例企业 — 文档中作为案例提及）

说明：实体会被规范化为 wiki/entities/ 下的页面，并且 source 页面会在 sources 列表保留原始链接与引用。

6) Connections（关系构建）
- RTO ← depends_on ← Feature Flag
- RPO ← depends_on ← Feature Flag
- LaunchDarkly → provides → Feature Flag
- Feature Flag ← enables ← 渐进式发布

说明：Connections 用于图谱构建（graph/graph.json），后续能在可视化页面（graph.html）展示节点与边。

7) Contradictions（冲突检测）
- 当前文档无明显与现有 wiki 冲突的声明；若检测到冲突，llm-wiki-sync 会把冲突条目列出并标注来源，供人工审查。
![[IMG-20260420150611080.png|872]]
![[IMG-20260420150611125.png]]
---

## llm-wiki-sync 的典型运行步骤（工程视角）

1. 读取 raw/<path>，解析 frontmatter/元数据（若缺失则询回填）。
2. 检索 wiki/index.md 与 overview.md，获取上下文（避免重复 ingest）。
3. 用 LLM 生成 Source Page（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。
4. 将结果写入 wiki/sources/<slug>.md，并更新 wiki/index.md、wiki/overview.md；如有新实体/概念也生成对应页面草稿。 
5. 记录日志：在 wiki/log.md 追加 ingest 记录（时间、文件、摘要、状态）。
6. 可选：触发 graph 重建（增量或全量），并把 graph/graph.json、graph.html 更新到站点。 
7. 通知：完成后通过 Hermes 的通知机制（deliver=origin 或 Telegram 指定 chat）告知负责人。

并发与配额注意：单文件 ingest 优先，批量操作分批（每批 2~3 篇）；对接外部 agent/Claude Code 时避免并发超配额。

审计与回滚：每次 ingest 前执行 git branch 或 checkpoint；如需回滚，可用 git revert 或恢复 checkpoint。

---

## 总结与扩展

- llm-wiki-sync 把 Karpathy 关于 LLM Wiki 的理念落地为可执行的工程流程：把知识以结构化表征保存，使得大模型既是“读者”也是“执行者”。
- 在 Obsidian 中可以直接通过关系图（graph view）查看笔记间的关联；在 llm-wiki-agent 中可以通过 wiki-graph 构建并在 graph.html / graph/graph.json 中可视化展示。
- 我们的实现基于 SamurAI 的 llm-wiki-agent，并在其上加入了企业级的同步、审计与 Hermes skill 封装，最终通过 Quartz 静态站把生成的 wiki 内容对外展示与分享。