Skill: hollis0220/prd-review (version 1.0.2)

--- name: prd-review-design description: 自动化审查商业化产品需求文档的逻辑准确性与闭环性，提取界面/功能/商业化设计要点并划分高-中-低优先级，输出设计师友好的标准化梳理文档；当用户需要审查PRD、梳理设计要点、划分设计优先级或快速对接开发时使用 dependency: python: - python-docx==1.1.0 - PyPDF2==3.0.1 --- # 商业化产品需求文档审查与设计要点梳理 ## 任务目标 - 本 Skill 用于：自动化审查商业化产品需求文档（PRD），快速校验需求逻辑准确性、闭环性，提取需设计的核心内容并划分优先级 - 能力包含：文档解析、逻辑审查、设计要点提取、优先级划分、标准化输出 - 触发条件：用户提供 PRD 文档并请求审查、梳理设计要点、划分优先级 ## 前置准备 ### 依赖说明 scripts 脚本所需的依赖包及版本： ``` python-docx==1.1.0 PyPDF2==3.0.1 ``` ### 文档来源支持 | 来源类型 | 支持格式 | 处理方式 | |----------|----------|----------| | 本地上传 | .docx, .pdf, .txt, .md | 调用 `scripts/doc_parser.py` 解析 | | 粘贴内容 | 纯文本 | 直接读取分析 | ### 文档内容要求 PRD 文档需包含以下核心内容： - 需求背景 - 需求目标 - 核心功能描述 - 业务逻辑 - 用户场景 ## 操作步骤 ### 步骤一：需求文档解析与信息提取 根据用户提供的文档形式，选择对应的处理方式： **情况一：用户上传本地文档** 判断文档格式： - Word 文档（.docx）→ 调用 `scripts/doc_parser.py` - PDF 文档（.pdf）→ 调用 `scripts/doc_parser.py` - 纯文本（.txt/.md）→ 直接读取 ```bash python scripts/doc_parser.py <文档路径> ``` **情况二：用户粘贴文档内容** 直接使用粘贴内容进行分析。 **情况三：用户提供在线文档链接** 引导用户： - 复制文档内容并粘贴 - 或下载文档后上传本地文件 提取信息维度（详见 `references/review_checklist.md`）： - 基础信息：需求名称、提出人、背景、核心目标 - 业务逻辑：核心功能描述、用户操作流程、业务链路 - 约束条件：技术限制、时间节点、资源限制、合规要求 - 预期效果：量化指标、定性要求 ### 步骤二：需求逻辑审查 基于提取的信息，执行双重逻辑校验。详细审查标准见 `references/review_checklist.md`。 **2.1 逻辑准确性审查** - 校验需求目标与需求背景的匹配性 - 校验业务逻辑的合理性（排查矛盾点） - 校验量化指标的可行性 - 校验商业化逻辑合规性 **2.2 逻辑闭环审查** - 需求输入-处理-输出闭环检查 - 异常场景闭环检查（付费失败、操作失误、权限不足等） - 商业化链路闭环检查（引流-转化-留存-复购） **审查结果输出**： - 通过：逻辑清晰，无明显问题 - 需优化：存在小问题，不影响整体推进 - 存在漏洞：存在重大逻辑缺陷，需修正后再进行设计 ### 步骤三：设计要点提取 基于审查通过的需求逻辑，按设计师工作流维度提取设计要点： **界面设计要点**： - 页面布局：核心页面、关键模块、信息架构 - 组件设计：表单、卡片、列表、弹窗 **交互设计要点**： - 操作流程：步骤拆解、跳转逻辑、返回路径 - 触发反馈：点击响应、加载状态、成功/失败提示 **视觉设计要点**： - 视觉层级：重点突出、信息分层 - 商业化元素：付费入口、价格展示、优惠标识 **状态设计要点**： - 正常状态：默认展示、数据完整 - 异常状态：空状态、错误状态、边界情况 - 角色状态：不同用户角色、权限差异 每个设计要点需对应需求中的具体描述，明确设计范围。 ### 步骤四：设计优先级划分 结合商业化优先级、需求紧急程度、设计难度，采用「高-中-低」三级划分： | 优先级 | 判定条件 | 预估工时参考 | |--------|----------|--------------| | 高 | 影响商业化核心目标、阻塞开发流程、涉及合规性 | 1-3天 | | 中 | 辅助核心功能、影响部分用户体验 | 0.5-1天 | | 低 | 优化类、补充类、可后续迭代 | 0.5天内 | 每个设计要点标注：划分依据、前置依赖、建议启动时间。 ### 步骤五：输出设计师友好的梳理文档 将审查结果、设计要点、优先级划分整理成标准化文档，便于设计师直接参考。输出格式见 `references/review_checklist.md` 中的「输出文档模板」。 **文档结构**： 1. 需求概览（一句话总结 + 核心目标） 2. 逻辑问题清单（问题位置 + 影响范围 + 严重程度 + 修复建议） 3. 设计要点清单（按界面/交互/视觉/状态分类） 4. 优先级排期表（优先级 + 设计要点 + 预估工时 + 前置依赖） 5. 补充建议与风险提示 **输出形式选择**： - 简洁版：适合快速对接，聚焦高优先级设计要点 - 详细版：适合存档和团队同步，完整呈现所有内容 ## 资源索引 - 本地文档解析：见 [scripts/doc_parser.py](scripts/doc_parser.py)（用途：解析 Word/PDF/TXT 文档） - 审查标准与模板：见 [references/review_checklist.md](references/review_checklist.md)（何时读取：执行审查、提取要点、生成输出时） ## 注意事项 ### 异常处理 - **文档解析失败**：提示用户检查文档格式或直接粘贴内容 - **需求逻辑漏洞较多**：建议用户先优化需求逻辑，列出核心漏洞 - **设计要点不明确**：提示用户补充相关细节 ### 商业化重点关注 - 付费流程合规性（付费提示清晰、无虚假宣传） - 数据收集合规性（用户隐私保护） - 商业化链路完整性（引流-转化-留存-复购无断裂） - 异常场景覆盖（付费失败、余额不足、权限不足等） ### 设计师视角要点 - 输出文档结构清晰，便于快速定位 - 逻辑问题明确标注位置和修复建议 - 设计要点按工作流组织，便于任务拆解 - 优先级包含工时预估，便于排期规划 ## 使用示例 ### 示例一：本地文档审查 **用户请求**：帮我审查这份 Word 文档的需求逻辑 **执行方式**： 1. 调用 `scripts/doc_parser.py` 解析文档 2. 执行逻辑准确性 + 闭环性审查 3. 输出逻辑审查报告 **输出**：逻辑问题清单（含位置、影响范围、修复建议） ### 示例二：粘贴内容审查 **用户请求**：审查这份 PRD，梳理设计要点 **用户操作**：直接粘贴 PRD 内容 **执行方式**： 1. 直接读取粘贴内容 2. 执行逻辑审查 3. 提取设计要点并划分优先级 4. 输出设计师友好的梳理文档 **输出**：逻辑问题清单 + 设计要点清单 + 优先级排期表 ### 示例三：仅提取设计要点 **用户请求**：梳理这份 PRD 的设计要点和优先级 **执行方式**： 1. 读取文档内容 2. 提取设计要点（界面/交互/视觉/状态） 3. 划分高-中-低优先级 4. 输出设计要点清单 + 优先级排期表 **输出**：分类设计要点清单 + 优先级排期表（含工时预估）

