# 丹阳公益婚恋服务平台 # 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必须坚持： > **活动不是单纯把人拉到现场。** > **报名必须有资格审核。** > **现场只使用完成任务必要的信息。** > **不强迫用户交换联系方式。** > **活动后的意向必须双向。** > **单向选择必须保密。** > **互选只是进一步了解，不等于成功牵手。** > **现场风险能够直接进入平台风控闭环。** > **公益红娘可以继续服务，但不干预私人沟通。** --- # 第一百九十七章 最终设计原则 整个公益相亲活动闭环最终要达到： > **线上先把身份和资格做好，线下把见面和体验做好，活动后把双方意愿保护好，再把真正互相愿意的人自然接回平台继续沟通。** 最终形成： > **线上筛选 → 公益活动见面 → 双向互选 → 平台沟通 → 公益红娘辅助 → 成功牵手** 这才是本平台区别于单纯“线上刷对象”和单纯“线下办相亲会”的核心服务闭环。