danyang-match/公益相亲活动与线下服务闭环详细设计.md

# 丹阳公益婚恋服务平台
# V1.0 公益相亲活动与线下服务闭环详细设计

版本：V1.0  
适用范围：微信小程序用户端、公益红娘工作台、运营管理后台、线下活动执行人员  
核心目标：把“线上报名—资格审核—现场签到—活动互动—活动后互选—红娘跟进—安全处置”形成完整闭环

---

# 第一章 设计目标

V1.0活动模块不是普通活动报名工具。

它承担三个核心价值：

1. 给线上匹配提供真实线下见面机会
2. 给公益组织提供可控、可审核的服务载体
3. 给长期线上无结果用户提供新的认识渠道

因此活动模块必须同时兼顾：

- 报名简单
- 资格真实
- 名额可控
- 现场好执行
- 用户隐私
- 双向意愿
- 后续跟进
- 安全处置
- 数据可追踪

---

# 第二章 活动闭环总流程

```text
后台创建活动
↓
发布
↓
用户浏览活动
↓
报名
↓
资格校验
↓
人工审核/自动通过
↓
报名成功
↓
活动提醒
↓
现场签到
↓
参加活动
↓
活动结束
↓
反馈
↓
选择“想进一步了解的人”
↓
双方互选
↓
建立Match
↓
聊天
↓
红娘可继续跟进
```

---

# 第三章 活动模块V1范围

必须支持：

```text
活动创建
活动编辑
活动发布
报名时间
人数限制
男女名额
年龄限制
人工审核
报名结果
活动提醒
签到二维码
现场签到
活动反馈
活动后互选
活动数据统计
活动取消
安全处置
```

暂不支持：

```text
活动收费
在线支付
座位票务
复杂排座
抽奖
积分
礼物
直播
视频连麦
群聊
活动商城
```

---

# 第四章 活动类型

V1建议支持统一业务类型：

```text
public_matchmaking
```

前端可以根据运营文案展示：

- 青年公益相亲会
- 七夕公益相亲活动
- 单身青年联谊会
- 公益交友活动
- 小型主题见面会

不要因为名称不同建立多套技术模型。

---

# 第五章 活动组织主体

每个活动必须明确：

```text
主办单位
承办单位
协办单位（可选）
```

例如：

- 妇联
- 工会
- 公益服务中心
- 志愿者组织

后台必须关联：

> organizer_org_id

避免出现无人负责的活动。

---

# 第六章 活动状态机

统一状态：

```text
draft
registration_open
registration_closed
ongoing
ended
cancelled
```

标准流程：

```text
draft
↓ 发布
registration_open
↓ 报名截止
registration_closed
↓ 活动开始
ongoing
↓ 活动结束
ended
```

取消：

```text
draft / registration_open / registration_closed
↓
cancelled
```

---

# 第七章 Draft草稿状态

草稿：

- 用户不可见
- 可编辑全部活动信息
- 不产生通知
- 不允许报名

后台可以：

> 保存草稿

---

# 第八章 发布前校验

活动从draft发布前必须校验：

```text
活动名称
开始/结束时间
报名开始/截止时间
活动地点
主办单位
活动介绍
参与条件
人数上限
报名审核方式
活动规则
联系方式
```

缺少关键字段：

> 不允许发布。

---

# 第九章 时间合法性

必须满足：

```text
registration_start_at
<
registration_end_at
<=
start_at
<
end_at
```

禁止：

> 活动已经开始但报名截止时间还在未来

除非未来明确支持现场报名。

V1默认不支持。

---

# 第十章 活动参与对象

活动可以配置：

```text
最低年龄
最高年龄
目标性别
区域要求（可选）
```

V1不建议设置过多资格规则。

核心仍然：

> 成年、实名、资料审核通过、账号正常。

---

# 第十一章 法定婚龄与活动年龄

活动可以面向：

> 成年单身人士。

但如果活动文案明确为：

> 婚姻登记、近期结婚等强婚姻导向活动

运营需要注意成年与法定婚龄的区别。

系统年龄配置不能错误地把18岁等同于法定登记结婚资格。

---

# 第十二章 活动详情前台必须展示

用户必须快速看到：

```text
活动名称
公益免费
活动时间
活动地点
主办/承办单位
适合人群
报名时间
活动介绍
活动流程
注意事项
报名状态
```

---

# 第十三章 活动费用

当前公益定位：

> V1默认免费。

前端统一：

```text
公益免费
```

如果未来出现必要的成本分摊：

必须另行做产品和合规设计。

V1不预留支付链路。

---

# 第十四章 活动人数模型

支持：

```text
total_limit
male_limit
female_limit
```

例如：

```text
总人数100
男性50
女性50
```

---

# 第十五章 总人数与性别人数关系

如果同时设置：

```text
male_limit = 50
female_limit = 50
total_limit = 100
```

正常。

如果：

```text
male_limit + female_limit > total_limit
```

后台必须提示配置不一致。

---

# 第十六章 不强制所有活动必须男女1:1

公益活动可能根据实际报名池调整。

因此：

> 男女名额可配置。

不要技术上写死50:50。

---

# 第十七章 活动报名入口

用户：

```text
活动首页
↓
活动详情
↓
立即报名
```

报名页面尽量复用用户已有资料。

避免再次要求：

