name	knowledge-extractor
description	从会话中提取操作性知识的工具。识别工作流程、工具序列、最佳实践，保存到文档、规则或脚本。避免经验流失，识别自动化机会，建立知识库。适用于知识管理、经验总结、工作流提取。当用户提到"总结经验"、"提取知识"、"记录流程"时使用。
license	Apache-2.0
metadata	[object Object]

知识提取器 (Knowledge Extractor)

🛠️ MCP 联动增强

本技能可与以下 MCP 工具联动：

Notion: 使用 mcp_Notion_create_page 或 mcp_Notion_append_block 将提取的知识同步到 Notion 知识库。
Obsidian: 使用 mcp_Obsidian_write-file 将工作流和经验记录到本地 Obsidian 库。
Everything Search: 使用 mcp_EverythingSearch_search 快速检索项目中已有的知识文档，避免重复提取。
Memory: 使用 mcp_Memory_add_observations 将核心经验记录到长期记忆中。

定位与边界

与 doc-manager 的区别：

knowledge-extractor：侧重从对话/工作中提取隐性知识（生成规则、脚本、流程文档）

doc-manager：侧重已有文档的整理（格式统一、结构优化、去重合并）

简单判断：

刚完成一段工作，想把经验沉淀下来 → knowledge-extractor

有一堆杂乱文档要整理 → doc-manager

与 deep-research-report 的区别：

knowledge-extractor：从自己的工作经验中提取知识

deep-research-report：基于外部资料生成研究报告

触发场景

当用户提到以下关键词时使用本技能：

提取知识、总结经验、reflect
记录流程、工作流提取
识别模式、自动化机会
保存经验、知识沉淀

核心价值

捕获"如何工作"而非"构建了什么"

从会话记忆中提取：

🔄 可复用的工作流程
🛠️ 有效的工具序列
⚠️ 常见错误及纠正模式
💡 发现的最佳实践
🤖 自动化机会

核心功能

📊 会话分析

分析会话中的操作序列
识别重复模式
提取成功的解决方案
发现失败模式和规避方法

🔍 知识分类

自动识别知识类型并路由到合适位置：

工作流程 → CLAUDE.md 或 docs/WORKFLOW.md
- 端到端的操作流程
- 多步骤序列
- 决策树
跨项目通用规则 → .claude/rules/
- 可复用的工作约定（例如提交规范、通用检查清单、通用流程原则）
- 不依赖某个具体项目的细节
项目特定规则 → 项目文档（例如 docs/PROJECT_RULES.md）
- 与当前项目强绑定的约束（例如目录结构、特定模块约定、项目内 API/命名规则）
- 需要团队可见/可审阅的说明
用户偏好 → .claude/rules/user-preferences.md
- 个人工作习惯
- 通用偏好设置
- 跨项目适用的规则
自动化脚本 → scripts/ 或 commands/
- 可自动化的重复任务
- 工具链脚本
- 构建/部署流程
技能改进 → 技能改进建议文档
- 发现的技能缺陷
- 新技能需求
- 技能优化建议

📝 知识文档化

结构化的知识表示
Markdown格式输出
包含上下文和示例
注明适用场景

🤖 自动化识别

识别以下自动化机会：

重复执行的命令序列
固定模式的文件操作
可脚本化的工作流
可以变成技能的流程

知识提取流程

会话内容
    ↓
分析操作序列
    ↓
识别模式和流程
    ↓
分类知识类型
    ↓
生成文档内容
    ↓
保存到合适位置
    ↓
验证和确认

使用示例

基本用法

# 用户输入
提取这次会话的知识 / reflect

# 技能输出
🔍 分析会话内容...

发现以下可提取的知识：

1. 工作流程 (2个)
   - FastAPI项目初始化流程
   - 数据库迁移标准流程

2. 自动化机会 (1个)
   - 重复执行的测试命令可以脚本化

3. 项目规则 (1个)
   - API接口命名规范

是否开始提取？

指定主题提取

# 用户输入
提取关于数据库迁移的知识

# 技能输出
📚 提取"数据库迁移"相关知识...

## 数据库迁移标准流程

**场景**: 修改数据模型后需要更新数据库

**步骤**:
1. 修改models.py中的模型定义
2. 生成迁移: `alembic revision --autogenerate -m "描述"`
3. 检查生成的迁移文件
4. 应用迁移: `alembic upgrade head`
5. 验证数据库结构

**常见问题**:
- 忘记导入新模型 → 迁移不包含新表
- 解决方案: 确保__init__.py导入所有模型

**最佳实践**:
- 迁移描述要清晰具体
- 每次迁移只做一件事
- 提交代码前测试迁移的升级和降级

保存到: docs/WORKFLOW.md#数据库迁移

（说明：当输出不是“流程文档”时，默认建议优先落到 `.claude/rules/`。）

识别自动化机会

# 用户输入
识别自动化机会

# 技能输出
🤖 发现以下自动化机会：

