从发货到动销：FDE用AI打通跨境快消的海外数据断层

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

跨境快消企业依赖当地经销商完成销售，总部却难以及时掌握终端动销，信息滞后、数据失真和人工审核成本长期存在。项目重新梳理总部、经销商和终端之间的数据链路，用 AI 完成数据抽取、清洗、校验和风险识别，形成机器辅助处理、业务人员最终决策的流程。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

FDE所在的团队长期服务跨境贸易和消费品企业，帮助企业处理海外市场的数据分析和业务数字化问题。

FDE本人是快消行业出身，过去几年一直在亚太做快消咨询，帮品牌方做出口和海外市场运营，因此比较清楚企业在进入海外市场时会遇到哪些真实问题。

这个案例服务的是澳洲一家头部乳企，做奶酪。

他们拓展海外市场时，选择通过经销商模式进入中国和越南市场。

对于很多消费品企业来说，这是非常常见的路径：总部负责品牌、供应链和产品，经销商负责当地销售和渠道运营。

总部在澳洲，在这两个市场里一个零售触点都没有，货发出去，过了国境就断了。

但问题也随之出现。

一开始接触这个项目时，很多人会认为这只是一个数据对接问题：把经销商的Excel接进来，统一格式就行了。

但真正进入现场之后，FDE发现事情远比想象复杂。

对总部来说，发货量只是中间指标，真正重要的是消费者最后购买了多少产品。

在业务里，项目团队通常会区分两个概念：一个是Sell In，也就是品牌方把货卖给经销商；另一个是Sell Through，也就是消费者最终从渠道买走多少。

Sell Through更能反映真实市场需求、营销投入效果和消费者反馈，但在跨境场景下，这类数据往往最难获得。

过去，海外业务的信息流转主要依靠人工：总部把订单、发货信息发送给经销商，经销商再通过Excel、邮件等方式反馈销售情况，中间还涉及语言转换、业务解释和数据整理。

看似只是传递数据，但实际上每一步都会产生损耗。

首先是信息滞后。

总部看到的数据可能已经是几周甚至更久之前的数据。

其次是数据失真。

比如总部问“销售情况怎么样”，不同角色理解可能不同。

有人理解为卖给经销商多少，有人理解为消费者购买多少。

如果业务理解不到位，数据口径从一开始就可能错。

第三是人工成本很高。

过去大量时间花在整理数据、开会解释、沟通确认，真正需要推动的市场业务反而被搁置了。

这个问题的本质，在于业务现场、数据流程和执行方式之间的脱节，远不止技术层面。

作为FDE，FDE的工作就是进入现场把真实问题拆出来，找到AI能力和业务流程的结合点。

二、原有流程与核心问题

在AI介入之前，企业主要依靠人工流程解决。

传统方式在早期阶段是有效的。

经销商规模有限，市场变化不复杂，人工沟通能够支撑业务运行。

通常流程是：总部发货 → 经销商接收产品 → 经销商整理销售数据 → 销售人员制作Excel → 业务人员翻译、整理，再反馈总部。

但随着业务规模扩大，问题逐渐暴露。

首先，数据标准不统一。

不同国家、不同渠道的数据格式完全不同。

有些数据来自Excel，有些来自PDF，有些甚至是图片或者手写凭证。

尤其在销售端，数据非常复杂：字段名称不统一、销售单位不一致、促销活动规则不同、买赠、返利等业务信息难以结构化。

比如，同样是一批销售数据，不同市场可能会用不同方式记录“买多少送多少”的促销活动，如果没有业务理解，很难判断真实销售情况。

其次，审核成本高。

过去很多市场费用、营销费用主要靠人工审核。

比如经销商提交市场活动费用，总部人员需要判断：这个费用是否合理？

这个活动是否真实发生？

这个金额是否符合行业水平？

但因为材料很多，人工很难做到精细判断。

最终结果就是：企业知道需要管理，但没有足够的人力去管理。

过去企业也尝试过引入BI工具和报表系统，希望把经销商数据统一管理起来。

但问题在于，这些工具只能处理已经结构化的数据，而海外经销商的原始数据恰恰是非结构化的。

工具上线后，数据清洗和整理仍然靠人工，系统只是换了一个地方看Excel。

BI解决的是把数画成图，解决不了两个市场口径不一样——把两份不可比的数据画成漂亮的图，只是让不可比这件事更隐蔽了。

企业花了钱，但没有解决核心问题。

