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

# 丹阳公益婚恋服务平台
# V1.0 匹配推荐算法与公益红娘协同机制详细设计

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

---

# 第一章 设计目标

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

核心目标只有五个：

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

因此V1.0采用：

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

而不是：

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

---

# 第二章 匹配系统总体结构

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

---

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

必须是：

> **双向匹配。**

不是：

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

而是：

```text
A符合B吗？
+
B符合A吗？
```

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

---

# 第四章 条件分两级

用户择偶条件统一分为：

## 4.1 Required

前端：

> 必须符合

含义：

> 不符合则直接淘汰。

---

## 4.2 Preferred

前端：

> 最好符合

含义：

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

---

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

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

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

其中最核心：

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

---

# 第六章 不进入算法的字段

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

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

避免让产品走向：

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

---

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

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

候选人B必须满足：

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

---

# 第八章 必须排除的关系

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

直接排除：

```text
A blocked B
B blocked A

A passed B且仍处于冷却期

A与B已经successful

A与B已有active match

B账号风险受限

B暂停寻找

B退出婚恋服务
```

---

# 第九章 已经喜欢的用户

如果：

```text
A liked B
```

但B未回应。

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

应该进入：

> 我喜欢的。

避免重复展示。

---

# 第十章 对方已喜欢A

如果：

```text
B liked A
```

A还没有处理。

这类用户可以给予：

> 适度排序提升。

但不能直接告诉A：

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

除非在：

> 喜欢我的

模块明确展示。

---

# 第十一章 性别匹配规则

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

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

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

```text
preferred_gender
```

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

---

# 第十二章 年龄Required判断

例如A要求：

```text
28～35
required
```

如果B年龄：

```text
32
```

则通过。

如果：

```text
36
```

直接淘汰。

---

# 第十三章 年龄Preferred评分

例如：

```text
28～35
preferred
```

建议评分：

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

具体梯度配置化。

---

# 第十四章 身高规则

Required：

> 不在范围直接淘汰。

Preferred：

可按偏差计算。

例如：

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

---

# 第十五章 地区规则

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

建议支持：

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

未来可扩展省市区代码。

---

# 第十六章 地区匹配等级

示例：

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

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

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

---

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

单纯看当前居住地不够。

例如：

A在丹阳。

B现在在南京，但：

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

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

因此地区建议拆：

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

---

# 第十八章 婚姻状态规则

用户可选：

```text
未婚
离异
丧偶
```

Required：

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

Preferred：

> 符合则加分。

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

例如：

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

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

---

# 第十九章 子女情况

不要把：

> 有子女

默认设计成扣分。

正确规则：

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

例如：

```text
接受
不接受
视情况
```

---

# 第二十章 学历

学历作为较低权重条件。

原因：

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

因此即便用户设置Preferred：

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

---

# 第二十一章 婚姻计划

婚姻计划是重要字段。

例如：

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

建议匹配距离模型。

---

# 第二十二章 婚姻计划距离

例如：

```text
A：1年内
B：1年内
```

100%。

```text
A：1年内
B：1～2年
```

80%。

```text
A：半年内
B：2年以上
```

20%或更低。

---

# 第二十三章 定居意愿

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

例如：

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

双方：

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

即使其他条件很好：

也应该低分或直接排除。

---

# 第二十四章 吸烟与饮酒

属于生活方式匹配。

建议低～中权重。

不要做社会价值判断。

只是：

> 是否符合对方偏好。

---

# 第二十五章 兴趣匹配

兴趣：

> 不是必要条件。

计算：

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

可采用Jaccard Similarity：

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

例如：

A：

```text
旅行 阅读 运动 电影
```

B：

```text
旅行 运动 美食
```

共同：

```text
旅行 运动
```

用于低权重加分。

---

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

兴趣相同：

> 不代表适合结婚。

所以V1建议兴趣：

> 5分左右。

主要用于：

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

---

# 第二十七章 生活方式评分

