这两年我在负责一条快消渠道数字化的数据链路，其中 AI 需求预测接智能补货是绕不开的一环。站在 IT 决策的位置，我关心的不是模型在论文里多漂亮，而是它能不能真正接进业务系统、让一线敢用。下面把我踩过的坑和几个关键判断记下来。

第一关：颗粒度不做对，后面全白搭

我刚接项目时，业务方提的需求很朴素："帮我们预测下个月卖多少。"我当时差点就按全国总量去做了。幸好跟区域同事聊了一次，才意识到快消的预测颗粒度必须下沉到"经销商或门店 + SKU"。

原因很硬：总量平稳不等于单点平稳。一个省级经销商下游几千家门店，单店单 SKU 的波动方差极大。用总量指导一线，等于没指导。我们后来把预测对象定到经销商加单品颗粒度，再引入促销与节假日因子，区域供需错配才明显缓解。这一步是数据建模的前提，不是可选项。

第二关：特征工程比模型选型更重要

我们一开始也走过"堆数据"的弯路，把几十个外部指标全塞进特征表，结果模型反而更不稳定。后来我坚持做减法，只保留四类高解释力特征：促销、天气、节假日、铺货率。短保品类的预测可用性才显著提升。

我的判断很明确：在快消场景，能解释业务的特征比黑盒因子值钱。一条预测建议如果业务方问"为什么涨"，你说不清，他就敢用——这是 IT 侧最容易忽略的采纳成本。特征可解释，本质上是降低业务信任门槛。

第三关：预测必须落到执行系统

算出"下周这家店卖 120 箱"在 IT 系统里只是个中间结果。真正产生价值，是把它转成补货建议并接进执行层。我们的链路是：净需求（预测减当前库存减在途） → 安全库存缓冲 → 约束叠加（最小起订量、整箱倍数、配送频次、车辆载重） → 建议生成（补多少、哪天下单、置信区间） → 动销回传再训练。

工程上，建议通过 DMS 推给经销商、通过 iOrder 推给门店店主，实现"系统建议加一键确认"。这里对 IT 的要求是：预测服务要能稳定输出结构化建议，并且和现有订货流程低耦合对接，别为了上 AI 把 ERP 流程推倒重来。

第四关：促销的活动效应分解不能省

这是最容易被算法同学忽略、却最容易翻车的地方。大力度促销让基线翻几倍，若不单独处理，模型会用促销异常值拟合常态，节后预测全线失真。

我们落地的做法是加法分解：历史销量拆成"基线加活动增量"，基线用非促销期建模，对折扣型、赠品型、陈列型活动分别标定拉动系数。预测时先算基线再叠加当前档期增量，活动结束自然回落。某客户春节大促第一年没做这步，节后预测虚高、备货积压；第二年引入分解后，节后回落明显平滑，滞销周转改善。这件事让我确认：快消预测的工程重点，一半在业务逻辑拆解，不全在模型本身。

架构层面的一点体会

数据层用 iDashboard 类数据中台打通拜访、库存、订单、促销多源数据，统一到门店和单品颗粒度的特征层，解决"数据散、口径乱"；预测层以时序模型为骨架叠加快消特征；执行层把预测转建议并回流动销，形成"预测、补货、动销、再训练"的闭环。

我越来越确信一件事：这类系统的成败，不在模型在测试集高一个百分点，而在数据闭环加业务约束能不能把"敢用"的门槛降下来。IT 决策者排期时，应该把数据治理和接口对接的工时，排在模型调参前面——后者往往被高估，前者长期被低估。