从文件散乱到随取随用：FDE用AI帮外贸企业把资料变成可用资产

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

原案例封面

为什么这个案例值得看？

一家年销售额数亿元、团队仅十余人的外贸礼品公司，样图、美工图、参考图和客户资料散落在员工电脑与文件夹中。项目从老板愿意付费解决的小问题进入，先整理图片和文件，让 AI 能够理解、检索和调用，再逐步接入阿里国际站运营、网站更新与产品海报等日常流程。

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

一、企业与业务场景

FDE接触这家企业时，第一反应是他们提出的需求一点都不“高大上”。

这是一家做外贸礼品的公司，产品包含起瓶器这类小商品，一年销售额大概有几个亿，但整个团队只有十几个人。

公司业务跑了很多年，问题在于数据太多、太散，而且其中相当一部分是图片，比规整的文字和表格更难整理。

电脑里有样图、美工图、参考图、客户交付图，还有各种产品模板，分散在不同电脑、不同文件夹里。

所以老板一开始给FDE的需求非常具体：能不能以后FDE直接跟AI说一句话，比如“帮业务人员找一下某个客户之前用过的某个模板”，AI就直接把东西找出来？

除了文件搜索，他还有几个需求。

比如，希望AI能够看到阿里国际站的数据，告诉他今天哪些关键词表现怎么样，要不要换词；希望AI帮公司网站持续发文章；还有产品海报，以前需要把产品图交给人处理，他希望以后直接给AI一个产品，就能自动放进已有模板里。

这些事情单独看都不复杂。

但真正的问题，其实藏在这些“小需求”下面。

首先是企业的数字资产并没有真正被组织起来。

文件虽然都在电脑里，但AI不知道这些文件之间是什么关系，人自己也未必知道。

其次是企业缺少AI可以直接运行的环境。

不能说今天买一个大模型账号，明天企业就AI化了。

网络、电脑环境、权限、文件结构、工作流程，这些都会影响AI到底能不能真正进入业务。

第三个问题反而最重要，就是信任。

很多老板已经听过不少AI概念，甚至知道Agent是什么，但他们不知道这些东西跟自己每天遇到的问题到底有什么关系。

所以FDE进去以后，项目实践表明第一件事是找到一个老板真正关心的问题，然后告诉他：这个问题，AI能不能比项目团队原来的方式解决得更好？

这才是起点。

二、原有流程与核心问题

这家公司之前已经为数字化和AI相关服务花过钱。

比如，老板花过大约5万元购买相关服务，对方可以基于国际站拿到一些数据，也搭建过外贸网站。

这个产品本身有一定价值，但更接近一个标准化产品。

企业遇到个性化问题以后，后续没有人继续陪他往下走，也没有人告诉他这个工具怎么和自己公司的工作方式结合。

项目持续追问，为什么传统的软件和外包方式以前能够运行？

因为过去企业的问题相对明确。

FDE要一个网站，就找人做网站；FDE要一个ERP，就买ERP；FDE要一个设计稿，就交给美工。

一个问题对应一个工具或者一个人。

这种方式本身没有错。

但随着业务越来越复杂，老板开始发现，公司里同时存在几十个、几百个非常碎的小需求。

如果每一个需求都找一个外包团队开发，成本根本承担不了。

更关键的是，很多问题甚至没有清晰到可以直接写成需求文档。

老板知道“这里不太顺”，但他自己都不知道应该开发什么。

FDE印象很深的是，这个外贸老板当时碰到一个客户需求。

客户给了他一个类似三角尺的产品，上面有一排不规则的刻度。

他们找过美工，也做过3D打样，但一直没有搞清楚这排刻度到底是什么，甚至准备人工照着抄，但又抄不准。

如果按照以前的工作方式，这可能又要找人、搜索资料、反复确认。

当时，FDE没有给他开发任何软件。

FDE直接把照片丢给AI，让AI判断这是什么产品，如果不知道就继续找相关资料、生产厂商以及附加文件，再分析如果要把这个产品做出来需要哪些信息。

大概10分钟，AI把产品找到了，也搞清楚了那排所谓“不规则的刻度”其实代表的是角度。

老板当时很惊讶。

因为按照他原来的思路，这件事情可能要研究一两天。

这个瞬间其实非常重要。

他第一次意识到，AI不需要被当成一个需要单独学习的新软件，它本身就是一种完全不同的解决问题方式。

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

真正开始做以后，项目没有急于开发功能。

第一步，先处理现场环境。

