早高峰，地铁B口。出口两侧的非机动车道被单车压得只剩半米宽，后来的骑行人干脆把车往人行道上一撂。想骑车接驳的人，只能在机动车道边上挪，跟公交、私家车抢一条缝。路口的摄像头拍得到堵，但说不清堵的源头，这正是共享单车监督管理平台需要回答的问题。

很多地方把单车当成治堵的对立面，见车就清。方向可能就反了。车和拥堵的关系，得先拆开看。

车和拥堵，其实是三层关系

      第一层最直观：车占道，路变窄。这是物理层面的因果。一辆车大约占掉0.2米宽的通行空间，二十辆乱停的车就能把一条非机动车道堵死，骑行者被挤上机动车道，机动车也得跟着减速，拥堵从慢行系统传导到了机动车系统。

      第二层藏在订单数据里。地铁口的骑行订单，起终点往往集中在地铁站周边一两公里内。接驳订单越密集的地方，公共交通的覆盖短板越明显，人们是没得选才骑车。

      第三层是骑行热力。哪条路常年有稳定骑行流量，哪条路规划了非机动车道却没人走，反映的是真实的慢行出行需求。有些路段的需求和设施之间，差得比想象中大。

      说白了，车只是表象。前面那个地铁口，问题未必是车太多，而可能是附近没有像样的停车区，或者地铁站末端断了公交接驳。三层关系看清楚了，下手的位置才不会错：占道问题找运维清运，接驳问题找公交，设施问题找规划。一件事牵三个部门，靠开会协调效率很低，不如让数据先说清楚。

平台数据怎么用：三个具体场景

      数据本身不治堵，用对地方才有价值。拿做项目时常见的三类场景来说。

      场景一，地铁口周边的骑行起终点分析。把订单起终点落在地图上，看清晨高峰从哪些小区流向地铁站、晚高峰怎么回流。流向集中的方向，就是接驳需求最旺的方向，公交部门可以据此加密接驳线或调整站点位置。

      场景二，违停高发路段。平台把违停工单和车辆分布叠加，高发点连成片，基本就是停车设施缺口所在。有次分析某个项目三个月的工单数据（行业口径），违停最集中的三个点位，恰好都是商圈周边没划停车框的路段。

      场景三，潮汐流向。

潮汐流向：同一方向的车流在早晚高峰出现规律性反向变化，早高峰往地铁站去，晚高峰往居住区回，像潮水一样有涨有落。

      判断出潮汐方向，调度就有了依据：早高峰前把车往地铁站方向补，晚高峰前反向调。平台的数据分析模块支持按时段切片看流向，GIS热力图把堆积点直接标在地图上，运维不用再靠人肉巡街找车。举个量的概念：某地铁口按早高峰7:30—9:00统计，车辆堆积峰值约400辆，周边规范停车框只划了180个（示例口径），缺口在哪一目了然。

把三类场景放到一张表里看：

各地情况差别很大，这张表只是常见组合，落地前还得拿本地数据验证，别照搬。

治堵不能只靠清车

      这里有个容易忽略的点。不少管理动作停在"清"——车堵了就拖，拖完看起来干净了。可人还是得出行的，第二天早上，车又堆回来了。

      清车治的是标。要治本，无非两条路：要么加停车设施，要么优化公交接驳，让人少骑车。难在"该在哪加、加多少"这个问题上。拍脑袋定，容易加错地方，钱花了，流量没导过去。

      平台的价值就在这一步：把"该在哪加"算出来。违停高发叠加骑行热力，缺口位置大致能圈出来；订单量再乘以换乘比例，车位规模也有个估算依据。这个估算不会百分百准，但比纯凭经验强。而且设施投下去之后，平台的违停数据和堆积预警还能反过来验证效果，加对了没加对，数据会说话。

往后看，治堵会越来越依赖数据协同

      趋势已经能看出来了。单车的数据不该只停在监管平台内部，接驳流向给公交部门，热力图给规划部门，违停分布给城管，各方看着同一份数据做决策，动作才不至于互相打架，也不用在部门之间来回要数据。有的城市已经开始这样做了，效果还需要时间检验。

      交通拥堵没有一招见效的办法。但至少下一轮规划地铁站周边的停车区时，可以先看看平台的数据，再决定钱往哪花。