1. 问题陈述

当前羽毛球系统以「个人发布比赛 + 个人用户报名」为核心模式，本质上是单向的——个人负责组织一切，个人用户被动参与。这种模式存在三个明显瓶颈：

1. 组织能力天花板：无法覆盖所有地域、所有层次的羽毛球活动需求，尤其是本地化、常态化的组局找搭子场景。
2. 缺乏社群载体：羽毛球天然是高社交属性的运动，用户有归属感诉求，目前系统无法承载「俱乐部」这一社群形态。
3. 商业变现单一：平台仅靠比赛报名费变现，缺乏 B2B2C（平台→俱乐部→用户）的多层商业模型。

引入「俱乐部」功能，本质上是将平台从一个「活动发布工具」升级为一个「羽毛球社群平台」——让有资源、有意愿的组织者（场馆方、教练、资深球友）成为平台的合作伙伴，由他们来服务和运营本地球友社群。

2. 目标

用户目标

业务目标

3. 非目标

4. 功能模块与用户故事

模块A：俱乐部注册与生命周期

A1. 注册申请流程

用户故事：

• 作为场馆方/组织者，我想要在前端提交俱乐部注册申请（填写名称、上传营业执照、选择所在城市/场馆位置、缴纳年费），以便成为平台的正式俱乐部合作伙伴。
• 作为平台管理员，我想要在后台审核俱乐部注册申请（查看资料、通过/驳回并附原因），以便确保平台上俱乐部的资质真实可靠。
• 作为申请者，我希望能看到申请的审核进度，以便了解当前状态。

需求规格：

【P0】注册申请入口

• 前端新增「创建俱乐部」入口，位于个人中心或首页显眼位置
• 注册流程分步表单（参考公众号注册体验），步骤建议如下：

步骤1：选择主体类型
  → 仅开放「企业/机构」注册（不开放个人注册）

步骤2：填写基本信息
  → 俱乐部名称（2-20字，需唯一性校验）
  → 俱乐部简介（选填，≤200字）
  → 所在城市（省-市-区 三级联动选择器）
  → 俱乐部详细地址（选填）
  → 联系人姓名、手机号（自动读取当前用户信息，可修改）

步骤3：上传资质文件
  → 营业执照（必填，支持 jpg/png/pdf，≤10MB）
  → 场馆照片（选填，最多5张，但建议设为强烈推荐的"选填"）
  → 其他资质证明（选填，如体育经营许可证等）

步骤4：阅读协议并缴费
  → 展示《俱乐部入驻协议》
  → 勾选「我已阅读并同意」
  → 支付年审费用
  → 拉起支付（微信支付）

步骤5：提交成功
  → 提示「申请已提交，预计 3 个工作日内完成审核」
  → 显示审核状态入口

【P0】后台审核系统

• 后台新增「俱乐部审核」菜单
• 列表展示：俱乐部名称、申请人、主体类型、提交时间、审核状态
• 审核操作：
  • 通过：俱乐部状态变为「正常运营」，自动生成俱乐部主页，通知申请人
  • 驳回：必须填写驳回原因（预设模板 + 自定义），允许申请人修改后重新提交
• 审核记录留痕（谁、何时、什么操作、原因）

【P0】年审机制

• 俱乐部注册通过后，有效期 = 1 年
• 到期前 30 天，系统向俱乐部管理员发送续费提醒（小程序订阅提醒 + 短信）
• 到期前 7 天、3 天、1 天，递增提醒频次
• 到期后未续费：
  • 俱乐部状态变为「已冻结」
  • 所有功能停止,俱乐部在前端隐藏不可查看,从之前的前端页面进入该俱乐部提示:俱乐部状态异常

验收标准：

• [ ] Given 用户点击「创建俱乐部」，When 进入注册流程，Then 展示分步表单
• [ ] Given 用户填写完步骤2点击下一步，When 俱乐部名称已被占用，Then 提示「该名称已被使用，请更换」
• [ ] Given 用户完成支付，When 提交成功，Then 生成审核记录，状态为「待审核」
• [ ] Given 管理员通过审核，When 操作完成，Then 俱乐部状态变为「正常运营」，申请人收到通知
• [ ] Given 管理员驳回申请，When 填写驳回原因后提交，Then 申请人可查看原因并重新提交
• [ ] Given 俱乐部到期未续费，Then 状态变为「已冻结」

模块B：俱乐部信息与管理

B1. 俱乐部信息编辑

用户故事：

• 作为俱乐部管理员，我想要编辑俱乐部的基本信息（名称、简介、封面图、轮播图等），以便向用户展示俱乐部的特色。
• 作为俱乐部管理员，我想要设置俱乐部的运营规则（是否开放加入、加入是否收费、非会员能否报名比赛、会员参赛折扣、是否开启俱乐部分销等），以便灵活管理俱乐部。

