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

丹阳公益婚恋服务平台

V1.0 公益相亲活动与线下服务闭环详细设计

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

---

第一章 设计目标

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

它承担三个核心价值：

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

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

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

---

第二章 活动闭环总流程

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

---

第三章 活动模块V1范围

必须支持：

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

暂不支持：

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

---

第四章 活动类型

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

public_matchmaking

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

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

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

---

第五章 活动组织主体

每个活动必须明确：

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

例如：

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

后台必须关联：

organizer_org_id

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

---

第六章 活动状态机

统一状态：

draft
registration_open
registration_closed
ongoing
ended
cancelled

标准流程：

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

取消：

draft / registration_open / registration_closed
↓
cancelled

---

第七章 Draft草稿状态

草稿：

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

后台可以：

保存草稿

---

第八章 发布前校验

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

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

缺少关键字段：

不允许发布。

---

第九章 时间合法性

必须满足：

registration_start_at
<
registration_end_at
<=
start_at
<
end_at

禁止：

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

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

V1默认不支持。

---

第十章 活动参与对象

活动可以配置：

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

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

核心仍然：

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

---

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

活动可以面向：

成年单身人士。

但如果活动文案明确为：

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

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

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

---

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

用户必须快速看到：

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

---

第十三章 活动费用

当前公益定位：

V1默认免费。

前端统一：

公益免费

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

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

V1不预留支付链路。

---

第十四章 活动人数模型

支持：

total_limit
male_limit
female_limit

例如：

总人数100
男性50
女性50

---

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

如果同时设置：

male_limit = 50
female_limit = 50
total_limit = 100

正常。

如果：

male_limit + female_limit > total_limit

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

---

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

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

因此：

男女名额可配置。

不要技术上写死50:50。

---

第十七章 活动报名入口

用户：

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

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

避免再次要求：

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

重复填写。

---

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

系统直接读取：

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

用户只确认：

当前资料是否正确。

---

第十九章 活动额外字段

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

紧急联系人
特殊备注

紧急联系人是否采集：

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

---

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

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

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

---

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

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

不允许报名。

提示：

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

按钮：

查看审核状态

---

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

如果：

account_status != normal

根据RiskAction判断。

严重限制状态：

禁止报名。

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

---

第二十三章 活动重复报名

数据库唯一：

activity_id + user_id

重复提交：

返回原报名结果。

不要创建第二条。

---

第二十四章 报名审核模式

活动支持：

need_review = true

或：

need_review = false

---

第二十五章 人工审核模式

报名后：

not_applied
↓
pending
↓
approved / rejected

用户页面：

报名审核中。

---

第二十六章 自动通过模式

如果：

need_review = false

且资格满足、名额足够：

not_applied
↓
approved

直接报名成功。

---

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

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

人工审核。

原因：

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

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

---

第二十八章 Pending是否占名额

建议V1正式采用：

Pending不占正式活动名额。

只有：

approved

才占名额。

---

第二十九章 Pending过多问题

可能出现：

剩余10个名额
待审核30人

这是允许的。

后台审核时显示：

当前剩余名额10。

第11个批准时：

返回：

ACTIVITY_FULL

---

第三十章 审核排序

后台报名列表建议支持：

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

默认：

按报名时间排序。

不做：

资产/颜值排序。

---

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

报名审核必要信息：

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

不需要：

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

---

第三十二章 报名审核通过

审核员点击：

通过

系统事务内：

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

事务后：

发通知。

---

第三十三章 报名拒绝

必须填写原因。

建议标准原因：

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

---

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

用户看到：

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

例如：

正确：

本次活动名额已满。

不建议：

系统风险评分达到72分。

---

第三十五章 报名结果通知

审核通过：

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

拒绝：

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

---

第三十六章 报名成功页

显示：

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

按钮：

查看我的活动

---

第三十七章 我的活动

分类：

待参加
审核中
已结束

状态：

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

---

第三十八章 用户取消报名

V1建议支持：

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

状态：

approved / pending
↓
cancelled

---

第三十九章 取消报名截止

活动可配置：

cancel_before

例如：

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

如果超过：

联系工作人员。

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

---

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

如果approved取消：

立即释放对应名额。

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

---

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

V1建议：

不做复杂自动候补系统。

名额释放后：

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

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

waitlist。

---

第四十二章 活动提醒

建议至少：

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

站内通知优先。

微信订阅消息是否发送：

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

---

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

示例：

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

包含：

• 时间
• 地点
• 查看活动

---

第四十四章 活动变更

