库存预警系统落地：覆盖天数、安全库存与视图脚本

库存预警系统这个词听起来像是大厂才用得上的东西，但我见过的落地效果最好的一套，是一个不到十人的小团队用一张数据库视图加一个定时脚本搭出来的，跑了一年多，把断货率从百分之十几压到百分之三以内，误报也没多到让人关掉通知。它的核心并不神秘：把分散在各个表里的库存、销量、在途、供应商交期捏到一起，算出一个“还能卖几天”的数字，然后在数字掉到某条线以下时，主动告诉该负责的人。这篇文章就把这件事从头拆一遍——库存预警系统到底是什么、它解决的是哪几类问题、阈值背后的数学怎么算、代码怎么写、上线会踩哪些坑。不管你是刚接手供应链数据的产品或运营，还是被派去“做个库存提醒”的后端，或者只是想让仓库别再莫名其妙断货，下面的内容都能直接抄去改。

1. 库存预警系统到底在解决什么问题

1.1 断货和压货，哪个更贵这件事得先想清楚

很多人一上手就想做“库存低于X就报警”，做到一半发现根本没法用，原因不在技术，在于没想清楚预警的目的是什么。库存管理本质上是在两个成本之间找平衡：一边是缺货成本，包括丢失的销售额、客户的信任、渠道排位的下滑；另一边是持有成本，包括占用的资金、仓储费、过期和跌价损失。这两条成本曲线一条向下一条向上，交点附近才是相对合理的库存水平，而预警系统干的事，就是在这个交点被突破之前，提前发出信号。

这就决定了一个关键认知：预警不是“库存少了就喊”，而是“库存撑不到下一批货到之前就喊”。判断的依据不是绝对数量，而是还能撑多久（覆盖天数）和补货要多久（采购提前期）之间的差。一个SKU库存剩五十件，如果日均卖两件，能撑二十五天，很安全；另一个SKU库存剩五百件，日均卖八十件，只能撑六天，而供应商要十五天到货，这就是紧急状况。只看数量做预警的系统，一定会误报连篇，最后被业务方拉进免打扰。

还有一个容易被忽略的点：断货和压货的成本并不对称。对于毛利高、复购强、客户流失代价大的品类，宁可多备一点；对于保质期短、更新换代快、跌价快的品类，宁可少备。所以一套好用的预警系统必须允许不同品类走不同的规则，而不是全公司一把尺子量到底。这个“分类分级”的设计，后面在阈值章节会详细讲。

1.2 一套能跑的系统，其实只有三层

把复杂度剥掉，库存预警系统的结构非常干净，就三层。

第一层是数据层，负责把事实凑齐。至少需要四类数据：当前可用库存（要扣掉已占用、锁定、质检中的部分）、历史销量（用于推算日均消耗速度）、在途与未交订单（已经下了单但还没到的货）、供应商交期（从下单到可用的天数）。缺任何一块，算出来的结论都是错的。实际项目里最耗时间的不是写代码，而是把这四份数据从不同的业务系统里对齐口径——同一个SKU在A系统叫“编码”，在B系统叫“货号”，在C系统干脆用条码，单位还有“件/箱/托”的换算问题。

第二层是规则层，负责把数据变成判断。这里包括日均消耗怎么算、安全库存怎么定、覆盖天数低于多少算哪一档、哪些SKU豁免、节假日怎么修正。规则层是整个系统的灵魂，代码量可能只占三成，但它决定了系统是“有用”还是“烦人”。

第三层是触达层，负责把判断送到人手上。可以是每天早上的汇总消息、可以是即时通讯工具里的群机器人、可以是邮件日报、也可以是看板上的红色标记。触达层最容易做，也最容易被做废——如果一天推两百条预警，等于没推。所以这一层的关键词不是“及时”，而是“分级”和“聚合”。

