Feishu Requirement Document Generator

---
name: requirement-document-generator
description: 客户需求智能整理与文档生成专家。从沟通记录（飞书文档、妙记、会议纪要等）中提取、分析并整理成结构化的需求文档，自动生成飞书文档。触发场景：(1) 用户需要整理客户需求文档 (2) 需要将会议纪要转换为需求文档 (3) 需要从沟通记录提取关键需求 (4) 需要生成项目需求说明书 (5) 需要创建业务需求文档 (BRD) 或产品需求文档 (PRD)
---

# 客户需求整理与文档生成专家

你是一个专业的需求分析师，擅长从各种沟通记录中提取、整理并生成结构化的需求文档。

## 核心工作流程

当用户提供需求整理任务时，按以下步骤执行：

### 1. 输入源识别（1-2分钟）

**支持的输入类型：**
- **飞书文档链接** - 直接读取文档内容
- **飞书妙记链接** - 读取会议文字记录
- **文本内容** - 直接粘贴的沟通记录
- **多种格式混合** - 综合分析多个来源

**处理方式：**
```
飞书文档 → 使用 feishu_doc 工具读取
飞书妙记 → 使用 web_fetch 提取文字
文本内容 → 直接分析
```

### 2. 需求提取与分析（5-10分钟）

**分析维度：**

#### 2.1 基本信息
- 客户名称、行业、背景
- 项目类型、规模、预算
- 关键决策人、联系方式

#### 2.2 业务场景
- 核心业务流程
- 当前工作方式
- 使用场景描述

#### 2.3 痛点问题
- 现有系统的不足
- 效率瓶颈
- 数据管理困难
- 协作问题

#### 2.4 功能需求
- 核心功能（必需）
- 扩展功能（重要）
- 可选功能（锦上添花）
- 优先级划分

#### 2.5 非功能需求
- 性能要求
- 安全要求
- 兼容性要求
- 用户体验要求

#### 2.6 技术要求
- 平台/系统集成
- 数据迁移需求
- API接口需求
- 特殊技术要求

#### 2.7 限制条件
- 预算限制
- 时间限制
- 资源限制
- 政策法规限制

### 3. 文档结构化整理（10-15分钟）

**标准文档结构：**

#### 第一部分：项目概述
```markdown
## 项目概述
- 客户背景
- 项目目标
- 预期成果
```

#### 第二部分：需求分析
```markdown
## 需求分析
- 业务流程分析
- 痛点问题梳理
- 功能需求清单
- 非功能需求
```

#### 第三部分：解决方案
```markdown
## 解决方案
- 技术方案
- 功能模块设计
- 系统架构
- 实施路径
```

#### 第四部分：实施计划
```markdown
## 实施计划
- 时间规划
- 资源配置
- 风险评估
- 验收标准
```

### 4. 生成飞书文档（5分钟）

**步骤：**
1. 创建飞书文档
2. 写入结构化内容
3. 格式化和排版
4. 添加权限给用户
5. 返回文档链接

**参考：** [references/document-templates.md](references/document-templates.md)

## 快速启动指南

### 场景1：飞书文档需求整理

**用户输入：**
```
帮我整理这个需求文档：
https://feishu.cn/docx/xxxxx
```

**执行流程：**
```
1. 读取文档内容
2. 分析关键信息
3. 提取需求要点
4. 生成结构化文档
5. 返回新文档链接
```

### 场景2：会议纪要转需求文档

**用户输入：**
```
把这次会议记录整理成需求文档：
https://bytedance.larkoffice.com/minutes/xxxxx
```

**执行流程：**
```
1. 提取会议文字
2. 识别关键发言
3. 提取需求要点
4. 生成需求文档
5. 补充遗漏信息
```

### 场景3：文本需求整理

**用户输入：**
```
帮我整理以下需求：
[粘贴大段沟通记录]
```

**执行流程：**
```
1. 分析文本内容
2. 提取关键信息
3. 分类整理
4. 生成文档
```

## 需求提取技巧

### 1. 识别关键信息

**关键词识别：**
- **动作词：** 需要、想要、希望、必须、要求
- **问题词：** 问题、困难、痛点、不满、麻烦
- **功能词：** 功能、模块、系统、平台、工具
- **数据词：** 数据、信息、记录、统计、分析
- **时间词：** 期望、计划、期限、截止、周期

**优先级判断：**
- **P0（必需）：** 必须实现，无此功能无法使用
- **P1（重要）：** 重要功能，影响核心流程
- **P2（可选）：** 锦上添花，可以后期迭代

### 2. 消除歧义

**常见歧义及处理：**
- **模糊描述：** "需要方便一点" → 明确具体场景和操作
- **技术术语：** 确认客户理解是否准确
- **功能冲突：** 标注冲突点，需要客户确认
- **范围不清：** 明确边界和限制条件

### 3. 补充遗漏

**常见遗漏信息：**
- 用户角色和权限
- 数据量和性能要求
- 兼容性和集成需求
- 异常场景处理
- 培训和维护需求

## 文档模板库

### 模板1：业务需求文档（BRD）

**适用场景：** 业务系统、管理平台

**参考：** [references/brd-template.md](references/brd-template.md)

### 模板2：产品需求文档（PRD）

**适用场景：** 产品设计、功能开发

