danyang-match/丹阳公益婚恋服务平台 产品详细功能架构设计 V1.0.md

# 丹阳公益婚恋服务平台
## 产品详细功能架构设计 V1.0

---

# 一、产品定位

本产品定位为：

> 面向丹阳市成年单身人士，由妇联、工会、民政相关公益活动、公益服务中心、志愿者团队等共同参与运营的公益婚恋服务平台。

平台坚持：

- 用户永久免费
- 实名认证
- 人工资料审核
- 丹阳本地优先
- 双向喜欢后聊天
- 系统推荐与人工牵线结合
- 线上匹配与线下公益活动结合
- 不以提高用户停留时长为目标
- 以真实、安全、高效促成婚恋关系为目标

核心价值：

> **让真实的单身人士，更安全、更高效地找到合适的人。**

---

# 二、产品总体架构

整个系统建议由四个主要端组成。

| 系统 | 主要使用人 |
|---|---|
| 微信小程序用户端 | 单身用户 |
| 公益红娘工作台 | 红娘、工作人员 |
| 运营管理后台 | 公益组织运营人员、管理员 |
| 平台管理后台 | 超级管理员、系统维护人员 |

整体关系：

```text
                 丹阳公益婚恋服务平台
                         │
        ┌────────────────┼────────────────┐
        │                │                │
   用户微信小程序     公益红娘工作台     管理后台
        │                │                │
        └────────────────┼────────────────┘
                         │
                    业务服务层
                         │
 ┌────────┬────────┬────────┬────────┬────────┐
 │用户中心│认证审核│匹配推荐│聊天消息│活动中心│
 ├────────┼────────┼────────┼────────┼────────┤
 │红娘服务│举报风控│状态管理│数据统计│权限管理│
 └────────┴────────┴────────┴────────┴────────┘
                         │
                      数据中心
```

---

# 三、用户端小程序总体结构

用户端一级导航建议严格控制为五个：

> **首页｜找对象｜消息｜活动｜我的**

不增加额外一级菜单。

这样可以确保首次使用者不需要学习。

---

# 四、用户首次进入流程

首次使用必须采用明显的任务引导，而不是让用户自己摸索。

完整流程：

```text
微信进入小程序
    ↓
微信登录
    ↓
阅读并同意服务协议、隐私政策
    ↓
实名认证
    ↓
完善基本资料
    ↓
上传头像/照片
    ↓
填写个人介绍
    ↓
填写择偶条件
    ↓
提交人工审核
    ↓
等待审核
    ↓
审核通过
    ↓
正式进入推荐系统
```

这里建议采用：

> **一步一页 + 明确进度**

例如：

```text
完善资料 2/5
████████░░
```

不要在一个页面放几十项表单。

---

# 五、首页模块

## 5.1 首页核心目标

用户打开小程序后的第一件事情应该是：

> 看今天有没有合适的人。

而不是：

- 看新闻
- 看活动广告
- 看社区
- 看运营Banner
- 看公益组织宣传

因此首页必须以推荐为核心。

---

## 5.2 首页结构

### 顶部区域

显示：

```text
上午好，张先生

今天为你推荐 6 位合适的朋友
```

辅助入口：

> 筛选推荐

---

### 推荐用户卡片

基本展示：

```text
头像

王女士
32岁 · 165cm
丹阳 · 本科
教师
未婚

已实名
资料已审核
```

推荐理由：

```text
为什么推荐给你？

✓ 年龄符合双方择偶要求
✓ 都希望在丹阳长期生活
✓ 双方婚姻状态符合
✓ 生活方式比较接近
```

操作只保留三个：

> 不合适  
> 查看资料  
> 喜欢

---

## 5.3 今日推荐

V1建议采用每日推荐机制。

例如：

普通用户每天推荐：

> 5～10位

具体数量后续可以在运营后台配置。

不建议无限刷人。

公益平台不需要制造“刷卡上瘾”。

---

## 5.4 推荐结束

当天推荐浏览完毕以后显示：

```text
今天的推荐看完啦

可以去“找对象”
看看更多符合条件的人
```

两个入口：

> 找对象

> 申请红娘帮我推荐

---

# 六、找对象模块

首页解决系统推荐。

“找对象”解决用户主动寻找。

---

# 七、基础筛选

默认显示最重要的条件：

| 条件 | 示例 |
|---|---|
| 年龄 | 28～35岁 |
| 身高 | 160～175cm |
| 地区 | 丹阳 |
| 婚姻状况 | 未婚 / 离异 |
| 学历 | 大专及以上 |
| 是否有子女 | 不限 |

