从库存割裂到业务联动：FDE用AI打通跨境电商的库存、补货与广告决策

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

原案例封面

为什么这个案例值得看？

跨境电商的订单、库存、新品、物流、补货和广告数据分布在多个平台、聚合 SaaS 与飞书中。项目先打通数据，再用 AI 处理物流照片和回填、生成补货预警，并联动库存与广告投放；每天 4—5 小时的图片和数据处理被压缩到 1 小时以内，2—3 小时的补货流程变为 AI 生成、人工确认。

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

一、企业与业务场景

这个案例表面上看是一起“系统集成”，但真正要解决的，是跨境电商业务链路上的信息割裂。

客户是一个十几人的跨境电商团队，主要做东南亚市场，主营服装。

服装行业每个颜色、每个尺码都会形成一个独立SKU，所以SKU特别多。

按照访谈中的估算，他们每个季度新增500～800个SKU，全年SKU大概在2500～3000个。

对于一个10～15人的团队来说，这样的SKU数量和平台复杂度已经不低了。

他们过去的库存数据集中在一个多平台聚合SaaS里，各个电商平台的库存会汇总进去，但新品开发、部分业务信息又在飞书里，两边没有打通。

客户最开始找到FDE时，说得非常简单，能不能把这个SaaS和飞书打通。

FDE没有急着把它当成一个API集成项目。

如果只是集成，技术上没有太大障碍，真正要问的是，打通以后谁用，用来解决什么业务问题。

所以项目团队没有急着开发，连续开了几次会，让客户录屏演示他们实际怎么工作。

也正是在这个过程中，项目团队才逐渐看到，库存只是整条链路上的一个环节。

工厂发货时没有用RFID或者扫码枪，物流环节仍然靠拍照、识图，再由员工人工看照片、填写数据，追踪物流单号和进展。

数据已经产生了，人还在充当那个“数据搬运工”。

库存管理也一样。

过去他们通过Excel计算补货，工作人员要从聚合SaaS里把数据扒下来，填进自己的计算表，按自己的一套公式计算补货，再把结果填进另一个模板，最后生成PDF发给供应商。

广告的问题更直接。

他们每天在Google、TikTok等平台投广告，广告是持续烧钱的。

如果某个SKU库存已经很低，广告还在继续跑，客户继续下单，企业却发不出货，广告费用还在继续消耗。

所以FDE最后看到的，是一条业务链。

订单和库存数据 → 物流数据 → 补货决策 → 供应商下单 → 广告投放。

真正值得解决的，是让这些原本割裂的环节能够互相感知。

二、原有流程与核心问题

过去这家团队的工具不算少，Excel、聚合SaaS、飞书都在转。

最累的，是那个在各个工具之间来回搬数据的人。

十几人的团队，业务规模还不大的时候，一个人来回搬数据也应付得过来，成本也不高。

他们补货也有一套自己的公式，工作人员看SKU过去三个月的销售，结合自己的预测逻辑，就能算出下一次该补什么颜色、什么尺码、补多少。

这套逻辑是成立的，问题在于它被埋进了一条需要人工反复搬数据的流程里。

所以项目团队没有重新发明一套库存算法。

客户原来的补货逻辑可以继续保留，项目团队要做的，只是把其中机械、重复、跨系统的动作交给机器。

这个案例的瓶颈，在数据和人的关系上。

工作人员先把数据从一个系统里扒下来，填进Excel；Excel算完，又誊到另一个模板；物流照片到了，再一张张人工看；广告又在另外的平台上跑。

每件事单独看都不重，可一旦连成一串，就是一条非常长的人工链路。

SKU还在涨。

几十个、几百个的时候，人盯得过来；涨到几千个，人一天的时间就大量耗在“看、抄、填、核对”上。

规模越大，人越被钉在这些搬运动作上。

项目团队的改造，是把这条人工链路拆开，看清哪些环节必须由人做，哪些环节机器做得更好，再把机器擅长的部分接上。

工具没换，人不用再当那个中间连接件。

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

这个案例最有意思的地方，是项目团队一开始根本没有一个完整需求内容。

客户最初只是说，FDE想把两个平台打通。

如果按照传统项目交付的方式，FDE可能就直接拿需求、评估接口、开始开发。

但FDE的工作方式不太一样，FDE需要先判断客户真正想解决什么。

项目团队大概花了一周，进行了三四轮沟通，把客户的场景一点点收集起来，再回来和团队讨论，哪些地方适合自动化，哪些地方可以接Agent，哪些地方其实不需要AI。

第一步，先把数据打通。

项目团队做的第一件事，是先把数据基础搭起来。

客户原来的核心数据在聚合SaaS里，业务管理又在飞书里，所以项目团队先想办法把数据同步到飞书，让他们可以直接在熟悉的业务环境里看到实时库存。

这个过程中，碰到了整个项目里最难啃的技术问题。

