From 463ae32c13334be9401763c8b89472976d317886 Mon Sep 17 00:00:00 2001 From: weishen Date: Mon, 20 Apr 2026 14:48:44 +0800 Subject: [PATCH] docs: refine article to focus on llm-wiki-sync analysis and use RTO-vs-RPO as example --- Hermes/xingzhi/llm-wiki-sync_公众号稿.md | 183 +++++++++++------------ 1 file changed, 87 insertions(+), 96 deletions(-) diff --git a/Hermes/xingzhi/llm-wiki-sync_公众号稿.md b/Hermes/xingzhi/llm-wiki-sync_公众号稿.md index 5d826058..71e09ebd 100644 --- a/Hermes/xingzhi/llm-wiki-sync_公众号稿.md +++ b/Hermes/xingzhi/llm-wiki-sync_公众号稿.md @@ -1,122 +1,113 @@ -# 用 AI 把零散资料变成可复用的知识库 —— 从原始稿到公众号的自动化工作流 +# 用 AI 把零散资料变成可复用的知识库 —— llm-wiki-sync 的实现与示例解析 -**副标题**：把 raw/ 里的每一份素材，变成结构化知识、内容包与长期增长的内容资产 +**副标题**：如何把 raw/ 里的每一份素材，通过 llm-wiki-sync 自动分析与提炼成结构化的 source 页面、实体与概念，以便长期检索与复用。 --- -## 封面图建议（可直接给设计/生成提示词） +## 前言与来源说明 -Prompt（给图像生成模型）： +本方案借鉴并整合了几条重要线索： +- 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 内容导出为可浏览、可分享的静态站点。 -> 扁平化流程图风格：笔记、文件夹、机器人助手（AI）和公众号稿件从左到右排列，颜色清爽（蓝绿系），中间有箭头连接，风格扁平、现代、适合科技类公众号封面，文字区域留白，保持高分辨率 PNG。 +下面重点介绍 llm-wiki-sync 如何把一篇笔记做结构化分析与提炼，并用仓库中的实例（wiki/sources/RTO-vs-RPO-Key-Differences-for-Modern-Disaster-Recovery）作为逐项说明。 --- -## 导语（钩子） +## llm-wiki-sync 的目标与核心能力 -你是不是遇到过这样的痛点：你有大量自己研究笔记，收藏的技术文章，公司文件，会议记录和创意草稿，但真正可以复用、检索并产出持续价值的“知识”却屈指可数？今天介绍一个可落地的思路：用 LLM 驱动的自动化同步（llm-wiki-sync），把 raw/ 目录里的原始素材，系统化为结构化 Wiki、输出内容可转化成真正的wiki站点便于分享和自己阅读。读完后，你就能知道如何开始落地。 +核心目标：把原始文档（raw/）自动转成结构化的 wiki source 页面，抽取关键要素（Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections），并记录 ingest 日志、差异与审计信息，供后续检索、合成与内容再生产使用。 -在开始之前，必须说明两点来源与灵感： -- LLM Wiki 的概念直接受到了 Andrej Karpathy 的影响，他在这篇著名的 gist 中提出了把知识库交给大模型驱动并持续同步的思想：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f -- 我们的 llm-wiki-sync 正是基于现有的开源实现进行扩展与工程化改造，参考并基线于项目：https://github.com/SamurAIGPT/llm-wiki-agent（在此项目基础上我们加了工作流、Cron、Hermes skill 与企业化的同步策略）。 +关键能力： +- 文本解析与语义压缩：把长文本压缩为 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：以 RTO vs RPO 为例 -- 原始素材散、格式乱：文件命名不规范、缺少摘要与元信息。 -- 知识难以复用：好内容写一次就扔，找不到历史背景与引用。 -- 人力成本高：每次写长文都要重新梳理背景与资料。 +仓库中的源页面：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 会把冲突条目列出并标注来源，供人工审查。 --- -## 二、什么是 LLM Wiki（以及我们所借鉴的工作） +## llm-wiki-sync 的典型运行步骤（工程视角） -**概念**：以 LLM（大模型）为执行引擎，把 raw/ 下的每份源文档转成结构化的 wiki 页面（Summary、Key Claims、Quotes、Connections、Entities），并维护索引与知识图谱。 +1. 读取 raw/，解析 frontmatter/元数据（若缺失则询回填）。 +2. 检索 wiki/index.md 与 overview.md，获取上下文（避免重复 ingest）。 +3. 用 LLM 生成 Source Page（Summary / Key Claims / Quotes / Concepts / Entities / Connections / Contradictions）。 +4. 将结果写入 wiki/sources/.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）告知负责人。 -如前所述，这一思路在社区已有经典表述：Andrej Karpathy 的 LLM Wiki 思路（见上文链接）强调把知识以可被模型直接消费的结构化碎片保存，从而让模型本身成为知识的持续维护者与“索引器”。我们在工程实现上参考并基线于 SamurAI 的 llm-wiki-agent 项目（链接见上文），在其之上做了： -- 企业化的 ingest 与审计流程（log、checkpoint、回滚） -- Hermes skill 封装（llm-wiki-sync），便于在本地/Telegram/CLI 调用 -- 与静态站构建（Quartz）对接，支持把生成的 wiki 导出为页面网站以便分享和浏览 +并发与配额注意：单文件 ingest 优先，批量操作分批（每批 3–10 篇）；对接外部 agent/Claude Code 时避免并发超配额。 + +审计与回滚：每次 ingest 前执行 git branch 或 checkpoint；如需回滚，可用 git revert 或恢复 checkpoint。 --- -## 三、核心思路（3 步落地流程） +## 总结与扩展 -1. 统一入口：把所有原始资料放进 raw/ 目录 -2. 自动同步（llm-wiki-sync）：触发 wiki-ingest → 生成 wiki/sources/.md → 更新 wiki/index、overview 与 entities -3. llm-wiki-sync 可以动态的察觉raw目录下文章的变化，比如有些原始内容过时了，你进行了修改，删除了一些文章，某些段落进行了修改。llm-wiki-sync都可以自动识别并更新manifest.json文件，以便于在后续的cron job里识别这些变化进行再次 ingest更新内容。 +- llm-wiki-sync 把 Karpathy 关于 LLM Wiki 的理念落地为可执行的工程流程：把知识以结构化表征保存，使得大模型既是“读者”也是“执行者”。 +- 我们的实现基于 SamurAI 的 llm-wiki-agent，并在其上加入了企业级的同步、审计与 Hermes skill 封装，最终通过 Quartz 静态站把生成的 wiki 内容对外展示与分享。 ---- - -## 四、操作演示（可复制的实操步骤） - -准备工作： -- 把文件放到 raw/，命名示例：raw/product-launch-2026.md -- 确认 llm-wiki-sync skill 已部署（或用 hermes 提供的 sync 脚本） - -执行（示例命令/流程）： - -1) 手动单篇 ingest（Hermes CLI） - -``` -hermes skill llm-wiki-sync ingest raw/product-launch-2026.md -``` - -2) 批量同步（Cron） - -``` -hermes cron create "every 6h" --prompt "sync raw/ to wiki/" --deliver=origin -``` - -3) 从 wiki 导出公众号初稿（示例） - -``` -hermes chat -q "从 wiki/sources/product-launch-2026.md 生成一篇适合微信公众号的 800 字文章，包含标题、导语、3 个要点与结尾 CTA。" -``` - ---- - -## 五、公众号稿件模版（可直接复制粘贴） - -（此处为可直接发布的公众号稿，基于“Marketing Content Creator”角色与上述流程精炼而成） - -**标题**：把零散资料变成可复用的“知识产品”——一套 LLM 驱动的实操方法 -**作者**：内容工程团队 - -**导语**： -很多团队都有大量写过的会议纪要、研究报告和草稿，但这些资产很少转化为持续价值。本文将手把手教你，如何用一套 LLM 驱动的同步流程，把 raw/ 下的原始素材自动整理成结构化 Wiki，再一键生成可发布的公众号稿件、短视频脚本与社媒文案。 - -（正文略 — 与之前稿件内容一致，保留原结构：问题、方案、操作指南、CTA） - ---- - -## 六、落地注意事项（工程与运营） - -- 语言/格式规范：遵守团队的输出规范（比如 CLAUDE.md 里的简体中文与结构化语义规则）。 -- 并发与配额：同步任务避免并发过高，建议单文件顺序 ingest 或批次处理（每批 3–10 篇）。 -- 通知策略：cron 任务要设置 deliver=origin 才会在 Telegram/当前 chat 发送完成通知。 -- 媒体与图片：若原始文件含图片，先上传到公共可访问路径或把本地路径记录到 source 页面中。 -- 回滚与审计：每次 ingest 前建议在 git 或 checkpoint 做一次快照，出问题可回滚。 - ---- - -## 七、把 Wiki 导出成网站（用 Quartz 构建并分享） - -在生成并维护好 wiki/ 内容之后，为了方便浏览与分享，我们会把 wiki 导出为静态网站。工程上我们使用 Quartz（https://github.com/jackyzha0/quartz）来做静态站构建： - -- 流程概述：把 wiki/ 与 raw/ 的需要公开的页面同步到 quartz-source/，运行 npx quartz build → 输出 quartz/ 静态目录 → 部署到 GitHub Pages / Vercel / Netlify 或自托管服务器。 -- 优点：通过浏览器即可随时阅读知识库、把页面分享给同事或外部合作方，并保留 OG meta、搜索与交互式知识图谱（graph）。 -- 实操建议：在构建流水线中加入两次构建（第一次生成 artifacts 并暂存 raw，第二次最终构建），并在 CI 中做增量构建以节省时间（详见项目脚本或我可以帮你生成的 pipeline）。 - ---- - -## 八、结语（行动号召） - -如果你准备好了，把你的一份 raw 文档发来（文件名或粘贴内容均可），我可以示范一次完整的 ingest → wiki → Quartz 构建 → 公众号初稿流程，现场出稿并给出可直接发布的文章与三条社媒文案。回复“演示 + 文件名”即可。 - ---- - -*注：本文在概念部分引用了 Karpathy 的 LLM Wiki 思路（链接见上文），工程实现基线使用了 SamurAI 的 llm-wiki-agent 开源项目，并用 Quartz 做最终的静态站构建与分享。* +如果你想，我可以把上面 RTO vs RPO 的 source 页面再跑一遍演示：展示原始 raw 文件、模型的中间输出（提取断言、实体的置信度、连接候选），以及最终写入 wiki 的 diff。要我现在生成演示输出吗？