三层之间是流水线关系，上一层脏了下一层全废。我见过不少项目一上来就折腾大屏和酷炫的告警卡片，结果底层库存数据还在用昨天的快照，预警永远慢半拍。顺序不能反：先把数据对齐，再把规则调准，最后才谈展示。

1.3 什么规模的团队真的需要它

不是所有人都需要一套系统。日订单几十单、SKU不到一百个的团队，一张维护良好的表格加人肉每天扫一眼就够了，上系统反而是浪费。判断标准可以粗略地用两条：一是SKU数量超过五百或日均订单超过三百单，人脑已经记不住每个品的消耗速度；二是参与库存决策的人超过三个，信息开始靠口头传递，而不是靠同一份数据。

一旦跨过这两条线，人工判断的失效会非常明显：采购盯的是交期，运营盯的是活动备货，仓管盯的是库位，三方看到的“库存”根本不是同一个数字。系统最大的价值往往不是“自动算”，而是让所有人看同一份口径一致的数据，把扯皮的时间省下来。这一点在小团队里体现得尤其明显——上系统之前每天要开半小时会核对数字，上系统之后会不开了，因为看板上的数就是唯一的数。

反过来说，如果连基础的库存台账都不准（盘点差异长期超过百分之五），先别做预警系统。预警的前提是数据可信，数据不可信的时候做预警，只会让所有人更快地不信任系统。这种情况下该做的是把入库出库流程和盘点机制先理顺，这一步省不掉。

2. 四条技术路线怎么选

2.1 从表格到自建服务，路线对比

落地的路径大体有四条，成本、灵活度、维护难度差别很大，没有绝对优劣，只有匹配不匹配。

选哪条路，取决于三个变量：SKU数量级、数据是否已经集中在一处、有没有稳定的技术人力。SKU少于三百且数据就在一张表里，别折腾，表格加条件格式足够；SKU上千且数据分散在订单、仓储、采购多个系统，基本只有后两条路可选。

有一点值得提醒：业务系统内置的预警模块，实际使用率往往很低。原因通常是规则固定，比如只能设一个固定下限，无法按品类差异化，也无法考虑在途和交期。买系统的时候销售演示得很好，真用起来发现“我要的不是这个”，这种情况非常普遍。所以选型阶段一定要拿自己最难的三个SKU去试跑，而不是看演示。

2.2 为什么我更推荐“视图 + 定时任务”这条中间路线

对绝大多数中型团队来说，第三条路的性价比最高。理由有四条。

第一，它不引入新的数据副本。预警逻辑直接跑在业务库或数仓上，库存一变，下一次跑批就能反映出来，不需要做同步链路，省掉一大类“数据不一致”的麻烦。第二，规则改起来只改SQL，业务方说“生鲜类要按三天覆盖预警，标品类按十天”，改一下条件就行，不用发版。第三，幂等和去重容易做，加一张预警记录表，用“SKU + 级别 + 日期”做唯一键，重复跑也不会重复推。第四，它足够便宜，一个会写SQL的人两三天能出第一版，不需要前后端配合。

它的短板也要说清楚：没有配置界面，改阈值要改代码或改配置表；并发能力一般，SKU过十万、跑批时间会拉长；复杂规则（比如多级BOM的物料需求推算）用SQL写会很痛苦。但只要你的SKU在五万以内、规则以单层为主，这些短板都还在可接受范围。

至于第四条自建服务，什么时候才真的需要？通常是这几种情况：需要给几十个不同角色配不同的订阅规则；需要支持人工确认、驳回、备注的完整工单流程；需要在预警触发后自动生成采购申请单并走审批。这些需求本质上已经不是“预警”，而是“补货流程”，这时候单独做服务才有意义。我的建议是先用视图路线跑半年，把规则摸清楚、把真实需求收集够，再决定要不要升级成服务，反过来先做服务再摸需求的，十有八九会返工。

2.3 中间路线的具体形态长什么样

