danyang-match/匹配推荐算法与公益红娘协同机制详细设计.md

丹阳公益婚恋服务平台

V1.0 匹配推荐算法与公益红娘协同机制详细设计

版本：V1.0
适用范围：微信小程序用户端、公益红娘工作台、运营管理后台
设计目标：规则透明、结果可解释、双向匹配、人工可辅助、用户拥有最终决定权

---

第一章 设计目标

V1.0匹配系统不追求复杂AI。

核心目标只有五个：

1. 不推荐明显不符合的人
2. 必须同时考虑双方条件
3. 优先推荐更适合进一步了解的人
4. 告诉用户为什么推荐
5. 给公益红娘提供可靠候选，而不是让红娘从全库人工翻找

因此V1.0采用：

硬条件过滤 + 双向条件验证 + 规则评分 + 推荐排序 + 公益红娘人工辅助

而不是：

• 黑盒AI
• 大模型直接判断婚恋匹配
• 深度学习推荐
• 向量数据库
• 颜值模型
• 收入阶层模型

---

第二章 匹配系统总体结构

用户A
↓
建立候选池
↓
基础资格过滤
↓
A的“必须符合”检查B
↓
B的“必须符合”检查A
↓
双方硬条件全部通过
↓
计算A对B适配度
↓
计算B对A适配度
↓
计算双方综合分
↓
生成推荐理由
↓
排序
↓
去重/冷却/频控
↓
进入每日推荐/找对象/红娘候选

---

第三章 匹配系统最重要原则

必须是：

双向匹配。

不是：

A喜欢什么
↓
平台找一个符合A的人

而是：

A符合B吗？
+
B符合A吗？

都通过，才有资格进入推荐候选池。

---

第四章 条件分两级

用户择偶条件统一分为：

4.1 Required

前端：

必须符合

含义：

不符合则直接淘汰。

---

4.2 Preferred

前端：

最好符合

含义：

不符合不会直接淘汰，但会降低推荐分。

---

第五章 V1支持的核心匹配字段

建议正式纳入算法的字段：

年龄
身高
地区
婚姻状态
子女情况
学历
吸烟
饮酒
定居意愿
婚姻计划
生活方式
兴趣

其中最核心：

年龄
地区
婚姻状态
子女情况
婚姻计划
定居意愿

---

第六章 不进入算法的字段

V1不建议直接用于匹配评分：

• 收入
• 房产
• 汽车
• 外貌
• 身份证地区
• 单位级别
• 家庭资产
• 用户照片颜值
• 工作单位知名度

避免让产品走向：

商业婚恋分层与“条件估价”。

---

第七章 候选人基础资格过滤

在计算任何分数前，先过滤。

候选人B必须满足：

B != A
B.account_status = normal
B.profile_review = approved
B.relationship_status允许推荐
B.visible_in_recommendations = true
B有有效主头像

---

第八章 必须排除的关系

A与B存在以下任一情况：

直接排除：

A blocked B
B blocked A

A passed B且仍处于冷却期

A与B已经successful

A与B已有active match

B账号风险受限

B暂停寻找

B退出婚恋服务

---

第九章 已经喜欢的用户

如果：

A liked B

但B未回应。

不应继续频繁出现在A每日推荐。

应该进入：

我喜欢的。

避免重复展示。

---

第十章 对方已喜欢A

如果：

B liked A

A还没有处理。

这类用户可以给予：

适度排序提升。

但不能直接告诉A：

“因为TA喜欢你，所以排第一。”

除非在：

喜欢我的

模块明确展示。

---

第十一章 性别匹配规则

基于用户当前产品设定与个人择偶条件执行。

如果V1仅支持异性婚恋匹配，必须在产品规则和数据结构中明确。

如果未来支持更广泛的择偶方向，应扩展：

preferred_gender

V1算法不要通过代码写死隐含规则，而应通过明确配置表达。

---

第十二章 年龄Required判断

例如A要求：

28～35
required

如果B年龄：

32

则通过。

如果：

36

直接淘汰。

---

第十三章 年龄Preferred评分

例如：

28～35
preferred

建议评分：

范围内       100%
超出1岁      80%
超出2岁      60%
超出3岁      40%
超出4岁+     0%

具体梯度配置化。

---

第十四章 身高规则

Required：

不在范围直接淘汰。

Preferred：

可按偏差计算。

例如：

范围内       满分
差1～3cm     80%
差4～5cm     60%
差6～10cm    30%
更大偏差      0

---

第十五章 地区规则

地区是丹阳本地平台非常重要的字段。

