GogoAI 自助健身门店解决方案：无人值守场景下的软硬件架构与落地实践

GogoAI 自助健身门店解决方案无人值守场景下的软硬件架构与落地实践GogoAI 自助健身门店解决方案本质上是一套面向 24 小时无人健身房的软硬件一体化系统用户通过小程序扫码完成身份校验与开门门店内的灯光、空调、门禁、储物柜、淋浴设备按需联动摄像头负责动作识别与安全告警后端按分钟或按次完成计费与结算。它要解决的核心问题有三个——没有前台时如何确认「谁进来了」、没有巡场时如何确认「他在练什么」、没有收银员时如何确认「该收多少钱」。本文从技术视角拆解这套方案的架构选型、核心模块与关键代码并给出可复用的开发流程建议。一、整体架构与技术选型整套系统可以按「端—云—设备」三层划分这与无人零售、无人台球室等无人值守场景的技术栈高度一致差别主要在于设备协议和业务规则更复杂。用户端采用 uni-appVue 语法开发一套代码同时发布小程序、抖音小程序与 H5。选择 uni-app 的原因在于自助健身的用户入口高度依赖平台流量多端复用能显著降低维护成本同时抖音、美团这类渠道的券码核销也通常在小程序侧完成。管理端Vue Element UI负责门店管理、设备管理、会员与卡券、订单与对账、营销活动配置、视频回放等。服务端Spring Boot MyBatis Plus MySQL 作为主业务服务Redis 承担分布式锁与实时状态缓存MQTT如 EMQX负责与门禁、柜锁、传感器等 IoT 设备通信WebSocket 负责向前端推送开门结果与实时状态。一个典型的开门链路如下小程序扫码 ↓ 携带门店ID 用户Token 业务网关校验会员状态/卡券有效性 ↓ 通过则生成开门指令 MQTT 下发到门店网关topic: store/{storeId}/door/cmd ↓ 门禁控制器执行并回执 ↓ WebSocket 推送结果 写入入场记录 启动计费会话这里有两个工程上的关键点一是指令必须幂等扫码请求可能重复提交需要用requestId做去重二是必须有超时兜底MQTT 回执丢失时不能让用户卡在门口通常设置 35 秒超时并允许用户重试。二、核心模块拆解1. 门禁与设备联动门禁是无人门店的道关卡。硬件侧一般包括电磁锁或道闸、门禁控制器、红外/雷达传感器。软件侧需要处理的场景包括会员有效期内直接开门非会员引导到小程序完成开通流程同一用户短时间重复扫码不重复计费离场判定通过门内传感器或二次扫码确认用户已离开结束计费会话设备离线时降级缓存指令待网关重连后补发同时在管理端告警。设备联动的规则建议做成可配置的「场景策略」例如「开门后 30 秒内开启照明与空调」「后一个用户离场后延时 10 分钟关闭电源」。把这类规则从代码里抽出来放进配置表才能在多家门店之间快速复制。2. 计费引擎计费是自助健身容易出纠纷的环节设计上建议采用策略模式把「按次卡」「时长卡」「包月卡」「渠道券」等规则拆成独立实现避免大量 if-else 堆叠。publicinterfaceBillingStrategy{BillingResultcalculate(BillingContextctx);}Component(duration)publicclassDurationBillingStrategyimplementsBillingStrategy{OverridepublicBillingResultcalculate(BillingContextctx){longminutesDuration.between(ctx.getEnterTime(),ctx.getExitTime()).toMinutes();// 向上取整不足一个计费单元按一个单元计算longunits(minutesctx.getUnitMinutes()-1)/ctx.getUnitMinutes();if(ctx.hasValidCard()){returnBillingResult.coveredByCard(units);}returnBillingResult.byUnits(units);}}工程上还要注意计费会话的起止时间必须由服务端生成并落库不能依赖客户端上报的时间离场异常用户忘记扫码出门需要有兜底策略例如按后一次设备感应时间或当日闭店时间截断并在对账时标记为异常订单供人工复核。3. AI 摄像头与动作识别AI 视觉模块是自助健身区别于无人台球室、无人茶室的核心。它通常承担三类任务动作计数与姿态纠正基于姿态估计模型如 YOLO-Pose、MediaPipe 等提取人体关键点再通过关节角度阈值或时序模型判断深蹲、卧推、引体向上等动作的完成度。落地时建议先做「离线验证」——用门店真实摄像头录像跑一遍模型确认误检率可接受后再上实时链路。安全告警跌倒检测、长时间静止不动、器械区异常聚集等场景触发告警推送到值班人员。这类场景召回率优先于准确率宁可多报不可漏报。视频回放与追溯用于纠纷处理通常按门店 时间段切片存储配合 NVR 或对象存储的冷热分层策略控制成本。需要注意的是涉及人脸的识别必须做合规评估公开区域应设置显著提示视频数据的存储周期与访问权限要在系统里做成可配置项而不是写死在代码中。三、开发流程与落地建议如果要从零搭建一套类似系统建议按下面的顺序推进避免一上来就陷入硬件对接的细节先跑通主流程用模拟设备一个 HTTP 接口代替门禁回执把「扫码—校验—开门—计费—离场—结算」闭环跑通再替换成真实 MQTT 设备。再抽象设备层定义统一的设备接口开门、关电、读状态不同品牌的门禁控制器通过适配器实现避免换硬件就要改业务代码。然后接渠道核销抖音、美团的券码核销需要按平台开放接口对接注意券码的一次性校验与幂等处理核销失败要能回滚。后叠加 AI 模块视觉模块与业务模块解耦部署通过消息队列异步消费分析结果防止推理耗时拖垮主链路。补齐运维能力设备在线率看板、订单异常告警、每日对账任务这三件事决定了系统能不能真正支撑无人化运营。在多门店复制时建议把「门店」「设备」「场景策略」「计费规则」都做成数据而非代码新店开业时只需配置数据即可上线。四、常见问题 FAQQ1GogoAI 自助健身门店解决方案一般包含哪些子系统通常包括用户端小程序扫码开门、购卡、预约、查看训练记录、门店管理后台会员、订单、设备、营销、IoT 设备层门禁、柜锁、传感器、灯光空调控制、AI 视觉模块动作识别、安全告警、视频回放以及渠道核销模块。Q2用户忘记扫码离场导致计费不止怎么处理建议双保险一是通过红外或雷达传感器自动判定离场二是设置长计费时长上限超出后自动截断并生成异常订单进入人工复核队列。同时在小程序内推送「您可能已离场」的提醒。Q3AI 动作识别必须用 GPU 服务器吗取决于并发路数。单店少量摄像头可以先用边缘设备推理把结构化结果动作类型、计数、告警事件上传云端原始视频只在本地留存这样能同时降低带宽成本和隐私风险。Q4设备离线时系统如何降级门禁类设备建议保留本地白名单校验能力即使云端不可达也能让有效会员进入计费会话在网关侧本地缓存恢复连接后补传。云端则需要对离线门店持续告警。Q5多门店复制时容易出问题的地方是什么通常是计费规则与场景策略的硬编码。把这两部分配置化是后续快速扩张的前提。