需求确认不是走形式，是给项目上保险
很多企业做电商网站，习惯把精力全压在视觉设计和功能开发上，觉得“需求文档写过了，开会也确认过了，剩下就看程序员怎么实现”。结果往往是在测试阶段甚至上线后，才发现支付回调对不上、会员等级算错价、库存超卖、订单状态混乱——这些问题返工成本极高，而且特别伤用户信任。
实际上，电商开发最贵的环节不是写代码，而是改需求。与其上线后焦头烂额，不如在开发前把下面这5个细节掰开揉碎确认清楚。每一条都来自真实项目中的“翻车现场”，值得你花10分钟对照自查。
1. 商品规格与SKU的边界，必须具体到“不可再拆”
很多需求文档只写“商品支持多规格”，但真正开发时，团队会反复问你：颜色和尺码是平级规格还是父子规格？同一款T恤，红色M码和蓝色L码，是同一个SKU下的不同组合，还是两个独立SKU？如果用户买了红色M码，库存扣减是按组合扣，还是分别扣颜色库存和尺码库存？
建议确认动作：拿3个真实商品（比如一件衣服、一个手机壳、一套组合礼盒），在文档里画出它们的规格层级、SKU编码规则、库存扣减逻辑、价格是否随规格变化。特别要注意“预售款”和“现货款”混卖时，库存如何隔离。如果连示例商品都画不清楚，开发出来的后台管理页面大概率也是一团乱麻。
2. 订单状态机：谁在什么条件下能改状态
订单不是只有“待付款、已付款、已发货、已完成”这么简单。实际业务中会有：用户申请退款、客服改地址、仓库拦截发货、风控冻结订单、超时自动取消……每个动作都会触发状态流转。
最容易出问题的是两个节点：一是“支付成功但库存扣减失败”，系统该给用户退款还是自动重试？二是“用户发起退款后，仓库已经打包”，这时候是允许拦截还是强制发货？这些问题如果不提前定义清楚，开发会按自己理解写逻辑，上线后客服每天要手动改订单状态，效率极低。
建议确认动作：画一张订单状态流转图，标注每个状态变更的触发条件（用户操作/系统自动/客服手动）、操作角色权限、是否发送通知。重点检查异常分支，比如支付超时、库存不足、地址无效。
3. 促销规则叠加顺序，写错一个就全盘亏损
满减、折扣券、会员价、新人专享价、限时秒杀——单独看都简单，但叠加起来就是数学题。比如一件商品原价200元，参与满300减50，同时用户有一张9折券，会员本身享受95折。请问最终支付金额是多少？是先算满减再打折，还是先打折再满减？优惠券是否参与满减门槛计算？
更隐蔽的是“赠品”逻辑：满赠活动是每个订单送一份，还是每个SKU送一份？如果用户拆分订单，赠品怎么算？如果用户退货导致不满足满赠条件，赠品金额如何扣除？
建议确认动作：整理一份“促销优先级规则表”，明确所有活动的计算顺序、互斥关系、是否允许叠加。用至少10组不同价格、不同优惠券组合的数据做手工测算，让开发按这个结果写代码。别嫌麻烦，这一步能省下后期大量对账工作。
4. 售后流程的“边界条件”比主流程更重要
大多数需求文档会写“支持7天无理由退货”，但不会写清楚：用户签收后第8天申请退货，系统是直接拒绝还是转人工？生鲜商品和定制商品是否在详情页明确标注不支持退货？如果用户退货时少了一件赠品，退款金额怎么扣？退款原路返回，但用户支付时用了优惠券，优惠券是否退回？退回后有效期怎么算？
这些边界条件如果不在开发前确认，上线后客服只能靠“手工备注+线下转账”来处理，不仅效率低，还容易产生财务漏洞。
建议确认动作：列出至少15种售后场景（质量问题、七天无理由、错发漏发、拒收、部分退货、换货、维修），逐一确认每个场景的审核流程、退款金额计算方式、物流费用承担方、系统自动化程度（是全自动还是半自动）。
5. 数据埋点与后台报表，别等上线后才发现“看不到数据”
很多企业上线电商网站后，最常问的一句话是：“为什么后台看不到转化率？为什么不知道哪个渠道带来的订单多？”原因很简单——开发前没定义清楚数据指标和埋点需求。
你需要确认的不只是“有订单列表”，而是：订单来源渠道（自然搜索/付费广告/社交媒体/直接访问）如何追踪？用户从浏览商品到提交订单，每一步的流失率怎么算？不同商品类目的GMV、退款率、毛利怎么统计？这些数据是实时更新还是T+1？
建议确认动作：在开发前，明确列出10个你最关心的核心指标（比如UV、加购率、支付转化率、客单价、复购率），并让开发确认这些指标的数据来源、计算口径、报表展示形式。如果预算允许，最好在开发阶段就接入第三方数据分析工具，而不是自研报表。
最后说两句实在话
以上5个细节，看起来琐碎，但每一个都对应着真实项目中的返工血泪。电商开发是一个高度依赖逻辑严谨性的工程，需求确认阶段的“差不多”，到了上线就是“差很多”。
如果你正在筹备电商网站，不妨把这份清单打印出来，和你的产品经理、开发负责人、运营同事坐在一起，逐条过一遍。哪怕多花两天时间，也比上线后每天处理客诉和改代码要划算得多。记住：需求文档写得越细，开发报价越准，上线后扯皮越少。