name: 文档提取 description: 从包括PDF、Word文档、会议记录、规格说明和Web内容在内的现有文档中提取需求。识别需求候选，分类并输出为预规范格式。 allowed-tools: 读取, Glob, Grep, 写入, 任务, WebFetch

文档提取技能

从现有文档源中提取需求，以系统地进行需求挖掘。

何时使用此技能

关键词: 提取需求、文档挖掘、PDF需求、记录分析、解析文档、现有文档、遗留需求、竞争分析

在以下情况下调用此技能：

从现有文档中挖掘需求
处理会议记录以获取需求
从竞争对手产品中提取需求
分析监管文档以获取合规需求
将遗留文档转换为结构化需求

支持的文档类型

类型	扩展名	提取方法
Markdown	.md	直接读取
文本	.txt	直接读取
PDF	.pdf	读取工具（PDF支持）
Word	.docx	读取工具
网页	URL	WebFetch工具
会议笔记	.md, .txt	记录模式
规格说明	.md, .docx	需求模式

提取工作流程

步骤 1: 文档评估

分析文档以确定提取策略：

document_assessment:
  path: "{文件路径或URL}"
  type: "{检测到的文档类型}"
  size: "{近似大小}"
  structure:
    has_sections: true|false
    has_lists: true|false
    has_tables: true|false
  quality:
    formal_language: true|false
    clear_requirements: true|false
    needs_interpretation: true|false

步骤 2: 模式匹配

应用需求检测模式：

显式需求标记:

- "系统应当..."
- "系统必须..."
- "用户应当能够..."
- "REQ-XXX:"
- 编号需求 (1.1, 1.2, 等)

EARS模式:

- "当[触发], [系统]应当[响应]"
- "在[状态]期间, [系统]应当[行为]"
- "在[功能]处, [系统]应当[行为]"
- "如果[条件], 则[系统]应当[响应]"

隐式需求指示器:

- "重要的是..."
- "我们需要..."
- "目标是..."
- "用户期望..."
- "性能应当..."

步骤 3: 需求提取

对于每个识别的需求：

extracted_requirement:
  id: REQ-{序列}
  text: "{清理后的需求陈述}"
  source: 文档
  source_file: "{文件路径}"
  source_location: "{节/页/行}"
  original_text: "{文档中的精确文本}"
  type: 功能性|非功能性|约束|假设
  confidence: 高|中|低
  extraction_method: 显式|模式|推断
  needs_review: true|false
  review_notes: "{为何需要审查}"

步骤 4: 分类

分类提取的需求：

categories:
  功能性:
    - 特征
    - 行为
    - 交互
  非功能性:
    - 性能
    - 安全性
    - 可用性
    - 可靠性
    - 可扩展性
  约束:
    - 技术
    - 业务
    - 监管
  假设:
    - 环境
    - 用户行为
    - 依赖项

步骤 5: 去重

识别并合并重复需求：

deduplication:
  strategy: 语义相似性
  threshold: 0.8
  action: 合并|标记为审查
  merged_requirements:
    - id: REQ-merged-001
      sources: [REQ-001, REQ-015]
      text: "{合并后的需求}"

文档特定策略

会议记录

transcript_extraction:
  focus_on:
    - 行动项
    - 做出的决定
    - 讨论的需求
    - 提出的担忧
  patterns:
    - "我们决定..."
    - "需求是..."
    - "行动项:"
    - "待办:"
    - "需要..."
  speaker_context:
    - 记录谁说
    - 根据说话者角色加权

监管文档

regulatory_extraction:
  focus_on:
    - 强制性需求 ("应当", "必须")
    - 禁止操作 ("不应当", "不能")
    - 条件性需求 ("如果...则")
  compliance_mapping:
    - 参考节号
    - 记录生效日期
    - 跟踪版本/修订

竞争分析

competitor_extraction:
  focus_on:
    - 特征描述
    - 用户能力
    - 独特卖点
  output:
    - 特征需求
    - 差异化机会
    - 差距识别
  confidence: 低  # 基于外部观察

遗留规格

legacy_extraction:
  focus_on:
    - 现有需求
    - 系统行为
    - 集成点
  modernization:
    - 更新术语
    - 转换为EARS格式
    - 标记已弃用需求

输出格式

每文档输出

extraction_result:
  source:
    file: "{路径或URL}"
    type: "{文档类型}"
    extraction_date: "{ISO-8601}"
    confidence: 高|中|低

  statistics:
    total_candidates: {数字}
    extracted: {数字}
    filtered: {数字}
    needs_review: {数字}

  requirements:
    - id: REQ-{数字}
      text: "{需求}"
      type: 功能性|非功能性|约束
      source_location: "{节/页}"
      confidence: 高|中|低
      original_text: "{精确源文本}"

  review_items:
    - requirement_id: REQ-{数字}
      reason: "{为何需要审查}"
      suggestion: "{建议操作}"

  metadata:
    sections_processed: {数字}
    extraction_patterns_used: ["{模式名称}"]

自主级别

引导模式

guided_behavior:
  document_selection: 人工选择
  extraction_strategy: AI建议, 人工批准
  each_requirement: AI高亮, 人工确认
  categorization: AI建议, 人工验证

半自主模式

semi_auto_behavior:
  document_selection: AI建议优先级, 人工批准列表
  extraction_strategy: AI自主选择
  requirements: AI提取所有, 人工批量审查
  categorization: AI分类, 人工抽查

全自主模式

full_auto_behavior:
  document_selection: AI处理所有相关
  extraction_strategy: AI根据文档优化
  requirements: AI提取、去重、分类
  output: 完整提取报告供最终审查

质量指标

高信心提取

显式需求标记 (“应当”, “必须”)
EARS模式匹配
编号需求列表
清晰的命令陈述

中信心提取

隐式指示器 (“应当”, “需要”)
上下文依赖解释
部分模式匹配
需要领域知识

低信心提取

从描述推断
叙述文本解释
竞争分析
基于上下文的假设

委派

对于相关任务，委派给：

差距分析: 检查提取需求的完整性
领域研究: 研究不熟悉的术语或概念
启发方法: 路由回技术选择

输出位置

保存提取结果到：

.requirements/{域}/documents/DOC-{文件名}-{时间戳}.yaml