- 姓名
- 年龄
- 性别
- 身高
- 学历

重复填写。

---

# 第十八章 报名资料复用原则

系统直接读取：

```text
实名认证
手机号
年龄
性别
审核状态
个人资料
```

用户只确认：

> 当前资料是否正确。

---

# 第十九章 活动额外字段

只有活动确实需要，才增加：

```text
紧急联系人
特殊备注
```

紧急联系人是否采集：

> 按活动需要配置，不作为所有活动默认必填项。

---

# 第二十章 报名资格前置检查

用户点击“立即报名”前，服务端检查：

```text
已登录
已绑定手机号
已实名
资料审核通过
账号正常
年龄符合
性别符合
活动报名开放
未重复报名
```

---

# 第二十一章 未审核用户报名

如果用户资料尚未审核通过：

不允许报名。

提示：

> 完成资料审核后即可报名参加公益相亲活动。

按钮：

> 查看审核状态

---

# 第二十二章 账号受限用户报名

如果：

```text
account_status != normal
```

根据RiskAction判断。

严重限制状态：

> 禁止报名。

不要只靠活动前端按钮灰掉。

---

# 第二十三章 活动重复报名

数据库唯一：

```text
activity_id + user_id
```

重复提交：

> 返回原报名结果。

不要创建第二条。

---

# 第二十四章 报名审核模式

活动支持：

```text
need_review = true
```

或：

```text
need_review = false
```

---

# 第二十五章 人工审核模式

报名后：

```text
not_applied
↓
pending
↓
approved / rejected
```

用户页面：

> 报名审核中。

---

# 第二十六章 自动通过模式

如果：

```text
need_review = false
```

且资格满足、名额足够：

```text
not_applied
↓
approved
```

直接报名成功。

---

# 第二十七章 V1建议默认人工审核

对于公益婚恋线下活动，建议默认：

> 人工审核。

原因：

- 男女比例控制
- 风险账号检查
- 活动适配
- 线下安全
- 便于组织

小型简单活动以后可配置自动通过。

---

# 第二十八章 Pending是否占名额

建议V1正式采用：

> **Pending不占正式活动名额。**

只有：

```text
approved
```

才占名额。

---

# 第二十九章 Pending过多问题

可能出现：

```text
剩余10个名额
待审核30人
```

这是允许的。

后台审核时显示：

> 当前剩余名额10。

第11个批准时：

返回：

```text
ACTIVITY_FULL
```

---

# 第三十章 审核排序

后台报名列表建议支持：

```text
报名时间
性别
年龄
审核状态
```

默认：

> 按报名时间排序。

不做：

> 资产/颜值排序。

---

# 第三十一章 活动审核员看到的信息

报名审核必要信息：

- 展示名
- 性别
- 年龄
- 丹阳/所在区域
- 实名状态
- 资料审核状态
- 风险状态摘要

不需要：

- 身份证
- 聊天内容
- 详细择偶条件

---

# 第三十二章 报名审核通过

审核员点击：

> 通过

系统事务内：

```text
检查活动状态
↓
检查剩余总名额
↓
检查性别名额
↓
registration → approved
↓
提交
```

事务后：

> 发通知。

---

# 第三十三章 报名拒绝

必须填写原因。

建议标准原因：

```text
活动名额已满
年龄不符合活动范围
资料需要进一步完善
活动参与条件不符合
安全审核未通过
其他
```

---

# 第三十四章 拒绝原因用户可见

用户看到：

> 具体但不过度暴露内部风控的信息。

例如：

正确：

> 本次活动名额已满。

不建议：

> 系统风险评分达到72分。

---

# 第三十五章 报名结果通知

审核通过：

> 你报名的“丹阳青年公益相亲会”已通过审核。

拒绝：

> 你的活动报名未通过，请查看具体说明。

---

# 第三十六章 报名成功页

显示：

```text
报名成功
活动名称
活动时间
活动地点
注意事项
```

按钮：

> 查看我的活动

---

# 第三十七章 我的活动

分类：

```text
待参加
审核中
已结束
```

状态：

```text
审核中
报名成功
已签到
活动已结束
报名未通过
活动已取消
```

---

# 第三十八章 用户取消报名

V1建议支持：

> 活动开始前主动取消报名。

状态：

```text
approved / pending
↓
cancelled
```

---

# 第三十九章 取消报名截止

活动可配置：

```text
cancel_before
```

例如：

> 活动开始前24小时可自主取消。

如果超过：

> 联系工作人员。

V1具体时长建议配置，不写死。

---

# 第四十章 用户取消后释放名额

如果approved取消：

> 立即释放对应名额。

可以允许后续候选审核通过。

---

# 第四十一章 是否建设候补名单

V1建议：

> 不做复杂自动候补系统。

名额释放后：

后台待审核列表继续审核即可。

如果后续活动规模增大再增加：

> waitlist。

---

# 第四十二章 活动提醒

建议至少：

```text
报名通过时
活动前一天
活动当天适当提前
活动取消/重大变更
```

站内通知优先。

微信订阅消息是否发送：

> 依据用户授权及微信规则。

---

# 第四十三章 活动前一天提醒

示例：

> 你报名的“丹阳青年公益相亲会”将于明天下午2点开始，请提前安排时间。

包含：

- 时间
- 地点
- 查看活动

---

# 第四十四章 活动变更

