12 KiB
12 KiB
幸运礼物 · 必爆隐藏奖池产品方案（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 |
期望值：
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 必爆机制
周期初始化：
T = J_current + Uniform[280000, 720000]
每次送礼按顺序执行：
J = J + 50。- 如果
J >= T且当前周期未触发，强制触发超级爆池。 - 超级爆池金额为
win_J = J * r，其中r = Uniform[0.32, 0.48]。 - 释放后
J_new = J - win_J，通常保留 52%-68% 底池。 - 新周期爆点为
T_new = J_new + Uniform[300000, 800000]。
参数依据：
- 28 万到 72 万爆点贡献区间用于覆盖热门房间约 40-120 分钟的心理窗口。
- 32%-48% 强制释放比例保证单次大奖冲击力，同时保留底池继续滚动。
5. 完整开奖流程
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 过大时，可以轻微抬高基础大奖概率：
p_base = 0.01 + min(0.004, (J - 500000) / 75000000)
动态调参必须写入规则版本或配置变更记录，不能只改运行内存，否则无法审计和复盘。
8. 预期效果与 KPI
| 维度 | 预期 |
|---|---|
| 用户行为 | 高频小奖维持发送频率，稀有大奖和必爆大奖制造传播峰值。 |
| 经济指标 | 平台抽水稳定，J Fund 不透支，大额释放后仍有底池恢复能力。 |
| 风险指标 | 单用户单次/累计上限、内部账号隔离、完整审计降低套利和质疑。 |
| 长期循环 | 数学上保证喂池后一定爆发，形成持续正反馈循环。 |
9. 技术实施建议
9.1 后端落地顺序
- 先实现资金原子更新、J Fund 周期状态、开奖事实和完整审计日志。
- 再接入 outbox worker，由钱包服务幂等入账。
- 最后接入房间 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 贡献，默认仍保持极简模式。 |