建议支持：

丹阳
镇江市区
镇江其他辖区
不限

未来可扩展省市区代码。

---

第十六章 地区匹配等级

示例：

同一主要地区     100
同一镇江市范围    80
江苏其他地区      40
其他地区          20

但如果用户地区设置为Required：

必须严格执行用户选定范围。

---

第十七章 地区与“长期定居”结合

单纯看当前居住地不够。

例如：

A在丹阳。

B现在在南京，但：

明确愿意回丹阳长期定居。

这种情况可以获得一定适配分。

因此地区建议拆：

当前生活区域
+
未来定居意愿

---

第十八章 婚姻状态规则

用户可选：

未婚
离异
丧偶

Required：

候选状态必须在用户允许集合中。

Preferred：

符合则加分。

婚姻状态本身不做价值排序。

例如：

未婚不能默认比离异得分高。

只能根据用户自己的选择。

---

第十九章 子女情况

不要把：

有子女

默认设计成扣分。

正确规则：

对方情况
是否符合用户自己的接受条件

例如：

接受
不接受
视情况

---

第二十章 学历

学历作为较低权重条件。

原因：

学历不能直接代表婚恋适配程度。

因此即便用户设置Preferred：

也不应让学历对最终结果产生过大影响。

---

第二十一章 婚姻计划

婚姻计划是重要字段。

例如：

半年内
1年内
1～2年
2年以上
顺其自然

建议匹配距离模型。

---

第二十二章 婚姻计划距离

例如：

A：1年内
B：1年内

100%。

A：1年内
B：1～2年

80%。

A：半年内
B：2年以上

20%或更低。

---

第二十三章 定居意愿

对丹阳本地产品非常重要。

例如：

长期在丹阳
愿意未来在丹阳
视情况
不考虑

双方：

一个必须丹阳，一个明确不愿丹阳。

即使其他条件很好：

也应该低分或直接排除。

---

第二十四章 吸烟与饮酒

属于生活方式匹配。

建议低～中权重。

不要做社会价值判断。

只是：

是否符合对方偏好。

---

第二十五章 兴趣匹配

兴趣：

不是必要条件。

计算：

共同兴趣数
/
双方兴趣并集

可采用Jaccard Similarity：

intersection(A,B)
-----------------
union(A,B)

例如：

A：

旅行 阅读 运动 电影

B：

旅行 运动 美食

共同：

旅行 运动

用于低权重加分。

---

第二十六章 兴趣不能权重过高

兴趣相同：

不代表适合结婚。

所以V1建议兴趣：

5分左右。

主要用于：

• 推荐理由
• 排序细微区分
• 聊天破冰

---

第二十七章 生活方式评分

可以由以下字段组成：

吸烟
饮酒
社交倾向
生活规律
户外/居家
家庭倾向

V1如果用户资料量不足：

先只使用吸烟、饮酒等已确认字段。

不要为了算法强制增加大量资料。

---

第二十八章 V1建议权重

推荐默认100分：

年龄             15
地区             15
婚姻状态          10
子女情况          10
学历               5
身高               5
婚姻计划          15
定居意愿          10
生活方式          10
兴趣               5
--------------------
总计             100

这是系统默认权重。

后台必须允许版本化配置。

---

第二十九章 权重不是用户个人权重

V1建议：

用户只选择：

必须符合
最好符合

不让普通用户自己调：

年龄权重17
学历权重8

这会明显增加使用复杂度。

---

第三十章 单方向适配分

定义：

Score(A→B)

表示：

B有多符合A的择偶期待。

例如：

年龄        15/15
地区        15/15
婚姻状态    10/10
子女        10/10
学历         5/5
身高         4/5
婚姻计划    12/15
定居        10/10
生活方式     8/10
兴趣         3/5

Score(A→B)=92

---

第三十一章 双方向评分

还必须算：

Score(B→A)

例如：

Score(A→B)=92
Score(B→A)=78

不能只展示92。

---

第三十二章 双向综合分公式

不建议简单：

(92 + 78) / 2 = 85

因为平均数可能掩盖单方明显偏低。

建议V1采用：

MutualScore =
0.6 × min(A→B, B→A)
+
0.4 × average(A→B, B→A)

---

第三十三章 综合公式示例

例如：

A→B = 92
B→A = 78

则：

min = 78
average = 85

MutualScore
= 0.6×78 + 0.4×85
= 80.8

这样可以体现：

双向适合比单方高分更重要。

---

第三十四章 为什么不用最低分直接作为最终分

如果：

