一、项目背景

这是一家扎根社区的便利店连锁，门店近三百家，鲜食（饭团、便当、关东煮、烘焙）是毛利担当，但也最头疼。接手前每家店的鲜食报货完全靠店长经验：保守了中午就空架、激进了晚上剩一堆扔掉。行业里鲜食损耗率普遍不低，这家店长期在两位数徘徊。另一块是社区订单——周边居民想线上下单、到店自提或就近配送，但门店系统没有这个能力，只能挂第三方平台，抽成高、履约还慢。我们当时的切入点是两件事：把鲜食报货从"拍脑袋"变成"看数据"，把社区履约从"靠别人"变成"自己接"。

二、落地场景

我们采用的门店系统给每家店做了"鲜食日配报货建议"模块：结合历史销量、天气、节假日、周边客流特征，每天下午给店长推一个报货清单，店长可以一键采纳或微调。社区侧打通了小程序下单，居民选"到店自提"或"即时配送"，订单进门店履约。门店库存做了效期管理，临期商品自动置顶促销、到期自动报废锁定，不让过期品上架。总部能看到每张单的损耗、周转和履约时长，按店排名做运营督导。

三、关键技术挑战与解决思路

第一个挑战是报货预测的冷启动。新店没数据、老店有季节波动，直接上复杂模型会翻车。我们先用"同类型门店聚类 + 移动平均"做基线，跑满四周积累本店数据后再切到带天气和节假日的轻量回归，预测粒度到"单品×单店×单日"。第二个挑战是损耗和缺货的跷跷板——压损耗容易缺货、保供给又涨损耗。我们的目标函数不是单纯最小化损耗，而是最大化"毛利贡献 - 损耗成本"，给每个单品设了可售时长窗口，超过窗口就触发降价而不是继续占架。第三个挑战是社区履约的时效，门店人手有限，我们把配送对接到周边骑手运力池，自提单优先，配送单按门店忙闲错峰接，避免高峰期店员顾不上打包。

案例片段（已脱敏）： 某社区店便当报货的真实调整——历史日均卖 42 份，周五因下班客流高曾冲到 71 份。系统结合"周五 + 晴 + 周边写字楼下班"特征，建议报 58 份；店长微调到 62 份。当日实际售出 60 份，剩余 2 份在效期窗口内降价清掉，损耗成本近乎为零，而未接入预测前同类周五平均剩 11 份直接报废。 效期管理规则片段：if (now > 到期时间 - 2h) then 状态=临期促销; if (now > 到期时间) then 状态=锁定报废 and 禁止上架 AND 生成损耗记录。上线后过期品上架事故从每月约 6 起降到 0。

四、效果数据

跑了约三个月，整体鲜食损耗率从约 11.3% 降到约 6.1%，光这一项对连锁毛利就是可观改善。报货准确率（实际销量落在建议量 ±15% 内）从约 64% 提升到约 88%。社区订单的到店自提平均时长约 12 分钟，即时配送平均约 26 分钟，比接第三方时快了不少，平台抽成也省了。门店库存周转天数从约 2.1 天降到约 1.4 天。数字为脱敏示意值，不同业态门店波动较大。

五、可复用经验总结

第一，鲜食报货不能追求"零损耗"，要追求"损耗和缺货的均衡利润最优"。第二，预测要分阶段，冷启动用简单方法、有数据再上模型，别一上来就堆复杂度。第三，效期管理必须系统强制，靠人记得住是侥幸。第四，社区履约能用自有运力就别全挂第三方，把控时效也省成本。这套"预测报货 + 效期强管控 + 自有履约"的组合，后来在烘焙、餐饮连锁的日配场景都被复用。

附：工程落地细节

报货预测的基线阶段我们用了同类型门店的销量聚类，先找到"和这家店画像最像的二十家店"，用它们的均值做冷启动，跑满四周本店数据后切到带天气和节假日特征的轻量回归，预测粒度到单品乘单店乘单日。效期管理在数据库层用定时任务扫，临期两小时自动置顶促销标签，过期瞬间锁状态禁止上架并生成损耗记录，店员在前台根本点不出过期品。社区履约的配送对接了我们自己谈的周边骑手运力池，自提单优先占用店员空闲档，配送单在午晚高峰错峰接，避免打包挤占收银。

附：给同行的一点提醒

鲜食这件事的本质是损耗和缺货的跷跷板，别把目标设成单纯最小化损耗，那样必然缺货，要追求损耗成本与毛利贡献的差值最大。预测要分阶段，冷启动用简单方法、有数据再上模型，一上来堆复杂度反而容易翻车。效期管控必须系统强制，靠人记得住是侥幸，我们上线前每月都有过期品上架的事故，强制锁定后归零。

附：一点落地后的量化补充

报货建议我们给店长保留了"一键采纳"和"微调"两个入口，数据证明约七成的店长直接采纳、两成小幅微调、只有一成会大幅改动，说明模型的基线已经比较可信。社区履约上线后，我们对比了接自有运力和接第三方的同类型门店，自有运力那组的履约时长平均短约七分钟、每单成本低约两成。总部运营督导现在每天看一张"损耗与周转"排名表，尾部门店会被定向辅导，整个连锁的鲜食管理水平被拉平了。