# 幸运礼物 · 必爆隐藏奖池产品方案（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 贡献，默认仍保持极简模式。 |