底部：

> 更多条件

---

# 八、高级筛选

展开以后可以包括：

- 职业
- 是否吸烟
- 是否饮酒
- 是否接受异地
- 是否接受有子女
- 计划多久结婚
- 是否愿意长期定居丹阳
- 兴趣爱好
- 生活方式

V1不要超过大约15个有效筛选维度。

---

# 九、搜索结果页

采用卡片列表。

不要使用非常复杂的信息展示。

每个用户卡片只显示：

```text
头像

李女士 · 31岁

165cm · 本科
丹阳 · 医疗行业

未婚 · 无子女

已实名 ✓

[查看资料]
```

可以显示：

> 符合你 7 项择偶条件

不要显示：

> AI匹配89.21%

---

# 十、个人详情页

个人详情页是整个平台最重要的页面之一。

结构建议：

## 第一屏：核心信息

头像、年龄、地区、职业等。

示例：

```text
王女士

32岁 · 165cm
丹阳
本科
教师

已实名 ✓
资料已审核 ✓
```

按钮：

> ♡ 喜欢

---

## 第二部分：关于我

展示：

- 婚姻状况
- 是否有子女
- 职业
- 学历
- 工作地区
- 居住地区
- 是否吸烟
- 是否饮酒

---

## 第三部分：我的介绍

例如：

> 性格比较开朗，平时喜欢旅行、看电影，也喜欢周末陪父母，希望认识一个认真、稳定、愿意共同经营家庭的人。

---

## 第四部分：我的生活

采用少量照片。

建议：

> 最多6～9张。

不是无限动态。

---

## 第五部分：兴趣标签

例如：

```text
旅行
电影
摄影
跑步
美食
```

---

## 第六部分：我的婚恋态度

例如：

```text
寻找：以结婚为目的的稳定关系

希望结婚时间：
1～2年内

是否愿意长期生活在丹阳：
愿意
```

---

## 第七部分：我的择偶期待

展示经过隐私处理后的核心条件。

例如：

```text
希望年龄：
30～38岁

希望地区：
丹阳 / 镇江

婚姻状况：
不限

最重要：
性格稳定、认真对待婚姻
```

不需要把所有筛选条件公开。

---

# 十一、“喜欢”体系

喜欢关系非常简单。

存在三种状态：

```text
我喜欢TA
TA喜欢我
互相喜欢
```

---

# 十二、喜欢后的交互

用户点击：

> 喜欢

出现轻提示：

```text
已表达喜欢

如果对方也喜欢你
即可开始聊天
```

不通知：

> XX刚刚偷偷喜欢了你

可以在“喜欢我的人”中看到。

---

# 十三、双向匹配机制

如果A喜欢B，同时B喜欢A：

系统生成：

> Match关系

然后双方收到：

```text
🎉 你们互相喜欢

可以开始聊天了解彼此了
```

按钮：

> 开始聊天

---

# 十四、不喜欢机制

用户点击：

> 不合适

系统记录：

```text
A → B 不感兴趣
```

默认一段时间内不再推荐。

后续管理员可以配置，例如：

> 180天内不重复推荐。

---

# 十五、“喜欢”中心

可以放在：

> 我的 → 我的缘分

里面分三个Tab：

```text
互相喜欢

我喜欢的

喜欢我的
```

其中：

### 互相喜欢

可以聊天。

### 我喜欢的

等待对方回应。

### 喜欢我的

用户可以：

> 喜欢TA

或者：

> 暂不考虑

---

# 十六、消息中心

消息分成两个类别：

### 聊天

### 系统通知

不需要更多分类。

---

# 十七、聊天功能

V1建议支持：

- 文字
- 图片
- 表情
- 系统安全提醒

暂时不要做：

- 视频聊天
- 语音通话
- 文件传输
- 红包
- 转账
- 礼物

---

# 十八、聊天安全机制

聊天窗口顶部固定轻提示：

> 请注意保护个人隐私，谨慎涉及转账、借款、投资等资金往来。

检测到高风险关键词时，例如：

```text
投资
转账
银行卡
借钱
博彩
贷款
```

弹出风险提示。

但不要拦截正常交流。

---

# 十九、解除匹配

聊天以后用户可以：

> 解除匹配

系统询问：

```text
确定不再继续了解吗？
```

可选原因：

- 感觉不合适
- 沟通不顺畅
- 已有其他对象
- 对方让我不舒服
- 其他

