做共享台球室无人系统这些日子我和团队被问得最多的问题不是“怎么造一个系统”而是“老板到店没人接待顾客扫码之后到底能不能像叫网约车一样顺畅走完开台、打球、结账全过程”。说白了微信双端赋能的本质就是用微信小程序做用户入口、用微信支付和消息通知做经营闭环把一个需要人力值守的传统球房改造成顾客自助使用、老板远程盯盘的无人化场景。先说清楚这套系统能解决什么顾客到店不用找前台桌台扫码或者扫门禁码就能开台系统自动开灯开锁、开始计费打完球在微信里就能结账临时要走还能在线续费。老板这边不需要守在店里微信里能看到每张台的实时状态、营收流水超时未结账会自动扣费并推送提醒。这篇文章适合三类人看一是准备把自己的球房改成无人模式的经营者二是接到台球室、棋牌室、健身房无人化项目的外包开发者和系统集成商三是想用微信小程序支付能力做实体场景创业的技术爱好者。1. 项目整体设计与思路拆解1.1 “双端赋能”具体指哪两端很多人一听“微信双端”就以为是安卓和苹果两个手机端其实在这个项目里双端指的是用户端和经营端两个完全不同的角色入口。用户端是微信小程序。功能上要包含扫码开门、桌台选择、计时计费、在线支付、续费、历史账单这些基础能力。顾客不需要下载App微信里搜一下或者扫个码就可以用。这一端的体验决定了顾客愿不愿意第二次来。我见过不少无人球房死在第一步顾客扫码之后小程序转圈打不开或者支付成功了灯却没亮这种体验比有人值守的服务差太多。经营端则是给老板和管理员用的承载在微信生态里。比较轻的做法是老板直接看微信支付商户平台和公众号后台重点看交易流水和消息提醒更完整一点的做法是做一个H5或小程序管理后台配合企业微信、公众号模板消息或订阅消息推送经营数据。经营端不需要像用户端那样频繁改版但一定要让老板用微信就看得到“今天开了多少台、有没有人超时、哪张台还在计费”。1.2 无人台球的核心业务链路整个无人系统的业务链路可以拆成一条非常清晰的线微信授权登录 → 扫描台码/门禁码 → 选择球桌与时长 → 微信支付/免密预授权 → 通电开灯开锁 → 自动计时 → 到点提醒 → 续费或结账 → 自动关灯断电 → 账单推送。这条链路里的每个环节都要闭环才能算真正无人化。比如自动关灯这一步很多第一版系统不做结果顾客走了灯还亮一晚上电费直接吃掉利润。再比如“到点提醒”如果缺少这一环顾客打球超时后被强制断电会产生大量投诉。系统必须预留一个“缓冲提醒机制”提前5到15分钟通过微信订阅消息提醒续费超时后再给一个宽限期最后才断电。1.3 为什么选微信而不是自建App做过实体场景创业的人都知道一句话用户不会为了打一次台球去下载一个App。微信小程序最大的价值是零安装成本扫码即用用完即走加上微信支付本身就是国人最习惯的支付方式跳过了绑定银行卡和充值这两道坎。另一个原因是消息触达。微信订阅消息、公众号模板消息、企业微信通知这三件套可以覆盖“开台成功通知、临近超时提醒、支付成功回执、经营日报推送”四个场景。如果是自建App推送通道要依赖厂商推送服务厂商一旦收紧权限消息到达率就没保障顾客和老板都会被晾在那里。还有一层信任问题。球房开在写字楼、商场或小区底商很多顾客对陌生第三方系统有天然警惕但微信支付和微信小程序自带品牌背书顾客付款时看到的是熟悉的支付界面跑单、盗刷的顾虑会明显降低。1.4 方案版本取舍扫码型和感应用型我给不同预算的球房做过三版方案成本从几千到几万不等这里直接对比给各位参考扫码基础版每张台面贴一个二维码顾客扫码开台系统控制电控箱开关灯和通电约2000-5000元/店适合已有门禁、只需要无人计费的小球房。扫码加智能门锁版门禁和台灯都由系统控制顾客扫码获得进场权限适合独立包间或整体封闭式球房成本在8000-15000元/店。蓝牙感应自动开门版顾客到门禁附近小程序通过蓝牙自动识别并开门无需手动扫码体验最好但调试量大且需要每个门禁配蓝牙网关成本最高。我个人的建议是第一版先做扫码基础版把稳定性和支付闭环跑通再逐步升级到智能门锁和蓝牙感应。很多球房老板一上来就追求“无感体验”结果蓝牙连接和远程开锁的问题一大堆反而把口碑做砸了。2. 双端分工与核心能力选型2.1 微信小程序端要解决的事小程序端是无人系统的门面核心要处理三件事身份识别、场地控制、计费状态同步。身份识别的关键是微信登录和openid映射。用户第一次授权时小程序通过wx.login拿到code后端调微信接口拿到openid再结合手机号绑定可选建立用户档案。注意这里有个经验现在微信对手机号快速填写的收费政策一直在调整而且用户对授权手机号很敏感如果不是强制要求实名场地第一版可以不绑手机号直接用openid做用户标识降低跳出率。场地控制分两类。一类是控制电控箱和智能灯通过云端的设备接口下发指令另一类是控制智能门锁需要对接锁厂商的IoT开放平台或者通过局域网内的网关做控制。选硬件时一定要确认设备支持云端API否则只能靠人工去开关无人化就是空话。计费状态同步要重点设计。小程序端展示的剩余时长和实际计费状态必须实时一致用户端用WebSocket长连接持续接收服务端状态服务端定期与设备上报数据对账。这是整个系统最容易出bug的地方微信小程序对WebSocket连接生命周期有严格限制切后台几分钟就会断连状态同步不能只靠客户端长连接服务端必须有能力轮询补偿。2.2 经营端的微信能力组合经营端要的不是花哨功能而是让老板随时看到真实经营状况。我常用的组合是微信支付商户平台公众号模板消息企业微信机器人通知。微信支付商户平台是所有资金的唯一来源和账单出口它自带交易明细、退款管理、财务报表经营数据可以直接从商户平台拉取不需要自己造轮子。老板每天打开微信就能核对流水这是很多自研后台替代不了的信任感。公众号模板消息适合做“非实时但重要”的通知比如每日营业汇总、每周营收报表。需要注意的是微信公众平台对模板消息的使用场景限制很严格每次用户与公众号互动比如点击菜单、回复关键字后可以获得一次下发模板消息的机会第二个自然日内有效。运营策略上要让顾客关注公众号并主动触发一次交互比如“点击菜单查看今日账单”这样系统才能合法地向用户推送后续通知。企业微信机器人通知则完全面向经营者。把球房的开台记录、异常告警、断电事件通过企业微信群机器人推送给老板不占用用户的订阅消息额度不管老板在不在店里都能实时盯盘。这套组合的优势是全部跑在微信生态内老板不需要装任何额外App也避开了微信个人号的封号风险。2.3 微信支付与消息推送的关键参数做无人系统绕不开微信支付很多新手死在参数配置这一步。这里记录一下我每次上线都会核对一遍的清单商户号mchid微信支付商户平台的唯一标识申请时需要营业执照和对公账户。小程序AppID在小程序后台获取支付下单时appid必须与小程序账号一致。APIv3密钥32位字符串用于请求签名商户后台设置后不可查看明文忘记只能重置。商户证书序列号API证书的序列号用于标识商户身份在商户平台下载证书后可以解析出来。平台证书/公钥用于验证微信支付回调请求的签名防止伪造回调。notify_url支付结果通知地址必须是公网可访问的HTTPS地址微信回调最多重试若干次每次间隔递增。退款接口申请退款需要商户证书私钥签名订单全额退款原路退回款项通常是T1或T2到用户账户。消息推送方面主要分清两个概念微信小程序的订阅消息和公众号的模板消息不能混用。小程序端发订阅消息需要用户在小程序内主动订阅而且一次性订阅只能发送一条公众号模板消息则需要用户关注公众号。无人台球场景里我更推荐把“开台成功、即将超时、结算完成”这些强实时通知做在小程序订阅消息里把“日结报表、营销活动”这类非实时通知放在公众号模板消息里。2.4 硬件选型与联动细节硬件是无人系统里最容易踩坑的部分我这里单独强调几点经验设备协议的开放性大于一切。电控箱、智能灯、门锁必须支持标准API或至少支持HTTP/MQTT协议最好能提供开放接口文档。很多所谓“智能硬件”只能用自己的App控制根本不适合集成到无人系统中采购前先问一句“能不能对接第三方开发”不能就直接pass。灯的联动控制要分场景。公共区域灯过道、前台建议走定时策略比如营业时间内常亮桌台灯则单独受开台状态控制。有些球房用的是普通LED灯没有智能开关这时要通过智能继电器/电控箱加装注意确认继电器额定功率和负载类型防止烧掉。门锁和断电的关系要设计好。顾客在包间里打球房间门锁住了如果计费到点直接断电房间一片黑顾客会产生严重不满。我的建议是包间场景只做“断电倒计时提醒”不做突然断电散台大厅台才可以到点直接断电因为散台互相照明不受影响断电后顾客自然离开。3. 实操过程与核心环节落地3.1 最简可跑通版本的分步实现我给新手团队的第一版建议是做一个“能用但不豪华”的MVP具体步骤如下注册微信小程序并开通微信支付商户号两套资质都要以球房经营主体申请小微企业也可以走简易进件流程。配置支付功能在商户平台开通JSAPI支付在微信支付商户平台设置notify_url为后端接口地址下载商户证书和APIv3密钥。开发小程序前端页面包含首页附近球房/扫码入口、台桌列表、支付弹窗、计费状态页、个人账单页。开发后端核心接口用户登录code2Session、台桌查询、创建订单、支付预下单、支付回调、计费定时任务、续费接口、退款接口。联调硬件控制通过控制板API下发开灯/关灯指令并记录指令状态。测试完整链路扫码 → 下单支付 → 开灯 → 计费 → 超时提醒 → 续费/结算 → 关灯。这里最关键的一个细节是下单和支付必须分开处理。先创建本地订单状态为待支付再调微信支付预下单接口拿到支付参数用户支付完成后微信回调后端后端标记订单已支付同时通知设备开灯。不要把设备控制逻辑写在支付前端回调里因为前端回调和后端回调有时间差极端情况下用户支付成功但前端页面被关闭会导致灯没开但钱收了。3.2 计费逻辑与订单状态机计时计费是无人系统的商业核心设计既要保证利润也要少挨骂。参考多个实战项目这里给出一套我验证过比较合理的规则最小计费单位15分钟。不要设成1分钟实时计费会导致每笔订单金额都是不规则数字用户对账时体验很差。单价硬式台球桌中式八球、斯诺克建议18-28元/小时具体随城市地段波动包间/贵宾厅建议35-60元/小时。消费上限单人连续计费上限建议4小时防止机器故障或用户遗忘导致无限扣费。到上限后强制结束本次计费并自动关灯断电。预授权模式无需用户预先充值通过微信支付“押金免密代扣”的方式冻结一笔预授权比如50元实际产生的费用在结束时按实结算。这种模式用户接受度最高也是最安全的资金处理方式。超时缓冲到点后不立刻断电给3分钟缓冲期缓冲期内按分钟计费超过缓冲期仍未续费或无人在场再执行断电。订单状态机要包含待支付、已支付/使用中、已续费、结算中、已退款、已完成、已超时/违约等状态。我个人建议在数据库里用真实的int枚举而不是字符串减少脏数据状态变更都要落日志方便查“谁扣了钱、为什么扣钱”。服务端计费用定时任务或延迟队列处理每30秒扫描一遍进行中订单比对当前时间与订单结束时间触发提醒、续费、断电等动作。注意定时任务一定要做幂等设计防止一个订单被两个worker重复处理导致重复扣费或重复开灯。3.3 微信消息通知的触发时序通知设计要跟着业务状态走我整理了一个触发时序表直接抄作业即可业务事件通知类型触发时机内容要点用户支付开台小程序订阅消息支付回调成功后台号、开始时间、单价、预计结束时间即将超时小程序订阅消息结束前15分钟剩余时长、续费入口、不续费的后果超时断电小程序订阅消息缓冲期结束本次消费金额、已自动关闭支付结算小程序订阅消息结算成功后使用时长、扣费明细、订单编号经营日报企业微信群机器人每日23:30单量、营业额、异常台数这里特别注意两个限制。第一小程序订阅消息的一次性性质决定了不能频繁给同一用户发同一类型消息所以“即将超时”这类高频提醒必须让用户在开台时明确勾选授权否则发送会直接被系统拦截。第二订阅消息和公众号模板消息的文案不能有诱导分享、诱导关注字样被平台审核发现是会封禁能力的这可不是吓唬人。3.4 计费公平性的用户体验细节无人系统最容易引发投诉的就是“计费不公平”。我自己见过几个反例有人结账时发现多扣了钱原因是系统把“实际使用时长”按“从下单时间到结算时间”计算但开灯可能因为设备故障延迟了几分钟用户进场前不断刷新等待最终仍然全额计费。给同样场景的建议是计费从设备反馈“成功开灯/开门”那一刻开始而不是从支付成功时间开始。支付和开灯之间的延迟如果超过30秒后台要自动给用户补偿对应时长的免费时间并在账单里明确显示“设备响应补偿”项。这种做法看起来亏了一点钱但换来的口碑和复购非常值。另外要在小程序端展示一个“实时计费面板”让用户随时看得到当前费用和剩余时间。人对自己看得见的东西才会放心如果只有一个开始时间和结束时间页面没有跳动计时用户心里就会打鼓。4. 常见问题与排查技巧实录4.1 微信支付回调丢失或延迟微信支付回调不是100%实时极端情况下会有分钟级延迟而且如果回调接口报错微信只重试有限次数。实际运行中我发现的最常见问题有三个notify_url是http而不是https导致回调被拒后端接口没有在响应中返回success字符串商户回调验签代码写错导致一直解密失败。排查时我有一套固定动作先到微信支付商户平台的“交易订单”中确认订单状态再看后端日志中是否有微信服务器IP的访问记录。如果完全没日志大概率是notify_url配置错误如果有请求但处理失败重点检查解密和签名验证逻辑。另外回调处理必须做幂等同一个支付结果可能因为重试被处理两次没幂等就会给用户重复开灯或重复发通知。4.2 用户扫码后小程序无法打开扫码进小程序这个动作看起来简单实际中多个场景会翻车。最常见的原因是二维码内容写错小程序码必须是通过微信官方接口生成的小程序码不能直接用普通的URL二维码否则扫描后无法直接跳到小程序。其次是用户微信版本过低老版本对小程序支持不完整需要引导更新。有一个我踩过好几轮的坑二维码用的短链接带有带参数跳转结果在微信内和微信外打开行为不一致。微信外打开小程序链接会进过渡页体验较慢微信内打开则应该直接拉起小程序。解决办法是统一用小程序码参数直接拼接在scene字段里并且scene字段只能传有限长度和特定字符传中文必炸。4.3 订阅消息发送失败订阅消息的失败率被很多人低估了。用户明明点了订阅为什么发不出去核心原因往往不是接口报错而是微信的发送条件判断严格一次性订阅必须用户通过wx.requestSubscribeMessage主动调起授权系统不能偷偷后台代发且每个openid的每一次订阅只对应一条消息如果用户开了两个台、订了两场球每场都需要单独的订阅授权。还有一个隐藏限制小程序订阅消息对类目有要求如果小程序的类目与“运动场馆/体育服务”不匹配订阅消息里某些行业字段可能无法申请到。申请时一定要选对服务类目类目不对后续很麻烦。排查订阅消息失败时我通常先看微信返回的errCode再确认用户是否真的有一次有效的订阅授权记录最后检查消息模板ID是否属于当前小程序。4.4 设备控制超时和状态不对账这是无人系统的恶性bug用户支付成功了但灯没开或门没开。导致这个问题的原因通常是设备厂商的IoT接口不可靠或者球房局域网与云端通信不稳定。设备控制链路越长故障概率越高因此我强烈建议所有设备控制指令都做“本地兜底”。所谓本地兜底就是在球房内部署一个小网关比如树莓派或工业控制板云端下发指令到网关网关直接通过局域网控制电控箱和门锁。局域网控制的响应时间在毫秒级而且断了外网也能独立工作比云端直接调设备厂商接口可靠得多。网关需要定期向云端上报设备状态云端以“设备上报为准”对账这样即使用户端小程序显示已开灯实际没开也能在若干秒内被发现并告警。4.5 常见问题速查表现象可能原因排查方法解决方案支付成功但未开灯回调未收到或设备接口异常查后端订单状态与回调日志增加网关本地兜底控制设备上报对账计时不准计费起点用了支付时间而非设备反馈时间查订单起始时间戳改为设备成功开灯时间为计费起点超时未提醒订阅消息授权失效查用户订阅记录与errCode引导再次授权或改用公众号模板消息兜底扫码无法打开小程序二维码类型错误检查是否用官方小程序码重新生成并设置scene参数订单重复扣费回调重试未幂等查数据库中重复订单日志增加唯一订单号约束和幂等处理这个小表是项目上线后的第一周排查锦囊建议打印出来贴在工位上。5. 工具选型与部署形态建议5.1 前端与后端的落地技术组合技术选型直接决定了项目后期维护成本。先说前端微信小程序基础框架用原生就好除非团队已经有成熟的uni-app或Taro经验否则不要为了“跨端”而跨端原生框架对微信支付、订阅消息、蓝牙、WebSocket这些原生能力的支持永远是最稳定的。后端我建议用Node.js或Java各有所长。Node.jsExpress/Koa上手快、JSON处理天然贴合微信接口适合快速上线JavaSpring Boot适合后面要扩展棋牌室、健身房等复杂业务系统事务和分布式调度更稳。数据库先用MySQL单库即可账单和订单数据量在单店规模下完全扛得住如果后面做连锁品牌再加上Redis缓存和消息队列拆服务。部署方面小体量项目可以用一台云服务器跑完所有服务2核4G足够操作系统选Ubuntu 22.04 LTS。微信支付回调要求公网HTTPS需要申请SSL证书并配置在Nginx层证书尽量用免费的域名证书成本为零。5.2 小程序云开发与自建后端怎么选微信小程序自带的云开发微信云托管这两年成熟了不少很多初学者会纠结用云开发还是自建后端。我的经验是分开看如果场地规模是1到3家店订单量一天不超过几百单云开发完全够用。云函数免运维数据库有免费额度微信支付的回调地址可以直接指到云函数冷启动虽然有延迟但可以接受。这套方案的最大优势是省事一个人就能维护整个系统。但如果目标是做连锁品牌或加盟体系就必须走自建后端。连锁场景需要多店铺的权限隔离、统一会员体系、跨店结算、总部报表这些在云开发里会写得非常别扭而且云开发数据库的联动查询和复杂事务处理能力都偏弱。后期一旦要做聚合支付、对接ERP或加盟商分账自建后端的灵活度是云开发给不了的。5.3 成本测算与运营建议最后说一个老板们最关心的数字账。我按一家10张台的中型球房测算过无人化改造的投入首个球房试点含整套系统开发、硬件采购、部署调试约2万到3万元。后续每增加一家店仅硬件和部署约1万到1.5万元。月均运维成本云服务器短信消息费用约200到500元。人力成本节省传统球房至少需要一名前台兼收银月薪3000到5000元无人化直接省下这笔开支。运营层面有几个实在建议第一开业期不要一上来就完全无人保留一名驻场管理员遇到顾客操作卡顿能及时兜底培养使用习惯后再逐步撤场。第二把“使用教程”做进桌台贴纸上扫码后小程序里也放一段几十秒的短视频演示中老年顾客群体很吃这一套。第三定期查看后台的“取消率”和“支付失败率”这两个指标能反映出很多体验问题比单纯看营业额更直观。我个人做这几个无人球房项目下来最大的体会是无人系统不是去掉人而是把人的职责交给流程和工具。微信双端赋能让顾客熟悉的微信变成了遥控器让老板熟悉的微信变成了驾驶舱剩下的核心工作就是保证计费公平、设备稳定、消息及时。这三件事做好了哪怕页面丑一点、功能简陋一点顾客也愿意用这三件事做不好再花哨的UI和营销活动都留不住人。如果你正准备做类似项目我建议从最小的扫码版MVP开始把支付闭环和设备联动跑稳了再慢慢加功能这条路是最稳的。