十月初有篇报道被同行转了一圈中国消费者报的观点是面对个体差异极强的婚恋市场单纯的算法匹配难以兼顾性格适配、相处模式这些软性维度AI 初筛 真人红娘终审的双轨模式正在成为行业转型样本。做婚恋系统的工程师看到这句话大概会心一笑。这不是一句产品话术这是一句架构决策。匹配这个环节里机器和红娘各管一段两段的边界怎么划、数据怎么互相喂才是婚恋系统真正要设计的东西。这一篇就聊聊这条人机协同链路在我们的婚恋系统里是怎么做出来的。机筛只负责不漏不负责行不行很多团队第一版匹配引擎的写法是把条件拼成一个 SQL查出全量符合的候选人直接推给会员。问题是条件窗口收得越紧结果越少放得越松噪声越多。运营同学会来问为什么给这位女会员推的人里有明显不合适的因为有些不合适根本不是条件能表达的。收入写了两万但聊天里自称刚失业离异但档案勾了未婚照片是十年前的。这些要靠红娘的眼睛SQL 查不出来。所以婚恋系统的机筛层定位要收窄它只做两件事硬性条件一票否决软性维度打分排序。分数不承诺合适只保证值得让人看一眼。defmachine_score(candidate,demand):# 硬性条件一票否决年龄区间、城市、婚姻状态口径 if not check_hard_conditions(candidate, demand): return None soft (0.4 * jaccard(candidate.interests, demand.interests) 0.3 * distance_score(candidate.district, demand.district) 0.3 * profile_completeness(candidate)) return round(soft * 100, 1)打分本身不复杂复杂的是排序之后的截断策略。我们的做法是按分数取 Top N 进池同时给每个候选人一个冷却期避免同一个人被反复推给同一个会员。机筛到此为止剩下的判断交给红娘。终审不是看一眼驳回理由必须结构化在婚恋系统里红娘终审这一步最常见的塌方是理由丢失。红娘看完说这个人不行然后呢系统里只有一行通过/驳回的状态位机筛永远不知道自己错在哪。所以工单表设计的关键字段是 verdict_tags一个 JSON 数组强制红娘从标签词表里选CREATETABLEmatch_task(idBIGINTPRIMARYKEYAUTO_INCREMENT,member_idBIGINTNOTNULLCOMMENT发起匹配的会员,candidate_idBIGINTNOTNULLCOMMENT机筛候选人,machine_scoreDECIMAL(5,1)NOTNULL,matchmaker_idBIGINTDEFAULTNULLCOMMENT接单红娘,statusTINYINTNOTNULLDEFAULT0COMMENT0待审 1审中 2通过 3驳回 4已约见 5过期,verdict_tags JSONDEFAULTNULLCOMMENT结构化结论标签,verdict_noteVARCHAR(512)COMMENT自由文本补充,deadlineDATETIMENOTNULLCOMMENT48小时审结时限,created_atDATETIMEDEFAULTCURRENT_TIMESTAMP,UNIQUEKEYuk_member_candidate(member_id,candidate_id));标签词表初期不用贪多十几个够用婚史口径不符、距离过远、职业信息存疑、照片与本人差距大、择偶诉求不现实。自由文本 verdict_note 保留但它是补充不是主键。这里有个内部争论过很久的细节要不要把 machine_score 给红娘看最后决定隐藏。分数会锚定判断红娘看到 92 分就不好意思驳回看到 61 分就顺手划走。机筛的分是排序用的不是给人看的。拒绝的理由比通过更值钱结构化标签真正的价值在下游。每周把 verdict_tags 聚合一次看驳回原因的分布。示例数据某合作机构一个月产生 1,860 条机筛任务红娘驳回率 41%驳回原因 Top 3 是职业信息存疑 28%“距离过远 22%”“婚史口径不符 15%”。这三个数字直接改写了机筛权重距离衰减函数调陡职业字段从软性加分项升级为需要材料佐证的半硬性条件。下个月驳回率降到 33%。这就是双轨模式在婚恋系统里的技术含义红娘的判断不是终点是训练信号。机筛犯过的错都以标签的形式流回权重层。可以说标签词表就是机筛和红娘之间的接口协议协议越准机筛进步越快。驳回原因聚合月度 职业信息存疑 ████████████████ 28% 距离过远 ████████████ 22% 婚史口径不符 ████████ 15% 择偶诉求不现实 ██████ 11% 其他 ██████████████ 24%自由文本先别急着上 NLP。verdict_note 里每周会出现一些词表没覆盖的说法让运营每月人工归一次类新说法沉淀进标签词表。词表版本化管理老工单的标签不回填统计口径按周切。工单池要有节奏红娘不是流水线婚恋系统的最后一个容易被忽略的环节是派单本身。早期我们用抢单模式结果红娘专挑容易的单——看一眼就能判断的真假头像被抢光剩下的都是要打电话核实职业的硬骨头deadline 到了没人动工单过期。改成随机派单加负载均衡之后配合 48 小时审结时限和超时回收重派超时率从两成多降到 5% 以内示例数据。另外给红娘留了免打扰时段相亲旺季晚间是红娘跟会员沟通的高峰终审工单自动避开这些时段派发。整条链路串起来是这样渲染错误:Mermaid 渲染失败: Parse error on line 1: flowchart LR A[会员择偶需求] -- B[机筛打分 ----------------^ Expecting NEWLINE, got NODE_STRING复盘这套设计的核心取舍就一条机器负责规模红娘的判断负责质量而质量要变成数据才能沉淀。机筛没有追求打分模型多精巧红娘终审也没有追求全部自动化因为婚恋系统里匹配质量的上限往往取决于驳回理由有没有被认真记录。先让标签词表转起来比引进任何花哨的模型都实在。文中方案来自我们在婚恋行业 SaaS云中红线的一线实践欢迎交流。