体育场馆的用水异常，传统上要等到月底水费账单明显偏高才会被注意到，等发现的时候，问题往往已经持续了好几周甚至更久，中间浪费掉的水已经没办法追回。博万体育App的异常用水检测想解决的正是这个时间差——把发现问题的时间点从"账单出来之后"提前到"异常刚开始发生的时候"。

分区是这套机制的前提

要做到实时发现异常，先要能把用水量精确到具体区域，而不是只有一个总表读数。多数体育场馆的用水其实来自好几个性质完全不同的场景：草坪灌溉、泳池补水和换水、更衣室淋浴、餐饮后厨，每一类的用水规律都不一样——灌溉集中在固定时段、泳池换水有周期性、淋浴用水和比赛日人流强相关。如果只看一个总表，这几类用水混在一起，某一类出了问题，总量的变化很可能被其他类别的正常波动掩盖掉，根本看不出异常。所以App要求场馆按功能区域安装分区智能水表，每个区域单独上传读数，这样App拿到的才是可以分别分析的数据，而不是一个笼统的总量。分区之后的第一件事是让每个区域各自建立历史基线，也就是这个区域在不同时段、不同星期几的正常用水范围通常是多少，这个基线不是一个固定数字，而是一个随时间变化的区间。

基线怎么建立，偏离怎么判断

历史基线是App根据这个区域过去一段时间的读数逐步积累出来的，会区分工作日和周末、区分比赛日和非比赛日、也会区分季节——灌溉区域的用水在不同季节本来就会有明显差异，不能用夏天的用水量去判断冬天是否异常。有了基线之后，App会把每个区域最新的实时读数和对应时段、对应场景下的历史区间做比较，如果读数落在区间之内，就当作正常波动，不会有任何提示；如果读数明显超出这个区间——比如某个时段的用水量达到了历史同类时段常见上限的数倍，或者本该没有用水的时段出现了持续读数，App会把这条记录标记为异常，进入告警流程。这里的判断标准不是一个固定的绝对阈值，而是相对于这个区域自己历史表现的偏离程度，因为不同场馆、不同区域的正常用水基数本来就差别很大，用统一的绝对数字去卡所有场馆并不合理。

一个例子：灌溉区凌晨用水突然升高

举一个具体场景来说明这套机制怎么运作。某场馆的草坪灌溉区域，历史上凌晨时段属于灌溉系统按计划短时开启的时间窗，正常情况下用水量会有一个固定的区间，开启后一段时间就会回落到接近零。某天凌晨，这个区域的读数在灌溉窗口结束后没有像往常一样回落，反而持续维持在一个不低的水平，一直延续到清晨。App在读数持续偏离预期区间超过一定时长后，判定这是一次异常，生成告警。

场馆管理者打开App，在通知里看到这条告警，点进去是异常详情页：页面上方是一张曲线图，蓝色线是当天这个区域的实时读数，灰色阴影区间是这个区域在同类时段的历史正常范围，可以清楚看到蓝色线在灌溉窗口结束后没有回落、明显脱离了灰色区间。详情页下面会给出偏离的大致幅度和持续时长，以及一句简短的可能原因提示——这类"该关闭时段持续出水"的模式，常见原因包括灌溉阀门卡滞未能正常关闭、管路存在渗漏，或者控制器的排程设置出现了错误。App不会替管理者下结论说具体是哪一种，而是把这几种常见可能性列出来，提示管理者按顺序去现场排查，比如先检查对应区域的阀门是否完全关闭，再检查管路是否有明显渗漏痕迹。

不同区域同时出问题，App怎么排优先级

一个场馆往往不止一个区域接入了分区水表，如果多个区域在相近时间段都出现了偏离，App不会把它们平铺展示成一串没有先后顺序的通知，而是按偏离程度和持续时长做一个大致的优先级排序。偏离幅度更大、持续时间更长的告警会排在更靠前的位置，同时App也支持把不同区域的告警分配给不同的责任人——比如草坪灌溉相关的告警默认推送给场地养护负责人，泳池和淋浴相关的告警推送给设施运维负责人，避免所有异常都堆在同一个人的通知列表里，导致真正紧急的问题被埋没在一堆待处理消息中间。这个分配关系是在场馆信息设置里配置的，接入水表时可以顺带把负责人和区域对应起来，后续告警会自动按这个对应关系分发。

告警会不会误报，App怎么区分正常波动和真的异常

实时检测机制不可避免会遇到一些看起来像异常、实际是正常情况的场景，比如场馆临时增加了一场额外的草坪养护作业，或者泳池因为设备维护多补了一次水，这类计划外但合理的用水，读数上同样会表现为偏离历史区间。App处理这类情况的方式是允许场馆管理者在收到告警后手动标注"已核实为正常"，并简单选择一个原因分类，比如临时养护、设备维护、活动加场等。这个标注不只是关闭当前这条告警，还会被计入这个区域后续基线调整的参考信息里——如果某类计划外用水未来会变得规律化（比如场馆决定把额外养护固定为每月一次），App会在积累到足够记录后，把这类情况纳入正常区间，减少后续重复出现同类误报的概率。反过来，如果管理者核实后确认确实是异常（比如例子里的阀门卡滞），处理完之后可以在App里标记"已处理"，这条记录会被保留在历史里，方便后续排查同类问题时参考。

刚接入的场馆，多久能用上这套检测

异常检测依赖的历史基线不是一开始就有的，需要一段时间的持续数据积累才能建立起相对可靠的正常区间。刚完成分区水表接入的场馆，App通常会先进入一段数据积累期，这段时间里页面上只会展示实时读数曲线，不会主动判断异常，因为过早给出判断反而可能因为基线样本不足而产生大量误报或者漏报。随着积累的时段样本逐渐增多——尤其是覆盖到不同星期几、不同季节、比赛日和非比赛日的多种场景之后，基线的可靠性会逐步提高，App才会开始正式启用异常判断和告警推送。这段积累期的长短因场馆而异，跟这个场馆各个区域的用水规律复杂程度、是否有明显的季节性变化有关，管理者可以在用水卡片里看到当前基线的积累状态和大致完成进度。

告警之后，App还能提供什么

异常告警不是一次性的提示，详情页会保留这条记录，管理者处理完现场问题后，可以回到App里查看后续读数是否已经回落到历史区间内，确认问题是否真的解决了，而不是只凭现场感觉判断。如果同一个区域短时间内反复出现类似模式的告警，App也会把这些记录关联起来展示，方便管理者判断是不是同一个未彻底解决的根源问题。这套实时检测机制和账单异常之后的排查思路是互补关系——如果错过了实时告警，或者告警发生时场馆恰好没有及时处理，等到水费账单明显升高才被发现，这时候该从哪里开始排查，体育场馆水费突然增加，AI应该先查哪里里有更完整的说明，思路和App告警页面给出的排查方向基本是一致的，只是一个是实时提前发现，一个是事后倒推。

这套异常检测能正常运作的前提，是分区智能水表已经稳定接入并且积累了足够的历史数据，如果某个场馆刚接入不久、历史基线还没建立完整，App会在对应区域标注数据积累中，暂时不会做异常判断，避免用不充分的历史数据给出误导性的告警。项目里其他区域的用水数据如果长期显示不完整，通常也是接入环节的问题，具体排查可以参考博万体育App里的场馆用水数据一直显示不完整怎么办。而整个用水监测模块，本身也是建立赛事项目之后打开的四个数据卡片之一，第一次建项目时的引导逻辑可以参考第一次使用博万体育App，为什么先建立一个赛事项目。