简介这是一份面向中小连锁超市运营管理与数据分析从业者的深度学习需求预测方案聚焦如何基于DeepSeek模型优化零售库存决策。文档系统梳理了传统库存管理在需求预测不准确、缺乏灵活性、信息传递不及时等方面的局限并给出从数据收集清洗、特征提取、模型搭建训练到评估验证的完整路径尤其对安全库存确定、商品陈列与促销规划等实际场景有细化讲解。资源仅包含一个PDF文件压缩包整体大小约1.61MB文档共30页目录结构清晰、图文完整便于按章节研读。文档还重点解析了损失函数监控、过拟合与欠拟合处理、评估指标选择与交叉验证等调优细节强调了数据质量对预测效果的决定性影响并由实际应用案例展示补货决策与销售业绩的改善。目前已有98人学习下载适合具备一定数据分析基础、希望借助深度学习提升超市运营效率的读者参考。1. 库存预测落不了地的锅不能都让算法背中小连锁超市最典型的库存困境是“怕缺货就多下单”生鲜、日配这类短保商品采购员手上没有需求数字只能按上周销量再乘一个经验系数结果畅销 SKU 缺货、滞销 SKU 积压同时存在。需求预测不是新概念但大多数门店连一张按“门店SKU日期”整理的销售明细都没有模型自然无从落地。这篇内容讲一条能跑的路径用 DeepSeek 的 API或内网本地部署做未来 7 天需求预测预测结果再换算成建议订货量落到补货流程里。适合没有专职数据团队的中小连锁超市也适合系统开发、运营、采购侧的同学判断这个方向值不值得自己搭一遍。2. 做 DeepSeek 需求预测前先把销售数据垫成“门店SKU日”宽表2.1 数据不是“库存表”而是一张干净的销售事实表一上来就把 POS 系统的数据拿来喂给模型第一道坎就是粒度混乱有的门店一天导出一次有的是订单行级还有的把退货款算成负数混在销售里。常见做法是先落一张最朴素的销售事实表五个字段够用store_id, sku_id, date, qty, amount有几个字段容易漏。门店编码要能对应到面积、商圈类型后面做特征才有意义SKU 要有品类、包装规格否则生鲜和饮料混在一起做预测模型很难学出规律。如果原来的商品档案里有“是否赠品”“是否烟草”这类字段先做一轮筛选把不可预测的 SKU 摘出来。2.2 生成滞后期与星期特征先别急着上深度学习DeepSeek 这类模型做预测依赖的是你在提示词里给它的上下文。因此把“历史长什么样”编成数字特征比模型本身更重要。我一般会先做下面这几列import pandas as pd sales pd.read_csv(sales_fact.csv, parse_dates[date]) sales ( sales.groupby([store_id, sku_id, date], as_indexFalse)[qty] .sum() ) sales sales.sort_values([store_id, sku_id, date]).reset_index(dropTrue) g sales.groupby([store_id, sku_id])[qty] sales[lag1] g.shift(1) # 昨天卖了多少 sales[lag7] g.shift(7) # 上个星期同期 sales[ma7] g.transform( lambda x: x.shift(1).rolling(7).mean() ) # 近7天均值排除当天 sales[ma28] g.transform( lambda x: x.shift(1).rolling(28).mean() ) # 近28天均值 sales[dow] sales[date].dt.dayofweek # 周一0周日6这里的核心其实只有一列销量加的都是时间特征。shift 的作用是让模型在看“今天”时不知道今天实际销量只能依赖昨天的值lag1和上周同期的值lag7避免模型看到答案。ma7、ma28 表达最近销售走势的平滑趋势。dow 是星期几周末型商品的规律基本靠它体现。对于中小连锁超市几十个门店、几千个 SKU 的量完全用不着分布式计算pandas 就能跑完特征生产。注意g.shift(1)在 groupby 之后仍然保持按门店和 SKU 分组位移不会出现跨门店错位。2.3 促销与节假日对需求预测影响最大的两个变量如果在提示词里只给历史销量模型无法解释“上周六突然多卖 50 件是因为买一送一还是因为节假日”。所以要在特征里明确告诉模型这两类事件。常见做法是维护一张促销计划表然后按“门店SKU日期”展开成逐日标记promo pd.DataFrame({ store_id: [S001, S001], sku_id: [SKU1001, SKU1001], start_date: [2025-07-12, 2025-08-01], end_date: [2025-07-14, 2025-08-03], }) promo[start_date] pd.to_datetime(promo[start_date]) promo[end_date] pd.to_datetime(promo[end_date]) rows promo.apply( lambda r: pd.DataFrame({ store_id: r[store_id], sku_id: r[sku_id], date: pd.date_range(r[start_date], r[end_date]), }), axis1, ) promo_daily pd.concat(rows.tolist(), ignore_indexTrue) promo_daily[is_promo] 1展开后的 promo_daily 再按 store_id、sku_id、date 合并回销售表就把“当天有没有促销”变成 0/1 列。节假日可以不用写死在代码里直接用chinese_calendar这类库生成或者在数据库中维护一张节假日日历表更直白。未来 7 天是否促销、是否节假日、星期几要跟着历史特征一起写进提示词后面第 4 章的调优才有意义。3. 调通 DeepSeek 预测接口Prompt 模板、temperature 与 JSON 返回3.1 安装与第一步请求用 OpenAI 兼容 SDK 就够了DeepSeek 的 API 兼容 OpenAI 的接口格式不需要额外引入专用 SDK。装一个 openai 库把 base_url 指过去就行pip install openai export DEEPSEEK_API_KEYsk-...from openai import OpenAI client OpenAI( api_keyyour_api_key, # 生产环境从环境变量读取不要写死 base_urlhttps://api.deepseek.com/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是零售需求预测助手输出 JSON。}, {role: user, content: 请预测未来 7 天销量。} ], temperature0.2, response_format{type: json_object} ) print(resp.choices[0].message.content)这里关键的两个参数是 model 和 temperature。model 常见选择是deepseek-chat普通对话响应快和deepseek-reasoner带思考过程适合复杂推理具体可用模型名以官网当前文档为准。temperature 控制随机性0.10.3 适合预测任务取值太高会出现同一天预测值忽高忽低短期销量预测我一般固定 0.2 上下。response_format是让模型强制输出 JSON 的开关。没有它模型经常在数字后面附带“这个预测是基于……”之类的解释解析会很痛苦。对数据任务这个参数基本属于必开。提示如果某些模型不支持response_format退而求其次是在提示词里写死“只输出 JSON不要输出解释”并在解析层做容错重试。如果门店数据不能出内网也可以把这套 prompt 放到本地部署的 DeepSeek 服务上base_url换成内网地址即可业务代码不用改。3.2 提示词模板把历史特征当成上下文让模型做预测比让模型写诗简单得多前提是把问题描述清楚。我会固定一个四段式模板每次都复用同一套角色与任务、特征说明、历史序列、输出要求。def build_prompt(row, forecast_days7): return f 你是中小连锁超市的需求预测助手。根据下面给出的 28 天日销售数据 预测该门店该 SKU 未来 {forecast_days} 天每天的销量。 历史四周数据星期、是否促销、是否节假日、销量 {row[history]} 输出要求 预测未来 {forecast_days} 天的每日销量格式为 JSON。 字段名依次为 date, forecast, confidence_low, confidence_high。 不要输出其他文字。 提示词里注意几点。历史序列只保留四周与相关标签太长模型容易被噪音干扰不要混入“每周总销量”“环比增长”这类由模型去理解的字段。confidence_low 和 confidence_high 是让模型在拿不准时用区间表达不确定性后面算安全库存会用到。3.3 拿到响应后的校验先做类型检查再进预测表接口返回的结构是resp.choices[0].message.content但模型即使开了 JSON 模式也可能返回空字符串或字段缺失。需要包一层解析和校验函数import json def parse_forecast(content: str) - dict: payload json.loads(content) assert forecast in payload, missing forecast assert isinstance(payload[forecast], list), forecast must be list assert len(payload[forecast]) 7, expected 7 days return payload这段代码的核心是“宁可这轮失败重试也不要让脏数据流进库存系统”。模型输出的小数保留两位如果某个 SKU 预测出负数直接截断成 0而不是报错因为补货环节天然不接受负需求。temperature 取值适用场景特点0 0.2短期销量预测、库存补货确定性高多次运行结果接近0.3 0.7生成多版本预测做集成结果有波动需要多次采样取均值0.8 以上头脑风暴、探索性分析一般不用于生产预测4. 用 MAPE / WAPE 评估 DeepSeek 预测先分快慢品再调 prompt4.1 预测结果要与真实值对齐DeepSeek 每轮预测的是“未来 7 天”但到第 8 天真实销售数据已经出来了。上线时最好把每次模型预测落一张表字段包含 store_id、sku_id、date、pred_qty、pred_low、pred_high、model_version、created_at等真实数据出来后再合并pred pd.read_csv(deepseek_forecast.csv) actual pd.read_csv(sales_fact.csv, usecols[store_id, sku_id, date, qty]) merged pred.merge( actual, on[store_id, sku_id, date], suffixes(_pred, _act) ) merged[abs_err] (merged[qty_act] - merged[qty_pred]).abs()merge 的结果就是后面计算指标的唯一依据。这里不需要复杂的时序对齐逻辑只要保证两张表的日期格式一致并且 actual 只取当天已落库的真实销量。4.2 指标口径不要只看 MAPE也要看 WAPE 和 BIAS指标计算方式说明MAPEmean(abs_err / qty_act) × 100%容易被日销 0/1 件的慢动品带偏WAPEsum(abs_err) / sum(qty_act) × 100%按销量加权整体偏差看得准BIASsum(qty_act - qty_pred) / sum(qty_act) × 100%正值代表系统性低估负值代表高估total_act merged[qty_act].sum() wape merged[abs_err].sum() / total_act * 100 bias (merged[qty_act] - merged[qty_pred]).sum() / total_act * 100注意这里 qty_act 可能为 0MAPE 会被除零干扰所以慢动品和快动品必须分开评估。日常销量大于 5 件的 SKU 用 WAPE 做口径销量经常只有 1 件的 SKU直接看区间覆盖比看百分比更有意义。4.3 DeepSeek 预测调参的关键few-shot 与上下文修剪第一轮 WAPE 在 30% 以上时不需要急着换模型先检查上下文。两个前提条件第一历史特征是否用了 4 周以上第二提示词里有没有说明预测日是否为促销日。在此基础上可以做 few-shot 调整把过去一周的真实序列放进提示词few_shot 最近7天实际销售 周一 2件周二 1件周三 3件周四 4件 周五 6件促销周六 8件周日 5件。 模型会照着“周五促销销量约等于平时的 1.5 倍”这类规律推断未来。如果预测仍然明显偏差就用 0.5 的 temperature 跑三到五次取中位数压掉随机噪声。中小超市的预测任务请求量不大成本完全在可接受范围内。5. 把预测接进补货建议订货量计算与回测脚本5.1 从日预测换算成建议订货量预测值本身不能直接发给门店要转成“建议订货量”公式如下建议订货量 max(0, ceil((日均预测销量 × (到货天数 下单周期) 安全库存 − 在库 − 在途) / 包装批量) × 包装批量)import math def reorder_qty(pred_qty, lead_time2, review_period1, safety_stock3, on_hand10, on_order0, batch_size6): demand pred_qty * (lead_time review_period) need demand safety_stock - on_hand - on_order if need 0: return 0 return math.ceil(need / batch_size) * batch_size注意 pred_qty 是日平均预测销量不是 7 天总量。lead_time 是从下单到到货的天数review_period 是盘点补货间隔比如每周日补货一次这个值就是 7不是 1。on_order 是已经在途的量不扣掉会重复下单。安全库存可以用 95% 服务水平对应的 z1.65乘以近 28 天日销量的标准差再乘以下单周期加采购提前期总天数的平方根import math safety_stock round(1.65 * std_daily_qty * math.sqrt(lead_time review_period))这个公式比采购员“多备三箱”要稳定得多。5.2 回测脚本看缺货率而不是只看误差预测误差降下来不代表补货结果好。更直接的验证方法是回测用过去 4 周的预测值配上同样的补货参数模拟每天库存变化统计缺货次数。没有完整的库存模拟模型时可以用一个粗略的代理指标——“预测是否覆盖实际”merged[hit] (merged[qty_pred] merged[qty_act]).astype(int) oos_rate 1 - merged[hit].mean()如果 oos_rate 高于 8%说明安全库存设小了低于 2%说明库存积压风险高可以适当下调补货系数。5.3 一个能直接上手的技巧用模型的置信区间调安全库存最后补充一个立刻能落地的小技巧不用统一安全库存而是让 DeepSeek 在输出预测时同时输出 confidence_low 和 confidence_high然后取区间宽度作为安全库存的调整量。预测波动大的 SKU比如生鲜、促销品区间自然宽稳定商品区间窄。这样安全库存会自动向高风险 SKU 倾斜比所有 SKU 用同一个系数更合理。我在实践中把区间宽度乘以 0.3 再叠加到基本安全库存上效果比统一调整参数来得直接。本文还有配套的精品资源点击获取
DeepSeek助力中小连锁超市：库存需求预测与补货落地全流程
简介这是一份面向中小连锁超市运营管理与数据分析从业者的深度学习需求预测方案聚焦如何基于DeepSeek模型优化零售库存决策。文档系统梳理了传统库存管理在需求预测不准确、缺乏灵活性、信息传递不及时等方面的局限并给出从数据收集清洗、特征提取、模型搭建训练到评估验证的完整路径尤其对安全库存确定、商品陈列与促销规划等实际场景有细化讲解。资源仅包含一个PDF文件压缩包整体大小约1.61MB文档共30页目录结构清晰、图文完整便于按章节研读。文档还重点解析了损失函数监控、过拟合与欠拟合处理、评估指标选择与交叉验证等调优细节强调了数据质量对预测效果的决定性影响并由实际应用案例展示补货决策与销售业绩的改善。目前已有98人学习下载适合具备一定数据分析基础、希望借助深度学习提升超市运营效率的读者参考。1. 库存预测落不了地的锅不能都让算法背中小连锁超市最典型的库存困境是“怕缺货就多下单”生鲜、日配这类短保商品采购员手上没有需求数字只能按上周销量再乘一个经验系数结果畅销 SKU 缺货、滞销 SKU 积压同时存在。需求预测不是新概念但大多数门店连一张按“门店SKU日期”整理的销售明细都没有模型自然无从落地。这篇内容讲一条能跑的路径用 DeepSeek 的 API或内网本地部署做未来 7 天需求预测预测结果再换算成建议订货量落到补货流程里。适合没有专职数据团队的中小连锁超市也适合系统开发、运营、采购侧的同学判断这个方向值不值得自己搭一遍。2. 做 DeepSeek 需求预测前先把销售数据垫成“门店SKU日”宽表2.1 数据不是“库存表”而是一张干净的销售事实表一上来就把 POS 系统的数据拿来喂给模型第一道坎就是粒度混乱有的门店一天导出一次有的是订单行级还有的把退货款算成负数混在销售里。常见做法是先落一张最朴素的销售事实表五个字段够用store_id, sku_id, date, qty, amount有几个字段容易漏。门店编码要能对应到面积、商圈类型后面做特征才有意义SKU 要有品类、包装规格否则生鲜和饮料混在一起做预测模型很难学出规律。如果原来的商品档案里有“是否赠品”“是否烟草”这类字段先做一轮筛选把不可预测的 SKU 摘出来。2.2 生成滞后期与星期特征先别急着上深度学习DeepSeek 这类模型做预测依赖的是你在提示词里给它的上下文。因此把“历史长什么样”编成数字特征比模型本身更重要。我一般会先做下面这几列import pandas as pd sales pd.read_csv(sales_fact.csv, parse_dates[date]) sales ( sales.groupby([store_id, sku_id, date], as_indexFalse)[qty] .sum() ) sales sales.sort_values([store_id, sku_id, date]).reset_index(dropTrue) g sales.groupby([store_id, sku_id])[qty] sales[lag1] g.shift(1) # 昨天卖了多少 sales[lag7] g.shift(7) # 上个星期同期 sales[ma7] g.transform( lambda x: x.shift(1).rolling(7).mean() ) # 近7天均值排除当天 sales[ma28] g.transform( lambda x: x.shift(1).rolling(28).mean() ) # 近28天均值 sales[dow] sales[date].dt.dayofweek # 周一0周日6这里的核心其实只有一列销量加的都是时间特征。shift 的作用是让模型在看“今天”时不知道今天实际销量只能依赖昨天的值lag1和上周同期的值lag7避免模型看到答案。ma7、ma28 表达最近销售走势的平滑趋势。dow 是星期几周末型商品的规律基本靠它体现。对于中小连锁超市几十个门店、几千个 SKU 的量完全用不着分布式计算pandas 就能跑完特征生产。注意g.shift(1)在 groupby 之后仍然保持按门店和 SKU 分组位移不会出现跨门店错位。2.3 促销与节假日对需求预测影响最大的两个变量如果在提示词里只给历史销量模型无法解释“上周六突然多卖 50 件是因为买一送一还是因为节假日”。所以要在特征里明确告诉模型这两类事件。常见做法是维护一张促销计划表然后按“门店SKU日期”展开成逐日标记promo pd.DataFrame({ store_id: [S001, S001], sku_id: [SKU1001, SKU1001], start_date: [2025-07-12, 2025-08-01], end_date: [2025-07-14, 2025-08-03], }) promo[start_date] pd.to_datetime(promo[start_date]) promo[end_date] pd.to_datetime(promo[end_date]) rows promo.apply( lambda r: pd.DataFrame({ store_id: r[store_id], sku_id: r[sku_id], date: pd.date_range(r[start_date], r[end_date]), }), axis1, ) promo_daily pd.concat(rows.tolist(), ignore_indexTrue) promo_daily[is_promo] 1展开后的 promo_daily 再按 store_id、sku_id、date 合并回销售表就把“当天有没有促销”变成 0/1 列。节假日可以不用写死在代码里直接用chinese_calendar这类库生成或者在数据库中维护一张节假日日历表更直白。未来 7 天是否促销、是否节假日、星期几要跟着历史特征一起写进提示词后面第 4 章的调优才有意义。3. 调通 DeepSeek 预测接口Prompt 模板、temperature 与 JSON 返回3.1 安装与第一步请求用 OpenAI 兼容 SDK 就够了DeepSeek 的 API 兼容 OpenAI 的接口格式不需要额外引入专用 SDK。装一个 openai 库把 base_url 指过去就行pip install openai export DEEPSEEK_API_KEYsk-...from openai import OpenAI client OpenAI( api_keyyour_api_key, # 生产环境从环境变量读取不要写死 base_urlhttps://api.deepseek.com/v1 ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是零售需求预测助手输出 JSON。}, {role: user, content: 请预测未来 7 天销量。} ], temperature0.2, response_format{type: json_object} ) print(resp.choices[0].message.content)这里关键的两个参数是 model 和 temperature。model 常见选择是deepseek-chat普通对话响应快和deepseek-reasoner带思考过程适合复杂推理具体可用模型名以官网当前文档为准。temperature 控制随机性0.10.3 适合预测任务取值太高会出现同一天预测值忽高忽低短期销量预测我一般固定 0.2 上下。response_format是让模型强制输出 JSON 的开关。没有它模型经常在数字后面附带“这个预测是基于……”之类的解释解析会很痛苦。对数据任务这个参数基本属于必开。提示如果某些模型不支持response_format退而求其次是在提示词里写死“只输出 JSON不要输出解释”并在解析层做容错重试。如果门店数据不能出内网也可以把这套 prompt 放到本地部署的 DeepSeek 服务上base_url换成内网地址即可业务代码不用改。3.2 提示词模板把历史特征当成上下文让模型做预测比让模型写诗简单得多前提是把问题描述清楚。我会固定一个四段式模板每次都复用同一套角色与任务、特征说明、历史序列、输出要求。def build_prompt(row, forecast_days7): return f 你是中小连锁超市的需求预测助手。根据下面给出的 28 天日销售数据 预测该门店该 SKU 未来 {forecast_days} 天每天的销量。 历史四周数据星期、是否促销、是否节假日、销量 {row[history]} 输出要求 预测未来 {forecast_days} 天的每日销量格式为 JSON。 字段名依次为 date, forecast, confidence_low, confidence_high。 不要输出其他文字。 提示词里注意几点。历史序列只保留四周与相关标签太长模型容易被噪音干扰不要混入“每周总销量”“环比增长”这类由模型去理解的字段。confidence_low 和 confidence_high 是让模型在拿不准时用区间表达不确定性后面算安全库存会用到。3.3 拿到响应后的校验先做类型检查再进预测表接口返回的结构是resp.choices[0].message.content但模型即使开了 JSON 模式也可能返回空字符串或字段缺失。需要包一层解析和校验函数import json def parse_forecast(content: str) - dict: payload json.loads(content) assert forecast in payload, missing forecast assert isinstance(payload[forecast], list), forecast must be list assert len(payload[forecast]) 7, expected 7 days return payload这段代码的核心是“宁可这轮失败重试也不要让脏数据流进库存系统”。模型输出的小数保留两位如果某个 SKU 预测出负数直接截断成 0而不是报错因为补货环节天然不接受负需求。temperature 取值适用场景特点0 0.2短期销量预测、库存补货确定性高多次运行结果接近0.3 0.7生成多版本预测做集成结果有波动需要多次采样取均值0.8 以上头脑风暴、探索性分析一般不用于生产预测4. 用 MAPE / WAPE 评估 DeepSeek 预测先分快慢品再调 prompt4.1 预测结果要与真实值对齐DeepSeek 每轮预测的是“未来 7 天”但到第 8 天真实销售数据已经出来了。上线时最好把每次模型预测落一张表字段包含 store_id、sku_id、date、pred_qty、pred_low、pred_high、model_version、created_at等真实数据出来后再合并pred pd.read_csv(deepseek_forecast.csv) actual pd.read_csv(sales_fact.csv, usecols[store_id, sku_id, date, qty]) merged pred.merge( actual, on[store_id, sku_id, date], suffixes(_pred, _act) ) merged[abs_err] (merged[qty_act] - merged[qty_pred]).abs()merge 的结果就是后面计算指标的唯一依据。这里不需要复杂的时序对齐逻辑只要保证两张表的日期格式一致并且 actual 只取当天已落库的真实销量。4.2 指标口径不要只看 MAPE也要看 WAPE 和 BIAS指标计算方式说明MAPEmean(abs_err / qty_act) × 100%容易被日销 0/1 件的慢动品带偏WAPEsum(abs_err) / sum(qty_act) × 100%按销量加权整体偏差看得准BIASsum(qty_act - qty_pred) / sum(qty_act) × 100%正值代表系统性低估负值代表高估total_act merged[qty_act].sum() wape merged[abs_err].sum() / total_act * 100 bias (merged[qty_act] - merged[qty_pred]).sum() / total_act * 100注意这里 qty_act 可能为 0MAPE 会被除零干扰所以慢动品和快动品必须分开评估。日常销量大于 5 件的 SKU 用 WAPE 做口径销量经常只有 1 件的 SKU直接看区间覆盖比看百分比更有意义。4.3 DeepSeek 预测调参的关键few-shot 与上下文修剪第一轮 WAPE 在 30% 以上时不需要急着换模型先检查上下文。两个前提条件第一历史特征是否用了 4 周以上第二提示词里有没有说明预测日是否为促销日。在此基础上可以做 few-shot 调整把过去一周的真实序列放进提示词few_shot 最近7天实际销售 周一 2件周二 1件周三 3件周四 4件 周五 6件促销周六 8件周日 5件。 模型会照着“周五促销销量约等于平时的 1.5 倍”这类规律推断未来。如果预测仍然明显偏差就用 0.5 的 temperature 跑三到五次取中位数压掉随机噪声。中小超市的预测任务请求量不大成本完全在可接受范围内。5. 把预测接进补货建议订货量计算与回测脚本5.1 从日预测换算成建议订货量预测值本身不能直接发给门店要转成“建议订货量”公式如下建议订货量 max(0, ceil((日均预测销量 × (到货天数 下单周期) 安全库存 − 在库 − 在途) / 包装批量) × 包装批量)import math def reorder_qty(pred_qty, lead_time2, review_period1, safety_stock3, on_hand10, on_order0, batch_size6): demand pred_qty * (lead_time review_period) need demand safety_stock - on_hand - on_order if need 0: return 0 return math.ceil(need / batch_size) * batch_size注意 pred_qty 是日平均预测销量不是 7 天总量。lead_time 是从下单到到货的天数review_period 是盘点补货间隔比如每周日补货一次这个值就是 7不是 1。on_order 是已经在途的量不扣掉会重复下单。安全库存可以用 95% 服务水平对应的 z1.65乘以近 28 天日销量的标准差再乘以下单周期加采购提前期总天数的平方根import math safety_stock round(1.65 * std_daily_qty * math.sqrt(lead_time review_period))这个公式比采购员“多备三箱”要稳定得多。5.2 回测脚本看缺货率而不是只看误差预测误差降下来不代表补货结果好。更直接的验证方法是回测用过去 4 周的预测值配上同样的补货参数模拟每天库存变化统计缺货次数。没有完整的库存模拟模型时可以用一个粗略的代理指标——“预测是否覆盖实际”merged[hit] (merged[qty_pred] merged[qty_act]).astype(int) oos_rate 1 - merged[hit].mean()如果 oos_rate 高于 8%说明安全库存设小了低于 2%说明库存积压风险高可以适当下调补货系数。5.3 一个能直接上手的技巧用模型的置信区间调安全库存最后补充一个立刻能落地的小技巧不用统一安全库存而是让 DeepSeek 在输出预测时同时输出 confidence_low 和 confidence_high然后取区间宽度作为安全库存的调整量。预测波动大的 SKU比如生鲜、促销品区间自然宽稳定商品区间窄。这样安全库存会自动向高风险 SKU 倾斜比所有 SKU 用同一个系数更合理。我在实践中把区间宽度乘以 0.3 再叠加到基本安全库存上效果比统一调整参数来得直接。本文还有配套的精品资源点击获取