path: scripts/doc_parser.py
content: #!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
PRD 文档解析脚本

功能：解析 Word/PDF 文档，提取纯文本内容供智能体分析
支持格式：.docx, .pdf, .txt, .md
"""

import sys
import os


def parse_docx(file_path: str) -> str:
    """解析 Word 文档"""
    try:
        from docx import Document
    except ImportError:
        return "[ERROR] 缺少依赖：python-docx，请安装后重试"

    try:
        doc = Document(file_path)
        content = []
        
        # 提取段落文本
        for para in doc.paragraphs:
            if para.text.strip():
                content.append(para.text.strip())
        
        # 提取表格文本
        for table in doc.tables:
            for row in table.rows:
                row_text = []
                for cell in row.cells:
                    if cell.text.strip():
                        row_text.append(cell.text.strip())
                if row_text:
                    content.append(" | ".join(row_text))
        
        return "\n".join(content)
    
    except Exception as e:
        return f"[ERROR] 解析 Word 文档失败：{str(e)}"


def parse_pdf(file_path: str) -> str:
    """解析 PDF 文档"""
    try:
        from PyPDF2 import PdfReader
    except ImportError:
        return "[ERROR] 缺少依赖：PyPDF2，请安装后重试"

    try:
        reader = PdfReader(file_path)
        content = []
        
        for page_num, page in enumerate(reader.pages, 1):
            text = page.extract_text()
            if text.strip():
                content.append(f"--- 第 {page_num} 页 ---")
                content.append(text.strip())
        
        return "\n".join(content)
    
    except Exception as e:
        return f"[ERROR] 解析 PDF 文档失败：{str(e)}"


def parse_txt(file_path: str) -> str:
    """解析纯文本文件"""
    try:
        # 尝试多种编码
        encodings = ['utf-8', 'gbk', 'gb2312', 'utf-16']
        
        for encoding in encodings:
            try:
                with open(file_path, 'r', encoding=encoding) as f:
                    return f.read()
            except UnicodeDecodeError:
                continue
        
        return "[ERROR] 无法识别文件编码，请将文件转换为 UTF-8 格式"
    
    except Exception as e:
        return f"[ERROR] 读取文件失败：{str(e)}"


def parse_document(file_path: str) -> str:
    """
    解析文档并返回纯文本内容
    
    参数：
        file_path: 文档路径
    
    返回：
        提取的纯文本内容
    """
    if not os.path.exists(file_path):
        return f"[ERROR] 文件不存在：{file_path}"
    
    file_ext = os.path.splitext(file_path)[1].lower()
    
    if file_ext == '.docx':
        return parse_docx(file_path)
    elif file_ext == '.pdf':
        return parse_pdf(file_path)
    elif file_ext in ['.txt', '.md']:
        return parse_txt(file_path)
    else:
        return f"[ERROR] 不支持的文件格式：{file_ext}，仅支持 .docx, .pdf, .txt, .md 格式"


def main():
    """主函数"""
    if len(sys.argv) < 2:
        print("用法：python doc_parser.py <文档路径>")
        print("支持格式：.docx, .pdf, .txt, .md")
        sys.exit(1)
    
    file_path = sys.argv[1]
    content = parse_document(file_path)
    print(content)


if __name__ == "__main__":
    main()


path: references/review_checklist.md
content: # 商业化产品需求文档审查清单

## 目录

1. [信息提取维度表](#信息提取维度表)
2. [逻辑准确性审查标准](#逻辑准确性审查标准)
3. [逻辑闭环审查标准](#逻辑闭环审查标准)
4. [设计要点提取维度](#设计要点提取维度)
5. [优先级划分标准](#优先级划分标准)
6. [输出文档模板](#输出文档模板)

---

## 信息提取维度表

### 基础信息

| 提取项 | 说明 | 商业化重点关注 |
|--------|------|----------------|
| 需求名称 | 需求的正式名称 | 是否体现商业化导向 |
| 需求提出人 | 提出需求的负责人 | 商业化相关部门（如营收、运营） |
| 需求背景 | 为什么提出此需求 | 当前商业化数据表现（如转化率低、营收下降） |
| 核心目标 | 需求要达成的目标 | 明确的商业化指标（如营收提升X%、转化率提升X%） |

### 业务逻辑

| 提取项 | 说明 | 商业化重点关注 |
|--------|------|----------------|
| 核心功能描述 | 需求涉及的主要功能 | 付费功能、变现入口、推广功能 |
| 用户操作流程 | 用户如何使用该功能 | 从接触到转化的完整路径 |
| 业务链路 | 后端处理逻辑 | 付费流程、数据流转、第三方对接 |

### 约束条件

| 提取项 | 说明 | 商业化重点关注 |
|--------|------|----------------|
| 技术限制 | 技术实现限制 | 支付接口限制、性能要求 |
| 时间节点 | 上线时间要求 | 营销活动时间窗口、竞品节奏 |
| 资源限制 | 人力、预算限制 | 商业化资源投入上限 |
| 合规要求 | 法律、政策约束 | 支付合规、数据合规、广告法合规 |

### 预期效果

| 提取项 | 说明 | 商业化重点关注 |
|--------|------|----------------|
| 量化指标 | 可测量的目标数值 | 营收、转化率、付费用户数、ARPU |
| 定性要求 | 不可量化的目标 | 用户体验优化、流程简化、品牌形象提升 |

---

## 逻辑准确性审查标准

### 1. 需求目标与背景匹配性审查

**审查要点**：
- 目标是否直接回应背景中提出的问题
- 目标是否具有商业化合理性
- 目标是否可衡量

**判断标准**：

| 审查结果 | 判断标准 | 示例 |
|----------|----------|------|
| 通过 | 目标与背景有明确因果关系，商业化导向清晰 | 背景：当前付费转化率仅5%，低于行业平均15%；目标：提升付费转化率至10% |
| 需优化 | 目标与背景有关联但不直接，或量化不够具体 | 背景：用户反馈付费流程繁琐；目标：优化付费体验（缺少量化指标） |
| 存在漏洞 | 目标与背景无关或逻辑矛盾 | 背景：用户活跃度下降；目标：提升付费转化率（活跃度下降时转化率提升可能不可行） |

### 2. 业务逻辑合理性审查

**审查要点**：
- 功能描述是否完整、无矛盾
- 用户操作流程是否顺畅
- 业务链路是否清晰

**常见问题清单**：

| 问题类型 | 问题描述 | 示例 |
|----------|----------|------|
| 逻辑矛盾 | 同一流程中存在相互矛盾的描述 | "用户无需登录即可付费" 与 "付费后需绑定账号" |
| 流程断裂 | 操作步骤之间缺少衔接 | 用户点击付费按钮后无跳转说明 |
| 条件缺失 | 缺少必要的前置条件说明 | 付费功能未说明是否需要实名认证 |
| 角色混乱 | 未明确不同用户角色的操作权限 | 普通用户和管理员的操作流程混在一起 |

### 3. 量化指标可行性审查

**审查要点**：
- 指标是否符合行业常规
- 是否有明确的数据支撑
- 实现路径是否可行

**判断标准**：

| 审查结果 | 判断标准 | 示例 |
|----------|----------|------|
| 通过 | 指标合理，有数据支撑，实现路径清晰 | 当前日均营收10万，目标提升20%至12万，通过优化付费入口实现 |
| 需优化 | 指标合理但缺乏数据支撑或路径不清 | 目标提升转化率，但未说明当前转化率基数 |
| 存在漏洞 | 指标不合理或无法实现 | 当前日均营收10万，目标提升100%至20万，无明确实现路径 |

### 4. 商业化逻辑合规性审查

**审查要点**：
- 付费流程是否符合支付规范
- 数据收集是否符合隐私保护要求
- 推广内容是否符合广告法规定

**合规检查清单**：

| 检查项 | 合规要求 | 常见违规示例 |
|--------|----------|--------------|
| 付费提示 | 价格明确、无隐藏费用 | 价格展示不清晰，实际扣费与展示不符 |
| 自动续费 | 需明确告知、提供取消方式 | 自动续费无明确提示，取消入口隐蔽 |
| 优惠活动 | 规则清晰、无虚假宣传 | "限时优惠"无明确时限，实际长期有效 |
| 数据收集 | 最小必要原则、用户知情同意 | 强制收集非必要信息，未说明用途 |

---

## 逻辑闭环审查标准

### 1. 输入-处理-输出闭环审查

**审查框架**：

| 环节 | 审查要点 | 检查内容 |
|------|----------|----------|
| 输入 | 触发条件明确 | 用户操作触发？系统自动触发？触发时机？ |
| 处理 | 处理流程完整 | 步骤清晰？角色明确？异常处理？ |
| 输出 | 输出结果明确 | 用户反馈？数据变化？状态更新？ |

**闭环检查示例**：

```
需求描述：用户点击付费按钮，完成支付后获得会员权益

闭环检查：
- 输入：用户点击付费按钮（触发条件明确）
- 处理：调用支付接口 → 等待支付结果 → 更新用户状态（流程完整）
- 输出：支付成功提示 + 会员权益生效（输出明确）

结论：闭环完整
```

### 2. 异常场景闭环审查

**商业化常见异常场景**：

| 异常场景 | 必要处理 | 审查要点 |
|----------|----------|----------|
| 付费失败 | 错误提示 + 重试引导 | 是否有友好的错误提示？是否提供重试或替代方案？ |
| 余额不足 | 充值引导 | 是否引导用户充值？充值入口是否便捷？ |
| 网络异常 | 重试机制 | 是否有自动重试？是否保存用户操作状态？ |
| 权限不足 | 权限申请或升级引导 | 是否说明权限用途？是否提供升级路径？ |
| 操作失误 | 撤销或修正机制 | 是否允许取消操作？是否有操作确认环节？ |

### 3. 商业化链路闭环审查

**商业化链路模型**：引流 → 转化 → 留存 → 复购

**审查要点**：

| 链路环节 | 审查要点 | 常见断裂点 |
|----------|----------|------------|
| 引流 | 用户如何接触到付费入口 | 入口隐蔽，用户无法发现 |
| 转化 | 用户如何完成付费行为 | 付费流程繁琐，中途流失 |
| 留存 | 付费后如何维持用户活跃 | 付费后无后续引导，用户沉寂 |
| 复购 | 如何促进用户再次付费 | 无续费提醒，无复购激励 |

**链路完整性检查示例**：

```
需求描述：新增会员付费功能，用户可购买月度/年度会员

链路检查：
- 引流：首页展示会员入口
- 转化：会员介绍页 → 选择套餐 → 支付
- 留存：会员权益说明，但未提及会员专属内容或服务
- 复购：未说明续费提醒机制

结论：链路存在断裂点，需补充留存和复购相关设计
```

---

## 设计要点提取维度

### 设计师工作流维度

按照设计师日常工作流程，从以下四个维度提取设计要点：

### 1. 界面设计要点

| 设计类型 | 提取要点 | 商业化重点 | 输出物 |
|----------|----------|------------|--------|
| 页面布局 | 核心页面结构、信息架构、模块划分 | 付费页面、转化入口、会员中心 | 页面原型、布局图 |
| 组件设计 | 表单、卡片、列表、弹窗等基础组件 | 付费金额输入、套餐选择、优惠券展示 | 组件规范 |

### 2. 交互设计要点

| 设计类型 | 提取要点 | 商业化重点 | 输出物 |
|----------|----------|------------|--------|
| 操作流程 | 步骤拆解、跳转逻辑、返回路径 | 付费流程引导、异常处理流程 | 流程图、交互说明 |
| 触发反馈 | 点击响应、加载状态、成功/失败提示 | 付费成功/失败提示、加载状态 | 交互说明 |

### 3. 视觉设计要点

| 设计类型 | 提取要点 | 商业化重点 | 输出物 |
|----------|----------|------------|--------|
| 视觉层级 | 重点突出、信息分层、阅读引导 | 付费按钮、价格信息、优惠标识 | 视觉规范 |
| 商业化元素 | 付费入口样式、价格展示、优惠标签 | 转化按钮设计、价格对比、限时标识 | 设计稿 |

### 4. 状态设计要点

| 设计类型 | 提取要点 | 商业化重点 | 输出物 |
|----------|----------|------------|--------|
| 正常状态 | 默认展示、数据完整、初始状态 | 正常付费流程展示 | 状态图 |
| 异常状态 | 空状态、错误状态、边界情况 | 付费失败、余额不足、网络异常 | 异常状态设计 |
| 角色状态 | 不同用户角色、权限差异展示 | 普通用户 vs 付费用户 vs 管理员 | 角色差异说明 |

---

## 优先级划分标准

### 高优先级判定条件（满足任一即可）

| 判定维度 | 具体条件 | 示例 | 预估工时 |
|----------|----------|------|----------|
| 商业化核心 | 直接影响营收或转化 | 付费页面设计、支付流程设计 | 1-3天 |
| 流程阻塞 | 不完成则无法推进开发/测试 | 核心功能逻辑设计、数据结构设计 | 1-3天 |
| 用户体验核心 | 影响核心用户体验 | 关键操作流程、主要界面布局 | 1-2天 |
| 合规性 | 涉及法律、政策合规 | 付费提示设计、隐私政策展示 | 0.5-1天 |

### 中优先级判定条件

| 判定维度 | 具体条件 | 示例 | 预估工时 |
|----------|----------|------|----------|
| 功能辅助 | 辅助核心功能实现 | 数据统计界面、设置页面 | 0.5-1天 |
| 体验优化 | 影响部分用户体验 | 次要交互优化、提示文案优化 | 0.5天 |
| 扩展功能 | 不影响主流程的功能 | 非核心功能模块 | 0.5-1天 |

### 低优先级判定条件

| 判定维度 | 具体条件 | 示例 | 预估工时 |
|----------|----------|------|----------|
| 优化类 | 提升体验但不影响功能 | 界面细节美化、动画效果 | 0.5天内 |
| 补充类 | 锦上添花的内容 | 帮助说明、引导页优化 | 0.5天内 |
| 迭代类 | 可后续完善的内容 | 非紧急的功能扩展 | 0.5天内 |

### 优先级排期建议

```
优先级排期原则：
1. 高优先级：立即启动，优先安排设计资源
2. 中优先级：高优先级完成后启动，或并行安排
3. 低优先级：视资源情况安排，可延后迭代

前置依赖说明：
- 标注「无依赖」的可直接启动
- 标注「依赖 X」的需要在 X 完成后启动
```

---

## 输出文档模板

### 一、需求概览

**需求名称**：{需求名称}

**一句话总结**：{用一句话概括需求核心内容}

**核心目标**：{商业化目标，如提升付费转化率X%}

---

### 二、逻辑问题清单

#### 严重问题（需优先修复）

| 序号 | 问题位置 | 问题描述 | 影响范围 | 修复建议 |
|------|----------|----------|----------|----------|
| 1 | {需求章节/段落} | {具体问题描述} | {影响哪些设计/流程} | {建议的修复方案} |

#### 一般问题（建议优化）

| 序号 | 问题位置 | 问题描述 | 影响范围 | 修复建议 |
|------|----------|----------|----------|----------|
| 1 | {需求章节/段落} | {具体问题描述} | {影响哪些设计/流程} | {建议的修复方案} |

#### 潜在风险（需关注）

| 序号 | 风险点 | 风险说明 | 建议措施 |
|------|--------|----------|----------|
| 1 | {风险点名称} | {风险具体说明} | {建议的预防措施} |

---

### 三、设计要点清单

#### 3.1 界面设计要点

| 序号 | 页面/模块 | 设计要点 | 对应需求描述 | 输出物 |
|------|-----------|----------|--------------|--------|
| 1 | {页面名称} | {具体设计要点} | {需求原文引用} | {原型/布局图} |

#### 3.2 交互设计要点

| 序号 | 流程/场景 | 设计要点 | 对应需求描述 | 输出物 |
|------|-----------|----------|--------------|--------|
| 1 | {交互场景} | {具体设计要点} | {需求原文引用} | {流程图/交互说明} |

#### 3.3 视觉设计要点

| 序号 | 元素/组件 | 设计要点 | 对应需求描述 | 输出物 |
|------|-----------|----------|--------------|--------|
| 1 | {视觉元素} | {具体设计要点} | {需求原文引用} | {设计稿/规范} |

#### 3.4 状态设计要点

| 序号 | 状态类型 | 设计要点 | 对应需求描述 | 输出物 |
|------|----------|----------|--------------|--------|
| 1 | {状态名称} | {具体设计要点} | {需求原文引用} | {状态图/设计稿} |

---

### 四、优先级排期表

#### 高优先级（立即启动）

| 序号 | 设计要点 | 所属模块 | 预估工时 | 前置依赖 | 建议启动时间 |
|------|----------|----------|----------|----------|--------------|
| 1 | {设计要点} | {界面/交互/视觉/状态} | {X天} | {无/依赖X} | {立即/日期} |

#### 中优先级（视情况启动）

| 序号 | 设计要点 | 所属模块 | 预估工时 | 前置依赖 | 建议启动时间 |
|------|----------|----------|----------|----------|--------------|
| 1 | {设计要点} | {界面/交互/视觉/状态} | {X天} | {无/依赖X} | {高优完成后} |

#### 低优先级（可延后迭代）

| 序号 | 设计要点 | 所属模块 | 预估工时 | 前置依赖 | 建议启动时间 |
|------|----------|----------|----------|----------|--------------|
| 1 | {设计要点} | {界面/交互/视觉/状态} | {X天} | {无} | {视资源安排} |

---

### 五、补充建议

#### 商业化重点关注

| 关注点 | 说明 | 设计建议 |
|--------|------|----------|
| {关注点1} | {具体说明} | {设计时的注意事项} |

#### 异常场景覆盖

| 场景 | 需求覆盖情况 | 设计建议 |
|------|--------------|----------|
| {异常场景1} | {已覆盖/未覆盖} | {设计处理建议} |

#### 协作建议

- **与产品确认**：{需与产品经理确认的问题}
- **与开发对齐**：{需与开发确认的技术限制}
- **与测试同步**：{需与测试确认的验收标准}

---

## 审查执行指南

### 执行顺序

1. **获取文档**：解析本地文档或读取粘贴内容
2. **提取信息**：按信息提取维度表提取需求信息
3. **逻辑审查**：执行准确性 + 闭环性双重审查
4. **要点提取**：按界面/交互/视觉/状态维度提取设计要点
5. **优先级划分**：综合商业化重要性、紧急程度、设计难度划分
6. **输出文档**：按模板整理结果

### 设计师友好输出原则

- **结构清晰**：按工作流组织，便于定位
- **问题可视**：明确标注位置、影响范围、修复建议
- **工时明确**：包含预估工时，便于排期
- **依赖清晰**：标注前置依赖，避免阻塞
- **协作导向**：指出需确认的问题和对齐事项

### 注意事项

- 审查时需结合商业化场景特点，重点关注付费、变现、推广相关逻辑
- 优先级划分需综合考虑商业化重要性、紧急程度、设计难度
- 输出文档需清晰、可操作，便于设计师直接参考
- 对于模糊描述，标注「需与产品确认」而非自行推断


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)