如果重要字段变更：

```text
时间
地点
```

已经approved的用户：

> 必须收到通知。

---

# 第四十五章 活动重大变更确认

如果活动时间大幅调整：

V1可以先：

> 通知用户。

未来可增加：

> 重新确认参加。

V1不必复杂化。

---

# 第四十六章 活动取消

管理员点击取消：

必须：

- 二次确认
- 填写取消原因
- 写审计
- 更新活动状态
- 通知已报名用户

---

# 第四十七章 活动取消后

```text
activity.status = cancelled
```

所有报名记录：

> 保留。

用户：

> 无法签到。

活动：

> 不允许重新开启。

如果要重新举办：

> 复制创建新活动。

---

# 第四十八章 现场签到设计

用户报名通过后，在活动时间范围内显示：

> 签到二维码。

二维码：

> 动态/短时Token。

---

# 第四十九章 签到二维码不能包含

禁止直接编码：

```text
userId
手机号
身份证
```

正确：

```text
signedCheckinToken
```

---

# 第五十章 签到Token内容逻辑

服务端签名内容可包含：

```text
registration_id
activity_id
nonce
expires_at
```

客户端只拿Token。

---

# 第五十一章 Token有效期

建议：

> 5～15分钟。

过期后用户页面自动刷新新的二维码。

---

# 第五十二章 签到人员权限

活动工作人员需要：

```text
activity.checkin
```

可以扫码。

普通红娘不自动拥有签到权限。

---

# 第五十三章 扫码签到流程

```text
工作人员扫码
↓
POST checkin
↓
服务端验证Token
↓
检查活动
↓
检查registration = approved
↓
检查是否已签到
↓
更新checked_in
↓
返回用户简要信息
```

---

# 第五十四章 签到成功页面

工作人员看到：

```text
签到成功

张先生
36岁
手机号尾号 1234
```

足够识别即可。

---

# 第五十五章 重复签到

重复扫码：

> 不报严重错误。

返回：

```text
已签到
签到时间：13:52
```

---

# 第五十六章 手工签到

二维码异常时，后台可：

```text
姓名/手机号搜索
↓
确认用户
↓
手工签到
```

必须记录：

> 操作员。

---

# 第五十七章 现场签到名单隐私

现场工作人员不应该看到：

- 用户完整婚恋档案
- 择偶要求
- 举报记录
- 身份证

只看签到必要信息。

---

# 第五十八章 活动现场编号机制

建议大型活动为用户生成：

```text
活动编号
```

例如：

```text
M018
F023
```

或者中性：

```text
A018
```

具体展示方式按活动运营决定。

---

# 第五十九章 活动编号的价值

现场可以用编号：

- 互动
- 互选
- 反馈

减少：

> 大声公开真实姓名和手机。

---

# 第六十章 不建议现场挂牌完整姓名

更安全方式：

> 名字/昵称 + 编号

例如：

```text
张先生 A018
```

具体根据活动形式。

---

# 第六十一章 活动现场流程模板

系统可给运营提供标准流程：

```text
13:30 工作人员准备
14:00 签到
14:30 开场说明
14:40 破冰互动
15:10 分组交流
16:00 自由交流
16:30 意向填写
16:45 活动说明
17:00 结束
```

这是运营模板。

V1系统不需要做复杂流程引擎。

---

# 第六十二章 活动规则确认

报名时必须确认：

```text
我已阅读并同意本次活动规则
```

活动规则至少说明：

- 文明交流
- 尊重他人
- 禁止骚扰
- 禁止营销
- 谨慎金钱往来
- 不得偷拍/传播他人隐私
- 服从必要现场管理

---

# 第六十三章 现场安全说明

开场建议工作人员统一说明：

> 尊重个人意愿，任何用户均可拒绝进一步交流。

> 不强制交换手机或微信。

> 活动后请通过平台双向意愿机制继续联系。

---

# 第六十四章 禁止现场强制交换联系方式

运营流程不能设计：

> 每个人必须互加微信。

正确：

> 用户自主决定。

最好通过平台：

> 双向互选。

---

# 第六十五章 活动现场突发投诉

工作人员应有快速入口：

```text
活动管理
↓
现场异常
↓
选择用户
↓
记录情况
```

V1可以复用：

> 风控/举报模块。

---

# 第六十六章 现场风险类型

例如：

```text
骚扰
言语冒犯
疑似营销
疑似虚假身份
疑似醉酒/失控
人身安全风险
其他
```

---

# 第六十七章 现场临时处置

工作人员根据严重程度：

- 提醒
- 劝离
- 暂停活动资格
- 提交平台风控

严重涉及现实安全：

> 按现场应急流程处理。

系统不替代现实报警或应急机制。

---

# 第六十八章 现场异常记录

建议：

```text
activity_incidents
```

记录：

```text
activity_id
user_id
incident_type
description
operator_id
created_at
risk_report_id
```

---

# 第六十九章 是否纳入V1数据库

建议纳入。

因为线下活动是平台重要安全场景。

可将其实现为：

> Risk模块的一种source_type = activity_incident。

这样减少新模块。

---

# 第七十章 活动结束判断

活动结束后：

```text
ongoing
↓
ended
```

可由定时任务自动更新。

管理员也可在特殊情况下提前结束。

---

# 第七十一章 活动结束后的用户入口

