亚马逊库存预测：做出能解释、能复盘的 SKU 需求估计

快速结论：先预测需求，再决定补多少货

先确定 SKU、站点、计量单位和预测日期，再把销量与实际可售情况核对，建立可比较周期的基础预测，并单独记录已知活动的调整。保存预测原版，等目标周期结束后，按相同口径检查误差。把结果、假设与未解决的异常交给负责人复核，再进入补货决策。

可以用六个标准检查这套流程：输入可比较、历史包含可售状态、调整有依据、使用未参与建模的数据验证、不确定性可见，以及后续核查有人负责。数字精确到小数点，并不代表预测可靠。团队需要能够解释这个数字依赖什么条件，以及哪些变化会让它失效。

先分清需求、已记录销量和补货数量

明确一件商品指什么，以及预测哪个商品

如果任务是库存规划，应优先预测件数，而不是直接用销售额代替数量。涨价可能提高销售额，却没有增加买家需要的商品件数。明确一件是一个可售包装、一个组件，还是一整箱。一笔六件装商品的销售，在该可售 SKU 的口径下可能是一件；拆成组件采购时，需要另做换算。

站点和 SKU 映射也应保留。把不同尺码混在一起，可能用某个尺码的积压掩盖另一个尺码的缺货。多渠道共用库存时可以做汇总规划，但必须先确保订单不重复计算、渠道归属明确。不要只留下总数而删除底层明细，否则汇总结果很难解释。

没有卖出，不一定代表没人想买

销量取决于买家当时是否能够购买，以及看到的具体报价和商品条件。已确认缺货时的零销量，不能证明需求为零；商品正常可售时的零销量，则可能正是间歇性需求的重要表现。还有第三种情况：数据缺失。它不应被自动归入前两类。

如果连历史字段都没有统一，先按亚马逊业务报告分析指南核对。预测模型无法替代对“订购件数为何换成发货件数”“单站点为何变成多站点”的解释。历史统计口径不一致，会让后面的计算从起点就失去可比性。

用决策时间确定预测范围，但不要把供应变化当成需求变化

今天预测下周，与今天预测未来十二周，回答的不是同一个问题。记录预测生成日期，以及预测所覆盖的起止日期。生产、运输和收货所需时间，帮助确定业务需要提前看多远；供应商晚发货，本身不意味着消费者需求会按比例增加。

补货决策还需要可用库存、已承诺数量、在途到货时间、供应商规则和风险选择。因此，即使未来需求预测为 280 件，也不等于应该采购 280 件。资金投入还要考虑成本与商品贡献，可以另行参考SKU 商品利润分析。不要把销量预测表当成完整的采购审批表。

选择预测公式前，先建立数据来源明细

保留原始导出文件，在副本上建立带日期的工作表。以下是规划数据集应考虑的字段，并不代表 Amazon 某一份报告会同时提供所有内容。从运营记录补充的字段，也要保留提供人和更新时间。

左右滑动表格，查看完整内容。

先核对总数，再解释销售规律

选定一个周期，把工作表总量与所采用的数据源对齐。发现差异时，先排查再拟合模型。导入程序把同一份文件读取两次，就可能制造一个看似真实的销量高峰。日期边界不同，也可能只改变每周分布，而月度总量仍然一致。

除非预测目标明确规定为净件数，否则不要直接从需求历史中扣除所有退货。退回一件商品，并不抹去最初发生过的购买请求。退回商品能否重新作为可用库存，是另一项状态判断。涉及取消或退货调整时，记录处理规则，确保未来验证沿用同一口径。

不要把粗略库存记录当成全天可售证明

日终有库存，不一定说明商品全天都能购买。部分时间可售或状态不确定，应单独标记，而不是自动记为完整一天。如果没有可靠的小时级记录，可以使用更粗的估计并说明限制，不要反推出看似精确的可售小时数。

AWS 的官方预测示例指出，把商品无法销售的时段当作普通零销量处理，可能让预测偏低。这一提醒强调的是数据状态区别，不是要求卖家删除所有零值。真正可售但无人购买的时段应保留，缺失值如何处理则应另行记录。AWS 示例说明

建立别人能够复算的基础预测

从可比较的销售机会开始

一种简单起点，是把一组明确、可比较且正常可售时段中的销量，除以这些时段的长度。只有未来条件具有合理可比性时，才把这个速度延伸到预测周期。保存纳入了哪些日期、排除了哪些日期，而不只是留下平均值。

这是一项参考计算，不是对所有商品都无偏的估计。如果缺货恰好发生在高需求日期，剩下的日期可能无法代表被遮住的需求；如果观察期一直有促销，算出的速度可能高于平时。没有可用的比较时段时，应停止这个公式，不能用零作分母，也不能临时填一个数字继续计算。

同时比较近期表现和合适的历史参照

