rlz/docs/多角色系统与分润方案.md

瑞来健康 — 多角色系统与分润方案

撰写日期：2026-06-07 基于现有四端架构（Spring Boot 后端 / Vue2 管理后台 / Android 陪护端 / 微信小程序患者端） 回答核心问题：是否应该在现有 B-C 两角色之外引入多角色体系？如果可行，怎么做？

---

一、可行性判断

1.1 结论：可行，且商业价值高

维度	评估	说明
技术可行性	高	RuoYi 框架自带 RBAC（角色-菜单-权限），sys_role / sys_user_role 表已就绪，userType 字段已区分 B/C/00
业务可行性	高	陪诊 O2O 天然涉及多方协作——接单、派单、客服、推广都需要不同的人
市场价值	高	多角色分润是平台规模化运营的前提——一个人做所有事无法复制，角色分工才能扩张
风险可控性	中	分润计算逻辑复杂，需严谨的财务对账机制，但属于工程问题，非根本障碍

1.2 为什么现在做合适

当前系统只有两角色（患者C / 陪护B / 管理员00），这导致了几个瓶颈：

1. 陪护员既要接单又要拉客 — 没有推广角色，平台流量全靠自然增长
2. 管理员要处理所有纠纷和派单 — 没有客服和调度角色，管理员瓶颈明显
3. 没有激励层 — 陪护员拿固定服务费，没有推广动力；推广人员没有变现路径
4. 无法规模化 — 每个城市都需要一套运营班子，但当前架构不支持

多角色分润体系是平台从"工具"升级为"平台"的核心一步。

---

二、角色体系设计

2.1 七角色全景

                         ┌─────────────┐
                         │   超级管理员  │  (sys admin, userType=00)
                         │   platform   │
                         └──────┬──────┘
                                │
        ┌───────────────────────┼───────────────────────┐
        │                       │                       │
   ┌────▼─────┐          ┌──────▼──────┐          ┌─────▼────┐
   │  运营经理  │          │  财务主管    │          │ 城市合伙人 │
   │operations │          │  finance    │          │  partner  │
   └────┬─────┘          └──────┬──────┘          └─────┬────┘
        │                       │                       │
   ┌────▼─────┐          ┌──────▼──────┐          ┌─────▼────┐
   │  客服专员  │          │  调度员      │          │ 推广员    │
   │  service  │          │dispatcher   │          │ promoter  │
   └──────────┘          └─────────────┘          └─────┬────┘
                                                        │
                        ┌───────────────────────────────┘
                        │
                  ┌─────▼─────┐
                  │  陪诊师    │  (existing, userType=B)
                  │ caregiver  │
                  └───────────┘

2.2 角色详细定义

角色 1：超级管理员 (platform_admin) — 已有

属性	说明
userType	00
职责	系统配置、角色分配、财务审批、全局数据查看
分润	无（拿固定工资或平台利润分红，不走系统分润）
终端	Web 管理后台
权限范围	全部菜单、全部数据

角色 2：运营经理 (operations_manager)

属性	说明
userType	03
职责	管理某个城市/区域的运营，统管调度员和客服，查看区域数据报表
分润	区域流水的 1%~3%（按区域全部订单金额计提）
终端	Web 管理后台（受限菜单） + Android App + 小程序
权限范围	所属区域的订单、用户、医院数据

角色 3：客服专员 (service_agent)

属性	说明
userType	04
职责	处理用户投诉、退款审核、纠纷调解、订单异常处理
分润	固定工资 + 处理工单提成（每处理一单 N 元，或按月考核）
终端	Web 管理后台（订单/退款模块） + Android App + 小程序
权限范围	订单管理（查看+退款审核）、用户管理（查看）

角色 4：调度员 (dispatcher)

属性	说明
userType	05
职责	手动分配订单给陪诊师（当系统自动派单失败时）、优化陪诊师排班、处理紧急调度
分润	每成功调度一单抽取 1%~2%（从订单金额中计提）
终端	Web 管理后台（订单+医院+用户） + Android App + 小程序
权限范围	订单管理（指派/改派）、陪护人员管理（区域范围内）、医院管理

角色 5：推广员 / 流量合伙人 (promoter)

属性	说明
userType	06
职责	通过分享链接/二维码/社交媒体引流新用户，推广平台服务
分润	三级分润（见 4.3 节）— 被推广用户消费金额的 5%~15%
终端	小程序推广端（独立 Tab 或页面）
权限范围	查看推广数据（邀请人数、订单数、佣金）、提现

