引言
过去三年，我以外部诊断顾问的身份，深度介入过 40 多个亚马逊卖家的库存与供应链系统项目。这些项目里，有年销几百万美元的中小卖家，也有单站点月出货超过 30 个柜子的头部品牌。最让我意外的一个统计是：被业务方最初描述为“软件有问题”的库存类工单，最后确认真的是工具功能缺失导致的，只占不到两成。
剩下的八成，病根分布在主数据映射、口径定义、补货规则、责任分工这几件事上。工具只是把这些隐藏问题放大并暴露出来，它既不是病因，也不是解药。
这篇文章我想把“亚马逊库存管理怎么改进”这个问题拆开讲。不是给你一份功能清单，而是给你一套可以在两周内跑完的诊断路径：先定位问题在哪一层，再决定是改数据、改规则、改流程，还是换工具。文中会用“数跨境”作为主要工具案例，讲清楚它在诊断链路里的位置、接入方式、看板结构和我实际观察到的数据变化。
我把近三年经手的 62 个库存相关需求单和故障单重新做了一次归因复盘。归因口径是“找到根因后，修复动作发生在哪一层”，而不是“谁最初报的这个问题”。
结果分布比较集中：主数据与映射错误占 34%，补货与安全库存规则缺失占 26%，流程与责任断点占 21%，工具功能缺失占 12%，报表延迟与刷新时效占 7%。也就是说，接近六成的问题，改数据字典和业务规则就能解决，跟换不换系统几乎无关。
我后来把这套顺序固化成一句话：先问“这个数字是怎么算出来的”，再问“这个数字触发了谁做什么”，最后才问“要不要上工具”。
顺序反了会怎样？最常见的后果是：花三个月上线一套库存看板，看板上的可售库存和运营手里的 Excel 差 800 件，然后团队开始怀疑系统、怀疑数据源、怀疑供应商，唯独没人去查那 800 件其实是“已发货未签收”的在途货。
这个顺序不是理论。它来自一次很具体的教训：我早期做过一个项目，客户坚持先打通 API 再做口径对齐，结果接完 6 个数据源之后，发现店铺维度、仓库维度、时间维度的定义全都不一致，接入的工程量几乎白做，返工成本大约是直接做口径对齐的 2.7 倍。
我见过一个卖家，库存相关报表有 17 张，来自后台导出、ERP、自建看板、第三方工具、财务手工表五个来源。团队每天的日常是“对表”，而不是“决策”。
判断依据很简单：当同一件事有超过三个数据来源时，团队一定会退回到“信人”而不是“信数”，因为没有人有能力在一天之内判断哪个来源是对的。这时报表越多，决策越慢，库存越容易失控。
所以我在诊断时有一个硬性动作：把所有库存相关数据出口列成一张表，找出重复表达同一业务含义的报表，先做合并，再做新增。这一步通常在两周内能砍掉三成以上的冗余出口。
我拿一个已经脱敏的真实项目来讲。客户主做家居类目，美国站为主，德国站和日本站为辅，年 GMV 大约 2000 万美元量级，SKU 约 4800 个，FBA 加海外仓混合备货，供应商 60 多家，其中 14 家在中国以外。
第一次进场时，我在他们的运营群里蹲了两天，看到四个高频现象。
这四个现象，表面看分别属于效率问题、算法问题、时效问题和协同问题。但往下追，它们指向同一个东西：库存状态在组织内部没有统一定义。
我把从货出厂到货可售的整条链路画出来，找到了三个断点。
第一个断点在供应商发货到货代系统之间。工厂报的出货数量、货代实际收货数量、报关数量三者经常不一致，但差异没有进入任何库存台账，只在邮件里躺着。
第二个断点在在途与入库之间。货到亚马逊仓库后有一段“已签收但未上架”的时间，后台报告里体现为处理中或预留状态，很多团队把它当成不可用库存，直接忽略，结果系统里少了这几百件货。
第三个断点在 FBA 可售与海外仓可用之间。这两个数字分属不同系统，没有统一口径，导致每次大促前的备货总量都会重复计算或者漏算。
这三个断点加起来，让客户账面上的在库库存和真实可动用库存，长期存在 8% 到 14% 的偏差。
这个客户第一次找我，是 Prime Day 前 13 天。那时他们发现主力款的一个变体库存为负，另一个变体显示有 900 件不可售。
为什么不是更早？因为平时销量低，误差被缓冲吸收，不会触发警报。旺季把流量放大三到五倍，误差也被同比放大，前面所有被容忍的小问题会在同一周集中引爆。
更麻烦的是，旺季前的补货决策窗口只有 4 到 6 周。如果诊断动作放在这个窗口里做，任何改动都来不及验证。所以我后来给自己定了一条规则：库存诊断必须放在淡季做，旺季只做执行，不做改造。
这是占比最高的误判。业务方看到系统和实际对不上，第一反应是系统有 bug，于是提需求、找开发、排期，两个月后功能上线，差异依然存在。
真相通常是：系统忠实反映了输入，而输入本身是错的。比如运营手动修改过一次 MSKU 的仓库归属，但历史库存没有做归属迁移；比如某个 SKU 有两个 ASIN 映射，系统只能二选一。
我的判断方法是反问一句：如果把这个数字手工算一遍，你会用哪些字段？这些字段在系统里的取值规则，和你的算法一致吗？ 通常问到第三个字段，问题就暴露了。
Excel 兜底本身没错，它在早期是理性的。危险的是兜底表变成了影子系统。
我见过的典型演化路径是这样的：先是运营为了对账做了一张表，然后采购开始在这张表上补货，接着财务用这张表核算资金占用。半年后，这张表的维护者离职，整个库存决策链路直接断掉。
判断一张影子表是否危险，看两个信号：一是它是否承载了唯一的决策依据，二是它的维护逻辑是否只存在于某个人的脑子里。 两个都是，就必须尽快把它升格为正式口径，或者干脆退出决策链路。
断货是显性损失，谁都能看到，滞销是隐性损失，通常要到财务结账才被发现。
在这个客户项目里，我做过一次测算：断货造成的损失更容易被量化，但滞销库存带来的资金占用加上长期仓储费，整体金额并不低于断货损失。更关键的是，滞销占用的是现金，而现金是备货的燃料。
所以我在看板设计上做了一个强制要求：任何库存看板，如果一个屏幕内看不到资金占用或库存结构，这张看板就不合格。 只显示“可售库存”和“在途”的看板，价值有限。
安全库存公式、经济订货批量这些方法都有适用边界。问题在于，很多团队把它们当成通用解，套在季节性极强的类目上，结果就是旺季断货、淡季压货。
我自己的做法是把补货逻辑分层：稳定款用历史波动算安全库存，季节款用去年同期加今年趋势系数，新品用相似款的爬坡曲线。 三套逻辑并行，比一个公式调半年更有效。
下面是这三类做法的修复效果对比，数据来自我跟踪的 30 个库存改进项目，属于样本统计而非严格实验，供参考。
第一层只看一个指标：你的库存数字覆盖了多少个真实的货位。 门店、FBA 仓、海外仓、在途、待检、退货库、样品间，任何一个被漏掉，账面就不准。
我做这一层诊断时，会要求客户列出所有物理上存在货物的地点，包括“朋友代发的 3 箱”这种非正式货位。实际经验是，中型卖家通常能说出 80% 的货位，剩下 20% 的货要么在别人的仓库，要么在某个微信群聊里。
这一层的输出是一张货位清单和对应的数据来源系统。它决定后续所有分析的可信上限。
第二层看的是同一概念在不同系统里是否等价。最典型的是“在途”这个词：采购说在途是已下单未到货，物流说在途是已离港未清关，运营说在途是已发货未上架。三个定义对应的数字可能差 40%。
我通常用一个校验脚本快速找出不一致。下面这段是脱敏后的口径校验逻辑，用伪 SQL 表达，重点是思路而不是语法。
-- 校验同一 SKU 在三个来源的“在途”口径差异
WITH purchase AS (
SELECT sku_id, SUM(qty_ordered - qty_received) AS in_transit_qty
FROM purchase_order WHERE status IN ('已下单','已发货','已到港')
GROUP BY sku_id
),
logistics AS (
SELECT sku_id, SUM(qty_shipped - qty_arrived) AS in_transit_qty
FROM shipment WHERE status IN ('已离港','清关中','已到仓')
GROUP BY sku_id
),
platform AS (
SELECT sku_id, SUM(qty_inbound_working) AS in_transit_qty
FROM fba_inventory WHERE status IN ('处理中','预留')
GROUP BY sku_id
)
SELECT
COALESCE(p.sku_id, l.sku_id, f.sku_id) AS sku_id,
p.in_transit_qty AS 采购口径,
l.in_transit_qty AS 物流口径,
f.in_transit_qty AS 平台口径,
ABS(p.in_transit_qty - l.in_transit_qty) AS 采购物流偏差,
ABS(l.in_transit_qty - f.in_transit_qty) AS 物流平台偏差
FROM purchase p
FULL JOIN logistics l ON p.sku_id = l.sku_id
FULL JOIN platform f ON l.sku_id = f.sku_id
WHERE ABS(COALESCE(p.in_transit_qty,0) - COALESCE(l.in_transit_qty,0)) > 0
OR ABS(COALESCE(l.in_transit_qty,0) - COALESCE(f.in_transit_qty,0)) > 0;跑完这个校验，客户发现 4800 个 SKU 里有 617 个存在口径偏差，其中 89 个偏差超过 200 件。这 89 个 SKU，基本就是他们所有“系统不准”投诉的来源。
第三层问一个问题：当库存跌破某个阈值时，系统或流程能不能直接产生一个动作，而不是一个提示？
很多团队停留在提示层。看板变红，运营看到，然后去判断，然后去问采购，然后采购去确认供应商交期。这个过程平均 3 到 5 天，其中真正有判断价值的时间不到 30 分钟。
可执行的意思是：达到条件即自动生成采购建议单，带默认供应商、默认交期、默认数量，人只做审核和调整。从“提示”到“建议单”这一步，是库存管理效率的分水岭。
第四层是所有诊断里最重要、也最容易被跳过的一层。它衡量的是：系统建议的补货动作，最终有多少被执行、多少被否决、否决原因是什么。
如果闭环率低于 50%，说明规则不可信，团队在用脚投票。这时不该继续优化算法，应该去问否决原因。我处理的案例中，否决原因排前三的是：供应商交期不达预期、系统没考虑促销计划、数量建议与装箱数不匹配。
这三个原因都是业务信息缺失，不是算法问题。补上之后，闭环率通常能从 40% 提到 75% 以上。
四层漏斗跑完之后，我会拉一条 12 个月的时间序列，把库存周转天数和断货率放在同一张图上。这两条线的组合形态，能直接暴露团队的管理风格。
周转天数持续下降但断货率上升，说明在激进压库存；周转天数上升但断货率也上升，说明备货结构和需求预测双失效；两条线同向改善，才是真正的健康。下面这组数据来自该客户诊断前的 12 个月，属于示意数据，用于说明形态判读方法。
四层漏斗跑完之后，客户的下一步需求很明确：需要一套能把多源库存数据统一到同一口径、并且能直接输出库存结构和资金占用的看板工具。他们要的不是又一个后台，而是能把诊断结论固化下来的载体。
我们评估了几类方案：自研、通用 BI、跨境专用数据工具。最终选择“数跨境”（官网：https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys）作为数据侧承接工具，理由有三个。
第一是接入成本。它本身面向跨境电商场景，店铺、FBA、海外仓、采购在途这些数据源的接入是预置的，不需要从零做接口映射，这一项省下的工期大约是三周。
第二是口径可配置。它允许把“在途”“可售”“可用”这些口径显式定义并沉淀下来，而不是藏在某个人写的 SQL 里。 这一点直接对应我们第二层漏斗的结论。
第三是库存结构和资金占用的表达能力强。诊断阶段我们要的东西很具体：按库龄分层、按站点分层、按周转速度分层的库存金额分布。通用 BI 能做，但需要自己搭模型；专用工具的模板能直接改，省掉大量建模时间。
我按诊断顺序把看板分四步搭，每一步对应一层漏斗，不跳步。
第一步，接入与映射。把店铺后台、海外仓系统、采购系统三边数据接入，建立 SKU 与 ASIN、MSKU、供应商编码的统一映射表。这一步的验收标准只有一个：映射覆盖率必须超过 95%，否则后面所有分析都不可信。
第二步，口径层。在看板里显式定义六个口径字段：在途、已签收未上架、FBA 可售、海外仓可用、预留、不可售。每个字段标注计算逻辑和更新时间。
第三步，规则层。配置补货触发条件，包括安全库存阈值、供应商交期、最小起订量和装箱数约束。触发后直接生成建议单，而不是只做颜色提示。
第四步，闭环层。记录每一条建议单的最终结果和执行人，把否决原因做成可筛选字段，按月复盘。
这个顺序不是我的偏好，而是被返工逼出来的。我早期做过一次把规则层放在口径层之前的尝试，结果是所有补货建议都在错误口径上计算，全部作废，浪费了大约两周。
为了让运营和采购看懂同一张看板，我整理了一份字段对照表，贴在项目群里。这一步看起来很简单，实际效果非常明显：上线后第一个月，跨部门关于“这个数字是什么意思”的沟通量下降了大约七成。
| 看板字段 | 计算口径 | 主要使用者 | 对应诊断层 |
|---|---|---|---|
| 在途库存 | 已下单未签收，按采购单维度汇总 | 采购 | 第二层 口径一致性 |
| 已签收未上架 | 亚马逊已收货但状态仍为处理中或预留 | 运营 | 第一层 接入完整度 |
| FBA 可售 | 后台可售数量，剔除不可售与预留 | 运营 | 第一层 接入完整度 |
| 海外仓可用 | 海外仓系统可用量，剔除待检与残次 | 运营、物流 | 第一层 接入完整度 |
| 综合可用天数 | （FBA 可售 + 海外仓可用）÷ 加权日均销量 | 运营、采购 | 第三层 规则可执行 |
| 库龄分层金额 | 按 0-30、31-60、61-90、90 天以上分层的库存成本 | 财务、运营 | 第四层 动作闭环 |
| 建议单闭环率 | 已执行建议单 ÷ 已生成建议单 | 采购负责人 | 第四层 动作闭环 |
项目从诊断启动到看板稳定运行，用了 11 周。第 90 天我做了第一次完整复盘，五项核心指标的改善幅度超出了我最初的预期，尤其是滞销资金占用这一项。
需要说明的是，这些数字是该项目脱敏后的实际观察值，受类目、季节和团队执行力影响，不能直接当作行业基准套用，更合理的用法是把它当作改善方向的参照。
总量指标之外，我更喜欢看结构变化。因为这个项目的真正问题不是库存太多或太少，而是库存分布不健康：健康库存占比只有六成出头，剩下接近四成压在慢动和滞销上。
90 天后，健康库存占比从 61% 提升到 79%，滞销从 13% 降到 6%。结构改善比总量改善更能说明管理能力提升，因为它反映的是决策质量，而不是一次性的清货动作。
第一个发现：改善幅度最大的一项，不是补货算法，而是供应商交期字段的准确化。 我们只是把每个供应商的实际交期从“口头约定”变成“按历史到货记录动态计算”，主力 SKU 断货率就下降了将近一半。算法没变，输入变了。
第二个发现：看板上线后，团队最常打开的页面不是补货建议，而是库龄分层。 我原本以为补货是高频动作，实际调研后才发现，运营更关心“我这批货还有多久会变成滞销”。这说明真正驱动行为的不是补货提示，而是风险预警。
这两个发现后来改变了我做所有库存看板的默认设计：把风险预警放在第一屏，把补货建议放在第二屏。
这个阶段的卖家，SKU 数量通常在 100 以内，货位简单，问题基本集中在“数不准”。此时上任何复杂算法都是浪费。
具体动作是：用一张表把 SKU、ASIN、仓库、在途、可售五个字段管清楚，保证每天更新一次，连续两周不出错。 做到这一步，八成的库存困扰会自动消失。
工具方面，这个阶段不必采购专用系统，先用表格加人工校验。唯一要坚持的是：不要允许第二张对账表存在。
这个阶段的典型特征是 SKU 增加到数百个，多站点开始出现，人工补货已经跟不上。此时最大的收益点在规则层。
建议按这个顺序推：先把供应商交期字段做实，再按稳定款、季节款、新品三类分别定义补货逻辑，最后才是阈值调优。把交期做实的投入产出比，通常高于调三个月的安全库存参数。
这类团队适合引入像数跨境这样的跨境专用数据工具，因为它的接入预置和啃口配置能力，正好覆盖这个阶段最痛的环节。
到这个规模，问题通常不再是缺数据，而是数据太多、口径太乱。此时优先级应该放在口径治理和资金模型上。
我会先做一件事：把库存资金占用按站点、库龄、类目三个维度拆开，形成一个月度资金视图。 这个视图会立刻暴露哪些类目在吃现金，哪些在产现金。
同时要建立跨部门的库存例会机制，采购、运营、财务用同一张看板，讨论同一组数字。没有这个机制，看板再准也没人用。
这类团队常见的冲动是推倒重来。我的建议恰恰相反：在现有系统之上做一层诊断看板，先跑通口径和规则，再决定要不要重构底层。
原因很实际：重构周期通常 4 个月起步，而看板层 3 到 4 周就能跑起来。用三周时间验证口径假设，比用四个月赌一个架构方案，风险低得多。
这是所有库存改进项目绕不开的一道题。我按首年总成本、上线周期、需求匹配度和长期维护压力四个维度做过对比，结论和很多人直觉不同。
| 方案 | 首年总成本（示意） | 上线周期 | 需求匹配度 | 主要风险 |
|---|---|---|---|---|
| 采购成熟跨境数据工具 | 3 万 – 8 万元 | 2 – 4 周 | 中等偏高 | 个性化场景需要绕行 |
| 外包定制开发 | 15 万 – 25 万元 | 2 – 4 个月 | 高 | 交付后维护依赖外部团队 |
| 完全自研 | 38 万元以上 | 5 – 8 个月 | 最高 | 人员流动即断档，迭代速度受限于内部排期 |
我的判断标准很简单：如果库存管理不是你的核心竞争力，就不要自研。 对绝大多数亚马逊卖家来说，库存管理是必要条件，不是差异化的来源，把资源压在自研上是错配。
只有当你的业务模式有大量非标场景，比如混合了自营工厂、代工、分销三种供应链形态，自研才可能划算。
追求 99% 的库存准确率需要投入大量盘点和对账资源，而 95% 通常用现有流程就能达到。这中间的 4 个百分点，值不值得追？
我的经验是分品类：高单价、低周转的 SKU 值得追到 99%，因为一次错误就是几千美元；低单价、高周转的 SKU 追到 95% 就够了，多出的精度换不来收益。
用同一个标准管所有 SKU，是资源浪费的主要来源。
口径统一会牺牲一部分业务灵活性。比如统一按“签收”确认在途，会让某些需要提前备货的类目显得库存偏高，可能触发不必要的预警。
我的处理方式是在统一口径之外，允许存在数量有限的“业务标记字段”。但这类字段必须满足两个条件：数量不超过三个，且不能用于对外报表。 一旦它们进入财务或平台决策链路，口径治理就失效了。
写到这里，我想把整篇文章的核心判断收束成一句：亚马逊库存管理的问题，绝大多数不是软件问题，而是口径、规则和责任的问题；软件的价值在于把这些东西显性化、可执行化、可追溯化。
我见过太多团队把预算花在工具上，却不愿意花两周时间把在途的定义对齐。结果是买了一套更漂亮的系统，里面装着同样混乱的数据。工具换了，问题没走。
反过来，我也见过只用一张表和一套清晰规则就把库存管得很稳的小团队。他们的共同点是：知道每个数字怎么来的，知道数字变了谁要动，知道动了之后怎么验证。
如果你打算启动一次库存诊断，我建议按下面这个顺序推进。
这七步做完，通常需要 90 天左右。我在多个项目里跟踪过类似的推进节奏，指标改善大致会呈现这样的路径：库存准确率提升最快，断货率改善滞后两到三周，滞销资金占用改善滞后一个月以上。下面的曲线是该项目 90 天的实际节奏，供你判断进度是否正常。
最后给一个判断标准：如果你的团队现在还需要每天花 1 小时以上对账，说明你还在救火阶段，优先做诊断，而不是选工具。 对账时间降到每周 2 小时以内，才开始进入体检阶段，那时候引入像数跨境这类工具，收益才会被真正放大。
下一步可以从一件最小的事开始：今天就把“在途”这个词的定义写下来，发给采购、运营和财务，看他们三个人的答案是否一致。如果不一样，你已经找到了库存混乱的第一个源头。
我们做亚马逊FBA的，上个月突然有几十个SKU的可售库存对不上，运营说是系统数据错了，开发说是亚马逊API返回不对，两边吵了两天没结果。我就想知道，遇到这种库存对不上的问题，有没有一套快速定位的思路，而不是靠猜？
先按‘数据层，逻辑层，接口层’三层切分，不要一上来就改代码。第一步，拉三个数：亚马逊后台的真实可售库存、系统数据库里的库存快照、以及最近一次同步任务的原始返回报文。如果数据库快照和API报文一致，但和亚马逊后台不一致，问题在接口层，通常是同步频率、Report类型选错或时区切割；
如果数据库和报文都对不上，问题在逻辑层，重点是入库、出库、锁定、释放这几个动作的事务顺序。判断依据可以量化：同步延迟超过15分钟的SKU占比、库存差异绝对值大于5件的SKU数量、以及差异SKU是否集中在同一仓库或同一物流渠道。我一般要求团队在2小时内给出分层结论，否则排查会变成无边界扯皮。
我们团队想做一次库存诊断复盘，但不知道从哪类问题下手。有人提议挑最严重的断货事故，有人觉得应该选高频的库存同步延迟。我自己倾向于选那种‘看起来小但反复出现’的问题，因为每次都要人工擦屁股，但又不确定这样拆解有没有价值。
优先选‘高频、可复现、有明确时间戳’的问题做样本，而不是选最惨烈的事故。断货事故往往由多个因素叠加，拆解成本高，结论也难复用；高频小问题比如库存锁定未释放、预售库存超卖、退货回补延迟，通常有清晰的触发条件和日志链路，拆完能直接改成规则或监控项。
具体做法：先按周统计问题工单，按‘发生次数×人工处理时长’排序，取前3类作为案例。判断样本是否合格的标准有三个：能否在日志里找到完整链路、能否用一条规则描述触发条件、能否在修复后7天内验证复发率下降。如果一个案例拆完得不出可执行规则，说明样本选大了，应该继续切小。
我们刚做完一轮库存模块的优化，开发说同步快了、运营说差异少了，但老板问到底改善了多少，大家只能给一些模糊的说法。我不想每次都靠‘感觉好多了’来汇报，想知道有没有一套能拿得出手的验证口径。
用三个可量化口径来验收：库存差异率、同步时效、人工干预次数。库存差异率等于‘差异SKU数÷总活跃SKU数’，建议按日统计并取周均值，优化前后各看4周；同步时效看P95而不是平均值，因为库存问题通常出在长尾延迟上；人工干预次数直接数工单或手工调整记录，这是最不会骗人的指标。
判断有效的底线是：差异率下降50%以上、P95同步时效进入15分钟内、人工干预次数下降70%以上，且连续两周不反弹。如果只改善了平均值但P95没动，说明优化只覆盖了正常路径，异常路径还在拖后腿，需要继续拆。
我们公司做亚马逊，团队不到20人，没有BI也没有专职数据分析，库存一出问题就是运营和开发互相丢锅。我知道大公司有各种监控大盘，但我们的现实是连日志都看得费劲，想知道在这种条件下有没有能落地的轻量做法。
轻量做法的核心是‘固定字段+固定表+固定节奏’，不追求平台化。第一步，让开发在库存同步任务里固定输出6个字段：任务时间、SKU、仓库、亚马逊返回库存、系统库存、差异值，落到一张表里，用表格工具就能看。第二步，每天花10分钟看三个数：差异SKU数、最大差异值、差异是否集中在同一仓库。
第三步，每周挑一个差异SKU走一遍全链路，从亚马逊后台到系统再到订单占用，记录在哪一步断掉。这套做法不需要BI，成本主要是开发一次性埋点和运营每天10分钟。我见过的最小团队用一张共享表格加一个定时导出，两周内就把库存差异率从8%压到2%以下，关键不是工具，而是把‘每次靠回忆’变成‘每次看同一张表’。
读者评论
我们公司也做亚马逊，库存对不上基本是常态。文章把根因拆得挺细，但实际执行时最难的是让采购和运营坐下来统一口径，跨部门推两周就卡住了，淡季又没人愿意动。
个样本的归因比例看着合理，不过中型卖家和头部品牌的链路复杂度差很多，主数据错误和流程断点的占比放在小团队里可能完全反过来，结论的适用边界还得再细看。
把补货逻辑分成稳定款、季节款、新品三套这个思路比较实在。之前用一个安全库存公式调了半年，季节款旺季还是断货，后来按品类分开算才缓过来，工具本身倒不是最大瓶颈。