可以由以下字段组成：

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

V1如果用户资料量不足：

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

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

---

# 第二十八章 V1建议权重

推荐默认100分：

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

这是系统默认权重。

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

---

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

V1建议：

用户只选择：

```text
必须符合
最好符合
```

不让普通用户自己调：

```text
年龄权重17
学历权重8
```

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

---

# 第三十章 单方向适配分

定义：

```text
Score(A→B)
```

表示：

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

例如：

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

Score(A→B)=92
```

---

# 第三十一章 双方向评分

还必须算：

```text
Score(B→A)
```

例如：

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

不能只展示92。

---

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

不建议简单：

```text
(92 + 78) / 2 = 85
```

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

建议V1采用：

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

---

# 第三十三章 综合公式示例

例如：

```text
A→B = 92
B→A = 78
```

则：

```text
min = 78
average = 85

MutualScore
= 0.6×78 + 0.4×85
= 80.8
```

这样可以体现：

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

---

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

如果：

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

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

因此：

> 最低分主导 + 平均分修正

更适合V1。

---

# 第三十五章 Required不参与补偿

重要：

> 不符合Required，直接淘汰。

不能：

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

这是错误的。

---

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

```text
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
    }
```

---

# 第三十七章 最低推荐阈值

建议初始：

```text
MutualScore >= 60
```

才能进入普通推荐候选。

后台可配置。

---

# 第三十八章 推荐等级

建议：

```text
85～100
很合适

70～84
比较合适

60～69
值得了解

<60
默认不推荐
```

前台：

> 不显示数字。

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

---

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

不要显示：

```text
匹配度92%
```

原因：

这会让用户误以为：

> 92%概率适合结婚。

实际上只是规则评分。

因此前台建议：

```text
比较合适
值得了解
```

更加诚实。

---

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

推荐理由必须：

> 来自真实数据。

不能让AI编。

---

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

优先展示：

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

---

# 第四十二章 推荐理由示例

```text
年龄符合双方的择偶要求

你们都长期生活在丹阳

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

双方都不吸烟

你们都喜欢运动和旅行
```

---

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

避免：

```text
系统认为你们很般配

AI判断你们适合结婚

成功概率86%

条件等级相近

经济实力匹配
```

---

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

首页：

> 3条。

详情：

> 最多4条。

不要展示十几条。

---

# 第四十五章 每日推荐策略

建议默认：

```text
6人/天
```

后台配置：

```text
5～10
```

不要做：

> 无限刷人。

---

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

公益婚恋平台核心不是：

> 增加刷卡时长。

而是：

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

数量少还有利于：

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

---

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

推荐两种：

## 方式A

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

早期用户少：

> 完全可行。

## 方式B

每日提前生成推荐池。

用户量增大后：

> 推荐使用。

V1技术可以先：

> 候选实时计算 + Redis缓存。

---

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

候选池按照：

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

综合排序。

---

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

活跃用户可以稍微靠前。

但不能：

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

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

---

# 第五十章 活跃状态建议

例如：

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

如果长期不活跃：

> 暂停推荐曝光。

具体周期后台配置。

---

# 第五十一章 新用户冷启动

新用户刚审核通过。

没有行为数据。

直接使用：

> Profile + Preferences规则匹配。

不需要行为推荐。

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

---

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

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

> 轻度新鲜度加权。

例如：

```text
前7天
+少量排序修正
```

目的：

> 避免新人长期没有曝光。

不能过度加权。

---

# 第五十三章 曝光公平性

如果只按最高分排序：

少数高分用户可能：

> 每天被大量推荐。

其他人没人看到。

因此需要：

> Exposure Balance。

---

# 第五十四章 曝光控制

建议记录：

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

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

> 轻微降权。

---

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

仍然应该：

> 匹配度优先。

公平性只是：

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

---

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

可以定义内部：

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

---

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

例如：

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

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

---

# 第五十八章 ReciprocityBoost

如果B已经喜欢A：

可以：

```text
+3
```

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

这可以提高：

> 双向匹配效率。

但不能绕过Required。

---

# 第五十九章 RepeatPenalty

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

应该降权。

例如：

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

如果用户明确Pass：

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

---

# 第六十章 推荐冷却机制

建议：

### 仅曝光未操作

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

### 用户Pass

较长冷却。

建议：

> 180天可配置。

### Unmatch

默认长期排除。

### Block

直到用户主动解除。

---

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

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

> 符合条件的人很少。

系统不能擅自放宽：

> Required。

---

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

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

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

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

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

---

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

运营管理员不能：

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

这是用户明确偏好。

只有用户本人：

> 修改。

---

# 第六十四章 Preferred自动放宽

Preferred允许系统做适度容忍。

例如：

年龄最好：

```text
30～35
```

可逐步考虑：

```text
29或36
```

但得分下降。

---

# 第六十五章 放宽顺序

建议按影响从低到高：

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

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

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

---

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

每日推荐：

> 系统主动精选。

找对象：

> 用户主动筛选。

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

---

# 第六十七章 找对象排序

默认：

```text
综合推荐
```

可后续提供：

```text
最近活跃
年龄
```

V1不建议增加太多排序。

---

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

例如用户临时筛：

> 30～32岁。

只影响当前Find结果。

不能覆盖：

> 我的择偶条件。

---

# 第六十九章 红娘候选算法

公益红娘工作台调用：

> 同一个Match Engine。

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

---

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

建议：

```text
王女士 32岁

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