这是平台规模化增长的核心角色。 推广员不参与服务交付，只负责流量获取，通过佣金激励实现病毒式增长。

角色 6：陪诊师 (caregiver) — 已有

属性	说明
userType	B
职责	接单、执行陪诊服务、完成订单
分润	服务费的 80%（平台抽 20%，详见《陪诊员服务费分账方案》）
终端	Android App（完整） + 小程序（轻量）
权限范围	查看自己订单、接单/拒单/开始/完成服务、查看收入、提现
说明	小程序提供轻量入口（接单/完成/收入查看），降低陪诊师使用门槛；Android App 提供完整体验（实时推送、后台服务、支付回调）

角色 7：患者/客户 (customer) — 已有

属性	说明
userType	C
职责	下单、支付、评价
分润	无（消费者）
终端	微信小程序
权限范围	下单、查看自己订单、申请退款、收藏、评价

---

三、角色选择流程

3.1 注册时选择角色

小程序注册流程（改造后）：

授权微信登录
  → 获取微信昵称/头像
  → 填写手机号 + 验证码
  → 【新增】选择身份（三选一）：
      ○ 我需要陪诊服务  → userType = C（患者）
      ○ 我提供陪诊服务  → userType = B（陪诊师，需实名认证）
      ○ 我推广赚佣金    → userType = 06（推广员）
  → 注册完成，进入对应首页

> **注意**：调度员(05)、客服(04)、运营经理(03) 不在注册页开放自选，需由超级管理员在后台分配。
> 注册页只开放三种 C 端身份，保证入口简洁。

管理后台创建用户时（已有用户管理页面改造）：
  → 点击"新增用户"
  → 填写基本信息
  → 【新增】选择角色：管理员/运营经理/客服/调度员/推广员/陪诊师/患者
  → 系统自动分配对应权限

3.2 角色切换

• 同一用户可以拥有多个角色（如陪诊师也可以同时是推广员）
• 小程序底部 Tab 根据角色组合动态展示
• 角色切换入口：我的 → 身份管理 → 切换到 XX 身份

3.3 各角色终端矩阵

角色	管理后台(Web)	小程序	Android App
超级管理员	✅ 全部	❌	❌
运营经理	✅ 受限	✅	✅
客服专员	✅ 受限	✅	✅
调度员	✅ 受限	✅	✅
推广员	❌	✅ 核心	❌
陪诊师	❌	✅ 轻量	✅ 完整
患者	❌	✅	❌

3.4 终端架构决策

微信小程序：同一个小程序，自定义 TabBar + 角色驱动

不新建独立小程序。 所有非管理员角色共用同一个小程序代码库，通过微信自定义 TabBar 根据 userType 动态切换底部导航和首页内容。

理由：

	新建小程序	同一小程序扩展
注册审核	每个独立审核，医疗健康类目门槛高	无需额外审核
认证费用	300元/年 × N个	0
代码维护	N 套或 monorepo	1 套，utils/ 共享
用户切换	小程序间跳转，体验割裂	同一应用内切换身份
推广转化	患者→推广员需跳另一个小程序	自然转化，无跳出

各角色看到的底部 Tab：

患者(C)               陪诊师(B) — 轻量入口     推广员(06)
┌────────────────┐   ┌────────────────┐   ┌────────────────┐
│ 🏠 首页        │   │ 📋 待接单       │   │ 📊 推广数据     │
│ 🛒 服务        │   │ 🔄 进行中       │   │ 👥 我的团队     │
│ 📋 订单        │   │ 📦 已完成       │   │ 💰 我的佣金     │
│ 👤 我的        │   │ 👤 我的        │   │ 👤 我的        │
└────────────────┘   └────────────────┘   └────────────────┘

调度/客服/运营(03/04/05)
┌────────────────┐
│ 📋 待处理       │
│ 📦 全部订单     │
│ 💰 收益明细     │
│ 👤 我的        │
└────────────────┘

文件结构：

