核心结论：PRD 转原型不是把文档段落直接变成页面，而是先从需求文档中提取用户、任务、页面、流程、规则和状态，再生成可编辑页面，最后用需求追踪矩阵检查每条需求是否有原型证据。缺少这一步映射，AI 很容易生成“页面看起来完整，但关键规则没有落地”的原型。
本文用“退款申请”功能演示从 PRD 到可评审原型的完整流程，适合产品经理、交互设计师、创业团队和需要用 AI 提速需求落地的产研团队。
PRD 转原型的正确顺序是什么
推荐顺序是：明确原型目标 → 结构化 PRD 输入 → 提取页面矩阵 → 对齐流程和状态 → 生成页面 → 补交互 → 建立需求追踪 → 评审验收。页面生成只占其中一步，前后的结构化和验收决定结果能否用于开发沟通。
如果 PRD 还不完整，可先用AI 生成 PRD补齐用户角色、功能清单、流程和异常条件；已有文档则直接进入下面的提取步骤。
第 1 步：先定义这次要生成什么原型
先确定目标端、用户角色、任务范围、保真度和评审对象。例如：“生成移动端退款申请流程，覆盖订单详情、申请、凭证上传、进度和结果通知；用于产品、设计和开发评审；暂不处理财务后台。”
范围不清时，AI 往往把相关功能全部加入页面，导致 URL、页面数和业务边界不断膨胀。建议把“本轮包含”和“本轮不包含”写成两个列表。
还要给本轮需求建立编号。编号不必复杂，可以按模块使用 REFUND-01、REFUND-02。它的价值不是形式规范，而是让评审者能够指出“REFUND-03 的上传失败状态缺失”，而不是笼统地说“好像少了点东西”。
第 2 步：把 PRD 整理成可生成的结构化输入
一段自然语言很难稳定映射成页面。至少提取六类信息：用户、任务、前置条件、规则、结果和异常。对于每个功能点，再写清“谁在什么条件下做什么，系统如何响应，成功和失败分别进入什么状态”。
还不熟悉文档结构时，可以参考PRD 文档结构与写作方法，但不要为了“文档完整”写大量与本轮原型无关的背景材料。
把模糊表述改写成可生成规则
“支持退款”无法直接生成页面，应改写成：“已付款且未超过 7 天的会员订单显示退款入口；用户选择原因并确认金额后提交；金额超过实付金额时禁用提交并提示；申请进入审核中后展示预计处理时间。”这样的句子同时包含角色、条件、动作、校验和结果。
第 3 步：从用户任务提取页面矩阵
页面不应该按 PRD 章节数量生成。更可靠的拆法是：一个用户任务对应一个或多个页面；当用户目标、操作对象、权限或状态发生明显变化时，再拆出新页面或弹层。
页面矩阵至少包含哪些列
- 用户任务：用户当前想完成什么。
- 页面或弹层：任务在哪个界面完成。
- 关键组件：页面必须出现哪些输入、信息和操作。
- 进入条件：从哪里来，需要什么权限或状态。
- 成功结果与异常状态：完成后去哪，失败后怎么办。
页面矩阵还可以帮助合并冗余页面。如果“查看退款进度”和“查看退款结果”只是在同一页面中状态不同，就不必生成两个独立页面；反过来，如果不同角色看到的操作和数据完全不同，则应拆开，避免用隐藏逻辑把复杂权限塞进同一画面。
第 4 步：在生成页面前对齐流程和状态
PRD 中的流程节点要能在原型里找到承接页面，原型里的按钮也要能追溯到流程节点。先把用户动作、系统处理和人工审核分开，再检查每个判断分支是否有出口。
PRD 与流程图相互矛盾时，不要让 AI 任选一个版本。应把冲突列为待确认项，并在评审前使用AI 需求评审或人工走查确认规则。
状态命名应保持一致。PRD 写“审核中”，流程图写“处理中”，页面又显示“待确认”，团队很难判断是否是同一个状态。生成前先建立状态表，记录状态名称、进入条件、允许操作和退出条件，再把同一套词用于 PRD、流程和原型。
第 5 步：生成页面，并限制 AI 不要扩展需求
将页面矩阵、流程和视觉要求一起作为输入，明确“不得新增未在 PRD 中出现的角色、页面和业务规则”。先生成结构和基础交互，再统一视觉；不要一开始同时要求复杂动效、品牌视觉和所有异常状态。
请根据以下 PRD 生成移动端退款申请原型。页面范围仅包含：订单详情、退款申请、凭证上传、退款进度和结果通知。请为每个页面标注对应需求编号，覆盖可申请、超时、上传失败、审核中、通过和驳回状态。不要新增优惠、物流或客服规则。输出后列出：页面清单、跳转关系、缺少的信息和需要产品确认的规则。
可以通过AI 生成可编辑原型快速起稿，再在画布中调整组件、内容和交互。
哪些 PRD 不适合直接生成原型
只有愿景、口号和功能名称，没有角色、规则或结果的 PRD 不适合直接生成；包含大量相互矛盾版本、没有标记最新结论的文档也不适合。先做需求澄清和版本清理，比反复要求 AI“重新生成得更合理”更有效。
第 6 步：补齐交互、校验和异常反馈
逐页检查输入限制、按钮可用条件、二次确认、加载反馈、失败重试、权限不足和重复提交。原型里若只有“点击后跳转”，却没有展示系统校验与错误反馈，开发仍然需要重新猜测。
第 7 步：用需求追踪矩阵做评审验收
需求追踪矩阵把“PRD 是否覆盖”从主观印象变成可核对证据。每条需求至少关联一个原型页面、一个交互或状态，以及评审结论。没有原型证据的需求标为待补；没有 PRD 来源的页面标为范围外。
矩阵中的“通过”不是指页面已经好看，而是需求覆盖、规则一致且结果可验证。“待补”表示已有明确规则但原型缺证据；“阻塞”表示规则本身尚未确认。把这三种结论分开，能避免设计团队替产品决策，也能避免开发带着未确认规则开工。
评审时只需要回答 6 个问题
- 目标用户和本轮任务范围是否一致？
- 每条核心需求是否有对应页面或状态？
- 每个按钮是否有明确目标和系统响应？
- 判断、权限、金额、时间等规则是否在原型中可见？
- 空、错、加载、失败和重复提交是否覆盖？
- AI 新增的页面或规则是否已被产品确认？
原型进入视觉优化前，还可沿用AI 原型五轮迭代方法继续校准任务、结构、状态、视觉和验收。
常见问题
一份完整 PRD 可以一次生成所有页面吗
可以尝试，但不建议把大范围产品一次生成。按核心任务或功能模块分批生成，更容易保持页面一致性，也便于发现规则冲突和遗漏。
PRD 里没有流程图还能生成原型吗
可以，但至少要提供页面顺序、判断条件和成功失败结果。流程描述越模糊，AI 越容易补出未经确认的跳转和业务规则。
生成高保真页面后还需要低保真评审吗
如果任务、页面和流程尚未确认，先看低保真结构更高效。高保真视觉会让评审过早讨论颜色和细节，掩盖需求与交互问题。
如何避免 PRD 和原型后续不同步
保留需求编号、页面清单和追踪矩阵；每次需求变更同时更新 PRD、流程、原型状态和评审结论，并记录修改日期和负责人。
PRD 转原型后还需要写交互说明吗
需要。原型可以展示路径和状态，但复杂校验、数据口径、权限、接口依赖和非功能要求仍应保留文字说明。原型和文档各自承担不同信息，不应互相替代。
PRD 转原型的关键不是生成速度，而是需求、页面、流程和状态之间的可追溯关系。把文档整理成结构化输入，用页面矩阵确定范围，用流程和状态约束生成，再通过追踪矩阵验收，才能得到团队可以评审和继续开发的可编辑原型。
