核心结论：AI原型评审应按结构、交互、状态和业务规则四层验收，而不是逐页讨论“像不像成品”。每一层都要对照需求来源，记录问题位置、影响、责任人和通过条件。只有核心任务可完成、关键规则有页面证据、异常能恢复、待确认项有归属，AI初稿才适合进入视觉深化或研发交付。
本文专门解决“AI生成后检查什么”，不重复会议组织和通用评审流程。需要了解会前准备、参会角色与会议节奏，可先查看产品原型评审完整流程；需要继续修改初稿，则可结合AI原型五轮迭代方法逐层修正。
评审开始前先冻结范围和版本
评审对象必须是一个可识别版本。写清本轮目标用户、核心任务、包含页面、不包含内容、需求来源和版本号；共享链接指向同一份评审版，不要在会议过程中直接覆盖。否则后来的意见无法判断针对哪个状态。
推荐准备“需求编号—页面—交互—状态—规则来源”的追踪表。每个关键内容都能回到PRD、流程图、业务制度或已确认决策；AI自行补充但没有依据的内容统一标记为待确认，不能因为界面看起来合理就默认通过。
AI原型为什么要分四层评审
四层的顺序不能随意交换：结构决定用户能否找到任务，交互决定动作如何发生，状态决定不同条件下看到什么，业务规则决定系统为什么允许或拒绝。上层仍在变化时先抠视觉细节，后续返工概率会明显增加。
| 评审层 | 核心问题 | 通过证据 |
|---|---|---|
| 结构 | 页面和信息是否支撑核心任务 | 任务—页面—信息映射完整 |
| 交互 | 用户动作、反馈和返回路径是否清楚 | 关键路径可点击走通 |
| 状态 | 条件变化、失败和权限差异是否覆盖 | 状态表与原型画面一致 |
| 业务规则 | 显示、校验、计算和权限是否有依据 | 规则来源、条件、结果可追溯 |
结构评审：每个页面是否服务明确任务
先从用户任务出发，不从页面列表出发。检查起点是否自然、页面是否过多或缺失、信息分组是否符合决策顺序、主操作是否突出、完成后是否有明确去向。一个页面若无法说明“谁在什么条件下用它完成什么”，就可能是AI套用的通用模块。
- 页面范围是否与本轮任务一致，没有擅自扩展报表、消息等模块？
- 页面、弹窗和抽屉的拆分是否由任务或状态变化决定？
- 关键字段是否来自真实需求，而不是通用占位信息？
- 主次操作是否与用户目标和风险等级一致？
- 列表进入详情、提交后返回、取消退出等路径是否闭合？
结构不通过时，先调整页面矩阵和信息层级，不要让AI同时更换视觉。可以通过AI生成可编辑原型快速补齐缺页或重组结构，但必须保留已经确认的任务和字段。
交互评审：每个动作是否有触发、反馈和结果
逐个检查核心操作的触发条件、操作过程、系统反馈、成功结果、取消方式和返回位置。按钮能点击不代表交互完整；如果提交后没有处理中状态、弹窗关闭后丢失输入、返回列表后筛选条件消失，用户任务仍然会中断。
评审时用“动作句”描述问题，例如“用户修改金额后再次提交，系统应重新校验并保留附件”，不要只写“这里交互不对”。动作、条件和预期结果越具体，后续修改越容易验收。
状态评审：不要只画正常成功页
AI最容易生成默认状态和成功结果，却遗漏空、加载、错误、无权限、禁用、处理中和部分成功。先按页面列状态，再按关键组件补状态；每个状态都要写进入条件、可见信息、允许操作和退出条件。
后台和复杂业务场景可参考空、错、加载与无权限状态设计补齐恢复动作。错误提示不能只说明“失败”，还要告诉用户原因、数据是否保留、可以重试还是需要改条件，以及最终回到哪里。
业务规则评审：界面上的每个限制都要有依据
业务规则包括显示条件、必填校验、金额计算、角色权限、状态转换、时效和并发处理。对每条规则至少回答：谁触发、在什么条件下、系统做什么、用户看见什么、失败如何处理、来源在哪里。
以“超过5万元需要二次审批”为例，评审者还应确认金额口径、币种、是否含税、谁是第二审批人、原审批结果是否保留、规则变更后历史单据如何处理。AI生成的阈值和角色若没有来源，只能作为待确认示例。
用追踪表检查四层是否真正闭环
评审清单不能停留在勾选。建议把需求编号、页面证据、交互路径、相关状态、规则来源、问题等级和负责人放在一张追踪表中。某项没有原型证据时标记“缺失”，存在但规则未确认时标记“待定”，已经走查通过才标记“通过”。
线上协作时，可结合远程原型评审的版本与评论方法让每条意见定位到具体页面和状态。评论解决不等于问题通过；修改后还要由原提出者或指定验收人按条件复查。
问题怎么分级，什么情况不能通过
P0用于核心任务无法完成、严重越权、关键数据错误或缺少恢复路径；P1用于主要规则缺失、需要解释才能完成、状态矛盾或高风险误操作；P2用于效率、理解和一致性问题；P3用于不影响任务的局部视觉和文案优化。
出现以下任一情况，不建议把版本标记为“评审通过”：核心任务有断点；PRD与原型关键规则冲突；AI新增重要角色或业务规则但无人确认；错误后数据丢失且无法恢复；不同权限看到相同敏感操作；待确认项没有负责人和截止条件。
AI原型评审检查清单
- 版本、范围、目标用户和核心任务是否写清？
- 每个页面能否映射到一个任务或必要状态？
- 字段、分组和主次操作是否支撑用户决策？
- 关键动作是否包含触发、反馈、结果、取消和返回？
- 默认、加载、空、错、禁用、无权限和成功状态是否按需覆盖？
- 显示、校验、计算、权限和状态转换是否有真实来源？
- AI自行补充的内容是否被标记为待确认？
- 每个问题是否有证据、等级、责任人和验收条件？
- 修改后是否建立新版本，并由明确人员复查？
常见问题
AI原型评审和可用性测试能互相替代吗？
不能。内部评审核对需求、规则和实现边界；可用性测试观察目标用户能否理解和完成任务。通常先让内部评审排除明显规则错误，再用用户行为验证方案。
评审时要不要讨论视觉？
可以，但应放在结构、交互和关键状态稳定之后。视觉评审关注组件一致性、层级、可读性和品牌规范，不应重新打开已经确认的业务范围。
所有问题都必须在本轮解决吗？
不必。范围外建议可以进入后续待办，但影响核心任务、关键规则、权限、数据和异常恢复的问题必须在进入下一阶段前解决或形成明确的风险接受结论。
AI原型评审真正要验收的不是页面数量，而是任务、界面和规则是否互相对应。坚持按结构、交互、状态和业务规则逐层检查，并保留证据与决策记录，团队才能把快速生成的初稿稳定地推进到可测试、可交付的版本。