coupon/
├── pages/              ← 患者端页面（现有，不动）
├── pages-promoter/     ← 推广端子包（新增）
│   ├── dashboard/      ← 推广数据看板
│   ├── team/           ← 我的团队
│   ├── commission/     ← 佣金明细 + 提现
│   └── share/          ← 分享素材/海报
├── pages-work/         ← 工作台子包（新增，调度+客服+运营共用）
│   ├── dispatch/       ← 调度：待接单 + 指派陪诊师
│   ├── refund/         ← 客服：退款审核列表
│   ├── dashboard/      ← 运营：区域数据看板
│   └── order-manage/   ← 通用：订单搜索/查看
├── custom-tab-bar/     ← 自定义 TabBar（按角色渲染）
└── app.json            ← 注册所有页面 + 子包

Android App：陪诊师→多角色共用

现有 Android App (peizhen) 由一个三 Tab 陪护端（首页/客户/我的）扩展为支持陪诊师/调度/客服/运营四种角色。登录后根据后端返回的 userType 动态加载不同 Fragment 组合。

推广员不适合 Android App — 其核心动作是微信生态内的分享裂变，App 下载门槛反成障碍。

改造点：

改动	说明
MainActivity 动态 Tab	当前写死 3 个固定 Tab（首页/客户/我的），改为根据 userType 组装
角色判断入口	SplashActivity → login → 后端返回 userType → 决定加载哪些 Fragment
调度员界面	待接单列表 + "指派"按钮 + 选择陪诊师弹窗 + 改派（复用现有订单列表 UI）
客服界面	退款审核 Tab + 通过/驳回 + 原因填写（复用现有订单详情 UI）
运营看板	可先用 WebView 加载后台运营页面，快速上线

各角色在 App 中看到的 Tab：

陪诊师(B) — 现有        调度员(05)            客服(04)             运营(03)
┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│ 🏠 首页(接单) │   │ 📋 待派单     │   │ 📋 退款审核   │   │ 📊 运营看板   │
│ 👥 客户(订单) │   │ 📦 全部订单   │   │ 📦 全部订单   │   │ 📦 全部订单   │
│ 👤 我的      │   │ 👤 我的      │   │ 👤 我的      │   │ 👤 我的      │
└──────────────┘   └──────────────┘   └──────────────┘   └──────────────┘

陪诊师说明：Android App 是陪诊师的完整工具（实时推送、后台服务、支付回调），但小程序也提供陪诊师轻量入口（接单/完成/收入查看），降低新陪诊师的注册门槛——无需下载 App 即可开始接单。

---

四、分润模型设计

4.1 分润总体结构

                    订单金额（患者支付 100%）
                         │
          ┌──────────────┼──────────────┐
          │              │              │
     平台抽成          服务费         推广佣金
     (20%)          (待分配)        (5%~15%)
          │              │              │
     平台收入       陪诊师 80%      推广员佣金
                   调度员 1~2%      (从平台抽成中出)
                   运营 1~3%        (从平台抽成中出)

4.2 各角色分润规则

角色	分润来源	比例/金额	结算周期	结算条件
陪诊师	订单服务费	订单金额 × 80%	T+7	订单完成 + 无退款
调度员	订单服务费	订单金额 × 1%~2%	T+7	手动调度的订单 + 完成
运营经理	区域流水	区域月流水 × 1%~3%	月结	区域达标
推广员	平台抽成	被邀请用户消费 × 5%~15%	T+7	订单完成 + 无退款
客服专员	固定+计件	底薪 + 处理工单 × N元	月结	工单关闭
超级管理员	平台利润	非系统分润	—	—

4.3 推广员三级分润（核心增长引擎）

推广员A 直接邀请 → 用户X
用户X 下单 100元 → A 拿一级佣金（5%，即 5元）

用户X 也成为推广员 → 邀请用户Y
用户Y 下单 100元 → X 拿一级佣金（5%，即 5元）
                  → A 拿二级佣金（3%，即 3元）

用户Y 也成为推广员 → 邀请用户Z
用户Z 下单 100元 → Y 拿一级佣金（5%，即 5元）
                  → X 拿二级佣金（3%，即 3元）
                  → A 拿三级佣金（2%，即 2元）

分润比例可配置：

级别	默认比例	配置键
一级	5%	promoter_level1_rate
二级	3%	promoter_level2_rate
三级	2%	promoter_level3_rate

总计推广佣金上限：订单金额的 10%（三级合计），从平台抽成的 20% 中支出。

4.4 分润示例

场景：一笔 500 元订单，推广员三级关系都存在，调度员手动分派：

