11

docs/prd/MY_TAB_INVITE_CODE_REDEMPTION_PRD_2026-04-16.md

@@ -0,0 +1,160 @@
+# “我的”Tab 填邀请码 PRD
+
+更新时间：`2026-04-16`
+
+## 0. 目标
+
+把“填邀请码”做成用户激活早期的一次性绑定动作，完成：
+
+1. 输入邀请码
+2. 校验邀请码是否可用
+3. 绑定邀请关系
+4. 发放被邀请奖励
+
+---
+
+## 1. 当前现状与问题
+
+当前页面有“填邀请码”按钮，但没有成型规则。最容易踩坑的点是：
+
+1. 什么时候还能填
+2. 一个账号能不能改绑
+3. 邀请人与被邀请人奖励何时发
+
+如果不先写清楚，后续很容易出现刷奖励和投诉问题。
+
+---
+
+## 2. 本期范围
+
+## 2.1 本期要做
+
+1. 邀请码填写弹窗
+2. 邀请关系校验
+3. 一次性绑定规则
+4. 绑定成功后的奖励发放
+
+## 2.2 本期不做
+
+1. 改绑邀请人
+2. 申诉人工修正流程
+3. 活动邀请码多类型扩展
+
+---
+
+## 3. 业务规则
+
+## 3.1 填写时机
+
+邀请码只允许在下面时间窗内填写：
+
+1. 新账号注册后
+2. 且尚未绑定过任何邀请码
+3. 且未超过首个有效周期，例如 `7` 天
+
+## 3.2 不允许情况
+
+以下情况不可填写：
+
+1. 已绑定过邀请码
+2. 用自己的邀请码填写
+3. 已超过填写时效
+4. 邀请码失效或不存在
+
+## 3.3 绑定结果
+
+绑定成功后：
+
+1. 写入邀请关系
+2. 发放被邀请用户奖励
+3. 更新邀请人待结算或已结算状态
+
+邀请码绑定后不可撤销、不可修改。
+
+---
+
+## 4. 详细设计
+
+## 4.1 页面结构
+
+弹窗内容仅保留：
+
+1. 输入框
+2. 提交按钮
+3. 当前可否填写状态
+
+不默认写长篇规则说明。
+
+必要提示采用短句：
+
+- 已绑定，无法修改
+- 该邀请码不可用
+- 绑定成功
+
+## 4.2 交互
+
+1. 输入邀请码
+2. 点击确认绑定
+3. 服务端校验
+4. 返回成功或失败状态
+
+成功后：
+
+- 按钮置灰
+- 展示绑定的邀请人昵称或摘要
+
+---
+
+## 5. 后端设计
+
+## 5.1 数据模型
+
+复用：
+
+- `user_invite_codes`
+- `user_referral_relations`
+- `user_reward_ledger`
+
+并为被邀请方增加：
+
+- `invited_by_user_id`
+- `invite_bound_at`
+
+## 5.2 接口
+
+### `GET /api/referrals/redeem-status`
+
+返回：
+
+- 是否还能填写
+- 已绑定邀请人摘要
+- 填写截止时间
+
+### `POST /api/referrals/redeem-code`
+
+入参：
+
+- `inviteCode`
+
+出参：
+
+- `ok`
+- `inviterSummary`
+- `rewardSummary`
+
+---
+
+## 6. 前端实现要求
+
+1. 已绑定状态下直接展示结果，不再显示输入表单
+2. 提交中不能重复点击
+3. 服务端失败原因要原样映射成短提示
+
+---
+
+## 7. 验收标准
+
+1. 符合条件的新账号可以成功绑定邀请码
+2. 同一账号不能重复绑定
+3. 不能填写自己的邀请码
+4. 奖励发放结果可追踪