# Pdd Extract Features

> PDD-Extract Features - 功能点提取技能

- Skill: `wonderslife/pdd-extract-features` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add wonderslife/pdd-extract-features`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wonderslife/pdd-extract-features/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wonderslife (https://skillmd.com/u/wonderslife)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wonderslife/pdd-extract-features

---


# PDD-Extract Features - 功能点提取技能

从业务分析结果和 PRD 文档中提取功能点，生成标准化的功能点矩阵 (feature-matrix.md)。

**输入**: 业务分析报告/PRD | **输出**: feature-matrix.md | **不负责**: 规格编写/代码实现

## 功能点分类

### 按复杂度
| 复杂度 | 代码 | 说明 | 开发时间 |
|-------|------|------|---------|
| 核心业务 | P0 | 核心流程，涉及多方审批 | 3-5天 |
| 重要功能 | P1 | 重要功能，有替代方案 | 1-2天 |
| 辅助功能 | P2 | 易于实现 | 0.5天 |

### 按操作类型
C(Create新增) | R(Read查询) | U(Update修改) | D(Delete删除) | B(Batch批量) | A(Approve审批) | E(Export导出) | F(Flow状态流转)

### 按AI角色
AI-L(AI主导) | AI-C(AI协作) | AI-R(AI辅助审核)

## 功能点提取流程

1. **分析业务用例**：从业务分析报告提取 参与者 | 用例名称 | 基本流程 | 扩展流程
2. **识别功能操作**：对每个用例识别 用例/操作/操作类型/复杂度/AI角色
3. **识别页面/接口**：功能点/页面路径/API路径/方法
4. **生成功能点矩阵**：模板见 `references/feature-matrix-template.md`
5. **P0功能点详情**：基本信息/功能描述/前置后置条件/输入字段/输出信息/业务规则/测试策略

## 功能点矩阵模板
完整模板（汇总表、详细列表、前端组件与数据源说明）见 `references/feature-matrix-template.md`。

## Guardrails

**必须遵守**：功能点ID全局唯一 | 每个功能点有明确操作类型 | 标注依赖关系 | P0功能点必须有详细描述
**避免**：❌遗漏关键业务操作 ❌循环依赖 ❌复杂度评估与实际不符

## 与其他技能协作
| 协作技能 | 方式 | 传入 | 期望输出 |
|---------|------|------|---------|
| pdd-ba | 顺序 | 业务分析报告 | 用例和流程 |
| pdd-generate-spec | 顺序 | 功能点矩阵 | spec.md |

## 人工审核
- **节点**：功能点矩阵生成后人工审核
- **内容**：完整性 | 复杂度(P0/P1/P2) | 测试策略 | 依赖关系
- **粒度**：批量审核 + 关键功能点(P0/复杂状态转换/外部集成/敏感数据)详细审核
- **输出**：`review-features.md` | 结果：passed / rejected / conditional

## Iron Law 铁律
1. **来源可追溯**：每个功能点必须可追溯到业务分析用例或PRD章节，不得凭空创造。
2. **粒度适中**：单功能点 = 单个可验收工作单元；过粗(一个FP含多个功能)或过细(拆分操作步骤)均违规。
3. **依赖显式化**：依赖必须明确声明，禁止循环依赖。
4. **复杂度有据**：P0/P1/P2 需明确标准（涉及审批/外部集成/核心规则），不得凭感觉定级。
5. **MECE完整验证**：提取后用 MECE 检验所有用例操作是否覆盖，有无遗漏辅助功能（导入导出/批量）。

**违规**：❌无法追溯的功能点 ❌"用户管理"作一个FP(过粗) ❌拆分表单步骤(过细) ❌循环依赖 ❌全P0或全P2
**合规**：✅标注"源自UC-xxx" ✅FP-001=完整"发起申请" ✅标注FP-005依赖FP-001 ✅P0理由"多级审批+状态机" ✅MECE后覆盖全部CRUD

## Rationalization 理性化对照
| # | 陷阱 | 应该怎么做 |
|---|------|-----------|
| 1 | 功能太小不值得列FP | 独立可验收的操作都应列为FP |
| 2 | PRD没写但我觉得要有 | 标"建议功能"单独列出，请用户确认 |
| 3 | 依赖太复杂先不管 | 至少标注直接依赖，传递依赖实施期细化 |
| 4 | 全标P0比较保险 | 严格按标准分级，P0通常≤总数的30% |
| 5 | 测试策略后面再想 | 每个P0定义正向+异常两个测试场景 |

**常见陷阱**：粒度失控(建立参考标准) | 隐含依赖(强制前置条件审查) | P0通胀(量化评估标准) | 测试盲区(每FP含基本测试场景)

## Red Flags 红旗警告

**Layer 1 输入防护**
- INPUT-FE-001: 报告为空/缺用例章节 → 🔴 终止，先完成业务分析
- INPUT-FE-002: PRD与报告矛盾 → 🟡 记录，以PRD为准并标注
- INPUT-FE-003: 缺CRUD矩阵/状态图 → 🔴 提示补充完整

**Layer 2 执行防护**
- EXEC-FE-001: 无法追溯到用例/PRD的功能点 → 🔴 删除或补来源引用
- EXEC-FE-002: ID重复/命名不规范 → 🟡 重新编号保持全局唯一
- EXEC-FE-003: 循环依赖(A→B→A) → 🔴 拆解/合并功能点消除循环
- EXEC-FE-004: P0缺详细描述 → 🔴 补充完整

**Layer 3 输出防护**
- OUTPUT-FE-001: 缺汇总统计(按复杂度/操作类型) → 🔴 补统计表
- OUTPUT-FE-002: 总数为0或过少 → 🔴 复查分析报告
- OUTPUT-FE-003: 格式不符模板 → 🟡 调整格式

**处理流程**：🔴 CRITICAL→立即停止报告等待指示 | 🟡 WARN→记录自动修复并标注 | 🔵 INFO→记录正常继续