跨境企业谈 AI，最常见的起点是"能不能把这几个系统打通"。Datawhale 公开的《FDE案例100》里有四个跨境案例，从起点到做法各不相同，但都说明了一件事：打通系统只是开头，真正要问的是打通以后谁用、解决什么问题。
这四个案例分别由各自的团队完成，与 AiPu 无关。下面是我们的整理，原话都标了编号。
先把整条链看清楚，再动手
NO.22 的客户是一个十几人的东南亚服装电商团队，最初只提了一句"把聚合 SaaS 和飞书打通"。团队没有直接写接口，而是开了几轮会，让客户录屏演示每天怎么工作。结果发现库存只是其中一环：物流靠拍照、人工看图填数；补货要把数据扒进 Excel 用自己的公式算，再誊到模板生成 PDF 发给供应商；广告则在另外的平台上一直跑。讲述者最后梳理出来的是一条链：
订单和库存数据 → 物流数据 → 补货决策 → 供应商下单 → 广告投放。（NO.22）
他们的 SKU 也不少：按访谈估算，每季度新增 500 到 800 个，全年大概 2500 到 3000 个。
第一步往往是数据，而且常常卡在接口上
NO.22 做的第一件事是把库存同步到客户熟悉的飞书里。难点不在 AI，而在对方 SaaS 的 API：Key 有失效机制，一个 Key 不能被多个团队同时用。最后他们加了一层开源数据库做中转。讲述者的总结是："API能不能用，和'有API'完全是两回事"（NO.22）。
NO.11 是一家十几个人、年销售额几个亿的外贸礼品公司，难点更基础：资料散在不同电脑上，大量是图片；公司网络由多台路由器、光猫串在一起，时常不稳定。讲述者说第一天几乎是在当网络工程师。老板也不愿意把合同、客户资料交给外部团队，于是他们把开发规范送进客户自己的环境里，数据不离开企业。
补货：保留客户原来的公式
NO.22 里有个细节值得记住：团队没有重新发明补货算法。客户原来按过去三个月销售算补货的逻辑是成立的，问题只是这套逻辑被埋在一条全靠人搬数据的流程里。Agent 照原来的规则算出该补的 SKU，人审核确认后生成订单。讲述者说，以前这一套至少要 2 到 3 个小时。
数据通了之后，客户又提出新需求：库存低了，对应广告能不能自动调低或暂停，避免一边烧广告一边发不出货。这一步是在前面打通之后自然冒出来的。
动销：发货量不是终点
NO.24 的客户是一家澳洲乳企，通过经销商进入中国和越南。总部只看得到发货（Sell In），看不清消费者最后买走了多少（Sell Through）。经销商的数据有 Excel、PDF，甚至图片和手写凭证，口径也不统一。讲述者说，企业以前上过 BI 工具，但数据清洗仍然靠人，"系统只是换了一个地方看Excel"（NO.24）。
他们的做法有两点：一是不推翻总部已有的系统，在上面加一层能力；二是第一版只做中国、只做一条产品线，跑通了才接越南。讲述者提醒，文中数字做过脱敏，市场费用审核里能发现的问题比例，从人工时的不到 10% 到 AI 辅助后约 30%。
装车：算出来还得能执行
NO.6 是黑河中俄跨境货运的装车优化。运费按方算，一辆约 110 方的车，98 方是保本线。团队用算法做三维装箱规划，但发现理论最优的方案工人执行不了，比如要进车厢踩着货物搬。后来改成按截面从里向外装，工人站在车门口操作，结果打印成编号卡和截面图。讲述者说明，项目目前完成的是原型验证，模拟测试稳定达到约 99 方。
这个案例提醒的是：跨境链条上的优化，最后要落到仓库和车门前的人能照着做。
跨境企业可以先盘一下这几件事
- 订单、库存、物流、补货、广告各在哪个系统？哪一步是人在中间搬数据？
- 现有 SaaS 的接口能不能稳定取数？多个团队能不能共用？
- 补货有没有一套大家认可的公式？先保留它，只把搬运和计算交出去。
- 海外渠道的数据口径是否一致？"销售额"指卖给经销商还是卖给消费者？
- 第一版能不能只做一个市场、一条产品线？
- 哪些结果要人确认后才能发给供应商或调整预算？
如果你们的数据也散在好几个地方，可以先做一次诊断，一起看看从哪一段开始打通最划算。