零售业务智能化落地干货

整理自智能制作 + 智能订货多年踩坑，2026-05-08

一、别急着上模型，先把数据搞干净

很多团队上来就想做预测模型，数据还是一塌糊涂。库存准确率不知道多少、销售数据里促销期没标注、断货期的数据混在正常销售里——这种数据喂进去，模型学到的全是噪音，上线了还不如规则。

做制作计划，最早上来就想做烤箱维度的精细管控，结果几块基础数据都没到位：SKU 加工工艺信息不全、库存数据不准、销量预测没有可信的基础、门店设备信息也没建设好——这些依赖没打好，方案直接死掉。后来从分类总量开始，一步步往细走，花了数年才走到事件驱动。

记住：数据成熟度和业务成熟度不到位，过早精细化是在浪费时间。先跑通粗粒度，等数据和业务都稳了，再往细做。

立项前先问自己：

团队最容易犯的错：想一口气把整个智能化体系搭起来，结果每块都做了，没一块真正好用，业务也不买账。

正确做法是：先找到店里当下最疼的那个点，把它解决好，让业务真实感受到变化，再往下推。

什么叫「最疼」，要从业务视角定义，不是技术视角。「我们能做预测」不等于「这是店里现在最需要的事」。去门店转转，问问店长，比在会议室开需求评审强。

上线前要能回答：解决这一个问题之后，哪个指标会变好、变多少？说不出来，这个需求先缓一缓。

很多团队觉得上了模型就应该把规则干掉，这个想法很危险。

规则是人把业务知识显式编进去的——最小起订量、货架期、供应商关系、促销限制，这些在规则里一目了然。模型学的是历史数据，历史数据里不一定有这些知识。做销量预测跑过好几版模型，有些 SKU 模型效果和规则差不多，甚至不如规则——就是因为这个原因。

比较靠谱的做法是混合调度：

SKU 分类路由
├── 长尾 / 新品 / 冷启动 SKU  → 规则兜底（数据少，模型不稳）
├── 跑量、数据稳定的 SKU      → 模型来做
└── 异常解释 / 规则生成        → 大模型辅助（不是用来直接出订货量的）

大模型在这里最适合的是「解释这次为什么预测偏了」「帮我生成一条新规则」，而不是直接拍一个订货数出来。

衡量标准：别把「上了模型」当 KPI，把「缺货率/库存周转改善了多少」当 KPI。每次模型上线要有对照组，才知道模型到底比规则强在哪。

很多团队把「店长/采购改了系统的数」当成失败信号，觉得人不信任系统。这个理解反了。

人改系统的数，说明系统不知道的事情存在：今天有个本地活动、这个供应商最近不稳定、这批货快过期要少订——这些信息系统拿不到，但人知道。人工调整行为本身就是最有价值的训练信号。

问题是，这个闭环能不能转起来，核心前提是系统要先让人少干活。如果系统没有帮人减负，推广成本就会很高，人不愿意用，fix 信号就收不到，系统永远进化不了。

推动路径，顺序不能反：

系统出一版数（不是让人从零填）
      ↓
人基于系统数调整（工作量大幅减少）
      ↓
调整行为 + 调整原因记录下来（这是信号）
      ↓
定期回收信号 → 迭代模型 / 规则

做产品时要注意：调整入口不只是「能改数字」，还要能记录「为什么改」。只记录改了多少，信号价值减半。

零售订货的效果评估比大多数人想的难——订货决策到销售结果有 1-7 天滞后，期间还有天气、活动、竞品这些干扰因素，很难说清楚「到底是模型的功劳还是市场自然好转」。

所以指标要在上线前就定好，而不是上线后再补。

三个核心指标要一起盯，单盯一个会出问题：

最简单可行的 A/B 方案：把相似门店分两组，一组走新策略、一组走旧策略，盯两周，对比这三个指标的变化。不完美，但够用，比「感觉变好了」可信多了。