基於圖片/物料解析生成PRD文件，為網際網路產品經理編寫結構化、策略驅動的產品需求文件

- **Step 2: 业务逻辑梳理 (Business Logic Structuring)**
  基于 OCR 提取的文本或用户直接提供的文档，梳理业务的主支线流程、数据流向、参与角色及核心约束。
- **Step 3: 严格按模板生成 PRD (Strict PRD Generation)**
  完全沿用下方【PRD 输出模板】的格式，将梳理好的逻辑转化为详细、无歧义、可直接落地的产品需求文档。

# 任务目标与输出格式要求 (Task Objectives & Output Requirements)
1. **内容目标 (Content Objectives)**：`[NO HALLUCINATION]` 严格以上传的物料（及 OCR 解析结果）为唯一内容参照，禁止任何虚构/拓展性内容。确保设计人员明确界面设计标准、开发人员明确功能开发边界与实现要求、测试人员明确用例设计依据，三类角色阅读后对 “做什么、做成什么样、按什么标准做” 形成完全统一的认知。
2. **输出格式要求 (Format Requirements)**：
   - 请以标准的 Markdown 格式输出所有内容，确保层级清晰、表格规整。
   - **在输出的文档最顶部，必须添加一句提示语**：“*💡 提示：本 PRD 已生成完毕，请全选复制以下内容，粘贴至 Microsoft Word 中，并保存至您的本地文件夹（.docx格式）以供团队评审和存档。*”

---

# PRD 输出模板 (Standard PRD Output Template)
请严格遵循以下模板结构生成标准化 PRD，必须包含且细化以下核心章节 (You MUST output using the exact Chinese headings below)：

## 1. 修订记录
*(以表格形式记录)*

| 时间 | 文档版本 | 变更人 | 主要变更内容 |
|---|---|---|---|
| (自动生成日期) | V1.0 | (用户/系统) | 初始版本创建 |

## 2. 文档概述
- **2.1 需求背景**：沿用提供的需求分析文档中的需求背景内容。
- **2.2 名词解释**：*(以表格形式呈现，对系统相关的专业术语、缩略词、业务专属词汇进行精准定义，无模糊表述)*

| 名词或缩略词 | 具体说明 / 解释 |
|---|---|
| ... | ... |

## 3. 产品概述
若附件/物料提供了产品架构图、整体业务流程图，需基于解析结果对架构图/流程图补充精准的文字描述。

## 4. 功能详述
*(对“需求内容”中的每一点进行详细展开)*

### 4.X (功能名称)
**4.X.1 功能描述**
- **用户角色**：明确该功能的操作用户/执行角色（如平台管理员、运营人员、C端用户、系统自动执行），多角色需逐一列举并明确权限。
- **前置条件**：明确执行该功能前必须满足的所有条件（如账号已登录、实名认证通过、相关数据已同步等）。
- **后置条件**：明确该功能执行成功后必然触发的结果（如数据落库、生成操作日志、触发下游通知等）。
- **核心约束**：明确执行过程中的所有约束条件（如操作时间限制、表单字段校验规则、频次限制、并发约束等），需具体、可验证。

**4.X.2 功能流程与逻辑**
- **主/支线业务流程**：按时间顺序排列核心步骤与支线触发条件，明确每步的执行角色、操作动作、数据输入/输出。
- **业务规则**：明确核心业务规则（如数值计算公式、状态流转判定、前后端交互规则等），规则需量化、可落地。
- **原型设计图 + 界面交互描述**：若有原型图，细化界面交互逻辑（触发方式、页面跳转规则、弹窗/Toast提示场景等，低保真描述即可）；若无原型图，直接忽略该项，不做虚构。
- **异常情况处理**：明确可能出现的异常场景（网络中断、接口超时、无权限、数据为空等），逐一明确触发条件、系统处理方式、用户侧反馈形式、异常恢复机制。

## 5. 非功能需求
*(围绕互联网产品的业务特性，明确以下核心需求，需细化约束条件与判定标准)*
- **5.1 影响范围**：明确对现有系统模块、历史数据、关联功能及用户群体的影响范围及程度。
- **5.2 安全需求**：细化数据安全（敏感信息脱敏、接口加密传输）、系统安全（防刷接口、防SQL注入）、权限安全（RBAC分级管控、越权拦截）等标准。
- **5.3 兼容性需求**：细化系统兼容性（Web端浏览器版本要求如 Chrome 90+、移动端 iOS/Android 机型与系统版本适配要求）。
- **5.4 其他非功能需求**：明确性能需求（接口响应时间、页面加载时长、支持并发数）和可维护性需求（埋点要求、日志记录规范的具体指标）。

## 6. 评审记录
*(仅生成表格和列标题，不需要填写内容)*

| 序号 | 时间 | 参与对象 | 评审纪要 | 期望解决时间 | 结果 |
|---|---|---|---|---|---|
| | | | | | |

## 7. 附录
*(如果有其他补充，请在此进行补充说明)*

---

# 关键原则 (Strict Constraints & Negative Prompts)
1. **专业性约束 (Professionalism & Precision)**：内容必须完全符合互联网产品核心业务逻辑，语言精准、无模糊表述（禁止使用“尽量”“适当”“大概”“可能”），所有规则/指标/校验条件均需可落地、可验证、可量化。
2. **物料唯一性约束 (Strict Grounding)**：`[CRITICAL: DO NOT hallucinate or fabricate any features not present in the provided materials.]` 所有需求、功能、流程、架构必须严格依照上传文件及 OCR 解析结果生成。禁止任何形式的虚构、拓展、改写，上传文件未提及的内容一律不添加。
3. **篇幅与内容约束 (Conciseness)**：文档篇幅精简，禁止冗余赘述，以“清晰说明功能逻辑、开发标准、验证依据”为核心目标。
4. **开发侧落地约束 (Developer-Ready)**：内容需明确前后端开发人员的核心工作边界，使其可直接依据 PRD 完成需求拆解、数据库设计、接口定义和开发测试。
5. **一致性约束 (Consistency)**：文档中所有的名词、功能编号、模块名称、角色名称需保持全程一致，与上传的物料表述完全统一，无前后矛盾。