相亲社交小程序：资料审核、匹配权限与举报处理

先让资料审核与推荐形成闭环

用户提交资料，经审核后进入推荐范围；红娘或运营推荐时应说明可见信息和联系方式开放条件。认证状态不能被当成对全部资料真实性的保证。

• 首版优先资料、审核、推荐反馈、屏蔽与举报。
• 验收示例：未通过审核的资料不能被推荐，屏蔽双方不能继续互相发起沟通。

聊天、认证与审核能力分开估算

即时通信、音视频、认证服务、内容审核和红娘工作台是独立模块。供应商能力、使用条件和按量成本需按实际选择核对。

• 先确定社区运营模式和处理人员，再评估自动化程度。
• 用资料被驳回后修改重提的流程核对后台工作量。

推荐与服务记录需要能交接

用户资料、审核过程、推荐结果和服务进度应保留关联；敏感信息交接与导出必须按已确认权限进行。

• 交接数据字典、规则配置、审核队列和异常账号处理方式。
• 抽取一个示例服务单，查到历次推荐与反馈但不额外暴露其他用户资料。

资料展示与联系方式不是同一层权限

访客、普通用户、已匹配用户、红娘和审核员应看到不同字段。运营查看敏感信息也应与负责的服务任务相关。

• 明确照片、地区、职业等字段的可见选项。
• 测试被取消匹配后，旧链接不能继续访问已收回的联系信息。

付费权益应对应可解释的服务

会员期限、推荐次数、人工服务和活动报名要分别描述，不将技术推荐结果承诺为恋爱或婚姻结果。取消与退款处理按已确认服务规则执行。

• 支付订单关联权益发放记录，退款时明确收回哪些尚未使用的权益。
• 重复支付通知只能发放一次权益，过期后权限按规则关闭。

推荐提醒尊重可见范围与用户设置

通知中避免直接泄露对方联系方式或未公开资料。用户关闭提醒后，站内服务状态仍可查看。

• 拉黑、注销或限制沟通的账号不应继续收到互动引导。
• 模拟关系解除后消息仍在队列中，发送前再次核对接收条件。

区分推荐次数、响应与服务完成

注册数和消息量不能直接代表匹配效果。分析应关注审核通过、推荐响应、服务处理与投诉情况，并说明统计口径。

• 运营记录的成功结果需有可核实依据和使用授权。
• 同一对用户多次推荐时，报表按约定去重。

先完成举报与人工处理演练

上线前以合成资料验证注册、审核、推荐、屏蔽、举报与退出流程。经营模式涉及的平台规则和资质应另行核对当期要求。

• 给审核与服务人员制定分类、处理和升级路径。
• 测试举报后管理员接手、反馈结果和受限账号操作边界。

规则变更时处理已有关系

调整会员权益或资料公开方式，应确认对已有用户的影响。已有推荐和服务单保留当时的规则版本。

• 持续处理积压举报、异常沟通和过期资料。
• 升级后回测旧会员、已屏蔽关系和未完成服务单。

私人资料避免无目的聚合和导出

不因系统能采集就收集更多资料。敏感字段、私信和审核材料应有不同保存与访问范围。

• 对导出和查询异常设置审计，提供按业务要求处理删除的路径。
• 测试普通运营账号不能读取不属于自己任务范围的私密材料。

需求讨论中的问题