如果重要字段变更：

时间
地点

已经approved的用户：

必须收到通知。

---

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

如果活动时间大幅调整：

V1可以先：

通知用户。

未来可增加：

重新确认参加。

V1不必复杂化。

---

第四十六章 活动取消

管理员点击取消：

必须：

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

---

第四十七章 活动取消后

activity.status = cancelled

所有报名记录：

保留。

用户：

无法签到。

活动：

不允许重新开启。

如果要重新举办：

复制创建新活动。

---

第四十八章 现场签到设计

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

签到二维码。

二维码：

动态/短时Token。

---

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

禁止直接编码：

userId
手机号
身份证

正确：

signedCheckinToken

---

第五十章 签到Token内容逻辑

服务端签名内容可包含：

registration_id
activity_id
nonce
expires_at

客户端只拿Token。

---

第五十一章 Token有效期

建议：

5～15分钟。

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

---

第五十二章 签到人员权限

活动工作人员需要：

activity.checkin

可以扫码。

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

---

第五十三章 扫码签到流程

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

---

第五十四章 签到成功页面

工作人员看到：

签到成功

张先生
36岁
手机号尾号 1234

足够识别即可。

---

第五十五章 重复签到

重复扫码：

不报严重错误。

返回：

已签到
签到时间：13:52

---

第五十六章 手工签到

二维码异常时，后台可：

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

必须记录：

操作员。

---

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

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

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

只看签到必要信息。

---

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

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

活动编号

例如：

M018
F023

或者中性：

A018

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

---

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

现场可以用编号：

• 互动
• 互选
• 反馈

减少：

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

---

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

更安全方式：

名字/昵称 + 编号

例如：

张先生 A018

具体根据活动形式。

---

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

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

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

这是运营模板。

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

---

第六十二章 活动规则确认

报名时必须确认：

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

活动规则至少说明：

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

---

第六十三章 现场安全说明

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

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

不强制交换手机或微信。

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

---

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

运营流程不能设计：

每个人必须互加微信。

正确：

用户自主决定。

最好通过平台：

双向互选。

---

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

工作人员应有快速入口：

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

V1可以复用：

风控/举报模块。

---

第六十六章 现场风险类型

例如：

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

---

第六十七章 现场临时处置

工作人员根据严重程度：

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

严重涉及现实安全：

按现场应急流程处理。

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

---

第六十八章 现场异常记录

建议：

activity_incidents

记录：

activity_id
user_id
incident_type
description
operator_id
created_at
risk_report_id

---

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

建议纳入。

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

可将其实现为：

Risk模块的一种source_type = activity_incident。

这样减少新模块。

---

第七十章 活动结束判断

活动结束后：

ongoing
↓
ended

可由定时任务自动更新。

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

---

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

“我的活动”中显示：

活动反馈

按钮。

---

第七十二章 活动反馈内容

V1建议：

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

---

第七十三章 满意度

可以用：

1～5

但前端可用：

很满意
满意
一般
不太满意
不满意

避免过度数据化。

---

第七十四章 意向选择

活动后提供：

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

用户可以：

有
没有

---

第七十五章 选择对象范围

用户只能从：

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

的人中选择。

不能手工输入任意userId。

---

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

建议展示：

活动编号
展示名
年龄
头像

例如：

A018 王女士 32岁

帮助用户确认。

---

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

A选择B。

B没有选择A：

B不知道A选择了自己。

这个规则必须严格执行。

---

第七十八章 双向互选

当：

A interested B
AND
B interested A

系统：

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

---

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

活动互选本身已经是：

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

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

可以直接创建：

Mutual Match。

---

第八十章 活动Match通知

建议：

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

按钮：

开始聊天

---

第八十一章 多人意向

用户可以选择几个人？

V1建议：

最多3位。

理由：

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

此数量建议配置化。

---

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

不建议强制1位。

一次线下活动中：

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

不等于承诺恋爱。

---

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

建议活动结束后开放：

24～72小时

例如默认：

48小时。

具体配置。

---

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

避免几个月后：

突然点击活动互选。

活动互选应该反映：

当次活动后的近期意愿。

---

第八十五章 截止后

不能再修改。

或者：

只允许在截止前修改。

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

---

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

建议：

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

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

V1更推荐：

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

技术上只暴露：

双向成功。

绝不暴露单向。

---

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

对于：

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

公益红娘可以继续服务。

---

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

默认：

不主动介入私人聊天。

可以在后续轻提示：

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

---

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

不要显示：

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

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