传统方案的根本缺陷，是缺少一个既理解业务现场、又能把AI能力翻译成可用系统的人。

三、AI 解决方案与交付路径

FDE的解决思路分为三步。

第一步，进入现场，重新梳理业务流程。

FDE近距离观察了总部的销售运营团队，看他们日常怎么接收经销商数据、怎么核对、怎么开会沟通；也通过远程方式了解了经销商侧的数据填报流程。

摸清全貌之后，项目团队开始明确：总部需要什么数据？

经销商能够提供什么数据？

哪些数据可以自动获取？

哪些数据必须人工确认？

比如，Sell In数据相对容易，因为它通常来自总部发货系统，结构比较标准；Sell Through数据更难，因为它来自渠道末端，数据来源复杂。

所以项目团队的重点是重新设计数据流转方式，从数据源头就把口径对齐。

第二步，拆解AI、人和系统分别承担什么工作。

项目团队认为，大模型的角色很明确：集中处理过去人工最消耗时间的部分。

AI主要负责从PDF、图片、Excel等非结构化数据中抽取信息，帮助完成数据清洗和格式转换，识别异常数据，辅助生成分析结果。

专业系统负责数据存储、数据管理、权限控制、业务流程流转。

人工负责最终判断、复杂业务决策、异常情况处理。

整个流程从过去的“人工传递 → 人工整理 → 人工审核”，变成“AI抽取 → AI校验 → 风险标记 → 人工最终审核”。

简单来说，就是把数据流转从“人为校验”变成“机器辅助校验 + 人工决策”。

第三步，让AI真正进入业务流程。

最初FDE的设想是搭建一个专门的海外数据平台，让经销商数据直接接入新系统。

但现场走了一圈后发现，企业总部已经有一套成熟的管理系统在跑，海外业务的员工和经销商都习惯了这套流程。

推翻重建不现实，更好的方式是在原有系统上做能力叠加：保留现有的框架和习惯，AI作为一层能力嵌入其中。

另外项目团队没有一上来就铺大摊子。

第一版只做中国、只做一条产品线，只回答一个问题：这条线的钱花得值不值。

就这一条线端到端做完整：数据能进来、数字点得开、结论能进周会。

跑通了，越南才接进来。

很多AI项目失败，是因为最后只是生成一个报告。

但企业真正需要的是：销售人员能看到数据，总部能快速判断市场情况，管理人员能发现异常。

AI嵌入已有系统后，总部可以新增数据入口，经销商按照统一字段提交数据，AI负责处理复杂数据，最终结果进入企业数据看板。

数据打通后，业务的人可以用大白话直接问，比如“这个SKU为什么掉了”。

但项目团队有一条硬约束：不是模型直接吐一个答案，而是模型帮项目团队定位到那一行原始数据，每个数字都点得开、看得见来源。

有些问题模型本来可以答得更漂亮，但溯不回去，项目团队就不让它答。

四、项目结果与业务价值

这个项目带来的价值，主要体现在三个方面。

先说明一句，下面的数字做过脱敏，量级是对的，绝对值做了处理。

第一，业务效果：减少市场费用浪费。

过去企业依靠人工审核市场费用，能够发现的问题比例不到10%。

引入AI辅助后，通过异常识别、历史数据对比和行业经验规则，可以发现约30%左右的问题。

虽然不是100%自动判断，但对于企业来说，已经意味着减少了相当一部分不必要支出。

比如，系统会根据历史活动、区域情况、类似案例进行交叉比较，标记异常费用。

最终仍由人工确认，但审核效率明显提高。

第二，流程变化：从经验管理变成数据管理。

过去海外业务管理高度依赖个人经验。

某个负责人熟悉市场，就能判断数据是否合理；换一个人，判断能力可能下降。

AI介入之后，企业开始把这些经验沉淀下来：什么数据异常？

什么费用合理？

什么情况需要进一步审核？

企业能力不再只存在于个人身上。

最直观的变化是周会。

以前的周会，前一个小时是在对数，这个数对不对、项目团队那份和FDE这份为什么不一样。

现在数已经在那儿了，会议直接从要不要动预算开始。

提问方式也变了：以前他们说“给业务人员一份报告”，现在直接问“这个SKU为什么掉了，是价格、铺货，还是渠道出了问题”。

能问出这么具体的问题，说明他们开始信这套东西了。

第三，长期价值：建立企业的数据能力。