对相对稳定的商品，近期滚动平均可以作为起点。有重复规律时，还应比较同类星期或对应季节。年度季节性需要相关季节的历史支持，几周记录无法证明一年一度的规律。较短窗口虽然反应快，也更容易把短期干扰误认为长期变化。

不要因为某个窗口最贴合已知结果，就认定它最好。用后续、未参与输入选择的周期验证不同窗口。如果更复杂的方法在所需预测范围内没有优于简单参照，应先排查数据与假设，而不是继续增加模型复杂度。

让人工调整与原始观察分开

实际销量、基础计算和规划人员的调整，应分别保留。比如“下期活动可能带来增量”，应放入调整栏，写出依据与负责人，而不是改写历史销量列，让公式自然算出想要的结果。

复盘时，这种分离非常重要。偏差可能来自基础方法、活动假设，也可能来自供应中断。如果这些因素已经合并成一个被覆盖的数值，就很难知道下一次应该修正哪一步。

完整算例：同样卖了 210 件，为什么会得到不同预测

假设一个虚构 SKU 在 28 个自然日内，正常可售且可比较的 21 天共卖出 210 件，另外 7 天已确认无法购买，销量为零。为了演示，暂时假设这 21 天适合作为参照；真实账户必须先检查这一条件。

比较分母，而不只是盯着总销量

用 210 除以全部 28 天，得到每天 7.5 件；用同样的 210 件除以 21 个可比较销售日，得到每天 10 件。如果未来 28 天都正常可售，其他条件也延续，那么按后一种速度可计算出 280 件。

这两种算法都没有直接测量缺货时本来会有多少人下单。两者的差额不是“已证实损失了 70 件销量”，而是可售条件假设不同带来的结果差异。它也不能证明下个月会继续保持同样的日销量。

左右滑动表格，查看完整内容。

这是情景分析，不是统计置信区间

224、280、336 分别来自每天 8、10、12 件的假设。它们不是经过校准的分位数或置信界限，也不能证明实际需求一定落在这个区间。这里的用途，是检查当速度假设改变时，规划结果会怎样变化。

继续追问每种情景有什么依据。确认会调价或促销，可以成为研究不同速度的理由，但不能自动确定变化幅度。如果没有可信依据支持这些数值，就应标为探索性假设，不能把中间值包装成已经验证过的预测。

下单之前，先写清下一项核查

本例的下一步可以是核查：参照日期与未来周期的星期分布和促销安排是否相似？另一项核查是确认新周期内的预计可售情况。给这些问题安排负责人，并保留当前计算版本。

后续调整预测时，新版与原版都要保存。这样才能区分“获得新信息后合理修订”，与“把旧预测覆盖掉以后，看起来每次都预测准确”。版本记录不是额外装饰，而是验证方法是否有效的基础。

处理季节性和促销，避免重复计算增量

对齐活动条件，不只是月份名称

重复出现的需求变化，需要与相关历史周期比较。活动日期可能移动，同一个月份包含的星期组合也可能不同。除日历之外，还要检查当时的可售情况、价格、商品组合与广告安排。

Amazon 的库存管理指南将销售历史和季节性列为相关规划因素，但这不意味着所有卖家都应该采用同一个库存目标。预测中应说明：认为哪种历史规律会重现，以及相比那段历史，现在发生了哪些变化。Amazon 库存管理指南

将活动情景与平常需求分开

如果近期平均销量已经包含促销，再额外乘一次促销系数，就可能把同一因素算两遍。尽可能建立正常时期的参照，再单独展示活动调整。如果正常时期证据太少，无法分离活动效果，也应直接说明这个限制。

广告预算变化不代表销量必然按相同比例变化。价格、其他报价与买家行为可能同时改变。使用明确假设，而不是承诺多投入多少广告费用就会多卖固定件数。每项调整都应能够回到证据，而不只是回到一个经验百分比。

旧规律不再代表商品时，应重新核查

商品改版、包装数量改变或某个变体停卖，都可能要求重建参照。保留映射历史，没有可解释的换算时，不要直接拼接新旧销量。突然增长也应先排查来源，确认不是数据问题，再考虑它是否代表新的常态。

预测更远的周期时，区分近期已有证据和远期假设。即使未来活动大多未知，一条逐周曲线仍然可以画得非常平滑。不要用曲线细节或更多小数掩盖不确定性，应明确哪部分需要后续更新。

新品与低频出单商品，需要不同的预测思路

新 SKU 没有历史，就把类比依据写出来

为没有销量记录的商品寻找参照时，应说明为什么选这些产品，以及价格、包装、定位和上新支持有什么不同。已有评价、稳定可售的成熟商品，不一定适合直接代表一个刚上架的新链接。

可以用类比形成小范围测试的假设，随后随着实际数据积累逐步替换。如果问题仍是“这个市场有没有需求”，先参考亚马逊商品需求分析。类目兴趣与竞品销量估计，不是新品未来销售件数的实测值。

