| ||||||||||||||||
一、需求文档里必须明确分销系统关系的 6 个核心点 只要把下面 6 点写清楚，分销关系就 100% 无歧义： 谁能成为分销员（准入条件） 如何建立上下级关系（邀请 / 绑定机制） 关系生效时间与有效期（永久 / 限时） 关系变更 / 解绑规则（改上级、解绑、冻结） 关系边界（自购、跨店、多店铺、多层级） 异常场景处理（退款、取消、拉黑）
二、需求文档标准写法（可直接复制） 1. 分销员准入规则 必须明确： 必须是商城注册用户 是否需要审核 是否需要消费满 X 元才能成为分销员 是否允许企业 / 团队成为分销员 示例： 分销员必须为商城已注册用户，无需消费，申请后自动审核通过。 2. 上下级绑定方式（最关键） 必须明确： 通过邀请码 通过分享链接 / 海报 通过扫码 手动后台分配 示例： 用户 A 通过分享链接 / 邀请码 / 二维码邀请用户 B 注册， 注册成功后，自动绑定上下级关系：A 为上级，B 为下级。
3. 绑定生效时机 注册时立即绑定？ 首次下单后绑定？ 支付后绑定？ 示例： 下级用户完成注册时，上下级关系立即生效。 4. 关系有效期 永久有效 有效期 X 天 / X 月 超过有效期自动解除 示例： 上下级关系永久有效，除非用户主动解绑或被系统拉黑。 5. 层级数量（必须写死） 一级分销 二级分销 三级分销 严禁写 “多级”。 示例： 本系统采用二级分销关系： 一级：直接邀请人 二级：邀请人的上级
6. 自购是否产生关系 / 佣金 自购是否算业绩 自购是否给自己佣金 自己邀请自己是否有效 示例： 用户自购： 可获得佣金 不产生新的分销关系 7. 关系变更规则 是否允许修改上级 修改后历史订单归属谁 后台是否可强制调整 示例： 上下级关系不允许用户自行修改， 仅后台管理员可强制变更，变更后新订单按新关系结算。
8. 解绑 / 拉黑规则 用户主动解绑 违规自动解绑 解绑后历史佣金是否清空 示例： 分销员被拉黑后： 立即解除所有下级关系 未结算佣金冻结 不再产生新佣金 9. 特殊场景边界（必须写） 下级未注册 → 注册后是否追溯上级 跨店铺、多门店是否互通关系 一个用户能否有多个上级 示例： 一个用户只能有一个上级， 未注册用户点击链接，注册后自动追溯绑定。 三、需求文档必须配一张图：分销系统关系流程图 必须画清楚： 分享 → 注册 → 绑定 → 生效 解绑 → 冻结 → 变更 没有流程图 = 关系不明确。
四、最简单判断标准（直接用） 如果开发、测试看完你的描述， 不需要再问你一句， 那就是明确了。 五、终极总结（可写进规范） 在需求文档中明确分销系统关系，只要写清： 谁邀请谁、怎么绑、何时生效、几级、有效期多久、能否改、如何解、边界是什么。 做到这些，分销关系永远不会乱、不会错、不会扯皮。 | ||||||||||||||||
|
||||||||||||||||
| ||||||||||||||||
|