正确：

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

可以：

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

---

第九十章 无意向用户

用户自己选择：

没有想进一步了解的人。

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

活动反馈仍正常保存。

---

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

后台是否能看到？

建议：

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

例如：

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

不要默认给普通运营看：

A单选B但B没选A。

---

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

默认：

不看。

除非用户主动申请：

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

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

---

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

用户现实现场自行交换：

平台无法完全禁止。

但活动规则应强调：

自主、自愿、谨慎。

平台仍建议：

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

---

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

其他普通用户不能查看：

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

这属于私人服务记录。

---

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

“我的活动”：

可以查看自己的历史。

---

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

服务用户时：

红娘可以看到必要摘要：

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

不必显示所有详细反馈。

---

第九十七章 活动数据统计

后台建议：

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

---

第九十八章 活动核心漏斗

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

---

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

双向互选：

只是愿意进一步了解。

不能宣传成：

成功牵手。

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

---

第一百章 活动成功指标

短期：

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

中期：

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

长期：

活动来源成功牵手数

---

第一百零一章 到场率

签到人数
/
审核通过人数

用于活动运营改进。

---

第一百零二章 男女比例

用于：

下一场活动招募调整。

不能用于：

对不同性别收费。

当前V1永久免费。

---

第一百零三章 年龄分布

可以按段：

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

后台统计。

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

---

第一百零四章 活动取消率

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

是否处罚？

V1建议：

只做轻量运营提示。

不要直接封号。

---

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

可以形成：

activity_no_show_count

作为活动管理参考。

未来可：

限制高需求活动报名。

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

---

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

没来活动：

不等于风险用户。

只是：

活动运营行为。

不要加入诈骗风险分。

---

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

V1人工处理：

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

无需自动候补通知系统。

---

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

权限：

activity.create

活动编辑：

activity.edit

活动发布：

activity.publish

报名审核：

activity.registration.review

签到：

activity.checkin

---

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

建议单独：

activity.cancel

因为影响较大。

必须审计。

---

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

建议：

活动管理员

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

现场工作人员

签到、现场异常记录。

公益红娘

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

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

---

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

如果使用志愿者：

建议：

创建独立低权限账号。

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

---

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

可以设置：

活动当天有效

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

---

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

现场志愿者只能查看：

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

不能进入：

用户管理后台。

---

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

必须有降级方案。

如果现场网络差：

后台可以：

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

如果完全离线：

V1可准备：

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

---

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

只包含：

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

必要时：

性别/年龄。

不能打印身份证。

活动结束：

按内部规则销毁。

---

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

工作人员可以使用：

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

不需要专用硬件。

降低活动执行成本。

---

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

后台：

应到 96
已到 83
未到 13

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

---

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

可以显示：

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

用于现场组织。

---

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

只要活动仍允许签到：

可以签到。

建议配置：

checkin_end_at

V1可默认：

活动结束前。

---

第一百二十章 提前签到

可配置：

例如：

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

服务端判断。

---

第一百二十一章 签到范围

V1不做GPS围栏。

原因：

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

---

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

可以使用：

用户主动打开地图。

如果接地图服务：

仅用于显示活动地点。

不持续采集用户位置。

---

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

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

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

必须在活动规则中：

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

---

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

不要默认：

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

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

应取得相应授权。

---

第一百二十五章 不愿出镜

活动流程应允许：

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

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

系统可后续增加：

photo_publicity_consent

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

---

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

对活动满意度：

运营统计可匿名汇总。

工作人员不必默认看到：

某用户给了2分。

涉及具体投诉：

再进入反馈/举报处理。

---

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

反馈：

活动流程不好。

举报：

某用户骚扰我。

两个入口不同。

安全问题必须进入：

Risk流程。

---

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

活动现场可有：

公益红娘咨询台。

用户自愿咨询：

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

红娘不应：

公开点评某用户条件。

---

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

如果形成正式服务：

创建MatchmakerService。

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

---

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

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

但活动后：

双向互选

是明确关系信号。

---

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

活动活跃度：

不等于更优质。

所以不进入基础MutualScore。

---

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

活动后互选列表：

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

可以：

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

V1建议：

简单、可识别优先。

---

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

V1不做复杂智能排桌。

如果运营需要：

人工分组。

未来再增加：

系统辅助分组。

---

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

需要考虑：

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

复杂度很高。

V1核心先验证：

活动报名与互选闭环。

---

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

如果用户报名后：

账号被封禁。

系统：

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

---

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

建议Registration状态扩展：

