AI+零售连锁，一个店长的自救实录 [特殊字符]

菜鸟Java码农

204人浏览 · 2026-06-10 17:49:03

菜鸟Java码农 · 2026-06-10 17:49:03 发布

老王今年35岁，管着5家社区超市。区域经理头衔好听，实际每天骑电动车到处跑，微信群999+。

最崩溃三件事干了八年没解决：库存永远对不上、排班永远排不好、促销永远看不出效果。

上个月盘点，洗衣液账面120瓶实际货架60瓶。剩下60瓶去哪了？查了一天——盘点表手写的"20"被看成了"120" 😂 这种低级错误每天都在发生。

想用系统管，公司ERP是十年前的查个数据等五分钟。自己买SaaS一个月好几千老板不批。三个月前用LangChain+Ollama+Chroma搭了本地工具，零成本数据不出门店。来看看 👇

场景一：库存管理——RAG商品信息库

故事

开超市最怕的不是没人来买，是东西少了你不知道，东西多了你也不知道。

老王遇到过最离谱的事：A店光明鲜奶还有两天过期每天倒十几瓶，B店同款鲜奶断货了店长在群里催采购。两个店就隔了两条街，一个信息差，一天损失两三百，一个月就是七八千。以前靠各店长下班前在群里报库存——问题是忙起来忘报、报了没仔细数、报了也没人汇总分析，纯走形式。

方案

他把五家店所有SKU信息、实时库存、保质期、销量、供应商报价全整理成结构化数据，存进本地Chroma向量库。BGE-M3做嵌入，Ollama跑Qwen2.5做问答。

现在手机问："光明鲜奶950ml，哪家店库存低于20瓶？按保质期排序。"10秒出结果——A店3瓶明天到期、C店15瓶后天到期。原理：自然语言→大模型理解意图→Chroma检索SKU→关联实时库存→输出结果，全程本地完成。

三个关键坑 🕳️

坑一：数据同步不及时。 每周手动导一次库存表，周五导的周六做促销卖空了，周一系统还显示有货，拉出来的数据全是错的。现在设了每日自动同步，用Windows定时任务每晚11点从各店POS系统拉数据，不费事但管用——库存准确性从"大概差不多"变成了"基本准确"。

坑二：商品名称五花八门。 A店系统里叫"农夫山泉550ml"，B店叫"农夫矿泉水小瓶"，C店直接叫"农夫550"。向量检索的时候三个名字对不上号，搜"农夫山泉"只能找到A店数据。老王足足花了两个周末做标准SKU映射表，把五家店不同系统的别名全对应到同一个标准名称。这一步又枯燥又累，但省不了——名称不统一检索就是残废的。

坑三：知识库没有分层设计。 一开始所有数据一股脑全塞进一个库里——商品信息、实时库存、供应商报价、促销活动全混在一起。搜"牛奶库存"可能返回供应商电话，噪音巨大。后来他拆成三个独立知识库：商品基础信息库放不变的数据、实时库存库存每天的变动、供应商信息库单独维护。分库之后检索速度提升一倍，结果准确率也明显上来了。

场景二：排班调度——Agent智能分配

故事

连锁零售的人事难题里排第一名就是排班。

五家店四十多个员工，有全职有兼职有大学生周末工。有人只能上早班因为要接孩子放学，有人只能上晚班因为白天还有另一份工，周末和节假日客流暴增平时反而平稳。还要保证每个班次收银台有人、理货区有人、生鲜区有人。

老王以前排一次班要在Excel前面算半天，来回调来调去。有一次排错了——一个全职员工一周上了61个小时班，超出劳动法规定的每周工时上限，差点被这个员工投诉到劳动监察大队。老王说：“我真不是故意的，就是算着算着算错了。”

方案

他用LangChain搭了一个排班调度Agent。逻辑分三步走：第一步录入所有约束条件——每个员工姓名、岗位、可上班时段、每周工时上限、技能标签（谁会收银谁会切肉）。第二步Agent根据约束自动生成初步排班表，先把"硬约束"分配了（比如某人只能上早班），再优化"软约束"（尽量让同一员工连续上同一班次减少通勤成本）。第三步自动检查——有没有人超工时、有没有岗位空缺、有没有技能不匹配。查完没问题再出最终版。

三个关键坑 🕳️

坑一：忘了节假日这个变量。 五一假期前两天Agent照常排班没给任何人多排，结果假期三天客流暴增三倍店里人手严重不够，顾客排队排到门外。现在老王在排班prompt里加了节假日日历模块，Agent会自动识别法定节假日和周末，根据历史同期客流数据上调人手配置。

坑二：完全依赖Agent审查不够。 有一次Agent把两个之前闹过矛盾的员工排在了同一班次，老王收到排班表直接发了。结果当天两个人在店里当着顾客的面吵起来 😅 AI永远不知道人情世故，任何主观约束你都必须在prompt里明确写出来，别指望AI自己猜到。

坑三：不设人工确认环节。 以前排班表直接发工作群店长照办。现在改了流程：Agent出初稿→发给各店长确认→店长可提出调整需求→汇总后最终发布。 多花半小时但少了无数后续扯皮。机器的归机器，人的归人。

场景三：促销分析——Text-to-SQL数据驱动

故事

每次做完促销活动，最让老王头大的是复盘。

上个月牛奶搞了个"买二送一"，销售额涨了50%看着挺不错。但到底赚了还是亏了？促销前日均卖30瓶，促销期间卖了90瓶——账面确实多了。但送掉的那30瓶成本算了没？促销带动的额外物流和人工成本算了没？促销结束后销量会不会因为顾客囤货而暴跌？

以前这些分析考他在Excel里手动拉数据自己列公式，算一遍要半天，算完就忘了，下次促销还是拍脑袋——“上次买二送一效果好像还行？那就再搞一次。”

方案

他把各店的销售流水同步到本地SQLite数据库，用LangChain做Text-to-SQL查询。现在直接用大白话问系统：

“上周洗护用品促销，参加活动的SKU和不参加的，日均销量变化对比多少？”
“买二送一活动算上赠品成本和额外物流人工，实际毛利率是多少？”
“上次促销结束后一周，日均销量恢复到促销前水平的百分之多少？”

大模型理解他的问题后自动生成SQL语句去数据库查，返回结构化结果。老王不需要会写SQL，只需要知道自己想问什么。

三个关键坑 🕳️

坑一：数据库字段口径乱七八糟。 销售记录里品类字段惨不忍睹——“洗护”、“洗护用品”、“日化-洗护”、“个护清洁”，四个名字全指同一个品类。老王花了一整周清洗历史数据统一了所有品类的命名规则。这一步最枯燥但AI查出来对不对全靠这个。

坑二：大模型对财务概念理解有偏差。 问"毛利率"大模型算出来一个几十万的数字——因为它把"毛利率"当成了"毛利额"。老王还以为这个月发财了 😂 现在他在prompt里明确定义了所有计算公式：毛利率=(销售额-成本)/销售额×100%。促销ROI=(促销期增量销售额-促销成本)/促销成本。

坑三：只看单次促销效果不看长期影响。 买二送一当月销量翻倍，但促销结束后一周日均销量掉到了原来的70%。为啥？因为顾客趁促销囤货了，把接下来一周的量提前买了。不对比长期数据的人看了只觉得"促销效果很好"，对的人看了知道"总销量没变还多送了赠品"。现在强制对比三个时间段：促销前两周基线→促销中→促销后两周恢复期。三段数据一起看才敢说赚了还是亏了。