1. **测试+提交流程** (重复执行7次)
   当前手动步骤:
   ```bash
   pytest
   git add .
   git commit -m "..."
   git push

建议: 创建脚本 scripts/test-and-commit.sh

#!/bin/bash
pytest || exit 1
git add .
git commit -m "$1"
git push

数据库重置流程 (重复执行3次) 当前手动步骤:
```
alembic downgrade base
alembic upgrade head
python seed_data.py
```
建议: 创建脚本 scripts/reset-db.sh

是否创建这些脚本？


## 输出格式

### 工作流程文档
```markdown
## [流程名称]

**适用场景**: [什么时候用]

**前置条件**:
- [条件1]
- [条件2]

**步骤**:
1. [步骤1] - [命令/操作]
2. [步骤2] - [命令/操作]
3. [步骤3] - [命令/操作]

**常见问题**:
- [问题] → [解决方案]

**最佳实践**:
- [实践1]
- [实践2]

**示例**:
```bash
[实际命令示例]

相关资源:

[文档链接]


### 项目规则
```markdown
# [规则类别]

## [具体规则]

**说明**: [为什么有这个规则]

**应用场景**: [什么时候应用]

**示例**:
✅ 正确:

[正确示例]


❌ 错误:

[错误示例]

提取策略

何时提取

推荐时机:

✅ 完成重要功能后
✅ 解决复杂问题后
✅ 上下文即将清理前
✅ 发现新的工作模式后
✅ 每天工作结束时

避免时机:

❌ 工作刚开始
❌ 还在探索阶段
❌ 没有明确成果时

提取粒度

合适的粒度:

✅ 完整的端到端流程
✅ 可复用的操作序列
✅ 解决特定问题的方法

避免的粒度:

❌ 单个命令（太细）
❌ 整个项目开发过程（太粗）

知识库结构

建议的项目知识库结构：

project-root/
├── .claude/
│   └── rules/
│       ├── project-conventions.md    # 项目规范
│       ├── tech-stack.md            # 技术栈规则
│       └── user-preferences.md       # 用户偏好
├── docs/
│   ├── WORKFLOW.md                   # 工作流程集合
│   ├── LEARNINGS.md                  # 经验教训
│   └── AUTOMATION.md                 # 自动化指南
├── scripts/
│   ├── dev/                          # 开发脚本
│   └── ops/                          # 运维脚本
└── CLAUDE.md                         # 项目级指令和流程

最佳实践

✅ 推荐做法

及时提取
- 趁记忆新鲜时提取
- 不要等到会话结束
保持结构化
- 使用统一的模板
- 分类清晰
- 易于查找
包含上下文
- 记录为什么
- 说明适用场景
- 提供示例
定期回顾
- 更新过时的知识
- 合并重复的内容
- 删除无用的条目

❌ 避免做法

过度提取
- 不要提取显而易见的知识
- 不要提取一次性的解决方案
缺少上下文
- 不要只记录步骤
- 不要忽略背景和原因
分散存储
- 不要随意创建新文件
- 遵循知识库结构

输出契约（必须包含）

知识提取输出必须包含：

提取范围：本次从哪些会话/哪些主题提取。
知识分类结果：至少包含“工作流程 / 项目规则 / 自动化机会”中的适用项。
可落地产物：给出建议写入的目标文件路径与章节位置（路由策略：跨项目通用规则优先 .claude/rules/；项目特定规则建议写入项目 docs/；如明确是流程文档亦可落到 docs/）。
示例：至少 1 个可直接复用的流程/规则示例。
下一步：建议如何在后续工作中复用这条知识。

真实性约束（必须）

只提取“真实发生/用户确认过”的流程与结论：不得把推测当事实。
不确定时必须标注：使用“推测/待验证/需确认”的标签，并列出验证方式或需要用户补充的信息。
避免虚构细节：如命令、路径、版本号、团队约定等无法从上下文确定，必须显式说明来源与不确定性。

边界条件与失败策略

会话信息不足：先询问要提取的主题/范围，或让用户贴出关键片段（提醒脱敏）。
不确定写入位置：按路由策略给出建议（跨项目通用规则 → .claude/rules/；项目特定规则/流程文档 → docs/），并标注“建议”；必要时先询问用户落点偏好。
无法写文件：在对话中输出完整文档草案与建议落盘路径。

最小失败输出（必须）

当无法完成提取/分类/落盘建议时，仍必须输出：

失败原因：信息不足/证据不足/权限限制/目标不明确。
已可交付内容：例如“可提取主题列表/候选分类/模板草案”。
需要用户补充的信息：最少清单（含脱敏提示）。
下一步：给出 1-3 条可执行建议。

合规与安全（统一规则）

不把用户隐私/密钥写入规则或文档；涉及敏感信息必须替换为占位符。
如需写入项目文件，先确认写入目标与覆盖策略。
统一规范详见：../../STANDARDS.md

配置项对齐（config.yaml）

skills.knowledge-extractor.auto_categorize（默认 true）：是否自动分类。
skills.knowledge-extractor.default_location（默认 .claude/rules/）：默认建议落点（跨项目通用规则优先沉淀在规则库；项目特定规则/流程文档通常落到 docs/）。

版本: 2.0
分类: 生产力工具
依赖: 无

knowledge-extractor

Install Skill

SKILL.md