把这条路线拆开，其实是四个部件。一个调度器，每天固定时间（或每小时）触发；一段计算逻辑，通常是一条带CTE的SQL，把结果写进预警结果表；一个推送脚本，读结果表、按人聚合、调消息接口；一张预警日志表，记录发了什么、发给了谁、什么时候发的，用于去重和事后复盘。

调度的频率要看业务节奏。日均订单几百单、供应商交期以周计的，每天跑一次足够，凌晨跑，早上人上班就能看到；生鲜、即时零售这类，可能要每小时甚至每十五分钟跑一次。频率提高带来的不是技术难度，而是推送噪音，所以频率和聚合策略要一起设计——跑得越勤，单次推送越应该只发“状态发生变化”的SKU，而不是全量重发。

存储上建议把“预警结果表”和“预警日志表”分开。结果表存当前状态，可以被覆盖更新；日志表只追加不修改，用来回答“这个SKU上周三到底有没有报过警”这类问题。这两张表分开设计之后，排查问题会轻松很多，因为你能清楚区分“系统没算出来”和“算出来了但没发出去”。

3. 预警规则的核心：算准安全库存和覆盖天数

3.1 覆盖天数：最好懂，也最容易算错

覆盖天数是整个系统的中心指标，定义很简单：现有可用库存除以日均消耗速度。但“可用库存”和“日均消耗”这两个词，各自的坑能埋掉半个项目。

先说可用库存。它不等于账面库存。正确口径通常是：在库数量 − 已锁定/已分配 − 质检中不可售 + 已下单未到货的在途（是否计入在途要看预警目的，如果预警是为了触发补货，在途必须计入，否则会重复下单；如果预警是为了提示可售量，则不应计入）。单位要统一，如果销售按“件”、采购按“箱”、一箱十二件，换算系数必须固化在主数据里，不能靠人记。

再说日均消耗。直接取“最近三十天销量除以三十”是最常见也最糟糕的做法。它会带来两个问题：一是新品没有三十天历史，算不出来；二是促销或断货期会把均值拉偏——如果过去三十天里有十天是断货的，那这三十天的“日均”是被压低的，用它算覆盖天数会高估安全性。实践中更稳的做法是只统计有货的天数，或者用加权移动平均：近七天权重零点五、近三十天权重零点三、近九十天权重零点二。加权的好处是对近期变化更敏感，同时不会被单日爆单带跑。

日均消耗 = 0.5 × (近7天销量/7) + 0.3 × (近30天销量/30) + 0.2 × (近90天销量/90)

这个权重不是金科玉律，是可以调的。周转快的快消品可以把近七天权重提到零点七，长周期的工业品反而应该压低近期权重、提高长期权重，因为单笔大单会严重扭曲短期数据。我的经验是先按上面这组默认值跑两周，拿实际断货情况回测，看哪些SKU的预测明显偏低或偏高，再针对性调整，而不是一上来就追求“最优权重”。

还有一个细节：新品冷启动。历史不足的SKU，可以用同类目同价格带的成熟SKU的日均作为初始值，或者用采购首批量的一个比例（比如三成）作为兜底，同时打上“新品”标记，允许更频繁的人工复核。这块如果偷懒不处理，上线第一天就会有一堆新品误报，很打击信心。

3.2 安全库存的两种算法与一个完整算例

安全库存是为了吸收不确定性而额外准备的那部分库存。它的存在理由是两个“不确定”：需求每天都在波动，交期也不总是准时。算法有两类，简单法和统计法。

简单法适合数据积累少、波动不剧烈的品类：

安全库存 = (最大日消耗 − 平均日消耗) × 采购提前期

它直观、好解释，业务方一听就懂。缺点是把波动当成确定值，比较粗。

统计法更严谨，把需求和交期的波动都考虑进去：

安全库存 = Z × √(LT × σd² + d² × σLT²) 再订货点 = d × LT + 安全库存

