跨境电商库存 AI，不是打通两个系统而是让库存影响广告
跨境服装团队的真正瓶颈不是缺一个接口，而是物流、库存、补货和广告彼此割裂；AI 要把数据自动流动起来，并在人关键节点确认。
文章目录
一个十几人的东南亚跨境服装团队，每季度新增约 500–800 个 SKU，全年 SKU 约 2500–3000 个。库存集中在多平台聚合 SaaS，业务管理在飞书，两个系统没有打通。
客户最初提出的是“把 SaaS 和飞书打通”。继续观察后，真正的链路才浮现出来：工厂发货靠拍照和人工识图，库存数据要扒到 Excel 计算补货，再誊到模板发 PDF 给供应商；广告在 Google、TikTok 等平台持续投放，却可能对着库存不足的 SKU 继续烧钱。
这个案例的落地重点不是集成 API，而是让数据自动流动：AI 识别物流照片并回填，Agent 按客户原有公式计算补货，库存下降再反向影响广告。图片识别、补货计算和广告调整都保留人工确认。
落地场景：让库存、补货和广告互相感知#
服装每个颜色、尺码都是独立 SKU，数量多且增长快。原有流程中，数据虽然不断产生，却需要人从系统中搬出、看图、填表、核对和再录入。
真正要解决的是一条跨系统链路：订单和库存数据 → 物流数据 → 补货决策 → 供应商下单 → 广告投放。单点库存工具并不能解决广告继续投放、订单继续进入但库存无法履约的问题。
落地难点：需求模糊，系统也未必真的开放#
“打通系统”不是完整业务需求#
如果直接按接口需求开发，最后可能只交付一个 API，却没有解决物流照片、补货、下单和广告联动。FDE 需要让客户录屏演示真实工作，先理解业务链路。
API 可用不等于能支撑共享场景#
供应商 SaaS 的 API 开放程度有限，Key 会失效，且一个 Key 不能满足多个团队共享数据。工程路径需要在业务目标不变的前提下不断调整。
既有补货公式是资产，不必重新发明#
客户根据近三个月销售和自己的预测逻辑计算颜色、尺码和数量，这套逻辑本身成立。项目要自动化的是扒数据、填表、核对和生成订单，而不是未经验证地替换客户公式。
效果跟踪容易在交付后断掉#
项目交付后客户移除了外部团队权限，营收、广告成本和利润数据没有完整拿到。时间效率变化明确，但后续业务效果归因仍然不足，需要在项目初期定义基线。
如何落地：先打通数据，再沿业务链逐步加能力#
第一步，先让库存进入飞书的熟悉环境#
团队用一周左右、三四轮沟通收集真实场景，决定先把聚合 SaaS 数据同步到飞书。由于原 API 不能满足多团队共享，增加 Supabase 作为中转层，再同步到业务环境。
第二步，让 Agent 识图并回填物流照片#
工厂发货照片进入多维表后，Agent 负责第一轮识别和回填，员工只检查结果。AI 被放在语义理解和视觉识别都能产生价值、且人可以快速确认的节点。
第三步，让 Agent 按原公式计算补货#
实时数据进入流程后，Agent 按客户已有补货规则计算，筛出需要补货的 SKU，给出周期和数量。工作人员从计算员变成审核员，确认后直接生成 PDF 订单发送给供应商。
第四步，让库存成为广告的约束条件#
把库存、订单和广告投放关联起来。当某个 SKU 库存下降到阈值，Agent 判断广告是否继续；库存不足时降低额度或暂停广告，避免一边烧钱一边无法发货。
第五步，只在需要理解和跨流程判断的地方用 Agent#
规则很死的任务可以用脚本或定时任务完成，只有涉及语义理解、跨系统判断和流程协作时才引入 Agent。AI 识别后人工核对，补货计算后人工确认，广告调整也保留业务判断。
落地成果：物流处理从 4–5 小时压缩到 1 小时内#
过去一个人每天处理物流照片和数据需要约 4–5 小时，AI 先识别和回填后，整体时间压缩到 1 小时以内。补货流程过去从多个系统扒数据、填 Excel、计算再整理订单，至少需要 2–3 小时；现在 Agent 计算后，工作人员主要检查和确认即可生成订单。
业务关系也发生变化：从人工搬数据变成数据自动流动，从人工计算变成 AI 计算、人工确认，从库存和广告各自决策变成库存开始影响广告。由于后续营收、广告成本和利润没有完整追踪，这些成果不能进一步写成利润或 ROI 增长。
| 变化前 | 落地后的变化 |
|---|---|
| 物流照片逐张人工看、人工回填 | AI 先识图和回填，人做最后核对 |
| 补货数据在 SaaS、Excel、模板间搬运 | Agent 按原公式计算，确认后生成供应商订单 |
| 库存与广告各自决策 | 库存下降可以触发广告降额或暂停判断 |
| 交付后缺少系统化效果跟踪 | 明确看到需要建立上线前后基线和持续归因 |
这个案例的价值不是“做了一个跨境电商 Agent”，而是把原本被人串联的多个工具接成了业务链。技术可以换，客户的补货逻辑和人工确认边界要保留。
这个案例给 FDE 的四个提醒#
第一，客户说的技术需求常常是业务结果的代称，要继续追问“打通以后谁用、解决什么”。
第二，API、权限和数据结构是现实门槛，企业 AI 的路径经常要在集成层重新设计。
第三，客户原有规则是资产，优先把机械搬运自动化，再考虑是否需要重写规则。
第四，交付、使用、反馈、迭代和效果归因要形成闭环，不能只在项目结束时交一个能跑的系统。
来源与边界#
- 原始资料：Datawhale《FDE案例100.pdf》，案例二十二“从数据割裂到业务联动：FDE推动跨境电商库存与广告协同”，案例访谈正文位于 PDF 第 220–228 页。
- 案例事实：十几人东南亚跨境服装团队；每季度新增约 500–800 个 SKU，全年约 2500–3000 个；物流照片处理从约 4–5 小时压缩到 1 小时以内；补货原流程至少 2–3 小时；方案增加 Supabase 中转层；库存联动广告。
- 结果边界：客户后续营收、广告成本和利润数据没有完整获得，不能据此推导利润提升或广告 ROI。
- 产品化解读：关于“数据自动流动、库存影响广告”和 Human in the loop 的总结，是基于案例事实的产品化分析。