需求规格：

【P0】俱乐部设置页

• 前端：俱乐部管理员进入「俱乐部管理」→「俱乐部设置」
• 可编辑项：

【P0】运营规则设置

【P1】俱乐部名称修改审核

• 若管理员修改俱乐部名称，提交后进入审核队列
• 审核通过前，旧名称继续使用

B2. 子管理员体系

用户故事：

• 作为俱乐部管理员，我想要设置子管理员并分配权限，以便分担日常管理压力。
• 作为子管理员，我只管理自己发布的比赛，不能管理或删除其他管理员的比赛。

需求规格：

【P0】子管理员设置

• 管理员在「俱乐部管理」→「管理员设置」中操作：
  • 添加子管理员：输入手机号，系统校验该手机号是否已注册平台账号
  • 子管理员必须完成手机号绑定 + 实名认证方可生效
  • 管理员可随时移除子管理员

【P0】子管理员额度

• 俱乐部默认可免费设置 5 个子管理员
• 子管理员额度与会员上限相互独立，不绑定：
  • 如需增加子管理员额度，需单独购买
• 子管理员额度为永久购买，非年付
• 额度阶梯（建议档位，具体价格待定）：

• 当前子管理员数量达到额度上限时，管理员无法添加新子管理员，前端提示「子管理员数量已达上限（X/Y），如需增加请单独购买子管理员额度」

【P0】权限边界

B3. 会员管理

【P0】会员移除规则

俱乐部管理员可以移除会员，但有严格限制：

• 前端会员列表需区分展示：
  • 免费会员：显示「移除」按钮
  • 付费会员：灰显「不可移除」标识，hover 显示原因（如「永久会员」/「会员有效期至 2027-03-15，到期后自动移除」）
• 移除操作需二次确认弹窗
• 仅俱乐部管理员有此权限，子管理员无权移除会员

【P0】管理员不可主动添加会员

• 俱乐部管理员/子管理员不能主动将用户添加为俱乐部会员
• 会员加入的唯一路径：用户自行申请 → 按俱乐部加入规则（审核/付费）完成加入

【P0】多俱乐部归属

• 平台允许用户同时加入多个俱乐部
• 用户在每个俱乐部的会员身份独立管理（费用独立、权益独立）
• 前端「我的俱乐部」展示所有已加入的俱乐部列表

【P0】会员归属规则

每个会员在俱乐部内归属到一个管理者名下，用于明确服务关系与售后责任。

【P0】会员归属转移

• 俱乐部管理员可以将会员的归属转移给任意子管理员，或收回至自己名下
• 子管理员之间不能互相转移会员，转移必须由俱乐部管理员操作
• 转移会员归属时，若该会员存在未完结的售后申请，禁止转移（详见模块D）

【P0】会员归属查看页面

• 子管理员：可查看「自己名下用户」列表
• 俱乐部管理员：可查看所有子管理员列表，以及每个子管理员名下所有用户的列表
• 俱乐部管理员也可查看自己名下用户列表

B4. 俱乐部人员上限与扩容

用户故事：

• 作为平台运营方，我想要设置俱乐部的默认会员上限并通过扩容变现，以便在俱乐部规模增长时获得持续收入。

需求规格：

【P0】基础上限

• 每个俱乐部默认最大会员数：500 人
• 会员数 = 所有状态为「正常」的会员（不含已退出/已移除/免费被移除/年费到期自动移除）
• 达到上限后，新用户无法申请加入，前端提示「该俱乐部已满员」

【P1】付费扩容

• 扩容方案参考企业微信模式：

  • 管理员在「俱乐部设置」→「会员上限」中发起扩容
  • 扩容阶梯（建议档位，具体价格待定）：

  扩容至	费用
  1000人	¥X/永久
  2000人	¥Y/永久
  5000人	¥Z/永久
  自定义	按每人 ¥N 计算

  • 扩容为永久购买，非年付
  • 续费年审时，仅需支付年审费用即可，无需再次支付扩容费

B5. 俱乐部分销

用户故事：

• 作为俱乐部管理员，我想要开启分销并设置比例，激励子管理员积极发布活动。
• 作为子管理员，我发布活动可获得报名费抽佣，以便获得实际收益。

需求规格：

【P0】分销开关与比例设置

• 俱乐部设置中新增「分销」开关（默认关闭）
• 开启后可设置一级分销比例（按报名费金额的百分比或固定金额，如 10%，范围 0-100%，或者 1¥）

【P0】分销生效范围

• 分销仅对子管理员生效，对俱乐部管理员无效
• 子管理员发布组局/比赛，用户付费报名时，子管理员按比例获得抽佣

【P0】资金归属规则

