《球友体育》智能约战与同城匹配功能需求规格说明书 (PRD)

业务背景与产品定位背景现状：民间球类运动爱好者常面临“凑人难（临时缺人/缺特定位置）”、“找对手难（水平悬殊导致体验差）”、“爽约率高”、“找场地难”等痛点。产品目标：通过 LBS 定位、ELO 动态天梯分级、角色位置互补及诚信履约机制，降低组局门槛，提高匹配效率与对局质量，并将单次拼场转化为长期社交/战队粘性。2. 核心功能架构与模块设计[智能约战与同城匹配]
├── 1. 快速组局/发布 (散人拼场 & 球队约战)
├── 2. 智能推荐与匹配引擎 (LBS + ELO + 位置互补)
├── 3. 信用履约与押金机制 (防鸽预付 + 互评体系)
├── 4. 流程履约与签到核销 (GPS打卡 + 现场分队)
└── 5. 赛后沉淀与战绩结算 (天梯分变动 + 球队沉淀)
详细功能模块需求模块一：约战/拼场发布与管理1. 发布类型散人拼场（个人/散客模式）：场景：如“半场3v3差1人”、“11人制足球差1门将”。必选要素：运动项目、场地位置（联动合作球场/自定义球场）、时间段、期望段位范围、空缺位置（如控卫/中锋/门将/前锋）、AA费用预设。球队约战（战队对决模式）：场景：整队寻找对等实力的球队进行友谊赛或排位赛。必选要素：球队主客场偏好、赛制（5人制/7人制/11人制；全场5v5/半场3将产品功能方案从“粗颗粒度的业务需求”细化为“研发可直接落地的 PRD”，核心在于将主流程拆解为底层规则、状态机与异常边界。一套标准的 PRD 深度细化结构通常涵盖以下六个关键维度：1. 业务逻辑与前置约束用户准入条件：角色权限（如普通用户、管理员）、账号状态（未绑定手机号、封禁中等）、设备环境（App 版本要求）。业务规则（Business Logic）：阈值限制（单日上限、频率限制如 60 秒重发验证码）、计费/积分消耗规则、数据有效周期。2. 核心流程与分支拆解主干流程（Happy Path）：用户最顺畅的完成路径。逆向流程（Rollback / Refund）：中途取消、主动退出、超时未操作、退款/冲正机制。跨端/后台联动：C 端操作后，B 端审核、数据看板及第三方系统（如支付、物流）的触发顺序。3. 页面元素与交互细节字段级规则表：字段名称控件类型是否必填字符长度/格式默认值/占位文案校验时机与报错提示用户昵称单行输入框必填2-20字符，禁止特殊符号"请输入您的昵称"失去焦点时校验；若超长提示"昵称最多20个字符"交互状态：Default（默认）、Hover/Active（点击/悬浮）、Disabled（置灰禁用，附说明为什么不可用）、Loading（加载中）。4. 状态机与生命周期定义状态枚举：例如订单状态（待支付、处理中、已完成、已取消、已超时）。流转触发条件：从【状态 A】跃迁至【状态 B】是由用户行为、系统定时任务还是三方回调触发。不可逆节点：明确哪些状态流转后不可撤销。5. 异常场景与容错策略（Edge Cases）弱网与超时：请求超过 5 秒无响应是前端重试、吐出 Toast 提示，还是走本地缓存降级？并发与幂等：用户快速连击提交按钮、跨设备同时登录时的处理机制（前端防抖 + 后端防重 Token）。空数据与极限值：列表为空时的缺省占位图；文本超长时的截断或省略处理；极端数值（如 0、负数、溢出）。6. 非功能性需求（NFR）与数据埋点性能要求：接口响应时间（P95 < 500ms）、首屏渲染耗时。埋点规划：页面曝光（Pageview）、核心按钮点击（Click）、转化漏斗关键事件及携带的参数属性（User_ID、Source、Timestamp 等）。

1 条评论