如果涉及：

> 骚扰 / 欺诈 / 不安全

直接引导：

> 举报

---

# 二十、举报机制

每个用户详情和聊天页面必须有：

> 举报

举报类型建议包括：

| 举报原因 | 处理等级 |
|---|---|
| 虚假资料 | 中 |
| 婚姻状态疑似虚假 | 高 |
| 骚扰 | 高 |
| 色情低俗 | 高 |
| 广告营销 | 中 |
| 诈骗 | 极高 |
| 金钱诱导 | 极高 |
| 冒充他人 | 极高 |
| 其他 | 人工判断 |

举报进入后台人工审核。

---

# 二十一、拉黑机制

拉黑后：

- 双方不能聊天
- 不再互相推荐
- 不再出现在搜索结果中
- 不再看到对方资料

后台保留关系记录。

---

# 二十二、活动模块

“活动”作为一级入口。

核心目标：

> 将线上用户导入真实、安全、可信任的线下婚恋场景。

---

# 二十三、活动首页

显示：

### 即将开始

例如：

```text
2026丹阳青年公益相亲会

时间
9月20日 14:00

地点
丹阳市××活动中心

报名人数
86人

公益免费

[立即报名]
```

---

# 二十四、活动详情

包含：

- 活动名称
- 活动介绍
- 时间
- 地点
- 主办单位
- 承办单位
- 适合人群
- 报名要求
- 活动流程
- 注意事项

操作：

> 立即报名

---

# 二十五、活动报名

因为用户已经有婚恋资料，因此尽量：

> 一键报名。

系统只确认：

```text
手机号
真实姓名
紧急联系人（视活动需要）
是否同意现场活动规则
```

避免重复填资料。

---

# 二十六、活动报名审核

工作人员后台可以：

> 通过

> 驳回

驳回必须填写原因。

例如：

```text
报名信息不完整

实名认证未完成

不符合本场活动年龄范围
```

---

# 二十七、活动签到

建议采用：

> 工作人员扫码签到

用户打开：

> 我的活动 → 签到码

工作人员扫描完成签到。

---

# 二十八、活动后反馈

活动结束后：

```text
这次活动体验如何？

非常满意
满意
一般
不满意
```

并询问：

> 是否遇到想进一步认识的人？

如果双方都确认：

可以自动建立：

> 活动匹配关系

---

# 二十九、公益红娘模块

公益红娘不是普通客服。

定义为：

> 帮助用户提高匹配成功率的人工辅助角色。

---

# 三十、用户申请红娘帮助

入口建议放：

首页：

> 没找到合适的人？公益红娘可以帮你。

或者：

我的 → 公益红娘

---

# 三十一、红娘服务类型

用户申请时选择：

```text
帮我推荐合适的人

帮我看看择偶条件

帮我联系意向对象

想参加线下活动

匹配很久没有结果

不知道怎么开始聊天

其他
```

提交后进入工作台。

---

# 三十二、红娘工作台

红娘首页：

```text
今日待处理        8

新服务申请        3

待跟进用户        12

待回复用户        5

我的牵线          28
```

必须简单。

---

# 三十三、红娘用户详情

红娘只能看到其工作所需的信息。

展示：

- 用户公开婚恋资料
- 择偶要求
- 用户匹配状态
- 已推荐人数
- 用户反馈
- 最近跟进情况

不能默认显示：

- 身份证完整号码
- 身份证照片
- 后台敏感数据
- 非必要私人信息

---

# 三十四、人工匹配

红娘可以点击：

> 帮TA找对象

系统根据用户条件推荐候选人。

例如：

```text
系统推荐候选人 18位
```

红娘筛选：

> 王女士

然后：

> 推荐给张先生

系统通知张先生：

```text
公益红娘为你推荐了一位朋友

推荐理由：
年龄、地区和婚恋目标比较符合

[查看资料]
```

注意：

红娘只能“推荐”。

不能替用户：

> 自动喜欢对方。

最终决定权必须归用户。

---

# 三十五、人工牵线

假设：

张先生喜欢王女士，但王女士没有回应。

用户可以申请：

> 请红娘协助联系

红娘可以向王女士发送系统通知：

```text
公益红娘提示：

有一位与你择偶条件比较符合的用户希望进一步认识你。

是否愿意查看？
```

仍然由王女士决定。

不能强制撮合。

---

# 三十六、红娘跟进记录

每次工作必须记录：

