# “我的”Tab 填邀请码 PRD

更新时间：`2026-04-16`

> 2026-04-30 更新：用户侧邀请码填写入口已迁到注册环节，当前落地以 `docs/technical/PROFILE_INVITE_CODE_REGISTRATION_AND_ADMIN_2026-04-30.md` 为准；“我的 Tab”不再保留填邀请码入口。

## 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. 奖励发放结果可追踪