角色	金额	计算
订单金额	500.00	患者支付
平台抽成(20%)	100.00	500 × 20%
陪诊师所得	380.00	500 × 80% - 20(调度)
调度员所得	10.00	500 × 2%
推广员一级	25.00	500 × 5%
推广员二级	15.00	500 × 3%
推广员三级	10.00	500 × 2%
平台净收入	60.00	100 - 25 - 15 - 10
运营经理月结	—	区域月度流水 × 1~3%（平台另行支出）

---

五、数据库改动

5.1 新增表

用户角色关系表 sys_user_role_ext（已有 sys_user_role 可扩展）

-- 扩展现有 sys_user 表，userType 支持新角色
ALTER TABLE sys_user MODIFY COLUMN userType VARCHAR(10) COMMENT 'C=患者 B=陪护 00=超管 03=运营 04=客服 05=调度 06=推广员';

-- 推广关系表
CREATE TABLE rlz_promotion_relation (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  promoter_id BIGINT NOT NULL COMMENT '推广员用户ID',
  invited_user_id BIGINT NOT NULL COMMENT '被邀请用户ID',
  level TINYINT NOT NULL COMMENT '关系层级: 1=一级 2=二级 3=三级',
  parent_promoter_id BIGINT COMMENT '上级推广员ID(二级/三级时)',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  UNIQUE KEY uk_invited (invited_user_id),
  KEY idx_promoter (promoter_id)
) COMMENT='推广关系表';

-- 分润记录表
CREATE TABLE rlz_profit_record (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  order_id BIGINT NOT NULL COMMENT '关联订单ID',
  user_id BIGINT NOT NULL COMMENT '分润受益人',
  role_type VARCHAR(10) NOT NULL COMMENT '角色: B=陪诊师 05=调度 06=推广 03=运营',
  profit_type VARCHAR(10) NOT NULL COMMENT '分润类型: service=服务费 dispatch=调度 commission=推广 salary=底薪',
  amount DECIMAL(10,2) NOT NULL COMMENT '分润金额',
  rate DECIMAL(5,2) COMMENT '分润比例(%)',
  status CHAR(1) DEFAULT '0' COMMENT '0=待结算 1=已结算 2=已打款',
  settle_time DATETIME COMMENT '结算时间',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  KEY idx_order (order_id),
  KEY idx_user (user_id),
  KEY idx_status (status)
) COMMENT='分润记录表';

-- 推广员佣金配置表
CREATE TABLE rlz_promoter_config (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  config_key VARCHAR(50) NOT NULL UNIQUE,
  config_value VARCHAR(50) NOT NULL,
  description VARCHAR(200),
  update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) COMMENT='推广员佣金配置';

INSERT INTO rlz_promoter_config (config_key, config_value, description) VALUES
('promoter_level1_rate', '5', '一级推广佣金比例(%)'),
('promoter_level2_rate', '3', '二级推广佣金比例(%)'),
('promoter_level3_rate', '2', '三级推广佣金比例(%)'),
('promoter_max_total_rate', '10', '推广佣金总上限(%)'),
('dispatch_rate', '2', '调度员分润比例(%)'),
('operations_rate', '2', '运营经理区域流水比例(%)');

-- 推广员提现记录表（可复用现有钱包逻辑）
-- 陪诊师已有 yue/leijijine 字段，推广员也可使用同字段

5.2 现有表修改

表	改动
sys_user	userType 枚举扩展，推广员需加 promotion_code(邀请码)、parent_promoter_id(上级推广员)
rlz_order	增加 promoter_id(推广员ID)、dispatch_type(派单方式: auto/manual)、dispatcher_id(调度员ID)
sys_menu	新增推广端、调度端、客服端菜单
sys_role	新增运营经理、客服、调度、推广员角色

5.3 sys_user 字段扩展

ALTER TABLE sys_user
  ADD COLUMN promotion_code VARCHAR(20) COMMENT '推广邀请码',
  ADD COLUMN parent_promoter_id BIGINT COMMENT '上级推广员ID',
  ADD COLUMN region_id BIGINT COMMENT '所属区域ID',
  ADD UNIQUE KEY uk_promotion_code (promotion_code);