final = min(A→B,B→A)

虽然强调双向，但损失部分区分度。

因此：

最低分主导 + 平均分修正

更适合V1。

---

第三十五章 Required不参与补偿

重要：

不符合Required，直接淘汰。

不能：

年龄不符合Required
但兴趣很多
所以总分仍有85

这是错误的。

---

第三十六章 算法完整伪代码

function calculateMatch(A, B):

    if not isEligible(A, B):
        return REJECT

    if !requiredMatch(A.preference, B.profile):
        return REJECT

    if !requiredMatch(B.preference, A.profile):
        return REJECT

    scoreAB = calculateDirectionalScore(A, B)
    scoreBA = calculateDirectionalScore(B, A)

    minScore = min(scoreAB, scoreBA)
    avgScore = (scoreAB + scoreBA) / 2

    mutualScore =
        minScore * 0.6 +
        avgScore * 0.4

    reasons = generateReasons(A, B)

    return {
        scoreAB,
        scoreBA,
        mutualScore,
        reasons
    }

---

第三十七章 最低推荐阈值

建议初始：

MutualScore >= 60

才能进入普通推荐候选。

后台可配置。

---

第三十八章 推荐等级

建议：

85～100
很合适

70～84
比较合适

60～69
值得了解

<60
默认不推荐

前台：

不显示数字。

只显示文字等级和推荐理由。

---

第三十九章 为什么不显示百分比

不要显示：

匹配度92%

原因：

这会让用户误以为：

92%概率适合结婚。

实际上只是规则评分。

因此前台建议：

比较合适
值得了解

更加诚实。

---

第四十章 推荐理由生成原则

推荐理由必须：

来自真实数据。

不能让AI编。

---

第四十一章 推荐理由优先级

优先展示：

1. 双方都满足的重要条件
2. 本地生活
3. 婚姻计划
4. 定居意愿
5. 生活方式
6. 兴趣

---

第四十二章 推荐理由示例

年龄符合双方的择偶要求

你们都长期生活在丹阳

你们对结婚时间的计划比较一致

双方都不吸烟

你们都喜欢运动和旅行

---

第四十三章 推荐理由不要出现

避免：

系统认为你们很般配

AI判断你们适合结婚

成功概率86%

条件等级相近

经济实力匹配

---

第四十四章 推荐理由最多数量

首页：

3条。

详情：

最多4条。

不要展示十几条。

---

第四十五章 每日推荐策略

建议默认：

6人/天

后台配置：

5～10

不要做：

无限刷人。

---

第四十六章 为什么控制每日数量

公益婚恋平台核心不是：

增加刷卡时长。

而是：

让用户认真看有限、相对合适的人。

数量少还有利于：

• 候选资源利用
• 本地小用户池
• 降低疲劳
• 减少“逛商品”感觉

---

第四十七章 每日推荐生成方式

推荐两种：

方式A

用户打开首页时实时计算。

早期用户少：

完全可行。

方式B

每日提前生成推荐池。

用户量增大后：

推荐使用。

V1技术可以先：

候选实时计算 + Redis缓存。

---

第四十八章 每日推荐基本排序

候选池按照：

1 MutualScore
2 双方Required完整度
3 新鲜度
4 对方活跃度
5 推荐历史

综合排序。

---

第四十九章 活跃度只能低权重使用

活跃用户可以稍微靠前。

但不能：

谁每天登录就永远排第一。

否则新用户和不高频用户会被饿死。

---

第五十章 活跃状态建议

例如：

7天内活跃      正常
30天未登录     轻降权
90天未登录     明显降权

如果长期不活跃：

暂停推荐曝光。

具体周期后台配置。

---

第五十一章 新用户冷启动

新用户刚审核通过。

没有行为数据。

直接使用：

Profile + Preferences规则匹配。

不需要行为推荐。

这正是V1规则算法的优势。

---

第五十二章 新用户适度曝光

新审核通过用户可以获得：

轻度新鲜度加权。

例如：

前7天
+少量排序修正

目的：

避免新人长期没有曝光。

不能过度加权。

---

第五十三章 曝光公平性

如果只按最高分排序：

少数高分用户可能：

每天被大量推荐。

其他人没人看到。

因此需要：

Exposure Balance。

---

第五十四章 曝光控制

建议记录：

最近7天曝光次数
最近30天曝光次数

当候选人短期曝光明显过多：

轻微降权。

---

第五十五章 曝光平衡不是平均主义

仍然应该：

匹配度优先。

公平性只是：

同等匹配程度下的排序修正。

---