```text
2026-08-28

电话沟通

用户近期工作较忙，暂不参加活动。

下次跟进：
9月10日
```

形成服务档案。

---

# 三十七、用户婚恋状态体系

这是平台的重要设计。

建议定义：

| 状态 | 含义 |
|---|---|
| 正在寻找 | 正常参与推荐 |
| 正在了解 | 正在和某人深入接触 |
| 暂停寻找 | 暂停推荐 |
| 成功牵手 | 已建立关系 |
| 已婚/退出 | 不再使用婚恋功能 |

---

# 三十八、“正在了解”状态

如果用户与某个对象已经深入了解，可以：

> 设置为正在了解

系统询问：

```text
是否暂停其他对象推荐？
```

用户选择：

> 是

平台就停止推荐。

这样更符合真实婚恋逻辑。

---

# 三十九、成功牵手

用户可以点击：

> 我已成功牵手

如果是平台内对象：

选择对方。

系统向另一方确认。

双方确认后：

```text
❤️ 恭喜你们成功牵手

平台将暂停双方的婚恋推荐
```

---

# 四十、成功案例

平台可以询问：

> 是否愿意匿名分享你们的故事？

默认：

> 不公开。

只有用户主动授权才能展示。

---

# 四十一、我的模块

“我的”页面建议结构：

```text
头像
张先生

已实名 ✓
资料已审核 ✓

资料完整度 85%

──────────

我的资料

我的择偶条件

我的缘分

公益红娘

我的活动

──────────

我的认证

隐私设置

黑名单

意见反馈

帮助中心

关于平台
```

---

# 四十二、资料完整度

可以显示：

> 85%

告诉用户：

```text
再完善2项资料
可以获得更准确推荐
```

但不要：

- 给积分
- 给金币
- 做签到任务

避免游戏化。

---

# 四十三、认证体系

V1确定：

### 强制认证

- 微信登录
- 手机号
- 身份实名认证

### 人工审核

- 头像
- 用户照片
- 基本资料
- 自我介绍

---

# 四十四、认证状态

用户侧显示：

```text
已实名认证 ✓

资料已人工审核 ✓
```

不直接展示：

> 身份证实名

等过度暴露的信息。

---

# 四十五、审核机制

提交后：

```text
资料审核中

工作人员正在审核你的资料
审核通过后即可开始匹配
```

审核结果：

### 通过

进入正常推荐。

### 需修改

告诉用户：

```text
头像无法确认本人

请重新上传清晰本人照片
```

### 拒绝

严重违规时拒绝。

---

# 四十六、后台用户审核中心

审核列表：

```text
待审核 18

今日已审核 26

需补充资料 5

异常资料 2
```

审核页面采用：

> 左边资料

> 右边操作

工作人员快速审核。

---

# 四十七、人工审核检查项

审核人员主要判断：

- 是否本人真实头像
- 是否明显网图
- 是否存在联系方式引流
- 是否出现广告
- 是否出现低俗内容
- 基础资料是否明显矛盾
- 年龄与身份认证是否一致
- 是否存在异常婚恋信息

---

# 四十八、后台总体架构

后台建议一级菜单：

```text
工作台

用户管理

资料审核

匹配管理

红娘服务

活动管理

举报风控

成功案例

内容管理

数据统计

组织人员

权限管理

系统设置
```

---

# 四十九、后台工作台

工作人员登录第一眼看到：

```text
今日新增用户      18

待审核资料        12

红娘待处理        8

活动报名待审核    16

待处理举报        2

昨日匹配成功      7
```

下面显示：

> 我的待办事项

这样工作人员不需要到处找任务。

---

# 五十、用户管理

支持查询：

- 姓名
- 手机号
- 年龄
- 性别
- 区域
- 注册时间
- 认证状态
- 审核状态
- 婚恋状态
- 风险状态

用户详情：

```text
基础资料

认证信息

择偶条件

匹配记录

聊天风险记录

活动记录

红娘服务记录

举报记录

状态变更记录
```

---

# 五十一、匹配管理

后台可以看到：

```text
今日系统推荐

今日新增喜欢

今日双向匹配

当前聊天关系

解除匹配数量

成功牵手数量
```

工作人员通常只看统计。

不应该随意查看私人聊天内容。

---

# 五十二、聊天隐私原则

建议从产品设计阶段确定：

> 管理员默认无权查看用户完整私人聊天记录。

只有：

- 用户举报
- 风控命中
- 法律要求
- 明确的安全事件