-- 区域表
CREATE TABLE rlz_region (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL COMMENT '区域名称',
  parent_id BIGINT DEFAULT 0 COMMENT '上级区域ID',
  level TINYINT COMMENT '1=省 2=市 3=区',
  manager_id BIGINT COMMENT '运营经理ID',
  status CHAR(1) DEFAULT '0',
  create_time DATETIME DEFAULT CURRENT_TIMESTAMP
) COMMENT='运营区域表';

---

六、后端实现要点

6.1 新增核心 Service

Service	职责
RlzPromotionService	推广关系绑定、邀请码生成、佣金计算
RlzProfitService	分润计算引擎（订单完成时触发）、分润记录生成
RlzDispatchService	调度派单逻辑、手动/自动派单切换
RlzRegionService	区域管理、运营经理绑定

6.2 分润计算引擎（核心）

// 订单支付成功后触发
// 在 WxPayNotify 或 weixinPayOrderNext() 中调用

@Service
public class RlzProfitService {

    // 支付回调成功后调用
    @Transactional
    public void calculateProfit(RlzOrder order) {
        BigDecimal totalAmount = new BigDecimal(order.getYuguMoney());

        // 1. 陪诊师服务费（80% - 调度费 - 运营费）
        BigDecimal caregiverRate = new BigDecimal("80");
        BigDecimal caregiverAmount = totalAmount.multiply(caregiverRate).divide(new BigDecimal("100"));

        // 2. 调度员分润（如果手动调度）
        if ("manual".equals(order.getDispatchType()) && order.getDispatcherId() != null) {
            BigDecimal dispatchRate = getConfig("dispatch_rate", "2");
            BigDecimal dispatchAmount = totalAmount.multiply(dispatchRate).divide(new BigDecimal("100"));
            caregiverAmount = caregiverAmount.subtract(dispatchAmount);
            createProfitRecord(order.getId(), order.getDispatcherId(), "05", "dispatch", dispatchAmount, dispatchRate);
        }

        // 3. 推广佣金（三级分润）
        Long promoterId = order.getPromoterId();
        calculatePromoterCommission(order, promoterId, totalAmount);

        // 4. 陪诊师分润
        createProfitRecord(order.getId(), order.getBId(), "B", "service", caregiverAmount, caregiverRate);

        // 5. 运营经理分润（月结，此处记录区域流水）
        recordRegionalRevenue(order);
    }

    private void calculatePromoterCommission(RlzOrder order, Long promoterId, BigDecimal amount) {
        // 向上追溯三级推广关系
        Long currentPromoterId = promoterId;
        for (int level = 1; level <= 3; level++) {
            if (currentPromoterId == null) break;
            String rateKey = "promoter_level" + level + "_rate";
            BigDecimal rate = getConfig(rateKey, level == 1 ? "5" : level == 2 ? "3" : "2");
            BigDecimal commission = amount.multiply(rate).divide(new BigDecimal("100"));
            createProfitRecord(order.getId(), currentPromoterId, "06", "commission", commission, rate);

            // 找上级推广员
            SysUser promoter = userService.selectUserById(currentPromoterId);
            currentPromoterId = promoter.getParentPromoterId();
        }
    }
}

6.3 新增 Controller

Controller	路由前缀	说明
RlzPromotionController	/system/promotion	推广数据、邀请码、团队列表
RlzProfitController	/system/profit	分润记录查询、结算管理
RlzDispatchController	/system/dispatch	调度派单、改派
RlzRegionController	/system/region	区域管理 CRUD

---

七、各端改动清单

7.1 管理后台 (Vue2) — 新增/改造页面

页面	路由	说明	工作估量
角色分配	/system/user/roleAssign	为用户分配角色（改造现有用户管理）	1天
区域管理	/system/region	省市区管理 + 绑定运营经理	1天
调度面板	/dispatch/board	待接单订单列表 + 手动指派陪诊师	2天
推广管理	/promotion/list	推广员列表 + 邀请数据 + 佣金记录	1.5天
分润管理	/finance/profit	全角色分润记录 + 结算审核 + 批量打款	2天
客服工单	/service/ticket	退款审核 + 纠纷处理 + 工单记录	1.5天
运营看板	/operations/dashboard	区域数据、收入趋势、陪诊师排行	2天

7.2 微信小程序 — 改造清单

核心思路：同一小程序 + 自定义 TabBar + 角色驱动 UI，不新建独立小程序。

基础设施