对于跨境企业来说，一次数据整理能解决当下的问题，但更长远的价值在于：未来进入更多国家、面对更多经销商、管理更多销售渠道时，企业手里有一套可复制的数据治理方式。

项目图示

原案例图示（PDF 第 238 页）

原案例图示（PDF 第 242 页）

原案例图示（PDF 第 243 页）

五、关键落地难点

AI落地最大的挑战不在模型。

项目团队的说法是：难点不在技术层，技术大概只占20%。

第一个挑战：数据质量问题。

很多人认为AI项目最难的是模型，但实际落地时，数据才是最棘手的环节。

前面提到销售数据来源复杂、格式不一，真正进入开发阶段后，这个问题的难度会被放大：不同国家的数据习惯差异很大，很难用一套规则覆盖所有情况。

此外，数据准确性也是落地的关键门槛。

比如一张发票可能是PDF，也可能是图片；可能清晰，也可能手写、折叠、模糊。

如果不针对这些边界情况做充分测试，模型上线后一定会出问题。

项目团队的解决方式是双层的。

一方面先建立数据规范，再利用AI处理非结构化数据，现在视觉语言模型对于图片、票据等内容识别能力提升明显，很多过去需要专门训练的问题可以直接利用成熟模型完成。

另一方面，项目团队建立了一套评估样本，收集正常案例、异常案例和边界案例，持续测试模型在真实场景下的表现。

从项目实践看，这套样本非常重要：只有知道模型在真实环境里的表现，才能放心交付。

第二个挑战：业务团队和经销商的接受度。

总部团队最初对AI的判断结果持保留态度。

他们习惯了自己看Excel、凭经验判断数据是否合理，现在系统自动标记异常，有些人会怀疑：“AI说的就一定对吗？”经销商侧也存在顾虑：统一字段提交意味着要改变原有的填报习惯，增加了操作步骤。

项目团队的做法是分两步走。

对总部团队，先让AI做辅助标记，保留人的最终决策权。

每一处风险标记都附带依据（历史对比、区域参考、行业规则），让审核人员能看到判断逻辑，每个结论都有迹可循。

当业务人员发现AI确实能帮他们发现之前漏掉的问题时，信任就自然建立起来了。

对经销商，项目团队尽量降低填报门槛，能自动抽取的字段由AI完成，经销商只需要确认和补充。

两边的磨合花了一段时间，但一旦跨过信任门槛，推进速度明显加快。

第三个挑战：企业权限和流程问题。

很多企业已有成熟系统，FDE不能简单推倒重建。

尤其海外企业，权限审批流程比较复杂。

所以项目团队的方式通常是适配已有系统、增加接口、调整流程，避免推倒重建。

六、FDE 交付方法与企业启示

从FDE的经验来看，AI落地最重要的一点，是不要从技术出发。

第一，FDE首先需要理解业务。

很多企业第一反应是：“企业有什么模型？”“企业能不能做Agent？”“企业能不能接入大模型？”但真正的问题应该是：业务哪里最痛？

哪里最浪费时间？

哪里过去依靠人工经验？

客户最终买单的，永远是解决问题产生的价值。

第二，FDE需要成为业务和技术之间的连接者。

一个纯技术工程师，如果不了解行业，很难发现真正的问题。

而一个懂业务的人，可以知道哪些数据重要、哪些流程可以优化、哪些结果企业真正关心。

FDE正是需要具备这种业务判断力，才能把技术能力用在真正产生价值的地方。

第三，AI项目成功关键在落地细节。

模型能力越来越强，通用能力越来越完善。

未来企业之间竞争的重点，将逐渐从模型能力转向对业务的理解深度。

FDE需要关注：用户是否愿意使用？

流程是否适配？

成本是否接受？

结果是否可靠？

项目团队内部把交付固化成五步：诊断、数据审计、窄MVP、嵌入、扩展。

顺序不能乱，理解业务永远在技术选型前面，赢得信任之后才扩面。

模型是入场券。

领域加交付，才是护城河。

评判一个FDE项目，不看demo多炫，看客户有没有真的改变决策方式。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 图像类型清单、标注样本集、识别错误集和人工复核规则
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径
• 人工审核、失败回退、上线巡检和持续迭代清单

来源与作者

Datawhale《FDE案例100》，受访者：朱恒璟（ChillaHub.ai联合创始人）；PDF 第 237-246 页，书内页码 236-245。本文为访谈资料的第三人称整理，不是本站新采访。