Menü
知识库构建（wiki/消化/查询/健康检查/图谱/结晶化）| 多源素材消化与分析。其他 skill（如 clippings-digest）通过此 skill 的 ingest 工作流完成消化。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
| name | llm-wiki |
| version | 1.2.0 |
| author | JYS (adapted for WorkBuddy) |
| license | MIT |
| description | 知识库构建（wiki/消化/查询/健康检查/图谱/结晶化）| 多源素材消化与分析。其他 skill（如 clippings-digest）通过此 skill 的 ingest 工作流完成消化。 |
知识库的价值：知识编译一次，持续维护，而不是每次重新推导。
位于 templates/ 目录，生成 wiki 页面时读取对应模板后填充：
source-template.md · entity-template.md · topic-template.md · query-template.md · synthesis-template.md · review-template.md
| 依赖 | 用途 | 回退方案 |
|---|---|---|
baoyu-url-to-markdown | 网页/X/YouTube 提取 | WebFetch |
wechat-article-search | 公众号检索 | 用户手动粘贴 |
markdown-converter | PDF/DOCX 转 Markdown | Read 直接读取 |
缺失不阻塞核心流程，自动降级为原生工具。
不触发：仅要求"总结这篇文章"时。
| 用户意图关键词 | 工作流 |
|---|---|
| "初始化知识库"、"新建 wiki" | init |
| URL / 文件路径 / "消化"、"整理" | ingest |
| "批量消化" / 给了文件夹路径 | batch-ingest |
| "关于 XX"、"查询" | query |
| "给我讲讲 XX"、"深度分析"、"综述" | digest |
| "对比一下 X 和 Y" / "整理时间线" | digest（特殊格式） |
| "检查知识库"、"健康检查"、"lint" | lint |
| "知识库状态"、"有多少素材" | status |
| "知识图谱"、"知识库地图" | graph |
| "删除素材"、"移除" | delete |
| "待审"、"review items" | reviews |
| "结晶化"、"把对话记进知识库" | crystallize |
重要：如果用户直接给了一个 URL 或文件，但没有明确说要做什么，默认走 ingest 工作流。如果知识库还不存在，先自动走 init 再走 ingest。
除 init 外，其他工作流默认先执行这段检查：
d:\Program Files\WorkBuddyDir）是否包含 .wiki-schema.md
~/.llm-wiki-path（C:\Users\13986\.llm-wiki-path）ingest / batch-ingest → 先运行 initquery / lint / status / digest / graph / delete → 提示用户先初始化知识库.wiki-schema.md.wiki-schema.md 的"语言"字段判断 WIKI_LANG
语言：中文 → WIKI_LANG=zh语言：English → WIKI_LANG=enWIKI_LANG=zh所有面向用户的输出和新写入的 wiki 内容，都按 WIKI_LANG 生成：
WIKI_LANG=zh → 使用中文WIKI_LANG=en → 使用英文术语对照：
| 中文 | English |
|---|---|
| 素材 | Source |
| 实体 | Entity |
| 主题 | Topic |
| 摘要 | Summary |
| 综合 | Synthesis |
| 消化 | Ingest |
| 对比 | Comparison |
| 深度报告 | Deep Dive Report |
| 知识图谱 | Knowledge Graph |
Ingest 和 batch-ingest 工作流遵循 Two-Step CoT 模式：Step 1 完整阅读原素材得到分析 JSON，Step 2 只基于分析 JSON 生成页面（不重复读原素材）。预算分配、部分读取规则、SHA256 缓存详见 references/token-optimization.md。
批量消化时，所有文件完成后执行一次交叉综合。完整步骤见 references/batch-cross-synthesis.md。
~/.llm-wiki-path 存在但当前目录不是知识库 → 提示用户已有知识库，询问新建还是切换询问知识库主题：
询问知识库语言：
zh（中文）或 en（English）zh询问保存位置：
~/Documents/我的知识库/（zh）或 ~/Documents/my-wiki/（en）D:\知识库\玉米知识库创建目录结构（用 Write 工具创建每个文件）：
知识库路径/
├── raw/
│ ├── articles/ # 网页文章
│ ├── tweets/ # X/Twitter
│ ├── wechat/ # 微信公众号
│ ├── xiaohongshu/ # 小红书
│ ├── zhihu/ # 知乎
│ ├── pdfs/ # PDF
│ ├── local/ # 本地文件
│ └── assets/ # 图片等附件
├── wiki/
│ ├── entities/ # 实体页
│ ├── topics/ # 主题页
│ ├── sources/ # 素材摘要
│ ├── synthesis/ # 综合分析
│ ├── comparisons/ # 对比分析
│ ├── queries/ # 查询记录
│ └── reviews/ # 待审项（人机协作）
├── purpose.md # 研究方向与目标
├── index.md # 索引
├── log.md # 操作日志
├── overview.md # 执行摘要
└── .wiki-schema.md # 配置文件
创建 .wiki-schema.md（知识库配置文件）：
---
主题: <用户指定的主题>
语言: 中文 | English
创建日期: YYYY-MM-DD
别名词表: # query/digest 时用于别名展开
LLM:
- 大语言模型
- 大模型
GS:
- 基因组选择
- genomic selection
---
将路径写入 ~/.llm-wiki-path（用 Write 工具）
创建 purpose.md：请用户填写研究目标、关键问题和研究范围
输出引导说明（按 WIKI_LANG 切换）：
zh：
知识库已创建！路径：<路径>
接下来你可以：
- 给我一个链接，我会自动提取并整理（网页、X/Twitter、公众号等）
- 给我一个本地文件路径（PDF、Markdown 等）
- 直接粘贴文本内容
- 批量消化：给我一个文件夹路径
推荐：用 Obsidian 打开这个文件夹，可以实时看到知识库的构建效果。
Token 优化详细策略见 references/token-optimization.md。
执行通用前置检查。
根据素材类型选择 WorkBuddy 原生工具：
URL 类素材：
WebFetch（内容转为 Markdown）baoyu-url-to-markdown skill（已安装），回退 WebSearchwechat-article-search skill，回退 WebSearchbaoyu-url-to-markdown skill 的 youtube adapter，回退手动提示WebFetch 尝试，失败则提示用户手动粘贴本地文件：
.md / .txt / .html → Read 直接读取.pdf → 用 markdown-converter skill（markitdown）或 Read 直接读取.docx / .pptx → 用 markdown-converter skill纯文本粘贴 → 直接使用
提取素材内容：按上面的路由获取素材文本。
保存原始素材到 raw/ 对应目录（用 Write 工具）：
{日期}-{短标题}.md![ 或 <img 或图片 URL）。如果检测到图片：
raw/assets/"images: {N} 和 image_paths: []读取上下文：
purpose.md > .wiki-schema.md > index.mdpurpose.md 存在，先读取核心目标和关键问题缓存检查（AI 级）：
.wiki-cache.json 中是否有相同哈希值{"<raw_file_path>": "<sha256_hash>", ...}Step 1 — 结构化分析（输出 JSON）：
purpose.md + 现有 wiki 结构（至少读取 index.md 概要和 new_vs_existing.updates 列出的已有页面）{
"source_summary": "一句话概括",
"entities": [
{"name": "xxx", "type": "concept", "relevance": "high",
"confidence": "EXTRACTED", "evidence": "原文摘录（≤50字）"}
],
"topics": [{"name": "xxx", "importance": "high"}],
"connections": [
{"from": "A", "to": "B", "type": "因果",
"confidence": "INFERRED", "evidence": "推理依据"}
],
"contradictions": [
{"claim_a": "...", "claim_b": "...", "context": "..."}
],
"new_vs_existing": {"new_entities": [], "updates": []},
"review_items": [
{"type": "create_page | deep_research | skip", "description": "...",
"reason": "为什么会触发待审", "suggested_queries": ["搜索词1", "搜索词2"]}
]
}
置信度赋值规则：
| 标注 | 含义 | evidence 要求 |
|---|---|---|
EXTRACTED | 原文直接陈述 | 必须，≤50字原文摘录 |
INFERRED | 从多处原文推断 | 必须，说明推理依据 |
AMBIGUOUS | 原文表述不清 | 可选 |
UNVERIFIED | 来自AI背景知识 | 可选 |
JSON 验证：输出后自我检查——确保 entities、topics、confidence 字段都存在。如果字段缺失，回退到单步流程（不进行 Step 2，新内容统一标注 confidence: UNVERIFIED）。
Step 2 — 页面生成（Token 优化版）：
purpose.md + 需要更新的已有页面（部分读取）new_vs_existing.updates 列出的已有页面，只读前 500 字 + YAML frontmatter；超 2000 字的页面用 grep 定位相关段落Review Items 生成规则（当 Step 1 分析中存在以下情况时生成）：
AMBIGUOUS 且对知识库核心主题重要 → 生成 review 建议用户确认INFERRED 且无直接原文支撑 → 生成 review 并预生成搜索词purpose.md 中标记的关键问题但无相关素材） → 生成 deep_research reviewtemplates/review-template.md 格式写入 wiki/reviews/生成素材摘要页（wiki/sources/{日期}-{短标题}.md）：
{SKILL_DIR}/templates/source-template.md 格式INFERRED / AMBIGUOUS 的条目，用 HTML 注释保留置信度：
<!-- confidence: INFERRED -->
.wiki-cache.json更新或创建实体页（wiki/entities/）：
templates/entity-template.md[[实体名]] 语法做双向链接更新或创建主题页（wiki/topics/）：
templates/topic-template.md更新 index.md：在对应分类下添加新条目，更新概览统计数字
更新 log.md：追加 ## {日期} ingest | {素材标题} 记录
向用户展示结果（按 WIKI_LANG）：
已消化：{素材标题}
新增页面：
- {素材摘要页}
- {新实体页1}
更新页面：
- {已有实体页2}
发现关联：
- 这篇素材和 [[已有素材]] 在 {某概念} 上有联系
raw/ 目录（同样检测图片）[待创建: [[概念名]]] 标记.md, .txt, .pdf, .html），忽略隐藏文件和系统目录references/token-optimization.md 的 Two-Step CoT 流程，先做缓存检查，命中则跳过references/batch-cross-synthesis.md 执行一次交叉综合使用 4 阶段混合查询管线：关键词搜索 → 图谱扩展 → 预算控制 → 上下文组装。
.wiki-schema.md 中的"别名词表"，如果用户的查询关键词命中某一组别名，将该组所有同义词纳入搜索（只在命中的组内展开，不跨组传递，自动去重）wiki/ 下用 Grep/Select-String 搜索所有关键词使用 4-Signal Relevance 模型，将 Phase 1 的前 5 个结果作为种子节点：
wiki/ 下所有页面的 YAML frontmatter（包含 type, sources[], 和 [[链接]]）读取最终选定的页面：
组装回答：
[[页面名]]）判断是否持久化：引用 3 个及以上来源时，询问用户是否保存
保存 query 页面（如用户同意）：
templates/query-template.md 生成页面wiki/queries/{date}-{short-hash}.md确定检查范围：
机械检查（AI 逐项执行）：
wiki/entities/ 下没有被其他页面 [[链接]] 引用的实体[[X]] 链接指向的 X.md 不存在AI 判断检查：
EXTRACTED / INFERRED / AMBIGUOUS / UNVERIFIED，高亮 AMBIGUOUS输出修复建议：按 WIKI_LANG 输出格式化的健康检查报告
询问用户：要自动修复哪些问题？
raw/ 子目录统计各来源文件数wiki/entities/、wiki/topics/、wiki/sources/、wiki/synthesis/、wiki/comparisons/ 各目录页面数purpose.md 是否存在WIKI_LANG）：
区别于 query：query 是快速问答（不生成新页面）；digest 是跨素材深度综合（生成持久化报告）。
wiki/synthesis/{主题}.md深度报告格式：背景 → 核心观点（附来源） → 不同视角对比 → 知识脉络 → 待解决问题 → 相关页面
对比表格式：维度对比表格 → 关键差异 → 相关页面
时间线格式：Mermaid gantt 图 + 事件说明（附来源）
使用 4-Signal Relevance 模型 计算节点间相关性。
| 信号 | 权重 | 说明 |
|---|---|---|
| Direct link | ×3.0 | 页面通过 [[wikilink]] 直接互相引用 |
| Source overlap | ×4.0 | 两个页面的 sources[] 字段指向同一原始源文件（权重最高） |
| Adamic-Adar | ×1.5 | 两个页面有共同邻居节点，根据邻居的度数加权 |
| Type affinity | ×1.0 | 两个页面属于同一类型（entity/entity, topic/topic 等） |
扫描双向链接：遍历 wiki/ 下所有 .md 文件，提取 [[链接]]
计算 4-Signal 相关性：
type, sources[] 字段）生成 Mermaid 图表 wiki/knowledge-graph.md：
graph LR 布局[3.5]）生成结构化数据 wiki/graph-data.json：
[
{"nodes": [{"id": "A", "type": "entity|topic|source", "connections": 5}], ...},
{"edges": [{"source": "A", "target": "B", "weight": 3.5, "signals": {"direct_link": 1, "source_overlap": 2, "adamic_adar": 0.5}}], ...}
]
wiki/knowledge-graph.html图谱洞察（随图谱一起输出）：
raw/ 和 wiki/sources/ 中定位.wiki-cache.json 中移除对应条目用户说"查看待审"、"pending reviews"、"有没有需要我确认的"时触发。
wiki/reviews/ 目录，列出所有 status: pending 的 review 页面status: declinedstatus 字段用户主动提供自己的思考、笔记、洞见（非外部素材）。
wiki/synthesis/sessions/{主题}-{日期}.md
confidence: INFERREDtemplates/synthesis-template.md需要创建或更新 wiki 页面时，先读取 references/file-format-spec.md 获取 YAML frontmatter 标准、置信度标注规则及各页面类型格式。生成页面时结合 templates/ 下对应模板。
Basierend auf der SOC-Berufsklassifikation