“我的活动”中显示：

> 活动反馈

按钮。

---

# 第七十二章 活动反馈内容

V1建议：

```text
活动整体满意度
是否愿意再次参加
有没有想进一步了解的人
意见建议
```

---

# 第七十三章 满意度

可以用：

```text
1～5
```

但前端可用：

```text
很满意
满意
一般
不太满意
不满意
```

避免过度数据化。

---

# 第七十四章 意向选择

活动后提供：

> “今天有没有想进一步了解的人？”

用户可以：

```text
有
没有
```

---

# 第七十五章 选择对象范围

用户只能从：

```text
同一活动
+
符合活动互选规则
+
未拉黑
+
账号正常
```

的人中选择。

不能手工输入任意userId。

---

# 第七十六章 互选名单展示方式

建议展示：

```text
活动编号
展示名
年龄
头像
```

例如：

```text
A018 王女士 32岁
```

帮助用户确认。

---

# 第七十七章 活动后意向隐私

A选择B。

B没有选择A：

> B不知道A选择了自己。

这个规则必须严格执行。

---

# 第七十八章 双向互选

当：

```text
A interested B
AND
B interested A
```

系统：

```text
创建Match
source = activity
↓
创建Conversation
↓
通知双方
```

---

# 第七十九章 活动互选生成Match

活动互选本身已经是：

> 双方明确同意进一步了解。

因此不需要再次点一次Like。

可以直接创建：

> Mutual Match。

---

# 第八十章 活动Match通知

建议：

> 你和王女士在本次活动中互相选择，可以开始进一步了解了。

按钮：

> 开始聊天

---

# 第八十一章 多人意向

用户可以选择几个人？

V1建议：

> **最多3位。**

理由：

- 保留一定自主空间
- 避免变成无限海选
- 方便活动后跟进

此数量建议配置化。

---

# 第八十二章 是否只能选1位

不建议强制1位。

一次线下活动中：

> 用户可能对2～3人有进一步了解意愿。

不等于承诺恋爱。

---

# 第八十三章 意向选择截止时间

建议活动结束后开放：

```text
24～72小时
```

例如默认：

> 48小时。

具体配置。

---

# 第八十四章 为什么需要截止

避免几个月后：

> 突然点击活动互选。

活动互选应该反映：

> 当次活动后的近期意愿。

---

# 第八十五章 截止后

不能再修改。

或者：

> 只允许在截止前修改。

截止时系统最终计算双方意向。

---

# 第八十六章 互选结果通知时间

建议：

> 用户提交后可以实时检查双向。

但如果担心“谁先选谁”产生压力：

V1更推荐：

> 截止后统一或双方完成后通知。

技术上只暴露：

> 双向成功。

绝不暴露单向。

---

# 第八十七章 活动后红娘跟进

对于：

- 双向互选
- 用户主动申请
- 长期无结果

公益红娘可以继续服务。

---

# 第八十八章 双向互选后的红娘

默认：

> 不主动介入私人聊天。

可以在后续轻提示：

> 如果需要公益红娘协助，可以申请帮助。

---

# 第八十九章 无互选结果用户

不要显示：

> “你没有被任何人选择。”

这种文案容易造成负面体验。

正确：

> 本次暂未形成双方共同意向。

可以：

> 查看新的推荐 / 申请公益红娘帮助。

---

# 第九十章 无意向用户

用户自己选择：

> 没有想进一步了解的人。

系统不再要求其继续选择。

活动反馈仍正常保存。

---

# 第九十一章 活动后单向意向数据

后台是否能看到？

建议：

> 运营普通人员只看聚合数据。

例如：

```text
提交意向人数
双向互选数量
```

不要默认给普通运营看：

> A单选B但B没选A。

---

# 第九十二章 红娘是否能看单向意向

默认：

> 不看。

除非用户主动申请：

> “请红娘帮我联系活动中某位对象”。

此时只处理该用户授权的具体意向。

---

# 第九十三章 现场交换联系方式后的平台边界

用户现实现场自行交换：

> 平台无法完全禁止。

但活动规则应强调：

> 自主、自愿、谨慎。

平台仍建议：

> 优先通过双向互选+平台聊天继续了解。

---

# 第九十四章 活动参与记录隐私

其他普通用户不能查看：

> 某人参加过哪些公益相亲活动。

这属于私人服务记录。

---

# 第九十五章 用户自己可查看

“我的活动”：

> 可以查看自己的历史。

---

# 第九十六章 红娘可查看活动记录边界

服务用户时：

红娘可以看到必要摘要：

```text
近期参加2次活动
暂无双向互选
```

不必显示所有详细反馈。

---

# 第九十七章 活动数据统计

后台建议：

```text
报名人数
审核通过人数
实际签到人数
签到率
男女比例
年龄分布
反馈提交人数
意向提交人数
双向互选数
活动来源Match数
```

---

# 第九十八章 活动核心漏斗

```text
活动曝光
↓
查看详情
↓
报名
↓
审核通过
↓
签到
↓
反馈
↓
意向
↓
双向互选
↓
聊天
```

---

# 第九十九章 不用“牵手率”包装单次活动

双向互选：

> 只是愿意进一步了解。

不能宣传成：

> 成功牵手。

真正成功牵手仍走后续双方确认。

---

# 第一百章 活动成功指标

短期：