其中 d 是平均日消耗，LT 是平均采购提前期（天），σd 是日消耗的标准差，σLT 是交期的标准差，Z 是服务水平系数。

举个具体算例。某个SKU日均消耗二十件，日消耗标准差六件，供应商平均提前期七天，交期标准差两天，目标服务水平百分之九十五，对应 Z 等于一点六五。

先算根号里的第一项：LT × σd² = 7 × 36 = 252。 第二项：d² × σLT² = 400 × 4 = 1600。 合计 1852，开方约等于 43.03。 安全库存 = 1.65 × 43.03 ≈ 71 件。 再订货点 = 20 × 7 + 71 = 211 件。

意思是：当可用库存（含在途）跌到两百一十一件时，就该下单了；其中七十一件是用来兜住波动的缓冲。这个数字拿给业务方看，比一句“设个下限吧”有说服力得多，因为它能回答“为什么是七十一而不是五十”。

服务水平系数可以查表：百分之九十对应一点二八，百分之九十五对应一点六五，百分之九十七点五对应一点九六，百分之九十九对应二点三三。服务水平不是越高越好，从九十五提到九十九，安全库存要涨四成，这些钱压在仓库里是有成本的，所以通常按品类分级设定，核心单品给高一些，长尾给低一些。

3.3 分级阈值：黄橙红三档怎么切

有了覆盖天数和提前期，分级就顺理成章。我习惯用三档，对应三种动作：

• 黄色（关注）：覆盖天数 < 提前期 + 安全缓冲天数。含义是“按正常节奏该准备下单了”，动作是采购确认。
• 橙色（催办）：覆盖天数 < 提前期。含义是“现在下单都可能来不及”，动作是催供应商、找替代货源。
• 红色（紧急）：覆盖天数 < 提前期 × 零点五，或可用库存小于等于零。含义是“马上要断”，动作是调拨、空运、限购、下架处理。

这三档的关键在于每一档都绑定一个动作，而不是只标个颜色。没有对应动作的预警，本质上只是噪音。我在设计表结构的时候会强制要求每一档写清楚“谁负责、做什么、多久内反馈”，哪怕只是一句备注，也能让推送接得住。

阈值也不该是全局统一的。可以按ABC分类：A类（贡献八成销售额的两成SKU）用更保守的阈值，宁可多备；C类（长尾）用更激进的阈值，甚至允许一定程度的缺货，因为它占用的资金效率太低。这张分类表最好从销售数据自动算，每季度刷新一次，别让人手工维护。

3.4 动态修正：让阈值跟着业务走

写死的阈值活不过三个月。业务会变：换供应商、上活动、改包装规格、开新仓。所以系统里要有几种修正机制。

季节性修正：用去年同期销量与本期的比值作为系数，乘到日均消耗上。做法是取过去两年的月度销量，算出每个月的季节指数，预警时按当月指数放大或缩小日均。节日属性强的品类收益最大，不做的后果是每年大促前必然一片红色误报。

活动修正：运营上报的活动计划（预计销量、起止日期）应该进系统，在活动期间用活动预测替代历史均值。这一块手工录入的成分多，可以用一张简单的计划表加人工确认，不用追求全自动。

交期修正：供应商的实际到货周期要回流。每次采购单实际到货后，记录实际天数，用最近若干次的平均值替代系统里维护的名义交期。名义交期往往是拍脑袋填的，实际值常常更差，用真实值能显著减少“以为还来得及”的情况。

这几种修正叠加起来，系统才算真正“懂业务”。但要提醒一句：修正逻辑越多，出错的地方也越多，每加一条都要有开关和灰度，别一次性全量上。

4. 动手搭建：建表、写视图、跑调度

4.1 数据模型：六张表撑起全部逻辑

不用设计得很复杂，六张表足够跑起来。

几个设计要点值得单独说。

