产品原型评审工具（V0 → V1 准入评审）
定位与目标
本技能用于帮助产品经理判断其 V0 原型是否达到进入 V1 设计阶段的质量门槛。V1 是 UI 设计师可以介入进行视觉设计的阶段，因此 V0 原型需要在结构、交互、一致性、状态覆盖等方面达到足够的完整度，才值得设计师投入时间。
评审不关注视觉美观度（这是V1阶段的事），而是关注「这个原型是否把产品逻辑说清楚了」。
输入获取
HTML 原型
- 用户提供 HTML 文件路径时，使用 Read 工具读取完整源码
- 分析 HTML 结构、CSS 样式、JavaScript 交互逻辑
- 如果是多文件项目，要求用户指定入口文件，然后按需读取关联的 CSS/JS 文件
Figma 原型
- 用户提供 Figma URL 时，首先检查是否有 Figma MCP 工具可用（
mcp__figma__get_figma_data） - 如果 Figma MCP 可用：
- 使用mcp__figma__get_figma_data获取节点结构、布局、样式信息
- 使用mcp__figma__download_figma_images下载关键页面截图用于视觉辅助分析
- 分析 Figma 节点树的层级结构、组件复用情况、Auto Layout 使用情况、页面/Frame 组织方式 - 如果 Figma MCP 不可用：
- 告知用户当前环境未连接 Figma 插件，无法直接读取 Figma 数据
- 提供替代方案供用户选择：
a) 将 Figma 页面导出为截图（PNG/JPG）上传，基于截图进行视觉评审
b) 将 Figma 原型导出为 HTML（Figma 支持 Export as HTML 或使用 Anima/Locofy 等插件），然后走 HTML 评审流程
c) 用户在 QoderWork 设置中连接 Figma MCP 后重试
- 如果用户选择截图方式，评审深度会有所下降（无法分析组件结构和自动布局），报告中应标注「基于截图评审，组件复用和层级结构信息有限」
补充信息收集
在开始评审前，如果用户没有主动提供，应当询问：
- 产品名称 / 项目名称
- 目标用户群体（简要描述即可）
- 核心使用场景（1-3句话）
这些信息用于在评审中判断信息架构和可用性是否合理。如果用户表示「不想多说直接评」，也可以跳过，但在报告中标注「缺少业务上下文，部分判断基于通用原则」。
评审维度与评分标准
总分 100 分，分配如下：
1. 页面结构完整性（20分）
评估原型是否覆盖了产品所需的所有关键页面和模块。
| 得分区间 | 标准 |
|---|---|
| 18-20 | 所有核心流程页面齐全，包含异常/空状态页面，页面层级清晰 |
| 14-17 | 核心流程页面基本齐全，但缺少部分次要页面或异常状态 |
| 10-13 | 关键流程有明显页面缺失，但主线流程可走通 |
| 5-9 | 大量页面缺失，核心流程不完整 |
| 0-4 | 仅有少量零散页面，无法构成完整产品 |
检查要点：
- 主流程的每个步骤是否都有对应页面
- 是否有首页/入口页
- 列表页 → 详情页 → 编辑页的常见链路是否闭环
- 登录/注册等通用页面是否考虑（如适用）
- 设置/个人中心等辅助页面是否覆盖（如适用）
2. 交互架构合理性（20分）
评估导航结构、页面跳转逻辑、操作流程是否合理。
| 得分区间 | 标准 |
|---|---|
| 18-20 | 导航层级清晰合理，跳转逻辑无死链，操作流程符合用户心智模型 |
| 14-17 | 导航基本合理，有个别跳转不清晰或缺少返回路径 |
| 10-13 | 导航存在明显问题，部分流程有断裂或死循环 |
| 5-9 | 交互架构混乱，用户难以完成核心任务 |
| 0-4 | 几乎没有考虑交互架构 |
检查要点：
- 全局导航是否一致（Tab栏/侧边栏/面包屑）
- 关键操作是否能在 3 步以内完成
- 是否有操作后无法返回的死胡同
- 弹窗/抽屉/新页面的使用是否合理
- 多步骤流程是否有进度提示
- 破坏性操作是否有确认机制
3. 页面一致性（15分）
评估跨页面的视觉和交互模式是否一致。
| 得分区间 | 标准 |
|---|---|
| 14-15 | 全局一致，相似功能用相同模式，布局节奏统一 |
| 11-13 | 大部分一致，个别页面存在不统一 |
| 7-10 | 一致性问题较多，相似功能用了不同模式 |
| 4-6 | 各页面风格差异大，缺乏统一规范 |
| 0-3 | 完全没有一致性考虑 |
检查要点：
- 相同类型的列表是否用相同的展示方式
- 表单的标签、输入框、按钮样式是否统一
- 相似操作（删除、编辑、新建）是否用相同的交互模式
- 间距、字号、颜色使用是否有规律
- 页面布局结构（头部、内容区、底部操作区）是否一致
4. 状态完整性（15分）
评估是否考虑了各种数据状态和交互状态。
| 得分区间 | 标准 |
|---|---|
| 14-15 | 充分考虑空状态、加载态、错误态、边界数据等 |
| 11-13 | 核心页面有状态考虑，部分次要页面缺失 |
| 7-10 | 仅考虑了正常状态，异常状态大量缺失 |
| 4-6 | 几乎没有状态考虑 |
| 0-3 | 完全没有状态考虑 |
检查要点：
- 列表为空时展示什么（空状态引导）
- 数据加载中的展示
- 网络错误/请求失败的处理
- 表单校验失败的提示方式
- 数据量极大时的展示（分页/无限滚动）
- 权限不足时的展示
- 首次使用引导（如适用）
5. 可用性（15分）
评估原型是否能让目标用户顺利完成任务。
| 得分区间 | 标准 |
|---|---|
| 14-15 | 信息层级清晰，操作可预期，反馈及时，无认知负担 |
| 11-13 | 基本可用，但有个别体验粗糙之处 |
| 7-10 | 存在明显可用性问题，用户可能困惑或出错 |
| 4-6 | 可用性问题严重，用户难以自主完成任务 |
| 0-3 | 基本不可用 |
检查要点：
- 关键操作按钮是否醒目、位置合理
- 信息密度是否适当（不过于拥挤或空旷）
- 操作后是否有反馈（成功/失败提示）
- 文案是否清晰、无歧义
- 是否有不必要的认知负担（如需要记忆跨页面信息）
- 如果产品有明确的移动端/多端需求，是否在原型中体现了关键页面的移动端布局思路或适配策略（此项仅在产品明确需要多端时评估，扣分上限2-3分；纯桌面端产品可跳过）
6. 可开发性（15分）
评估原型是否能被开发团队准确理解和实现。
| 得分区间 | 标准 |
|---|---|
| 14-15 | 逻辑完备、标注清晰，开发可直接实现，无需频繁确认 |
| 11-13 | 大部分逻辑清晰，少数场景需确认 |
| 7-10 | 有不少模糊地带，开发需频繁沟通确认 |
| 4-6 | 大量逻辑不清晰，开发无法判断预期行为 |
| 0-3 | 无法作为开发参考 |
检查要点：
- 数据流向是否可推断（列表的数据从哪来、提交到哪去）
- 条件逻辑是否明确（什么时候显示A，什么时候显示B）
- 组件的交互细节是否可理解（下拉框是单选还是多选、日期范围如何选择）
- 是否有技术上难以实现或成本极高的设计
- 接口数据结构是否可推断
输出报告结构
评审完成后，生成一份完整的 Markdown 报告，保存为文件。报告必须包含以下所有章节：
报告模板
# V0 原型评审报告
## 1. 基本信息
| 项目 | 内容 |
|------|------|
| 产品名称 | {名称} |
| 评审日期 | {日期} |
| 原型类型 | HTML / Figma |
| 原型版本 | V0 |
| 页面数量 | {数量} |
| 评审目标 | V1准入评估 |
## 2. 总体结论
| 项目 | 结果 |
|------|------|
| 总分 | {X}/100 |
| 风险等级 | {优秀/良好/有风险/不通过} |
| V1 准入建议 | {通过/有条件通过/不通过} |
| 核心问题数量 | P0: {n} 个, P1: {n} 个, P2: {n} 个 |
**总体评语：** {1-2句话概括当前原型的整体状况和最大的优势/短板}
## 3. 评分卡总表
| 维度 | 满分 | 得分 | 通过标准 | 状态 |
|------|------|------|----------|------|
| 页面结构完整性 | 20 | {X} | ≥14 | ✅/⚠️/❌ |
| 交互架构合理性 | 20 | {X} | ≥14 | ✅/⚠️/❌ |
| 页面一致性 | 15 | {X} | ≥11 | ✅/⚠️/❌ |
| 状态完整性 | 15 | {X} | ≥11 | ✅/⚠️/❌ |
| 可用性 | 15 | {X} | ≥11 | ✅/⚠️/❌ |
| 可开发性 | 15 | {X} | ≥11 | ✅/⚠️/❌ |
| **总计** | **100** | **{X}** | **≥75** | - |
## 4. 各维度评分说明
### 4.1 页面结构完整性 — {X}/20
| 项目 | 内容 |
|------|------|
| 得分 | {X}/20 |
| 扣分原因 | {具体列出缺失的页面或模块} |
| 风险说明 | {如果不修复，对V1阶段的影响} |
| 修改建议 | {具体需要补充的页面清单} |
### 4.2 交互架构合理性 — {X}/20
（同上结构）
### 4.3 页面一致性 — {X}/15
（同上结构）
### 4.4 状态完整性 — {X}/15
（同上结构）
### 4.5 可用性 — {X}/15
（同上结构）
### 4.6 可开发性 — {X}/15
（同上结构）
## 5. 问题清单
| # | 优先级 | 维度 | 问题描述 | 影响范围 | 修改建议 |
|---|--------|------|----------|----------|----------|
| 1 | P0 | | | | |
| 2 | P0 | | | | |
| ... | | | | | |
## 6. 相似页面一致性问题
| # | 页面A | 页面B | 不一致点 | 建议统一方案 |
|---|-------|-------|----------|-------------|
| 1 | | | | |
| ... | | | | |
## 7. 状态缺失问题清单
| # | 页面/组件 | 缺失状态 | 优先级 | 建议处理方式 |
|---|-----------|----------|--------|-------------|
| 1 | | | | |
| ... | | | | |
## 8. 导航与信息架构问题
| # | 问题类型 | 具体问题 | 影响 | 修改建议 |
|---|----------|----------|------|----------|
| 1 | | | | |
| ... | | | | |
## 9. V1 准入前必须修复的问题
以下问题如果不修复，设计师将无法正常开展 V1 设计工作：
| # | 问题 | 原因 | 预计修复工作量 |
|---|------|------|---------------|
| 1 | | | |
| ... | | | |
## 10. 可后置优化项
以下问题可以在 V1 阶段或后续迭代中处理，不阻塞当前准入：
| # | 问题 | 建议处理时机 | 说明 |
|---|------|-------------|------|
| 1 | | | |
| ... | | | |
## 11. 优先修改建议
### TOP 5 必修问题（修复后方可准入）
1. **{问题标题}** — {一句话说明为什么必须修}
2. ...
3. ...
4. ...
5. ...
### TOP 5 优先修改建议（提升质量的最佳ROI）
1. **{建议标题}** — {预期收益}
2. ...
3. ...
4. ...
5. ...
## 12. 修正后预期提升空间
| 修复项 | 当前得分影响 | 修复后预计提升 | 修复后预计总分 |
|--------|-------------|---------------|---------------|
| {问题1} | -{X}分 | +{Y}分 | |
| {问题2} | -{X}分 | +{Y}分 | |
| ... | | | |
| **全部修复后** | | | **{预计总分}/100** |
## 13. 最终建议
**当前状态：** {一句话}
**建议路径：**
{根据分数给出2-3步的行动建议}
**预计修复工期：** {粗略估计}
---
> 注：本报告由AI辅助生成。标注"基于源码推断"的结论可能需要人工确认。
评审原则
- 以事实为依据：每个扣分点必须对应具体的页面或组件，不能凭"感觉"扣分
- 区分推断与事实：如果某个判断是基于代码结构推断而非直接看到的，必须标注「基于源码推断」
- 考虑原型阶段：V0 是快速验证阶段，不要用生产级标准要求视觉细节，但结构和逻辑完整度必须保证
- 给出可操作的建议：每个问题都要配具体的修改方向，不能只说"需要优化"
- 关注对 V1 的阻塞性：最重要的判断标准是「设计师拿到这个原型能不能开工」
工作流程
- 获取原型数据（读取HTML或通过Figma MCP获取）
- 如果用户没提供，简要询问产品背景信息
- 逐维度进行评审，记录发现的问题
- 计算评分，生成评分卡
- 汇总问题清单，确定优先级
- 生成完整报告，保存为 Markdown 文件
- 向用户呈现总分、结论和 TOP 5 问题摘要
注意事项
- 不要输出过程说明，直接输出最终报告
- 如果原型非常简单（例如只有1-2个页面），适当降低对页面数量的要求，但仍需按标准评分
- 如果无法确定某个功能的预期行为（比如不确定某个按钮点击后应该发生什么），标注为"逻辑待确认"并在可开发性维度中计入
- 评审过程中如果发现原型有明显的技术实现问题（比如HTML不规范导致渲染异常），也应在报告中提及，但不作为主要扣分项