```text
报名率
到场率
反馈率
双向互选率
```

中期：

```text
活动来源聊天启动率
正在了解人数
```

长期：

```text
活动来源成功牵手数
```

---

# 第一百零一章 到场率

```text
签到人数
/
审核通过人数
```

用于活动运营改进。

---

# 第一百零二章 男女比例

用于：

> 下一场活动招募调整。

不能用于：

> 对不同性别收费。

当前V1永久免费。

---

# 第一百零三章 年龄分布

可以按段：

```text
18～24
25～29
30～34
35～39
40～49
50+
```

后台统计。

具体活动文案应避免让用户形成等级感。

---

# 第一百零四章 活动取消率

如果某用户多次报名不来：

是否处罚？

V1建议：

> 只做轻量运营提示。

不要直接封号。

---

# 第一百零五章 多次无故缺席

可以形成：

```text
activity_no_show_count
```

作为活动管理参考。

未来可：

> 限制高需求活动报名。

但V1不建议自动严厉处罚。

---

# 第一百零六章 No-show与风控分离

没来活动：

> 不等于风险用户。

只是：

> 活动运营行为。

不要加入诈骗风险分。

---

# 第一百零七章 活动候补运营

V1人工处理：

> 有名额释放后继续审核待审核用户。

无需自动候补通知系统。

---

# 第一百零八章 活动创建权限

权限：

```text
activity.create
```

活动编辑：

```text
activity.edit
```

活动发布：

```text
activity.publish
```

报名审核：

```text
activity.registration.review
```

签到：

```text
activity.checkin
```

---

# 第一百零九章 活动取消权限

建议单独：

```text
activity.cancel
```

因为影响较大。

必须审计。

---

# 第一百一十章 活动角色分工

建议：

### 活动管理员

创建、报名审核、数据管理。

### 现场工作人员

签到、现场异常记录。

### 公益红娘

必要时现场/后续婚恋服务。

三个角色权限不要自动混为一体。

---

# 第一百一十一章 活动现场工作人员临时账号

如果使用志愿者：

建议：

> 创建独立低权限账号。

不要把管理员密码告诉志愿者。

---

# 第一百一十二章 临时账号有效期

可以设置：

```text
活动当天有效
```

活动结束后自动停用或人工停用。

---

# 第一百一十三章 活动人员数据权限

现场志愿者只能查看：

```text
报名名单必要字段
签到状态
活动编号
```

不能进入：

> 用户管理后台。

---

# 第一百一十四章 活动现场网络异常

必须有降级方案。

如果现场网络差：

后台可以：

> 搜索报名名单后手工签到。

如果完全离线：

V1可准备：

> 最小脱敏纸质/离线名单作为应急。

---

# 第一百一十五章 应急名单原则

只包含：

```text
活动编号
展示名
手机号后四位
```

必要时：

> 性别/年龄。

不能打印身份证。

活动结束：

> 按内部规则销毁。

---

# 第一百一十六章 现场二维码设备要求

工作人员可以使用：

> 手机Web后台/微信扫码工作页面。

不需要专用硬件。

降低活动执行成本。

---

# 第一百一十七章 活动签到统计实时显示

后台：

```text
应到 96
已到 83
未到 13
```

支持工作人员掌握现场情况。

---

# 第一百一十八章 男女签到实时数

可以显示：

```text
男性已到 41/48
女性已到 42/48
```

用于现场组织。

---

# 第一百一十九章 活动开始后迟到

只要活动仍允许签到：

> 可以签到。

建议配置：

```text
checkin_end_at
```

V1可默认：

> 活动结束前。

---

# 第一百二十章 提前签到

可配置：

例如：

> 活动开始前60分钟允许签到。

服务端判断。

---

# 第一百二十一章 签到范围

V1不做GPS围栏。

原因：

- 不必要定位
- 隐私增加
- 现场工作人员扫码已足够

---

# 第一百二十二章 活动地址导航

可以使用：

> 用户主动打开地图。

如果接地图服务：

> 仅用于显示活动地点。

不持续采集用户位置。

---

# 第一百二十三章 活动现场照片

活动组织方可能拍摄活动照片。

这和用户婚恋资料照片不是同一用途。

必须在活动规则中：

> 明确告知是否拍摄和可能用途。

---

# 第一百二十四章 宣传照片默认原则

不要默认：

> 用户参加活动就授权公开宣传。

如果需要公开个人可识别照片：

> 应取得相应授权。

---

# 第一百二十五章 不愿出镜

活动流程应允许：

> 用户表达不愿用于公开宣传。

运营现场做好标识/区域管理。

系统可后续增加：

```text
photo_publicity_consent
```

V1如实际有宣传拍摄需求建议纳入报名确认。

---

# 第一百二十六章 活动反馈匿名性

对活动满意度：

> 运营统计可匿名汇总。

工作人员不必默认看到：

> 某用户给了2分。

涉及具体投诉：

> 再进入反馈/举报处理。

---

# 第一百二十七章 普通意见与安全举报分离

反馈：

> 活动流程不好。

举报：

> 某用户骚扰我。

两个入口不同。

安全问题必须进入：

> Risk流程。

---

# 第一百二十八章 红娘现场服务

活动现场可有：

> 公益红娘咨询台。

用户自愿咨询：

- 择偶条件
- 活动对象
- 后续服务