is_stockout这个字段很关键，标记当天是否处于断货状态。有了它，算日均消耗时可以排除断货日，避免“因为断货所以显得卖得慢，因为卖得慢所以显得库存安全”的荒谬循环。很多系统栽在这上面。

alert_key是去重用的，一般由“日期 + sku_id + 级别”拼成，加唯一索引。定时任务重跑或者补偿执行的时候，insert ignore或on duplicate key update就能保证不重复推送。

first_flag用来标记“这是该SKU首次进入这个级别”，配合推送策略可以实现“只有状态升级才推，状态维持只更新看板”。这一条能把推送量砍掉七成以上。

4.2 预警视图：一条SQL把结论算出来

下面这段SQL是核心，用MySQL 8的写法，PostgreSQL稍微改改也能用。思路是先算日均、再算覆盖天数、再套阈值分级。

WITH sales_stat AS ( SELECT sku_id, SUM(CASE WHEN stat_date >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) THEN qty ELSE 0 END) / 7.0 AS avg_7, SUM(CASE WHEN stat_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) THEN qty ELSE 0 END) / 30.0 AS avg_30, SUM(CASE WHEN stat_date >= DATE_SUB(CURDATE(), INTERVAL 90 DAY) THEN qty ELSE 0 END) / 90.0 AS avg_90 FROM sales_daily WHERE is_stockout = 0 GROUP BY sku_id ), inv AS ( SELECT sku_id, SUM(on_hand - locked + in_transit) AS available_qty FROM inv_snapshot WHERE snap_date = CURDATE() GROUP BY sku_id ), merged AS ( SELECT i.sku_id, i.available_qty, COALESCE(0.5 * s.avg_7 + 0.3 * s.avg_30 + 0.2 * s.avg_90, 0) AS daily_use, COALESCE(l.lt_days, 15) AS lt_days, COALESCE(t.lead_buffer_days, 3) AS buffer_days FROM inv i JOIN sku_master m ON m.sku_id = i.sku_id AND m.status = 1 LEFT JOIN sales_stat s ON s.sku_id = i.sku_id LEFT JOIN supplier_lt l ON l.sku_id = i.sku_id LEFT JOIN alert_threshold t ON t.category = m.category AND t.abc_class = m.abc_class ) SELECT sku_id, available_qty, ROUND(daily_use, 2) AS daily_use, lt_days, CASE WHEN daily_use <= 0 THEN 9999 ELSE ROUND(available_qty / daily_use, 1) END AS cover_days, CASE WHEN available_qty <= 0 THEN 'RED' WHEN daily_use <= 0 THEN 'NONE' WHEN available_qty / daily_use < lt_days * 0.5 THEN 'RED' WHEN available_qty / daily_use < lt_days THEN 'ORANGE' WHEN available_qty / daily_use < lt_days + buffer_days THEN 'YELLOW' ELSE 'NONE' END AS alert_level FROM merged WHERE available_qty IS NOT NULL;

几个写法上的考量。日均用三层加权而不是简单平均，前面解释过原因。daily_use <= 0的情况单独处理成 9999，是为了避免除零，同时把这些“没有销量”的SKU排除在预警之外——它们通常该走滞销清理流程，不属于库存预警范畴。交期缺省值给了十五天，是个保守的兜底，宁可早报也不要漏报。

性能上，如果明细表很大，可以先做日粒度的汇总表，视图只查汇总表。我实际跑过八十万行快照加三千万行销售明细的组合，不建索引的话单次查询要一分多钟，加了(snap_date, sku_id)和(sku_id, stat_date)两个复合索引之后降到三秒以内。索引这一步别省，它是性价比最高的优化。

4.3 调度脚本与推送

计算部分交给SQL，脚本只负责串联：跑SQL写结果表、比对状态变化、调推送接口、记录日志。用Python写一段，逻辑如下。

