现在产品经理或者设计师，基本都用AI做后台原型。AI做后台很快：导航、数据卡片、列表和详情页都有，视觉上也像一个完整系统。但很多地方出现问题，还达不到评审的程度，比如按钮点下去以后，原型没有说明是保存、返回还是进入下一步。
所以我更关心的不是界面像不像后台，是这套多页面原型能不能沿着一条任务走完。下面用一个
Paico生成的跨境电商售后管理系统原型
做例子，看看多页面AI原型该怎么验收。
这个原型共有7个页面，面向客服主管和售后专员，
任务包括退货、退款、换货、物流和争议处理
。首页先给出待处理退货、SLA超期预警、待审退款金额等概览，接着进入退货申请列表，再打开某个工单处理。
先检查列表页的筛选条件是否能解释首页的数字？从“退货申请”进入订单详情后，用户能否回到原来的筛选结果？详情页的“批准退款”“拒绝退货”分别会进入什么状态？把页面按钮按任务走一遍，很多问题不用等到开发阶段才发现。
我会先写一张很短的路径表
：入口、动作、下一页、完成条件。比如“退货列表→打开RS-8821→查看证据→批准退款→进入退款审批”。如果一个按钮只能写成“点击后看情况”，说明需求还没有落到原型里。
案例里的列表行有工单号、平台、订单号、SKU、退款金额、原因、证据数量、SLA倒计时和状态。打开#RS-8821后，详情页继续显示Amazon US、SKU-BT-007、申请退款金额$128.50、证据3/3已上传，以及“SLA：-2h”的超期提醒。
这些字段不是装饰，它们要在页面之间接得上。列表显示“与描述不符”，详情页就应该能看到买家选择的具体原因；列表显示3/3份证据，详情页要能定位到破损照片、包装照片和功能演示。若AI把同一工单改成不同金额或不同状态，页面单看都合理，串起来就会失真。
一个字段尽量只在流程中决定一次，后面页面负责引用、补充或允许修改。
设计师可以把关键字段列成表，标注来源、可编辑页面和展示格式。交给AI生成多页时，这张表比一段“做得统一一点”的描述有用得多。
这个原型把SLA超期工单放在首页优先位置，列表页也提供“超期、即将超期、正常”的筛选。验收时要继续追问：筛选没有结果时显示什么？证据只有1/3份时，审批按钮能不能点？退款已批准后，列表状态、详情页时间线和首页数量是否一起变化？
后台系统常见的状态至少有
加载中、空数据、筛选无结果、权限不足、提交失败和数据过期
。状态不一定要各画一张新页面，但要在画布中留出清楚的组件状态。比如证据不足时提示“还缺少2份材料”，并说明由谁补传；提交失败时保留已填备注，给出重试入口；权限不足时告诉用户联系哪个角色。
让AI补状态时，指令要限制范围：“只修改退款审批区域，补充证据不足、审批中、审批失败三种状态，沿用现有按钮和颜色规则，不改列表字段。”范围越清楚，局部修改越不容易牵连其他页面。
这个案例是Paico生成的线框原型，页面数量、角色和核心任务先被整理出来，适合拿来讨论信息架构。AI生成后仍要
在可编辑画布里逐页看
：导航是否重复，列表和详情是否使用同一套字段，组件状态是否覆盖了真实工作。
发现问题时，可以在具体位置打开编辑模式修改。比如把首页的“待审退款金额”与列表筛选结果对应起来，把详情页的处理时间线补上“人工复核待确认”，再重新走一遍任务。
原型评审通过后，
可以继续让Paico生成UI界面
。若团队已有组件库，可以在生成前提供Design.md或组件规则，减少同一个按钮在不同页面出现不同变体。
AI生成的设计稿会在原型基础上做高保真视觉设计，最后卡一导出到Pixso设计文件中继续细化，或者通过设计到代码流程生成React实现，不过代码阶段仍要检查字段、状态和权限。
找一位没有参与生成的人，只给他一个任务：“处理一笔Amazon退货，查看证据并完成审批。”不要解释应该点哪里，记录他在哪一步停住、返回后丢了什么、有没有把“超期”和“待审核”混为一谈。
这轮测试可能会暴露页面之间的断点，修正后再跑主路径，并把暂时没有结论的规则标为“待产品确认”，例如退款审批是否需要主管权限、证据不全能否转人工、筛选条件返回后是否保留。AI能把第一版原型搭起来，设计师和产品经理仍要决定任务边界与验收标准。
多页面原型的质量，一般体现在一条流程能不能顺畅走完。先查路径，再查字段，再查异常状态，最后走一遍用户体验，AI生成的页面才有机会进入真实项目。
