评审会上最难解释的原型或者UI，是那种页面看起来已经很完整，但大家顺着按钮点下去，发现
关键业务规则根本没有地方呈现
。
例如要做一个企业内部的请假审批流程，告诉AI核心功能是“员工提交申请，主管审批，HR备案”，AI很快能排出申请表、审批列表和详情页。但跨月假期怎么算？主管不在岗时谁接手？申请被退回后，员工修改的是原单还是新建一单？这些没有说清，UI界面再整齐也只能拿来做初稿。
产品经理用AI做原型UI，第一步应当是把业务规则整理到足以被AI画出来的程度。
不要一上来就列“需要三个页面”，最好先写一条具体路径：员工填写申请，提交后查看状态；主管收到待办，查看假期余额和团队排班后作出决定；被退回的申请回到员工手里，并显示原因。
沿着路径看，每个动作都需要一个明确的入口和反馈。员工点击提交时，哪些字段必填？主管拒绝时是否必须填写理由？HR备案是自动流转，还是还要确认一次？
可以先把流程写成“角色—动作—系统反馈”三列。
如果一句规则还无法说清由谁触发、产生什么结果，暂时不要让AI替它设计按钮。
否则AI会按照常见产品习惯补全空白，而那个习惯未必符合你的业务。
这一步很适合让AI帮忙找遗漏，比如我会用Paico的需求规划功能，把已知规则交给它，它会多轮对话和我讨论，并列出尚未定义的状态和异常情况，如果不放心可以再由业务方逐项确认。
第一版原型UI出来后，很多人会先走主流程：填表、提交、审批、完成。其实这条线是最容易画的，更值得检查的应该是
流程被打断时会发生什么
。
请假审批至少有待填写、待审批、已通过、已拒绝、已撤回几种状态。申请资料不全时，提交按钮应提示什么？主管审批过程中员工能否撤回？审批人换岗后，历史记录归谁查看？这些状态会影响列表筛选、详情页操作和提示文案。
检查时还可以把一份真实但匿名的样例申请从头走到尾，
再换一份有问题的样例
。逐屏标记用户看不到答案的地方。这样做比笼统地要求“补齐异常状态”有效，因为团队能指出具体在哪个页面、哪个动作之后卡住。AI可以把常见结构快速摆上画布，但业务状态、权限和文案仍需要产品经理核对。
我的建议是，等需求已经梳理清楚后，再让AI UI工具起草页面。输入的提示词里要包含角色、操作路径、必须展示的信息、不可改变的规则，以及这次只做哪些页面。
例如第一轮只生成员工申请页和主管审批详情页，不要求一次做完整系统。申请页需要假期类型、起止时间、剩余额度、交接人和附件；审批详情页需要申请信息、历史记录、同意与退回操作。每个字段都应能追溯到一个业务用途。
我在用Paico生成UI草稿时，会先让它处理这两个页面，再
在可编辑设计稿里调整字段顺序和操作区
。已有团队规范的话，可
上传Design.md或选用现成组件库
，让按钮、表单和状态样式尽量沿用原有规则。重点是把已确认的需求落到画布上，而不是让一次生成替代需求评审。若后续要交给设计师继续细化，可以直接导出到团队使用的Pixso或Figma设计工具里。
“这个按钮往右移一点”和“主管可以转交审批”看起来都是改稿意见，性质却不同。前者主要影响布局，后者会增加角色权限、流转状态、通知和操作记录。
评审记录
最好把意见分成三类
：业务规则变更、交互与信息调整、视觉细节。每改一条业务规则，就回到流程里检查上下游页面。增加转交审批后，主管列表要有转交入口，接手人要收到待办，员工可能需要看到当前审批人，历史记录也应留下痕迹。
这时再让AI修改原型UI，指令应写清改动范围和需要保留的部分。重新生成整套页面容易把已经确认的结构一并改掉。修改完成后，用上一轮的样例申请再走一遍，确认原有路径没有被破坏。
如果习惯用设计工具，比如已经在Pixso画布里维护设计稿，也可以
用Pixso AI基于资源库规范修改界面
。无论在哪个工具中改，评审记录都应保留“为什么改”和“哪些状态受影响”。
当原型或UI通过评审，
还差一步才能交给开发
。页面里可能有“审批中”的标签，但没有写明状态从什么时候开始；也可能画了“撤回”按钮，却没有说明审批通过后还能不能撤回。交付说明重点写清字段来源、状态流转、角色权限和异常提示。对每个主要按钮，至少说明点击条件、操作结果、失败反馈。没有定下来的规则直接标为待确认，不要让开发从画面推测。
AI UI工具可以帮忙整理初版说明，也能根据原型生成页面代码。生成React代码或通过设计转代码流程读取设计稿，都不能替代业务逻辑确认。开发拿到的应该是经过评审的页面、状态说明和未决问题，而不只是几个看起来完整的界面。
一份原型是否有用，评审时看的是大家
能否围绕同一条业务路径发现问题
；交付时看的是开发遇到边界情况能否找到答案。页面画得快是好事，但规则走样后的返工更贵。