Required：
全部符合

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

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

---

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

可以多看到：

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

目的是：

> 帮助人工判断。

---

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

不能因为匹配工作看到：

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

---

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

流程：

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

---

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

算法难以完全处理：

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

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

> 人工辅助判断。

---

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

再次强调：

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

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

应：

> 建议用户修改。

用户确认修改后：

> 重新计算。

---

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

红娘可以说：

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

用户可以：

```text
接受
拒绝
```

只有用户接受：

> 系统更新条件。

---

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

后台不能提供：

> 直接替用户改择偶条件

普通按钮。

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

必须：

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

V1建议仍由用户本人改。

---

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

例如A：

> 希望红娘帮我联系B。

系统：

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

---

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

红娘不能：

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

正确：

> 平台内发起意向。

---

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

推荐记录：

```text
source = matchmaker
```

与：

```text
daily
discover
activity
```

区分。

方便后续统计：

> 哪种方式转化更好。

---

# 第八十一章 红娘效果评价

不要只看：

> 红娘推荐了多少人。

建议看：

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

---

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

V1不建议：

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

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

---

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

后台建议：

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

管理员据此分配。

---

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

系统可以识别：

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

标记：

> 可关注。

---

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

系统可给红娘提示：

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

不能写：

> “用户条件太差”。

---

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

资料未完整：

> 本就不能审核通过。

审核后仍有选填项缺失：

不应该直接重罚。

但信息越完整：

> 推荐理由可能更充分。

---

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

不能因为：

> 上传6张照片

就比：

> 只上传2张照片

获得明显匹配加分。

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

照片主要影响：

> 用户自己判断。

不是算法核心分。

---

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

禁止：

```text
被喜欢越多
→ 排名越高
```

否则会形成：

> 马太效应。

---

# 第八十九章 热门用户控制

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

系统可以：

> 降低曝光频率。

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

---

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

核心指标：

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

但不能只优化这个指标。

---

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

长期真正关注：

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

V1先把数据记录好。

---

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

如果只优化：

> 用户点击喜欢。

可能会把系统变成：

> 外貌刷人产品。

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

---

# 第九十三章 用户反馈闭环

推荐后行为：

```text
查看
喜欢
Pass
Match
Unmatch
成功
```

都记录。

未来可以优化规则。

但V1不做自动机器学习。

---

# 第九十四章 Pass原因V1策略

