先说结论：我见过的仓库 AI 预测项目，黄的原因从来不是模型选错了。
过去两年，找我聊"AI 预测"的仓库越来越多。需求预测、补货建议、排班人手估算——听上去都很美好。我看他们演示，梯度提升树和时间序列模型轮番上阵，超参数调得比绣花还细。然后我问一句：喂进去的特征有哪些？对方递过来的表格里，经常只有三列：日期、SKU、销量。
这种项目不黄才怪。模型是厨子，特征是食材。你给厨子一篮子烂菜，他炒出什么都是那个味道。预测这件事，真正的功夫在提示词之外——在数据进模型之前那段没人爱干的脏活累活：特征工程。
仓库里的数据，九成不能直接喂模型
2023 年我在安大略看了一家 12 万平方英尺的 3PL 仓。他们花了大价钱请咨询公司做了一套销量预测模型，上线三个月，预测准确率还没他们运营主管凭经验拍的准。运营主管是个干了十几年的老手，他说："这模型连黑五都不知道，还不如我。"
查了才知道：模型只拿了系统里的历史订单量做训练。黑五？系统里没有促销日历。返校季？没有。港口拥堵导致到货晚了两周、补货预测全跑偏？更没有。咨询公司说这些"外部数据"接进来成本高，先跑起来再说。
这就是第一个坑：仓库系统里最完整的那份数据（历史销量），恰恰是最单薄的特征。它告诉你"发生了什么"，不告诉你"为什么发生"。预测模型要的是后者。一个只会看销量曲线的模型，本质上就是在用昨天的形状猜明天的形状，遇到任何结构性变化——促销、断货、新品上架——立刻翻车。
所以动手之前，先把数据清单收拾好。我给客户的清单长这样：
历史销量（按天、按 SKU、按仓库），至少两年，最好三年；促销日历，谁定的、什么力度、持续几天，一个都不能漏；断货记录——注意，是"有需求但没货卖"的天数，不是销量为零的天数，两者在系统里长得一样、含义相反；节假日和学校假期，注意感恩节这种每年日期都不一样的节日；天气数据，极端天气对本地零售仓的影响大得惊人；港口和干线拥堵情况，做进口货的仓，这个决定了在途量什么时候变成在库量；退货数据，按 SKU 的退货率，退货高的品类，净销量和毛销量是两回事。
这份清单里，一半以上的数据不在系统里——在市场部的表格里，在运营主管的脑子里，在货代的邮件里。AI 落地之前，先把这些数据找回来、结构化、落进一张表。这一步没有捷径，也没有哪个大模型能替你做。
该喂什么：仓储特有的那几味料
通用教程教你的特征——滞后项、滚动均值、星期几——这些当然要做。但仓库有自己的味道，有几个特征是别处教程不会讲的，我一个一个说。
在途量。 系统里的"库存"和"能卖的货"经常是两回事。做了进口业务的仓，一批货在海上漂 30 天，这 30 天里系统库存是零，但销售不能按零备货。把"已下单未到货"的在途量做成特征，模型才能理解"库存低但不用慌"和"库存低真的要断货"的区别。2024 年红海绕航那阵子，一家做家居的仓在途周期从 35 天拉到 60 天，没做这个特征的模型，连续两个月说"无需补货"——货还在船上漂着呢。
库位周转特征。 同一个 SKU，放在黄金拣选区和放在高层货架上，销量真的会不一样——拣选效率影响履约时效，时效影响复购。这个特征很多人想不到：用"该 SKU 过去 30 天所在库位的平均拣选行走距离"或者简单点"是否在促销端架"做特征，能吃掉一部分"莫名其妙"的销量波动。
退货率滚动。 服装、鞋类仓的退货率能到两三成。模型如果只看毛销量，会系统性高估真实需求。把"过去 8 周该 SKU 退货率"喂进去，让模型自己学到"这个品类要打折扣看"。
断货标记。 这是最容易被忽略、影响最大的一个。销量为零的那天，到底是没人买，还是没货卖？系统里都记成 0。必须把"当天可售库存是否为零"做成二值特征，否则模型会把断货学成"这个 SKU 没人要"，越备越少——恶性循环。
特征构造的几板斧：滞后、滚动和错位
特征选好了，接下来是构造。仓库预测常用的就三板斧，我把每斧的火候说清楚。
第一板斧是滞后特征：用过去 N 天的销量预测未来。关键问题是 N 取多少。先做 7、14、28 三档，看验证集上哪档贡献大再细调。别一上来就加 365 天——特征一多，模型就开始"背答案"而不是"学规律"。
第二板斧是滚动窗口：过去 4 周均值、过去 8 周最大值、过去 12 周标准差。滚动窗口解决的是"趋势"问题。但 4 周、8 周、12 周窗口高度相关，等于把同一句话说了三遍，选一两个就够了。
第三板斧最有仓库特色，我叫它错位特征：把"原因"和"结果"在时间上对齐。促销是 11 月 20 日开始的，但备货决策要在 10 月底做——特征的时间戳要按"决策时点"来，不能按"发生时点"来。港口拥堵指数是到货前 30 天的才有预测价值。这些错位关系每个仓库都不一样，得跟运营和采购一笔一笔对——这是特征工程里最值钱、也最没法抄作业的部分。
最隐蔽的自杀方式：数据泄漏
前面都是"怎么做"，这里讲"怎么死"。数据泄漏是预测项目里最隐蔽的死法，而且死的时候特别体面——验证集上准确率高得吓人，上线就崩。
最经典的泄漏：用"当月实际促销力度"做特征去预测"当月销量"。训练时这个特征当然好用，模型一学一个准。但做预测时下个月的促销力度还没定——你喂给模型的是未来才知道的数据，这叫"穿越"。正确的做法是用"计划中的促销"（决策时点已知的信息）。
另一个常见泄漏藏在滚动窗口里：预测 12 月销量，特征里用了"过去 8 周均值"，而这 8 周里混进了 12 月第一周的数据——如果你是按周滚动预测，这一周的数据在预测时点还不存在。检查方法很笨但很有效：对每一条训练样本，问自己——"在预测的那个时间点，这个数我真的能拿到吗？"拿不到，就删。
还有标准化泄漏：用全量数据算均值方差做归一化。在小样本 SKU 上，这个泄漏能让验证集虚高好几个点。正确做法：只用训练集算统计量，验证集和测试集套用。
特征越多越好吗？说说权衡取舍
最后说个得罪人的判断：特征不是越多越好。
我见过一个 200 多个特征的模型，验证集上比 30 个特征的版本准了 2 个点。客户很兴奋，我泼了冷水：这 200 个特征里，有 60 多个依赖外部数据源——天气接口、港口拥堵指数、社交媒体热度。任何一个接口挂了、改版了、收费了，模型就得返工。维护 200 个特征的数据管线，需要一个专职的数据工程师；维护 30 个，运营团队自己就能搞定。
那 2 个点的准确率提升，值不值一个全职人力？对月出 40 万单的仓，可能值；对月出 3 万单的小仓，肯定不值。特征工程的终点不是"最准的模型"，是"组织养得起的模型"。我的建议：先用 20～30 个核心特征跑起来，上线、验证、看到业务效果，再决定要不要加。能稳定跑两年的 30 特征模型，胜过跑三个月就没人维护的 200 特征模型。
验收的时候别只看准确率那一个数。我要求客户看三个：第一，对比基线——模型必须显著超过"用去年同期"或"用过去 4 周均值"这种笨办法，超不过就别上线；第二，分层看——畅销品、长尾品、新品分开算准确率，平均数会骗人，模型经常在畅销品上很准、长尾上瞎猜；第三，看决策价值——预测准 5 个点，到底少了多少缺货、省了多少呆滞库存？算不出来业务账的技术指标，都是自嗨。
回到开头那句话：模型选错很少致命，特征做错必死无疑。下次再有人跟你聊仓库 AI 预测，别问他用什么模型，问他特征表长什么样。答不上来的，项目多半还在"演示很美"的阶段。真正的功夫，永远在提示词之外。
