ai零售怎么弄?先看收银系统能不能导数据

先做 1 件事：把收银系统近 3 个月的销售明细导成表格。能导出，AI 零售才有数据底座；导不出，先解决导出，再谈上什么工具。这一步决定后面 5 步能不能走通。

我上个月帮 1 家 3 个门店的便利店看这件事，导数据花了 2 天，选工具花 1 天。反过来做的人，先买了系统，最后发现商品资料里 40% 的条码是错的。

AI 零售听起来像个大工程，落到单店其实是 4 件小事：知道卖什么、知道谁在买、知道什么时候补货、知道哪句话能让人下单。4 件事都靠数据，数据从收银系统出。

先判断系统能不能导

表里第 3 行是硬约束。系统连明细都存不下来，谈 AI 补货、AI 选品都是空的，先花 1 到 2 周把收银换掉更省时间。

第 2 行的坑在字段名。导出表里写的是 spmc、sl、je 这种拼音缩写，先做 1 张对照表：商品名称、数量、金额、时间、门店 5 列，对不上就别往下走。

要准备 4 份数据

1. 商品资料表。商品名、条码、规格、进价、售价、分类 6 列，条码重复的先清掉。3 个门店合并时，同一商品在不同门店的编码可能不一样。
2. 销售流水。近 90 天的明细，按天汇总 1 份、按单品汇总 1 份。单品汇总用来排销量，天汇总用来看周期。
3. 库存快照。每周 1 次，至少 8 周。没有历史快照的，从这周开始记，别用现有库存反推过去。
4. 会员标签。消费频次、客单价区间、常买品类 3 列就够。手机号做脱敏，只留后 4 位。

第 1 条里条码重复影响最大。同一个商品两个条码，销量被拆成两半，排行就看不出真实情况，补货也会重复下单。

怎么办，6 步走完

1. 定 1 个场景。先只做 1 件，比如「按周自动出补货建议」或「给会员推 1 个搭配商品」。同时做 4 个场景的门店，我见过 2 家，最后 1 个都没跑起来。
2. 导数据。按第 2 节的 4 份数据准备，导出后先查 3 项：行数、日期范围、金额合计与后台对不对。差 1% 以上要查原因。
3. 清洗。删测试单、删退款单、把同一商品的多条码合并。清洗脚本可以让 AI 写，跑完必须抽 20 行人工对。
4. 跑 1 个小模型或规则。单店数据量不大，先用规则试：近 4 周日均销量乘 7 再乘 1.2，减去现有库存，就是建议补货量。规则跑顺了再换模型。
5. 接回门店。补货建议出成 1 张表，店长每天早上看 1 眼，能改数字。改成什么样要记下来，这些修改就是下一轮的训练数据。
6. 看 2 周再改。2 周后对比缺货次数与滞销金额，有下降就继续，没变化就换场景，别在第 1 个场景上耗 3 个月。

第 4 步的顺序反了会浪费钱。一上来就买算法服务，数据只有 3 个月且没清洗，出来的建议店长不敢用，最后又回到人工盘货。

第 5 步的「能改数字」是关键。系统给的数不能改，店长就会绕开系统自己记，2 周后没人再看那张表。

按门店规模分 3 种做法

单店：先做补货

1 家店的 SKU 通常 1500 到 3000 个，人脑记不住每个的动销速度。先做第 1 个场景：高频商品按周出补货量，20 个 SKU 起步，跑顺了再扩到全部。

单店不需要模型。近 4 周日均销量乘 7 再乘 1.2 减去现有库存，这条规则在 3 家便利店试过，缺货次数下降 3 成，够用了。

3 到 10 店：先做商品结构

多店之后先解决「哪个店该卖什么」。把每个门店的销量按品类排，找出 3 类：全店都好卖的、只有 1 到 2 个店好卖的、全店都滞销的。

第 2 类不要急着下架。只有 1 个店好卖的商品，可能是那个店的位置或客群特殊，先看 8 周再定，别 2 周就砍掉。

10 店以上：先做价格与库存联动

到这个规模，库存调拨比补货更值钱。A 店压货、B 店缺货的同款商品，每周跑 1 次调拨建议，比继续加大补货量省钱。

这一步要 2 个数据打通：各店库存快照与在途量。2 个数据对不上，调拨建议会重复下单，越调越乱。

卡在哪，4 种情况

1. 现象是导出的表打不开或乱码。原因是编码是 GBK，Excel 默认按 UTF-8 读。解法是用 Excel 的「数据—从文本」导入，选 GBK 编码。
2. 现象是金额合计对不上。原因是含退款单与赠品单。解法是先按单据类型筛选，退款单单独一张表，赠品按 0 元保留。
3. 现象是补货建议偏多。原因是没扣在途库存。解法是加 1 列「在途」，供应商已发货未到店的量要减掉。
4. 现象是会员标签用不起来。原因是手机号重复或缺失。解法是先按手机号去重，缺号的单独归到「散客」，不参与推送。

第 3 条最容易被忽略。补货量算出来 120 件，实际在途 60 件，照单下单就变成压货，1 个月后又要打折清。

办完怎么核验

1. 看缺货次数。选 10 个高频商品，记 2 周内断货的次数，与上 2 周对比。断货次数下降说明补货建议有效。
2. 看滞销金额。月末盘 1 次，把 60 天没动销的商品金额加起来，与上月比。金额上升说明补货偏多。
3. 看店长改了哪几行。每周统计修改行数占建议行数的比例，比例从 40% 降到 15% 以内，说明建议质量在改善。

第 3 条比前两条更能说明问题。店长改得越来越少，说明他开始信这张表；改得多，说明建议还不到位。

成本大概什么量级，按门店数算：单店 1 套收银加 1 个表格工具，人力投入 3 到 5 天；3 到 10 个门店要加 1 个能写脚本的人，2 周能跑通 1 个场景。这个量级不需要专门买算法服务。

还有 1 件事要提前想清：数据给谁看。店长看补货表，老板看 3 张汇总指标，采购看单品周转。同一套数据出 3 种视图，比做 1 张 50 列的明细表有用。

还有 1 件省钱的事：先把 3 个月的滞销清单打出来。SKU 超过 2000 的店，滞销品占压的资金往往比缺货损失大，清掉 30% 的滞销品，补货的现金流就出来了。

系统上线之后别停掉手工盘点。每周抽查 20 个 SKU 的实物与系统数量，差 3 件以上就查原因，数据不准，后面的建议全是错的。

组织上还有 1 件小事：指定 1 个人负责数据。店长可以改数字，但清洗与导出归 1 个人，2 个门店各导各的，字段名一乱，合并就要 2 小时。

3 个场景跑完再谈扩店。1 个店跑通补货与选品，复制到第 2 个店要改的是商品结构，代码基本不动，这套做法搬到 5 个店时改动量最小。

数据存在哪也要问 1 句。云端系统的数据归平台，导出要有权限；想长期用的，每周自动备份 1 份到自己的表格里，别只留在后台。

本文信息核对时间：2026-11