# 丹阳公益婚恋服务平台 ## 产品详细功能架构设计 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、开发到运营的最高设计原则。