拿到一份 AI 生成的采购审批原型，先做三个动作：同意一笔 50,000 元的申请、连续点击两次审批提交、在请求超时后尝试继续操作。这三次走查能暴露金额边界、重复操作和结果不确定的问题；只浏览成功页面，往往看不出来。
AI原型评审应按结构、交互、状态和业务规则四层核对。下面接着采购审批后台的 PROC-2026-018 申请，把评审从“感觉不对”推进到具体页面、复现步骤和通过条件，并提供可以直接使用的验收用例表与整改记录。如果还没有明确的需求编号与页面对应关系，先按PRD与原型一致性方法整理来源；若初稿仍缺主路径，可用AI原型五轮迭代方法补齐后再评审。
评审开始前先冻结范围和版本
评审对象必须是一个可识别版本。写清本轮目标用户、核心任务、包含页面、不包含内容、需求来源和版本号；共享链接指向同一份评审版，不要在会议过程中直接覆盖。否则后来的意见无法判断针对哪个状态。
推荐准备“需求编号—页面—交互—状态—规则来源”的追踪表。每个关键内容都能回到PRD、流程图、业务制度或已确认决策；AI自行补充但没有依据的内容统一标记为待确认，不能因为界面看起来合理就默认通过。
PROC-2026-018：把这份材料带进评审
沿用五轮迭代文章中的同一笔申请：林宁申请采购10台测试设备，单价8,000元，总额80,000元；预算科目为研发设备，可用预算120,000元，附件为“设备采购清单.pdf”。周岚是当前节点的采购审批人。评审前把以下规则放在原型链接旁边。
评审版本：PRD v1.2 / 采购审批原型 V0.3-评审版。
P-01：只有当前节点被分配的审批人可以提交审批；申请人林宁只能查看。
P-02：审批金额严格大于50,000元时，同意前必须二次确认；50,000元不触发，50,000.01元触发。
P-03：驳回原因不能为空；提交失败保留原因；处理中不允许重复提交。
P-04：已撤回申请只读，不提供同意或驳回操作。
本例结果：周岚同意80,000元申请后，显示“采购审批已同意”，进入“待财务复核”，不是整笔采购终审完成。
本轮不做：转交、批量审批、预算修改、真实付款。
准备待办列表、申请详情、提交结果三个页面及一个审批确认弹层；另能定位加载、无权限、驳回校验失败、提交失败与已撤回等状态。边界走查临时换入49,999.99、50,000.00、50,000.01元，完成后恢复80,000元，不据此推断其他金额的后续审批制度。
这轮还要细化一个容易被“提交失败”掩盖的分支：连接超时后，审批结果可能尚未确认。将它列为 P-03 的待确认处理分支，请研发说明怎样查询原请求结果，再决定能否重试。
AI原型为什么要分四层评审
建议先确认页面结构能支撑核心任务，再逐项核对交互、状态和业务规则。结构决定用户能否找到任务，交互决定动作怎样发生，状态说明条件变化后看到什么，规则解释为什么允许或拒绝。遇到规则冲突就回到需求材料，不必等到最后一层才处理；视觉细节留到这些问题稳定后再讨论。
| 评审层 | 核心问题 | 通过证据 |
|---|---|---|
| 结构 | 页面和信息是否支撑核心任务 | 任务—页面—信息映射完整 |
| 交互 | 用户动作、反馈和返回路径是否清楚 | 关键路径可点击走通 |
| 状态 | 条件变化、失败和权限差异是否覆盖 | 状态表与原型画面一致 |
| 业务规则 | 显示、校验、计算和权限是否有依据 | 规则来源、条件、结果可追溯 |
结构评审：每个页面是否服务明确任务
先从用户任务出发，不从页面列表出发。检查起点是否自然、页面是否过多或缺失、信息分组是否符合决策顺序、主操作是否突出、完成后是否有明确去向。一个页面若无法说明“谁在什么条件下用它完成什么”，就可能是AI套用的通用模块。
- 页面范围是否与本轮任务一致，没有擅自扩展报表、消息等模块？
- 页面、弹窗和抽屉的拆分是否由任务或状态变化决定？
- 关键字段是否来自真实需求，而不是通用占位信息？
- 主次操作是否与用户目标和风险等级一致？
- 列表进入详情、提交后返回、取消退出等路径是否闭合？
结构不通过时，先调整页面矩阵和信息层级，不要让AI同时更换视觉。可以通过AI生成可编辑原型快速补齐缺页或重组结构，但必须保留已经确认的任务和字段。
先从周岚的待办走到财务复核
- 以周岚视角打开待我审批，找到 PROC-2026-018；列表显示林宁、80,000元和待采购审批。
- 进入详情，核对10×8,000元的采购明细、120,000元可用预算、采购附件与历史审批记录。
- 点击同意，先看到80,000元的确认弹层；取消后仍回到待采购审批，不改变单据状态。
- 再次同意并确认，进入提交结果；显示“采购审批已同意”和“待财务复核”，返回后此单从待我审批移至我已审批。
通过：周岚能找到决策所需信息，完成当前节点后知道下一步。不通过：三页一弹层虽然都存在，列表却跳到空白详情；或者结果写成“采购完成”，让人误以为财务与付款都已完成。
信息缺失时，整改单写“审批详情增加预算科目与采购附件”，不要写“详情页更丰富”。若缺的是确认弹层或返回待办的路径，先修页面和跳转，不要让AI重新生成一套后台。
交互评审：每个动作是否有触发、反馈和结果
逐个检查核心操作的触发条件、操作过程、系统反馈、成功结果、取消方式和返回位置。按钮能点击不代表交互完整；如果提交后没有处理中状态、弹窗关闭后丢失输入、返回列表后筛选条件消失，用户任务仍然会中断。
评审时用“动作句”描述问题，例如“周岚填写驳回原因后提交失败，系统应保留原因并说明下一步”，不要只写“这里交互不对”。动作、条件和预期结果越具体，后续修改越容易验收。
重复提交，要看第二次点击发生了什么
周岚对80,000元申请点击同意并确认后，检查提交过程；再以驳回路径补做一次输入保留测试。
- 确认提交后立即显示处理中，不再接受重复审批动作，原申请信息保留。
- 在处理中再次尝试提交，不应出现第二条审批路径，也不应跳到另一个空白结果页。
- 成功后显示本节点已同意、待财务复核和原申请编号；返回列表仍能找到同一笔申请。
- 回到驳回分支，先留空原因点击提交，应停留并提示必填；再输入“附件缺少设备型号”，进入明确提交失败状态，原因应保留，可按已确认规则重试。
原型通过的证据：这些画面和跳转表达了同一条审批过程。研发还需要确认：服务端如何识别重复审批请求、怎样查询提交结果。原型按钮被禁用，只说明界面规则表达清楚，不能证明接口已经避免重复处理。
状态评审：不要只画正常成功页
AI最容易生成默认状态和成功结果，却遗漏空、加载、错误、无权限、禁用、处理中和部分成功。先按页面列状态，再按关键组件补状态；每个状态都要写进入条件、可见信息、允许操作和退出条件。
后台和复杂业务场景可参考空、错、加载与无权限状态设计补齐恢复动作。错误提示不能只说明“失败”，还要告诉用户原因、数据是否保留、可以重试还是需要改条件，以及最终回到哪里。
超时不能直接等同于提交失败
这里最容易做错：请求超时后，原型只弹出“提交失败，请重试”，周岚又审批一次。但第一次请求可能已经成功，只是返回结果丢失。先显示“正在确认审批结果”，查询原提交，再决定是否重试。它与“接口已明确返回失败、可以重试”是两个不同分支。
| 页面条件 | 应该看到什么 | 下一步怎样继续 |
|---|---|---|
| 驳回原因未填 | 原因字段提示必填，停留当前页 | 补写原因后提交 |
| 审批提交中 | 显示处理中，阻止重复操作 | 等待结果，不提前显示整笔采购已完成 |
| 接口明确提交失败 | 说明失败，保留驳回原因 | 按已确认的失败规则重试 |
| 连接超时，结果未知 | 显示“正在确认审批结果”，保留当前申请信息与输入 | 先查询原提交结果，暂不直接重复审批 |
| 查询确认已同意 | 显示原申请编号、采购审批记录和待财务复核 | 进入该申请详情，不再次提交审批 |
| 查询明确未提交 | 说明未提交，保留原输入 | 允许重试；请求标识与查询协议由研发确认 |
| 查询仍无确定结果 | 显示结果仍待确认 | 继续查询或联系处理人，不把未知写成成功 |
不通过：超时后同时出现“审批已完成”和“重新提交”，或者驳回原因消失。通过：明确失败、已成功和结果未知互不混淆，每种状态都有下一步。原型不能触发真实网络条件时，为这些分支建立可定位画面，并在交互说明里写清进入条件。
业务规则评审：界面上的每个限制都要有依据
业务规则包括显示条件、必填校验、金额计算、角色权限、状态转换、时效和并发处理。对每条规则至少回答：谁触发、在什么条件下、系统做什么、用户看见什么、失败如何处理、来源在哪里。
本例 P-02 规定“金额严格大于50,000元，同意前需要二次确认”。如果原型变成“大于或等于5万元”，恰好50,000元就会多出确认弹层；如果80,000元点击同意后直接提交，则缺了已确认的操作保护。不要把二次确认误写成第二个审批人：前者是周岚的确认动作，财务复核是本例后续流程节点。
| 测试金额 | 周岚点击同意后 | 发现什么就不通过 |
|---|---|---|
| 49,999.99元 | 不触发高金额二次确认，进入提交处理 | 出现高金额确认弹层 |
| 50,000.00元 | 仍不触发高金额二次确认 | 按“大于或等于”错误触发 |
| 50,000.01元 | 先二次确认，确认后才提交 | 直接进入提交，或取消后也提交 |
| 恢复80,000元 | 二次确认后提交；成功进入待财务复核 | 结果误写整笔采购已完成 |
不要只检查提示中的“超过”二字。真正的通过证据是金额条件、弹层出现时机、取消动作和确认动作一致。边界金额只用于检查确认条件，不能反向推断这些金额是否需要财务审批。
可把下面的要求交给AI辅助查漏：
对照采购审批规则P-01至P-04，检查原型V0.3的页面清单和状态说明。逐项列出规则编号、页面位置、触发条件、当前反馈、期望反馈。重点检查49,999.99 / 50,000.00 / 50,000.01元的二次确认条件、重复点击、驳回失败保留原因与提交超时。恢复80,000元后核对结果为待财务复核。只引用所给材料；看不到的分支写“缺少画面证据”，不要判断通过，也不要自行补写业务规则。按“问题—影响—需要谁确认”输出。
用追踪表检查四层是否真正闭环
评审清单不能停留在勾选。建议把需求编号、页面证据、交互路径、相关状态、规则来源、问题等级和负责人放在一张追踪表中。某项没有原型证据时标记“缺失”，存在但规则未确认时标记“待定”，已经走查通过才标记“通过”。
线上协作时，可结合远程原型评审的版本与评论方法让每条意见定位到具体页面和状态。评论解决不等于问题通过；修改后还要由原提出者或指定验收人按条件复查。
把一条问题写成下一位同事能复查的记录
问题：REV-02 / P-02 / 申请详情—同意。
复现：在原型V0.3临时将金额改为50,000.00元，周岚点击同意。
当前结果：出现高金额二次确认弹层。
期望结果：不触发该弹层；只有金额严格大于50,000元才触发。
处理人：设计负责人修改条件表达与跳转；产品负责人核对P-02；测试负责人复查三个边界金额及80,000元主路径。
关闭条件：V0.4中49,999.99与50,000元不触发，50,000.01元和80,000元触发；取消不提交，确认才提交，80,000元成功结果仍为待财务复核。
如果设计只改了“大于或等于”的文字，却没有改弹层触发，这条问题仍不能关闭。评论点“已解决”是处理动作；按关闭条件走通路径，才是验收动作。
问题怎么分级，什么情况不能通过
团队可以沿用既有的问题等级；如果还没有约定，可按对当前交付的影响分级：核心任务断点、关键金额错误或越权路径作为阻塞项，必须先修；主要状态缺失安排在交付前完成；局部效率、视觉和文字问题可进入后续任务。P0—P3 的名称并不是统一标准，开会前要先说明本团队的定义。
出现以下任一情况，不建议把版本标记为“评审通过”：核心任务有断点；PRD与原型关键规则冲突；AI新增重要角色或业务规则但无人确认；错误后数据丢失且无法恢复；不同权限看到相同敏感操作；待确认项没有负责人和截止条件。
本例可以这样作出结论：金额确认条件错误，不通过；超时后的恢复路径未定，阻塞；错误文案中有一个不影响理解的标点问题，可带任务通过，但需要明确负责人和完成时间。对于未确认的财务规则，不能仅凭“研发以后处理”把整条审批路径交付出去。
AI原型评审检查清单
- 版本、范围、目标用户和核心任务是否写清？
- 每个页面能否映射到一个任务或必要状态？
- 字段、分组和主次操作是否支撑用户决策？
- 关键动作是否包含触发、反馈、结果、取消和返回？
- 默认、加载、空、错、禁用、无权限和成功状态是否按需覆盖？
- 显示、校验、计算、权限和状态转换是否有真实来源？
- AI自行补充的内容是否被标记为待确认？
- 每个问题是否有证据、等级、责任人和验收条件？
- 修改后是否建立新版本，并由明确人员复查？
下载采购审批验收表和整改记录
采购审批原型验收用例表（CSV）包含 12 条已写好条件和预期结果的用例，覆盖入口、金额确认边界、重复提交、超时、驳回与角色差异；“实际结果”留空，便于团队按自己的原型填写。采购审批评审记录（Markdown）包含规则卡、三条填写示范、修改要求和复查结论写法。
完成检查后，应得到一份明确的结果：哪个版本通过，哪些问题已经复查，哪些任务带到下一轮。将这份记录连同原型和需求版本，按AI原型团队协作与交付流程交给下一位负责人。需要安排会议和远程评论时，可继续参考产品原型评审流程。
常见问题
AI原型评审和可用性测试能互相替代吗？
不能。内部评审核对需求、规则和实现边界；可用性测试观察目标用户能否理解和完成任务。通常先让内部评审排除明显规则错误，再用用户行为验证方案。
评审时要不要讨论视觉？
可以，但应放在结构、交互和关键状态稳定之后。视觉评审关注组件一致性、层级、可读性和品牌规范，不应重新打开已经确认的业务范围。
所有问题都必须在本轮解决吗？
不必。范围外建议可以进入后续待办，但影响核心任务、关键规则、权限、数据和异常恢复的问题必须在进入下一阶段前解决或形成明确的风险接受结论。
AI原型评审真正要验收的不是页面数量，而是任务、界面和规则是否互相对应。坚持按结构、交互、状态和业务规则逐层检查，并保留证据与决策记录，团队才能把快速生成的初稿稳定地推进到可测试、可交付的版本。
