从大海捞针到全链路提效：FDE用AI重构TikTok达人建联与履约

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

原案例封面

为什么这个案例值得看？

TAP 团队同时管理大量达人、上万个商品和持续增加的履约任务，信息散落在平台、Excel、飞书和不同岗位手中。项目重新梳理达人建联、选品、履约和数据管理链路，让 AI 承担筛选、匹配、内容生成、提醒和数据整理，试运行后平均履约周期由约一个月缩短到约 18 天。

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

一、企业与业务场景

这个项目的业务场景，是一家国内头部电商企业在海外TikTok生态里的达人建联业务。

如果用国内电商的经验来理解，TAP有点像“团长”。

商家有新品或者营销节点，希望在短时间内找到大量达人帮自己带货，就会先找到TAP；TAP再从自己的达人资源里筛选合适的人，推动他们接品、拿样、创作内容，最终把商品挂到达人账号上。

这个角色本身解决的是一个很现实的问题：TikTok上商品太多，达人不可能一个个去翻商品市场，也很难仅凭商品信息判断什么值得带，所以TAP需要把商家和达人组织起来。

项目团队接触这个客户的时候，对方其实没有一开始就把问题定义得特别清楚。

最开始他们找到FDE时，问的是一个很宽泛的问题：“企业团队怎么用AI赋能？”所以FDE没有直接回答，而是先反过来问他们：项目团队们现在的业务到底怎么跑？

哪个环节最慢？

谁每天最累？

哪里最容易出错？

后来项目团队去了企业现场，从老板到部门负责人，再到各个小组负责人，基本都访谈了一遍。

访谈下来，FDE发现他们其实已经意识到自己效率不高，但之前所谓的数字化，更多只是“先进团队先用飞书”，真正到了业务层面，依然有大量工作靠人工完成。

FDE把整个业务放在一起看，发现这个问题贯穿了好几个环节。

第一是达人建联，找人难。

运营人员需要在TikTok上寻找、筛选达人，然后主动发消息沟通。

以前很像“大海捞针”，运营需要自己找人、看达人信息、判断是不是适合合作，再进行沟通。

第二是商品匹配，匹配难。

客户自己的选品池里就有上万个商品，而达人又有不同的内容标签。

有的是运动达人，有的是生活方式达人，有的是历史、哲学类内容创作者。

到底什么商品应该推给什么达人，本质上是一个匹配问题。

第三是履约，周期长。

达人确定合作之后，还要经历寄样、收样、沟通拍摄、创作视频、提交TikTok等环节。

原来的平均履约周期大概在一个月左右。

运营人员大量时间花在“催”上：企业的样品到了没有？

什么时候拍？

什么时候提交？

是不是快到截止时间了？

第四是数据管理，太分散。

这其实是一个更底层的问题。

TikTok上有一部分数据，Excel里有一部分，财务系统里还有一部分。

达人BD（Business Development，商务拓展）、履约人员和财务各自维护自己的数据，老板想知道一个达人从建联到最终产生GMV（Gross Merchandise Volume，商品交易总额）到底经历了什么，并不容易。

所以FDE最后判断，整个业务链路已经到了需要重新梳理的阶段。

二、原有流程与核心问题

业务规模还不大的时候，这套流程主要靠人。

一个运营每天维护几十个达人，自己记得住谁聊到哪一步、谁收了样品、谁还没有拍视频，再配合飞书和Excel，业务就能够正常运转。

达人建联本身还高度依赖人与人之间的沟通，特别是一些粉丝量很大的达人，甚至接近明星级别的达人，商务沟通里有很多微妙的东西，过去主要靠经验丰富的BD去判断、沟通。

真正的问题，是业务复杂度上来以后，这套方式开始出现瓶颈。

比如选品池从几百个商品变成上万个商品，运营就不可能再靠经验一个个匹配；达人越来越多以后，也不可能每天靠人工翻Excel找哪些人要催；数据分散在不同系统里以后，管理者也很难及时看到整个业务漏斗。

项目的核心逻辑是，过去这套方式解决的是“业务能不能跑”的问题，而AI要解决的是“业务规模起来以后还能不能高效地跑”的问题。

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

当时，FDE做的第一件事情，是把业务流程画出来。

从达人进入，到达人建联，到选品匹配，再到拿样、创作、履约，最后到数据复盘，FDE把整个链路拆开来看：每一步是谁在做？

输入是什么？

输出是什么？

需要什么判断？

哪些工作必须由人完成？

哪些工作其实可以交给机器？

拆完以后，FDE发现并不是所有环节都适合AI，所以项目团队的思路是AI和人重新分工。

第一步：让AI先做“找对人”达人建联是一个很典型的例子。

项目团队可以利用商品信息、达人标签、内容属性等数据，先筛出一批更值得运营人员关注的达人。

例如，一个商品的主要卖点是什么，它适合什么样的人群；一个达人是什么内容类型，他的受众是什么。

系统先把匹配度高的人筛出来，给BD一份更精准的名单，这样运营人员就不用从整个TikTok里“大海捞针”。