在严格权限和操作留痕机制下才能调取必要内容。

避免后台工作人员随意查看用户私人交流。

---

# 五十三、举报风控中心

显示：

```text
待处理举报

高风险用户

重复被举报用户

疑似广告账号

疑似诈骗账号

被大量拉黑用户
```

风险等级：

```text
正常
关注
高风险
封禁
```

---

# 五十四、风险评分

V1不需要复杂AI。

简单规则即可。

例如：

```text
被3人举报
+30

短时间大量喜欢
+10

多人举报诈骗
+50

频繁发送联系方式
+15

多人拉黑
+20
```

达到阈值：

> 自动进入人工审核。

不要自动直接封号。

严重明确违规除外。

---

# 五十五、活动管理后台

工作人员可以：

```text
创建活动

编辑活动

发布活动

暂停报名

查看报名

审核报名

签到管理

名单导出

活动反馈

活动复盘
```

---

# 五十六、活动人员管理

后台可实时看到：

```text
报名人数 108

男 55
女 53

审核通过 96

待审核 12

已签到 86
```

这对于妇联、工会、公益活动非常实用。

---

# 五十七、组织和人员体系

由于未来可能有多类公益组织参与，因此后台必须支持组织。

例如：

```text
丹阳市妇联

某某工会

某公益服务中心

某志愿者团队
```

人员归属组织。

---

# 五十八、后台角色

建议V1至少定义：

| 角色 | 职责 |
|---|---|
| 超级管理员 | 系统管理 |
| 机构管理员 | 本机构管理 |
| 审核员 | 用户资料审核 |
| 公益红娘 | 婚恋服务 |
| 活动管理员 | 相亲活动 |
| 风控人员 | 举报处理 |
| 志愿者 | 指定辅助工作 |

---

# 五十九、权限最小化原则

必须遵循：

> 谁需要什么，就只能看到什么。

例如：

### 活动志愿者

只需要：

- 用户姓名
- 手机尾号
- 活动报名状态
- 签到状态

不能看到：

- 身份证号码
- 择偶要求
- 私人聊天
- 举报记录

---

# 六十、匹配系统V1设计

V1采用：

> 规则匹配 + 权重评分

暂时不用复杂AI模型。

---

# 六十一、匹配第一层：硬条件

如果双方任一硬条件冲突：

> 不进入推荐。

例如：

张先生：

```text
希望年龄 27～34
```

王女士：

```text
35岁
```

如果年龄被设置成：

> 必须符合

则不匹配。

---

# 六十二、双向匹配原则

不是：

> A的条件符合B

就够了。

必须：

```text
A符合B的要求
+
B符合A的要求
```

才能进入推荐。

这是婚恋匹配最核心的逻辑。

---

# 六十三、匹配第二层：综合评分

示例100分：

| 类别 | 权重 |
|---|---:|
| 年龄 | 15 |
| 地区 | 15 |
| 婚姻状况 | 10 |
| 子女情况 | 10 |
| 学历 | 5 |
| 身高 | 5 |
| 婚姻计划 | 15 |
| 定居意愿 | 10 |
| 生活方式 | 10 |
| 兴趣 | 5 |

未来可后台调整。

---

# 六十四、推荐结果呈现

前台不要显示：

> 93分

建议转换成：

```text
很合适

比较合适

值得了解
```

并显示：

> 推荐理由。

---

# 六十五、推荐排除机制

以下情况不推荐：

- 已拉黑
- 已明确不喜欢
- 被封禁
- 暂停寻找
- 成功牵手
- 正在了解且关闭推荐
- 不符合硬条件
- 风险审核中

---

# 六十六、冷启动问题

丹阳本地平台早期用户可能不多。

所以系统必须支持：

> 候选池不足时适度放宽“最好符合”条件。

不能放宽：

> 用户设置的“必须符合”。

例如：

用户希望：

```text
本科最好
```

可以推荐大专。

如果用户设置：

```text
本科必须
```

则不能推荐。

---

# 六十七、系统通知

通知必须控制数量。

只发送有价值的消息：

```text
资料审核结果

有人与你互相喜欢

公益红娘推荐

活动报名结果

活动提醒

安全提醒

账号状态变化
```

不要大量营销通知。

---

# 六十八、首页公益内容

虽然这是公益项目，但不要把首页变成公益宣传栏。

公益组织介绍可以放：

> 我的 → 关于平台

首页最多保留：

> 公益婚恋服务

这一品牌标识即可。

---

