AI生成原型后，团队最需要的不是再发一次链接，而是一份能接手的任务包：当前原型、对应规则、评审决定、待办负责人，以及这一版允许研发开始做的范围。只说“大家看一下”，得到的往往是零散意见；把一个具体任务、一个版本和几个待决定问题放在一起，才有办法推进。
下面沿用水果生鲜APP：用户购买车厘子3斤装，结算前库存从2件变成1件，优惠券也因数量变化而失效。你将看到这次变化如何从页面评论变成产品决策、设计修改、研发任务和测试验收，并可直接下载已填好的交接包。
先让团队接住同一个生鲜下单任务
AI生成的页面通常能帮助团队更早看到结构，但“能点击”不等于“已确认”。把它当成最终交付物，会隐藏三类风险：页面字段可能只是合理猜测，正常路径可能缺少异常状态，视觉效果可能掩盖了权限、数据和实现约束。
把初稿拿来共同走一条路径，比让每个人浏览不同页面更容易发现分歧。采购者关心能否下单，设计师关心反馈是否清楚，研发需要知道订单何时创建，测试要知道异常结果。四个视角最后应落到同一份版本、规则和任务记录中。
在进入这一步之前，先按AI原型评审清单确认主路径能演示。这里重点解决评审结果怎样被团队接走，不需要重新展开一次工具选型。
| 本例固定材料 | 具体内容 |
|---|---|
| 商品 | SKU CHERRY-3J：车厘子3斤装，单价129元，购物车原数量2件 |
| 库存变化 | 加入购物车时可买2件，提交订单前最新可售量变为1件 |
| 优惠券规则 FRESH-02 | 商品金额满199元减10元，同一张券只核销一次；本例不展开运费 |
| 库存规则 FRESH-01 | 提交前按最新可售量校验；超出时不创建订单，展示差额，并让用户确认数量调整 |
| 提交规则 FRESH-03 | 创建订单结果未知时先查询原请求结果，不能通过再次点击直接新建订单 |
| 当前材料 | PRD v1.2、AI原型 V0.2；本轮形成 V0.3 交付稿 |
两件商品金额为258元，满足优惠后为248元；改为一件后商品金额129元，未满199元，原优惠不再可用。这里的重点不是优惠算法多复杂，而是库存调整同时改变了数量、价格和提交条件，一次页面修改会牵动多个角色的工作。
用一张接手单说明这次要决定什么
不要把需求背景重新写成一篇长 PRD。先用一页接手单把评审所需的上下文补齐，放在原型链接旁边，让没有参与生成过程的人也能快速进入问题。
| 接手单字段 | 水果生鲜APP示例 | 为什么必须写 |
|---|---|---|
| 目标任务 | 新用户选择车厘子3斤装，在库存变化后确认数量与金额，再继续下单 | 防止评审变成逐页挑视觉细节 |
| 原型范围 | 首页（含搜索结果）、商品详情、购物车、结算、订单；个人中心仅验证订单查询入口 | 明确本轮看什么、不看什么 |
| 已确认规则 | 提交前校验最新库存；满199减10；同券只核销一次 | 把业务事实与AI猜测分开 |
| 待确认问题 | 结算时库存变少，如何让用户确认数量，并重新确认不再满足满减的金额？ | 把争议变成可回答的问题 |
| 当前版本 | V0.2 / PRD v1.2；产品A主持，周三16:00评审 | 让评论和修改有归属、有时间边界 |
接手单只写影响本次决策的信息。AI生成的文案、图片和推荐字段，如果还没有业务来源，应标记为“示例”或“待确认”，不要因为它出现在页面里就把它当成产品事实。
接手单发出时同时说明每个人要回来给什么答案：产品确认库存和优惠规则；设计补库存变化的页面与操作；研发确认库存校验和订单创建的时序；测试按数量、金额和重试条件复查。不要给四个人同一个“看看有没有问题”的任务。
邀请文字可以直接复制：
请评审生鲜下单 V0.2 / PRD v1.2，主路径为车厘子3斤装两件结算。重点决定两件事：①可售量变为1件时如何让用户确认数量；②调整后不满199元，如何说明优惠失效。请在周三16:00前按 FRESH-01/02 记录意见，每条写页面位置、触发条件和期望结果。支付退款及会员体系不在本轮范围。原型链接与规则卡见本消息附件。
把库存不足、优惠失效和支付异常交代清楚
团队评审 AI 原型时最容易漏掉的不是主页面，而是操作之后会发生什么。先围绕关键任务补状态，能让产品、设计、研发和测试在同一张问题地图上讨论。
| 任务节点 | 至少补哪些状态 | 评审要问的具体问题 |
|---|---|---|
| 搜索与列表 | 无结果、加载、网络失败、筛选后为空 | 用户知道下一步怎么继续吗？ |
| 商品详情 | 库存不足、规格切换、图片加载失败 | 价格、库存和可购买状态是否同步？ |
| 购物车 | 数量上限、失效商品、重复提交 | 修改数量后总价和优惠是否重新计算？ |
| 下单支付 | 成功、失败、取消、超时、权限不足 | 用户能否分辨“订单已创建”和“支付未完成”？ |
| 订单售后 | 无订单、处理中、已完成、不可操作 | 不同角色看到的操作是否一致？ |
补状态不是为了把页面做复杂，而是为了让评审从“页面像不像成品”转向“任务是否闭环”。当一个状态会改变数据、权限或下一步动作时，必须在原型或说明中明确表达，不能留给研发猜。
沿车厘子下单路径走一遍
以水果生鲜APP为例，不要让每个人自由浏览五个页面。给所有评审人同一条任务：搜索车厘子 → 选择 3 斤装 → 加入购物车 → 修改数量 → 提交订单 → 处理库存不足。每个人都沿着这条路径走，反馈才有可比性。
- 从入口开始：确认用户能否理解首页搜索、分类和推荐的区别。
- 记录关键动作：选择规格、加购、改数量和提交订单，每一步都写下预期结果。
- 主动触发异常：切换到预先准备的“最新可售1件”状态，检查提示位置、文案和恢复路径。
- 核对角色差异：如果运营、客服或管理员看到不同操作，记录权限条件。
- 收敛成问题：把“感觉不顺”改写为“用户在库存不足后无法知道是否需要重新选择规格”。
可以从这段提示词开始，再按项目实际修改：“为新用户设计水果生鲜APP，完成搜索、选择规格、加入购物车和下单；页面包括首页（含搜索结果）、商品详情、购物车、结算、订单和个人中心，个人中心仅保留订单查询入口；库存不足、优惠券失效、支付失败必须有明确状态；输出可点击页面，并保留可编辑结构。”这是一份示例输入，不是所有项目的固定模板。
把这条路径写成每个人都能照着走的脚本
| 顺序 | 评审人操作 | 此时应该看到的结果 |
|---|---|---|
| 1 | 搜索车厘子，选择3斤装，加购2件 | 商品单价129元、数量2、商品金额258元 |
| 2 | 使用满199减10的优惠券 | 优惠10元，本例商品应付金额248元 |
| 3 | 进入提交前库存变化分支 | 提示“该规格目前最多可买1件”；不创建订单，也不静默把数量改成1 |
| 4 | 确认改为1件 | 商品金额129元，提示“不满199元，该优惠券不可用”；优惠取消后的金额明确可见 |
| 5 | 用户重新确认后提交 | 显示提交中，阻止重复点击；成功后进入对应订单详情 |
| 6 | 进入创建订单结果未知分支 | 先查询原结果；已创建则打开原订单，明确未创建后才重试 |
这一轮不通过的情况：数量从2件悄悄变成1件；仍减去10元，显示119元；库存不足时先创建了无法履行的订单；超时重试生成第二张订单。原型评审通过：这条路径的画面、跳转和规则都对应一致。库存扣减、优惠核销和订单幂等的真实行为，列入研发与测试任务继续验证。
把库存争议写成可执行的评论
评论区最怕出现三种句子：“这里再优化一下”“感觉不够高级”“能不能更简洁”。它们表达了偏好，却没有告诉执行者改什么、为什么改、改到什么程度。
建议每条关键评论都包含三个部分：观察到的事实 → 对任务的影响 → 建议的决策。例如：“库存不足时按钮仍显示可提交，用户可能误以为订单已创建；本轮先提示最新可售量，用户确认改为1件后重新计算优惠与金额；产品确认规则，设计补画面，研发明确库存校验时序。”
| 评论类型 | 不够用的说法 | 可执行的说法 |
|---|---|---|
| 任务问题 | 首页有点乱 | 新用户找不到分类入口；把搜索放在首屏第一操作区，并由产品确认优先级 |
| 状态问题 | 这里要考虑异常 | 支付超时后保留原订单号，先查询支付结果；确认可重试时才提供相应动作，禁止再次创建订单 |
| 规则问题 | 这个按钮能不能隐藏 | 客服角色不可修改库存；按角色隐藏并在接口层拒绝写入 |
| 视觉问题 | 颜色不够醒目 | 错误提示与价格信息对比不足；设计按现有品牌色规范调整，并由测试复核可读性 |
从一句抱怨，改成一张修改任务
意见 FB-07：V0.2 / 结算页 / 库存不足。购买2件时最新可售量变为1件，页面直接把数量改成1，仍显示已优惠10元。用户没有确认新数量和金额。
本轮决定 D-03：保留原选择，提示最新可售1件；用户确认后调整数量，移除不满足门槛的优惠，再确认金额。
设计任务 DS-08：补提示、确认调整、优惠不可用三个状态及取消返回；不新增到货提醒或会员功能。
验收：按步骤1—4走查，金额依次为258、248、129元；取消调整时保持原购物车，但禁止超库存提交。
产品决定“怎么处理库存变化”，设计把决定表达为画面，研发确认实现时序，测试用具体数据复查。评论可以关联到页面位置，但不能仅凭评论已关闭就认定所有角色的任务完成。
用规则编号连接页面和交互说明
AI原型进入团队后，最容易出现“页面改了、PRD没改”“评论说了、研发找不到”的分叉。文档的作用不是把页面重新描述一遍，而是记录页面无法单独表达的规则、状态、数据来源和验收条件。
每个关键页面至少补四类信息：触发条件、数据规则、状态变化、验收标准。例如购物车页要写清数量变化如何影响库存与优惠，提交失败时订单是否创建，测试如何判断“重复点击没有重复下单”。
可以用墨刀AI整理规则说明，再在墨刀原型中补齐对应页面、预览路径和评论位置。文档里保留规则编号，原型说明引用同一编号；需要持续维护两边对应关系时，按需求追踪矩阵核对变更。
本例不需要在PRD里逐字描述每个按钮的位置，只需让以下对应关系稳定下来：
- FRESH-01 → 结算页库存变化：写清最新库存不足时不创建订单，用户怎样确认数量、怎样取消。
- FRESH-02 → 优惠失效状态：写清按调整后的商品金额重新判断门槛，129元时不享受满减。
- FRESH-03 → 结果待确认：说明先查原请求结果，研发补查询与重复请求约定，测试复查只有一张订单。
让AI协助整理时，可复制这段要求：
根据以下原型页面说明、规则 FRESH-01/02/03 和评审意见 FB-07，整理 V0.3 交付包。分别输出：已确认决策、设计修改、研发依赖、测试用例、未决问题。每项保留对应规则与页面位置，任务写负责人角色和完成条件。不要把“待确认”改写为“已实现”；不要新增会员、到货提醒或促销规则。金额使用：129元/件，原数量2件，满199减10，最新可售1件。
让 V0.3 的决策进入交付记录
评审结束后不要只说“大家没意见了”。没有决策记录，下一次修改仍会重新争论同一问题。最小可用的决策记录包含版本、结论、依据、负责人、截止时间和未决风险。
| 决策项 | 本例记录 | 下一步 |
|---|---|---|
| 库存不足的处理 | 数量超出库存时不创建订单；用户确认调整数量后重新核对金额 | 产品确认规则；研发确认接口状态 |
| 优惠券失效 | 结算页提示原因，允许移除后继续下单 | 设计补充文案；测试添加回归用例 |
| 个人中心范围 | 本轮只验证订单查询，不评审会员体系 | 另建后续任务，避免扩大当前版本 |
| 版本编号 | V0.3 作为本轮开发评审稿 | 所有新评论关联 V0.3，不覆盖历史结论 |
如果意见冲突，记录“暂不决定”也是一种有效决定，但必须写出需要什么证据、由谁补齐、什么时候再议。这样团队不会把沉默误认为共识。
不要在研发使用的版本里继续随手改
当 V0.3 进入开发后，新意见仍会出现。例如运营希望把优惠门槛从199元改为99元。此时先记为 CHG-04，列出受影响的结算提示、优惠金额和测试用例，不能直接覆盖 V0.3 的原型与规则。
保留 V0.3 的评审记录与可定位材料，再建立 V0.4 工作稿；明确哪一份可用于开发、哪一份仍在讨论。如果当前分享链接始终指向最新稿，就在交付包中同时留存版本记录或对应快照，并注明链接用途，避免把会持续变化的工作链接当作固定验收依据。
| 材料 | V0.3：当前开发 | V0.4：后续工作稿 |
|---|---|---|
| 优惠规则 | 满199减10，已经确认 | 满99减10，等待运营和产品决定 |
| 一件129元 | 不满足优惠，商品应付129元 | 如果新规则批准，则为119元；现在不能替换旧验收条件 |
| 交接动作 | 研发与测试按V0.3执行 | 评估影响与排期，批准后一起更新规则、原型和用例 |
给研发一份能接手的任务包
研发不需要一张更长的截图，而需要能判断实现边界的材料。建议把以下内容放在同一个项目或交付入口中：
| 交付材料 | 研发要能回答的问题 | 谁负责补齐 |
|---|---|---|
| 可点击原型与版本号 | 当前实现哪条路径，哪些页面还在探索？ | 产品/设计 |
| 状态与交互说明 | 点击、失败、取消、重复提交分别发生什么？ | 产品 |
| 数据与权限边界 | 字段来自哪里，谁能看、谁能改？ | 产品/研发 |
| 评审决策记录 | 哪些意见已经采纳，哪些被明确拒绝？ | 产品 |
| 验收条件 | 开发完成后按什么结果判断通过？ | 产品/测试 |
如果交付材料还包含生成的页面代码，研发先核对能复用的组件和接口接入点。本例最重要的是库存校验时序、优惠重新计算和订单请求去重；页面代码并不能证明这三件事已经实现。
把一个库存问题拆成四张可验收任务
| 任务与负责人 | 要完成的内容 | 交回什么才算完成 |
|---|---|---|
| PM-03 / 产品A | 确认库存变化与优惠门槛规则，关闭FB-07的规则争议 | PRD v1.2的FRESH-01/02及决策D-03；未决项单独列出 |
| DS-08 / 设计B | 补数量确认、优惠不可用、取消返回和结果待确认分支 | V0.3页面位置、可预览路径、对应规则编号 |
| DEV-12 / 研发C | 明确校验库存、创建订单、查询结果和优惠核销之间的顺序 | 接口时序与错误返回约定；哪些分支尚未完成需明确标注 |
| QA-09 / 测试D | 用固定SKU和金额复查主路径、库存变化、取消、重复点击与超时 | 测试条件、实际结果、缺陷链接；原型通过与接口通过分别记录 |
接手时可以采用明确的分工顺序：产品先确认规则，设计与研发随后并行补画面和接口约定，测试再把两份材料转成用例。设计任务完成，不代表 DEV-12 已完成；研发还缺查询接口约定时，交付状态写“界面范围已确认，结果未知分支待研发确认”，不要笼统写“已交付”。
下载生鲜APP V0.3交接包（Markdown），其中已填好规则卡、版本约定、评审邀请和交付目录。另可下载四角色任务表（CSV）与六条验收用例（CSV），替换项目成员和链接后即可使用；实际结果由团队走查后填写。
在墨刀里保留项目与评审上下文
把这次交接放进墨刀时，围绕当前项目检查四件事：
- 结果可编辑：生成页面能否继续调整，而不是只能下载一张图。
- 上下文可留存：需求、原型、说明和评论能否围绕同一项目继续追踪。
- 评审可收敛：能否把意见关联到版本和页面，并形成明确结论。
- 交付可衔接：研发能否拿到可点击路径、状态规则和实现边界，而不是只拿到视觉截图。
可用墨刀团队协作把编辑和评审留在项目中：先安排产品与设计维护页面，评审者用同一条预览路径评论，再把采纳意见回写任务表。远程参与者的会前材料、评论格式和讨论节奏，可参照在线原型远程评审方法。
如果你的输入不是文字，而是手绘草图或已有截图，可先看从草图生成原型图的方法；输入方式不同，但进入团队协作前仍要完成同样的接手、状态和决策步骤。
已有团队项目时，优先把原型、规则、评论与任务接回既有工作台；需要比较不同工具的编辑与协作方式，再查看原型设计工具选型指南。
未决问题怎样继续推进
并不是每个问题都能在一次评审里决定。把它写成能被关闭的缺口，比反复提醒“还需人工确认”更有用。本例有两个典型未决项：
- OPEN-01：库存校验发生在什么时点？研发C补充创建订单的接口时序，产品A核对失败时是否会生成订单；未确认前，不能以“库存不足不建单”作为已实现结论。
- OPEN-02：优惠券在创建订单还是支付成功时核销？产品A与研发C确认业务与数据状态，测试D补支付取消、超时及重复提交用例；不能让AI文档默认选择某个时点。
每个缺口写清需要的材料、负责人、截止时间和影响范围。若它只影响支付后的处理，可以先推进已确认的商品浏览页面；若它决定能否创建订单，就要标明阻塞结算分支。涉及金额、权限或不可逆操作的规则，必须由对应负责人确认后再加入交付版。
分享范围也随任务设置：内部评审使用必要成员可访问的材料，外部演示只包含适合对外展示的数据。评审材料不必向无关成员开放，演示数据也不用包含真实订单或客户信息。
常见问题
AI生成原型后，应该先发给谁？
先发给能确认目标任务和业务规则的产品负责人，再邀请设计、研发和测试按同一条任务路径走查。先确定评审问题，再发链接，能减少无目的浏览。
评审时应该看页面还是看文档？
两者都要，但顺序是先用原型走任务，再用文档补规则和验收条件。页面回答“用户看见什么、怎么操作”，文档回答“为什么这样做、异常时怎么办、怎样算完成”。
AI生成的原型能直接交给研发吗？
通常不能直接当作完整工程需求。至少要补齐版本、状态、数据和权限边界、已决策问题与验收条件；代码输出若有，也只能作为结构起点，真实接口、权限、安全和性能仍需研发处理。
如何判断团队真的达成共识？
让团队成员按同一任务复述入口、关键状态和完成标准，并能找到对应版本、评论结论和负责人。没有可追踪证据的“大家都同意”，不算稳定共识。
下一位同事能接手，才算交付完成
AI生成原型最值得利用的地方，是让团队更早拥有一个可以共同观察的对象；它不能替团队决定业务规则，也不能替研发承担实现责任。把初稿接手、状态补齐、结构化评审、版本决策和交付材料固定下来，AI 才会从一次性出图工具变成团队持续迭代的入口。
如果你已经准备好一份真实需求，可以从墨刀AI原型入口开始，生成后按本文的接手单和评审清单推进；把已确认规则与待决定问题一起放在原型旁边，方便下一位同事接手。
最终检查只有一个问题：下一位接手的人，能否在不参加生成过程的情况下，知道当前版本解决什么、哪些地方已经决定、哪些风险仍待确认？如果答案是肯定的，AI 原型才真正进入了团队协作流程。