改造项	说明	工作估量
自定义 TabBar	custom-tab-bar/ 组件，根据 userType 返回不同 tabBar 配置（最多5个Tab）	1天
注册页改造	增加身份选择（我需要服务 / 我提供服务 / 我推广赚佣金），调度/客服/运营不开放自选	0.5天
我的页改造	增加"身份管理"入口 + 当前角色标识 + 多角色切换（患者⇄推广员可互切）	0.5天
首页改造	根据角色展示不同功能入口（患者看服务/推广员看数据/工作角色看工单）	1天

推广端子包 pages-promoter/（新增）

页面	说明	工作估量
推广数据看板	累计邀请人数、推广订单数、佣金总额、趋势图表	1.5天
我的团队	下级推广员列表（一级/二级/三级），含每个人的邀请数和贡献佣金	1天
佣金明细	每笔佣金来源（哪个用户、哪笔订单）、金额、状态（待结算/已到账）	1天
提现页面	佣金提现到微信零钱（复用现有 withdrawal 页面逻辑）	0.5天
分享工具	生成带邀请码的分享海报/小程序码，一键转发好友/群	1天

工作台子包 pages-work/（新增，调度+客服+运营共用）

页面	说明	工作估量
调度面板	待接单列表 + 点击指派陪诊师（弹窗选择） + 改派 + 超时提醒	2天
退款审核	退款申请列表 + 通过/驳回 + 驳回原因填写 + 退款进度跟踪	1.5天
运营看板	区域订单数/收入/陪诊师排行（可先用 WebView 加载后台页面快速上线）	1~2天
订单搜索	全平台订单搜索 + 状态筛选 + 详情查看（复用现有订单列表组件）	1天

小程序端合计：约 11~13 天

7.3 Android App — 改造清单

核心思路：现有陪护 App 保持不动，通过登录后角色判断动态加载不同 Fragment 和 Tab。陪诊师/调度/客服/运营四种角色共用同一 APK。

改造项	说明	工作估量
MainActivity 动态化	当前写死 3 个 Tab（首页/客户/我的），改为根据 userType 组装不同的 Fragment 集合和底部导航	1天
角色判断入口	SplashActivity → login 成功 → 后端返回 userType → 存入本地 → MainActivity 读取	0.5天
调度员界面	新增 DispatchFragment：待派单列表 + "指派"按钮 + 陪诊师选择弹窗 + 改派确认	2天
客服界面	新增 RefundFragment：退款审核列表 + 通过/驳回 + 原因填写弹窗	1.5天
运营看板	新增 OpsFragment：用 WebView 加载后台运营看板页面（快速上线方案）	0.5天
订单列表复用	TraceFragment 的 5 个子 Tab 已有完整订单管理，调度/客服/运营可直接复用	0天
网络层	新增调度/退款/统计相关 API 调用（在 HttpConstants 中补充 URL）	0.5天
收入明细	MyFragment 增加多角色收益展示（陪诊服务费 + 调度费 + 推广佣金等分项列示）	1天

Android 端合计：约 7 天

不需要两套 App。 一份代码，一份 APK，登录后根据角色展开不同界面。推广员不进 Android App，统一走微信小程序。

---

八、实施路线图

阶段 0：前置条件（当前 → 4周）

在做多角色之前，先完成商业化评估报告中的 P0 安全问题：

□ JWT 密钥强化
□ 支付密钥迁移环境变量
□ 生产环境 Druid/Swagger 关闭
□ 短信接口限流
□ 日志脱敏（密码/手机号）

耗时：2周，1人

阶段 1：角色基础设施（第 5~8 周）

□ 数据库表创建（推广关系/分润记录/区域/配置）
□ sys_user 字段扩展（invite_code, parent_promoter_id, region_id）
□ 后端：推广服务、分润引擎、调度服务、区域服务
□ 管理后台：角色分配、区域管理
□ 小程序：re注册页身份选择 + 自定义 TabBar 框架
□ Android：MainActivity 动态 Tab 重构 + 角色判断入口

耗时：4周，2人（1后端 + 1全栈）

阶段 2：推广 + 分润闭环（第 9~11 周）

□ 后端：分润计算引擎接入支付回调
□ 后端：推广佣金自动结算
□ 管理后台：推广管理、分润管理
□ 小程序：推广端子包（数据看板 + 团队 + 佣金 + 提现 + 分享海报）
□ Android：收入明细增加多角色分项展示
□ 联调测试：下单 → 支付 → 分润计算 → 推广佣金生成