# 六十九、隐私设置

用户至少可以控制：

```text
是否出现在系统推荐

是否允许被搜索

是否展示职业

是否展示具体工作单位

是否展示生活照片

是否接收活动推荐

是否接受红娘推荐
```

---

# 七十、敏感信息设计

前台原则上不要公开：

- 姓名全称
- 手机号
- 微信号
- 身份证
- 精确住址
- 精确工作单位
- 收入证明
- 家庭住址

例如：

真实姓名：

> 王女士

而不是：

> 王某某完整姓名

用户在深入了解后自行决定是否交换联系方式。

---

# 七十一、手机号保护

手机号仅用于：

- 实名认证
- 账号安全
- 活动必要联系
- 公益红娘联系

不能对其他普通用户开放。

---

# 七十二、数据统计

运营后台建议统计：

### 用户数据

- 注册用户
- 认证用户
- 审核通过用户
- 活跃用户
- 男女比例
- 年龄结构
- 区域分布

### 匹配数据

- 推荐次数
- 喜欢数
- 双向匹配数
- 聊天建立数
- 解除匹配数

### 公益服务数据

- 红娘服务人数
- 人工推荐次数
- 线下活动次数
- 活动参与人数

### 成果数据

- 正在了解人数
- 成功牵手人数

这些数据未来对：

> 妇联  
> 工会  
> 民政公益项目  
> 公益项目总结

都非常有价值。

---

# 七十三、核心运营漏斗

平台最重要的数据漏斗：

```text
注册
↓
实名认证
↓
资料审核通过
↓
完成择偶条件
↓
收到推荐
↓
表达喜欢
↓
双向喜欢
↓
开始聊天
↓
线下见面
↓
正在了解
↓
成功牵手
```

管理后台必须能看到每一级转化率。

---

# 七十四、V1明确开发范围

第一版必须完成：

### 用户体系

微信登录  
手机号  
实名认证  
个人资料  
择偶条件  
人工审核

### 匹配体系

系统推荐  
条件搜索  
喜欢  
双向匹配  
不喜欢  
拉黑

### 沟通体系

文字聊天  
图片  
系统通知

### 公益服务

公益红娘申请  
红娘工作台  
人工推荐  
跟进记录

### 活动体系

活动发布  
活动报名  
报名审核  
签到  
活动反馈

### 安全体系

举报  
黑名单  
风控标记  
账号封禁  
隐私权限

### 后台

用户管理  
审核中心  
红娘服务  
活动管理  
风控中心  
组织人员  
数据统计  
权限管理

---

# 七十五、V1明确不开发

为了避免项目失控，V1明确不做：

```text
直播

短视频

动态广场

朋友圈式社区

虚拟礼物

金币

积分商城

VIP会员

付费曝光

付费聊天

付费查看联系方式

AI数字人

复杂AI聊天机器人

游戏化签到

排行榜

用户等级

视频相亲

语音房

多人聊天室
```

这些功能以后也不是默认要开发。

只有实际运营证明有必要，才讨论。

---

# 七十六、核心页面数量控制

为了保证项目轻量化，用户端V1建议控制在大约：

> **25～35个核心页面。**

不要第一期做七八十个页面。

后台：

> **约10～15个主要业务页面。**

通过详情页、抽屉、弹窗复用完成管理。

---

# 七十七、最核心的产品闭环

最终所有系统设计都必须围绕这一条闭环：

```text
真实用户进入平台
        ↓
实名认证 + 人工审核
        ↓
建立真实婚恋档案
        ↓
填写择偶要求
        ↓
系统精准推荐
        ↓
发现合适对象
        ↓
表达喜欢
        ↓
双向喜欢
        ↓
安全聊天
        ↓
公益红娘辅助
        ↓
参加线下活动 / 线下见面
        ↓
进一步了解
        ↓
成功牵手
```

---

# 七十八、产品设计最终原则

整个项目后续无论增加什么功能，都必须同时回答四个问题：

### 这个功能能否提高真实性？

不能，就谨慎做。

### 这个功能能否提高匹配效率？

不能，就不应该成为核心功能。

### 这个功能能否提高用户安全？

如果降低安全性，就不能做。

### 一个普通用户是否不看说明就会使用？

如果不能，就重新设计。

最终产品不追求：

> 功能最多。

而追求：

> **步骤最少、理解最简单、匹配最高效、服务最真实。**

这应该成为整个丹阳公益婚恋服务平台从产品、UI、开发到运营的最高设计原则。