第五十六章 推荐排序最终分

可以定义内部：

RankingScore =
MutualScore
+ FreshnessBoost
+ ActivityBoost
+ ReciprocityBoost
- ExposurePenalty
- RepeatPenalty

---

第五十七章 修正项范围必须小

例如：

FreshnessBoost      0～3
ActivityBoost       0～2
ReciprocityBoost    0～3
ExposurePenalty     0～5
RepeatPenalty       0～10

核心100分匹配不能被运营修正彻底覆盖。

---

第五十八章 ReciprocityBoost

如果B已经喜欢A：

可以：

+3

让双方更容易在推荐中相遇。

这可以提高：

双向匹配效率。

但不能绕过Required。

---

第五十九章 RepeatPenalty

同一候选人已经展示多次：

应该降权。

例如：

已曝光1次   0
2次        -3
3次        -6

如果用户明确Pass：

直接进入冷却，不再靠Penalty。

---

第六十章 推荐冷却机制

建议：

仅曝光未操作

7～30天后可以再次出现。

用户Pass

较长冷却。

建议：

180天可配置。

Unmatch

默认长期排除。

Block

直到用户主动解除。

---

第六十一章 用户池很小时怎么办

丹阳本地早期很可能遇到：

符合条件的人很少。

系统不能擅自放宽：

Required。

---

第六十二章 无候选时处理顺序

第一步：
确认是否真的没有满足Required的人

第二步：
扩大Preferred条件容忍范围

第三步：
向用户提示可调整择偶条件

第四步：
提供公益红娘入口

---

第六十三章 不允许后台偷偷改Required

运营管理员不能：

为了让推荐更多，自动放宽用户的必须条件。

这是用户明确偏好。

只有用户本人：

修改。

---

第六十四章 Preferred自动放宽

Preferred允许系统做适度容忍。

例如：

年龄最好：

30～35

可逐步考虑：

29或36

但得分下降。

---

第六十五章 放宽顺序

建议按影响从低到高：

兴趣
↓
生活方式
↓
身高
↓
学历
↓
年龄Preferred
↓
地区Preferred

婚姻状态、子女等是否放宽：

必须严格按照用户设置和业务含义处理。

---

第六十六章 “找对象”与“每日推荐”算法区别

每日推荐：

系统主动精选。

找对象：

用户主动筛选。

两者底层候选资格规则相同。

---

第六十七章 找对象排序

默认：

综合推荐

可后续提供：

最近活跃
年龄

V1不建议增加太多排序。

---

第六十八章 临时筛选不修改择偶条件

例如用户临时筛：

30～32岁。

只影响当前Find结果。

不能覆盖：

我的择偶条件。

---

第六十九章 红娘候选算法

公益红娘工作台调用：

同一个Match Engine。

但可以看到更多解释信息。

---

第七十章 红娘候选列表结构

建议：

王女士 32岁

双向综合：高
A→B：较高
B→A：较高

Required：
全部符合

主要推荐理由：
✓ 年龄
✓ 丹阳
✓ 婚姻计划

红娘不需要看到复杂数学公式。

---

第七十一章 红娘比普通用户多看到什么

可以多看到：

• 哪些Required通过
• 哪些Preferred不符合
• 双方婚恋计划差异
• 用户最近推荐情况
• 是否长期没有Match

目的是：

帮助人工判断。

---

第七十二章 红娘不能看到什么

不能因为匹配工作看到：

• 身份证
• 完整聊天
• 举报证据
• 无关风险内部材料
• 精确家庭住址

---

第七十三章 红娘人工推荐机制

流程：

用户A申请红娘帮助
↓
Match Engine生成候选
↓
红娘查看候选
↓
人工判断
↓
选择B
↓
填写推荐理由
↓
发送给A
↓
A自己决定喜欢/不合适

---

第七十四章 红娘人工判断可以补充什么

算法难以完全处理：

• 用户真实表达偏好
• 近期家庭计划
• 对沟通风格的期待
• 用户主动向红娘说明的特殊情况

红娘可以在用户授权范围内：

人工辅助判断。

---

第七十五章 红娘不能覆盖Required

再次强调：

算法Required失败
↓
红娘不可直接推荐

如果红娘认为用户设置过严：

应：

建议用户修改。

用户确认修改后：

重新计算。

---

第七十六章 红娘建议修改择偶条件

红娘可以说：

“目前符合你全部必须条件的用户较少，是否考虑把学历从必须符合改成最好符合？”

用户可以：

接受
拒绝

只有用户接受：

系统更新条件。

---