对方SaaS的API开放程度很低，Key的机制也满足不了客户多个团队同时共享数据的需求。

最后项目团队增加了一层开源的云端数据库（Supabase）做中转，让数据先进入这个中间库，再从这里同步到飞书。

这也正是FDE做事的方式，业务目标不变，实现路径可以不断调整。

第二步，让AI处理物流照片。

数据打通之后，一个非常明显的人工瓶颈冒了出来，物流照片。

以前工厂拍完照，上传到多维表，接下来全靠员工一张张看图、回填。

这个流程其实非常适合AI。

所以项目团队让Agent参与“识图+回填”，同时保留人工确认。

AI负责把原来最耗时间的第一轮识别和数据录入做掉，人只需要最后检查。

这一点FDE很看重，AI放在这里，是因为这段工作本来就适合它。

第三步，让AI照着原来的公式算补货。

数据打通之后，原来那套靠人扒数据、填表、计算的补货流程，就有了新的基础。

现在数据可以直接进入业务流程，Agent按照原来的补货规则进行计算，把需要补货的SKU筛出来，同时给出预计的补货周期和数量。

人工的角色从“计算员”变成了“审核员”。

如果结果没问题，确认之后就可以直接生成PDF订单发给供应商。

第四步，再把库存和广告联系起来。

做到这里，客户又自然产生了下一层需求。

既然现在已经知道库存了，那是不是可以让库存反过来影响广告？

于是项目团队进一步把库存、订单以及广告投放情况结合起来。

当某个SKU库存下降到一定程度时，Agent可以判断对应广告是否还应该继续投。

如果库存不足，就先把广告额度调低，甚至暂停广告，避免一边烧广告、一边发不出货。

所以整个过程，更像是一步步往前推，打通数据，看见新问题，解决新问题，再产生新的业务可能性。

客户一开始自己也没有把这些需求全部想清楚。

很多时候，他只是知道“业务人员现在很痛”，但不知道技术应该怎么解决。

FDE要做的，就是把这种结果导向的需求，拆成可以落地的业务和技术问题。

Image Image

四、项目结果与业务价值

这个案例有一个特别的地方，交付结束后，客户把项目团队的团队权限移除了，后续的营收、广告成本和利润数据，项目团队没有拿到完整的。

但时间效率上的变化是比较明确的。

以前处理物流照片和数据，一个人每天大概需要花4～5个小时去看图片、写数据。

现在AI先完成识别和回填，人只需要做最后的核对，整体时间被压缩到了1小时以内。

补货也是类似。

以前从不同系统扒数据、对数据、填Excel、计算，再整理成订单，至少需要2～3个小时。

现在Agent把结果算出来之后，工作人员主要负责看一眼、验证一下，确认之后就可以生成订单。

所以可以把这个项目的价值概括成三个变化。

第一，从“人工搬数据”变成“数据自动流动”；第二，从“人工计算”变成“AI计算、人工确认”；第三，从“库存、补货、广告各自决策”变成“库存开始影响广告决策”。

尤其第三点，项目经验表明比单纯节省几个小时更重要。

以前库存是一个结果，广告是另一个动作，两边其实是割裂的。

现在库存变化可以直接影响广告投放，业务开始从单点自动化走向了流程之间的联动。

当然，这个案例的效果跟踪还有不足。

五、关键落地难点

这个项目真正难的地方，其实不在Agent怎么写。

最难的是两件事，需求，以及现实世界里那些“不好用的系统”。

第一个挑战，客户说出来的需求，不一定是真正需求。

客户一开始说的是“帮业务人员把两个系统打通”。

但如果项目团队就照着这个需求做，可能最后只是交付了一个API接口，而没有解决他真正的问题。

所以项目团队反复让客户演示工作流程，甚至让他录屏。

只有把“他每天到底怎么工作”看清楚以后，项目团队才发现后面还有照片处理、补货、供应商下单、广告投放等一系列问题。

这件事让FDE慢慢相信，FDE很重要的一个角色其实是“翻译”。

客户说的是业务语言，技术人员听到的是技术语言，中间需要有人把两者转换起来。

FDE团队在团队里其实就比较偏这个Echo的角色，前期咨询、快速做演示、做技术选型，再把客户说的话整理成技术人员可以执行的需求。

甚至当时，FDE在和技术团队开会之前，会先让AI帮FDE把客户的需求重新梳理一遍，再拿去跟技术人员沟通。

这本身就是一种AI优先的工作方式，AI先帮助FDE提高自己的理解和表达效率，项目本身仍然由FDE来推进。

第二个挑战，API能不能用，和“有API”完全是两回事。

一开始项目团队想得很简单，有API，就可以接。

真正做起来以后才发现，SaaS方提供的API虽然能用，但Key有失效机制，一个Key也不能被多个团队同时使用。

如果A团队刷新Key，B团队原来的Key就会失效，而客户除了项目团队之外，实际有多个团队需要共享这个key去拉数据。