项目团队决定直接使用最顶尖的大模型，但到了企业现场才发现，他们内部的网络环境经过历年来自己不断的调整，非常复杂：4台路由器、2台光猫、1台交换机，还有一个软路由，整个网络串得很乱，也时常不稳定。

所以，为了让Agent具备更稳定和灵活的内网访问权限和工具，FDE第一天几乎是在当网络工程师。

这个开头也说明，企业AI落地的第一件事，常常是先把以前留下来的基础设施问题解决掉。

公司内网不通、设备环境不一致，再好的Agent也跑不起来。

第二步，重新整理企业文件。

网络解决以后，FDE做的第二步是整理企业的文件。

这一步比简单地把文件塞进一个所谓“知识库”要复杂得多。

项目团队的做法，是重新组织散落在各台电脑上的资料，建立文件之间的关系，让AI知道哪些文件属于哪个客户、哪个产品、哪个项目，以及不同资料之间是什么关系。

但这里马上遇到了一个现实问题：这些资料不能直接交给项目团队。

对于老板来说，电脑里的合同、客户资料、产品文件，本身可能就是公司最核心的资产，有些东西甚至不会给公司其他员工看，更不可能全部打包发给一个外部FDE。

第三步，把数据留在企业，把开发能力送进去。

按照传统做法，项目团队会把数据打包拿回来开发，但到了现场才发现这条路走不通。

于是项目团队调整了思路，先把一套Harness整理成任务包，把框架、原则、规范和Demo一起部署到客户自己的Codex里，再让客户本地的Codex按照项目团队的规范，在他的电脑和文件环境里继续完成开发。

项目团队前期花了几十个小时把框架做好，然后让客户侧的Codex继续跑大约40个小时。

跑出来以后，老板开始测试。

测试产生的日志、问题和记录，再由客户侧的AI整理给项目团队，项目团队根据这些反馈继续修改规范和任务，再让客户侧的AI完成适配。

这个过程从项目实践看很重要。

因为它改变了过去“驻场工程师必须一直守在客户电脑旁边”的工作方式。

数据不需要离开企业，开发和适配却仍然可以继续。

第四步，让交付沉淀成企业自己的能力。

更重要的是，项目团队不想永远替企业做这些需求。

FDE的目标是把文件文档化，把资料关系梳理出来，把知识沉淀下来，再建立工作流、Skill和Agent。

这些东西逐渐沉淀以后，企业自己就能解决越来越多的问题。

FDE更希望最后交付的是企业自己解决下一批问题的能力，让企业以后不必每遇到一个问题都来找FDE。

四、项目结果与业务价值

如果只从一个软件项目的角度看，现在其实还很难给这个案例下一个“效率提升了多少百分比”的结论，因为项目本身还处在第一阶段，交付也还没有全部完成。

不过，这个项目已经发生了几个非常明显的变化。

第一个变化，是企业开始真正理解AI能做什么。

那个角标尺问题，老板本来以为要研究一两天，项目团队现场用AI大约10分钟就找到了产品来源和刻度含义。

后来他觉得矢量图很难做，项目团队又直接问AI应该用什么工具，当场把矢量图做了出来。

这个结果真正重要的地方，是老板开始意识到，以前很多他以为必须找专业人员、必须走固定流程的问题，现在可以换一种方式解决。

第二个变化，是信任建立以后，企业开始主动释放更多需求。

一开始，老板只愿意拿一个很小、很具体、试错成本比较低的问题给项目团队。

但在做出一些交付以后，他很快又提出了十几到二十个新的需求。

这个变化比单纯的效率指标更能说明问题。

因为它意味着企业已经从“业务人员要不要试一下AI？”，变成了“业务人员公司还有哪些问题可以这样解决？”第三个变化，是老板对AI的判断开始从“买一个工具”，变成“重新思考公司怎么工作”。

项目实践说明：对这类企业来说，FDE最大的价值未必是帮他少雇一两个人。

真正有价值的是，通过几个具体项目，让老板看到一种新的工作方式，从而改变他后面的战略判断。

尤其是项目团队接触的很多企业，本身正处于业务快速增长、人力跟不上的阶段。

在这个时候，老板如果意识到未来新增业务不一定都要靠增加人力解决，这种认知变化带来的价值，可能远远超过某一个工具本身节省的成本。

项目图示

原案例图示（PDF 第 111 页）

原案例图示（PDF 第 112 页）

原案例图示（PDF 第 114 页）

五、关键落地难点

