308 lines
12 KiB
Markdown
308 lines
12 KiB
Markdown
# 幸运礼物 · 必爆隐藏奖池产品方案（6.25 版）
|
||
|
||
## 文档信息
|
||
|
||
| 项 | 内容 |
|
||
| --- | --- |
|
||
| 版本 | v1.0 |
|
||
| 日期 | 2026-06-25 |
|
||
| 范围 | 语音房幸运礼物的新一版产品与算法方案 |
|
||
| 状态 | 产品方案，不能直接等同于当前代码已上线能力 |
|
||
|
||
目标是在语音房送礼场景里提供一个极简、高方差、长期自平衡的幸运礼物系统。用户侧只感知“送礼 -> 开奖 -> 结果表现”，后台通过隐藏奖池完成持续喂池和必然爆池。平台先抽水，剩余资金进入小奖反馈层和隐藏奖池层，所有开奖必须可审计、可重放。
|
||
|
||
## 1. 项目背景与目标
|
||
|
||
### 1.1 背景
|
||
|
||
用户发送幸运礼物后，需要马上获得强反馈。传统固定倍数或简单随机容易出现长时间无大奖、低波动、低传播的问题，用户会认为玩法“干等”或“不刺激”。新方案用三层反馈叠加：
|
||
|
||
- 高频小奖让每次送礼都有反馈。
|
||
- 稀有大奖制造黑天鹅惊喜。
|
||
- 必爆隐藏奖池保证在可控贡献量内一定出现大额 payout。
|
||
|
||
### 1.2 核心目标
|
||
|
||
| 目标 | 说明 |
|
||
| --- | --- |
|
||
| 用户侧 | 每次送礼都有独立开奖体验，高频小奖、稀有大奖和必爆大奖叠加。 |
|
||
| 平台侧 | 每笔先抽水，剩余奖池自平衡，不允许平台倒贴。 |
|
||
| 长期循环 | 通过“持续喂池 -> 必然爆池 -> 留底滚动”形成可持续戏剧性循环。 |
|
||
| 认知成本 | 用户端不展示复杂池子、爆点和概率，只触发送礼并接收结果。 |
|
||
| 审计公平 | 每次开奖记录 before/after、随机因子、trigger 状态和结果，支持事后重放。 |
|
||
|
||
### 1.3 成功标准
|
||
|
||
- 单次 100 金礼物的玩家侧期望返还约为 75-78 金。
|
||
- 必爆机制保证在可控贡献量内一定出现大额 payout。
|
||
- 大奖释放后隐藏奖池仍保留 52%-68% 底池，继续滚雪球。
|
||
- 内部账号、机器人和主播测试流量不能真实消耗 J Fund。
|
||
|
||
## 2. 核心设计理念
|
||
|
||
### 2.1 三层爽感
|
||
|
||
| 层级 | 机制 | 产品意义 |
|
||
| --- | --- | --- |
|
||
| 高频层 S Fund | 超过 58% 概率获得正返还。 | 维持连续发送行为，避免每次都空。 |
|
||
| 稀有大奖层 J Fund | 1% 概率按隐藏池百分比释放。 | 形成不可预测的大额惊喜。 |
|
||
| 必然爆发层 Must-Hit | 隐藏爆点强制释放 32%-48% 奖池。 | 消除长期干等，完成喂池到爆池的闭环。 |
|
||
|
||
### 2.2 隐藏与独立
|
||
|
||
- 公共奖池状态、爆点和当前周期不对客户端展示。
|
||
- S Fund 与 J Fund 独立 roll，小奖层 Miss 不影响大奖层触发。
|
||
- 每次送礼都先形成完整开奖事实，再由表现层展示结果。
|
||
|
||
### 2.3 平台零风险
|
||
|
||
- 每笔送礼先扣平台抽水。
|
||
- J Fund payout 只能按比例释放，并受留底、单次上限和风控上限约束。
|
||
- 奖池余额不足时不能透支，必须降级为可支付结果或 Miss。
|
||
|
||
## 3. 资金流与数学模型
|
||
|
||
每送 100 金单位礼物，资金拆分如下：
|
||
|
||
| 去向 | 金额 | 占比 |
|
||
| --- | ---: | ---: |
|
||
| 平台抽水 | 22 金 | 22% |
|
||
| S Fund 小奖反馈 | 28 金 | 28% |
|
||
| J Fund 隐藏奖池 | 50 金 | 50% |
|
||
|
||
长期口径：
|
||
|
||
- 平台固定收益：22 金。
|
||
- S Fund 期望返还：约 22.84 金，利用率约 81.6%。
|
||
- J Fund payout 长期受控在总贡献 50% 以内，依赖分段释放比例、必爆上限和留底。
|
||
- 玩家侧综合期望返还约为 75.84 金，符合社交礼物玩法的健康区间。
|
||
|
||
## 4. 开奖算法
|
||
|
||
### 4.1 S Fund 小奖反馈层
|
||
|
||
S Fund 使用 Alias Method 做 O(1) 采样。金额使用连续均匀分布，避免固定值被用户感知为机械规律。
|
||
|
||
| Tier | 概率 | 返还金额 | 期望贡献 |
|
||
| --- | ---: | ---: | ---: |
|
||
| Miss | 42% | 0 | 0 |
|
||
| 小回血 | 32% | Uniform[8, 18] | 4.16 |
|
||
| 中回血 | 16% | Uniform[25, 45] | 5.60 |
|
||
| 好奖 | 7% | Uniform[60, 120] | 6.30 |
|
||
| 大回血 | 3% | Uniform[150, 280] | 6.45 |
|
||
|
||
期望值：
|
||
|
||
```text
|
||
E[S] = 0.32 * 13 + 0.16 * 35 + 0.07 * 90 + 0.03 * 215
|
||
= 22.51
|
||
```
|
||
|
||
说明：原始方案中的 `22.84` 与表格均值直接计算不完全一致。按当前表格区间中点计算是 `22.51`。如果产品口径必须锁定 `22.84`，需要微调某一档金额区间或概率后再进入实现。
|
||
|
||
### 4.2 J Fund 基础隐藏奖池层
|
||
|
||
每次送礼原子增加 50 金到 J Fund。J Fund 与 S Fund 独立开奖。
|
||
|
||
基础触发：
|
||
|
||
- 触发概率：1.0%。
|
||
- 获奖金额：`win_J = J * r`。
|
||
- 释放后：`J_new = J - win_J`，不清空奖池，保留自然底池。
|
||
|
||
释放比例按当前 J Fund 规模分段：
|
||
|
||
| J Fund 当前规模 | r 范围 |
|
||
| --- | --- |
|
||
| J < 200000 | Uniform[0.05, 0.10] |
|
||
| 200000 <= J < 500000 | Uniform[0.08, 0.15] |
|
||
| J >= 500000 | Uniform[0.12, 0.22] |
|
||
|
||
### 4.3 Must-Hit 必爆机制
|
||
|
||
周期初始化：
|
||
|
||
```text
|
||
T = J_current + Uniform[280000, 720000]
|
||
```
|
||
|
||
每次送礼按顺序执行：
|
||
|
||
1. `J = J + 50`。
|
||
2. 如果 `J >= T` 且当前周期未触发，强制触发超级爆池。
|
||
3. 超级爆池金额为 `win_J = J * r`，其中 `r = Uniform[0.32, 0.48]`。
|
||
4. 释放后 `J_new = J - win_J`，通常保留 52%-68% 底池。
|
||
5. 新周期爆点为 `T_new = J_new + Uniform[300000, 800000]`。
|
||
|
||
参数依据：
|
||
|
||
- 28 万到 72 万爆点贡献区间用于覆盖热门房间约 40-120 分钟的心理窗口。
|
||
- 32%-48% 强制释放比例保证单次大奖冲击力，同时保留底池继续滚动。
|
||
|
||
## 5. 完整开奖流程
|
||
|
||
```text
|
||
on_lucky_gift(user_id, amount = 100):
|
||
platform_rake += 22
|
||
s_fund += 28
|
||
|
||
j_before = j_fund
|
||
j_fund += 50
|
||
|
||
s_win = roll_s_fund()
|
||
credit_user(user_id, s_win)
|
||
|
||
j_win = 0
|
||
forced = false
|
||
|
||
if j_fund >= current_trigger and current_cycle_not_triggered:
|
||
r = uniform(0.32, 0.48)
|
||
j_win = j_fund * r
|
||
j_win = apply_jackpot_caps(j_win, j_fund)
|
||
j_fund -= j_win
|
||
current_trigger = j_fund + uniform(300000, 800000)
|
||
forced = true
|
||
else if random() < 0.01:
|
||
r = get_r_by_pool_size(j_fund)
|
||
j_win = j_fund * r
|
||
j_win = apply_jackpot_caps(j_win, j_fund)
|
||
j_fund -= j_win
|
||
|
||
if j_win > 0:
|
||
credit_user(user_id, j_win)
|
||
|
||
write_audit_log(...)
|
||
```
|
||
|
||
必须注意：真实实现不能在抽奖事务里直接调用钱包入账。应先写开奖事实和 outbox，再由 worker 幂等发奖，避免数据库事务和外部 RPC 混在一起。
|
||
|
||
## 6. 安全、公平与风控规则
|
||
|
||
| 规则 | 要求 |
|
||
| --- | --- |
|
||
| 单次上限 | `win_J = min(win_J, j_fund * 0.48, 500000)`。 |
|
||
| 个人累计上限 | 可选日/周 jackpot 累计封顶，防止洗钱和异常套利。 |
|
||
| 内部账号隔离 | internal、bot、host 测试账号只能走 S Fund 和模拟 J Fund，不真实消耗 J Fund。 |
|
||
| 随机性 | 使用密码学安全 RNG，每次记录 seed 或可验证随机材料，支持重放。 |
|
||
| 并发安全 | J Fund 更新必须在数据库事务内完成，使用行锁、版本号或分布式锁防止并发透支。 |
|
||
| 初始种子 | 新周期可注入 8 万到 15 万启动 J Fund，计入营销成本或后期回收。 |
|
||
| 审计完整性 | 每笔记录 gift_id、user_id、room_id、j_before、j_after、s_win、j_win、forced_hit、random_seed、trigger、ts。 |
|
||
|
||
## 7. 参数配置与动态调优
|
||
|
||
### 7.1 推荐 v1.0 参数
|
||
|
||
| 参数 | 推荐值 | 调优方向 |
|
||
| --- | --- | --- |
|
||
| 平台抽水 | 22% | 不可低于 18%。 |
|
||
| S Fund 贡献 | 28% | 维持 E[S] 约 22.5-23.5。 |
|
||
| J Fund 贡献 | 50% | 核心滚雪球资金来源。 |
|
||
| 基础池奖概率 | 1.0% | 可在 0.6%-1.5% 调整。 |
|
||
| 必爆释放比例 | Uniform[0.32, 0.48] | 越高越激进，越低越耐久。 |
|
||
| 初始爆点范围 | Uniform[280000, 720000] | 礼物量越大，范围可越大。 |
|
||
| 新周期爆点范围 | Uniform[300000, 800000] | 大奖后重建周期，避免连爆过密。 |
|
||
|
||
### 7.2 动态微调
|
||
|
||
当 J Fund 过大时，可以轻微抬高基础大奖概率：
|
||
|
||
```text
|
||
p_base = 0.01 + min(0.004, (J - 500000) / 75000000)
|
||
```
|
||
|
||
动态调参必须写入规则版本或配置变更记录，不能只改运行内存，否则无法审计和复盘。
|
||
|
||
## 8. 预期效果与 KPI
|
||
|
||
| 维度 | 预期 |
|
||
| --- | --- |
|
||
| 用户行为 | 高频小奖维持发送频率，稀有大奖和必爆大奖制造传播峰值。 |
|
||
| 经济指标 | 平台抽水稳定，J Fund 不透支，大额释放后仍有底池恢复能力。 |
|
||
| 风险指标 | 单用户单次/累计上限、内部账号隔离、完整审计降低套利和质疑。 |
|
||
| 长期循环 | 数学上保证喂池后一定爆发，形成持续正反馈循环。 |
|
||
|
||
## 9. 技术实施建议
|
||
|
||
### 9.1 后端落地顺序
|
||
|
||
1. 先实现资金原子更新、J Fund 周期状态、开奖事实和完整审计日志。
|
||
2. 再接入 outbox worker，由钱包服务幂等入账。
|
||
3. 最后接入房间 IM、区域播报、后台配置、后台查询和监控告警。
|
||
|
||
### 9.2 服务边界
|
||
|
||
| 服务 | 职责 |
|
||
| --- | --- |
|
||
| room-service | 只负责送礼主链路、房间状态、Room Cell 和房间 outbox，不拥有奖池。 |
|
||
| activity-service | 拥有幸运礼物规则、S Fund、J Fund、开奖事实、风控和发奖 outbox。 |
|
||
| wallet-service | 负责送礼扣费和幸运礼物返奖入账，保证幂等账务。 |
|
||
| statistics-service | 只消费事件写聚合表，不回查 owner service 明细表。 |
|
||
| server/admin | 提供参数配置、规则版本、开奖明细和统计查询入口。 |
|
||
|
||
### 9.3 必须支持热更新
|
||
|
||
以下参数需要后台配置并落规则版本：
|
||
|
||
- 平台抽水比例。
|
||
- S Fund 分布、概率和金额区间。
|
||
- J Fund 贡献比例。
|
||
- 基础大奖概率和分段释放比例。
|
||
- Must-Hit 爆点范围和释放比例。
|
||
- 单次、单用户、设备、房间、主播风控上限。
|
||
- 内部账号和机器人隔离规则。
|
||
|
||
### 9.4 监控告警
|
||
|
||
- J Fund 余额异常波动。
|
||
- 实际 win rate 与配置概率长期偏离。
|
||
- 单用户、单设备、单房间大额中奖集中。
|
||
- outbox 发奖积压或失败。
|
||
- 钱包返奖幂等冲突。
|
||
- 必爆周期长时间未重置或重复触发。
|
||
|
||
### 9.5 合规
|
||
|
||
上线前需要法务确认虚拟礼物概率玩法边界。客户端可以公开必要规则说明，但不能暴露隐藏奖池余额、当前爆点和触发进度。
|
||
|
||
## 10. 审计日志字段
|
||
|
||
每笔开奖至少记录：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| gift_id | 本次送礼或抽奖唯一 ID。 |
|
||
| command_id | 幂等命令 ID，重试必须复用。 |
|
||
| user_id | 送礼用户。 |
|
||
| room_id | 房间 ID。 |
|
||
| target_user_id | 收礼用户。 |
|
||
| amount | 本次礼物真实扣费金额。 |
|
||
| s_before / s_after | S Fund 变更快照。 |
|
||
| j_before / j_after | J Fund 变更快照。 |
|
||
| s_win | S Fund 中奖金额。 |
|
||
| j_win | J Fund 中奖金额。 |
|
||
| forced_hit | 是否 Must-Hit 强制触发。 |
|
||
| trigger_before / trigger_after | 周期爆点变更。 |
|
||
| random_seed | 可验证随机材料。 |
|
||
| random_rolls | 本次所有随机 roll 明细。 |
|
||
| status | pending、granted、failed。 |
|
||
| created_at_ms | UTC epoch milliseconds。 |
|
||
|
||
## 11. 当前实现差距
|
||
|
||
本方案与当前仓库中的幸运礼物 v2 配置化 RTP 奖档模型不是同一个口径。进入技术实现前，需要明确是否替换现有 v2 主链路，或作为新 `pool_id` / 新规则版本并行上线。
|
||
|
||
必须确认的差距：
|
||
|
||
- 当前实现按 `pool_id`、规则版本、阶段奖档和 RTP 窗口抽奖；新方案按 S Fund、J Fund 和 Must-Hit 周期抽奖。
|
||
- 当前实现已有三层基础奖池和风控计数；新方案需要新增隐藏 J Fund 周期状态和强制爆点。
|
||
- 当前实现 worker 已支持异步发奖；新方案必须复用这个账务边界，不能把伪代码中的 `credit_user` 做成事务内 RPC。
|
||
- 当前统计只能消费事实事件写聚合表；新方案的 S/J payout 需要补充事件字段或独立统计读模型。
|
||
|
||
## 12. 版本迭代计划
|
||
|
||
| 版本 | 内容 |
|
||
| --- | --- |
|
||
| v1.1 | 增加多档幸运礼物，高价礼物贡献更高 J Fund 比例。 |
|
||
| v1.2 | 按房间活跃度自适应 Must-Hit 爆点范围。 |
|
||
| v1.3 | 可选展示个人累计 jackpot 贡献，默认仍保持极简模式。 |
|