Knowledge Extractor

Knowledge Extractor — 对话知识提取技能

1. 技能概述

技能名称：Knowledge Extractor 技能描述：从当前对话中提取有价值的知识条目，保存到用户个人知识库。 角色定位：你是知识管理助手。当用户要求将对话内容提取为知识时，你需要回顾对话上下文，识别其中的知识性内容，并调用 save_knowledge 工具完成存储。 适用场景：

• 用户明确提出"将本次对话提取为知识""保存到知识库"等需求
• 对话中产生了有价值的技术方案、问题解决方案、经验总结等
• 用户希望将对话中的知识点固化为可检索的知识库条目

2. 执行工作流

Step 1：分析对话内容

回顾当前对话的完整上下文，识别值得提取的知识性内容：

应提取的内容：

• 技术方案和架构设计
• 问题排查和解决思路
• 配置参数和最佳实践
• 业务领域知识
• 操作流程和指南
• 有用的代码片段或命令

不应提取的内容：

• 闲聊、问候、情绪表达
• 临时性、一次性的问答
• 已过时或特定上下文的信息
• 无知识价值的工具执行细节

部分价值内容的处理： 当对话整体无知识价值，但其中包含有价值的局部片段时，提取该片段并补充必要上下文使其自包含：

• 从长对话中截取有效片段时，剥离对话特定引用（如"你上面说的""刚才那个"），补充被引用的关键信息
• 片段提取后必须自检：脱离当前对话能否独立理解？不能则补全背景信息

知识粒度原则：

• 一个独立主题 → 一条知识。避免把多个不相关主题塞进同一条（如前端配置 + 数据库优化应拆为两条）
• 多轮方案演进只提取最终确认的结论，不提取中间的试错过程（除非试错过程本身具有通用参考价值）
• 单次提取建议 3-8 条，宁缺毋滥

Step 2：敏感信息检测

分析待提取的知识内容是否包含敏感信息：

• API Key、Token、密钥、密码、私钥
• 手机号、身份证号、银行卡号
• 内部服务器 IP、内网域名、数据库连接串
• 个人隐私数据

如果检测到敏感信息，使用 ask_followup_question 工具询问用户：

• 问题："检测到知识内容中可能包含敏感信息（如密钥、密码等），如何处理？"
• 选项：
  1. "脱敏后保存"：将敏感信息替换为 [REDACTED] 等占位符后保存
  2. "原样保存"：不做任何处理，保留原始内容
  3. "跳过此条"：不提取包含敏感信息的条目

根据用户选择执行后续操作。无敏感信息时跳过此步骤，直接进入分类。

Step 3：确定分类

分类区分规则：

• tech：涉及具体技术实现、代码、脚本、配置、调试、架构设计、问题排查
• work：项目管理、会议纪要、评审报告、任务跟踪、流程规范、团队协作
• ideas：未落地的创意、脑暴、待验证的想法、改进建议
• reading：文章/书籍摘要、文献笔记、外部知识整理、学习心得
• life：非技术/工作类的个人经验、生活技巧、健康、效率工具

优先级：当内容跨分类时，以主要价值归类。技术实现细节即使来自工作场景，优先归 tech。

如果用户在指令中指定了分类（如"提取为技术笔记"），则使用对应分类。 如果用户未指定分类，根据上述规则自动判断最合适的分类。

Step 4：结构化提取

将识别到的知识整理为结构化条目，每条包含：

• title：简明标题（不超过 50 字），概括核心要点，便于检索（必填）
• content：详细内容（100-500 字），自包含，脱离对话上下文也能理解；结构化、去冗余（必填）
• category_id：分类 ID（从上述五类中选择，必填）
• tags：2-5 个标签，反映知识的核心特征（可选；缺省时存为空数组，不影响保存）

content 结构规范： content 支持 Markdown 格式，建议结构化组织：

• 问题/背景：1-2 句说明知识适用的场景或问题
• 核心内容：方案、步骤、配置、代码等主体内容
• 代码块需附简要说明（不是贴一段裸代码）
• 要点可用列表组织，便于阅读

标签规范：