【P0】分销关闭的影响

• 分销关闭或未设置比例时，子管理员发布的活动报名费全部计入俱乐部管理员余额，子管理员无抽佣

模块C：俱乐部比赛与组局

注：比赛和组局均不绑定具体场地，场地信息由发布者在活动描述中自行填写

C1. 比赛列表整合方案

用户故事：

• 作为普通用户，我想要在比赛列表中看到所有可参加的比赛（无论是平台发布还是俱乐部发布），以便不遗漏任何感兴趣的活动。
• 作为俱乐部会员，我想要能筛选只看本俱乐部的比赛，以便快速找到内部活动。

需求规格：

【P0】比赛列表重构

• 总比赛列表合并展示：平台比赛 + 俱乐部公开比赛（混合排列，按时间倒序）
• 新增筛选条件：
  • 「只看俱乐部比赛」
  • 「只看个人比赛」
  • 「只看本俱乐部比赛」（仅对有俱乐部归属的用户可见）
  • 若用户属于多个俱乐部：选中后弹出俱乐部选择下拉框，选择具体俱乐部后筛选
  • 若用户属于单个俱乐部：直接筛选该俱乐部的比赛

方案选择：采用「混合排列 + 筛选项」方案（而非「俱乐部置顶」方案），原因：

• 置顶方案对个人发布者不公平，会降低个人用户发比赛积极性
• 混合排列 + 筛选兼顾了公平性和可发现性
• 后续可根据数据调整排序权重（如俱乐部比赛获得少量加权但不置顶）

【P1】俱乐部比赛标识

• 俱乐部比赛在列表中展示俱乐部 Logo/名称
• 「俱乐部认证」标识，提升可信度

C2. 俱乐部内部比赛

用户故事：

• 作为俱乐部管理员，我想要发布仅限本俱乐部会员参加的比赛，以便组织内部活动。
• 作为俱乐部会员，我想要在俱乐部主页看到所有内部比赛，以便不错过俱乐部专属活动。

需求规格：

【P0】内部比赛发布

• 管理员/子管理员在「俱乐部管理」→「发布比赛」中操作
• 新增比赛发布选项：「是否允许非会员报名」
  • 不允许（默认）：比赛仅展示在俱乐部内部比赛列表，不在总列表中显示
  • 允许：比赛同时展示在俱乐部内部列表和总比赛列表
• 该选项的可用性受俱乐部运营设置中「非会员能否报名俱乐部比赛」开关控制

【P0】俱乐部内部比赛列表

• 俱乐部详情页新增「赛事」Tab
• 展示该俱乐部所有比赛（含内部和公开），按时间排列
• 非会员访问时，仅展示公开比赛

【P0】会员专属折扣

• 若管理员设置了会员折扣（如 8 折），报名费自动计算：
  • 会员：原价 × 折扣
  • 非会员：原价
• 前端报名页清晰展示原价和折后价

C3. 踢人与代报名（争议功能）

详细分析见第 5 节「争议问题」

C4. 比赛管理规则

【P0】发布后不可编辑

• 俱乐部发布的比赛一旦发布成功，不可再次编辑
• 管理员/子管理员只能做删除操作
• 删除限制（沿用系统现有规则）：
  • 只有无任何用户报名的比赛可以删除
  • 或比赛已经结束后可以删除
  • 有活跃报名的比赛禁止删除，前端提示「该比赛已有 X 人报名，无法删除」
• 如果发现比赛信息有误，只能删除后重新发布

模块D：退款与售后体系

D1. 现状分析

现有系统的退款逻辑分散在多个场景中：

现有问题：

• 售后审核全部压在平台运营方，效率低、不灵活
• 俱乐部模式下，俱乐部管理员更了解实际参与情况，但没有审核权
• 缺少会员费退款通道

D2. 新流程设计

核心变化：审核权从「平台运营方」下放到「俱乐部管理员/子管理员」，平台退居仲裁角色。

新流程：
用户提交退款资料 → 俱乐部管理员/子管理员审核
  ├── 同意 → 系统自动退款（原路返回）
  └── 拒绝 → 显示拒绝原因 +「平台介入」按钮
                └── 平台运营方仲裁 → 判同意/判驳回（终局）

权限隔离：

• 俱乐部管理员：可查看并审核本俱乐部所有退款申请
• 子管理员：仅可查看并审核自己发布的活动产生的退款申请
• 会员费退款：仅俱乐部管理员可审核，子管理员无权

D3. 退款类型与权限矩阵