第七十七章 红娘不得代修改

后台不能提供：

直接替用户改择偶条件

普通按钮。

若特殊线下协助确需操作：

必须：

• 明确用户授权
• 留操作日志
• 告知用户变更结果

V1建议仍由用户本人改。

---

第七十八章 红娘联系意向对象流程

例如A：

希望红娘帮我联系B。

系统：

A明确申请
↓
红娘确认B仍可联系
↓
向B发系统通知
↓
“有一位用户希望进一步了解你”
↓
B自主查看/决定

---

第七十九章 不直接给手机号

红娘不能：

A想了解B
↓
直接把B手机号发给A

正确：

平台内发起意向。

---

第八十章 红娘推荐来源标记

推荐记录：

source = matchmaker

与：

daily
discover
activity

区分。

方便后续统计：

哪种方式转化更好。

---

第八十一章 红娘效果评价

不要只看：

红娘推荐了多少人。

建议看：

服务人数
推荐人数
查看率
喜欢率
双向匹配率
正在了解率
成功牵手率

---

第八十二章 不做红娘排行榜

V1不建议：

金牌红娘Top10
牵手王
红娘PK榜

公益服务不需要游戏化竞争。

---

第八十三章 红娘工作量控制

后台建议：

每位红娘服务中用户数
待跟进数
超时数

管理员据此分配。

---

第八十四章 长时间无匹配用户识别

系统可以识别：

审核通过30天
+
有活跃
+
无双向匹配

标记：

可关注。

---

第八十五章 长期无结果原因分析

系统可给红娘提示：

候选池过小
Required过多
地区范围很窄
用户很少主动Like
资料完整度一般

不能写：

“用户条件太差”。

---

第八十六章 用户资料完整度与推荐

资料未完整：

本就不能审核通过。

审核后仍有选填项缺失：

不应该直接重罚。

但信息越完整：

推荐理由可能更充分。

---

第八十七章 照片数量与排序

不能因为：

上传6张照片

就比：

只上传2张照片

获得明显匹配加分。

否则会诱导用户过度上传。

照片主要影响：

用户自己判断。

不是算法核心分。

---

第八十八章 被喜欢数量不能作为质量分

禁止：

被喜欢越多
→ 排名越高

否则会形成：

马太效应。

---

第八十九章 热门用户控制

如果一个用户短时间收到大量Like：

系统可以：

降低曝光频率。

避免其积累大量无法处理的意向。

---

第九十章 双向匹配效率指标

核心指标：

Mutual Match Rate =
双向匹配数
/
有效Like数

但不能只优化这个指标。

---

第九十一章 更重要的最终指标

长期真正关注：

聊天建立率
持续沟通率
正在了解率
线下见面率
成功牵手率

V1先把数据记录好。

---

第九十二章 推荐算法不能只追求点击

如果只优化：

用户点击喜欢。

可能会把系统变成：

外貌刷人产品。

所以V1不做点击率机器学习。

---

第九十三章 用户反馈闭环

推荐后行为：

查看
喜欢
Pass
Match
Unmatch
成功

都记录。

未来可以优化规则。

但V1不做自动机器学习。

---

第九十四章 Pass原因V1策略

前面已确定：

点击不合适不强制询问原因。

因此算法不能依赖：

Pass原因。

减少用户操作负担。

---

第九十五章 Unmatch原因可用

解除匹配时已有原因选项。

可以作为：

运营分析数据。

但V1不直接自动训练模型。

---

第九十六章 推荐规则版本

每条RecommendationRecord应记录：

rule_version

例如：

v1
v2

以后修改权重：

可以比较效果。

---

第九十七章 权重修改流程

后台管理员：

创建新版本
↓
检查权重总和
↓
保存草稿
↓
人工确认
↓
激活

不直接覆盖旧版本。

---

第九十八章 权重调整必须审计

记录：

谁改
什么时候
旧值
新值
原因

避免运营人员随意调算法。

---

第九十九章 是否需要A/B测试

V1：

不需要复杂A/B平台。

如果以后需要：

可以按小比例用户测试新规则。

V1先：

一个正式规则版本。

---

第一百章 算法解释接口

后端建议：

MatchResult {
  scoreAB
  scoreBA
  mutualScore
  level
  reasons
  requiredChecks
  preferredChecks
}

普通用户DTO：

只返回：

level
reasons

红娘DTO：

可增加：

requiredChecks
preferredChecks

---

第一百零一章 推荐服务内部模块建议

