需求表达很散
用户可能只是想今晚吃饭、周末运动、生日有人陪，但传统社交产品要求用户先建立关系，再表达需求，路径过长。
我试图解决的不是“没人聊天”，而是“想找人一起做事却不知道怎么开口”。
产品经理视角下，这个项目的核心矛盾是：用户有即时陪伴需求，但陌生人社交存在信任成本、沟通成本和线下安全顾虑。
陌生沟通压力高
没有共同上下文时，聊天容易变成尬聊。以活动需求作为入口，可以天然给双方一个低压力话题。
线下见面需要信任感
找搭子最终常常会走向线下，产品必须设计申请审核、系统通知、举报、信用和评价等安全机制。
产品解法：用“需求卡片”替代泛社交关系，用“申请通过”替代无门槛私聊。
我把匹配链路设计成先看场景、再申请、后聊天。这样既提升效率，也让发布者拥有筛选权。
1浏览需求广场按分类、时间、距离和性别筛选。
2发布活动用户填写时间、地点、人数、性别要求。
3申请陪伴申请不是直接私聊，降低发布者被打扰感。
4审核通过发布者接受后自动创建聊天会话。
5评价沉淀陪伴记录和评分形成后续信任资产。
四个主 Tab，围绕一个完整用户闭环。
首页负责发现，发布页负责供给，消息页承接申请结果和聊天，我的页面沉淀历史记录与信用资产。信息架构尽量接近微信用户熟悉的移动端使用习惯。
🔎需求广场
分类、搜索、距离和性别筛选。
✍️发布需求
用结构化表单降低发布成本。
💬消息系统
通过申请后进入会话。
🛡️安全机制
举报、通知、评价和信用分。
关键页面截图：从发现需求到发布和管理。
界面使用浅色背景、低饱和选中态、卡片层级和胶囊控件，目标是让本地社交产品看起来更可信、更轻盈。
好的搭子产品，不应该先问“你是谁”，而应该先问“你想一起做什么”。这是我对本项目的核心产品判断。
决策一
将入口定义为“发布具体需求”，不是泛化的陌生人推荐。这样能提升双方沟通上下文，降低首次互动成本。
决策二
把聊天权限放到“申请通过”之后，让发布者有筛选权，减少骚扰，也更适合线下活动场景。
决策三
加入收藏、系统通知、举报、陪伴记录等模块，把一次性约伴逐步转化为可沉淀的信任体系。
决策四
视觉上避免高饱和和强刺激，选择低饱和、圆角、留白和轻动效，让社交产品更有安全感。
我在项目中覆盖的产品能力。
这个项目适合作为产品经理面试案例，因为它能同时体现用户洞察、信息架构、交互流程、数据模型和工程协作理解。
场景化需求洞察
识别“孤独感”背后更具体的活动陪伴需求，并用分类体系承接不同场景。
低打扰互动机制
通过“申请-审核-聊天”的路径设计，在效率和安全之间做平衡。
可沉淀的数据模型
围绕用户、需求、申请、会话、消息、收藏、通知、举报和陪伴记录搭建数据闭环。
前端微信小程序原生页面、组件、TabBar、表单和筛选交互。
云函数user / needs / chat / init-db，负责权限与业务状态流转。
云数据库9 个集合支撑发布、申请、聊天、收藏、举报和评价。
云存储承接需求图片上传，丰富需求卡片表达。