D4. 退款状态机

                   退款申请状态流转

   ┌─────────┐   用户提交申请    ┌──────────┐
   │ 无申请   │ ─────────────→  │ 待审核    │
   └─────────┘                └──────────┘
                                   │
                    ┌──────────────┼──────────────┐
                    │              │              │
                管理员同意      管理员拒绝    超时未处理
                    │              │         (超过72h)
                    ▼              ▼              │
              ┌──────────┐  ┌──────────┐         │
              │ 已同意    │  │ 已拒绝    │ ←──────┘
              │ 待退款    │  └──────────┘
              └──────────┘        │
                    │          用户点击
                系统自动        「平台介入」
                执行退款           │
                    │              ▼
                    ▼        ┌──────────┐
              ┌──────────┐  │ 平台仲裁中 │
              │ 已退款    │  └──────────┘
              │ (终态)    │        │
              └──────────┘   ┌────┴────┐
                             │         │
                         平台判同意  平台判驳回
                             │         │
                             ▼         ▼
                       ┌──────────┐ ┌──────────┐
                       │ 已退款    │ │ 平台驳回  │
                       │ (终态)    │ │ (终态)    │
                       └──────────┘ └──────────┘

   ┌──────────┐   用户主动撤销     ┌──────────┐
   │ 待审核    │ ───────────────→  │ 已撤销    │
   └──────────┘  (管理员处理前)    │ (终态)    │
                                  └──────────┘

状态说明：

D5. 关键业务规则

D6. 会员费退款特殊规则

用户故事：

• 作为已付费加入俱乐部的用户，我想要申请退还会员费，以便在不满意时挽回损失。

需求规格：

【P0】会员费退款冷静期设计

【P0】权益清算

• 若用户在会员期间已享受会员参赛折扣（如比赛报名打折），退款时需扣除已享受的折扣差价
• 计算逻辑：实际退款 = 按比例应退金额 - SUM(各比赛原价与折后价的差额)
• 若差价超过应退金额，退款额为 0（不追索）

【P0】退款后处理

• 会员费退款成功后，系统自动将该用户从俱乐部移除
• 清除会员身份及所有相关权益
• 该用户可重新申请加入俱乐部（重新走付费/审核流程）

【P0】审核权限

• 会员费退款申请仅俱乐部管理员可审核
• 子管理员无权限查看或审核会员费退款

D7. 售后通知与归属转移限制

用户故事：

• 作为提交售后的会员，我希望能及时通知到负责审核的人。
• 作为俱乐部管理者，我希望售后通知精准触达，避免无关人员被打扰。

需求规格：

【P0】售后通知范围

• 会员提交售后申请时，通过小程序订阅提醒通知（平台暂未对接短信）：
  • 俱乐部管理员
  • 该会员当前归属的子管理员（若归属在俱乐部管理员名下，则仅通知俱乐部管理员）
• 不通知所有子管理员，原因：
  • 子管理员只负责自己名下会员的售后，广播通知会造成信息过载与越权
  • 避免无关子管理员看到不属于自己名下会员的售后信息

技术说明：小程序订阅提醒为一次性订阅，需被通知者预先授权。建议在俱乐部管理员/子管理员开通权限时，引导其订阅「售后审核提醒」类消息模板。

【P0】归属转移限制

• 会员存在未完结（非终态）的售后申请时，禁止转移该会员的归属
• 售后处理完毕（已退款 / 平台驳回 / 已撤销等终态）后，才允许转移
• 俱乐部管理员转移归属时前端校验并拦截，提示「该会员尚有未处理完的售后，需处理完毕后方可转移」

设计说明：售后审核责任人与会员归属强绑定。若在售后未完结时转移归属，会导致「谁该继续处理这笔售后」的责任不清。因此采用「未完结售后 → 禁止转移归属」这一最简单明确的方案。

5. 争议问题分析与方案建议

问题1：踢人与代报名

现状：当前系统不支持「管理员踢人」和「代其他用户报名」功能。

分析：

踢人和代报名在免费场景下没有争议。争议集中在收费场景：

方案：

踢人（收费场景）：

• 管理员发起「移出比赛」请求，需填写理由
• 系统通知被踢用户：「你将被移出比赛 X，费用将自动退回，是否同意」
• 被踢用户确认，系统自动退款（原路返回）
• 平台不抽取退款订单佣金
• 被踢用户拒绝 → 移除失败

代报名（收费场景）：

• 改为「邀请报名」模式：
  1. 管理员选择会员 → 发起参赛邀请
  2. 会员收到通知 → 进入报名页确认
  3. 会员自行完成支付
• 不做管理员直接代付，原因：
  • 支付归属不清晰（退款退给谁？）
  • 存在纠纷风险
  • 支付合规风险

问题2：个人注册 vs 企业注册

分析：

推荐方案：

• 仅开放「企业/机构」注册，要求提供营业执照
• 未来可考虑的个人场景：「召集人」角色（轻量版俱乐部），仅支持组局找搭子

6. 开放问题

文档状态：待评审 |