MatchEligibilityService
RequiredConditionService
DirectionalScoringService
MutualScoringService
RecommendationReasonService
RankingService
ExposureControlService
RecommendationHistoryService

不一定拆成独立微服务。

都可在Match模块内。

---

第一百零二章 MatchEligibilityService

负责：

• 账号状态
• 审核状态
• 婚恋状态
• 隐私
• Block
• 已有关系
• 冷却期

---

第一百零三章 RequiredConditionService

负责：

A Required → B
B Required → A

必须纯规则、可测试。

---

第一百零四章 DirectionalScoringService

负责：

Score(A→B)

输入：

A preference
B profile
active rule config

输出：

dimension scores
total

---

第一百零五章 MutualScoringService

负责公式：

0.6 × min
+
0.4 × avg

后续公式如果变化：

不影响前端。

---

第一百零六章 ReasonService

只从：

已经通过的真实匹配字段

生成说明。

不能独立“创造”理由。

---

第一百零七章 RankingService

处理：

MutualScore
+
Freshness
+
Activity
+
Reciprocity
-
Exposure
-
Repeat

最终输出顺序。

---

第一百零八章 ExposureControlService

维护：

最近曝光量
单日曝光上限
重复推荐

避免热门用户被过度曝光。

---

第一百零九章 SQL候选池初筛

数据库先做：

审核通过
账号normal
目标性别
年龄粗范围
地区粗范围
未暂停
隐私允许

例如先得到：

100～500个候选。

再在应用层计算。

---

第一百一十章 不建议数据库写超复杂评分SQL

不要把所有：

CASE WHEN...
CASE WHEN...

都塞SQL。

V1：

SQL过滤 + 应用层评分

更容易维护和测试。

---

第一百一十一章 Redis推荐缓存

可缓存：

recommendation:{userId}:{date}

内容：

排序后的候选ID。

详情数据：

实时/短缓存读取。

---

第一百一十二章 推荐缓存失效事件

以下事件发生：

立即使相关缓存失效：

修改择偶条件
资料审核变化
暂停寻找
成功牵手
Block
Unmatch
风险封禁
隐私修改

---

第一百一十三章 推荐时二次校验

即使缓存中有B：

真正返回卡片前：

再做轻量Eligibility检查。

避免：

B刚暂停，A仍然看到。

---

第一百一十四章 算法性能目标

丹阳本地早期：

单用户候选池并不会非常大。

目标：

候选过滤 < 300ms
评分排序 < 300ms
推荐接口整体 P95 < 1.5s

完全不需要重型推荐基础设施。

---

第一百一十五章 单元测试要求

每个维度至少测试：

• 完全符合
• 边界值
• Required失败
• Preferred部分符合
• Null/未填写
• 异常值

---

第一百一十六章 双向条件测试

必须测试：

A接受B
B不接受A

结果：

REJECT。

不是：

仍推荐给A。

---

第一百一十七章 地区边界测试

例如：

A：

丹阳 required

B：

南京
未来愿意丹阳

如果A要求的是：

当前居住地丹阳

则失败。

如果A要求的是：

未来定居丹阳

则按对应字段判断。

字段含义必须清楚。

---

第一百一十八章 Null字段处理

对于非必填选项：

候选人没有填写。

不能默认：

符合。

建议：

Required + 对方未知
→ 不通过/不可判断

Preferred + 对方未知
→ 该维度0分或中性低分

具体按字段定义。

---

第一百一十九章 为什么Required未知不能自动通过

例如：

A：

不接受吸烟者，Required。

B：

没填吸烟状态。

系统不能假设：

B不吸烟。

否则违反用户硬条件。

---

第一百二十章 信息不完整提示

如果由于关键Required字段未知导致候选池很少：

可以提示用户：

完善生活资料有助于更准确匹配。

而不是系统猜测。

---

第一百二十一章 推荐结果审计

对于每次推荐，可以保存：

user_id
target_id
rule_version
mutual_score
reasons
shown_at
source

后续有投诉：

可以知道：

当时为什么推荐。

---

第一百二十二章 算法不应保存敏感推断

不要保存：

用户大概率高收入
用户看起来性格强势
用户可能离婚风险高

这些都不属于V1。

---

第一百二十三章 红娘操作审计

红娘人工推荐必须记录：

operator
user
target
reason
time
service_id

---

第一百二十四章 红娘推荐理由规范

建议：

基于资料事实。

例如：

年龄、地区和婚姻计划均较符合，
双方都希望长期在丹阳生活，
建议进一步了解。

不要写：

我觉得你们一定很合适。

---

第一百二十五章 系统与红娘边界

