| ||||||||||||||||||||||||||||||||||||
一、核心原则（一句话记住） 原型不是画界面，是把需求 “可视化”。 需求写什么，原型就画什么；原型画什么，开发就做什么。 二、确保电商系统原型准确反映需求的 8 个落地方法 1. 原型必须和需求文档一一对应、可追溯 每个页面、每个按钮、每个弹窗，都要对应需求里的某一条。 原型上标注： 模块 功能点 需求 ID（可选但非常有用） 禁止出现： 需求里没有的按钮 没定义的字段 没说明的弹窗 这样原型不会凭空加东西。
2. 先画「业务流程图」，再画「页面原型」 电商系统开发最容易错的就是流程： 订单、支付、退款、优惠券、拼团、分销、售后。 流程图 = 骨架 原型 = 皮肉 没有流程图直接画原型，100% 跑偏。 必须画： 正常流程 异常流程（失败、取消、超时、关闭） 边界场景（库存不足、余额不足、权限不足） 3. 原型必须包含「所有状态」，不能只画正常态 电商页面一定有多状态，缺一个就会出问题： 例如订单列表： 待支付 已支付 已发货 已完成 已关闭 退款中 / 已退款 例如商品详情： 有库存 无库存 已下架 活动中 状态不画全 = 需求不完整 = 开发瞎做。
4. 所有交互必须明确：点了去哪、出什么、失败怎么办 原型里必须写清楚交互规则，不能只画框框： 点击按钮 → 跳转到哪？ 提交成功 → 提示什么？ 提交失败 → 提示什么？ 表单不填 → 能不能提交？ 列表无数据 → 显示空状态吗？ 示例标准写法： 点击【支付】→ 调用支付接口 → 成功→跳转订单成功页；失败→toast 提示 “支付失败”，留在当前页。 交互不明确 → 原型无效。 5. 字段、名称、状态、术语必须和需求完全一致 这是最容易出歧义的地方： 需求写：订单号 原型不能写：订单 ID、单据号、定单编号 需求写：待支付 原型不能写：未付款、待付款 需求写：优惠券 原型不能写：代金券、抵扣券 术语统一 = 原型准确的基础。
6. 必须做「原型 + 需求」联合评审 参加人必须齐全： 业务方 产品 / 需求 前端 后端 测试 评审只确认 3 件事： 原型是否完全覆盖需求 原型是否有歧义、缺失、多余 流程是否能跑通、无逻辑错误 任何一个人看不懂 → 原型不合格。 7. 建立「原型自检清单」，不符合不让过 提交前必须检查： 是否和需求文档一一对应 是否有流程图 是否包含所有状态 是否所有按钮都有交互说明 术语、字段是否统一 是否有异常 / 边界场景 是否明确权限（谁能看、谁能点） 是否和现有系统风格兼容（二次开发重点） 缺一项，打回重画。
8. 电商系统开发原型定稿后必须锁定、版本化、可回溯 每次修改都升版本：V1.0 → V1.1 记录修改人、修改时间、修改原因 不允许私下改原型、不更新文档 原型一旦确认 = 视觉需求基线。 三、电商最容易不准的 6 个原型点（重点盯） 订单状态流转（漏状态 = 灾难） 支付 / 退款流程（少一步就资损） 优惠券规则展示（用户理解错会投诉） 库存显示与扣减（超卖必赔） 后台列表查询条件（运营无法工作） 权限控制（谁能看、谁能改） 这些地方原型准确，整个项目就稳了。
四、最简单最强总结（可直接当制度） 确保原型准确反映需求，就 4 条： 先流程图，后原型 需求写什么，原型画什么 状态、交互、术语必须完整统一 必须联合评审 + 版本锁定 做到这 4 条，原型永远不会偏离需求。 | ||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
|