低频商品的真实零销量不能删除

间歇性出单的商品，可能正常在售数天才出现下一笔订单。删掉这些零值会抬高平均速度。既要看多久出一次单，也要看每次订单数量；可以研究按周汇总是否更便于识别规律，但不能因此丢掉实际决策需要的时间信息。

不要把稀疏记录强行解释为稳定的每日需求。可能需要更适合间歇性需求的方法，但仍然应与简单参照公平比较。证据不足以支持有效估计时，清楚标明不确定性的情景，比一个假装精确的模型结果更有用。

区分暂时中断与商品生命周期结束

库存耗尽、链接异常和主动停产，含义不同。尽可能记录每次中断的原因。不能仅因为程序自动补齐了日期，就假设已经停卖的商品仍会保持原有需求。

商品边界、可售状态或数据质量尚未解决时，应暂停相关自动建议。系统仍然可以输出一项有价值的调查任务，但不应把它变成可以执行的采购指令。先确认问题是什么，再决定是否扩大预测范围。

用提前保存的预测，检查后来发生的误差

验证的提前期要与业务决策一致

在目标周期开始前保存预测，等实际结果出现后，按相同计量单位和日期定义比较。提前一周预测表现不错，不能作为提前十二周采购可靠的证明。条件允许时，使用多个历史时间点回测，每次只使用当时已经能够获得的信息。

《Forecasting: Principles and Practice》强调，应使用未参与拟合的数据评价预测，而不是仅看对训练历史的贴合程度；它也说明实际值为零或接近零时，百分比误差可能失真。这对低频 SKU 尤其值得注意。预测误差参考

平均方向偏差为零，不代表每期都准确

下面是另一个独立的虚构示例，四个周期均已结束，并具有正常可售条件。本表将带符号误差定义为“预测减实际”，因此正数表示高估。有些系统采用相反方向，使用时应先写清约定。

左右滑动表格，查看完整内容。

带符号误差相加为零，绝对误差之和却是 60。平均绝对误差 MAE 为 60 除以 4，也就是每期 15 件。这里不是模型完美，而是高估与低估在平均时互相抵消。对于库存决策，即使总预测量等于总观察量，各期偏差发生的时间也可能很重要。

把数字误差与经营结果分开评价

比较方法时，应使用相同周期与统计范围。记录无法正常销售的周期，不要默默删除不利结果。销售受到约束时，应说明实际销量未必反映未受约束的需求；如果另行估计损失需求，把估计序列与实测销量分开保存。

不存在适用于所有 SKU 的一个准确率，让采购可以不经判断直接执行。要看误差大小、方向、预测提前期，以及判断错误的后果。预测本身可能合理，但收货延迟仍导致缺货；反过来，靠大量库存避免缺货，也不能证明预测方法优秀。

按需要选择人工、原生工具、自动化或智能体辅助

人工表格：适合仍然能够逐项复核的范围

从受保护的原始数据页、计算页和带版本的预测记录开始。核对一个 SKU，标记异常，并保存下一期预测。最终结果应当可以由其他人复算，而不是只能依赖制作人的记忆。

这种方法适合数量不大、规律相对清楚的序列。当复制公式、无记录调整和映射变化超出复核能力时，就会变得脆弱。此时可以先自动化重复的数据准备，但不要认为换掉表格就同时修好了全部假设。

原生工具：检查你的账户实际提供什么

Amazon 的 FBA 页面介绍了用于库存规划的控制面板和补货工具。可以把账户中可用的建议作为复核输入，保存生成时间和相关设置，而不是假设它能回答所有自定义预测问题。Amazon FBA 工具介绍

报告权限也需要区分。SP-API 文档将 Vendor Forecasting Report 标为面向 Vendors，这不能证明普通 Seller Central 卖家拥有相同预测接口。设计接入前，应核对具体报告及角色要求，不能因接口名字中有 Forecast 就认定一定可用。Amazon 分析报告文档

脚本自动化：先暴露异常，再扩大处理量

经过授权的数据流程可以统一导入、识别重复记录并生成可复算的基准。明确字段结构、时区、映射版本和数据新鲜度要求。出现缺失输入或对账失败时，暂停受影响的输出并留下异常记录，不要把上一版结果冒充本次更新。

选择软件时，看它能否保留原预测、修改依据、数据来源、异常以及所需提前期的验证结果。使用机器学习不等于能够改善你的 SKU 预测。用可比输入和周期，把试用结果与已经保存的简单参照进行比较，再判断增加复杂度是否值得。

智能体辅助：协调复核，不替人做未经授权的决定

可以考虑让智能体参与预测周边的复核工作，例如整理已授权证据、起草解释和转交未解决的问题。预测数值仍应能够追溯到确定的方法。解释写得流畅，不证明输入或模型一定正确。

