需求文档转成原型图，关键是把文字中的角色、动作、规则和异常，分别落到页面、组件、状态和交互上。先选一条完整流程，整理页面与状态清单，再让 AI 生成初稿或手工搭建；完成后逐条对照原需求，补缺失反馈和返回路径。不能仅凭画面精美，就判断需求已经实现。
使用墨刀 AI 生成原型时，可以把需求资料与生成目标一起提交，再继续调整。下面沿用社交 App 的场景，用“发布一条社区动态”讲清输入、生成与编辑三个阶段。已有 PRD 也不必整份重写，先抽出与这条任务有关的章节即可。
先分清：文档里的哪些内容要画成页面
PRD 的背景、目标、业务规则和技术约束不是同一种信息。“用户希望分享日常”是目标，“点击发布进入编辑页”对应路径，“内容为空不能提交”对应状态，“内容保存多久”则可能需要业务和研发共同确认。把它们全部扔给 AI，容易得到很多页面，却遗漏关键规则。
| 文档信息 | 转成原型时表达什么 | 社区发布示例 |
|---|---|---|
| 用户角色与权限 | 谁能看到入口，谁能执行动作 | 已登录成员可以发布；访客发布前需要登录 |
| 主流程 | 页面顺序、入口和返回 | 信息流 → 编辑动态 → 发布结果 → 信息流 |
| 输入与校验 | 字段、可选项、禁用和错误反馈 | 文字为空且没有图片时，不能直接发布 |
| 业务状态与异常 | 等待、失败、恢复与已完成状态 | 上传失败可重试；发布失败保留已填内容 |
| 范围与约束 | 暂不做的功能，以及待确认说明 | 本次不做视频、付费内容和复杂审核后台 |
一个需求不一定对应一个页面。发布失败可以是编辑页内的一条提示，图片上传中可以是图片区域的局部状态。先判断用户是否进入了新的任务，再决定新建页面还是补状态，避免出现十几个只有一行文字不同的页面。
第一步：把一段需求整理为可生成的任务说明
下面是一段用于练习的需求，包含本轮明确采用的规则。实际项目请换成已经与业务确认的版本；字符数量、图片上限和身份条件都不应由 AI 随意决定。
需求：社区 App 发布动态
目标：已登录成员能发布文字或图片动态，并在信息流看到结果。
输入：文字最多 500 字；最多 9 张图片，支持调整顺序和删除。
校验：文字和图片不能同时为空；有图片上传失败或上传中时不能发布。
发布过程：点击后显示发布中，避免重复提交。
结果：成功后回到信息流，新动态出现在顶部；失败保留内容，可再次尝试。
退出：编辑过内容后离开，询问继续编辑还是放弃；本轮不做草稿长期保存。
范围外：视频、付费内容、评论管理、内容审核后台。
待确认：单图大小与格式、发布频率限制、审核是否影响立即展示。接着为重要规则分配短编号。编号用于把页面和原文连接起来，不需要把文档每句话都编号。例如 R01 是非空校验，R02 是上传状态，R03 是发布结果，R04 是退出处理。后续业务改动时，就能知道哪些页面和状态受影响。
| 需求编号 | 页面或局部区域 | 必须包含的状态 |
|---|---|---|
| R01 · 非空校验 | 编辑动态页的发布按钮与输入区 | 空白、仅文字、仅图片、超出字数 |
| R02 · 图片上传 | 编辑页的图片区域 | 上传中、成功、失败、删除后的变化 |
| R03 · 发布结果 | 编辑页与信息流 | 发布中、失败可重试、成功回到信息流 |
| R04 · 离开编辑 | 返回入口与确认浮层 | 未编辑直接离开；已编辑询问放弃或继续 |
这时再准备文档或粘贴需求，任务范围会比“做一个社交 App”清楚得多。资料里有重复或冲突时，例如一处写“成功立即展示”，另一处写“审核后展示”，先把冲突列出来，不要让 AI 选择一条后悄悄删掉另一条。
第二步：先确认结构，再生成可以操作的初稿
在墨刀 AI 输入区域提交材料后，先要求整理页面与状态。如果直接生成整套页面，发现入口顺序和范围不对时，往往需要同时修改多个页面。下面的提示词适合把准备好的发布动态需求先转成结构。
请根据提供的“社区 App 发布动态”需求，先整理页面和状态，不补充未确认规则。
输出：
1. 页面清单：信息流、编辑动态，以及必要的局部浮层。
2. 每页列出入口、主要控件、用户动作和下一步。
3. 把 R01—R04 映射到具体页面或局部状态。
4. 标出空白、上传中、上传失败、发布中、发布失败与成功的表现。
5. 将资料冲突和缺失规则放到“待确认”，不要自行决定。
本轮不加入视频、付费、评论管理或后台页面。检查输出时，先看它是否把“上传失败”和“发布失败”混成同一个状态：前者发生在图片区域，用户可以针对一张图片重试或删除；后者发生在提交内容后，应保留整份内容并允许再次提交。再看是否出现范围外页面，及时删除无关内容。
结构确认后，再给出布局方向和生成范围。界面风格只需要足够支撑评审，例如移动端单列信息流、底部主操作、清楚的错误信息；不要先堆叠一串互相矛盾的视觉形容词。
按已确认结构生成移动端原型。先完成信息流和编辑动态两页。
信息流保留“发布”入口；编辑页包含文本输入、字数提示、图片列表和发布按钮。
把 R01—R04 的状态放进可演示路径：空内容不能发布，上传失败能处理，发布失败保留内容，成功返回信息流。
使用简洁、留白清楚的界面；首轮重点检查位置、文案和行为。
未确认的图片大小、发布频率和审核规则只保留说明，不新增限制。生成结束后实际走一次流程：从信息流进入编辑，输入内容，处理失败状态，再返回。若 AI 只是画出了“失败”字样，却没有重试或取消入口，这个需求仍未落到可操作的路径上。可以把缺口直接圈定到区域，让下一次修改只处理这一项。
第三步：按缺失的规则继续编辑，而不是整套重做
当页面结构大体正确时，保留已有成果，逐项修正问题。一次要求“更专业、更丰富、更好看”，通常会同时改变布局和内容，反而不容易判断原问题是否解决。把修改说明写成区域、现状、目标及需要保留的部分。
修改编辑动态页的图片上传区域：
当前：图片失败后只有红色提示，没有恢复操作。
目标：每张失败图片显示“重试”和“删除”；有上传中或失败图片时，发布按钮不可用并说明原因。
删除最后一张图片后，如果文字也为空，仍按 R01 禁止发布。
保留现有顶部导航、输入区和整体视觉，不新增页面。另一个常见缺口是退出编辑：如果用户只进入页面而未修改，返回可以直接离开；已经写了内容时，返回应出现确认。确认中的“继续编辑”回到原内容，“放弃”清空本次编辑并返回信息流。不要用同一个返回动作覆盖这两种情况。
继续改 HTML，还是转换为原型原生元素
如果生成产物是 HTML 页面，可以在预览区域点击“编辑”进入可视化编辑，继续修改局部内容。导入墨刀原型时，默认的 AI 组件承载 HTML 和动态交互，也能继续进行 HTML 可视化编辑；需要逐个调整原型元素时，再转换为可编辑元素。
这两种形态适合不同目标。保留 AI 组件，适合继续修改和演示已有 HTML；转为原生元素，适合精细调整页面、补原型交互和交付设计资源。转换后的原生页面需要重新检查状态与跳转，不应假定 HTML 脚本都会成为原生交互。具体入口可查看HTML 可视化编辑与转换说明。
评审时，怎样判断需求是否真的被表达出来
不要只按页面数量验收。用同一条任务核对需求编号、操作和预期结果；将尚未实现的状态标为缺口，评审后再补，避免把漂亮的静态页面误交为完整交互原型。
| 检查情境 | 原型应表达的结果 | 对应规则 |
|---|---|---|
| 没有文字也没有图片 | 发布不可用，能理解还缺什么 | R01 |
| 有文字但一张图片上传失败 | 能针对该图重试或删除，不能直接提交 | R02 |
| 提交后失败 | 保留文字、图片及顺序，出现可重试入口 | R03 |
| 发布成功 | 回到信息流，可以看到刚发布的内容 | R03 |
| 编辑过内容后点击返回 | 继续编辑保留内容；确认放弃后才离开 | R04 |
涉及真实账号、上传服务、发布审核和长期存储的部分，原型可以表达界面与预期规则，工程实现仍需要另外对接。评审记录应写清当前演示了什么、哪些规则待业务确认、哪些状态还未补齐；例如“审核是否影响立即展示未确定，因此发布成功后的提示暂未定稿”。
需求变化后，先找受影响的状态
假设图片上限从 9 张改为 6 张，至少影响上传入口、数量提示、已有超过上限内容的处理，以及测试用例。先更新需求规则和页面说明，再修改界面；不要只把“最多 9 张”的文案替换为“最多 6 张”，却仍允许继续上传。
如果改为“审核后展示”，则需要重新讨论发布成功后的信息流表现和提示文案，这属于流程变化，不是换一张结果图。按需求编号追踪改动，才能判断应该局部修改还是重画相关路径。
从现有文档中选出一条最明确的流程，照着角色、规则、状态清单准备输入，就可以开始第一版。需要梳理文档本身的结构，可继续阅读用 AI 拆解需求和待确认问题；准备好输入后，在墨刀 AI生成这条流程，并按上面的检查情境逐项走通。