红娘不应：

> 公开点评某用户条件。

---

# 第一百二十九章 红娘现场跟进记录

如果形成正式服务：

> 创建MatchmakerService。

不要用纸质笔记长期保存敏感婚恋资料。

---

# 第一百三十章 活动与推荐系统协同

活动报名数据不直接提高用户匹配分。

但活动后：

> 双向互选

是明确关系信号。

---

# 第一百三十一章 不因“经常参加活动”提高质量分

活动活跃度：

> 不等于更优质。

所以不进入基础MutualScore。

---

# 第一百三十二章 活动对象展示算法

活动后互选列表：

不需要再按全平台算法强排序。

可以：

- 按活动编号
- 按用户互动记录（如果未来有）
- 基础推荐程度轻量排序

V1建议：

> 简单、可识别优先。

---

# 第一百三十三章 是否现场提前推荐座位对象

V1不做复杂智能排桌。

如果运营需要：

> 人工分组。

未来再增加：

> 系统辅助分组。

---

# 第一百三十四章 为什么V1不做智能排桌

需要考虑：

- 性别
- 年龄
- 条件
- 座位
- 轮换
- 现场临时缺席

复杂度很高。

V1核心先验证：

> 活动报名与互选闭环。

---

# 第一百三十五章 活动用户状态变更

如果用户报名后：

> 账号被封禁。

系统：

- 活动报名资格失效
- 通知活动管理员
- registration可变为cancelled_by_platform或内部状态

---

# 第一百三十六章 是否新增cancelled_by_platform

建议Registration状态扩展：

```text
pending
approved
rejected
cancelled
cancelled_by_platform
```

便于区分：

> 用户自己取消

和：

> 平台安全原因取消。

---

# 第一百三十七章 用户隐私说明

因安全原因取消活动资格：

前台只展示：

> 当前报名资格已取消，请查看账号状态或联系工作人员。

不要暴露内部Risk详情。

---

# 第一百三十八章 活动开始前资料变化

例如用户婚姻状态发生重要变化并进入重新审核。

如果活动已approved：

建议：

> 暂停其活动资格，等待审核。

活动管理员收到：

> 资格状态变化提醒。

---

# 第一百三十九章 用户注销

如果未开始活动已报名：

根据之前规则：

> 自动取消报名并释放名额。

---

# 第一百四十章 活动数据表补充建议

在前面数据库基础上建议增加：

```text
activity_rules_version
activity_checkin_config
activity_interest_config
activity_incidents
```

但V1可简化为activities中的配置字段+RiskEvent。

---

# 第一百四十一章 建议新增字段

activities可增加：

```text
cancel_deadline_at
checkin_start_at
checkin_end_at
interest_submit_deadline_at
max_interest_selections
```

---

# 第一百四十二章 Registration可增加

```text
cancelled_at
cancel_reason
cancel_source
```

cancel_source：

```text
user
admin
risk
system
```

---

# 第一百四十三章 ActivityFeedback扩展

建议：

```text
satisfaction
join_again
comment
submitted_at
```

意向最好不要只放单个：

```text
interested_user_id
```

因为已经建议最多3人。

---

# 第一百四十四章 活动意向数据模型修正

建议单独表：

```text
activity_interests
```

字段：

```text
id
activity_id
user_id
target_user_id
created_at
```

唯一：

```text
activity_id + user_id + target_user_id
```

---

# 第一百四十五章 为什么单独表更合理

因为一个用户可能选择：

> 最多3人。

原先activity_feedback中的单个interested_user_id：

> 无法满足。

因此V1数据库设计后续实现时应采用：

```text
activity_feedback
+
activity_interests
```

---

# 第一百四十六章 activity_interests安全约束

必须：

```text
user_id != target_user_id
```

并且双方：

> 都是该活动合法参与者。

---

# 第一百四十七章 双向互选查询

判断：

```text
A → B exists
AND
B → A exists
```

则：

> Mutual Activity Interest。

使用唯一Match创建逻辑。

---

# 第一百四十八章 活动来源Match去重

如果A、B本来已经有active Match：

活动互选：

> 不创建第二个Match。

只记录：

> activity mutual interest。

---

# 第一百四十九章 已有Match用户活动互选

系统可以提示：

> 你们已经互相喜欢，可以继续在聊天中了解。

无需重复通知过多。

---

# 第一百五十章 已Unmatch的双方活动再次互选

是否允许重新建立Match？

V1建议：

> 可以，但需要明确作为新的双方意愿。

因为线下再次见面后：

> 双方都重新选择对方。

数据库原matches设计若一pair只一条：

可将：

```text
unmatched → active
```

但必须：

- 记录reactivated_at
- 保留历史

更推荐未来有MatchHistory。

V1可以先采用：

> 重新激活原Match + Audit/Event。

---

# 第一百五十一章 Block仍然最高优先级

如果双方活动互选但存在：

> 任一方Block。

系统：

> 不建立Match。

理论上被Block方也不应该出现在互选名单。

---

# 第一百五十二章 活动结束后数据同步

需要更新：

- 活动状态
- 我的活动
- 反馈入口
- 互选入口
- 统计
- 红娘服务提示

---

# 第一百五十三章 活动日报/复盘

活动结束后后台可生成简单汇总：