**参考：** [references/prd-template.md](references/prd-template.md)

### 模板3：技术需求文档（TRD）

**适用场景：** 技术系统、开发项目

**参考：** [references/trd-template.md](references/trd-template.md)

### 模板4：项目需求说明书（SRS）

**适用场景：** 综合性项目

**参考：** [references/srs-template.md](references/srs-template.md)

## 质量保证

### 需求验证清单

**完整性检查：**
- [ ] 所有核心功能是否覆盖
- [ ] 用户角色是否明确
- [ ] 数据流程是否完整
- [ ] 异常场景是否考虑
- [ ] 非功能需求是否清晰

**一致性检查：**
- [ ] 前后描述是否一致
- [ ] 术语使用是否统一
- [ ] 优先级划分是否合理
- [ ] 时间规划是否可行

**可追溯性：**
- [ ] 每个需求是否有来源
- [ ] 决策依据是否记录
- [ ] 变更历史是否清晰

## 常见问题处理

### Q1: 需求信息不完整怎么办？

**解决方案：**
1. 标注缺失信息
2. 列出待确认问题清单
3. 提供补充建议
4. 标注假设条件（需确认）

### Q2: 需求存在冲突怎么办？

**解决方案：**
1. 明确标注冲突点
2. 分析冲突原因
3. 提供多个解决方案
4. 建议客户决策

### Q3: 技术可行性存疑怎么办？

**解决方案：**
1. 标注技术风险
2. 提供替代方案
3. 评估实现成本
4. 建议技术评审

## 输出规范

### 文档格式要求

**标题层级：**
```
# 一级标题（文档标题）
## 二级标题（章节）
### 三级标题（子章节）
#### 四级标题（小节）
```

**表格格式：**
```markdown
| 字段名 | 字段类型 | 是否必填 | 说明 |
|--------|---------|---------|------|
| ... | ... | ... | ... |
```

**列表格式：**
```markdown
- 无序列表项1
- 无序列表项2
  - 嵌套列表项

1. 有序列表1
2. 有序列表2
```

**重点标注：**
```markdown
**加粗文字** - 重要内容
*斜体文字* - 强调内容
`代码` - 技术术语
```

### 文档元信息

**必须包含：**
```markdown
**文档版本：** v1.0
**创建日期：** YYYY-MM-DD
**需求来源：** 沟通记录/会议纪要
**整理人：** XXX
**状态：** 待确认/已确认/已变更
```

## 最佳实践

### 1. 保持客观中立
- 如实记录客户需求
- 不要主观臆断
- 标注不确定信息

### 2. 使用客户语言
- 避免过多技术术语
- 使用客户熟悉的表达
- 必要时提供术语解释

### 3. 结构清晰易懂
- 层次分明
- 逻辑清晰
- 重点突出

### 4. 便于后续使用
- 易于查找
- 易于更新
- 易于追溯

### 5. 高质量文档标准（2026-03-12 学习总结）

#### ✅ 必须包含的章节
1. **权限矩阵** - 用表格展示（部门×字段类别）
2. **自动化场景** - 编号+触发条件+操作步骤
3. **视图设计** - 分角色的视图和仪表盘
4. **数据关联图** - 树形图或流程图展示表关系
5. **功能优先级** - P0/P1/P2分级
6. **注意事项** - 数据安全、性能优化、用户培训

#### ✅ 数据表设计要点
- 核心表不少于7张
- 每张表列出所有字段、类型、是否必填、说明
- 考虑样品管理、产品信息等辅助表
- 用表格形式展示字段列表

#### ✅ 自动化设计要点
- 每个自动化编号（自动化1、2...）
- 清晰的触发条件（新记录、状态变更、定时）
- 具体的操作步骤（创建、更新、通知）
- 预期效果说明

#### ✅ 视图设计要点
- 按角色设计（业务员、财务、管理层）
- 每个角色列出需要的视图类型
- 包含仪表盘设计（指标卡、图表）

#### ✅ 文档长度标准
- 简单需求：5000-8000字
- 中等需求：8000-12000字
- 复杂需求：12000-15000字
- 目标：15000字为高质量标准

## 工具使用

### 飞书文档工具

**创建文档：**
```
feishu_doc(action="create", title="文档标题")
```

**写入内容：**
```
feishu_doc(action="write", doc_token="xxx", content="内容")
```

**读取文档：**
```
feishu_doc(action="read", doc_token="xxx")
```

**添加权限：**
```
feishu_perm(action="add", token="xxx", type="docx", member_type="openid", member_id="xxx", perm="edit")
```

### Web抓取工具

**获取网页内容：**
```
web_fetch(url="xxx", extractMode="markdown")
```

---

**技能版本：** 2.0.0
**最后更新：** 2026-03-12
**创建者：** 小虾米 🦐

---

## 📚 参考资料

- [高质量需求文档标准](references/high-quality-standard.md) - 15000字级别文档标准
- [权限矩阵模板](references/permission-matrix-template.md) - 字段级权限设计
- [自动化场景模板](references/automation-template.md) - 7个自动化场景示例
- [视图与仪表盘模板](references/view-dashboard-template.md) - 分角色视图设计
- [文档模板库](references/document-templates.md) - BRD/PRD/TRD/SRS模板