最后项目团队在中间加了一层数据中转，把数据先引出来，再同步回飞书。

这件事让FDE印象很深，它说明了一个问题，现实世界里的AI落地，很多时候卡在模型之外，企业原有系统的开放程度、数据结构和接口限制，往往才是真正的门槛。

AI本身可能已经能做了，但数据根本拿不出来，还是落不了地。

第三个挑战，先判断这个问题到底需不需要AI。

项目团队一开始考虑过Agent，但会先判断，看到一个需求，到底值不值得上Agent。

一些非常确定、规则非常死的任务，其实写一个脚本、跑一个定时任务就够了。

只有当任务开始涉及语义理解、跨系统判断，传统脚本比较难覆盖的时候，才需要引入Agent。

所以做方案选择时，需要先问，这个问题到底需不需要AI。

能用简单自动化解决的，就不要为了追热点强行用Agent；真正需要理解、判断和跨流程协作的部分，再把Agent放进去。

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

长期项目实践表明，FDE真正的壁垒并不在“会不会搭一个Agent”。

因为现在代码、自动化、Agent这些东西都更容易获得了，技术本身在变便宜，真正值钱的，是项目团队能否理解业务、判断需求，以及知道什么方案真正适合这个客户。

FDE团队总结下来，有几个比较重要的经验。

第一，先解决业务问题，再决定用什么AI。

客户告诉企业的往往是一个结果，“业务人员希望库存不要断”，“业务人员希望补货不要这么麻烦”，“业务人员希望广告不要浪费钱”。

但他不一定知道应该用Agent、脚本、自动化还是一个表格解决。

FDE的价值，是先把客户要的结果拆开，看清它背后对应哪条业务链路，再判断技术该插在哪一段。

第二，不要把“需求不明确”理解成客户不知道自己要什么。

其实客户通常知道自己想要什么，他们只是不会用技术语言描述。

这个案例里，客户知道自己想把库存管理做好，也知道自己希望减少人工操作，但他不知道API怎么接、不知道哪些流程适合自动化，也不知道库存和广告其实可以联动。

所以FDE的工作，是把客户已经存在、却一直没被清楚说出来的需求，落成可以执行的技术方案。

第三，AI落地一定要保留人在关键节点上的判断。

这个案例里，项目团队没有追求100%无人化。

图片识别之后，保留人工核对；补货计算之后，人工确认；广告调整也是基于库存情况做业务判断。

项目经验表明这是比较现实的AI落地方式，AI负责处理大量重复工作，人负责最终判断。

（Human in the loop)尤其在企业场景里，真正有价值的，是把人的时间从低价值操作中释放出来，让这些时间流向更需要人的判断力的地方。

第四，FDE一定要沉淀行业方法论。

这一点，是FDE这两年体会特别深的地方。

如果今天做一个电商客户，明天做一个制造业客户，后天又做一个完全不同的行业，每次都从零开始理解业务，那么交付成本会非常高。

但如果项目团队长期深耕一个行业，很多东西就可以复用。

比如表格应该怎么设计、业务流程在哪几个环节最容易出问题、Agent应该插在哪里、客户通常会有哪些需求，这些经验都会逐渐沉淀下来。

项目经验表明真正可持续的FDE，是找到自己最擅长的行业和场景，把一个行业反复做深。

第五，交付之后，效果归因也是FDE工作的一部分。

这个案例最大的遗憾，就是项目团队当时交付完以后，没有把后续效果完整追踪下来。

主要是项目团队以往的合作模式也是偏向外包的方式，对于效果的追踪没有那么重视。

交付之后，只有客户在使用过程中遇到问题会回来找项目团队，但项目团队没法系统地记录和监控到底节省了多少时间、减少了多少成本、对营收和利润产生了多少影响。

后来项目团队也意识到，这其实应该成为FDE服务闭环的一部分，交付、使用、反馈、迭代、效果归因，再进入下一轮优化。

团队后来也开始探索更系统的回访和数据收集方式。

所以如果让FDE重新做一遍这个项目，FDE可能会在一开始就设计好一套“效果基线”。

项目上线前，记录人工处理需要多少时间；上线后，再持续记录需要多少时间；补货、广告、订单等关键环节，也尽量找到可以量化的指标。

这样项目团队最终交付的，就既是一个“能跑的AI”，也是一套能够证明自己到底创造了多少业务价值的解决方案。

这也是这一案例中的FDE角色，站到业务现场，和企业一起，把一个模糊的问题，逐渐变成一个可以运行、可以使用、可以持续产生价值的东西。

七、可复用的交付资产

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

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

来源与作者

Datawhale《FDE案例100》，受访者：张新卓（Pathwyze杭州拓径咨询Founder）；PDF 第 219-228 页，书内页码 218-227。本文为访谈资料的第三人称整理，不是本站新采访。