import datetime as dt import pymysql conn = pymysql.connect(host="localhost", user="app", password="***", database="supply", charset="utf8mb4") def run_batch(): today = dt.date.today().isoformat() with conn.cursor() as cur: # 1. 重算当日预警结果（先删后插，保证幂等） cur.execute("DELETE FROM alert_result WHERE alert_date = %s", (today,)) cur.execute(""" INSERT INTO alert_result (alert_date, sku_id, cover_days, alert_level, owner) SELECT %s, sku_id, cover_days, alert_level, owner FROM v_inventory_alert WHERE alert_level IN ('RED','ORANGE','YELLOW') """, (today,)) conn.commit() # 2. 只取新升级的预警（首次进入该级别） cur.execute(""" SELECT r.alert_level, r.sku_id, r.cover_days, m.owner FROM alert_result r JOIN sku_master m ON m.sku_id = r.sku_id LEFT JOIN alert_log g ON g.alert_key = CONCAT(%s, '-', r.sku_id, '-', r.alert_level) WHERE r.alert_date = %s AND g.log_id IS NULL ORDER BY FIELD(r.alert_level, 'RED','ORANGE','YELLOW') """, (today, today)) rows = cur.fetchall() if not rows: return # 3. 按负责人聚合，一人一条消息 grouped = {} for level, sku, cover, owner in rows: grouped.setdefault(owner or "unassigned", []).append( f"[{level}] {sku} 可售 {cover} 天" ) for owner, items in grouped.items(): text = f"库存预警 {today}（{len(items)} 条）\n" + "\n".join(items[:20]) send_bot(owner, text) # 4. 写日志，供次日去重 with conn.cursor() as cur: cur.executemany(""" INSERT IGNORE INTO alert_log (alert_date, sku_id, level, channel, sent_at, alert_key) VALUES (%s, %s, %s, 'bot', NOW(), %s) """, [(today, lv_sku[1], lv_sku[0], f"{today}-{lv_sku[1]}-{lv_sku[0]}") for lv_sku in [(r[0], r[1]) for r in rows]]) conn.commit()

这段代码里最值得抄的是两个地方。一是先删后插，保证同一天重跑不会产生重复数据；二是日志表做左连接判空，只有没推送过的才推，从机制上根治重复。推送消息里只放前二十条，超出的写“其余N条见看板”，避免消息过长被折叠。

定时触发用系统调度即可，一行足够：

# 每天早上七点半跑一次，日志留在本地便于排查 30 7 * * * cd /opt/alert && /usr/bin/python3 run_alert.py >> logs/alert.log 2>&1

调度上有个经验：永远不要让脚本在业务高峰跑。库存快照如果是凌晨生成的，跑批要在快照生成之后；如果快照时间不稳定，脚本里加一个“检查最新快照日期是否为今天”的前置判断，不满足就退出并记录，比跑出错误结论要好得多。

4.4 推送内容怎么组织才有人看

技术跑通了，最后一公里是“有没有人真的看”。我踩过的最大坑是：第一版把预警明细全量推给采购负责人，一天一百八十条，第三天他就把机器人静音了。后来改了三件事，阅读率才回来。

第一件是按人聚合。每个SKU在主数据里绑定负责人，推送时按人分组，一人一条，标题里写清楚条数和最紧急级别。人对自己名下的东西是有责任感的，看到一个列表会去处理；看到一条公共消息，第一反应是“这不是我管的”。

第二件是只有状态变化才推。红橙黄三档，从黄变橙、从橙变红才推，维持原级别只在看板更新。这一条把日均推送量从一百八十条降到二十条左右，量降下来之后，每条都被认真看了。

第三件是给出建议动作。同样一条橙色预警，“SKU-1024 可售 5.2 天，低于交期 7 天”和“SKU-1024 可售 5.2 天，建议今日下单并联系供应商确认 X 日前到货”，后者被处理的概率高得多。系统不一定能给出最优建议，但至少要给出下一步动作的指向，比如“建议立即下单”“建议走调拨”“建议暂停活动投放”。