耗时：3周，2人

阶段 3：调度 + 客服上线（第 12~14 周）

□ 管理后台：调度面板 + 客服工单
□ 后端：调度派单逻辑
□ 小程序：工作台子包 — 调度面板 + 退款审核
□ Android：调度员界面(DispatchFragment) + 客服界面(RefundFragment)
□ 联调：手动派单完整流程 + 退款审核完整流程

耗时：3周，2人

阶段 4：运营看板 + 全线联调（第 15~16 周）

□ 管理后台：运营看板（区域数据可视化）
□ 小程序：运营看板（可用 WebView 快速上线）
□ Android：运营看板（WebView 加载后台页面）
□ 全角色端到端测试（患者→陪诊师 + 推广员三级 + 调度派单 + 客服退款）
□ 性能优化（分润计算批量处理）
□ 文档 + 培训材料

耗时：2周，2人

总工期

阶段	内容	时间
阶段 0	安全整改	2 周
阶段 1	角色基础设施	4 周
阶段 2	推广 + 分润闭环	3 周
阶段 3	调度 + 客服	3 周
阶段 4	运营看板 + 联调	2 周
合计		14 周（约 3.5 个月）

人员配置：2 人（1 后端 + 1 全栈/小程序/Android），约 28 人周 = 7 人月。 费用估算：10~18 万 RMB（2人 × 3.5月）。

---

九、风险与应对

风险	影响	概率	应对措施
分润金额计算错误	资金纠纷	中	多级对账：系统计算 + 管理员审核 + 月度导出报表
推广刷单薅羊毛	资金损失	高	反作弊：同设备/IP限制、最小提现金额、订单完成才结算
三级分润法律风险	被认定为传销	低	严格限制三级、不设人头费只按消费分润、法务审核
陪诊师抵制调度员分润	运营阻力	中	调度分润从平台抽成出，不影响陪诊师收入
角色权限越权	数据泄露	中	RuoYi RBAC 已有基础，需逐个接口加 @PreAuthorize
推广佣金过高挤占利润	平台亏损	中	所有比例可配置、设总佣金上限(10%)、定期分析 ROI

---

十、总结

核心价值

1. 从 2 角色 → 7 角色：将平台的劳动分工精细化，每个人都能在平台上找到自己的位置
2. 推广分润 = 增长引擎：三级分润让每个用户都有动力去邀请新用户，实现病毒式增长
3. 调度运营 = 规模化基础：有了调度和运营角色，才能跨城市复制，而不是依赖单一管理员
4. 分润透明 = 信任基础：每笔订单的分润记录清晰可查，所有角色都能看到自己的贡献和回报
5. 终端最大化复用：不新建独立小程序或 App，通过自定义 TabBar + 角色驱动 UI，一份代码服务全部角色

推荐策略

先做推广员 + 分润引擎（阶段 1+2），再做调度 + 客服（阶段 3）。 理由是：

• 推广员角色直接带来用户增长，ROI 最快
• 分润引擎是整个体系的核心基础设施，先建好再扩展其他角色
• 调度和客服是成本中心，推广是利润中心，先利润后成本

终端策略：

终端	策略
微信小程序	同一小程序 + 自定义 TabBar + 2 个新子包（pages-promoter + pages-work），不建新应用
Android App	现有 peizhen 工程扩展，陪诊师/调度/客服/运营四角色共用，推广员不进 App
Web 后台	新增 7 个页面（角色分配/区域管理/调度面板/推广管理/分润管理/客服工单/运营看板）

关键成功指标

指标	目标（上线后 3 个月）
推广员注册数	≥ 100 人
推广带来的订单占比	≥ 30%
推广获客成本(CAC)	< 订单金额的 10%
调度员处理的订单占比	≥ 20%
客服工单处理时效	< 2 小时
分润计算准确率	100%（经人工审核确认）

---

相关文档：

• 商业化评估报告：D:\androidPj\rlz\docs\商业化评估报告.md
• 陪诊员服务费分账方案：D:\androidPj\rlz\docs\陪诊员服务费分账方案.md
• 订单流转设计方案：D:\androidPj\rlz\docs\订单流转设计方案.md
• 后台管理功能模块规划：D:\androidPj\rlz\docs\后台管理功能模块规划.md
• PRD 文档：D:\androidPj\rlz\docs\项目功能的prd文档.md