Genarrative/docs/prd/MY_TAB_INVITE_CODE_REDEMPTION_PRD_2026-04-16.md

“我的”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. 奖励发放结果可追踪