```text
报名 108
通过 96
签到 87
到场率 90.6%
提交反馈 72
提交意向 46
双向互选 11对
```

---

# 第一百五十四章 不自动生成宣传口径

这些内部数据不能直接变成：

> “牵手成功11对”。

正确：

> 形成11组双方进一步了解意向。

---

# 第一百五十五章 活动复盘备注

管理员可以填写：

```text
现场情况
问题
下次改进
```

用于公益组织内部运营。

---

# 第一百五十六章 是否需要活动模板

V1技术上可以提供：

> 复制活动。

不建设复杂模板中心。

例如：

> 复制上一场活动 → 修改日期地点。

---

# 第一百五十七章 活动复制

复制：

- 活动介绍
- 人数配置
- 规则
- 年龄范围

不复制：

- 报名人员
- 签到
- 反馈
- 互选

---

# 第一百五十八章 后台活动操作审计

必须记录：

```text
创建
修改
发布
取消
审核报名
手工签到
修改关键时间
```

---

# 第一百五十九章 活动安全日志

需要重点记录：

- 被风险取消资格
- 现场异常
- 举报
- 劝离
- 紧急情况

---

# 第一百六十章 活动管理员不能处理平台级封禁

活动管理员可以：

> 提交风险事件。

真正封禁：

> 由风控权限角色处理。

避免现场人员权限过大。

---

# 第一百六十一章 现场紧急联系人

如果实际活动确实需要：

> 可在该活动报名中收集。

使用目的：

> 现场紧急情况。

不能：

> 以后拿来营销或红娘联系。

---

# 第一百六十二章 紧急联系人数据生命周期

活动结束且安全处理需求结束后：

> 应按数据保留策略及时清理。

不应永久留在用户婚恋档案。

---

# 第一百六十三章 紧急联系人不是用户Profile字段

不要写入：

```text
user_profiles
```

应属于：

> activity_registration scoped data。

---

# 第一百六十四章 活动报名协议版本

建议记录：

```text
activity_rule_version
agreed_at
```

如果不同活动规则不同：

> 方便追溯。

---

# 第一百六十五章 活动规则变更

已报名后若重大修改规则：

> 需要重新通知。

是否要求重新确认：

> 视变更重要程度。

---

# 第一百六十六章 活动数据权限矩阵

| 数据 | 用户本人 | 红娘 | 活动管理员 | 签到志愿者 | 风控 |
|---|---:|---:|---:|---:|---:|
| 自己报名 | 是 | 必要时 | 是 | 简要 | 必要时 |
| 报名名单 | 否 | 否/有限 | 是 | 简要 | 必要时 |
| 身份证 | 否 | 否 | 否 | 否 | 特殊权限 |
| 签到状态 | 自己 | 有限 | 是 | 是 | 必要时 |
| 活动反馈 | 自己 | 默认否 | 聚合/必要 | 否 | 必要时 |
| 单向意向 | 自己 | 默认否 | 默认否 | 否 | 必要时 |
| 双向互选 | 自己 | 服务必要 | 聚合 | 否 | 必要时 |

---

# 第一百六十七章 活动前端P0页面

```text
活动首页
活动详情
报名确认
报名成功
我的活动
签到二维码
活动反馈
活动互选
互选成功
```

---

# 第一百六十八章 后台P0页面

```text
活动列表
创建/编辑活动
报名管理
报名审核
签到管理
活动数据
现场异常
```

---

# 第一百六十九章 活动详情按钮状态

```text
registration_open + not_applied
→ 立即报名

pending
→ 报名审核中

approved
→ 报名成功

rejected
→ 查看原因

full
→ 报名已满

registration_closed
→ 报名已结束

cancelled
→ 活动已取消
```

---

# 第一百七十章 活动结束按钮

如果用户已签到：

```text
填写活动反馈
```

如果已反馈且互选期开放：

```text
查看/修改我的意向
```

---

# 第一百七十一章 活动反馈不强制

用户不填写：

> 不影响账号。

不要为了数据完整性强制。

---

# 第一百七十二章 用户互选也不强制

用户可以：

> 没有想进一步了解的人。

系统必须尊重。

---

# 第一百七十三章 互选成功页面

```text
♥

你们在本次活动中互相选择

[张先生头像] [王女士头像]

可以开始进一步了解了

[开始聊天]

稍后再聊
```

与线上Mutual Match视觉保持一致。

---

# 第一百七十四章 活动后无结果页面

推荐：

```text
感谢你的参与

本次暂未形成双方共同意向。

可以继续查看平台推荐，
或申请公益红娘帮助。

[看看新的推荐]
[申请红娘帮助]
```

---

# 第一百七十五章 不显示“没人选你”

这是明确UX红线。

---

# 第一百七十六章 活动运营不做竞争排名

不展示：

- 最受欢迎男嘉宾
- 最受欢迎女嘉宾
- 收到多少选择
- 人气榜
- 心动榜

保持公益、尊重、非娱乐化。

---

# 第一百七十七章 活动现场不做“公开表白墙”

V1不建议。

避免：

- 隐私暴露
- 尴尬
- 社交压力

---

# 第一百七十八章 活动数据也不做个人受欢迎度

后台不需要：

```text
某人被选择8次
```

作为“高价值用户”指标。

只在必要的互选计算中使用单向记录。

---

# 第一百七十九章 活动质量评价

更适合关注：