还有一个小细节：消息里带一个可以直接点开的看板链接，让人能一键看到明细和趋势。这一步看起来无关紧要，但它决定了对方是“扫一眼就过”还是“点进去处理”。

4.5 上线节奏：先影子跑两周，别急着推

新系统上线最容易犯的错是当天就开推。规则没调过、数据没校验过，推出去的全是误报，用户的第一印象一旦坏了，后面很难挽回。稳妥的做法分三段。

第一段，影子模式跑两周。系统照常计算并写入结果表，但不推送，只做一个内部看板。这两周里，每天花十分钟把系统算出来的红色和橙色列表，跟人工判断对照，记录差异。差异通常集中在几类：新品无历史、大促期间销量异常、在途数据没接进来、单位换算错。把这几类逐个修掉，规则的准确率会提升一大截。

第二段，灰度推送两周。先只推给两三个愿意配合的业务骨干，每人每天几条，收集反馈。这个阶段要重点听两句话：“这条不该报”和“这个为什么没报”。前者优化阈值，后者补数据源。两周下来，规则基本就稳了。

第三段，全量放开。放开的同时把看板同步上线，让不习惯被推送的人也能主动查看。之后进入维护节奏，每月回看一次误报和漏报，每季度根据销售结构变化刷新一次ABC分类和阈值。

这个过程听起来慢，但比“上线—翻车—返工”快得多。我经手的一个项目为了赶节点跳过了影子期，结果第一周误报率超过六成，业务方直接要求下线，后面花了两个月才重新建立信任。教训很值钱。

5. 常见问题与排查实录

5.1 误报：九成来自这五个原因

误报是库存预警系统最常见的抱怨，几乎每个项目都会遇到。按出现频率排，主要有五种。

新品和历史数据缺失。没有销量历史，日均算成零或者算成同类均值，都会偏。处理办法是给新品单独设一条规则，用首批采购量的消耗速度做初始估算，并标记为“待校准”，前三十天允许人工调整。

在途没算进去。已经下单的货还在路上，系统不知道，就会重复报警并诱导重复下单，这是最危险的一类误报，因为它会直接造成超储。检查方法很简单：随机挑一个报了警的SKU，看看它的采购单状态，如果已有在途，说明视图里的在途没关联上。

单位不统一。销售按件、采购按箱、仓库按托，任何一处换算漏了，覆盖天数就会差一个数量级。这类问题在排查时有个特征：错误往往是“整批”的，某个品类全错，其他品类正常，一看就是主数据的换算系数填错了。

退货和换货未回冲。销量表如果只统计正向出库，退货没扣减，日均会被高估，导致过度补货。反过来如果退货直接冲减销量但库存没加回来，又会造成虚假缺货。这两张表的口径必须对齐。

大促和一次性订单。某个SKU突然来了一笔团购，日均被拉高好几倍，系统立刻报红。这种情况要么在销量表里标记“异常单”并在计算时剔除，要么在活动计划里登记预期销量，用计划值覆盖。

排查误报有个通用套路：拿一个具体SKU，把它过去三十天的库存快照、销量明细、采购单、退货单全部拉出来，手工算一遍覆盖天数，跟系统结果比对。差异出现在哪一步，问题就在哪一步。这个方法笨但极快，通常半小时就能定位。

5.2 漏报：多数不是规则问题，是链路断了

漏报比误报更隐蔽，因为没人喊，问题在沉默中累积，等到发现时往往已经断货。排查顺序应该从链路往规则走，而不是反过来。

第一查快照。当天的库存快照有没有生成？生成时间是不是在跑批之后？我遇到过一次，上游系统的快照任务因为磁盘满了失败，预警系统读到的是昨天的数据，一整天都在用过期的库存判断，结果三个爆款断货没报。解决办法是在跑批脚本开头加一个校验：最新快照日期必须等于今天，否则发一条“数据异常”的内部告警并退出，宁可今天不报，也不要报错的。

