AI生成原型后，先挑一条真实任务走完，再把发现的问题分成任务、结构、状态、视觉、验收5轮修改。每一轮只改一个层级，并保留上一轮已确认的内容。这样即使生成结果不合预期，也能定位到具体字段、条件或跳转，不必从头重做整套页面。
下面沿用采购审批后台，提供一套能直接复制的练习材料、五轮提示词和逐轮应看到的结果。你可以直接复用文中的对话提示词，也可以先通过墨刀AI生成原型获得可编辑初稿，再按照5轮方法逐步调整。
AI生成原型后为什么不能直接进入评审
AI原型是根据需求描述自动生成的页面、组件和交互初稿。它的优势是启动快、便于探索方案，但首轮结果通常只覆盖最明显的正常流程。真实项目还需要确认业务字段、权限、异常、反馈、品牌规范和验收标准。
如果直接让团队评审首轮生成结果，讨论很容易被配色、圆角和布局吸引，而遗漏真正影响开发的业务问题。另一种常见做法是不断输入“更专业一点”“更高级一点”，这类模糊要求会让AI同时改变结构、文案和视觉，团队难以判断哪次修改真正有效。
五轮迭代原则：先业务、后界面；先结构、后视觉；每轮写清“保留什么、修改什么、如何判断完成”。
先准备一笔8万元的采购申请
不要每轮临时更换角色和金额。把下面这份材料放在对话最前面，五轮都使用同一笔申请；如果你的初稿还没有明确的需求规则，先按AI生成PRD的方法整理一版可确认的需求，再开始修改页面。
项目：采购审批后台，桌面端。
申请单：PROC-2026-018；申请人：林宁；部门：研发部。
采购内容：10台测试设备；单价8,000元；申请总额80,000元。
预算科目：研发设备；可用预算120,000元；附件：设备采购清单.pdf。
角色：林宁是申请人，只能查看；周岚是当前节点的采购审批人，可以同意或驳回。
当前状态：待采购审批；同意后进入待财务复核，下一审批角色为财务审批人。
P-01：只有当前节点被分配的审批人可以提交审批。
P-02：审批金额严格大于50,000元时，同意前必须二次确认。
P-03：驳回原因不能为空；提交失败保留原因；处理中不允许重复提交。
P-04：已撤回申请只读，不提供同意或驳回操作。
本轮不做：转交、批量审批、预算修改、真实付款。这组金额和规则用于练习采购流程，不代表墨刀内置了一套采购制度。操作前保存一份“采购审批 V0.1”，再按五轮分别保留修改记录。同一笔80,000元申请从列表、详情、弹层到结果页都应保持一致，它是最容易识别改动是否失控的参照物。
第一轮生成或修改前，先在预览中做一次记录：能否从待办找到 PROC-2026-018；详情是否显示120,000元预算；点击同意是否出现确认弹层；结果是否写“待财务复核”。只记录当前看到的结果，不把应有的结果提前写成通过。
第1轮：校准用户任务和页面范围
第一轮不要急着改颜色或组件，而要先回答三个问题：谁在使用？他要完成什么任务？完成后系统应该给出什么结果？这一步决定AI生成原型是否围绕真实目标，而不是堆砌常见模块。
假设首轮需求只有“生成一个采购审批后台”。可以改成下面这段对话：
保留当前后台的整体布局，不调整视觉风格。
本轮只校准用户任务和页面范围：
1. 用户是被分配到当前审批节点的采购审批人，目标是核对依据后完成本节点审批；
2. 页面范围为待办列表、申请详情、提交结果3个页面，以及1个审批确认弹层；
3. 详情页必须显示申请人、预算科目、采购金额、附件和历史审批记录；
4. 审批完成后明确显示结果、下一审批人和返回待办列表的入口。
不要增加数据看板、消息中心等与本任务无关的模块。“完成审批”在这里指完成当前节点，结果仍需进入财务复核；不要把本节点的“同意”画成整笔采购已终审。
修改完成后，先用一句话复述每个页面的任务。如果无法解释某个模块为什么存在，就应删除或放到后续范围，而不是继续装饰。
把页面收敛成一条可以走完的路线
| 页面或弹层 | 这一步应看到什么 | 下一步 |
|---|---|---|
| 待办列表 | PROC-2026-018，林宁，80,000元，待采购审批 | 点击该行进入申请详情 |
| 申请详情 | 明细合计80,000元、可用预算120,000元、采购附件、审批记录 | 点击同意，打开审批确认弹层 |
| 审批确认弹层 | 本次同意80,000元；确认后进入财务复核 | 取消回详情；确认后进入提交结果 |
| 提交结果 | “采购审批已同意”；流程状态“待财务复核”；返回待办入口 | 返回后此单从待我审批移至我已审批 |
如果修改后多出了数据大屏或付款页：圈定这些新增页面，补一句“删除本轮新增加的数据大屏与付款页，只保留上表路径；PROC-2026-018 的字段与当前样式保持不变”。不要再次发送整个后台的生成要求。
第2轮：修正信息架构、字段和操作优先级
第二轮处理“页面上有什么，以及它们如何分组”。产品经理应根据真实业务材料核对字段，避免AI用通用占位内容代替业务信息。对于后台系统，建议优先检查列表列项、筛选条件、详情分组、主次按钮和返回路径。
保留第1轮确认的3个页面、1个弹层和用户任务，本轮只修改信息结构：
1. 待办列表按“待我审批、我已审批、已撤回”分组；
2. 筛选项保留申请人、部门、金额区间和提交时间；
3. 详情信息分为基本信息、采购明细、预算与附件、审批记录；
4. “同意”为主按钮，“驳回”为清晰可见的次按钮；暂不增加转交和保存备注；
5. 不新增未经确认的字段，无法确定的数据标记为“待业务确认”。这一轮的验收重点不是页面是否美观，而是用户能否快速找到决策所需信息。涉及金额、权限、合规或业务承诺的字段，必须回到PRD、制度文件或业务负责人处核验。需求仍然分散时，可以先用AI生成PRD整理来源、规则和待确认事项。
用同一笔申请核对金额与字段
| 核对位置 | 应显示的内容 | 常见偏差与修正 |
|---|---|---|
| 列表金额与详情总额 | 均为80,000元；明细10×8,000元=80,000元 | 若一处仍是占位金额，只改 PROC-2026-018 的数据绑定或显示内容 |
| 预算与采购金额 | 预算120,000元与申请80,000元并列，单位都为元 | 不要把剩余预算计算成已扣减结果；是否预占预算尚不在本轮范围 |
| 审批操作 | 周岚可同意/驳回；林宁仅查看 | 看到两个角色都有审批按钮时，先改权限表现，不新增另一套详情页 |
| 列表分组 | 待我审批、我已审批、已撤回 | “已撤回”仅供查看历史；不得出现可再次审批的主按钮 |
字段相同不等于信息好找。预览时先问“周岚同意前要看哪三项？”本例是申请金额、预算依据和附件；把这三项放在同一阅读区，再安排历史审批记录，比给每条信息都加卡片更有用。
第3轮：补齐交互、权限和异常状态
AI生成原型图最容易遗漏的是边界状态。一个可评审原型不仅要展示“点击后成功”，还要说明什么时候不能点击、失败后怎么办、谁有权限、重复操作如何处理。
保持现有页面结构和字段不变，本轮只补充交互状态：
1. 列表增加加载中、无数据和加载失败状态；
2. 无审批权限时隐藏提交操作，并说明需要联系哪类管理员；
3. 驳回必须填写原因，同意超过5万元的申请需要二次确认；
4. 提交失败时保留已填写内容，提供重试入口；
5. 防止重复提交，处理中按钮不可再次点击；
6. 提交成功后显示审批结果、操作时间和下一步去向。建议让研发和测试参与这一轮评审。他们更容易发现数据依赖、接口失败、并发操作和恢复路径。复杂需求也可以通过AI需求评审先查找冲突、缺口和待确认规则，再反映到原型中。
用边界金额和失败状态查找断点
“超过5万元”很容易被生成结果改成“大于等于5万元”。先用同一份详情临时换入下表金额，再恢复80,000元；涉及状态不能通过真实请求触发时，可以在原型中建立对应状态画布并连好跳转，评审展示的是处理方式。
| 尝试的动作 | 本例预期 | 出错时给AI的局部修正 |
|---|---|---|
| 周岚同意49,999.99元申请 | 不出现高金额二次确认，进入提交处理 | 条件必须是金额＞50,000；不要调整其它按钮 |
| 周岚同意50,000.00元申请 | 与上一行一致，不触发高金额确认 | 将“≥50,000”改为“＞50,000”，保留边界值 |
| 周岚同意50,000.01元或80,000元申请 | 先出现确认弹层，取消后不改变审批状态 | 取消只关闭弹层；确认才进入提交处理 |
| 林宁进入同一笔申请 | 能查看详情，但没有同意/驳回入口 | 按 P-01 显示只读状态，保留详情字段 |
| 驳回原因留空后提交 | 停留在当前界面，提示“请填写驳回原因” | 校验失败时不跳转成功页 |
| 填写“附件缺少设备型号”后提交失败 | 原因仍在，可重试；处理中不可再次提交 | 保留输入值，只改变提交状态和反馈 |
若AI补齐异常状态时把主流程重新排版，停止这一轮，回到上一份保存结果，再分别处理“权限”“金额确认”“失败重试”。每条指令都写明只作用于申请详情或对应弹层。拆指令的依据是影响面，不是把同一句话换一种说法。
第4轮：统一组件、视觉和品牌规范
前三轮确认业务后，第四轮才进入视觉收敛。这里的目标不是追求更多装饰，而是让同类信息和操作使用一致的组件规则，降低用户理解成本，也方便设计和开发复用。
保持用户任务、字段、交互和所有异常状态不变，本轮只统一视觉规范：
1. 使用团队现有设计系统的表格、表单、弹窗和消息组件；
2. 主按钮、次按钮和危险操作保持固定层级；
3. 统一标题、正文、辅助文字的字号和颜色；
4. 金额风险和审批异常使用语义色，不使用颜色作为唯一提示；
5. 表格密度适合高频办公场景，长文本和小屏宽度下不遮挡；
6. 不改变已经确认的页面结构和业务文案。如果团队已有组件库，应直接写出组件名称和使用限制；如果尚未建立设计系统，至少固定颜色、字号、间距、圆角、按钮和表单规则。这样后续继续用AI修改UI时，输出不容易在不同页面之间漂移。低保真结构确认后，需要继续收敛界面细节时，可以用AI生成高保真设计稿探索视觉方案，但不要让视觉变化覆盖已经确认的业务规则。
给视觉修改一个可核对的范围
本例可以补充以下约定：申请详情里的字段标签保持左对齐；金额使用同一种千位分隔格式；“同意”保持主按钮；“驳回”不与“返回”混成同一层级；“待财务复核”用文字和状态标记共同表达。检查长附件名、窄窗口和驳回错误提示是否挤压操作区。
视觉修改后，再走一次80,000元的同意路径。如果二次确认消失，或结果变成“采购已完成”，这次调整就改变了业务。回退视觉修改，补充指令：“只调整组件外观；保留 P-02 的确认条件、弹层取消动作和待财务复核状态”。
第5轮：按验收标准收口为可评审版本
第五轮不再扩展功能，而是把原型变成有明确评审边界的版本。所谓可评审原型，是指参与者知道本轮要验证什么、哪些内容已经确认、哪些仍是假设，以及什么结果代表通过。
不要新增页面和功能。请根据以下标准完成评审版收口：
1. 用户可以从待办列表进入详情并完成同意或驳回；
2. 正常、无权限、校验失败、提交失败和提交成功状态均可查看；
3. 所有字段标明来源，未确认规则统一标记“待业务确认”；
4. 为关键操作补充交互说明和验收条件；
5. 输出本次变更清单、未解决问题和建议参会角色；
6. 版本名称改为“采购审批原型 V0.3-评审版”。评审会议应围绕任务和证据推进，而不是逐页收集审美意见。可以让参会者分别以采购审批人、财务审批人和无权限用户的身份完成任务，记录中断位置、误解和未覆盖规则。需要把验收标准进一步转成正常、异常和边界场景时，可以用AI生成测试用例补齐测试覆盖，再由测试人员确认是否可执行。
留下可交给同事的评审包
五轮结束时，至少保留原型链接、五轮修改记录和待确认问题。不要只发一句“大家看看新版”；可以直接使用下面这段评审说明，把其中的链接替换为实际项目链接。
评审对象：采购审批原型 V0.3-评审版。
本次任务：周岚从待我审批打开 PROC-2026-018，核对80,000元申请，完成同意或驳回。
本次已表达：申请字段、3页1弹层、当前节点权限、＞50,000元确认、失败保留输入、结果转财务复核。
请重点检查：50,000元边界；驳回原因留空；提交失败重试；申请人只读。
仍需确认：是否需要预算预占、下一审批人具体分配规则；本轮不据此增加付款或预算修改功能。
提出问题时请给出：页面/状态 + 操作 + 当前结果 + 期望结果 + 对应规则编号。
原型、PRD和记录：在此处填入实际项目链接。这段说明可以跟随分享链接一起发送。准备交研发时，再用PRD与原型一致性追踪矩阵将 P-01 至 P-04 对应到原型状态；这样下一次规则变化有明确的修改位置。
用一张记录表回看五轮改动
下表是本例的目标记录；实际操作后，在记录中补上观察结果和原型位置，不要把“预期”直接标成“已通过”。
| 轮次 | 本轮主题 | 应留下的改动 | 回看这一点 |
|---|---|---|---|
| 1 | 任务与范围 | 3个页面、1个确认弹层；删除大屏与付款页 | 能沿 PROC-2026-018 完成列表—详情—确认—结果 |
| 2 | 信息结构 | 列表/详情金额一致；预算与附件集中；申请人与审批人区分 | 80,000元、120,000元及设备附件可在详情核对 |
| 3 | 交互状态 | ＞50,000元确认；申请人只读；失败保留原因；防重复提交 | 50,000.00不确认，50,000.01确认；失败可重试 |
| 4 | 视觉规范 | 按钮层级、金额格式、状态文字、长文件名处理 | 视觉改变不影响 P-01 至 P-04 的行为 |
| 5 | 评审收口 | V0.3评审包、未决问题、任务脚本、关联PRD | 收件人知道检查什么、如何报告问题、哪些不在范围 |
下载采购审批五轮修改记录 CSV，或下载练习材料与提示词 Markdown。表中的申请、金额、规则和预期结果已填写，可以先完成一遍，再替换为自己的业务。
改完视觉后，回走三条采购路径
视觉改完不代表前面的业务规则还在。打开同一版本，用 PROC-2026-018 再走三遍；每遍只记实际结果、页面位置和需要修改的规则。
- 周岚同意80,000元：从待办进入详情，核对预算和附件，确认后看到“待财务复核”；取消确认时，申请仍应停在待采购审批。
- 林宁查看同一申请：详情信息可见，但不能提交同意或驳回；不能因为换了组件，就恢复了审批按钮。
- 驳回失败后重试：输入“附件缺少设备型号”，进入提交失败状态后，原因仍在；重试期间不可连续提交，成功后只保留本次审批结果。
记录可以只保留“操作、实际结果、原型位置、处理人”四列。如果没有出现确认弹层，记录“P-02未表达，需要补确认条件”，不要写“基本通过”。看到新问题时只回改对应规则；若第4轮误改了多条规则，则回到第3轮保存的版本，再限定视觉修改范围。
也可以让AI按 P-01 至 P-04整理差异：要求它列出对应页面、当前表现、冲突位置和缺少的材料。没有提供某个状态，就保留“待核对”，不把没有发现问题当成通过。更完整的规则对照可接着使用PRD与原型一致性追踪矩阵。
采购附件、分享范围和接口，交接前再确认
这份原型可以用文中的虚构姓名和练习附件完成评审。换成实际采购清单时，先移除与任务无关的员工个人信息、供应商报价和合同细节，并确认上传与分享范围。使用供应商图片或团队之外的图标、字体时，也要核对使用条件。
交接给研发时，单独列出本例还没有实现的工程规则：审批权限由哪个接口判断、重复请求如何去重、失败重试是否会重复写入审批记录。原型只能展示这些处理方式；采购提交、权限控制和记录保存仍需在实际系统中实现与验证。
常见问题：AI生成原型后如何继续修改
AI生成原型可以继续编辑吗？
可以，但要区分“重新生成图片”和“编辑结构化原型”。可编辑原型能够继续调整页面、组件、文案和交互，更适合团队评审与交付。修改前应先锁定不变项，避免一次指令让结构、规则和视觉同时漂移。
墨刀AI可以修改原界面吗？
可以通过明确的对话要求继续迭代生成结果，也可以把原型衔接到可编辑设计流程中完善。建议写清保留范围、修改对象、限制条件和验收标准，不要只输入“优化一下”。
每轮提示词应该写多长？
长度不是关键，边界清楚更重要。一轮提示词通常包含当前目标、必须保留的内容、需要修改的3至6项，以及完成标准。需求复杂时应拆成多轮，不要把业务、交互和视觉要求塞进同一条指令。
产品经理如何判断AI原型已经可以评审？
至少要满足四点：核心任务可以走通；关键业务字段有来源；正常和异常状态可查看；评审者知道本轮要验证什么。只有页面效果、没有规则和验收标准的版本，不适合作为正式评审稿。
AI原型迭代中谁负责确认业务规则？
AI可以整理和提示缺口，但规则仍应由对应负责人确认。产品经理负责需求边界，业务负责人确认政策与口径，研发和测试确认实现与异常路径，设计师负责体验和规范。本例的金额确认、审批分配和预算口径，分别由产品、业务与研发确认后再进入开发。
下一步：用一个真实需求完成5轮迭代
选择一个本周要评审的真实需求，从一份可编辑原型初稿开始，再依次完成任务、结构、状态、视觉和验收五轮对话。不要追求一次生成完美界面，而要让每次修改都有明确目标、可比较结果和责任人。完成后保留版本与修改记录，为下一轮产品决策提供依据。
