城市共享单车监管平台
城市共享单车监管平台
车已经堆成山了，系统才知道。为什么？
大多数平台的回答是：巡查员拍张照报上来，或者市民投诉打到 12345，数据这才进系统。也就是说，平台不是在"预警"，是在"记录"。等大屏上那个红点亮起来的时候，清运车已经来不及调了。淤积预警机制要解决的，就是把这个发现时间往前挪——最好在车还没堆起来之前，就有人收到通知。
淤积预警机制：由平台按预设规则持续比对停车点车辆数与容量，发现超标或异常趋势时自动向指定人员发出通知，并衔接后续处置流程的一套规则体系。它不是一个大屏功能，而是一条"发现—通知—处置—回传"的流水线。
先说淤积为什么会发生。三个原因，一个比一个现实。
一是潮汐需求。早高峰，居住区的车涌向地铁站，晚高峰再倒回来。某个地铁站口按工作日早高峰统计，两个小时净流入能到两三百辆（示例口径，具体数字随城市和站点差别很大），而旁边停车点的容量可能只有 80 辆。需求是潮水，泊位是池塘，潮水天天来，池塘就这么大。
二是调度滞后。运营企业不是不调度，是调度总比淤积慢半拍。人只能等车堆多了、照片发到群里了才知道要派车，从发现到清运到场，一两个小时就过去了。
三是配额拍脑袋。很多停车点的容量是规划时凭感觉定的，画个框就写个数，从没按实际流入量校准过。配额本身失真，后面的预警自然跟着失真。这事没有标准答案，各地客流差别很大，配额必须一个点一个点地调。
真正麻烦的地方在于，淤积没有统一的"长相"。有的是突然冲高，有的是慢慢累积，有的是上周没有、这周反常。一种规则管不住三种情况，所以成熟的淤积预警机制通常分三层。
第一层是阈值预警。车辆数超过停车点配额就亮灯，最直接，管的是"现在已经超了"。缺点也明显：它只能告诉你结果，不能给你留出反应时间。
第二层是趋势预警。不看绝对值，看方向——某个点连续三四个小时净流入为正，哪怕总量还没超配额，按这个速度两小时后必爆。这就把干预提前了，调度车可以在堆起来之前出发。
第三层是对比预警。拿本周和上周同时段比。周一下午三点，这个点平时常年停 40 辆，今天停了 120 辆，绝对值没超配额，趋势也就这一个小时的样本，但和上周一比就知道不对劲：附近八成有活动、施工围挡或者地铁口临时封闭。
三层规则叠在一起用，才覆盖得住。单一规则，要么漏报要么误报。
规则怎么落到系统里？以我们平台预警管理模块的配置思路为例，大致是下面这张表的格式（触发条件为示例口径，实际数值要按各城市客流校准）：
预警类型 | 触发条件 | 通知对象 | 延伸动作 |
阈值预警 | 停车点车辆数超过配额的 110%，持续 15 分钟 | 运营企业区域调度员、街道巡查员 | 派发清运工单，限时到场 |
趋势预警 | 连续 3 小时净流入为正，且预测 2 小时内超配额 | 运营企业调度中心 | 提前调度，平峰错峰清运 |
对比预警 | 车辆数达到上周同时段的 200% 以上 | 平台值守人员、运营企业负责人 | 人工核实原因，视情况派单 |
表里的通知对象不是随便填的。预警发到不该收的人手机上，等于没发——区域调度员收得到、动得了，这条预警才算数。
这是很多平台项目最容易漏掉的一环。
预警弹出来了，然后呢？如果通知只是在大屏上闪一下，或者在值班群里冒个消息，那它和没有预警区别不大。淤积预警机制的最后一段，必须接到工单管理上：预警自动生成工单，派给具体的人，带处理时限——比如参考行业里常见的 053060 口径，5 分钟响应、30 分钟到场、60 分钟清运完毕。处理完了还要回传，清运前拍一张、清运后拍一张，平台核验销单。整条链全流程可追溯，月底考核才有依据。
反过来说，如果预警和工单是两套系统、两拨人在用，中间靠微信截图传话，那预警发得再准也是空转。
漏报固然不好，误报的杀伤力经常被低估。
阈值定得太紧，比如超配额 5% 就报，一天下来几十条预警，绝大部分是擦边超标，清一下就回落。头一周值班员还条条点开看，第二周就开始划掉，第三周直接免打扰。人一麻木，真出事的那条预警混在一堆噪声里，照样没人理。所以我们的建议是宁可宽一点：阈值放到 110% 起步，把持续时长加上，把趋势和对比两层用足。少报几条擦边的，换值班员对每一条预警都当真，划算。
各地情况差别很大，具体数值只能给个参考，上线后要按误报率慢慢往回收。
从这几年的项目看，淤积预警机制的趋势是往前端挪：从"超了才报"到"快超就报"，再到结合天气、节假日、周边活动的预测式提醒——明天有雨加会展，某个点的流入量大概率先给个预估。数据监控和数据分析的能力跟上之后，预警会从被动报警变成主动排班，调度车提前一小时就位，而不是事后清山。谁能把发现时间从"堆成山之后"挪到"堆起来之前"，谁的街道就少接一半投诉电话。