婚恋交友系统的核验与风控工程实现：核验流水线、风险信号与审核双通道

婚恋交友类系统与普通会员系统的技术分水岭，不在聊天和匹配，在「核验是一次性的吗、风险是可查的吗、内容是可控的吗」这三个问题上。核验有有效期、风险有台账、审核有通道，系统才立得住；反过来先堆功能，通常会在接入内容审核或应对检查时被迫重构注册链路。

本文按三条线拆：核验流水线、风险信号体系、内容审核双通道。每条线给出数据结构与几条工程约束。

一、模块边界与两条架构判断

| 模块 | 核心职责 | 关键约束 |

|---|---|---|

| 注册与核验服务 | 实名、婚姻状况、学历等核验项的采集与复核 | 核验记录带有效期，过程可追溯 |

| 资料与匹配 | 资料卡、筛选、推荐 | 资料修改留版本，敏感字段脱敏展示 |

| 沟通互动 | 私信、动态、活动 | 消息过审、引流拦截、举报入口常驻 |

| 会员与计费 | 套餐、次数核销、退款 | 计费规则可配置，核销流水不可改 |

| 风控与运营后台 | 举报处置、风险画像、审核队列 | 处置留操作人与时间，可导出 |

两条架构判断：其一，核验做成独立服务。 核验有第三方接口、人工复核队列、重试与超时、留痕四类需求，塞在用户模块里，每加一种核验项都要动主表。其二，风控台账与业务库物理分离。 风控查询是扫描型负载，和在线交易混库会互相拖累；分离后还能对业务侧开放只读副本。

二、核验流水线：把「已实名」变成一条可复验的记录

婚姻登记数据不向商业平台开放，这是产品设计要先接受的边界。可行的路径是：本人授权、自助查询、提交结果、人工复核。工程上把这条路径做成五段流水线：

图 5：婚姻状况核验流水线（示意）

核心表是核验记录表，建议字段：

-- 核验记录（只追加，复核通过才算生效）
verification(
  id, user_id, item,            -- item: identity / marriage / education / ...
  status,                       -- pending / passed / failed / expired
  evidence_url,                 -- 凭证原件（查询截图等）
  extracted_json,               -- OCR 预提取字段与置信度
  reviewer_id, reviewed_at,     -- 人工复核
  valid_until,                  -- 有效期，到期转 expired
  created_at
)

四条约束：

核验状态与用户状态解耦。 不要把「已实名」写在用户表字段上，它是一个随时间衰减的状态。到期自动转 expired，未复验的账号在发起约见等动作前做前置校验拦截。

凭证原件按用户隔离存储。 查询截图含敏感个人信息，存储路径不带用户 ID 明文，访问走带过期的签名 URL，下载留痕。

人脸授权是独立动作。 生物识别属敏感个人信息，授权页要独立、可回溯（版本号 + 勾选时间 + 端与 IP），拒绝人脸的用户保留人工复核通道，否则等于变相强制。

失败要分类。 failed 必须带原因码（信息不一致 / 图像不清晰 / 已过期 / 来源不可信），前端按原因给下一步指引，不然用户只会反复提交。

三、风险信号：把「感觉不对」变成四张可查的表

婚托类行为在数据上会留下痕迹，工程问题是大多数系统没建这几张表：

图 6：风险信号的四类数据来源与六级处置（示意）

| 数据源 | 关键字段 | 能回答的问题 |

|---|---|---|

| 约见记录 | 会员 ID、对象 ID、红娘 ID、时间、收费标记 | 同一对象 30 日内被多少不同会员约见 |

| 次数核销流水 | 套餐 ID、核销时间、关联订单 | 单日核销速度是否异常 |

| 资料与核验 | 核验结果码、失败原因、资料版本 | 资料关键项与核验结果是否一致 |

| 行为与设备 | 设备指纹、注册来源、文本相似度 | 是否同一团伙批量注册 |

三条实现要点：

规则引擎做成「规则表 + 命中记录」两层。 每条规则一个编码（如 R001 同一对象跨会员高频约见）、阈值可配置、命中写 risk_hit(record_id, rule_code, score, detail_json)。风险分可解释的前提，是每个分都能落到具体命中记录上。

处置动作做成状态机而不是开关。 normal → noticed → limited_msg → limited_meet → unpublished → banned，每级迁移留操作人、依据（命中的规则记录 ID）与时间。只有「封号」一个动作的系统，运营要么不敢用、要么滥用。

申诉通道与处置同级别对待。 误伤的申诉要有队列、有时限、有复核记录，处置与申诉写同一张操作日志表，事后能完整还原。

四、内容审核：公开内容与私信的双通道

两类内容的时效要求不同，策略也不同：

图 7：先审后发与先发后审的选择（示意）

公开内容（资料、动态、活动）建议先审后发：机审识别命中即拦，未命中进入人工队列，队列要有限时 SLA 与积压告警。私信建议实时机审加举报回扫：机审结果只做拦截与计分，不阻塞发送；举报是兜底通道，举报闭环要落在表上——report(reporter, target, category, status, handled_by, handled_at)，状态机 submitted → accepted → resolved / rejected，结果回告举报人。

两条常被省掉的工程要求：

日志字段要一次定全。 时间、账号、IP、设备、动作、前后状态，这六项缺一项，事后调证就要靠猜。日志留存周期按合规要求定，别用滚动覆盖。

审核记录与业务记录同粒度。 「这条消息为什么被拦」要能从消息 ID 追到审核记录，审核记录要能追到命中的规则与模型版本。模型迭代后历史处置的解释力，靠的就是版本号。

五、交付视角的检查单

这类系统交付验收时，建议按下面的清单过一遍：

| 检查项 | 判定标准 |

|---|---|

| 核验记录可复验 | 存在 valid_until，到期后账号动作被前置拦截 |

| 凭证访问留痕 | 每次查看截图有日志，URL 带过期 |

| 风险命中可解释 | 任一风险分能列出命中的规则与明细 |

| 处置可还原 | 操作日志含操作人、依据、前后状态 |

| 举报闭环完整 | 状态机齐、结果回告、同目标累计计分 |

| 审核可追溯 | 消息 ID 能追到审核记录、规则与模型版本 |

把核验、风险、审核三条线的数据结构先定下来，页面和接口都是后面的事；反过来先做页面，通常第二个月就会开始重构注册链路。