```text
到场率
用户满意度
双向互选率
后续聊天率
安全事件数
```

---

# 第一百八十章 活动风控指标

后台：

```text
活动举报数
现场异常数
被劝离人数
高风险报名拦截数
```

---

# 第一百八十一章 活动异常率

如果某场活动：

> 举报明显较多。

运营需要复盘：

- 场地管理
- 参与人筛选
- 活动流程
- 工作人员配置

---

# 第一百八十二章 线下安全应急联系人

每场活动后台建议配置：

```text
活动负责人
联系电话
现场安全负责人
```

用户详情中可显示：

> 活动联系电话。

---

# 第一百八十三章 不在公开活动页展示工作人员私人手机号

如可行：

> 使用工作号码。

若只能使用个人手机号：

也应评估是否需要全部公开。

---

# 第一百八十四章 V1活动服务闭环最终架构

```text
线上用户
  │
  ↓
Activity Browse
  │
  ↓
Registration
  │
  ↓
Eligibility Check
  │
  ↓
Manual Review
  │
  ↓
Approved
  │
  ↓
Reminder
  │
  ↓
QR Check-in
  │
  ↓
Offline Event
  │
  ├── Risk Incident → Risk Service
  │
  ↓
Feedback
  │
  ↓
Activity Interest
  │
  ↓
Mutual?
  ├── No → 继续推荐/红娘
  │
  └── Yes
        ↓
       Match
        ↓
   Conversation
        ↓
   Getting to Know
```

---

# 第一百八十五章 开发优先级

## P0

```text
Activity CRUD
发布/取消
报名
资格检查
人工审核
人数控制
我的活动
二维码签到
后台签到
活动反馈
```

---

## P1

```text
活动互选
activity_interests
双向互选生成Match
活动提醒
现场异常关联Risk
用户取消报名
```

---

## P2

```text
活动复盘
更完善统计
复制活动
临时工作人员账号
更多运营配置
```

注意：

活动互选属于V1完整闭环的重要模块，虽然排在实现P1，但必须在V1正式上线范围内完成。

---

# 第一百八十六章 并发测试

必须测试：

1. 多人同时抢最后名额
2. 两个审核员同时批准最后名额
3. 用户重复报名
4. 用户取消与管理员批准同时发生
5. 重复扫码签到
6. A、B同时互选
7. Activity刚取消用户同时报名

---

# 第一百八十七章 权限测试

必须测试：

- 志愿者查看完整用户资料
- 活动管理员查看聊天
- 红娘直接批准活动报名
- 无权限人员取消活动
- 普通用户访问他人签到Token
- 用户修改activityId查看他人报名

必须全部正确拒绝。

---

# 第一百八十八章 隐私测试

必须确认：

- 用户看不到他人报名信息
- 用户看不到单向意向
- 运营人员默认看不到单向意向详情
- 签到人员看不到身份证
- 紧急联系人不会进入普通Profile
- 已注销用户不继续公开活动资料

---

# 第一百八十九章 活动业务验收场景一

活动：

```text
男50
女50
```

当前：

```text
男49
女40
```

再批准一名男性：

> 成功。

再批准下一名男性：

> GENDER_QUOTA_FULL。

即使总人数仍未到100。

---

# 第一百九十章 活动业务验收场景二

用户32岁，活动范围：

```text
25～30
```

报名：

> AGE_NOT_ELIGIBLE。

年龄由实名认证birth_date计算。

---

# 第一百九十一章 活动业务验收场景三

用户报名pending。

期间活动取消。

审核员再点击通过：

> ACTIVITY_NOT_OPEN。

---

# 第一百九十二章 活动业务验收场景四

A选择B。

B没选A。

最终：

> 不建立Match。

B：

> 不知道A单向选择。

---

# 第一百九十三章 活动业务验收场景五

A选择B。

B选择A。

双方：

> 自动形成activity来源Match。

聊天立即可用。

---

# 第一百九十四章 活动业务验收场景六

A已Block B。

即使由于旧缓存A的互选页面出现B：

提交时服务端：

> 拒绝该意向。

并刷新名单。

---

# 第一百九十五章 活动业务验收场景七

活动用户发生严重骚扰。

现场工作人员：

> 提交风险事件。

风控员：

> 处理账号。

账号限制实时影响：

- 活动资格
- 匹配
- 聊天

---

# 第一百九十六章 线下服务核心原则

V1.0必须坚持：

> **活动不是单纯把人拉到现场。**

> **报名必须有资格审核。**

> **现场只使用完成任务必要的信息。**

> **不强迫用户交换联系方式。**

> **活动后的意向必须双向。**

> **单向选择必须保密。**

> **互选只是进一步了解，不等于成功牵手。**

> **现场风险能够直接进入平台风控闭环。**

> **公益红娘可以继续服务，但不干预私人沟通。**

---

# 第一百九十七章 最终设计原则

整个公益相亲活动闭环最终要达到：

> **线上先把身份和资格做好，线下把见面和体验做好，活动后把双方意愿保护好，再把真正互相愿意的人自然接回平台继续沟通。**

最终形成：

> **线上筛选 → 公益活动见面 → 双向互选 → 平台沟通 → 公益红娘辅助 → 成功牵手**

这才是本平台区别于单纯“线上刷对象”和单纯“线下办相亲会”的核心服务闭环。