pending
approved
rejected
cancelled
cancelled_by_platform

便于区分：

用户自己取消

和：

平台安全原因取消。

---

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

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

前台只展示：

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

不要暴露内部Risk详情。

---

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

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

如果活动已approved：

建议：

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

活动管理员收到：

资格状态变化提醒。

---

第一百三十九章 用户注销

如果未开始活动已报名：

根据之前规则：

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

---

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

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

activity_rules_version
activity_checkin_config
activity_interest_config
activity_incidents

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

---

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

activities可增加：

cancel_deadline_at
checkin_start_at
checkin_end_at
interest_submit_deadline_at
max_interest_selections

---

第一百四十二章 Registration可增加

cancelled_at
cancel_reason
cancel_source

cancel_source：

user
admin
risk
system

---

第一百四十三章 ActivityFeedback扩展

建议：

satisfaction
join_again
comment
submitted_at

意向最好不要只放单个：

interested_user_id

因为已经建议最多3人。

---

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

建议单独表：

activity_interests

字段：

id
activity_id
user_id
target_user_id
created_at

唯一：

activity_id + user_id + target_user_id

---

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

因为一个用户可能选择：

最多3人。

原先activity_feedback中的单个interested_user_id：

无法满足。

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

activity_feedback
+
activity_interests

---

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

必须：

user_id != target_user_id

并且双方：

都是该活动合法参与者。

---

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

判断：

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只一条：

可将：

unmatched → active

但必须：

• 记录reactivated_at
• 保留历史

更推荐未来有MatchHistory。

V1可以先采用：

重新激活原Match + Audit/Event。

---

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

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

任一方Block。

系统：

不建立Match。

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

---

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

需要更新：

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

---

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

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

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

---

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

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

“牵手成功11对”。

正确：

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

---

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

管理员可以填写：

现场情况
问题
下次改进

用于公益组织内部运营。

---

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

V1技术上可以提供：

复制活动。

不建设复杂模板中心。

例如：

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

---

第一百五十七章 活动复制

复制：

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

不复制：

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

---

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

必须记录：

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

---

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

需要重点记录：

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

---

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

活动管理员可以：

提交风险事件。

真正封禁：

由风控权限角色处理。

避免现场人员权限过大。

---

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

如果实际活动确实需要：

可在该活动报名中收集。

使用目的：

现场紧急情况。

不能：

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

---

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

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

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

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

---

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

不要写入：

user_profiles

应属于：

activity_registration scoped data。

---

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

建议记录：

activity_rule_version
agreed_at

如果不同活动规则不同：

方便追溯。

---

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

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

需要重新通知。

是否要求重新确认：

视变更重要程度。

---

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

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

---

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

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

---

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

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

---

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

registration_open + not_applied
→ 立即报名

pending
→ 报名审核中

approved
→ 报名成功

rejected
→ 查看原因

full
→ 报名已满

registration_closed
→ 报名已结束

cancelled
→ 活动已取消

---

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

如果用户已签到：

填写活动反馈

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

查看/修改我的意向

---

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

用户不填写：

不影响账号。

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

---

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

用户可以：

没有想进一步了解的人。

系统必须尊重。

---

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

♥

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

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

可以开始进一步了解了

[开始聊天]

稍后再聊

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

---

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

推荐：

感谢你的参与

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

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

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

---

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

这是明确UX红线。

---

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

不展示：

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

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

---

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

V1不建议。

避免：

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

---

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

后台不需要：

某人被选择8次

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

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

---

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

更适合关注：

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

---

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

后台：

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

---

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

如果某场活动：

举报明显较多。

运营需要复盘：

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

---

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

每场活动后台建议配置：

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

用户详情中可显示：

活动联系电话。

---

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

如可行：

使用工作号码。

若只能使用个人手机号：

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

---

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

线上用户
  │
  ↓
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

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

---

P1

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

---

P2

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

注意：

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

---

第一百八十六章 并发测试

必须测试：

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

---

第一百八十七章 权限测试

必须测试：

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

必须全部正确拒绝。

---

第一百八十八章 隐私测试

必须确认：

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

---

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

活动：

男50
女50

当前：

男49
女40

再批准一名男性：

成功。

再批准下一名男性：

GENDER_QUOTA_FULL。

即使总人数仍未到100。

---

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

用户32岁，活动范围：

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必须坚持：

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

报名必须有资格审核。

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

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

活动后的意向必须双向。

单向选择必须保密。

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

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

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

---

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

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

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

最终形成：

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

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