第二查主数据状态。SKU被停用、类目为空、负责人没填，都会导致它在视图里被过滤掉。这类漏报的典型特征是“某个品从来不报警”，很反常。可以每周跑一次核对：把在售SKU列表和预警覆盖列表做差集，凡是不在预警范围内的在售SKU都要有明确原因。

第三查阈值配置。类目和ABC分类的组合如果在阈值表里没有对应记录，左连接会得到空值，被兜底值覆盖，可能兜底值设得太宽松。建议给所有组合配齐，并且在代码里对“未匹配到阈值”的情况打日志，定期检查日志量。

第四才查规则本身。是不是提前期维护得太短？是不是把交期标准差忽略了导致安全库存偏低？这类问题相对少见，但一旦存在，影响是系统性的。

5.3 推送治理：从刷屏到被认真看

推送这件事，量和质是反比关系。我的经验是把日均推送控制在每个接收人十条以内，超出就说明分级或聚合没做好。

具体手法有三条。分级推送：红色实时推，橙色每天早报推，黄色只进看板不主动推。聚合推送：一人一条，不分SKU发多条。抑制重复：同一SKU同一级别，三天内只推一次，除非级别升级。这三条叠加，量能降一个数量级。

还有一条容易被忽略：推送要有出口。每条预警最终应该有四种归宿——已下单、已调拨、已确认无风险、已豁免。系统里要能记录这个状态，否则同一批预警会天天出现，用户很快就会认为“报了也没用”。哪怕只是在表格里加一列状态，由人手动更新，也比完全没有出口强。

5.4 问题速查表

6. 让这套东西活得久一点

系统上线三个月后，最危险的敌人不是技术债，是没人维护。规则是半年前调的，供应商换了交期没更新，新品类的阈值还是默认值，慢慢地预警又开始不准，用户又开始不看。我见过的活过两年的系统，都有几个共同习惯。

一是每月一次的准确率复盘。把当月所有红色预警拉出来，看有多少是真的断了或者差点断，算一个命中率。命中率低于六成就要查原因。这个动作花不了两小时，但它是系统不腐化的唯一保障。

二是把交期数据的更新挂到采购流程上。不要指望有人专门去维护交期表，最好的方式是采购单实际到货时自动回写实际天数，用滚动平均替代名义值。数据跟着流程走，才不会腐烂。

三是阈值的调整权交给业务方。技术只提供工具，什么品类该备多少天，业务比技术清楚。给一张配置表，让业务方能自己改，改完下一次跑批就生效，比每次提需求排期要高效得多。当然要加审计，记录谁在什么时候改了什么。

最后分享一个我觉得最值钱的小技巧：给预警系统本身加一条预警。监控三件事——最近一次跑批时间、最新快照日期、当日预警条数。如果跑批超过二十六小时没成功，或者快照日期不是今天，或者预警条数突然掉到零（正常业务下不可能零），就发一条内部消息。这三条监控加起来不到二十行代码，但能在系统悄悄失效的时候第一时间发现它。我吃过这个亏，一个跑了半年的系统因为数据库账号密码过期静默失败了三天，谁都不知道，直到仓库打电话来问为什么这周没收到补货提醒。

我自己在实际操作中的体会是，库存预警系统真正的难点从来不是代码，而是“口径”和“习惯”这两件事。口径是把库存、销量、在途、交期这四个数对齐，让所有人看同一份真相；习惯是让业务方形成“看到预警就处理、处理完就标记”的闭环，而不是当成又一个要忽略的通知。技术上，一张视图加一个定时脚本就能起步；难的是把它当成一个需要持续养的产品，而不是一次性的交付物。如果准备动手，我的建议是从二十个最重要的SKU开始，把这一小撮跑准，再逐步扩到全量——小范围跑通带来的信任，比一次性全量铺开有用得多。