但最终发消息、沟通、建立关系，项目团队仍然保留人工，因为达人是客户最核心的资产。

所以这里AI的角色，是让BD从寻找目标，变成直接和目标沟通。

第二步：用AI解决“什么商品给什么达人”的匹配问题以前运营需要根据达人标签和自己的经验判断应该推什么商品，现在项目团队把商品本身的卖点提取出来，再和达人的内容属性进行匹配。

比如一个咖啡产品，它的卖点可能包括口味、气泡、品牌、联名等；如果一个达人本身就是职场、生活方式方向，那么这个商品和他的内容属性可能比较匹配。

AI可以先完成这层筛选，再由人工确认，这就把原本大量依靠人的经验进行的初筛，变成了“AI先筛、人再判断”。

第三步：用AI帮助达人完成内容创作，解决履约动力问题这个环节是项目实践表明比较有意思的地方。

很多时候，达人并不是不愿意带货，他们真正的卡点是拿到商品以后不知道“怎么拍”。

因为一个带货视频不是简单地把商品介绍一下就结束了，它需要考虑达人自己的表达方式、商品卖点，以及当前什么样的视频内容更容易获得关注。

所以项目团队把这几个因素结合起来：达人特点 + 商品卖点 + 爆款内容参考，系统分析之后，给达人提供几个可选的拍摄脚本。

这实际上是在帮助达人完成一部分创作工作，对达人来说是一个“利他”的能力，而不仅仅是TAP自己提高效率。

访谈中客户反馈，目前达人对这部分能力的接受度比较高。

在这个基础上，未来还可以进一步探索AI视频生成，让达人在真实出镜之外，多一种内容生产方式。

不过对于个人IP型达人，项目团队仍然认为真实的人和内容是核心。

第四步：把“每天人工催人”变成系统主动提醒这是整个项目里比较容易看到效率变化的一块。

过去运营人员需要每天打开Excel，看哪些达人到了截止时间，再一个个去催。

现在系统会根据履约状态自动判断：哪些达人已经收样，哪些人还没有完成，哪些任务快到截止时间，哪些已经超过系统提醒仍然没有动作。

系统先自动提醒，如果达人还是没有履约，再把任务交给人工运营处理。

这样一来，人不需要每天从几张表里找工作，系统会直接说明：“今天业务人员真正需要处理的事情是什么”，这也是这一案例体现的AI落地和普通自动化之间很重要的区别：AI落地在做的是重新组织人的工作方式。

第五步：把分散的数据重新串起来项目团队还把达人建联、履约、商品、GMV等数据逐渐放到统一的业务视角里。

管理者真正需要看的，是今天新增了多少达人、建联了多少、有多少进入履约、带来了多少GMV、一个达人投入了多少样品成本，以及最后给企业带来了多少价值，这样才能真正判断一个达人到底值不值得长期合作。

所以从头到尾，可以把这个项目理解成：AI嵌进了整个业务流程。

四、项目结果与业务价值

最直接的变化，是履约周期缩短了。

过去，从确定合作到达人收到样品、完成创作并提交视频，平均大约需要一个月；项目试运行之后，目前配合的达人平均履约时间已经到了约18天。

但从项目实践看，这个数字并不是这个项目最大的价值。

更重要的是，整个团队的工作方式发生了变化。

以前运营人员大量时间花在找人、找商品、找任务上，现在变成了AI先帮他们筛达人，系统先帮他们匹配商品，AI辅助达人完成创作，系统自动提醒履约，系统主动把需要人工介入的任务拉出来。

于是运营人员可以把更多时间放在真正需要人的地方：和达人沟通、建立关系、处理复杂商务问题。

尤其是高价值达人，这种变化更明显，过去运营人员可能把大量精力耗在寻找和筛选上，现在可以把精力集中到真正重要的商务关系上。

另外一个变化，是管理者开始真正看到业务。

以前老板很难看清一个达人从建联到GMV中间每一步发生了什么；现在至少可以围绕“达人—履约—GMV”形成更完整的业务视角。

所以如果一定要总结这个项目的价值，可以概括为：以前团队是在管理一堆表格，现在是在管理一条业务链路。

五、关键落地难点

当然有，而且项目实践表明这些问题恰恰是FDE案例最值得分享的部分。

第一个挑战，是数据权限。

这个项目的数据大量来自TikTok，而且涉及跨境业务，所以数据权限、用户隐私、数据留存和服务器部署都有比较严格的要求。

项目团队光数据这一块就花了接近一个月，数据申请会被打回来再重新申请，权限账号要重新确认，服务器怎么部署也需要确认，甚至数据能不能离开所在国家、应该留在哪里，都需要提前搞清楚。

所以如果要做境外业务，FDE可以特别建议FDE提前把数据合规和数据流向研究清楚。

不要等系统都做完了才发现数据拿不到。

第二个挑战，是哪些事情应该交给AI，哪些事情不能交。

这是这个项目里项目团队反复讨论的问题。

比如达人匹配可以交给AI，建联名单可以交给AI初筛，履约提醒可以自动化；但真正和重要达人沟通，项目团队还是保留人工。

