图片提交

This commit is contained in:
2026-04-20 15:47:21 +08:00
parent 22f148e5ec
commit d55e364abc
3 changed files with 5 additions and 5 deletions

View File

@@ -0,0 +1,113 @@
**副标题**:如何把每一份笔记,通过 llm-wiki-sync 自动分析与提炼成结构化的页面、实体与概念,以便长期检索与复用。
---
## 前言与来源说明
本方案借鉴并整合了几条重要线索:
- Andrej Karpathy 对“LLM Wiki”理念的阐述将知识以可被大模型直接消费的结构化方式保存https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
- 我们的实现基于开源项目 SamurAI 的 llm-wiki-agenthttps://github.com/SamurAIGPT/llm-wiki-agent在其基础上扩展了企业化的 ingest 流程、Cron 调度与 Hermes skillllm-wiki-sync
- 最终静态化展示使用 Quartzhttps://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 日志、差异与审计信息,供后续检索、合成与内容再生产使用。
关键能力:
- 文本解析与语义压缩:把长文本压缩为 24 句高密度 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 回滚变更。
实现技术栈要点Hermesskill 调用、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) SummarySummary
- 核心主题RTO恢复时间目标与 RPO恢复点目标的定义、区别及在现代持续交付中的应用
- 问题域:灾难恢复规划、发布风险管控
- 方法/机制:通过 Feature Flag 实现秒级 RTO 和低 RPO
- 结论/价值预防优于恢复Feature Flag 将部署事故从灾难转为非事件
说明Summary 由模型将整篇文章的主旨、问题背景、关键方法与结论压缩为 24 条,便于快速检索与索引。
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概念抽取
- RTORecovery Time Objective
- RPORecovery Point Objective
- Feature Flag特性开关
- Kill Switch紧急关闭机制
- 渐进式发布Gradual Rollout
说明:概念会被标准化为 wiki 的 concept 页面wiki/concepts/),用于聚合所有提到该概念的 source 页面。
5) Key Entities实体抽取
- LaunchDarklyFeature 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 PageSummary / 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 内容对外展示与分享。