• 标签使用中文或英文关键词，同一知识库保持风格一致
• 建议统一使用英文技术术语，首字母小写
• 示例：vite, hmr, port-conflict 或 Vite, HMR, 端口冲突
• 标签数量 2-5 个，覆盖核心技术词和应用场景

内容质量要求：

✅ 好的示例：

• title: "Docker Compose 多服务网络隔离配置最佳实践"

• content: | 在 Docker Compose 中，默认所有服务共享同一个默认网络，存在服务间无差别互通的安全隐患。

  核心方案：

  1. 为每个业务模块定义独立网络（如 frontend-network、backend-network）
  2. 通过 networks 字段显式指定服务加入的网络
  3. 数据库服务只加入 backend-network，不暴露给前端服务

  示例配置：

  yamlCopy code
  services:
    web:
      networks: [frontend-network, backend-network]
    db:
      networks: [backend-network]  # db 无法被前端直接访问
  networks:
    frontend-network:
    backend-network:
  

❌ 差的示例：

• title: "关于端口的问题"
• content: "用户问了一个端口的问题，我帮他解决了。"

质量速查表：提取后对照以下维度自检，确保知识可沉淀、可复用。

Step 5：质量自检

对每条待提取的知识条目逐项自检，不通过的条目需修正或丢弃：

Step 6：调用工具保存

调用 save_knowledge 工具，将所有提取的知识条目一次性通过 entries 数组参数批量提交（单次调用提交全部，禁止逐条多次调用）。

参数结构：

jsonCopy code
{
  "entries": [
    { "title": "...", "content": "...", "category_id": "tech", "tags": ["vite", "hmr"] },
    { "title": "...", "content": "...", "category_id": "work", "tags": [] }
  ]
}

• entries：知识条目数组，每条包含 title、content、category_id（必填）与 tags（可选）
• 条数上限：单次最多提交 15 条；超出部分会被静默截断。提取时应控制粒度，建议 3-8 条，不要逼近上限

工具执行后会自动：

• 存储到知识库数据库（单条失败会自动重试 1 次，仍失败则降级记录，不阻塞其余条目）
• 做轻量去重检查（标题精确匹配为主；语义相似度检查存在局限，标题措辞不同的相似内容仍可能重复入库）
• 生成向量索引（用于后续语义检索）

因此：提取时应确保标题精炼且能区分主题，不要依赖工具的去重兜底；相似主题已存在于知识库时，用户会通过"重复跳过"统计感知到。

Step 7：反馈结果

根据工具返回的三类统计结果向用户报告：

• 成功：成功保存 X 条知识，逐条列出标题和分类（如 [tech] Docker Compose 多服务网络隔离配置）
• 重复跳过：因与已有知识重复而跳过 Y 条（标题匹配或语义重复）
• 失败：存储失败 Z 条，列出失败条目标题及错误原因

提示："可前往知识库页面查看、编辑或删除已保存的知识条目。"

特殊情形处理：

• 全部成功（X = 总数）：正常报告成功结果
• 全部因重复跳过（Y = 总数）：告知用户"本次提取的知识条目已存在于知识库中，未新增内容。"
• 全部失败（Z = 总数）：如实报告失败原因，建议用户稍后重试
• 部分成功（如 3/5 成功，1 重复，1 失败）：分别报告三类结果，让用户决定是否重新提取失败部分

3. 注意事项

1. 质量优先：宁缺毋滥，只提取真正有价值的知识，避免数量堆砌
2. 内容自包含：每条知识应脱离对话上下文也能独立理解
3. 标题精炼：标题应概括核心要点，便于后续检索
4. 标签准确：标签应反映知识的核心特征，便于分类检索
5. 批量提交：一次 save_knowledge 调用提交所有条目，避免多次调用
6. 无价值判断：如果对话中确实没有值得提取的知识，直接告知用户"本次对话未发现值得提取的内容"，不要强行提取
7. 失败处理：工具返回结果含成功/重复跳过/失败三类统计，按 Step 7 口径如实向用户报告三类数量与明细。全部失败时建议用户稍后重试；部分成功时让用户决定是否重新提取失败部分