只有复核人员能够识别过期数据、拒绝无依据调整并找回旧版本之后，才考虑扩大范围。采购、广告或发货修改不应默认包含在试点中，除非相应权限和控制已经另行约定。升级处理的正确结果，有时是要求补充证据，而不是增加订单。

OpenMax 可以如何参与预测复盘

当困难在跨团队交接时，再考虑协作平台

OpenMax将产品定位为人类与智能体协作平台。一个可以讨论的场景，是把库存、营销和运营之间的预测复核组织起来。这个定位并不等于已经提供原生 Amazon 需求模型，或已经连接你的卖家账户。

这里提出的工作流是：提供已授权的预测资料，整理假设变动，将异常分配给明确负责人。实施前需要确认数据访问、保留方式、权限和所需接入。保留计算与来源记录供人核对，不要让语言模型自行补出缺失数量。

先用一份可复制的预测复盘记录

可以先把下面结构放进现有文档。它是一份编辑模板，不代表 OpenMax 的产品导入格式。只纳入复核需要的数据；本文的汇总示例并不需要能够识别客户身份的信息。

决策：复核下一期需求预测，不直接下采购单
范围：站点、SKU、包装单位、渠道
生成：日期、时区、预测版本
周期：目标日期与汇总粒度
来源：导出文件、获取时间、负责人
可售：正常可售、无法购买、状态未知的时段
基准：公式、纳入日期、排除项
调整：理由、证据、负责人
情景：假设速度及计算件数
验证：原预测、实际值口径、误差方向
异常：缺少的证据、下一项调查
复核：责任人、截止时间、接受的修改

没有协作问题时，保留简单做法

少量稳定 SKU，可能用经过检查的表格和一次简短复盘会议就足够。不要只是为了让预测流程显得高级而加入 OpenMax，也不应期待智能体确定地还原从未观察到的需求。

如果交接确实需要改善，可以用Amazon 卖家工作流自动化指南界定小范围试点。先复核一份资料，对照底层数据检查解释，解决限制后，再扩大访问范围或任务职责。

常见问题：亚马逊库存预测怎么做

需要多少历史销量才能预测？

没有适用于所有 SKU 和预测范围的固定天数。需要足够的可比较记录建立参照，并留出后续周期验证。年度季节性需要相关季节的历史，短期上新数据无法证明这种规律。记录不足时，明确使用了哪些假设，并随着证据积累更新。

断货日期应该计为零需求吗？

不应该。已确认无法购买，不代表客户没有需求。保留实际销量，标记可售状态，并记录任何修正。也不要删除所有零销量日期，因为商品正常在售却无人购买的零值，本身就是需求规律的一部分。

亚马逊新品没有历史销量怎么预测？

选择有理由的参照商品，明确上新假设，并解释产品、价格和销售条件的差异。把结果当作小范围可复核测试的情景，而不是需求实测序列。随着新品自身数据出现，再逐步替换类比假设。

季节性和促销应如何处理？

比较相关活动及销售条件，不要只匹配月份名称。将正常时期的基准与活动调整分开，避免重复添加已经包含在观察速度中的增量。记录为什么认为活动会重现，以及什么变化会使这个假设失效。

一定要使用库存预测软件吗？

不一定。可控数量的 SKU 可以先使用经过复核的表格。数据准备、版本管理和异常处理超出当前流程能力时，软件才更有价值。按所需预测提前期与原有参照比较，不要仅凭 AI 标签选择。

预测销量就是应该补货的数量吗？

不是。需求预测是在特定条件下估计未来件数，补货还要考虑可用库存、已承诺数量、在途时间、供应商规则和经营约束。把这些条件另行核对之后，才能形成采购或发货决定。

预测准确率多少才算好？

要结合 SKU、预测提前期和误差后果判断。将绝对误差与方向偏差同可比较基准一起检查。实际需求接近零时，百分比指标可能误导；汇总误差很小，也可能掩盖单个周期的大偏差。比较工具前先定义评价方法。

多久更新一次库存预测？

更新频率应匹配数据新鲜度与决策节奏，可售状态、促销或商品身份发生重要变化时增加复核。即使频繁修改，也应保留原始版本。数字更新得快，不能替代对假设是否仍成立的检查。

下一步：保存一个预测，复盘下一个已结束周期

选择一个来源记录清楚的 SKU。明确单位与预测范围，核对可售情况，记录基准，并在目标周期开始前保存预测。安排下一次复核日期，以及负责解释差异的人。

复盘时区分数据问题、假设变化和真正的预测误差。如果流程仍然说不清，先完善记录，再增加 SKU。如果限制来自协作，就带着同一份资料讨论 OpenMax 工作流：哪些证据需要整理，谁必须复核，以及哪些动作继续由人控制？