补货自动化上线 90 天后，我们的缺货率从 12.4% 降到 6.8%，库存周转天数从 96 天压到 78 天。但如果只让我看一个数字来决定要不要继续投入，我选的不是这两个，而是另一个更"反常识"的指标：采购员补货建议的决策方差下降了约 64%。因为缺货率会受大盘、季节、平台流量影响，而决策方差只说明一件事，同一批数据、同一批 SKU，不同人、不同时间点做出来的补货判断，是不是从"各凭经验"变成了"基本一致"。
前者是结果，后者才是自动化真正交付的东西。
这篇复盘不写 ERP 功能清单，也不写"上线即降本 30%"这种话。我把自己团队从人工补货走到规则补货、再到例外管理的完整过程拆开，重点回答三个问题：效果到底该用什么指标衡量，验证怎么做才不被大盘增长骗过去，以及哪些团队现在还不适合做全自动补货。
在动手做验证之前，我先把"什么叫有效"写成了一个可争议、可反驳的定义。如果这一步不做，后面的所有数据都会被解读成"看起来还行"，这也是大多数复盘文章读完没有信息量的根本原因。
我们团队补货相关的人力从每周 42 小时降到 16 小时，降幅看起来不错，但这部分是"副产品"。真正难以替代的价值是：过去 6 个店铺的补货判断分散在 4 个人手里，同一种情况能做出 4 种不同的补货量。上线规则补货后，同一种情况输出的建议差异被压到了 ±8% 以内。
为什么这件事更重要？因为人力可以再招，方差只能靠机制消除。方差大的团队，库存结构会随着人员流动而剧烈波动，这种波动在旺季会被放大成断货和滞销同时发生。
我见过太多复盘把"上线三个月后 GMV 增长"写成系统功劳。问题是，那三个月里你还上了新品、投了广告、参加了平台活动。没有基线期（上线前的稳定观测窗口）和对照期（未纳入自动化的 SKU 或店铺），任何归因都只是故事。
我们的做法是：先取 90 天人工补货的稳定基线，再把 SKU 按销量分层，A 类 SKU 先纳入自动化作为实验组，结构相似的 B 类 SKU 继续人工补货作为对照组。这样至少能把"大盘涨了"和"系统起作用了"分开。
这是最容易被忽略的一条。自动化对"日均销量高、波动小、供应商交期稳定"的 SKU 几乎是无痛的，缺货率下降最明显。但对长尾 SKU，尤其是一周卖两三件、还带季节性的，规则补货反而容易制造风险：安全库存被历史销量撑高，几轮下来呆滞库存就起来了。
所以我们的结论是：不要把自动化理解为"全局覆盖"，它是分层策略。头部 SKU 用规则补货，长尾 SKU 应该用更低的安全库存加更短的复核周期。
我们尝试过把参数全部交给系统，只保留事后审核。结果在第 6 周就出问题了：一个大促前置的备货建议被系统判定为"异常高需求"，自动压回了 40%，导致活动首日断码。这件事之后，我们保留了三个强制人工干预窗口：大促前 30 天、新品上架前 14 天、供应商交期变更时。
我的判断是：自动化系统的成熟度，不看它自动处理了多少比例，而看它的例外识别是否准确、例外处理路径是否顺畅。自动处理 85% 加例外处理 15%，比自动处理 100% 但错误无人发现要健康得多。
我们做过一次内部对比：同样的规则引擎，在"销量口径已经统一、在途库存实时同步"的前提下运行，与在"销量口径各店各算、在途靠 Excel 手工维护"的前提下运行，缺货率表现差了将近一倍。算法没变，数据质量变了。
这让我形成了一个很实用的排序：先解决口径，再解决规则，最后才谈算法优化。绝大多数跨境团队的卡点根本不在算法层。
脱离业务约束谈方法论没有意义。我把团队当时的真实条件列出来，你可以直接对照自己的情况判断这篇复盘对你有多大参考价值。
我们的店铺分布在 Amazon、Shopify 独立站和 TikTok Shop，海外仓一个在美西、一个在德国，国内还有一个中转仓负责集货和质检。在售 SKU 1240 个，其中近 90 天有动销的约 780 个，活跃供应商 46 家。
这个规模有点尴尬：靠纯人工加表格还能勉强撑住，但一旦某个采购员请假，整个补货节奏就会乱。它不属于"人少反而灵活"的区间，也不属于"必须上重型系统"的区间，正好卡在最需要规则化但最容易半途而废的位置。
第一类是数据断点。销量在三套后台，库存在 WMS，在途在货代的表格里，供应商交期在采购员的聊天记录里。做一次全量补货决策，平均要先花 6 到 8 小时对齐数据，而且对齐完的数据当天就可能过时。
第二类是口径断点。同样叫"日均销量"，运营按 7 天算、采购按 30 天算、财务按自然月算。三个口径放一起，安全库存算出来能差 30% 以上。这个问题比缺数据更隐蔽，因为它不影响"有结论"，只影响"结论对不对"。
第三类是执行断点。补货建议做出来了，但要经过运营确认、主管审批、采购下单三个环节，任何一个环节卡住，采购周期就往后拖。我们统计过，从"决定要补"到"实际下单"的平均间隔是 4.7 天。
第四类是反馈断点。补货之后有没有效果，没人系统回顾。缺货了怪采购慢，滞销了怪运营没推，最后没人知道是判断错了还是执行错了。
很多团队的做法是先上工具、再补数据、最后想怎么证明有效。这个顺序会带来一个很尴尬的结果：系统已经在跑了，你却没有"上线前"的干净基线了。
我们的顺序反过来：先用两个月建立基线，明确五个指标的口径和数据来源；再做小范围灰度，只放开 A 类 SKU；最后才扩大范围。多花的这两个月时间，换来的是后面每一个结论都能被验证，而不是只能被相信。
下面这五个误区，我在自己的项目里全部踩过，也在我看过的同行复盘里反复出现。它们的共同点是：看起来都在讲数据，实际上没有一个能被反驳。
最典型的表述是"上线后三个月，动销率提升了 15 个百分点"。这句话的问题在于，它没有告诉你如果没有上系统会怎样。如果那个季度正好是旺季、正好上了新品、正好加了广告预算，那 15 个百分点里有多少属于系统？
我们做归因时用的是减法：把实验组 SKU 的变化，减去对照组 SKU 的同口径变化，剩下的才是系统带来的增量。我们那次的做法是 A 类 480 个 SKU 进实验组，B 类结构相似的 260 个 SKU 做对照，结果系统带来的缺货率改善是 3.9 个百分点，而不是账面上的 5.6 个百分点。
缺货率是最容易被优化的指标，因为只要把安全库存拉高、把补货量放大，缺货率一定会降。问题是钱被压在了库存里，而这个代价往往要两三个季度后才显现。
所以我们强制要求两个指标必须一起看：缺货率下降的同时，库存周转天数不能上升；如果上升了，就必须说明上升的是哪一类 SKU、预计多久能消化。我们第一阶段就出现过缺货率降到 7.1%、但周转天数涨到 103 天的情况，后来发现是长尾 SKU 的安全库存被系统性抬高。
有些团队的效果提升，本质上是采购主管花了三周时间，把每个 SKU 的安全库存参数手动调了一遍。这在短期有效，但它是不可持续的：人员一变动、市场一波动，参数就过期了。
我的判断标准很简单：看系统在没有人工调参的情况下，能不能连续两个月维持效果。如果能，说明规则本身成立；如果不能，说明效果来自人的经验，只是暂时借用了系统的壳。
跨境的在途库存比国内复杂得多：有离岸在途、有清关在途、有平台仓收货中的、还有海外仓之间调拨的。我见过最典型的错误是"可用库存 = 仓库现有库存"，结果系统反复建议补货，因为它在途中的货根本没被算进去。
正确的可用库存口径应该是：本地仓可售 + 在途可预期到货（按交期概率折算）+ 平台仓可售 – 已占用（未发货订单、调拨预留）。这个口径如果不统一，后面的所有补货建议都会系统性偏大。
有一种很隐蔽的失败：为了追求"自动处理率"，团队把例外阈值调得很宽，导致系统吞掉了本该报警的情况。表面上看自动处理率上去了，实际上是告警被静音了。
我们内部把这类现象叫"虚假自动化"。判断方法是看例外数量是否异常低，以及断货原因里"未识别异常"的占比。健康的系统应该有稳定的例外量，例外量突然掉到接近零，通常不是变好了，而是监控失效了。
这一节是我认为整篇复盘最有复用价值的部分。它分成两半：先定义指标口径，再定义系统结构，最后讲怎么把两者接到一起做验证。
我们最终锁定了五个指标，每个都写清楚了计算方式、数据来源和观察窗口。口径写不清楚的指标，一律不进验证体系，因为它一定会被用来"证明有效"。
| 指标 | 计算口径 | 数据来源 | 观察窗口 |
|---|---|---|---|
| 缺货率 | 可售天数低于 7 天或已断货的 SKU 数 ÷ 应有动销 SKU 数 | 库存快照 + 销量 | 周快照，取月度均值 |
| 库存周转天数 | 平均库存金额 ÷ 近 90 天销货成本 × 90 | 库存金额 + 成本 | 滚动 90 天 |
| 呆滞库存占比 | 库龄超 120 天且近 30 天无动销的库存金额 ÷ 总库存金额 | 库龄报表 | 月末快照 |
| 采购下单及时率 | 建议触发后 48 小时内完成下单的采购单数 ÷ 触发总数 | 采购单 + 建议日志 | 按周统计 |
| 补货人工耗时 | 数据整理 + 会议对齐 + 下单核对的工时合计 | 工时记录 | 按周统计 |
这五个指标里，缺货率和采购及时率是执行层指标，周转天数和呆滞占比是资产层指标，人工耗时是效率层指标。三类指标的响应速度完全不同：执行层数周内就能看到变化，资产层通常要一到两个季度，效率层看流程改造是否真正落地。把这三类指标混在一个时间轴上判断效果，是最常见的误判来源。
数据层解决"用什么数"。至少要包含：SKU 主数据与平台映射、历史销量（区分自然销量和促销销量）、库存快照、在途数量与预计到货日、供应商交期与交期波动、MOQ 与包装倍数、以及促销日历。
规则层解决"补多少"。我们用的是组合规则：安全库存保底、再订货点触发、动态目标库存决定补货量、旺季系数做时间段修正。这四者不是并列关系，而是层层修正的关系。
执行层解决"怎么落地"。从补货建议生成、人工复核、审批、下单到到货跟踪，每个环节都要有状态和时间戳，否则你无法区分"判断错了"和"执行慢了"。
例外层解决"什么时候不该自动"。大促、新品、清货、供应商异常、平台仓限制，这五类情况必须能自动识别并转人工。例外层的能力，决定了这套系统能跑多远。
— 动态目标库存与补货建议计算（简化示意，非生产代码）
— 核心思路：安全库存兜底波动，目标库存决定补多少，旺季系数只修正时间段
WITH base AS (
SELECT
sku_id,
warehouse_id,
AVG(daily_sales) AS avg_daily_sales, -- 近 28 天日均销量
STDDEV_SAMP(daily_sales) AS sd_daily_sales, -- 销量波动
MAX(supplier_lead_time_days) AS lead_time_days, -- 采购交期
MAX(lead_time_sd_days) AS lead_time_sd, -- 交期波动
MAX(moq) AS moq
FROM dw_sales_daily
WHERE dt >= DATE_SUB(CURRENT_DATE, 28)
GROUP BY sku_id, warehouse_id
),
calc AS (
SELECT
sku_id,
warehouse_id,— 安全库存：同时考虑需求波动与交期波动（服务水平系数 1.65 ≈ 95%）
65 * SQRT(lead_time_days * POW(sd_daily_sales, 2)
+ POW(avg_daily_sales, 2) * POW(lead_time_sd, 2)) AS safety_stock,
— 提前期需求
avg_daily_sales * lead_time_days AS lead_time_demand,
— 动态目标库存：提前期需求 + 安全库存，再乘旺季系数
(avg_daily_sales * lead_time_days
+ 1.65 * SQRT(lead_time_days * POW(sd_daily_sales, 2)
+ POW(avg_daily_sales, 2) * POW(lead_time_sd, 2)))
season_factor AS target_stock,
moq
FROM base
JOIN dim_season_factor USING (sku_id) — 旺季系数按品类 + 月份维护
)
SELECT
sku_id,
CEIL(GREATEST(target_stock - available_stock - in_transit_qty, 0) / moq) * moq AS suggest_qty
FROM calc
JOIN dw_inventory_snapshot USING (sku_id, warehouse_id)
WHERE target_stock - available_stock - in_transit_qty > 0;这段逻辑里最值得说的不是公式，而是三个刻意的设计：一是安全库存同时考虑交期波动，而不是只管销量波动；二是补货量基于目标库存差额，而不是固定批量；三是最终数量必须向上取整到 MOQ 的整数倍。第三点看起来最土，但它能避免大量"建议补 37 件、实际只能订 100 件"的无效建议。
我们最终采用的是"历史回测 + 灰度分组"的组合方案，两者解决的问题不同。
历史回测解决的是"如果当时用规则算，会算出什么"。用过去 180 天的真实销量和交期数据回放规则引擎，对比人工实际下单量。这一步不需要上线，成本低，能提前发现明显的参数问题。
灰度分组解决的是"上线之后到底有没有用"。把 SKU 按销量分层后，同层内随机分成实验组和对照组，只对实验组启用自动建议，对照组维持人工。这样能在真实大盘环境下做对比。
基线期的长度建议不少于 60 天，最好覆盖一个完整的促销周期。我们一开始只取了 45 天，结果基线期刚好撞上一次平台活动，导致缺货率基线被严重低估，后面的改善幅度看起来特别好看，其实是自己给自己放水。
具体的归因步骤我们固定成四步，每次复盘都按这个顺序走：
第四步特别重要。我们有一次改善幅度特别好，后来发现同期有一家竞品断货，导致我们的自然销量上升，而销量上升恰好让规则补货看起来更准。如果不用文字明确标注这类事件，数据的说服力会被透支。
前提一：实验组和对照组的结构相似。销量层级、交期、客单价、仓储位置至少要大致对齐，否则对比的是两组不同的业务，不是两种不同的补货方式。
前提二：观察窗口覆盖完整周期。执行层指标观察 4 到 6 周即可，资产层指标至少需要一个完整采购周期加上一个销售周期，我们用的是 90 天。
前提三：承认没有量化的部分。任何复盘都会有无法归因的部分，写"未量化"比硬凑一个数字更专业，也更容易让团队内部相信这套验证方法本身。
我们分了三个阶段推进，每个阶段都单独做验证，这样能知道哪些改善来自哪一层能力。以下数据来自我们团队 2024 年 3 月到 10 月的内部经营看板，已做脱敏处理，用区间或近似值呈现。
第一阶段只做最朴素的规则：再订货点加安全库存，规则层不引入旺季系数，例外层只保留"新品"一类。灰度范围是 A 类 480 个 SKU，对照组是 B 类 260 个 SKU。
这一阶段的效果最"干净"，也最能说明规则引擎的基础价值。实验组缺货率从 9.1% 降到 6.2%，对照组同期从 13.8% 降到 12.9%，净改善约 2.0 个百分点。库存周转天数几乎没有变化，因为补货总量基本持平，只是把节奏从"想到才补"变成了"到点就补"。
采购下单及时率改善最明显，从 71% 涨到 84%。这一项几乎全是流程收益：建议自动生成、审批链路从三级压到两级，平均下单间隔从 4.7 天降到 2.1 天。
第二阶段的核心变化是补货量从"固定批量"改成"目标库存差额"，并加入按品类维护的旺季系数。这一步的效果更大，但风险也更大。
实验组缺货率进一步降到 4.9%，但第 5 周我们发现库存周转天数从 94 天涨到了 101 天。排查后确认是长尾 SKU 的问题：这些 SKU 的日均销量只有 1 到 3 件，但销量波动系数很大，导致按公式算出来的安全库存被系统性抬高。
修正动作有两个：一是对日均销量低于 3 件的 SKU，强制使用"最小安全库存 + 缩短复核周期"的策略，而不是套用通用公式；二是给旺季系数设置了 1.35 的上限，避免品类全年系数被单次活动拉高。
第三阶段没有再改算法，主要做两件事：把例外类型从 1 类扩展到 5 类，以及建立参数月度复核机制。
例外类型扩展后，自动通过率从 88% 降到 76%，但因"未识别异常"导致的断货从每周 7 到 9 次降到了 2 到 3 次。这个交换在我看来非常划算：牺牲一部分自动化率，换取异常识别的可靠性。
参数治理方面，我们固定每月做一次参数健康度检查，看三个东西：安全库存超过 60 天销量的 SKU 有多少、旺季系数是否被异常值污染、交期参数是否还符合实际。这个检查每次大约 3 小时，但避免了参数慢慢漂移。
前面反复强调"口径统一优先于算法"，那具体靠什么统一？我们最终的方案是把经营数据的口径层交给专业的数据分析工具，补货执行仍然留在 ERP 和采购流程里。这两件事必须分开，混在一起做，最后一定是两边都不彻底。
我们用的是数跨境（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys），它的定位是跨境经营数据分析平台，不是补货执行系统。我实际用到的主要是四块：
需要说清楚的是：数跨境解决的是"口径和验证"这一层，它不负责生成采购单、也不负责下单执行。我们的分工是，数跨境负责把数据统一、把指标算清楚、把周转和库龄结构暴露出来；规则引擎在 ERP 侧运行，输出补货建议；采购在 ERP 里完成审批和下单。三者边界清晰，才不会互相甩锅。
如果一定要给一个判断：当你的团队还在为"日均销量按 7 天还是 30 天算"争论时，先别急着上补货算法。先花两周把口径统一了，收益比调参数大得多。
我把三个阶段的最终结果整理成一张表。这张表最有价值的部分不是"变好的"，而是"没变"和"变差"的，它们定义了这套方案的边界。
| 指标 | 基线期（人工补货） | 阶段三（规则 + 例外管理） | 对照组同期 | 归因判断 |
|---|---|---|---|---|
| 缺货率（实验组） | 9.1% | 4.3% | 由 13.8% 降至 11.8% | 净改善约 3.9 个百分点，60% 以上可归因系统 |
| 库存周转天数 | 94 天 | 82 天 | 102 天 | 改善确定，但一半来自长尾 SKU 采购收缩 |
| 呆滞库存占比 | 18.6% | 14.1% | 17.9% | 改善缓慢，存量消化需要 2 到 3 个季度 |
| 采购下单及时率 | 71% | 89% | 73% | 几乎全部为流程收益，与算法无关 |
| 补货人工耗时 | 42 小时/周 | 16 小时/周 | 38 小时/周 | 真实节省，但例外处理新增约 4 小时未计入 |
| 新品首单准确率 | 无历史数据 | 仍靠人工判断 | 无历史数据 | 没有改善，系统对新品无效 |
| 大促期缺货率 | 16.2% | 15.4% | 16.8% | 基本没变，大促仍必须人工干预 |
看清楚这张表，你就明白为什么我说"补货自动化不是一个一键开关"。它能把稳定盘子的执行效率提上去，但无法替你判断新品能不能爆、也无法替你预判大促的真实峰值。
第一个反常识：数据延迟比算法精度更重要。我们把算法从"加权移动平均"换成更复杂的模型，缺货率只改善了 0.2 个百分点。但把库存快照的更新频率从每天一次改成每 4 小时一次，缺货率改善了 0.7 个百分点。输入数据的时效性，比模型复杂度更能决定结果。
第二个反常识：供应商交期不稳定时，自动化会放大错误。我们有一家供应商，标称交期 30 天，实际波动在 22 到 48 天之间。规则引擎按 30 天算出来的补货点，在交期顺的时候库存堆积，在交期差的时候直接断货。后来我们把交期标准差作为独立参数引入安全库存公式，这个问题才明显缓解。
第三个反常识：参数不是越精细越好。我们一度给每个 SKU 单独维护安全库存系数，参数表膨胀到 4 个维度、上千个组合。结果是没人能解释某个参数为什么是这个值，出问题也追不到根因。后来收缩成"按销量层级 + 按品类"两个维度，效果没有变差，可维护性大幅提升。
第四个反常识：自动化上线后，补货会议反而变多了。因为原来大家都在闷头算，现在系统给出了统一建议，反而需要开会讨论"系统建议和人的判断不一致时听谁的"。这其实是好事，说明争议从"数据对不对"前移到了"规则合不合理"。
第五个坑：把例外处理当成临时工作。我们最初没有给例外处理分配固定人力，导致例外积压、无人跟进，最后又退化成"所有建议都要人工过一遍"。后来固定每周 4 小时专门处理例外，情况才稳定下来。
下面按团队规模和数据基础分场景给建议。判断标准不是公司大小，而是SKU 数量、动销比例、供应商集中度、仓储复杂度这四个变量。
这个规模用"表格加人工判断"完全跑得动，强行上规则引擎反而增加维护成本。真正该做的是三件事：把销量口径统一（明确用 28 天还是 30 天）、把在途库存变成可查询的数据、把补货决策留痕（谁在什么时候基于什么数据做了什么判断）。
这三件事做完，你会发现很多"缺货问题"其实是"信息不同步问题"。在这个阶段，一套算得清楚的数据看板，价值远高于一套补货算法。
这是我们自己所在的区间，也是投入产出比最高的区间。建议路径是：先做 ABC 分层，A 类 SKU 完全规则化，B 类规则加人工复核，C 类维持人工但设定库存上限。
重点投入在例外层，而不是算法层。把大促、新品、清货、供应商异常、平台仓限制这五类情况识别清楚，比把预测精度提升 2 个百分点有用得多。
SKU 规模一大，最大的问题不是算不过来，而是不同类别的 SKU 适用完全不同的补货逻辑。快消品适合高频小批量，季节性商品适合提前铺货，定制品适合按单采购。用同一套参数覆盖全部 SKU，一定会出现"一部分缺货、一部分积压"。
这个阶段建议把补货策略做成"策略模板"，每个模板对应一类 SKU，参数在模板层维护，SKU 只负责挂载模板。这样参数治理量级会从"上千个 SKU"降到"十几个模板"。
多平台最大的坑是同一个物理商品有多个平台 SKU，库存却是共享的。如果不做映射，每个平台各自算补货，结果一定是重复补货或者互相抢占。
建议把映射关系当作一级主数据来维护，并且明确"库存归属优先级"，比如独立站订单和平台订单同时到达时，库存怎么分配。这个问题不解决，后面所有补货逻辑都是空中楼阁。
平台仓有发货截止时间、有单次入仓上限、有最低库存要求，这些限制如果不写进规则层，系统会给出"理论上正确、实际上无法执行"的建议。我们第一版就吃过这个亏，系统建议补 600 件，但平台仓单次入仓上限是 300 件，剩下的只能压在中转仓。
正确做法是把平台仓的规则参数化：单次入仓上限、入仓提前期、最低留存库存，全部作为约束条件参与补货量计算。
大促期间历史数据基本失效，因为需求曲线和平时完全不同。我们的做法是在大促前 30 天到结束后 14 天，把相关 SKU 强制转为人工复核模式，系统只提供建议不自动执行。
这不是自动化能力不足，而是对自动化边界的清醒认识。大促缺货率从 16.2% 只降到 15.4%，这个结果本身就说明系统在这段时间的贡献有限，硬推自动执行只会放大风险。
验证做完之后，真正的难题才出现：明知道有效，但要投入多少、投在哪里、放弃什么。这一节讲的是决策，不是方法。
我的判断框架是这样：数据口径层适合用专业数据工具，决策逻辑层适合用 ERP 或独立规则引擎，执行交易层必须留在 ERP 或采购系统里。三层混做，通常结果是三层都做不好。
我们的实际组合是：数跨境负责口径统一、指标看板、周转与库龄分析；ERP 负责规则运行和采购执行。这个组合的好处是，任何时候我都能用第三方口径去质疑 ERP 的输出，而不是只能相信它自己的报表。
如果例外识别准确率低于 90%，全自动就是危险的。判断方法很简单：把系统标记为"正常"的补货建议抽样 50 条，看有多少条实际上是异常情况（比如漏了大促、漏了供应商变更）。
我们在这项抽检里的准确率大约是 92%，所以保留了三类强制人工干预。如果准确率掉到 85% 以下，我的建议是立即扩大人工复核范围，而不是继续调参数。宁可慢一点，也不要让错误静默发生。
参数精细化有一个明确的收益拐点。我们从"统一安全库存系数"细化到"按销量层级区分"，缺货率改善了 1.6 个百分点；从"按销量层级"再细化到"按销量层级加品类"，只再改善了 0.4 个百分点，但参数数量翻了 4 倍。
我的经验是：细化到维护成本开始明显上升时，就应该停下来。因为参数越细，越依赖人去理解和维护，抗人员变动能力反而越弱。
预测算法的前提是每个 SKU 有足够的历史数据，且外部变量相对稳定。跨境场景里，这两条经常不成立：新品没数据、旺季数据不可用、平台政策变动频繁。
所以我的选择顺序是：规则引擎打底，对数据充足的头部 SKU 局部引入预测模型，长尾 SKU 用简单规则加短周期复核。把预测模型用在数据不足的 SKU 上，得到的往往是"看起来很聪明但错得很有自信"的结果。
省人是短期可见的收益，资金效率是长期收益。两者在早期可能冲突：为了降低缺货率而抬高安全库存，短期缺货率好看了，但资金占用上升，真正的收益被推迟。
我们的取舍是：前 90 天优先看执行层指标（缺货率、及时率），同时监控资产层指标不恶化；90 天之后再转向资产层指标优化。这个顺序能让团队在早期建立信心，又不至于把成本推到后面。
这篇复盘从头到尾只做了一件事：把"补货自动化有没有用"这个模糊的问题，变成一组可以被证伪的数据。下面是我认为最值得带走的三个判断，以及一份可以立即执行的清单。
第一，补货自动化的真实收益是决策方差收敛，不是人力节省。人力节省是可见的副产品，方差收敛才是它无法被替代的原因。如果你只用一个指标衡量效果，我建议用"同一情况下的补货建议差异度"。
第二，数据口径的价值高于算法精度。我们把库存快照更新频率从每天一次改成每 4 小时一次，缺货率改善 0.7 个百分点；把算法换成更复杂的模型，只改善 0.2 个百分点。这个对比值得贴在每个做补货项目的团队墙上。
第三，自动化有明确的边界，认清边界比扩大覆盖更重要。新品首单、大促峰值、供应商剧烈波动，这三件事系统目前都帮不了你。承认这一点，才能把有限的人力放在真正需要判断的地方。
如果你想在自己团队里试一次验证，不需要先买任何工具，按下面这个顺序走一遍就有结论：
这七步做完，你就有了一个可以自己判断"该不该继续投入"的基础。不需要等系统上线，也不需要等预算批准。
如果你现在的判断是"值得做"，下一步不是马上去选 ERP 模块，而是先把数据层跑通：把多平台多店铺的订单和库存拉到统一结构，把库存周转和库龄结构做成可持续查看的看板。这一步我自己是用数跨境完成的，它解决的是"我能不能看清自己的库存结构"这个问题。
等你能稳定回答"哪些 SKU 在拖周转、哪些 SKU 有断货风险、哪些 SKU 卖得好但不赚钱"这三个问题之后，再去设计规则层，你会发现参数怎么定、例外怎么分，都会变得清晰很多。
最后留一个问题给你：你们现在的补货，最痛的到底是断货还是滞销？这两个问题的解法完全相反，断货要往前推采购节奏，滞销要往后收采购规模。如果你连自己痛在哪都还没分清，那么现在最该做的不是上系统，而是先把基线数据做出来。
我们团队去年上了一套ERP，供应商说补货模块能自动跑，但我看后台就一个「已生成采购建议」，老板问我效果怎么样，我一时答不上来。我不想拿「省了几个人」这种虚的去汇报，但又不知道该抓哪些数。
至少锁定五个指标，并且先定口径再看结果：一是缺货率，按「统计期内有销量但可售库存为0的SKU天数 ÷ 总SKU可售天数」算，分母要固定；二是库存周转天数，用「平均库存成本 ÷ 期间出库成本 × 期间天数」，跨境要把在途库存单独列，不要混进可售库存；
三是补货及时率，「按计划到货日到货的采购单数 ÷ 应到货采购单数」；四是滞销库存占比，一般取90天无销量且仍有库存的SKU金额占比；五是异常处理工时，统计采购员每周手动改建议、催单、核对在途的耗时。五个指标里，缺货率和周转天数是一对互相拉扯的指标，只看一个必然被误导，必须同时看。
汇报时给出基线期、上线后、同期对照三列，而不是只给一个变化百分比。
我们SKU有八百多个，系统每天生成一堆采购建议，我看有些数量明显不对，比如一个平时一天出三单的品让我补两千个。我问实施顾问，他说是参数问题，但没说清到底哪里出的错，我现在基本还是人工一条条改，等于白上了。
不敢下单通常不是系统坏，而是三类参数没校准。第一类是销量口径，检查系统取的是「下单口径」还是「发货口径」，跨境平台常有下单后取消、超时未付，如果没剔除，日均销量会被系统性高估；第二类是交期参数，看填的是供应商承诺交期还是历史实际到货交期，两者常差7到15天，交期填短了就会算出偏高的安全库存；
第三类是MOQ和装箱率，很多系统在建议数量上不做向上取整，导致建议值无法下单。可执行做法是先做一周「影子运行」：系统出建议，人工照常决策，每天记录两者差异最大的前20个SKU，逐个反查是哪个参数导致的。通常一周就能定位出80%的偏差来源。
另外设一个金额阈值，比如单条建议超过某个金额必须人工复核，低于阈值直接放行，用例外管理代替全量复核。
我们上线补货规则那段时间正好赶上旺季，销量本来就涨，老板看到数据好看就说系统有效。但我心里没底，因为去年同期也在涨，而且我们同时换了物流商。我想做一次说得清的归因，但不知道该怎么设计。
最稳的做法是做灰度分组，而不是看整体前后对比。如果SKU量大，按SKU维度随机分成实验组和对照组，实验组走自动建议，对照组保持人工，其他条件尽量不动；如果SKU太少分不出组，就退而用历史回测，拿过去一段时间的历史数据跑一遍规则，看它当时会给出什么建议、结果会怎样。
观察窗口建议至少覆盖一个完整的补货周期，也就是「供应商交期 + 上架时间 + 一个销售周期」，跨境通常要8到12周，只跑两周基本看不出东西。归因上要明确区分三类因素：系统贡献、外部因素（旺季、物流、汇率、平台流量）、以及人为干预。
记录每次人工改单的SKU、改动幅度和原因，这部分数据是后续判断「自动化到底起了多少作用」的关键，没有它，任何效果结论都站不住。
我们是小团队，SKU不到一百个，供应商就三家，交期一直挺稳。看到别人都在讲智能补货、自动补货，我也在犹豫要不要上，怕不上就落后，但又担心系统调参和维护的时间比人工还多。
判断标准不是「有没有上自动化」，而是「补货决策的复杂度和出错成本」。如果SKU数量少、供应商集中且交期稳定、没有多仓多平台调拨、大促节奏可预期，那么人工加一张维护良好的表格往往比系统更快也更准，因为参数维护本身就是成本。
反过来说，出现下面任意一个信号，就值得开始做自动化：SKU超过三五百个、跨两个以上平台或店铺、有海外仓和平台仓同时在途、供应商超过十家且交期波动大、或者补货决策依赖某个人的经验而这个人一走就乱。还有一条容易被忽略：先做半自动。
让系统只负责算建议和数据汇总，下单和例外判断保留人工，等偏差稳定在一个可接受的范围之后，再逐步放开金额小、周转快的那部分SKU。全自动是个结果，不是起点。从跑通规则到敢于放开，跨境的团队通常需要三到六个月。
读者评论
最有价值的其实是归因部分。把5.6个百分点拆成季节、广告、供应商交期和系统增量，用对照组减法得出3.4个点的真实效果，这套做法比绝大多数复盘诚实。不过实验组和对照组毕竟是不同SKU，结构相似不代表需求波动一致，3.4这个数字本身也带误差。
口径统一高于算法这句说到点上了。我们团队也是销量口径三个部门三套算法，安全库存能差三成，上了工具反而把错误放大了。先花两个月建基线听起来慢，但省掉的是后面反复推翻结论的成本，这个顺序值得借鉴。
长尾SKU那条提醒很关键。一周卖两三件的品类，用历史销量算安全库存只会越堆越高，最后变成呆滞。分层策略说得容易，实际难点是怎么划这条线，还有复核周期定多长，文中没展开有点可惜。
关于全自动的反思比较真实。系统把大促备货压回40%导致断码，这种事只有真跑过才会遇到。保留大促前30天、新品前14天的人工窗口是很务实的折中方案，但例外窗口一多，规则的价值会被稀释，平衡点还得看团队规模。
样本是6个店铺、1240个SKU、46家供应商，属于还能靠表格硬撑的区间，结论对更小或更大的团队迁移性有限。缺货率和周转天数的改善，有多少来自采购收缩长尾、多少来自节奏前移，文中也只给了大概。