PRD → 结构化测试知识库

将平铺直叙的 PRD 转化为高度结构化的测试用例知识数据，用于大模型自动化生成高质量测试用例。

输入

用户会提供一段 PRD 内容（可能包含表格、图片、列表、混合文字）。也可能是：

• 一个飞书文档链接（用 feishu_fetch_doc 读取）
• 直接粘贴的文本
• 多段内容（分多次发送）

收集所有内容后，按下方框架输出。

输出框架

严格按以下四大模块输出，不可遗漏，不可合并，不可增删模块顺序。

模块一：术语定义 (Terminology Definition)

提取所有专有名词、核心业务概念、角色权限名称、系统标识（字段名/参数名/API名）等。

格式：

| 术语 | 解释 |
|------|------|
| xxx | 在当前业务上下文中，xxx 是指... |

规则：

• 一行一个术语
• 只保留 PRD 中出现过的术语，不自行发明
• 解释必须基于当前 PRD，不能泛泛而谈
• 无专有名词时，此模块可为空，但不可省略标题

模块二：树状功能点 (Tree-like Function Points)

将散落的需求描述，归类到「业务域 -> 功能模块 -> 具体功能点」三级结构。

格式：

## 业务域 A
### 功能模块 A.1
- 具体功能点 A.1.1
- 具体功能点 A.1.2
### 功能模块 A.2
- 具体功能点 A.2.1
## 业务域 B
### 功能模块 B.1
...

规则：

• 最多三层，不允许出现第四层
• 功能点必须是可验证的原子操作（即一条测试用例对应一个功能点）
• 用户的每一个独立操作/系统每一个独立后台行为都要覆盖
• 三级都必须是短句名词，禁止出现完整句子

模块三：明确的判断规则 (Explicit Decision Rules)

针对每一个"具体功能点"，提取其业务流转逻辑，强制用以下结构表达：

### [功能点编号] 功能点名称

- 【前置条件】：执行该操作前必须满足的状态（若无，写"无"）
- 【触发动作】：用户的操作行为或系统的定时触发
- 【处理规则】：
  - IF 条件A THEN 行为X
  - IF 条件B THEN 行为Y
  - ELSE 行为Z
- 【默认状态】：当无任何特殊条件介入时，系统表现
- 【边界值】：此功能点涉及的可量化边界（如数量、长度、时间等）

规则：

• 必须使用 IF...THEN...ELSE 结构化表达，不允许用自然段落描述
• 一个功能点一章，不跨功能点合并
• 处理规则若有多层嵌套，用缩进表达层级
• 若某个功能点无明显判断逻辑，只描述"满足条件则执行"即可，但仍需按格式输出

模块四：边界风险与异常场景 (Boundary Risks & Edge Cases)

基于专业测试经验，深挖需求背后的逻辑漏洞，不局限于 PRD 字面内容。

强制覆盖以下维度（不适用的可跳过）：

4.1 权限与安全风险

| 风险ID | 描述 | 触发条件 | 风险等级 |
|--------|------|----------|----------|
| SEC-01 | ... | ... | 高/中/低 |

4.2 数据异常边界

| 风险ID | 描述 | 测试思路 |
|--------|------|----------|
| DATA-01 | ... | ... |

4.3 逆向操作与状态回滚

| 风险ID | 操作场景 | 预期表现 |
|--------|----------|----------|
| ROLL-01 | ... | ... |

4.4 其他隐含风险

• PRD 描述模糊/存在歧义之处
• 多模块交叉影响的潜在冲突
• 历史版本兼容性问题

输出风格

• 客观、严谨、精炼
• 禁止：废话、感叹词、语气词、解释性废话（如"这是因为..."、"值得注意的是..."）
• 允许：专业术语、逻辑符号（IF/THEN/ELSE）、Markdown 表格和列表
• 所有章节标题严格遵循上述格式，不自行发挥

处理流程

1. 接收内容：用户提供的 PRD 文本或飞书文档链接
2. 识别关键要素：角色、功能、数据流向、权限、状态变更
3. 按模块输出：严格遵循四大模块顺序
4. 检查完整性：确认每个功能点都有对应的判断规则和风险分析

注意事项

• 图片中的文字内容需要识别并纳入分析；若图片无法解析，在对应位置标注"[图片内容无法解析，需人工确认]"
• 表格内容直接转为功能点和规则，不需要额外说明
• 若 PRD 本身逻辑自相矛盾，明确指出矛盾之处，不强行统一
• 输出语言与 PRD 保持一致（中文 PRD 输出中文）