系统负责：

筛
算
排
解释

红娘负责：

看
判断
沟通
辅助
跟进

用户负责：

最终决定

---

第一百二十六章 理想协同流程

系统发现候选
↓
普通推荐有效？
├─ 是 → 直接推荐用户
└─ 用户长期无结果
        ↓
    红娘介入
        ↓
    系统提供候选解释
        ↓
    红娘人工筛选
        ↓
    用户自主决定

---

第一百二十七章 红娘不是“人工绕过算法”

红娘存在的价值不是：

算法不行，所以全人工。

而是：

算法做大规模初筛，人工处理复杂情况。

这是V1最适合公益组织的协同方式。

---

第一百二十八章 系统自动触发红娘建议

V1可以轻量提示：

如果用户：

30天无Mutual Match

且活跃：

首页提示：

可以让公益红娘帮你进一步看看。

但：

不自动创建红娘服务。

用户自己申请。

---

第一百二十九章 红娘主动介入边界

V1建议：

默认用户申请后介入。

如果公益机构要主动服务：

必须有：

用户事先同意接受公益红娘推荐/协助。

没有同意：

不主动电话联系婚恋事项。

---

第一百三十章 自动推荐频率

每日一次主推荐即可。

不建议：

上午推6个
中午推6个
晚上再推6个

避免打扰。

---

第一百三十一章 推荐通知

可以有：

今天有新的合适推荐。

但不是：

每个候选人一个通知。

降低骚扰感。

---

第一百三十二章 系统无法推荐时文案

正确：

暂时没有完全符合你条件的人。

可以：

调整“最好符合”的条件，或申请公益红娘帮助。

不要：

你的条件太高。

---

第一百三十三章 用户条件过窄提示

系统可计算：

Required过滤前候选100
↓
Required过滤后0

可以判断：

条件较严格。

文案：

当前符合所有“必须符合”条件的人较少。

---

第一百三十四章 条件优化助手V1

不需要AI。

可以规则提示：

你的6项条件中有5项设为必须符合，
当前候选范围较小。

按钮：

查看择偶条件。

---

第一百三十五章 不自动推荐“降低标准”

不要使用：

降低要求

文案。

建议：

调整条件

扩大了解范围

更加尊重用户。

---

第一百三十六章 未来AI升级接口预留

未来可增加：

AICompatibilityService

但它只能：

作为额外排序信号。

不能替代：

• Required
• 用户隐私
• Block
• 账号状态

---

第一百三十七章 AI未来的正确位置

未来：

硬条件过滤
↓
规则匹配
↓
AI辅助理解文本/兴趣
↓
排序微调

而不是：

把两个用户资料扔给大模型
↓
问“适不适合结婚？”

---

第一百三十八章 不允许AI自动作婚姻判断

未来也不能对用户输出：

“AI判断你们婚后幸福率89%。”

这种结果既不可验证，也容易误导。

---

第一百三十九章 算法核心监控指标

运营后台建议：

候选池平均人数
无候选用户比例
每日推荐完成率
详情查看率
Like率
Mutual Match率
Chat启动率
Unmatch率
红娘介入率

---

第一百四十章 性别供需统计

本地平台需要关注：

男女用户数量
各年龄段比例
各地区比例

但只是：

运营参考。

不能用于对用户差别收费，因为本项目永久免费。

---

第一百四十一章 候选池健康度

后台可以显示：

例如：

30～35岁男性
有效候选 83

30～35岁女性
有效候选 61

帮助公益组织：

设计线下活动和招募宣传。

---

第一百四十二章 红娘运营数据

建议：

平均接单时间
平均首次跟进时间
平均服务时长
平均推荐人数
推荐后Like率
Match率

不建议只统计：

电话打了多少个。

---

第一百四十三章 算法配置权限

只有：

超级管理员
或
指定算法配置管理员

可修改。

普通红娘：

只读。

---

第一百四十四章 推荐规则回滚

新规则出现异常：

后台支持：

激活旧版本。

不要现场改数据库权重。

---

第一百四十五章 推荐规则发布前检查

系统自动检查：

权重总和=100
最低分0～100
所有必要字段存在
规则版本唯一

---

第一百四十六章 推荐算法V1完整数据流

用户进入首页
↓
RecommendationService
↓
检查缓存
├─ 有
│  ↓
│ Eligibility二次校验
│
└─ 无
   ↓
   数据库初筛候选
   ↓
   Required双向过滤
   ↓
   Score A→B
   ↓
   Score B→A
   ↓
   MutualScore
   ↓
   RecommendationReasons
   ↓
   Ranking修正
   ↓
   Exposure控制
   ↓
   写RecommendationRecord
   ↓
   Redis缓存
