Tapx PRD Overview / 1.4.0

试用止损、礼物闭环、计费透明与主播运营补强

本轮目标不是继续扩功能，而是先把 Tapx 的核心商业链路修到可放量状态。优先堵住试用漏洞，建立邮箱验证码一体化认证，再把首页理解、计费表达、礼物反馈、主播统计和后台画像串成一条完整产品线。

会议来源：2026-05-13 产品会 阶段目标：试用可控、首访清晰、礼物闭环、计费透明 关联系统：test_user / tapx_backend / tapx_admin / web_car_controller
P0 止损 3

首页理解、试用防刷、前置计费是当前必须优先落地的三条主线。

计划 PRD 6

本轮只创建总览，后续将拆成 6 份详细 PRD 分别推进。

核心子系统 4

前台、后端、后台和控车端都在本轮范围内，属于跨系统联动需求。

计费原则 30s

默认采用前置计费思路，即使用 1 秒也按首个计费单元扣费。

本期要解决什么

会议内容可以归纳为四个结果导向：让用户看懂、让试用止损、让礼物能赚钱、让计费讲明白。

首访理解与找主播

首页需要把产品价值说清楚，并同时支持两种路径：找指定主播，或浏览当前可体验主播。

试用资格与身份可信

登录注册改成一体化入口，用户用邮箱验证码完成认证后，才允许领取每账号唯一的一次试用额度。

礼物商业化闭环

礼物要形成积分购买、设备反馈、订单记录、按比例分润和收入统计的完整链路。

计费透明与安全运营

用户在进入控车前必须看到计费规则；主播与后台需要最小必要的安全控制和访问画像能力。

PRD 拆分目录

当前已创建总览以及 `1.4.1` 到 `1.4.6` 的全部 HTML PRD。下面 6 张卡片已经全部落地。

系统
优先级
打开执行工具页
显示 6 / 6 份计划文档
1.4.1

首页价值表达与选主播路径优化

P0

解决用户第一次打开首页时“不知道产品是做什么的”，并降低“找指定主播”与“浏览可体验主播”的操作成本。

已创建 test_user tapx_backend
1.4.1-home-and-streamer-selection.html
查看计划范围
核心范围
  • 首页首屏价值表达与主 CTA 改造
  • 指定主播查找入口与浏览入口的双路径设计
  • 主播列表、在线状态、可体验状态的更清晰表达
关键验收
  • 用户 3 秒内理解产品用途
  • 可以清楚区分“直接找人”和“看看谁现在可玩”
1.4.2

试用、防刷、邮箱验证码一体化认证

P0

解决试用积分可无限领取的严重漏洞，并把登录注册改造成以邮箱验证码为核心的合并流程。

已创建 test_user tapx_backend
1.4.2-trial-auth-and-abuse-prevention.html
查看计划范围
核心范围
  • 统一认证页，邮箱验证码为主路径，支持用户名 / 密码辅助登录
  • 邮箱验证码发送、校验、按邮箱频控与失败提示
  • 唯一试用资格发放与重复领取拦截
  • MVP 仅按邮箱维度做唯一性与幂等控制
关键验收
  • 未完成邮箱认证的用户不能领取试用
  • 同一账号不得重复获得试用额度
1.4.3

礼物、积分、设备反馈与订单分润

P1

把礼物系统从单点想法推进到完整闭环：积分购买、礼物消费、屏幕和语音反馈、订单沉淀、后台按比例分润。

已创建 test_user tapx_backend tapx_admin web_car_controller
1.4.3-gift-points-and-revenue-share.html
查看计划范围
核心范围
  • 积分购买礼物与礼物商品定义
  • 车端液晶屏与语音播报联动
  • 礼物订单数据结构与分润口径
  • 后台礼物订单核对与分润规则配置能力
关键验收
  • 礼物支付成功后车端有真实反馈
  • 后台可根据订单生成主播分润依据
1.4.4

计费规则展示与前置计费方案

P0

让用户在合适时机明确看到扣费规则，并在控车链路中正式采用前置计费逻辑。

已创建 test_user tapx_backend web_car_controller
1.4.4-billing-rules-and-precharge.html
查看计划范围
核心范围
  • 试用与正式控车的计费说明文案与展示时机
  • 首个 30 秒计费单元与后续 30 秒整档续费规则定义
  • 余额不足、续费、会话结束提示口径
关键验收
  • 进入控车前可见计费规则
  • 实际计费与展示规则一致
1.4.5

主播 H5 控车安全能力与收入统计

P1

给主播最小必要的车控安全开关，并让主播主页可以按收入类型和时间范围查看分润后的收益汇总。

已创建 test_user tapx_backend
1.4.5-streamer-h5-and-income-stats.html
查看计划范围
核心范围
  • 主播选择指定车辆并执行停止喷水、停止移动
  • 收入按观众时长、礼物、喷水等类型汇总
  • 支持按时间段查询，不展示完整流水明细
关键验收
  • 主播可以对指定车辆做安全停控
  • 收入数字为分润后的结果
1.4.6

后台用户访问画像增强

P1

为运营和运维补充用户更详细的访问信息，至少包含 IP 地址和浏览器信息，便于排查异常和分析行为。

已创建 tapx_admin tapx_backend
1.4.6-admin-user-access-observability.html
查看计划范围
核心范围
  • 列表展示：用户 ID、邮箱、邮箱验证状态、试用状态、最近 IP、浏览器
  • 详情展示：注册 IP、最近登录 IP、浏览器、OS、来源页、认证与试用日志
  • 为风控和运营复盘提供基础字段
  • 与试用防刷策略形成数据闭环
