kb-active-capture

Category: Docs & Knowledge | Uploader: Yuanyi-Ma | Downloads: 0 | Version: v1.0（Latest）
忆织知识提取（对话型）— 当用户在聊天中主动要求"提取知识"、"总结要点"、"提炼思路"、"复盘记录"时触发。自动过滤闲聊和低价值内容，仅提取核心知识点入库。注意：如果是让从现成的【长篇独立文档文件】中提取，请勿使用本技能。
Changelog: Source: GitHub https://github.com/Yuanyi-Ma/Memloom
Directory Structure

Current level: skills/kb-active-capture/
📄 SKILL.md 6.6 KB
SKILL.md

---
name: kb-active-capture
description: 忆织知识提取（对话型）— 当用户在聊天中主动要求"提取知识"、"总结要点"、"提炼思路"、"复盘记录"时触发。自动过滤闲聊和低价值内容，仅提取核心知识点入库。注意：如果是让从现成的【长篇独立文档文件】中提取，请勿使用本技能。
---

# 忆织知识提取

## 触发场景

当用户在对话中**主动要求**以下操作时使用此技能：
- "帮我提取这段对话的知识"
- "总结一下刚才讨论的要点"
- "提炼一下这段排查的思路"
- "复盘一下刚才的选型过程"

## 任务目标

你是一个严格结构化的数据提取程序。请严格按照以下过滤规则和分类逻辑，分析当前对话记录并提取核心信息。

## 步骤一：基础过滤（强制执行）

回顾当前对话记录，根据以下两方面原则进行过滤：

**原则一：通用规则（以下内容不提取）：**
- 超过 5 行的具体代码实现或长篇系统报错日志
- 文本润色、翻译、日常闲聊
- 常规的软件安装步骤或环境依赖排查
- 简单的语法错误纠正、单词拼写、格式排版
- 基础的工具使用说明、API 参数查询（搜索引擎能快速查到的内容）
- 没有逻辑推导过程的机械问答

**原则二：复利规则（读取用户的历史偏好）：**
请读取文件 `~/.memloom/feedback/rejected.md`（如果存在），其中记录了用户曾经删除过的知识类型。这些内容也不应再次提取。

**如果根据以上两方面原则过滤后，对话中没有剩余有价值的内容**，直接告知用户「📭 当前对话暂无值得提取的核心知识」并停止。否则继续。

## 步骤二：场景分类与特定提取规则

对通过过滤的有价值内容，判断其所属场景，按对应规则提取：

1. **编程与架构场景：**
   - 必须提取：系统选型时的妥协与取舍（牺牲了什么换取了什么）、导致复杂问题的底层运行机制（如内存分配、并发冲突机制）
   - 禁止提取：常规的业务增删改查逻辑、特定框架的基础用法、正则表达式写法

2. **论文与学术场景：**
   - 必须提取：该研究填补的核心理论空白、推导结论所依赖的关键假设或边界条件
   - 禁止提取：论文摘要的直白翻译、基础数学公式的推算过程、常规的文献列举

3. **其他通用场景：**
   - 必须提取：解决某一类复杂问题的通用思维模型或因果分析逻辑

### 知识粒度原则（严格遵守）

**一次连贯的问答 = 一个知识单元 = 一张卡片。** 判断粒度的依据是对话结构，而不是内容中涉及了几个子概念：

- 如果用户问了一个问题，AI 给了一个完整回答（即使回答中包含多个对比项、多个子概念），这属于**一个知识单元**，应当合并为一张卡片
- 例如：用户问"同步和异步共识的区别"，AI 回答中分别介绍了两者 → 这是**一张卡片**（标题如"同步与异步共识的核心权衡"），不要拆成"同步共识"和"异步共识"两张
- detail 中应当覆盖子概念间的**关联、对比和权衡**，而不是孤立地描述每个子概念
- **只有当对话中出现了明确不同的话题转换**（用户问了完全不相关的新问题），才应生成多张卡片

## 步骤三：去重检查（必须执行）

在生成卡片之前，你必须对每个候选知识点执行以下去重流程：

1. **API 查重**：对每个候选知识点，执行以下命令搜索已有卡片（返回含 title/brief/detail 的完整信息）：
   ```bash
   curl -s -X POST http://127.0.0.1:3000/api/cards/check-duplicate \
     -H 'Content-Type: application/json' \
     -d '{"title": "<候选知识的标题或核心关键词>"}'
   ```
2. **比对判定**：如果返回了 `duplicates` 列表，对比候选知识与已有条目的 detail，核心概念和阐述逻辑基本一致（即使措辞不同）则判定为重复
3. **跳过重复**：确认重复的知识点不生成卡片，在最终结果中告知用户「已跳过 N 条与已有知识重复的内容」

> 如果 API 返回无相似条目，直接进入步骤四。

## 步骤四：获取分类列表

执行以下命令获取当前可用的分类列表：

```bash
curl -s http://127.0.0.1:3000/api/config/categories
```

后续构造卡片时，category 字段必须严格使用返回列表中的值，并遵循**顺序梯度规则**：按照 API 返回的分类列表顺序，从第一个分类开始逐一判断，一旦知识点符合某个分类就归入该分类，不再考虑后续分类。列表越靠前优先级越高。

## 步骤五：构造卡片

对每个候选知识点，构造以下字段：

- **title**: 15 字以内，提炼核心概念
- **category**: 严格使用步骤四返回的分类列表中的值
- **tags**: 相关标签数组
- **brief**: 100 字以内，高度概括其运作机制
- **detail**: 用 150-300 字，客观严密地阐述其底层逻辑和成立条件。禁止包含原对话中的大段代码或公式，必须转化为通用的原理解释。如果知识点本身是事实性声明（如政策定义、历史事件），不要仅罗列事实，而应侧重阐明它为什么被提出、它解决了什么底层问题、以及它在技术或理论体系中的结构性位置。
- **review_question**: 构造一道必须运用 detail 中原理进行推理或取舍分析才能回答的场景应用题。规则：1. 必须设定一个 detail 中未直接出现的全新具体场景；2. 答案必须依赖 detail 中的原理进行推导，不能靠背诵事实回答；3. 自检：如果此题可以仅靠记住一个名称、日期、定义就答对，必须重新出题。

## 步骤六：服务端校验

构造完成后，调用校验 API 对每张卡片进行字段合法性校验：

```bash
curl -s -X POST http://127.0.0.1:3000/api/cards/validate \
  -H 'Content-Type: application/json' \
  -d '{"card": {"title": "...", "category": "...", "tags": [...], "brief": "...", "detail": "...", "review_question": "..."}}'
```

如果返回 `{"valid": false, "errors": [...]}` 则根据错误提示修正卡片内容，重新校验直到返回 `{"valid": true}`。

## 步骤七：执行入库

校验通过后，将卡片通过 HTTP API 入库（可一次提交多张）：

```bash
curl -s -X POST http://127.0.0.1:3000/api/cards/ingest \
  -H 'Content-Type: application/json' \
  -d '{"cards": [{"title": "...", "category": "...", "tags": [...], "brief": "...", "detail": "...", "review_question": "..."}]}'
```

成功后 API 返回 `{"ingested": N, "cards": [...]}` 。向用户展示成功入库的结果。
Comments 0
Latest | Hot
Please login before commenting.
No comments yet. Be the first one!
kb-active-capture

Directory Structure

SKILL.md

Report

Notice
