先带着真实业务问题沟通
准备原型前，可以用一两个日常场景说明谁在什么情况下需要完成什么工作，以及目前卡在哪里。已有表格或纸质单据可以帮助理解字段，但需要去除不必要的敏感信息。产品经理据此整理功能与角色，不要求客户一开始就写出完整技术文档。讨论越贴近真实操作，原型越容易暴露需求中的缺口。
按一条完整流程检查
评审时从入口开始，依次看创建、提交、审核、处理与查询，确认每一步由谁执行以及需要看到哪些信息。不要只挑几个好看的页面讨论，缺少状态和异常的原型容易在开发时出现大量补充需求。可以使用示例数据走一遍流程，把不符合实际的地方当场记录，再明确修改后的预期结果。
把正常路径和异常一起说明
退回、撤销、权限不足、内容为空和重复提交都值得在原型阶段确认。原型不必实现真实接口，却应表达关键反馈，让使用者知道系统会怎样回应。对尚未决定的规则，标记待确认事项与负责人，不要把默认演示效果当作双方已经同意的业务逻辑。这样正式报价与开发范围才有清楚依据。
确认方案后再评估实施
友软提供一对一产品经理需求沟通，并免费提供项目方案与原型。客户对方案和原型满意后，再讨论正式开发的范围、周期与费用。评审结论可以整理为功能清单、流程说明和仍待确认的问题，作为后续协作基础。免费原型帮助双方先看清产品方向，正式开发与交付内容则以双方确认的约定为准。
方案落地前需要确认
本文以“免费原型评审怎么做”为主题讨论功能设计，属于方案指南，不代表某个客户项目的实际交付承诺。具体实施前，应由业务负责人确认适用规则、使用角色、现有系统接口和验收方式，再通过原型验证关键操作。对于暂时不能确定的条件，保留待确认清单，在范围明确后评估开发周期与费用，避免将示例直接套用于不同企业。