原型不是效果图，而是成本最低的需求沟通工具
第二天下午，我做了一个很简单的沟通实验：一位同学只用语言描述几何图形，其他人照着画，过程中不允许提问。几十位参与者里，第一轮只有极少数人画对。
第二轮允许随时澄清后，正确率明显提升。这个实验没有复杂理论，却让全班直接看到：同一句话进入不同人的头脑，会形成不同画面。
文字准确，不代表理解一致
需求文档可以写得很完整，但阅读者仍然会依据自己的经验补全空白。
“首页展示热卖商品”这句话，产品经理想到的可能是瀑布流卡片，设计师想到的是大图推荐，开发者想到的是一个普通列表，业务方则可能只关心库存商品优先展示。
大家都没有故意误解，只是文字无法承载所有细节。如果直到开发完成才看到真实页面，分歧就会以返工的方式出现。
原型把抽象讨论变成具体决策
可交互原型让团队可以直接讨论：入口在哪里、点击后发生什么、不同角色看到什么、异常时如何反馈。
它的价值不是替代 PRD，而是暴露 PRD 中还没有被真正理解的部分。当业务方指出“这里不应该先支付，而应该先确认库存”时，原型完成了它最重要的工作：在编码前发现认知差异。
因此，我判断原型质量不会只看视觉，而会看它是否支持关键决策。
评审原型时应该问什么
不要把评审变成“颜色好不好看”的意见会。可以按四类问题推进：
业务问题
- 用户从哪里进入，最终要完成什么？
- 哪些步骤需要人工处理或其他角色参与？
- 状态变化是否符合真实业务？
页面问题
- 每个业务节点由哪个页面承载？
- 页面之间的前进、返回和中断路径是否清楚？
- 移动端和桌面端的主要使用场景是什么？
功能问题
- 正常操作后系统给出什么反馈？
- 无数据、错误、重复操作和权限不足时怎样处理？
- 哪些功能属于本期，哪些只是未来设想？
决策问题
- 本次评审要确认哪些事项？
- 尚未确认的问题由谁补充、何时关闭？
- 原型改完后是否需要再次评审？
AI 把原型成本降下来后，评审方式也要改变
传统原型制作周期较长，团队容易把第一次完整稿当成“接近定稿”。AI 可以快速产生多个可交互版本后，更适合采用短循环：先做关键流程，尽快评审，确认方向后再扩展。
速度提升不意味着减少沟通，反而应该增加低成本沟通次数。以前两周才能看一次原型，现在一小时可以看到初版，就应该把分歧更早暴露。
敢于提问是一项职场能力
第二轮沟通实验改善的关键不是描述者突然更专业，而是接收者获得了提问权。
从学校进入企业后，很多新人担心提问暴露自己“不懂”，于是带着猜测继续做。真正危险的不是暂时不懂，而是没有澄清就投入大量开发。
高质量问题通常很具体：
- “订单提交后是立即扣库存，还是商家确认后再扣？”
- “账号重复时保留用户已经填写的其他字段吗？”
- “这个页面第一版只服务手机，还是需要同时支持电脑？”
问题越靠近流程、状态和边界，越能减少后续返工。
一次有效原型评审的产物
评审结束后，至少应该留下：
- 已确认的主流程和页面范围。
- 需要调整的交互和视觉问题。
- 尚未解决的业务决策及负责人。
- 本期明确不做的内容。
- 下一版原型的验收标准。
如果会议结束只有一句“整体不错，再优化一下”，说明原型还没有真正进入决策流程。
讲师判断：一次好的原型评审必须产生决定
评审不是把页面从头讲一遍，而是围绕尚未确定的问题做选择。我会在会议前把争议点写成问题，例如“缺货后允许继续下单还是阻止提交”“教师审批是逐条处理还是批量处理”，并要求参会者在原型上完成对应动作。这样反馈才能落到流程和规则，而不是停留在个人审美。
会议结束时，每条反馈都要归入四类：接受并修改、拒绝并说明理由、需要补充信息、留到后续版本。没有归类和负责人，就没有真正完成对齐。原型之所以成本低，正是因为它允许我们在代码和数据迁移之前把这些决定做出来。
如果不同角色意见冲突，不要让页面设计师替业务做决定。回到用户目标、风险和数据，明确最终拍板人，并把选择记录到需求中。下一次评审只验证这项决定是否被正确呈现，避免同一个问题反复讨论。
课后练习
找三位没有参与需求讨论的人体验你的原型，不做讲解，只观察他们如何完成指定任务。记录卡住、误解和主动提问的位置，再判断问题来自页面表达、业务规则还是需求本身。