前面已确定：

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

因此算法不能依赖：

> Pass原因。

减少用户操作负担。

---

# 第九十五章 Unmatch原因可用

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

可以作为：

> 运营分析数据。

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

---

# 第九十六章 推荐规则版本

每条RecommendationRecord应记录：

```text
rule_version
```

例如：

```text
v1
v2
```

以后修改权重：

可以比较效果。

---

# 第九十七章 权重修改流程

后台管理员：

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

不直接覆盖旧版本。

---

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

记录：

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

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

---

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

V1：

> 不需要复杂A/B平台。

如果以后需要：

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

V1先：

> 一个正式规则版本。

---

# 第一百章 算法解释接口

后端建议：

```text
MatchResult {
  scoreAB
  scoreBA
  mutualScore
  level
  reasons
  requiredChecks
  preferredChecks
}
```

普通用户DTO：

只返回：

```text
level
reasons
```

红娘DTO：

可增加：

```text
requiredChecks
preferredChecks
```

---

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

```text
MatchEligibilityService
RequiredConditionService
DirectionalScoringService
MutualScoringService
RecommendationReasonService
RankingService
ExposureControlService
RecommendationHistoryService
```

不一定拆成独立微服务。

都可在Match模块内。

---

# 第一百零二章 MatchEligibilityService

负责：

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

---

# 第一百零三章 RequiredConditionService

负责：

```text
A Required → B
B Required → A
```

必须纯规则、可测试。

---

# 第一百零四章 DirectionalScoringService

负责：

```text
Score(A→B)
```

输入：

```text
A preference
B profile
active rule config
```

输出：

```text
dimension scores
total
```

---

# 第一百零五章 MutualScoringService

负责公式：

```text
0.6 × min
+
0.4 × avg
```

后续公式如果变化：

> 不影响前端。

---

# 第一百零六章 ReasonService

只从：

> 已经通过的真实匹配字段

生成说明。

不能独立“创造”理由。

---

# 第一百零七章 RankingService

处理：

```text
MutualScore
+
Freshness
+
Activity
+
Reciprocity
-
Exposure
-
Repeat
```

最终输出顺序。

---

# 第一百零八章 ExposureControlService

维护：

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

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

---

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

数据库先做：

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

例如先得到：

> 100～500个候选。

再在应用层计算。

---

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

不要把所有：

```text
CASE WHEN...
CASE WHEN...
```

都塞SQL。

V1：

> SQL过滤 + 应用层评分

更容易维护和测试。

---

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

可缓存：

```text
recommendation:{userId}:{date}
```

内容：

> 排序后的候选ID。

详情数据：

> 实时/短缓存读取。

---

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

以下事件发生：

立即使相关缓存失效：

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

---

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

即使缓存中有B：

真正返回卡片前：

> 再做轻量Eligibility检查。

避免：

> B刚暂停，A仍然看到。

---

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

丹阳本地早期：

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

目标：

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

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

---

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

每个维度至少测试：

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

---

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

必须测试：

```text
A接受B
B不接受A
```

结果：

> REJECT。

不是：

> 仍推荐给A。

---

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

例如：

A：

```text
丹阳 required
```

B：

```text
南京
未来愿意丹阳
```

如果A要求的是：

> 当前居住地丹阳

则失败。

如果A要求的是：

> 未来定居丹阳

则按对应字段判断。

字段含义必须清楚。

---

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

对于非必填选项：

候选人没有填写。

不能默认：

> 符合。

建议：

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

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

具体按字段定义。

---

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

例如：

A：

> 不接受吸烟者，Required。

B：

> 没填吸烟状态。

系统不能假设：

> B不吸烟。

否则违反用户硬条件。

---

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

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

可以提示用户：

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

而不是系统猜测。

---

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

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

```text
user_id
target_id
rule_version
mutual_score
reasons
shown_at
source
```

后续有投诉：

可以知道：

> 当时为什么推荐。