原因很简单：AI现在仍然可能犯一些很低级的错误，在普通工作里，一个小错误可能只是改一下内容，但在商务关系里，如果对象是一个拥有几百万粉丝的达人，一句话说错了，损失可能远远超过自动化节省的人力成本。

这也是为什么最终没有做“全自动达人建联”。

第三个挑战，是企业内部的人。

很多企业一听到AI，第一反应就是“是不是要替代人”，这个项目里项目团队其实非常注意这一点。

FDE在推进的时候，会把AI的定位明确成“帮助大家解决问题、提高效率”，让大家理解这套系统是要帮忙，不是要替掉谁。

同时项目团队在访谈时也不会只找老板，因为老板决定战略，但真正使用系统的是一线员工。

所以FDE可以同时和上层、中层、基层沟通：老板告诉项目团队业务目标，一线员工告诉项目团队每天到底卡在哪里，两边的信息拼起来，系统才有可能真正落地。

这也是为什么FDE一直强调FDE的一个核心能力：让这个系统真正进入企业的工作方式。

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

这个项目清晰地说明：FDE真正难的地方，往往不是模型。

现在很多AI能力其实已经非常成熟了，对于中小规模企业来说，技术选型本身反而没有以前那么难，项目团队更关注的是成本、稳定性和ROI（Return on Investment，投资回报率），尽量用成熟的框架和合适的模型解决问题，避免为了技术先进而技术先进。

真正难的是下面几件事。

第一，先理解业务，再谈AI。

不要一上来问客户“业务人员想做一个什么AI产品”，应该问：企业的业务怎么跑？

谁在跑？

哪里最浪费时间？

哪里最容易出错？

哪个指标最影响业务结果？

只有把这些问题问清楚，才能知道AI应该放在哪里。

这个项目最开始客户只是说“希望AI赋能团队”，但如果项目团队停在这个层面，最后可能只能给他做一个聊天机器人。

真正走进企业之后，项目团队才发现，最值得解决的是业务链路里的几个具体环节。

所以FDE的第一项能力，其实是价值识别能力。

第二，重新分配人和AI的工作。

FDE现在越来越倾向于把AI理解成一种新的生产力。

它适合接手高频、重复、有明确规则的事情，但高度依赖信任、关系和判断的工作仍要留给人。

这个项目最后，是让BD不再把时间浪费在找人和翻表格上，AI把人从低价值工作里释放出来，人再去做真正高价值的事情。

第三，FDE必须同时懂技术和业务语言。

FDE团队是技术出身，做了十年代码，后来经历了项目、产品等不同岗位。

早期项目中曾出现一个误区：只要把技术讲清楚，客户就应该能理解，但后来发现不是。

很多老板没有时间理解模型、Agent（智能体）、RAG（Retrieval-Augmented Generation，检索增强生成）这些东西，他真正关心的是：“业务人员能不能帮业务人员把这个问题解决掉”。

所以FDE要做的是把技术语言翻译成业务语言，把业务问题再翻译成可以落地的技术方案。

这也是为什么项目实践表明，技术同学如果想做FDE，除了技术能力之外，还必须补商业沟通、场景识别和价值表达的能力。

第四，真正的FDE要对业务结果持续负责。

项目经验表明FDE和传统软件外包最大的区别之一，就是是否对业务结果持续负责。

传统项目可能是：需求来了 → 做系统 → 验收 → 交付；但FDE更像：进入业务 → 理解问题 → 做第一版 → 让业务使用 → 根据反馈继续改 → 找到新的业务问题 → 再迭代。

这个项目就是这样，一期做完以后，客户自然会出现二期需求，因为当第一个问题解决以后，企业会发现下一层问题。

所以FDE要做的，是持续陪着企业把AI能力往业务里推进。

最后，项目实践表明FDE一定要做深垂直场景。

未来AI的技术门槛会越来越低，很多基础能力都会变成标准能力，真正有价值的是，FDE是不是足够懂某个行业，知道这个行业的问题在哪里，知道AI应该怎么进入它的业务流程。

所以项目团队自己也在考虑，未来不再什么项目都接，会进一步深耕一两个垂直场景，因为当项目团队足够懂一个行业之后，第一次做这个场景可能需要100%的成本，第二次可能变成80%，第三次可能变成60%，项目团队不断把经验、工作流、技能和业务理解沉淀下来，才能真正形成自己的壁垒。

这一案例中的FDE角色，最终是站到业务现场，找到AI真正能创造价值的位置，然后一直把它推进下去的人。

这也是项目实践表明这个项目最有价值的地方：项目团队没有试图证明AI什么都能做，项目团队做的，是通过一次真实业务落地，把“哪些事情交给AI、哪些事情留给人”这件事重新划分了一遍。

当这个边界划对了，AI才真正开始变成业务生产力。

七、可复用的交付资产

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

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

来源与作者

Datawhale《FDE案例100》，受访者：KevinSun孙斌（117AI FDE团队负责人）；PDF 第 47-56 页，书内页码 46-55。本文为访谈资料的第三人称整理，不是本站新采访。