一、项目背景 我们给一家连锁餐饮做供应链协同，这家店有几十个门店，卖的是带保质期的半成品和生鲜。补货最早靠店长凭感觉报数，报多了门店堆货过期，报少了高峰期断货，总部完全看不到各店真实库存，月底损耗一算吓一跳。更糟的是保质期，食材临期没有预警，经常是过期了才发现，只能整批报废，既亏钱又有可能流出问题批次。我们接手时，总部最想要的就是两件事：别断货，也别报废，还得能看清每家店到底有多少货。

中央仓和门店仓我们做了分级，保质期短的本地直配，保质期长的走中央仓统配，避免短保品在长途上耗掉太多可用天数，到店就快到期。

项目推进里最难的是让门店愿意扫批次码，初期觉得多一步动作，我们把它和收货流程绑死，不扫码不能入系统，坚持两周后店员发现查临期真的方便，抵触就消失了。

二、落地场景 第一块是门店销量预测，每个智能体盯着自己门店的历史销售、天气和促销，给出未来几天的销量预估。第二块是智能补货建议，结合预测、当前库存和在途订单，算出该补多少、什么时候补。第三块是保质期批次追踪，每批入库食材带批次和到期时间，系统全程跟着走。第四块是临期预警与调拨，临期食材先在同城门店间调拨消化，调不掉的再走报废，报废要审批留痕。最后是损耗看板，总部实时看各店缺货率、报废率和周转天数。

预测还有个坑是节假日，平时模型准，一到长假销量翻倍，我们单独给节假日打标并叠加历史同期，否则补货点算出来偏低，假期直接断货。

三、关键技术挑战与解决思路 销量预测不准是头号难题。单纯看历史均值会被促销和天气带偏，我们让门店智能体把促销计划和天气因子都吃进去，预测误差比纯均值小了一截。补货触发要平衡，补少了断货补多了报废，我们设了安全库存加动态补货点，旺季自动抬高。批次追踪最容易漏，我们强制入库必须扫批次码，过期前系统按先进先出推调拨。临期调拨靠同城网络，我们做了门店地理分群，调拨只在同群内短驳，避免长途运输把食材折腾坏。

总部视角变化最大，以前月度经营会靠各店长口头报数，现在打开看板就能看见每家店的缺货和报废，开会从扯皮变成直接定补货策略。

门店预测还有一个隐藏输入是促销，总部搞活动时单店销量会短期翻倍，如果模型只吃历史均值就会严重低估，我们把促销计划作为显式特征喂进去，并给活动日单独加权，否则补货点在活动期会算低导致断货，这个坑我们在一次店庆断货后才补上，之前纯靠均值确实懵。另外天气对生鲜损耗的影响我们也单独建模，台风天配送难、损耗高，模型会提前建议少补并加快调拨，这部分虽小但对报废率贡献不小。

四、效果数据 上线约半年，门店平均缺货率从约百分之八降到约百分之三，高峰期断货投诉明显少了。报废率从约百分之六降到约百分之二，光这一项一年省下的损耗就很可观。库存周转天数缩短约三成，钱压在货上的少了。预测准确率提升到约八成，总部第一次能看清全部门店的真实库存，月底损耗复盘从拍脑袋变成看数据。

数据打通后总部开始做跨店调拨决策，不再各店自扫门前雪，热门品在门店间腾挪，整体缺货和报废同时往下走，这块协同效益比单店优化大得多。

五、可复用经验总结 餐饮补货最怕拍脑袋，总部看不到店里真实库存，所有决策都是盲的，我们早期靠店长报数，报多报少都失真，损耗就是这么来的。批次追踪必须强制扫码，临期预警才有抓手，否则过期了才发现等于白干。临期先调拨再报废，同城短驳能救回一大半本来要扔的货。说到底这种供应链，数据通了人才能做对决定，系统把看不清这个根问题解决了，损耗自然下来。

餐饮供应链系统，预测是发动机但批次追踪是底盘，没有批次追踪，临期预警就是空话，我们这次是先补底盘再做预测，顺序不能反。

供应链数字化没有捷径，先把底盘打牢再谈智能，我们这次的顺序如果反过来，效果一定大打折扣。

结语 现在这家连锁把批次扫码当成收货铁律，近期在接供应商直送的预测协同，让补货点更靠前。

案例片段（已脱敏）： 临期调拨片段（伪码）：for batch in nearExpiry(store, days=2):    targets = peerStores(store, withinKm=5)   // 同城同群    for t in targets if t.Need(batch.Item) > 0:        transfer(batch, t)                     // 先调拨消化        break if batch.NotTransferred:    scrap(batch, approveRequired=true)         // 调不掉的再报废我们统计过上线前一个月，约七成报废本可以在临期前两三天调拨到其他门店消化；规则上线后，这部分里有六成以上被成功调拨，直接减少了对应比例的报废。