George Gabriel1. 从一个反常识的痛点说起：为什么堵车比想象中更费电
如果你开过电车经历过晚高峰，大概率见过隔壁油车车主一脸淡定地原地怠速，而你盯着仪表盘上的续航里程往下掉，心里那叫一个焦灼。油车堵车时油耗虽高，但至少发动机热效率还在勉强撑住，而电车在蠕行工况下，电机效率虽然高，但空调、电池热管理、娱乐屏、座椅通风加热这些"隐性电老虎"一个都关不掉。实测下来，一台主流纯电SUV在走走停停的拥堵路段，百公里等效电耗可以飙到25-30kWh，比通畅路况高出一大截，续航打折打到六折甚至五折都很正常。
更麻烦的是充电需求的时空分布。通勤潮汐决定了大家早上扎堆往CBD挤、晚上扎堆往居住区回流，而充电桩建设往往是"哪里地便宜装哪里"，结果就是：高峰时段核心商圈的充电站排队排到马路牙子上，而一些偏远的快充站闲得能当停车场。这种错配不仅让车主体验差，更让电网侧非常难受——变压器容量是按峰值负荷设计的，但负荷的时间特性和空间特性如果摸不准，就只能"宁可多修不能少盖"，造成巨大的投资浪费。
我们团队这几个月折腾的事情，简单说就是：把导航软件的路况数据直接接进电网规划模型，用实时路况反推电动车的充电需求走势，再映射到具体的电网馈线、变压器节点上，给规划人员提供一份"哪里该建桩、哪里该扩容、哪里该上储能"的动态决策参考。这活儿一开始听着挺简单——不就是把两个数据集拼一起跑个回归嘛——真正下手以后才发现，导航数据是给人开的车看的，电网规划是给变压器和馈线算账的，两个世界的语言完全不一样，中间的坑比想象中多得多。
这篇文章就从头到尾聊一遍这个项目：为什么路况能当电网规划的探测器、数据怎么接、特征怎么抠、模型怎么搭、踩了哪些坑、最后到底有没有用。给想往"交通-能源融合"方向折腾的同学做个参考。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 路况数据为什么能当电网规划的"前哨探头"
2.1 核心逻辑：车流就是充电需求的"先行指标"
电网规划最头疼的问题不是总量不够，而是不知道负荷会出现在哪里、出现在几点。传统做法靠的是历史用电曲线的外推，再加一点用户侧调研问卷，滞后性非常明显。你想啊，一个区域如果新建了一座写字楼，员工们开始开电车通勤，那这片区域的充电需求曲线会怎么变？调研问卷能给个大概方向，但具体到某个周五晚高峰的突发拥堵，问卷是不可能告诉你的。
这就是路况数据的价值所在。导航软件的路况，本质上是海量真实车辆位置、速度、轨迹的实时汇聚。一辆车在路上跑，它要么在去充电的路上，要么已经充满电在去目的地路上，要么是油车/货车/出租车——虽然不是每一辆车都是电车，但车流的规模和结构，直接决定了充电需求的"水位"。一个区域的车流密度、平均速度、停留时长分布，跟该区域的出行需求强度高度相关，而出行需求强度又是充电需求最核心的驱动因子。
这里有一条清晰的传导链：路况拥堵程度 → 车辆行驶状态变化 → 单位里程电耗变化 → 剩余电量(SOC)分布变化 → 充电需求和充电时长的变化。每一步都有物理意义，不需要端到端硬学黑盒，而是可以用中间变量拆解。
2.2 导航数据里到底藏着哪些对电网有用的信息
导航软件的原始路况数据，常见的有这几类：
- 拥堵指数/拥堵等级：实时或分时段的道路畅通度，一般分成畅通、缓行、拥堵、严重拥堵几个等级。这是最直观的"出行热度"指标。
- 路段平均速度：按道路分段统计的实际通行速度，比拥堵等级更细粒度。速度的下降幅度还能侧面反映事件型拥堵（事故、封路、天气）。
- 轨迹起终点数据（OD）：脱敏后的出行起终点聚合数据，能看到"从哪来到哪去"的大致流向。这个对电网规划特别有用，因为它直接揭示了通勤潮汐的势能方向——早上从郊区涌向市中心，晚上反过来。
- 途经点/兴趣点停留热度：导航搜索和导航行为的聚合，比如某个商场、某个小区、某个高速服务区的搜索热度突然升高，往往意味着那里即将出现一波到达车流。
如果只做粗颗粒度，光靠拥堵指数也能凑合跑，但如果想让模型有业务可解释性，一定要把平均速度和OD流向加进来。
2.3 为什么不能直接把路况和充电量做回归
这里必须泼一盆冷水。很多人一听这个思路，第一反应就是"把路况拥堵度当X、把充电桩充电量当Y，跑个XGBoost不就行了"。真这样做，模型大概率会"看起来挺准，一上线就废"。
原因有几个。第一，路况和充电量之间不是同时刻对应的。早高峰拥堵发生在8点，但充电高峰往往滞后到9点半甚至10点之后——因为通勤到公司后还要停车、上楼、插枪。这个滞后窗口是动态的，跟区域功能（办公区 vs 居住区）有关系，简单的同步回归会把时序因果硬生生压成虚假相关。第二，路况反映的是"所有车的流量"，充电量只反映"电车的充电行为"，两者之间存在一个随时间、季节、油价、补贴政策变化的折算系数。第三，电网规划最终要落到变压器和馈线上，而路况是落在道路网上的，两个空间网格完全不同源，不做映射直接回归，等于拿苹果比橘子。
所以我们最终采用的做法是"物理拆解+数据驱动"两层结构：先用物理规则把车流折算成潜在的充电需求，再用数据驱动模型逼近真实充电行为中的复杂非线性关系。后面详聊。
3. 数据接入与特征工程：把地图App的"脾气"翻译成模型能懂的变量
3.1 怎么拿路况数据：源、频率和配额
导航路况数据不是随随便便能拿全量的。主流的来源有这么几个：
- 地图开放平台的路况API：提供指定矩形区域或道路ID的路况状态和平均速度，一般按次调用，有QPS和日配额限制，几千个路段轮询一遍要算好频率。
- 合作方提供的历史路况且数据：一些做智慧交通的公司在卖脱敏的历史路况快照数据集，含路段编码、时间戳、速度、拥堵等级，按城市按日期打包。对做规划模型来说，历史数据比实时数据更重要。
- 公开的浮动车数据：部分城市交通运行报告会发布区域平均速度、拥堵延时指数的时间序列，颗粒度比较粗，但免费、稳定，适合做冷启动基线。
我们项目实际用的是"API实时拉取+历史快照缓存"的组合。规划模型需要的是长时间跨度的样本，而不是某一天的实时快照，所以重点是和交通数据供应商签了一个城市的脱敏历史数据集，再叠加开放API拉取当日的实时数据进行"近实时预测"。频率上，路况API每天按15分钟一个时间片拉全量，约96个时点，每个时点覆盖全市数百条关键道路。
提示：拿数据前一定先确认版权和合规边界。路况数据的二次加工使用在很多供应商协议里是受限的，我们所有演示数据都做了脱敏和权限报备，这一步别省。
3.2 路网匹配：把道路车流翻译到电力馈线区
这一步是整个项目里最脏、最容易被低估的活。导航路网是一张由路段（Link）和节点（Node）组成的拓扑图，电网规划模型面对的则是馈线（Feeder）、变压器（Transformer）、台区（District）组成的电力拓扑图。两套拓扑之间没有任何天然对应关系，必须建立映射。
我们的做法分三步：
- 先把城市路网按行政区和主干道切割成若干个"交通小区"（Traffic Analysis Zone, TAZ），每个小区包含一组道路半径内的导航路段。
- 再把电网馈线的供电范围通过电网GIS系统的地理坐标映射到同一坐标系下，做空间叠加。一个馈线可能覆盖多个交通小区，一个交通小区也可能跨越多条馈线，所以最终生成的是"交通小区→馈线"的权重关联矩阵。权重可以用各小区的夜间人口密度、写字楼面积、充电桩密度等做加权。
- 最后把每段路况数据按照道路所在地的交通小区编码打标，聚合到馈线尺度上去。
这步做完，路况数据就"落"到了电网能用的空间颗粒度上。但注意，这个映射关系不是一劳永逸的，电网拓扑会调整，交通小区会因封路、开通新路而变化，所以映射表需要定期重新计算，最好做成自动化流程。
3.3 特征工程：别只盯着拥堵指数
特征怎么构造，直接决定了模型的天花板。我们最后用到的特征大致分四组，每一组都有明确的业务含义：
组一：拥堵与速度特征
- 区域加权拥堵指数（按道路长度加权）
- 区域平均速度（分工作日/周末分箱）
- 拥堵蔓延度：当前时刻拥堵路段的空间邻接数量
- 速度波动率：过去2小时速度的变异系数，能捕捉"偶发事件"型拥堵
组二：时序与日历特征
- 时刻、星期几、是否节假日、是否工作日
- 通勤高峰标识（早高峰7-9点、晚高峰17-20点，按区域类型差异化设置）
- 上一时刻/前一小时/前一天同刻度的拥堵延滞值（滞后特征）
组三：空间与用地特征
- 区域POI结构：办公面积占比、居住面积占比、商业面积占比
- 区域充电桩保有密度、快充/慢充比例
- 区域与主城中心的直线距离、轨交换乘热度
组四：天气与环境特征（辅助）
- 气温、降水、风速。气温对电车电耗影响极大，冬天低温+开暖气堵车是最恶劣场景，必须作为外生变量引入。
特征确定后，还要处理一个关键问题：时间对齐。路况的时间片、天气的时间片、充电桩充电量的时间戳往往不是同一个基准，我们统一转成15分钟粒度并做前向填充，确保所有特征在同一个时点上对齐。这里千万别用未来数据做填充，不然会引入泄漏。
3.4 标签怎么定：不能直接用"充电桩实时功率"
如果直接把充电桩的15分钟充电量作为标签，还有一个隐患：充电桩只有用了才有充电量，而充电需求可能因为排队、桩坏、电价太贵等"被压抑"了。也就是说，观测到的充电量是"供给侧受限的需求"，而不是真实需求。比如某个区域充电桩严重不足，车主想充充不上，路况数据明明很热，但充电量数据却很低，模型就会学到"热的地方充电需求反而低"这种错误规律。
我们处理的办法是引入"充电事件计数器"而不是单纯用电量做标签。只要充电枪成功启动并持续一段时间，就记为一个有效充电事件。充电桩运营商后台一般都有这些事件记录。用充电事件数 + 总充电量两个指标一起做多输出回归，事件数更能反映需求强度，电量则反映需求深度。两者结合，既回避了供给挤压问题，又能估计总耗电。
4. 模型架构：怎么把路况"怼"进电网规划
4.1 整体设计：两阶段模型，不搞一键端到端
方案选型时我们对比了好几个路线。端到端深度学习最诱人：输入一段时间的路况序列，输出未来24小时的馈线负荷曲线。但问题也很明显——缺少中间环节的校验，模型预测偏了都没法解释是哪一环出了问题。电网规划是一个强解释性场景，规划人员要能回答"为什么这个台区要扩容"，你不能只说"模型说它要扩容"。
最后我们定的是两阶段解耦架构：
- 阶段一：路况驱动充电需求预测。输入历史路况、日历、天气特征，输出未来若干小时内各馈线对应区域的充电需求曲线（覆盖充电事件数和功率两路输出）。
- 阶段二：电网规划模拟。将充电需求曲线叠加到原有常规负荷曲线上，推算各变压器的负载率、馈线电流、电压偏差等，给出超阈值时段和风险节点。
这样做的好处是，阶段一的预测误差可以在阶段二的模拟里被加权量化，规划人员在看到最终结论时，能随手调出"哪段路况导致了需求抬升"的归因。
4.2 阶段一的模型选型：为什么最终用了"梯度提升+轻量序列网络"的混合
针对充电需求预测这个具体任务，我们实测了几个候选模型，结论可能跟直觉有点不一样。
- 纯XGBoost/LightGBM：用滑动窗口的特征工程也能达到不错的效果，特别是加入滞后特征后，短期1-2小时的预测精度非常能打。但问题是它对"路况序列中的长程依赖"（比如连续拥堵3小时后的需求拐点）捕捉能力偏弱，本质上还是在做特征匹配。
- 纯LSTM/Transformer：序列建模能力强，但数据量要求高，训练周期长，而且容易在业务特征的复杂交叉上吃亏。我们只有一年多的历史数据，纯深度学习的效果不稳定。
- 混合方案（最终采用）：主干用LightGBM建模"区域类型×时段×拥堵状态"的非线性映射，同时用一个轻量的双向GRU（只有1-2层）处理每根馈线对应交通小区的历史速度时序，抽取短期趋势向量作为额外特征，喂给LightGBM。这样既保留了GBDT对复杂离散特征的处理优势，又注入了序列信息。
具体到实现上，模型输入形态做成每根馈线一个样本组，训练时按调度器的路由树并行，输出维度是未来8小时（32个15分钟时点）的充电需求序列。损失函数用了加权分位数损失，目标是覆盖10%到90%的分位数区间，而不只是点预测——电网规划需要知道最坏情况，光给一条均值曲线是不够的。
阶段一的核心代码逻辑大致长这样：
python复制# 伪代码示意，非完整实现
import lightgbm as lgb
import torch
import torch.nn as nn
class TrendEncoder(nn.Module):
"""轻量双向GRU，抽取速度时序的高阶趋势特征"""
def __init__(self, input_dim, hidden_dim=32):
super().__init__()
self.gru = nn.GRU(input_dim, hidden_dim, batch_first=True, bidirectional=True)
self.proj = nn.Linear(hidden_dim * 2, 16)
def forward(self, x):
# x: [batch, seq_len, input_dim]
_, hn = self.gru(x)
# 取双向最后一层拼接
trend_feat = torch.cat([hn[-2], hn[-1]], dim=-1)
return self.proj(trend_feat)
def build_gbdt_dataset(road_feature_df, trend_model):
"""将路况原始特征 + GRU抽取的趋势特征合并成GBDT训练集"""
trend_feat = trend_model(seq_tensor(road_feature_df))
merged = pd.concat([road_feature_df.drop(columns=['speed_seq']), trend_feat], axis=1)
return merged
params = {
'objective': 'quantile',
'alpha': 0.5,
'learning_rate': 0.03,
'num_leaves': 127,
'max_depth': 8,
'feature_fraction': 0.8,
'bagging_fraction': 0.9,
'lambda_l1': 0.1,
'lambda_l2': 0.5,
'verbosity': -1
}
model = lgb.train(params, lgb.Dataset(train_x, train_y), num_boost_round=2000)
4.3 阶段二的电网模拟：需求曲线如何变成"扩容建议"
阶段一的输出是充电需求曲线，但电网规划不能只看需求，要看变压器会不会过载、馈线电压是否越限、继电保护是否误动。阶段二本质上是在做潮流分析和可靠性校核，但这里我们做了简化——因为规划层面的问题不需要毫秒级电磁暂态仿真，只需要稳态负载率推演。
我们把充电需求叠加到常规负荷预测曲线上，采用典型日负荷曲线叠加法：
- 取该馈线区域过去3个月的平均常规负荷15分钟曲线，记为base(t)。
- 取阶段一输出的充电需求中位数场景p50和极端场景p90，记为ev(t)。
- 叠加得到总负荷总负载L(t)=base(t)+ev(t)。
- 对照变压器额定容量S和功率因数cosφ，逐时点计算负载率= L(t)/(S·cosφ)。
当某个时点负载率连续超过80%（按规划规程，变压器长期负载率一般不建议超过80%），就标记为一条风险记录。把一年8760小时都推演一遍，就能得到每个台区"超载小时数"、"最高负载率"、"超载月份分布"等规划指标。
这一步看起来简单，实际操作中有一个很容易忽略的问题：常规负荷和充电负荷并不是简单相加的关系。因为充电桩本身也会影响低压侧电压，而且如果装了光伏，中午时段的净负荷可能是负的。我们在叠加时专门加了"净负荷修正项"，把分布式光伏出力和充电桩的无功特性都考虑进去，否则负载率会被算高。
4.4 模型融合与校验：别让一个解跑天下
项目迭代后期我们还试验了不同超参、不同特征集合下的多模型投票。具体来说，除了LightGBM主干，还额外训练了一个以Transformer为主体的序列模型，专门负责捕捉"连续多日拥堵模式"下的中长期趋势。最终输出取两者加权平均，权重根据最近30天滚动验证误差在线调整。融合的收益在极端天气场景下特别明显——单模型容易过拟合到某个特定天气模式，融合后鲁棒性提高了一截。
校验环节我们重点盯三件事：
- 时间外样本测试：绝对不能混着年份做随机切分，必须按时间先后切，比如用前10个月训练、后2个月验证。
- 空间泛化测试：用A城训练，直接搬到B城试打榜，看看精度掉多少。路况数据驱动的特征本身有跨城市迁移潜力，但区域POI结构差异会显著影响精度。
- 极端社会事件（大活动、节假日）敏感性：演唱会散场、春节返乡这类场景下，模型预测误差会明显放大，这属于预期内的系统性偏差，规划时会给一个额外的安全裕度系数。
5. 实测结果与规划效果的改善：这玩意儿到底有没有用
5.1 试点区域与数据概况
我们在南方某二线城市的中心城区做了一版完整的试点。该区域面积约40平方公里，覆盖两条商业街、三个大型居住组团、一个高新产业园和两所高校，口径内共有充电站120余座、充电枪2000余根，电网侧涉及7条10kV馈线、23台配电变压器。
训练数据从2023年4月到2024年3月，一共12个月的导航路况历史数据、充电桩运营数据、天气数据；验证集用2024年4月的4周数据。
5.2 预测精度：短期预测能到什么水平
直接看结果。按15分钟颗粒度评估充电负荷预测误差（MAPE，平均绝对百分比误差），在验证集上：
| 场景 | 预测提前量 | MAPE（负荷点预测） | 峰值时段MAPE | 备注 |
|---|---|---|---|---|
| 普通工作日 | 1小时 | 8.6% | 9.9% | 效果最稳定 |
| 普通工作日 | 4小时 | 14.2% | 17.5% | 4小时后误差明显放大 |
| 雨天 | 1小时 | 12.7% | 15.8% | 需要天气特征加持 |
| 节假日 | 1小时 | 19.4% | 26.1% | 最难预测 |
| 普通工作日 | 8小时（全天预测） | 21.3% | 28.7% | 只能做趋势参考 |
8.6%的1小时MAPE，放到电力负荷预测领域算是不错的成绩。但如果只做点预测，规划人员还是不敢用，所以我们重点看了分位数区间的覆盖率：p10-p90区间在实际值覆盖上达到了约83%，离理论90%还差一截，后续考虑用更复杂的校准方法（如保序回归校准分位数）。
5.3 给电网规划带来了哪些看得见的改变
模型输出不止是"报个数字"，而是要能直接指导规划动作。试点期内，模型给出的关键结论有这么几条：
- 定位了3台高风险变压器：有两台在晚高峰叠加充电后负载率超过95%，其中一台在学校附近，周五下午放假高峰时段连续超载。原规划里这两台都不在近三年扩容名单上，但推演结果显示如果不处理，下个夏天大概率出问题。
- 发现了一个"隐性需求洼地"：某个离主路很近的产业园，路况数据显示早晚通勤车流密度高，但周边充电桩利用率长期不足。原因不是没需求，而是园区入口和充电桩位置动线设计不合理，导航并不会把去充电的车引导到那里。模型反推出潜在需求后，规划部门重新调整了引导标识和入口闸机，充电桩利用率两个月内提升了30%。
- 优化了储能配置位置：原来计划在某个商业区统一配一套1MW/2MWh的储能来削峰，但模型数据显示该商业区的充电峰值其实出现在午间——光伏出力也最大的时段——削峰需求没有想象中强。反而是隔了两条街的居住区，夜间充电峰值明显，那里才更需要储能。这个结论直接改写了当年的储能布点方案。
5.4 精度对比：路况驱动 vs 不用路况的基准模型
为了验证"路况数据到底起了多大作用"，我们做了消融实验。基准模型只用历史充电负荷自身的时序外推（SARIMA+简单回归），不引入任何路况特征；对照模型加上路况特征后，1小时预测的MAPE从12.9%降低到8.6%，峰值时段MAPE从18.5%降低到9.9%。尤其是极端拥堵事件（事故、大暴雨）发生时，基准模型的误差经常翻倍，而路况驱动模型的上升幅度相对温和，因为路况本身的异常波动已经提前把信息传递出来了。
这个对比其实说明了一个很现实的结论：在平稳日子里，路况数据的边际贡献没那么大，但一旦有突发性交通扰动，路况特征几乎是唯一能提前感知需求波动的信号源。 对电网规划来说，"平静日子"不是重点，"风险日子"才是。
6. 这活儿的坑比想象中多：踩坑记录与经验心得
6.1 坑一：导航数据是"驾驶视角"，不是"停车视角"
这是整个项目里最大的坑。导航路况记录的是正在路上跑的车的速度，但充电需求发生在车停下来之后。一辆车从路况数据里消失了，可能是因为它到达了目的地停车场，也可能只是进入了隧道或者没有GPS信号。如果我们简单地把"路况热度高"等同于"充电需求高"，就会忽略一个关键点：充电行为发生在目的地附近，而不是路况拥堵的路段上。
我们的解决办法是引入"OD热点热度"特征，用导航搜索目的地的聚合数据来标识"车流将要流向哪里"。但即便这样，依然有偏差——很多车主开车到了目的地后并不会马上充电，而是等到SOC低到某个阈值才充；这个阈值又跟个人习惯有关，很难从聚合路况里完全还原。最终我们只能接受这个误差，并在预测区间上放宽。
6.2 坑二：地图围栏和馈线边界的"薛定谔重叠"
交通小区和馈线供电范围的空间映射看着是纯几何问题，实际操作起来全是边界归属的nasty case。有个台区边界正好穿过了某条主干道，道路两侧分属两个不同馈线，但导航路况API返回的路段速度是整条路的平均速度，没法按车道细分。还有地图围栏在河岸、高架桥下经常出现飘移，把河对岸的路段也算进小区里，导致数据污染。
这块没什么灵丹妙药，只能在映射表里做"路段-小区-馈线"三重校验，用路段的行政编码、桥隧标志、车道方向信息辅助纠偏。每次电网拓扑更新后强制重跑一遍映射校验，不能偷懒。
6.3 坑三：节假日和极端天气是模型的"照妖镜"
平时再准的模型，到了五一、国庆、除夕这种日子，误差都能让你怀疑人生。原因不复杂：节假日的出行目的结构完全变了，通勤需求被旅游、探亲、聚会需求取代，POI结构特征不再适用；而极端天气下，交通路况本身的分布也会剧烈变形。我们一开始没想到这个问题的严重性，直到有一版模型在国庆假期预测某高速服务区充电需求时，直接把峰值低估了60%。
后来的做法是：给模型加一个"日历类型强特征"（节前、节中、节后、寒暑假、特殊活动日），并单独用节假日数据微调一个旁路模型；如果预测日恰好是节假日，就显著加大p90分位数的权重。简单说就是"平时靠主模型，特殊日子靠防守式预测"。
6.4 坑四：数据频率和配额决定模型"天花板"
跟地图API供应商对接那阵子才发现，实时路况数据的配额限制比想象中死板得多。想要全城每5分钟更新一次，费用直接翻几倍；改成15分钟更新后，又发现部分偏远路段的数据刷新不稳定，经常出现"前一小时有数据、后一小时全是空值"。解决方法是做"自愈式填充"：用同类型路段的同时刻历史中位数填充缺失值，再用空间插值平滑，不给模型喂NaN。
这套数据补全逻辑后来被做成了独立的工具模块，建议任何想入手的团队都先把数据质量和监控做好，模型再花哨也拯救不了脏数据。
6.5 一点真心建议：最小可行闭环先跑起来
如果让我给后来的团队一个最重要的建议，那就是：别一上来就贪大求全。不要妄图第一天就做一个覆盖全市、多馈线、支持实时预测的完美系统。我们团队最开始也犯过眼高手低的毛病，折腾了两个月连数据同步都没跑顺。后面痛定思痛，先用一条馈线、一个交通小区、一个月的路况数据和充电数据，跑了一个最简单的最小可行版本，把整个数据管道和模型框架打通，再慢慢扩展。这个过程看着慢，实际反而快。
另外，一定要让电网规划的业务人员尽早参与进来。工程师眼里"这个MAPE降了2个百分点"是巨大胜利，但规划人员更关心"你能不能告诉我明年夏天哪台变压器会过载"。做项目的时候多问一句他们真正想要的东西，能少走很多弯路。
我个人在这个项目里最大的感受是，交通和电力这两个行业原来离得那么远，却因为电动车这个"移动的用电单元"被硬生生拉到了一起。导航软件的路况数据，本质上是一张实时人口活动热力图，只要映射做对、特征挖好，它的价值远不止"避开堵车路段"这么简单。电网规划这事儿，过去靠经验、靠历史曲线，现在多了一双能实时看到城市脉动的眼睛，虽然还不算完美，但方向肯定是靠谱的。
后续我们打算把这套模型扩展到更多城市，把公交、共享单车、出租车轨迹这些多源交通数据也纳进来，看看能不能把充电需求预测再往前推几个小时的预报窗口。到时候有新的进展和踩坑，再回来跟大家唠。