↓
返回6位

---

第一百四十七章 红娘协同完整数据流

用户申请红娘
↓
建立MatchmakerService
↓
分配红娘
↓
系统调用Match Engine
↓
生成候选列表
↓
红娘查看：
Required
Preferred
推荐理由
历史服务
↓
人工筛选
↓
推荐给用户
↓
用户自主查看
↓
Like / Pass
↓
正常Relationship流程

---

第一百四十八章 核心验收场景一

A条件：

年龄30～35 Required
丹阳 Required
本科以上 Preferred

B：

32
丹阳
大专

A→B：

Required通过。

学历Preferred不满足：

扣相应分。

仍可推荐。

---

第一百四十九章 核心验收场景二

A要求B符合。

但B要求：

年龄40～45 Required

A只有36。

即使A非常喜欢B：

系统不应推荐。

因为：

B的Required不接受A。

---

第一百五十章 核心验收场景三

系统评分：

A→B 95
B→A 62

不能显示：

95分超高匹配。

最终双向分应明显受到：

62

影响。

---

第一百五十一章 核心验收场景四

A Pass B。

B第二天高分候选。

仍：

不应该重新推荐给A。

必须遵守冷却。

---

第一百五十二章 核心验收场景五

A Block B。

红娘搜索B准备推荐给A。

系统必须：

排除。

不能靠红娘记忆。

---

第一百五十三章 核心验收场景六

用户有5项Required导致候选0。

系统：

不偷偷放宽。

而是：

暂时没有完全符合条件的人
+
修改择偶条件
+
公益红娘

---

第一百五十四章 核心验收场景七

红娘推荐B给A。

A查看后Pass。

系统记录：

source = matchmaker
action = passed

后续不要不断由其他红娘重复推荐B。

---

第一百五十五章 V1明确不建设

不建设：

• 深度学习推荐
• 协同过滤
• AI婚恋预测
• LLM自动决定对象
• 人脸颜值评分
• 财富评分
• “高价值用户”标签
• 用户等级
• 热门榜
• 付费曝光
• 超级喜欢
• Boost
• AI聊天代聊

---

第一百五十六章 匹配系统开发优先级

P0

Eligibility
Required双向过滤
DirectionalScore
MutualScore
RecommendationReason
每日推荐
Like/Pass排除

---

P1

曝光控制
新用户修正
活跃度修正
对方已喜欢轻度Boost
红娘候选

---

P2

长期无结果分析
候选池健康度
规则效果对比
更完善的运营统计

---

第一百五十七章 推荐系统代码验收标准

任何算法版本必须：

• 相同输入得到稳定结果
• Required绝不被软分覆盖
• 双向评分
• 规则可配置
• 规则版本化
• 推荐理由可解释
• 不访问不需要的敏感数据
• Block即时生效
• 用户状态即时生效
• 有单元测试

---

第一百五十八章 公益红娘协同验收标准

必须做到：

红娘不需要从全部用户中盲目搜索。

系统先提供合格候选。

红娘可以理解为什么推荐。

红娘不能突破用户硬条件。

红娘不能替用户喜欢。

红娘不能私自提供联系方式。

红娘每次推荐都有记录。

---

第一百五十九章 V1核心算法公式最终确定

候选资格：

Eligible
AND
Required(A→B)
AND
Required(B→A)

方向评分：

Score(A→B) = Σ DimensionScore × Weight

双向综合：

MutualScore =
0.6 × min(ScoreAB, ScoreBA)
+
0.4 × average(ScoreAB, ScoreBA)

排序：

RankingScore =
MutualScore
+ SmallPositiveAdjustments
- ExposureAndRepeatPenalty

---

第一百六十章 最终设计原则

V1.0匹配系统必须坚持：

先排除不合适，再判断谁更合适。

双方条件同等重要。

用户“必须符合”的条件系统不得偷偷修改。

评分是排序工具，不是假装预测婚姻幸福。

推荐必须能解释。

兴趣只能辅助，不能替代核心婚恋条件。

不能根据财富、外貌、人气给用户隐性分级。

算法负责大规模初筛，红娘负责复杂人工辅助。

红娘不能突破系统安全和用户自主权。

最终喜欢谁、是否聊天、是否进一步交往，始终由用户本人决定。

整个V1.0匹配机制最终可以概括为：

规则筛得准，双方都合适，红娘帮得上，用户自己选。