关键验收
  • 后台能查到更完整的访问上下文
  • 异常用户排查效率提升

建议执行顺序

排序原则是先止损，再统一收费口径，再提高流量转化，最后补商业化增强和后台画像。

1

先修试用漏洞

优先做 `1.4.2`。这一步直接影响平台损失，是当前最明确的 P0。

2

再统一计费口径

紧接着做 `1.4.4`。如果收费逻辑和展示口径不清楚，后续首页优化和礼物商业化都会放大争议。

3

然后放大首页转化

完成 `1.4.1` 后，用户才会更容易从首访进入主播浏览和控车漏斗。

4

补礼物闭环

`1.4.3` 是商业化增强器，适合在身份和计费基础稳定后推进。

5

补主播侧运营工具

`1.4.5` 用于提高主播可控性和收益感知，服务后续供给侧稳定。

6

最后增强后台画像

`1.4.6` 虽然重要，但不应阻塞本轮最核心的止损和收费主链路。

依赖关系

下面是更适合汇报展示的依赖图。图下保留了 Mermaid 源码，便于后续复制到 Markdown 或设计文档中继续扩写。

1.4.1 首页价值表达 先让用户知道产品是什么、去哪里找主播 1.4.2 邮箱验证码认证 登录注册合并、唯一试用资格、防刷 试用资格发放 真实邮箱后才能领取一次试用 1.4.4 计费规则展示 在控车前把扣费逻辑讲明白 前置计费 30 秒单元 平台收益优先，首单元先扣费 1.4.3 礼物与订单分润 积分购买、车端反馈、订单沉淀、分润 1.4.5 主播 H5 安全停控和收入汇总 1.4.6 后台访问画像 IP、浏览器与运营排查能力
P0 立即优先 P1 二阶段增强 跨系统协同节点
Mermaid 渲染预览

下面这块会在浏览器里自动渲染。如果没有显示成图，通常是因为当前预览环境没有执行外部模块脚本，或无法访问 Mermaid CDN。

flowchart TD A[1.4.1 首页价值表达与选主播路径] --> B[1.4.2 登录注册合并 + 邮箱验证码] B --> C[唯一试用资格发放] C --> D[1.4.4 试用与正式控车计费说明] D --> E[前置计费 30 秒单元] E --> F[正式控车消费闭环] F --> G[1.4.3 礼物购买与设备反馈] G --> H[订单分润与主播收入统计] F --> I[1.4.5 主播 H5 安全控制] H --> J[1.4.6 后台运营与访问画像] I --> J
Mermaid 源码 
flowchart TD
    A[1.4.1 首页价值表达与选主播路径] --> B[1.4.2 登录注册合并 + 邮箱验证码]
    B --> C[唯一试用资格发放]
    C --> D[1.4.4 试用与正式控车计费说明]
    D --> E[前置计费 30 秒单元]
    E --> F[正式控车消费闭环]
    F --> G[1.4.3 礼物购买与设备反馈]
    G --> H[订单分润与主播收入统计]
    F --> I[1.4.5 主播 H5 安全控制]
    H --> J[1.4.6 后台运营与访问画像]
    I --> J

阶段验收口径

这部分只定义总览层面的通过标准，详细交互和字段要求放到后续子 PRD 中补齐。

首页理解 用户打开首页后，能明确知道 Tapx 是真实设备互动产品，并知道下一步去哪里找主播。
选主播路径 同时支持“找指定主播”和“浏览当前可体验主播”两种操作路径。
试用防刷 邮箱验证码认证后才允许领取试用，且同一账号不能重复获得试用额度。
计费透明 用户进入试用或正式控车前，可见扣费规则、最小计费单元和余额不足提示。
礼物闭环 用户可使用积分购买礼物，车端液晶屏和语音能给出反馈，后台有订单与分润依据。
主播与后台能力 主播能做安全停控，后台能查看用户 IP、浏览器等更详细的访问信息。

已确认口径与建议

以下内容已经结合当前会议确认和本轮建议收敛，可直接作为后续详细 PRD 的默认口径。

试用额度口径

已确认按统一试用积分余额发放。前台对外展示等价体验，例如约 30 秒控车或 2 次喷水，具体积分数值由计费方案文档定义。

认证方式口径

已确认邮箱验证码不完全替代密码。认证页以邮箱验证码为主路径，同时支持用户名 / 密码辅助登录，当前开发阶段不需要兼容迁移设计。

前置计费续费建议

建议首个计费单元和续费单元统一按 30 秒整档处理；剩余 5 秒提示下一档扣费，余额足够且用户未结束时自动续扣，否则当前档结束后自动停止。

礼物分润口径

已确认分润为可配置规则，不做全局固定值。`tapx_admin` 需要提供分润规则配置能力，供运营配置不同分润方案。

MVP 防刷口径

已确认本期只按邮箱维度做最小防刷。最小实现为邮箱唯一、邮箱验证码发送频控和试用领取幂等，IP / 设备 / UA 风控延后。

后台画像粒度建议

建议分两层。列表显示用户 ID、邮箱、邮箱验证状态、试用状态、注册时间、最后活跃、最近 IP、浏览器；详情显示注册 IP、最近登录 IP、浏览器、OS、语言、来源页和最近认证 / 试用日志。