很多人做亚马逊的利润核算，停在“这个月赚了多少钱”这一步；做供应链规划，停在“下个月补多少货”这一步。这两件事在同一家公司里往往由两个人、两套表、两个时间节奏完成，中间隔着一道看不见的墙。2024 年第四季度，我帮一家深圳家居收纳卖家做年末复盘，他们当年 GMV 约 1200 万美元，财务报表显示全年净利率 11.3%，看起来健康，但 12 月账上现金只剩 38 万美元，供应商 1 月的货款要付 210 万人民币，同时还有 3 个柜子在海运途中。
老板问我的第一句话是：“我到底是赚钱还是亏钱？”这不是财务问题，而是利润核算与供应链协同没有衔接好的典型症状。
这篇文章我想把这套衔接方法讲透。核心不是推荐某个工具，而是回答一个具体问题：当利润核算的颗粒度、时间轴和触发规则，与采购、备货、发货的决策节奏对齐之后，一家亚马逊卖家能多赚多少、少占多少现金、少踩多少坑。文中会以我在实际项目中使用过的数跨境为例，说明数据层如何落地，也会给出不同规模卖家的取舍建议。
我把过去几年经手的亚马逊卖家项目做了一次归因，发现利润核算与供应链协同之间真正需要打通的衔接点并不复杂，只有三个。任何一个没打通，都会出现“利润表好看、现金紧绷”或者“销量增长、净利下滑”的背离。三个都打通，决策效率会有量级上的提升。
第一个衔接点是口径。财务口径的采购成本通常是加权平均，供应链口径的采购成本往往是最近一次下单价格，运营口径的成本有时干脆用“估算值”。三个口径放在一起，同一个 SKU 的毛利可以差出 5 到 8 个百分点。
我的判断标准很直接：如果一个 SKU 的利润核算结果，无法直接回答“这批货该不该再补”，那这个口径就是无效口径。有效口径要求采购成本按批次绑定，头程按实际柜型分摊，平台费用按下单时点抓取，而不是月底一次性摊销。
第二个衔接点是时间轴。亚马逊的利润确认和现金回款之间通常有 14 天左右的结算差，而采购付款发生在发货前 30 天甚至更早。这意味着一个 SKU 在利润表上贡献了 4 美元净利润，可能在现金上先净流出 15 美元，90 天后才回流。
只算利润不算时点，就会出现“越增长越缺钱”。我在项目里要求所有利润报表增加一个字段：该笔利润对应的现金回笼日期。这个字段一旦加上，很多“看起来赚钱”的 SKU 会自动暴露。
第三个衔接点是触发规则。绝大多数卖家的补货触发条件是“可售天数低于 X 天”，这是一个纯销量指标。问题在于，可售天数低于 28 天时补货，可能正好撞上这个 SKU 净利润率为负的月份。
我的做法是给每个 SKU 设两条触发线：一条是销量线（可售天数），一条是利润线（贡献毛利额或净利率）。两条线同时满足才进入补货池，只满足销量线的进观察池。补货不是补销量，是补利润。
补货决策伪代码（我实际项目中的简化版）
for sku in active_skus:
days_cover = onhand_qty / avg_daily_sales_28d
net_margin = sku_net_profit_30d / sku_revenue_30d
cash_cycle = procurement_lead_time + shipping_days + settlement_days
if days_cover = margin_floor:
action = "补货"
elif days_cover = safety_days and net_margin < 0:
action = "停止采购 + 清库存"
else:
action = "维持"
这三条衔接线看起来简单，但落地时最难的不是逻辑，而是数据能不能在同一张表上被同一个人看到。下面这张图是我在项目里常用的费用拆解结构，它决定了后面所有判断的基础。
要理解衔接为什么难，得先看清亚马逊卖家的数据环境有多碎。一家中等规模的卖家，日常同时在用的系统通常包括：亚马逊卖家后台、广告后台、第三方 ERP、财务软件、货代对账表、采购合同台账，再加上若干 Excel。这六七个数据源的关键字段各不相同，时间口径也各不相同。
我 2023 年接触过一家铺货型卖家，在售 SKU 约 4200 个，年 GMV 800 万美元左右。他们的利润核算方式是每月导出后台报表，用销售额乘以一个经验毛利率 18%，直接当作毛利。
我们做了一次全量重算，结果是：贡献正毛利的 SKU 只有 2100 个左右，占比五成，另外一半 SKU 的贡献毛利接近零或为负。真正拖累利润的是头程分摊和长期仓储费，这两项在“销售额乘毛利率”的算法里完全看不到。
精品型卖家的问题相反。SKU 只有二三十个，每个都能算清楚利润，但补货节奏是拍脑袋决定的。我见过一个做宠物用品的卖家，2024 年 Q3 因为担心 Q4 断货，把主力款备货量做到了历史销量的 3.2 倍。
结果 Q4 实际销量只增长了 40%，多出来的库存压了 47 万美元现金，次年 3 月开始产生长期仓储费。他们其实算得清单件利润，但没有把“利润对资金占用的敏感度”纳入补货计算。
多站点是最容易失控的场景。美国站用美元、欧洲站用欧元、日本站用日元，各自的 VAT、EPR、包装法费用结构不同，回款周期也不同。一个在德国站看起来净利率 16% 的 SKU，如果把 VAT 递延和 EPR 年费按季度摊进去，净利率可能只有 9%。
更麻烦的是，很多卖家用一个统一的“汇率”把所有站点折算成人民币看总账，这会掩盖掉某个站点实际在亏损的事实。多站点必须分站点做利润核算，合并只用于看总量，不用于做决策。
这些误区我在不同卖家身上反复见到。它们的共同特点是：单独看都不算大错，但叠加起来会让利润核算彻底失去决策价值。
这是最普遍的。采购成本只是冰山露出水面的部分，佣金、FBA 配送费、头程、广告、仓储、退货、汇损这些加起来，通常占售价的 55% 到 70%。只扣采购成本，等于把真实成本结构里最大的一块忽略了。
我的经验值是：在亚马逊美国站，如果你的净利率算出来超过 25%，大概率是漏项了，而不是你特别会做。精品卖家的健康净利率区间通常在 10% 到 18% 之间，铺货型更低。
很多人一旦货发出去，就默认这笔钱是沉没成本，不再纳入决策。但 FBA 库存是实实在在占用资金的资产，而且它还会持续产生费用：月度仓储费、长期仓储费、库存移除费。
我要求客户在利润表里加一行“库存资金占用成本”，按年化 6% 到 8% 的资金成本率乘以平均库存货值。一个周转 120 天的 SKU，光资金成本就吃掉约 2% 到 2.6% 的货值。这一行加上之后，很多“微利但慢周转”的 SKU 会直接变成负贡献。
典型的补货公式是：日均销量乘以（生产周期加海运周期加安全天数），再减去在途和可售库存。这个公式没有错，但它只回答“够不够卖”，不回答“值不值得卖”。
我在项目里会额外输入两个变量：该 SKU 近 30 天净利率，以及该 SKU 的现金转换周期。净利率为负的 SKU，补货量直接归零；现金转换周期超过 120 天的 SKU，补货量按系数打折。
财务结账口径追求的是准确和合规，通常按月、按科目、按法人主体归集。决策口径追求的是快和细，需要按 SKU、按批次、按天。这两个口径服务于不同目的，不能互相替代。
常见的情况是，运营想看某个 SKU 上周的真实利润，去找财务要数，财务说月结还没做完。决策口径必须能实时或按天产出，哪怕精度略低，也比一个月后拿到精确数字有价值。
我见过不少卖家上了 ERP，报表很漂亮，但补货决策依然是老板拍脑袋。原因是系统算出来的建议和业务直觉冲突时，没有人能解释清楚差异从哪来，最后系统被弃用。
所以衔接的最后一公里不是技术，是规则共识：采购、运营、财务三方要事先约定，当系统建议与人工判断不一致时，走什么流程复核。
下面这套六层模型是我在多个项目里迭代出来的，从最底层的单位经济模型，到最上层的复盘闭环。它的价值不在于复杂，而在于每一层都能对应到一个具体决策。
这一层要解决的问题是：卖一件到底赚多少。必须包含售价、佣金、FBA 配送费、头程分摊、采购成本、广告分摊、仓储费、退货成本、汇损、税费。每一项都要标注取数来源和更新频率。
我的要求是：这一层的输出只有一个数字，单件净利润，且必须能按批次追溯。不能按批次追溯的利润，无法用于判断某次采购决策是对是错。
把每个 SKU 的完整链路时间标出来：下单付款日、工厂完工日、离港日、到港清关日、入仓上架日、销售周期、平台结算日。这些节点连起来就是资金占用时间。
我通常用一张时间轴图来表示，横轴是天数，纵轴是累计现金投入。曲线的最低点，就是这个 SKU 的最大资金压力点。
现金转换周期的算法是：采购付款到平台回款的总天数，减去供应商给的账期天数。亚马逊卖家普遍账期很短或者没有账期，所以这个周期通常在 90 到 130 天之间。
这个数字直接决定备货规模的上限。如果你的现金转换周期是 120 天，那么你手上每 100 万美元现金，全年最多只能支撑约 300 万美元的销售规模，否则一定会出现资金断裂。
我会把 SKU 分成四类：高利润高周转、高利润低周转、低利润高周转、低利润低周转。分类标准用毛利率和周转天数两个维度，阈值根据类目调整。
分类之后策略完全不同：高利润高周转的加码，高利润低周转的优化物流方式，低利润高周转的提价或降本，低利润低周转的直接清退。
这一层把前面四层的结果转成动作。每个 SKU 都有明确的补货、停售、清货触发条件，且条件由系统自动监控，触发后推送给责任人。
关键是规则的优先级要清晰：现金流预警的优先级高于利润优化，利润优化的优先级高于销量增长。三条冲突时按这个顺序裁决。
每一批货售完之后，回看当初的利润预测和实际结果差多少，差异来自哪里。是头程涨了，还是广告超了，还是退货率上升了。复盘结果反哺第一层的参数。
我在项目里要求这个复盘按批次做，而不是按季度做。按季度做，问题会被平均掉；按批次做，才能定位到具体是哪一批采购定价出了问题。
这个模型里最值钱的不是算得准，而是找到能压缩的节点。我通常从三个地方下手。
前面讲的是逻辑，这一节讲怎么落地。我在实际项目里会用数跨境作为数据底座，原因很简单：它能把店铺订单数据、平台费用明细、采购单据、库存与在途数据，挂在同一套 SKU 主数据上，官网 https://shukuajing.jiushuyun.com/?utm_source=seo&utm;_plan=est&utm;_unit=gys 上可以看到具体的功能边界和数据接入方式。
以我 2024 年服务的那个家居收纳卖家为例。落地之前，他们的数据状况是这样的：运营手上是后台下载的订单明细，含销售额和部分平台费用；采购手上是供应商对账表，含下单数量、单价、付款进度；财务手上是银行流水加月度费用汇总。
这三套数各自的字段不一样，SKU 编码规则也不一样。运营用 ASIN，采购用工厂型号，财务用中文品名。要对一次账，平均需要 3 个人花 2 天时间。
我做的第一件事不是接数据，而是建一张 SKU 主数据表，把 ASIN、MSKU、工厂型号、中文品名、批次号这几个字段强制绑定。这张表是全套核算的地基，没有它，后面所有口径统一都是空谈。
第二件事是把平台费用明细按 SKU 维度抓下来，而不是按订单抓。亚马逊的结算报表里，很多费用是订单级甚至账户级的，需要按规则分摊到 SKU。分摊规则一旦确定就要固化下来，不能每次核算都换一套。
第三件事是把采购单和在途库存接进来。这一步做完，采购成本、头程、库存数量就能和生产批次绑定，利润可以按批次算了。
这个卖家 2024 年 9 月准备 Q4 备货，最初计划是主力 12 个 SKU 全部按 3 倍历史销量备货，涉及采购金额约 180 万美元。我们用打通后的数据重新算了一遍，发现了三个问题。
第一，有 3 个 SKU 的实时净利率已经降到 4% 以下，原因是 FBA 配送费在 2024 年调整后，这几个 SKU 正好跨到了更高的尺寸分段。第二，有 2 个 SKU 的库存可售天数已经超过 150 天，再补货会直接触发长期仓储费。第三，有 4 个 SKU 的现金转换周期超过 140 天，按现有现金储备，全量备货会导致 12 月付款缺口。
最终的调整方案是：3 个低净利率 SKU 补货量下调 60%，2 个高库存 SKU 暂停补货并启动促销，4 个长周期 SKU 改为分两批发货。采购金额从 180 万美元降到约 124 万美元。
这个项目从 2024 年 10 月执行到 2025 年 2 月，我记录了四个多月的数据变化。需要说明的是，这些数字来自项目内部记录，属于单一卖家样本，不具备行业普适性，但可以作为量级参考。
| 指标 | 上线前（2024 年 9 月） | 上线后（2025 年 2 月） | 变化 |
|---|---|---|---|
| 对账耗时 | 约 16 人时/月 | 约 3 人时/月 | 下降 81% |
| SKU 级利润更新频率 | 月度 | 按天 | 提速约 30 倍 |
| 库存周转天数 | 78 天 | 61 天 | 缩短 17 天 |
| 长期仓储费 | 1.8 万美元/季度 | 0.6 万美元/季度 | 下降 67% |
| 平均资金占用 | 约 340 万美元 | 约 268 万美元 | 下降 21% |
| 旺季断货 SKU 数 | 32 个 | 9 个 | 下降 72% |
这里面我最看重的是库存周转天数从 78 天降到 61 天。因为周转天数的改善同时带来三个好处：资金占用下降、仓储费下降、滞销风险下降。而它并没有以断货率上升为代价，断货 SKU 反而从 32 个降到 9 个。
在积累了一定数据之后，我做了一张散点图，横轴是 SKU 的周转天数，纵轴是毛利率，气泡大小代表销售额。这张图上最值得警惕的区域是右上角和左下角。
右上角是高毛利但慢周转，这类 SKU 单看利润表很漂亮，但资金效率低，通常适合做长尾或限量款。左下角是低毛利但快周转，这类 SKU 贡献现金流的稳定性，但一旦头程涨价就会立刻变成负贡献。
真正健康的是左上角：高毛利加快周转。而右下角低毛利慢周转的 SKU，我的建议是无条件清退，不管它历史销量有多高。
同一套方法，不同卖家落地的顺序完全不同。下面按几种典型情况给建议，你可以直接对号入座。
这个阶段的卖家，SKU 通常不超过 100 个，人员不超过 5 人。上复杂系统反而增加负担。我建议先用一张结构化的表格，把每个 SKU 的售价、佣金、FBA 费、头程、采购、广告、仓储、退货全部列出来。
重点是每周更新一次真实数据，坚持三个月。三个月之后你会对每个 SKU 的真实利润有清晰判断，这时候再考虑是否需要用工具固化。
这个阶段的痛点是人工核算跟不上 SKU 增长。我的建议是引入统一的数据底座，把订单、费用、采购、库存挂到同一套主数据上，同时把补货触发规则写下来并执行。
关键是规则要简单可执行。不要一上来就做十几条规则，先做三条：净利率低于阈值的 SKU 不补货、可售天数超过上限的 SKU 停止补货、现金转换周期超过 130 天的 SKU 分批发货。这三条能拦住大部分错误决策。
这个规模下，利润核算和供应链规划应该由专人或者专门小组负责，而不是运营兼着做。需要建立按天更新的利润看板，以及每周一次的补货评审会。
评审会的输入是三张表：SKU 利润报表、库存健康度报表、现金流预测表。输出是本周的补货清单、清货清单和调价清单。没有输入表格的评审会，很容易变成拍脑袋会。
多站点必须按站点单独做利润核算，每个站点的费率结构、税负、回款周期都要单独建模。合并报表只用于看整体规模，不用于做单个 SKU 的决策。
我通常建议先选一个站点做透，把口径和规则跑通，再复制到其他站点。同时做三个站点，往往三个都做不好。
新品期允许净利率为负，但必须设定明确的止损条件和退出时间点。我一般建议新品的观察期是 90 天或 500 单，先到为准，到期后净利率不达标的直接停售。
成熟期的标准相反，要求净利率稳定且现金转换周期可控。成熟期 SKU 一旦净利率连续两个月下滑超过 5 个百分点，就要启动归因分析。
做亚马逊规划，最难的不是知道该做什么，而是知道该放弃什么。下面三组取舍是我在项目里反复遇到的，每次都需要老板亲自拍板。
想要高周转就要压低库存，压低库存就可能断货，断货会拉低排名进而影响毛利。想要高毛利通常要做差异化，差异化意味着更长的开发周期和更高的备货风险，周转会变慢。
我的建议是：在现金紧张阶段优先保周转，在现金充裕阶段优先保毛利。判断标准很简单，看账上现金能覆盖几个月的采购付款。低于三个月，优先周转。
核算越精细，出数越慢；出数越快，精度越难保证。解决办法是分层：日常补货决策用按天更新的快速口径，允许一定误差；月度复盘和年度预算用精确口径，按批次核对。
两套口径之间的差异要能解释清楚，差异超过 3 个百分点就要查原因。这样既保证了决策速度，也保证了最终准确。
平台原生报表的优势是免费且数据准确，劣势是只有单个平台视角，无法和采购、库存打通。自研的优势是完全贴合自身业务，劣势是维护成本高，业务一变就要改。
采购第三方工具的优势是上线快、功能完整，劣势是部分个性化需求无法满足。我的经验是：年销 500 万美元以下优先用第三方工具，500 万以上再考虑自研或深度定制。
| 方案 | 上线周期 | 年度成本量级 | 适合规模 | 主要风险 |
|---|---|---|---|---|
| 平台原生报表加手工表 | 1 周内 | 低于 1 万元 | 年销 100 万美元以下 | 口径不统一，无法支撑多平台 |
| 第三方跨境数据工具 | 2 至 6 周 | 数万元级 | 年销 100 万至 2000 万美元 | 个性化规则适配有限 |
| ERP 深度定制 | 3 至 6 个月 | 数十万元级 | 年销 2000 万美元以上 | 需求变更导致维护成本上升 |
| 完全自研 | 6 个月以上 | 百万元级 | 年销 5000 万美元以上 | 人才依赖高，迭代风险大 |
把前面所有内容收拢，我想留下三个可能和主流说法不太一样的判断。
很多卖家把利润核算当成财务工作，追求算得准。但我的判断是：一个每天更新、误差 5% 的口径，比一个月更新、误差 1% 的口径有价值得多。因为前者能触发补货、调价、清货动作，后者只能用于事后总结。
真正衡量利润核算体系好坏的指标，不是准确率，而是它每周触发了多少个有效决策。如果一个报表三个月没有带来任何动作调整，这张报表就是无效的。
大部分卖家把精力放在销量预测上，试图算得更准。但亚马逊的需求波动太大，预测精度提升空间有限。我的判断是：把精力从提高预测精度，转向设计更好的响应规则，回报率更高。
响应规则包括：净利率跌破阈值时自动停止采购、库存超过上限时自动进入促销池、现金低于安全线时自动切换分批发货。这些规则不需要预测未来，只需要对当下做出正确反应。
我见过太多按月度做的利润分析和补货复盘，最后都变成了数字游戏。因为月度汇总会把好的批次和坏的批次平均掉，看不出问题在哪。
按批次做，每一批采购从下单到清仓的全过程都可以追溯，采购定价是否合理、头程是否超支、广告是否投过头、退货是否异常，全部一目了然。批次是利润核算和供应链协同最小的公共单位。
如果你读到这里想动手，我建议按下面的节奏推进，不要一次全做。
最后提醒一句：这套方法的效果不取决于工具多先进，而取决于采购、运营、财务三方是否愿意用同一套数字说话。我见过用 Excel 做到极致的团队，也见过上了完整系统但因为口径分歧而弃用的团队。先统一规则，再谈工具，这个顺序不能反。
我做亚马逊两年多，一直觉得财务算利润、运营管补货是两条平行线，财务月底给个毛利数字，运营照样凭感觉备货。结果有一次大促前猛补了一批货，三个月后算下来利润全被仓储费和资金占用吃掉了。我就特别想知道，这两件事到底该从哪一头开始接？
衔接点是SKU级别的单件全成本加可承诺库存，两个口径必须落到同一张主数据表上。具体做法是先建SKU主数据表，把采购价、头程分摊、平台佣金、FBA配送费、仓储费、退货损耗、广告摊销、汇率口径全部折算成单件成本，并且每月固化一个版本，比如每月5号结上月账，用结算报表的实际值反向校准之前填的预估成本。
补货动作不直接看销量，而是按单件毛利减去资金占用成本排序，分批补货。判断依据很简单：如果一个SKU的单件毛利扣掉六十天资金占用成本后是负数，就不该给它加库存，只做清库存。数据口径统一到结算月加SKU加站点，不要混用自然月，因为广告后台和结算后台的时间差通常有七到十四天，两边混着看永远对不上账。
我刚开始只算采购价和FBA配送费，大盘看着每月都赚钱，可现金流一直紧巴巴。后来拆开看才发现头程和退货损耗是大头，长期仓储费更是悄悄吃掉了一整款产品的利润。这些费用到底怎么摊到单品上才算合理？
给一套可以直接抄的分摊规则。头程按体积重或实重分摊到单件，海运加清关加入仓的总费用除以实际到仓数量，抛货一定按体积重算，否则轻小件会被严重低估。长期仓储费不要扔进公共费用池，直接按库存账龄报表归到对应SKU，这样才能看出是哪几款在拖后腿。
退货按退货率乘以单件不可再售损失计提，退货率用近九十天滚动值，别用全历史，因为旺季退货率天然高一到两个百分点。广告建议双口径，一个全店摊销看整体盈亏，一个按投放ASIN归属看单品决策，补货时用后者。
判断依据是规则要固定，每月只允许改一个变量，比如汇率或运费单价，这样才能判断出到底是售价问题还是成本问题。实操上把成本表做成上月实际、本月预估、差异归因三列，差异超过百分之三的SKU才拉出来单独复盘，不然你会陷进无休止的对账里。
SKU一多Excel就开始崩，VLOOKUP跑一次要等半分钟，我还试过自己写脚本，维护成本高得离谱。市面上有ERP、有各种协同平台，也有朋友推荐用某项目管理平台来管流程，我实在不知道该往哪个方向走。
分三个阶段判断，不要一上来就想着自研。第一阶段SKU少于两百、站点少于三个，Excel加固定模板完全够用，重点不是工具而是把字段定义写死，至少包含SKU、站点、结算月、单件成本、可售库存、在途库存、周转天数这七项。
第二阶段出现多币种、多店铺、多人协作，就得上工具，选择标准只看三条：能不能按SKU维度同时存成本和库存、能不能对接平台结算报表、能不能配置触发规则，比如周转天数超过七十五天自动生成清货任务。第三阶段才考虑自研，前提是你已经能把口径写成一份别人照着做也不会错的文档，否则只是把混乱搬进了代码里。
至于某项目管理平台这类工具，把它当作任务和节奏的载体而不是数据仓库，明细数据仍然留在ERP或表格里，平台只承载补货任务、复盘卡片和责任人。判断依据是一个工具既想存明细又想管流程，最后两边都不准。
老板每个月只问一句这个月赚不赚钱，我说不清是补货节奏调对了，还是单纯汇率帮了忙。有时候毛利在涨，但账户里的钱反而更少了，我特别需要一个能自证有效的指标体系。
盯四个核心指标，分周度和月度两个节奏。周度看四件事：在途库存金额、可售天数、断货SKU数量、九十天以上滞销库存占比。月度看四件事：SKU级全成本毛利、库存周转天数、现金周转周期（采购付款天数加库存天数减平台回款天数）、退货与损耗占销售额比例。
判断依据是看组合而不是单点：如果毛利在涨但现金周转周期同步变长，说明利润被库存吃掉了，本质是备货过度；如果断货SKU在下降而滞销占比同时在涨，说明补货规则过于保守或者需求预测偏乐观。
复盘节奏建议周一复盘上周补货执行情况，月初对上月成本差异，差异超过百分之三的SKU写一句话归因，连续三个月回头看这些归因是否重复出现，重复出现的就是流程缺陷，不是运气问题，那种情况要改规则而不是改数字。
读者评论
补货两条线同时满足才补货，逻辑上对，但落地时负毛利SKU直接停采，链接权重掉得很快，后面再推广告成本可能比亏的那点毛利还高。另外可售天数在旺季和淡季的权重完全不同，28天这条线是不是也该按季度动态调？机械套用容易把清库存和保排名搞混。
库存资金占用按年化6%到8%算偏保守了。我们用的供应链金融实际成本接近13%，而且亚马逊回款有预留金，现金缺口往往比利润表提前一两个月出现。加现金回笼日期字段确实有用，但小卖家靠Excel很难做到按天更新，最后还是月底补录。
分站点还原VAT和EPR的方向没错，但把年费按销售额或重量分摊到SKU，跟实际申报口径经常对不上。欧洲站我们试过按包装材料拆分，差异还是有。数据源头不干净，再细的模型也只是看起来精确。小卖家可能连分站点人员都没有，落地成本得再考虑。