---

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

不要保存：

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

这些都不属于V1。

---

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

红娘人工推荐必须记录：

```text
operator
user
target
reason
time
service_id
```

---

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

建议：

> 基于资料事实。

例如：

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

不要写：

```text
我觉得你们一定很合适。
```

---

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

系统负责：

```text
筛
算
排
解释
```

红娘负责：

```text
看
判断
沟通
辅助
跟进
```

用户负责：

```text
最终决定
```

---

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

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

---

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

红娘存在的价值不是：

> 算法不行，所以全人工。

而是：

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

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

---

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

V1可以轻量提示：

如果用户：

```text
30天无Mutual Match
```

且活跃：

首页提示：

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

但：

> 不自动创建红娘服务。

用户自己申请。

---

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

V1建议：

> 默认用户申请后介入。

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

必须有：

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

没有同意：

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

---

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

每日一次主推荐即可。

不建议：

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

避免打扰。

---

# 第一百三十一章 推荐通知

可以有：

> 今天有新的合适推荐。

但不是：

> 每个候选人一个通知。

降低骚扰感。

---

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

正确：

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

可以：

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

不要：

> 你的条件太高。

---

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

系统可计算：

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

可以判断：

> 条件较严格。

文案：

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

---

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

不需要AI。

可以规则提示：

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

按钮：

> 查看择偶条件。

---

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

不要使用：

> 降低要求

文案。

建议：

> 调整条件

> 扩大了解范围

更加尊重用户。

---

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

未来可增加：

```text
AICompatibilityService
```

但它只能：

> 作为额外排序信号。

不能替代：

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

---

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

未来：

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

而不是：

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

---

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

未来也不能对用户输出：

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

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

---

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

运营后台建议：

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

---

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

本地平台需要关注：

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

但只是：

> 运营参考。

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

---

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

后台可以显示：

例如：

```text
30～35岁男性
有效候选 83

30～35岁女性
有效候选 61
```

帮助公益组织：

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

---

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

建议：

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

不建议只统计：

> 电话打了多少个。

---

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

只有：

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

可修改。

普通红娘：

> 只读。

---

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

新规则出现异常：

后台支持：

> 激活旧版本。

不要现场改数据库权重。

---

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

系统自动检查：

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

---

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

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

---

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

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

---

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

A条件：

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

B：

```text
32
丹阳
大专
```

A→B：

> Required通过。

学历Preferred不满足：

> 扣相应分。

仍可推荐。

---

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

A要求B符合。

但B要求：

```text
年龄40～45 Required
```

A只有36。

即使A非常喜欢B：

> 系统不应推荐。

因为：

> B的Required不接受A。

---

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

系统评分：

```text
A→B 95
B→A 62
```

不能显示：

> 95分超高匹配。

最终双向分应明显受到：

> 62

影响。

---

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

A Pass B。

B第二天高分候选。

仍：

> 不应该重新推荐给A。

必须遵守冷却。

---

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

A Block B。

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

系统必须：

> 排除。

不能靠红娘记忆。

---

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

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

系统：

> 不偷偷放宽。

而是：

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

---

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

红娘推荐B给A。

A查看后Pass。

系统记录：

```text
source = matchmaker
action = passed
```

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

---

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

不建设：

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

---

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

## P0

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

---

## P1

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

---

## P2

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

---

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

任何算法版本必须：

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

---

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

必须做到：

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

> 系统先提供合格候选。

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

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

> 红娘不能替用户喜欢。

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

> 红娘每次推荐都有记录。

---

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

候选资格：

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

方向评分：

```text
Score(A→B) = Σ DimensionScore × Weight
```

双向综合：

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

排序：

```text
RankingScore =
MutualScore
+ SmallPositiveAdjustments
- ExposureAndRepeatPenalty
```

---

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

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

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

> **双方条件同等重要。**

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

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

> **推荐必须能解释。**

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

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

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

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

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

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

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