做这个项目的过程中，有三个挑战让FDE印象最深。

第一个挑战，是现场环境不一致。

项目团队的程序在本地跑得很好，到了客户电脑上就会出现各种报错。

原因也很简单，每一台电脑的环境都不一样。

最开始经常发生这样的情况：FDE发一个安装包，对方说报错；他截图给FDE，FDE修改以后再发一个；结果又出现新的错误。

这些在标准软件工程里可能是很基础的问题，但到了真实企业现场，它就是会实实在在拖慢整个项目。

所以后来项目团队把环境当成了第一现场问题，进去之后先花时间把每台电脑的网络、权限、运行环境摸清楚，尽量提前统一，后面来回返工才少了很多。

第二个挑战，是数据和隐私。

AI要真正发挥作用，就必须接触企业最有价值的资料。

但恰恰是这些资料，老板最不愿意交出去。

所以项目团队换了一种方式，把开发能力和任务规范送到他的环境里，让客户自己的AI在本地完成工作，数据始终不离开企业。

第三个挑战，是老板和员工的时间与配合。

老板要处理业务，产品做好以后需要他测试，他又可能几天都不在公司；员工白天要工作，项目团队又需要调试他们的电脑。

但定制化产品必须有人真正使用，项目团队才能知道哪里不符合需求。

有一段时间，项目团队甚至一直在催老板：“业务人员有时间用一下，至少给企业留一点记录。”后来项目团队开发了一个远程通道，让项目团队的AI可以在后台连接客户电脑上的AI，在不影响员工正常工作的情况下完成一些任务。

很多长任务放到晚上跑，双方都节省了大量沟通和等待时间。

回头看，这三个挑战没有一个直接关于模型，但每一个都能决定项目能不能真正跑起来。

FDE必须进入业务现场，原因就在这里。

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

这些项目进一步说明：FDE不应被定位为一个“AI外包”。

如果只是帮客户开发一个小软件，项目团队一定会陷入和传统外包的比价，而且专业的软件外包公司很可能比项目团队做得更成熟。

FDE真正应该解决的是另外一个问题，就是怎么让AI这种通用能力进入一家具体的企业，并且最终留下来。

第一，从一个非常小、非常具体的问题开始。

不要一上来跟老板讲多Agent协作、Harness或者企业智能体。

老板真正关心的是：“业务人员现在这个问题，业务人员能不能解决？”而且这个问题最好是他正在为之付出时间、成本，甚至正在影响业务的。

把这个问题解决以后，信任自然就会出现。

项目团队在实践中看到的也是这样：很多老板一开始只愿意拿一个点试，做出结果以后，才会把后面的十几个、几十个问题交出来。

第二，不要只讲AI，要现场解决问题。

现在很多企业老板已经听过太多AI概念了。

真正有效的是，把他眼前关心的问题拿出来，让他亲眼看到企业的思考过程。

概念听过以后很容易忘，但一个真实问题被当场解决，老板会立刻知道AI跟自己有什么关系。

第三，要把交付目标从“做一个工具”变成“沉淀企业能力”。

FDE希望企业以后不用每遇到一个问题都来找FDE。

做完一次项目，企业带走的应该是一套自己继续解决问题的方法，一个具体的工具反而不是重点。

这样交付几次以后，企业遇到新问题时，第一反应会从“找人”变成“自己先试”。

第四，FDE要接受一个事实：大量工作并不“AI”。

项目团队可能要修网络，要处理Windows环境，要梳理文件命名，要解决权限，要等老板开会回来，要催员工测试。

这些看起来都不是AI技术，但它们决定了AI到底能不能进入真实业务。

FDE最稀缺的能力，是能不能站在真实业务问题面前，把所有阻碍AI发挥作用的环节一个个拆掉。

“懂多少个模型”反而是次要的。

最后，项目实践表明最理想的FDE，是让客户越来越独立。

有一天企业会发现：以前一个需求出现以后，FDE要去找软件公司、找外包、找顾问；现在这个需求出现以后，FDE团队的数据、工作流和AI能力已经在那里了，FDE可以先自己解决。

到这一步，AI才真正变成了企业自己的能力，而不再只是采购清单上的又一个软件。

七、可复用的交付资产

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

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

来源与作者

Datawhale《FDE案例100》，受访者：Nature张晨曦（通向智流（杭州）科技有限公司创始人）；PDF 第 108-120 页，书内页码 107-119。本文为访谈资料的第三人称整理，不是本站新采访。