阿布贾气象站：1个温度模型被废掉的72小时

31.4°C还是32.1°C，对用户来说没有区别。产品经理出身的工程师在部署阿布贾温度预测模型三个月后，亲手把它下线了。

这个决定源于一个朴素的观察：连续数值预测看着漂亮，却无法触发任何行为。用户不会因为这0.7°C的差异改变穿衣决策，更不会因此取消户外计划。模型精度再高，也只是个精致的数字摆件。

从"看着准"到"能用上"

团队把问题重构为二分类：今天阿布贾下雨吗？这个转变直接改变了产品的可用性边界。温度预测给出的是参考信息，降雨预测给出的是行动指令——带伞、洗车、改期。

技术路径随之切换。原SARIMA时间序列模型被保留作为基线，但主模型转向XGBoost（极端梯度提升）。关键调整在于特征工程：严格的时间序列结构被注入，包括滞后变量、滚动统计量、以及日期周期性编码。

验证策略也换了打法。传统的随机交叉验证在时间序列里会泄露未来信息，团队改用滚动窗口验证（walk-forward validation）。简单说，就是用过去预测未来，而不是用未来"预测"过去——后者在Kaggle竞赛里刷分好看，落地就是灾难。

生产环境的隐藏陷阱

模型上线前，团队发现两个反直觉的问题。一是类别极度不平衡：阿布贾旱季长达半年，"无雨"样本压倒性多数。二是误报代价不对称——预测有雨实际无雨，用户白背伞；预测无雨实际有雨，用户被淋透。

这逼着团队重新设计评估指标。准确率（accuracy）在这种场景下是陷阱：一个永远预测"无雨"的模型能有80%+准确率，但毫无价值。他们转向精确率-召回率曲线（precision-recall curve）和F1分数，并引入业务自定义的损失权重。

特征工程的细节更能体现工程团队的强迫症。原始数据包含温度、湿度、气压、风速等12个维度，但直接扔进去会过拟合。他们做了三件事：按气象学常识筛选物理相关特征、对强相关特征做PCA降维、以及最关键的一步——把"昨天是否下雨"作为强预测因子单独编码。

从实验室到手机通知栏

模型最终部署为每日早7点的推送服务。用户打开App看到的不是概率数字，而是"今日有雨，建议带伞"或"今日无雨，适宜洗车"的明确指令。A/B测试显示，这种二分类交互的次日留存比温度预测版本高出23%。

团队把完整流程开源，包括数据清洗脚本、特征工程代码和验证框架。GitHub仓库的README里写着一行备注：「如果你也在做天气预测，先问自己——用户能因为这个预测做什么？」

那个被下线的温度模型没有白做。它教会团队一件事：在机器学习产品里，精度是手段，行动才是目的。现在他们正在把同样的逻辑应用到拉各斯的交通拥堵预测——不是预测"拥堵指数7.2"，而是"这条路现在走，会比平时多花15分钟"。

如果你的模型输出不能让用户立刻做出一个具体决定，它真的完成了使命吗？