FDE 案例 100 文字整理版

前言

AI 开始真正走进企业如果今天把所有企业放在同一张 AI 地图上，我们会看到一幅非常不均匀的图景。有些企业还在思考 AI 能为自己做什么，有些企业的数字化基础仍在建设，有些企业已经开始把大模型、智能体和自动化工作流带进真实业务，甚至尝试规模化地改变原有的工作方式。很难用一个统一的阶段去概括今天的企业 AI 落地。

但在过去一段时间里，当我们真正走进企业、访谈一个个 AI 落地案例之后，有一件事情变得越来越确定：AI 已经开始在真实世界里创造价值。

它往往不会首先表现为一次宏大的“企业 AI 转型”，更多时候，它发生在一个个具体甚至细小的场景里：一个原本需要大量人工处理的流程、一段依赖老师傅经验的知识、一项反复进行的信息整理工作、一次销售跟进、一份报告、一条生产流程，或者一个过去因为成本太高而始终没有被很好解决的问题。这些变化可能并不轰动，却已经开始真正影响企业的效率、成本和工作方式。

这也是我们发起「FDE 案例 100」的原因。

我们希望记录的，并不是 100 个所谓的“AI 落地标准答案”。事实上，今天也不存在这样的标准答案。我们更想记录的是一群先行者正在进行的探索：他们如何发现问题，如何理解业务，如何选择技术，如何在现实条件下做取舍，又如何一点点把 AI 融入到真正的业务现场。有些探索已经取得了明确的效果，有些仍处于验证和迭代之中。它们并不完美，也未必能够被直接复制。但正是这些带着探索痕迹的实践，让我们看见 AI 从技术能力走向产业价值的真实路径。任何一次大的技术变革，都需要这样一批先行者。

在这个过程中，我们也越来越意识到，AI 落地已经不再只是一个技术问题。当 AI 真正进入企业，问题会逐渐从“模型能不能做到”，延伸到“什么问题值得解决”“业务部门如何参与”“数据和知识如何组织”“新的工作流程如何建立”“项目上线之后由谁持续运营”，以及更重要的 —— 企业自身如何在一次次项目中逐渐形成使用 AI、理解 AI 和建设 AI 的能力。这意味着，AI 带来的变化最终会进入组织本身。

而这也是我们理解 FDE 的方式。FDE 并不是简单地来到企业完成一个项目，再把一个系统交付出去。我们更希望它是一种共建关系：FDE 与企业一起发现问题、定义问题、构建方案、验证价值，同时帮助企业把方法、经验与能力逐渐沉淀在组织内部。一次项目的结束，不应该意味着 AI 能力的离开。真正有价值的 AI 落地，是企业在解决一个具体问题的同时，也开始学会如何解决下一个问题。

因此，我们更愿意把 FDE 看作企业 AI 转型过程中的长期共建伙伴：站在技术与业务之间，也站在今天与未来之间，与企业共同完成一段转型的探索过程。

这本案例集，也是 Datawhale 对这个过程的一次阶段性记录。我们希望持续连接真实的产业需求、快速变化的 AI 技术，以及那些愿意走进现场解决问题的 FDE 团队与人才，形成一个开放、可信、长期生长的生态网络，让更多真实需求被看见，让更多实践经验得以流动，也让更多愿意走进产业的人发现机会。

在这里，也想感谢每一位愿意参与这次记录的人。感谢所有接受访谈、愿意分享真实实践的企业、FDE 团队与一线探索者。正是因为大家愿意把真实的过程、经验与思考打开，我们才有机会看到 AI 落地更完整、更具体的面貌。也感谢参与案例征集、访谈、整理、编辑、设计与传播的每一位伙伴，感谢你们一起把这些散落在产业现场的实践，一点点整理成今天这本案例集。

同时，也感谢一路支持 FDE 项目的企业、社区与生态伙伴，以及「得到 AI 学习圈」在案例呈现上带给我们的启发与灵感。这本案例集能够最终呈现在大家面前，离不开每一位参与者的信任、分享与共同投入。

特别感谢某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人、某某人以及所有参与其中，未能一一列出的伙伴。

我们相信，未来真正改变产业的，不只会是更强的模型。还会是无数企业、技术团队与实践者，在一个又一个真实场景中的共同探索。而我们想做的，是把这些探索记录下来。

很多年以后回头看，也许今天这些并不完美的尝试，正是 AI 真正走进产业现场的一个起点。

（本案例集按照 FDE 姓名首字母排序）

2026 年 9 月 6 日

从师徒带教到 AI 辅助培训：FDE 用 AI 破解制造业经验传承难题

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我当时服务的是德国斯图加特一家制造零部件的企业，大概有七八十名员工。企业有多条产线，也有很多不同型号的产品。

这个行业有一个明显的特点，很多生产知识非常细。比如生产不同零部件时，需要调整参数，也会涉及不同金属材料的比例。因为零部件最终面对的使用环境不同，有些可能需要应对强酸环境，有些需要耐磨损，所以不同的材料配比、设备操作和生产经验，会直接影响产品质量。

真正让企业焦虑的，是这些知识并不完全存在于标准文档里，相当一部分经验掌握在老师傅手里。

老师傅知道某个产品应该怎么调、什么情况下参数应该发生变化、设备出现某种状态时应该怎么处理。这些东西很多属于长期实践形成的隐性经验，很难简单靠一份操作手册完整记录下来。

企业最担心的是，如果人走了，经验会不会也跟着人一起走了。

所以我进场之后，没有先问“要用什么模型”，先去看他们到底怎么培养新人。

现在回头看，这一步其实比后面选什么模型更重要。因为企业最开始说的是“我们想把老师傅的经验沉淀下来”，但这句话还不能直接变成一个 AI 项目。

我必须继续往业务里走，直到把它变成一个更具体的问题，新人学习过程中到底缺哪些知识，这些知识在哪里，以及怎样才能让它在真正需要的时候被找到。

Q2在你参与之前，这个问题过去是怎么解决的？

过去主要还是靠“人带人”。

新人进入企业之后，要经历一套比较长的培训和实习过程，老师傅在这个过程中承担了很重要的带教角色。根据我当时了解到的情况，培养一个新人可能需要两三个月甚至更长。

制造业里的很多经验，本来就是在长期实践中形成的，老师傅不仅知道标准答案，还知道什么时候不能机械地照标准答案执行，所以过去依靠师徒制，其实是一种非常自然的知识传递方式。

真正的问题，是企业的业务环境开始变化了。一方面，老师傅自己的生产任务很重，没有足够时间持续带新人；另一方面，一些经验丰富的员工开始接近退休。与此同时，企业又希望把过去依赖个人的经验沉淀成组织能够长期使用的知识。

所以我做的，是先把老师傅最有价值的经验留下来，让那些过去必须反复问老师傅的问题，可以通过另一种方式完成第一次解答；真正复杂、需要判断的问题，再回到老师傅这里。这样，老师傅的时间就不需要一直消耗在重复性的知识传递上。

从这个角度看，我做的事比“传统培训改 AI 培训”更进一步，是在重新分配人在培训流程里的作用。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

整个项目真正花时间的地方，其实在于前后几个环节怎么串起来，把知识库搭出来只是其中一步。

第一步，先进入业务，把技术往后放。

一开始，我原本比较习惯通过访谈了解客户需求，高层、中层、一线员工都会聊。

但实际做项目的时候，我发现一个问题，一线员工不一定愿意花很多时间接受访谈，而且很多日常工作中的细节，他自己也未必能在访谈里完整描述出来。所以后来我调整了方法。

除了访谈，我会直接跟着员工走一遍他每天的工作流程，看他一天具体在做什么、在哪里停下来、哪里需要问别人、哪些问题不断重复出现。

这样得到的问题，比单纯问一句“你有什么痛点”具体得多。

这个项目里，我也是先找到主管，把生产线和新人培训流程梳理出来，然后统计新人最常出现的问题、最容易反复出错的知识，以及哪些内容属于老师傅才能掌握的隐性经验，最后把这些内容整理成一张知识地图。

第二步，把人的经验变成 AI 能够使用的知识。

知识地图有了之后，下一步才真正进入知识处理。

企业本身已经存在一部分知识文档，我先把这些已有材料导入，再通过文档解析、RAG 等方式进行处理。但只有文档还不够，我更重要的一项工作，是把老师傅过去存在脑子里的隐性经验抽象出来，让它能够进入企业的知识体系，最终能够被 AI 理解和检索。

这里很容易出现一个误区，觉得把文档扔进去，AI 能回答问题，知识库就算做完了。我没有按这个标准验收。

前期调研时统计出来的那些高频问题，本身就会成为后面的测试集。比如当时我会看文档解析是否能够达到大约 95%，问题召回片段的准确率是否能够达到 80%以上，在一个最小范围的测试里达到约定标准，我才认为这条技术路径初步跑通。

我觉得这正是 FDE 和单纯做技术开发不太一样的地方，前面发现的问题，最后一定要重新回到这些问题上验证。

第三步，把 AI 放回原来的培训流程。

技术通路跑通以后，项目其实还没有结束。如果只是给员工一个新的 AI 入口，让大家自己去用，很多时候最后是用不起来的。

所以我继续往业务流程里做。当时企业原本就有新人培训环节，我把 AI 知识能力接进了他们实际使用的平台，并进一步设计了一套类似在线课程打卡的培训流程。

新人能够看到自己在规定时间内完成了多少学习内容；带教师傅也能够回到平台查看新人当前的学习进度；每节课程还会设置问答，对学习结果做一次简单验收。也就是说，AI 进入了原来的新人培训流程，没有额外增加一个“聊天机器人”。

第四步，陪着企业把它真正用起来。

上线以后，我还持续调整前端易用性、页面和实际问答效果。这个过程不是一天两天，当时仅陪跑就接近两个月，整个项目如果从立项、调研一直算到最终陪跑，大约经历半年；如果只算真正投入在项目里的时间，大约四个月左右。

所以企业 AI 落地很少是“系统上线=项目结束”。真正的落地，往往发生在上线之后。

员工怎么使用、哪里不习惯、老师傅愿不愿意看、新人能不能看懂，这些问题最后都会反过来要求我继续修改产品。

Q4相比传统方式，使用 AI 后的实际效果如何？

从实际业务变化来看，有几个变化是比较明确的。

首先，过去分散在老师傅个人经验里的知识，开始被系统化整理，企业第一次能够比较完整地知道哪些经验真正不能随着老师傅退休而流失。

其次，老师傅的角色开始发生变化，从重复回答所有问题，逐渐转向关注新人学习进度以及处理更复杂的问题。

第三，培训本身变得更可追踪。以前新人“学到了哪里”“到底掌握了多少”，很大程度依赖带教师傅自己的观察，现在这些进展都能在平台上被清楚地看到和跟踪。

对我来说，这个项目真正的价值，在于企业原本高度依赖个人的经验传承过程，开始变成一套能够沉淀、检索、学习和追踪的组织流程。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目里，我觉得至少有三个挑战值得单独拿出来讲。

第一个挑战，是用户说不清需求，也说不清经验。

最开始我采用访谈，希望通过和不同层级员工交流了解问题。但做下来才意识到，一线员工未必愿意投入很多时间，而且很多隐性的工作习惯很难靠问答完整说出来。

所以我后来减少对纯访谈的依赖，直接跟着员工走他的日常流程。这是一个很小的调整，但对 FDE 来说非常重要。有时候你不能继续追问用户“你需要什么”，得自己去现场看，看他到底怎么工作。

第二个挑战，是技术指标不能由 FDE 自己关起门来定义。

比如文档解析率、召回准确率做到多少算合格，没有一个可以直接套用的行业标准。我的做法是先做一个小范围测试，看看当前条件下大概能达到什么水平，再和客户沟通他们真正需要什么，最后双方共同确定验收标准。所以验收标准本身，也是业务沟通的一部分。

第三个挑战，是技术跑通以后，员工不一定愿意用。

所以后来我花了很多时间调整前端页面、学习流程和易用性。我没有要求新人改变整个工作习惯去适应 AI，尽量把 AI 放进他们已经存在的培训和协作环境里。

我做企业项目时一直比较坚持这一点，如果客户已经有能够解决问题的技术栈、平台或者模型，我会尽可能复用，避免为了展示技术能力把客户已有的东西全部推翻重做。因为站在客户角度看清楚“什么已经能用、什么真正需要改”，本身就是建立信任的过程。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这个项目以后，我更清楚地认识到，FDE 最重要的能力其实不在“知道多少模型”

上。我更愿意把 FDE 理解成一个团队，团队里有人需要真正进入客户现场，判断业务问题；有人要把需求变成能在客户环境里跑起来的东西；还需要更专业的技术人员保证架构、性能和未来的扩展性。

但不管角色怎么分，最后做的都是同一件事，把企业模糊的问题，变成可落地、可验证的 AI 解决方案，再把它真正推进到企业业务流程里。如果让我把这次项目里的经验再压缩一下，我会总结成四点。

第一，不要从“企业想做什么 AI”开始，要从“企业每天到底怎么工作”开始。

用户自己有明确需求当然很好，但即使没有明确需求，只要他的业务 SOP 足够清晰，我也可以沿着流程一个环节一个环节去判断哪里适合 AI。所以对企业来说，在做 AI 之前，把自己的核心业务流程先梳理清楚，本身就非常重要。

第二，不要急着推翻客户已有的东西。

我做前期调研时，会先看企业现在用了什么技术栈、什么平台、什么模型，哪些东西能够继续复用。如果已有能力能够解决问题，就尽可能沿用。FDE 要做的，是找到客户成本和业务效果之间更合适的方案，不必去证明自己的技术方案最复杂。

第三，前期发现的问题，要直接变成后面的测试标准。

这个案例里，新人高频问题在访谈结束后没有停留在报告里，直接变成了知识库测试集。我认为这是非常关键的一步。只有这样，AI 最终验证的才是“能不能解决真实业务问题”，单纯的技术指标漂不漂亮退居其次。

第四，AI 一定要进入流程，不能停在 Demo 里。

知识库能回答问题，只能证明技术通路跑通了。新人真的愿意学、带教师傅真的愿意看、学习结果能够被验收，这才说明它开始进入业务。所以我最后花了接近两个月陪跑。很多企业 AI 项目真正困难的部分，其实在最后这一公里，怎么让 AI 和企业原来的业务流程真正连接起来。

这就是我对 FDE 这个角色的理解。AI 能力还会继续变强，做 AI 应用的门槛也会越来越低，但企业自身的流程、组织和真实业务环境不会因此自动变得清晰。FDE 真正要解决的，就是 AI 与企业之间最后这一公里的问题。未来技术会变、模型会变、服务形式也会变，但这种“深入现场、发现问题、验证方案、进入流程”的能力，我认为仍然会长期存在。

从人工审材料到自动化办件：FDE 用 AI 提升车管所网办效率

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

这个案例有一点特殊，一开始客户并没有提出一个“AI 需求”。我进入车管所，最早只是为了接一个系统运维项目。

当时原来的系统承建商已经倒闭，留下来的源代码并不完整，文档也缺失，而且整个系统涉及多种技术，有\.NET 客户端、安卓端显示程序，也有 Web 管理和调度系统。很多公司评估以后都不愿意接，因为这不是找一个工程师简单维护一下就能解决的问题，需要真正把遗留系统扎进去看懂。我把这个项目接了下来。

但现在回过头来看，运维只是我进入业务现场的入口，真正有价值的需求，是进入现场以后才慢慢发现的。在驻场过程中，我开始观察车管所的网办业务。

浙江的政务服务数字化程度已经比较高，很多事情群众在线上就可以办理，甚至一次都不用跑。但我发现一个很有意思的问题，前台已经数字化了，后台却还有大量工作依赖人工。

群众在线提交业务后，会上传各种材料，比如身份证、营业执照、合同、发票等。这些材料基本都是图片，而且拍摄质量五花八门。

工作人员要一张一张点开，再用肉眼判断材料对不对、信息是否完整，然后继续进行后续审核和录入。这个流程一直这么运行，所以大家甚至已经习惯了。但我在现场看下来，问题其实很明显，可以总结成三个特征，慢、累、量上不去。

第一是慢。大量图片都需要人工打开、查看、核对，再把相关信息录入系统。单件业务从头到尾审核下来，大概要 15 分钟。

第二是累。这种工作谈不上复杂，只是高度重复。工作人员每天长时间盯着屏幕看照片，有人直接反馈“眼睛都受不了”。

第三是业务量上不去。车管所的网办业务背后还有一个比较特殊的业务关系。部分服务由驻点快递企业参与，车管所完成审核和制证以后，由快递公司负责后续打包和寄递。

快递企业需要投入人员驻点，如果业务量不够、人工成本又高，这项服务本身就会面临经营压力。

所以这件事情表面上看，是“工作人员看图片太累”，但往后拆，其实牵扯的是整个业务链条。审核效率决定办件能力，办件能力影响群众服务，也影响合作方的运营成本和整个服务模式能不能持续。

我在现场待得越久，越清楚一件事，FDE 不能只等着客户把需求写成一句“我要一个 AI 审核系统”再来做。很多时候，真正的需求并不会自己跳出来。你得先进入现场，看业务是怎么跑的，看人在做什么，看哪个环节每天重复发生，再去判断这里有没有值得被 AI 重新改造的地方。

Q2在你参与之前，这个问题过去是怎么解决的？

其实没有特别的解决方案，就是靠人。

群众把材料上传以后，工作人员打开图片，用肉眼审核，再人工处理后面的业务。这个流程已经运行了很长时间，对车管所来说，它甚至不被认为是一个特别需要解决的问题。这点我觉得很重要。

我们今天回头看，会觉得“这么明显的重复劳动，为什么不自动化？”但站在当时业务部门的角度，它是可以运行的。人员在那里，流程已经形成，大家知道每天该怎么做，虽然慢一点、累一点，但没有影响到系统基本运转。

所以我第一次跟客户提出，可以用视觉技术替代一部分人工审核的时候，对方其实并没有马上接受。他们的第一反应是，现在这样不也能干吗，为什么还要再花钱上一套新东西。另外，他们对 AI 能不能真的达到业务要求也没有把握，哪怕市面上已经有一些现成能力，一方面价格不低，另一方面谁也不敢保证拿过来就能解决车管所真实场景里的问题。

所以从传统方式走向 AI，原来的方式并没有突然失效。真正的变化来自业务条件。当时经济环境发生变化，驻点服务企业也开始面临经营压力，希望减少人员投入，同时把业务量做上去。原来“不够痛”的效率问题，一下子变得现实起来。这时候，我们前期准备的方案才真正有了落地机会。

所以我后来做项目有一个很深的感受，很多 AI 需求一直都在，只是还没有痛到需要改变。FDE 要做的，是提前看见这个问题，在业务真正需要改变的时候，已经有一个可以验证的方案放在那里，不去强行制造需求。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

整个项目没有先设计出一套完整方案，再一次性上线。实际上，它经历了一个很长的观察、验证、建立信任、立项、迭代的过程。

第一步，是先把问题看清楚，不急着选模型。

我没有一开始就跟客户讲“我们要上 AI”。我先把业务拆开来看，人工到底在干什么。拆完以后会发现，整个审核过程本质上主要有几类工作，看图片、识别材料类型、读取关键信息、判断材料是否符合要求、填写相关数据，以及在不同系统之间搬运信息。

这样一拆，技术路径其实就自然出来了。需要“看”的部分，用机器视觉、OCR 和相关识别算法；需要从合同等复杂文本中提取信息的部分，后来逐步引入大模型；需要重复填写和系统间流转的部分，则通过 RPA 完成。

所以我们最终围绕的是一个目标，尽可能让机器替代人工去完成重复性的“看、读、

填、搬”。

第二步，是用真实业务数据一点点把能力磨出来。

车管所材料审核最大的特点，是数据非常不标准。我们最后做了大约 9 类图像材料，包括合同、发票、营业执照、身份证复印件等。每一种材料都要重新收集真实素材、标注、训练，再上线观察效果。这里跟实验室环境完全不一样。

比如身份证国徽面，正常情况下应该拍完整身份证，但有些群众上传的照片可能只拍了一个国徽。合同更麻烦，机动车抵押登记涉及大量金融机构，每家公司的格式合同都不一样，有些为了把内容压缩在一页纸上，字体非常小，还有很多材料本身就是复印件，再经过拍照上传以后，图像质量进一步下降。

所以训练不可能一次就结束，要不断把真实业务中的异常样本拿回来，补充正样本、负样本，再继续优化。整个研发和迭代周期前后大概持续了半年，识别率也是这样一点点从 70%多提升到 98%左右。

第三步，是把 AI 嵌回原来的业务流程，不做孤立工具。

这一点是我觉得非常关键的。如果只是做一个识别 Demo，识别完告诉工作人员“这张图片是什么”，价值其实很有限。真正要解决的，是识别之后业务能不能继续往下跑。

所以我们把识别、审核、填单以及后续系统流转整个串起来。车管所原有业务涉及不同 Web 系统，审核通过之后，数据还需要进入公安部统一的业务系统。我们没有要求工作人员重新学习一套完全独立的工作方式，而是通过 RPA 把不同系统联动起来，实现了数据搬运。

最终，大部分正常业务可以自动完成，工作人员主要看结果和报表，只有异常情况才需要人工介入核验。换句话说，我们把 AI 直接变成了原业务流程中的一个执行环节，工作人员不需要再面对一个独立工具。

第四步，是先用结果建立信任，再推动正式立项。

政务项目还有一个很现实的问题，不是技术做出来就能上线。最开始客户对 AI 效果没有把握，项目要正式启动，还涉及报告、立项、预算以及技术可行性论证。所以我们前期承担了一部分售前成本，先选取部分场景做起来。

与其让客户相信我们的 PPT，不如让他先看到真实效果。与此同时，我们原来的运维服务也在持续推进，通过一次次交付，客户知道我们不是“画饼”，技术能力和服务能力都逐渐得到认可。等到 AI 方案本身也跑出了一定效果，再叠加人员减少、业务效率压力以及政府创新需求等条件，项目才真正获得立项机会。

所以在这个项目里，信任是在一次次交互结果里建立起来的，光靠认识远远不够。FDE 进入一个组织以后，第一个项目未必就是最终最有价值的项目。有时候先从一个小切口进去，把第一件事情做好，才有机会真正看见后面的需求。

Q4相比传统方式，使用 AI 后的实际效果如何？

先看效率。原来一单业务全流程审核大概需要 15 分钟，现在基本可以缩短到三五分钟。

随着审核效率提高，日均办件量也从原来的约七八百件，提高到 1100 件左右。

这里需要说明的是，AI 并没有凭空创造这些需求。很多群众原本就有办理需求，只是过去受制于审核产能，业务处理不过来。AI 把原来卡在人工审核环节里的产能释放出来以后，这部分需求才真正被承接。

但我觉得，比数字更重要的是人的工作发生了变化。原来工作人员需要把大量时间花在打开图片、检查材料、填写信息这些重复劳动上。自动化以后，这部分工作减少了，他们可以把时间用在群众咨询、新增业务以及更需要人工判断和沟通的事情上。

比如群众来到大厅以后有很多问题需要解释，以前后台审核占掉大量精力，现在工作人员可以把更多时间放到服务群众上。所以这件事的本质，是重新分配人的时间，让一个人审核得更快只是表面收益。

对于参与驻点服务的合作方来说，变化同样明显。在人员不增加甚至减少的情况下，整体办件量仍然能够保持并略有增长，这让原来因为人工成本过高而承压的服务模式有了更好的经营空间。

而对车管所来说，项目最终顺利通过验收，后续又持续有新的业务交给我们。后来双方还共同成立了 AI 创新实验室，我们也继续派人员驻点，共同研发新的应用。在我看来，这可能比某一个技术指标更能说明项目到底有没有真正创造价值。一个 AI 项目真正成功的标志，是验收通过之后，客户还愿意继续和你做第二个、第三个项目。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

如果让我总结这个项目最难的地方，最难的是组织和规则，算法反而排在后面。

第一个挑战，是材料数据太不标准，识别率上不去。

车管所的材料不像实验室数据集那么干净，身份证、合同、发票这些常见材料在实际上传时会出现各种意想不到的形态。这些问题相对明确，但解决起来并不轻松。识别率不够，我们就继续收集样本；负样本不足，就补负样本；参数不合适，就继续优化。这些问题虽然麻烦，但基本都有工程上的解决路径，真正难的在后面。

第二个挑战，是 AI 把过去人工审核里的“放宽”暴露了出来。

自动审核跑起来以后，我们发现有些业务过去人工审核时存在一定程度的“放宽”。这时候问题从“模型能不能识别出来”，变成了“识别出来以后到底应该怎么办”。

如果完全按照技术标准严格执行，可能影响原有业务量和合作关系；如果继续保持过去的宽松尺度，又可能失去自动审核的意义。这种事情技术团队自己不能拍板。我们的做法是把问题和数据客观呈现给甲方，哪些材料存在问题，按照不同审核尺度每天能处理多少业务，业务量会发生什么变化，然后让甲方结合实际经营和管理要求做最终决策。

经过一段时间运行，大家有了真实业务数据，再逐渐找到效率、合规和业务量之间的平衡点。这里 FDE 需要非常清楚自己的边界。我们的职责是把技术能力做出来，把问题暴露出来，把不同选择可能产生的结果说明白；但涉及业务利益和管理规则的最终决策，必须交给业务负责人。

第三个挑战，是组织协同。

一个项目刚进去的时候，你可能只跟一个部门、一个负责人打交道。但真正开始落地以后，会涉及不同部门、不同角色甚至外部合作伙伴。信息化、数字化、智能化一旦真正改变流程，就一定可能影响某些人的原有工作和利益。

所以 FDE 除了做技术，还必须会沟通、协调、项目管理，甚至要会“算利益账”。你要让不同角色看到，这个变化对他意味着什么，谁会获得收益，谁的工作会改变，出现冲突以后谁有最终决策权。这些问题处理不好，再好的模型也很难真正进入生产环境。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这个项目，我心里渐渐笃定了一件事。AI 应用一定是从业务内部生长出来的，外部强行叠加进去的东西往往留不下来。

现在我去很多企业交流，大家都会说自己有“AI 焦虑”。老板知道 AI 很重要，信息部门也知道 AI 很重要，但你问“你具体想解决什么问题”，很多人反而说不清楚。这时候如果 FDE 直接开始讲 Agent、RAG、大模型，意义并不大。

我现在更习惯先问企业一个问题，你能不能先列出企业经营过程中最重要的十个问题。

如果十个问题能够列出来，我们再一起判断，哪些问题可以通过数字化解决，哪些可以通过智能化解决，哪些问题现在值得投入，哪些问题即使 AI 能做，投入产出比也不成立。这才是 FDE 真正应该做的第一步。所以我认为，FDE 进入企业，首先应该更像一个顾问，其次才是一个开发工程师。

第一，先找到真问题，再讨论 AI。

不要从“我会什么技术”出发找应用，要从业务每天真实发生的问题出发。一个问题是不是值得做，我会看几个很现实的指标，它是不是高频发生，是不是影响效率、收入、

成本或者服务质量，业务部门自己有没有解决意愿，有没有预算。只有这些条件成立，AI 项目才有真正落地的基础。

第二，从一个小切口进入，别一上来就做“大而全”。

我进入车管所的入口，甚至只是一个遗留系统运维项目。但这个小项目让我进入了现场，也让我真正看见业务怎么运行。所以不要低估第一个小项目的价值。小切口的意义，是建立信任，也是获得观察业务的机会。第一件事情做好以后，你才能逐渐进入更核心的流程，看到更多原来在会议室里看不到的问题。

第三，FDE 必须长期靠近现场。

很多需求不是访谈一次就能问出来的。这个案例里的材料审核问题，就是我在运维过程中一点点观察出来的。客户一开始甚至不觉得这是一个特别需要解决的问题。所以我们现在也会把人员派驻到客户现场，因为只有靠近现场，你才能知道工作人员每天到底在做什么，什么事情最耗时间，哪些流程大家已经习以为常，却可能正是最值得 AI 改造的地方。

第四，不要只把 AI 做成一个工具，要把它嵌进业务流程。

真正的业务价值，在于识别之后数据能不能自动流转，流程能不能继续往下执行，异常情况谁来处理，原来的工作人员要不要多做一步操作。如果 AI 只是多出来一个页面，最后还需要人工复制结果、粘贴到另一个系统里，那它带来的价值就会大打折扣。AI 真正落地，是它成为业务流程的一部分，旁边不用再单独多一个 AI 工具。

第五，组织能力往往比技术能力更决定项目成败。

技术能力当然重要。没有基本技术能力，这个事情根本接不下来。但到了真实项目里，技术越来越像一项基本技能。真正拉开差距的，是沟通、管理、协调、需求分析以及理解业务的综合能力。

因为 FDE 面对的，从来都超出模型本身，背后还有客户、管理者、一线工作人员、合作伙伴、预算、流程、利益关系以及组织内部的决策机制。

一个 FDE 真正要搭建的，其实是业务与技术之间的桥梁。技术只是桥的一端，另一端是业务问题、组织关系和真实价值。只有两边真正接起来，AI 才算完成了从“技术能力”到“业务能力”的最后一步。

从案头工作到智能协作：FDE 用 AI 优化诉讼律师的案件处理能力

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我们服务的对象是诉讼律师团队，主要处理商事合同纠纷、公司股权争议等复杂案件。

一个律师接到案件后，需要经历一个完整的长流程：理解客户需求、阅读大量案件材料、梳理事实关系、寻找法律依据、设计诉讼策略，最终形成各种法律文书。

表面上看，这是一个知识密集型行业。但深入观察后我发现，律师每天有大量时间消耗在案头工作上。

首先，案件材料规模庞大且高度非结构化。一个典型的商事诉讼案件可能包含合同、聊天记录、财务凭证、证据文件等数十种材料类型，总页数动辄上千页。律师需要逐一阅读、标注、归类，仅材料整理就可能耗费 3 到 5 个工作日。遇到涉及十几个当事人的复杂案件，光是梳理人物关系就需要两三天。

其次，法律语言的转化门槛高。当事人的原始描述往往是日常口语，律师需要将其提炼为具有法律意义的要件事实，再匹配相应的请求权基础。这个转化过程完全依赖律师个人的法律功底，新人律师和资深律师的效率差距可达 3 到 5 倍。

第三，案件信息需要持续维护。诉讼周期通常持续数月甚至一年以上，期间新的证据、

争议点不断出现。律师必须持续维护对案件的完整认知，每次重新进入案件都要花费大量时间恢复记忆，回顾之前的分析脉络。

我逐渐意识到，律师的产能瓶颈不在专业判断，而在信息处理的效率。他们既是决策者，也是被案头工作困住的执行者。想要提升律师的整体办案能力，不能只让 AI 回答一个孤立的法律问题，需要让 AI 进入律师完整的工作流程，成为持续协作的伙伴。

Q2在你参与之前，这个问题过去是怎么解决的？

过去律师行业已经有一些工具。

法律数据库（如北大法宝、威科先行）可以查询法条和判例，文档管理系统帮助律师归档文件，也有一些早期的法律问答工具尝试辅助生成简单文本。

但这些工具解决的只是“查”和“生成”两个单点动作。真实案件是持续变化的，律师需要反复回到同一个案件，补充分析、更新判断。传统法律数据库的设计逻辑是一次性查询，这与律师的实际工作节奏完全脱节。

过去的标准工作方式是这样的：律师收到案件材料后，人工阅读和整理；把自然语言描述转换成法律专业语言；通过法律数据库寻找相关依据；结合自身经验形成判断；最后输出报告、诉讼材料或策略建议。整个过程大量依赖律师个人的大脑和经验。

过去十年，律所也尝试过引入更多数字化工具，但落地效果普遍不理想。

原因有两个：第一，每个工具只解决一个单点问题，律师需要在五六个系统之间切换，案件上下文被割裂，无法形成连贯的工作流；第二，这些工具的使用门槛与律师自然的工作方式存在断层，律师需要学习特定的检索语法或操作逻辑，增加了额外负担。

最终，大部分工具沦为查法条的辅助手段，未能真正融入案件处理的完整流程。

传统方案的根本缺陷，是缺少一个能够同时理解技术和业务现场的角色，把律师真正需要的能力翻译成可落地的系统。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

第一步，是进入业务现场理解用户。

项目启动后，我没有直接设计功能，而是先进入了律师的真实工作环境。我们对律所诉讼团队的观察是一直持续进行的，因为诉讼是一件很复杂的事情，我们会从现场带回已经脱敏的各类资料回来研究。另外也会跟合伙人律师进行深度访谈调研，这样的调研频率非常高，我们从调研中知道他们想要什么，想在哪些地方省时间，哪些地方即使省了时间他们也不放心。这对我们的系统设计会很有指导意义，哪些留给人来决策，哪些让 AI 直接干好交付，都围绕着真实的需求进行。

我们从早上九点律师打开电脑开始，观察他们如何接收客户邮件、如何翻阅纸质案卷、

如何在多个系统之间切换查找信息。我旁听了他们的案件讨论会，记录了合伙人如何拆解一个看似简单的合同纠纷，他们讨论的焦点不只在于法条本身，更在于如何从微信聊天记录中判断当事人的真实意思表示。

我会和律师深入沟通，追问一个案件从开始到结束到底经历哪些步骤，每一步需要什么交付物，这些交付物最终给谁看，什么样的结果才是真正可用的。

这背后我一直把握一个原则：“交付价值”。AI 需要生成的是一个律师能够直接使用、能够交付给客户、法院或其他专业人员的结果。

第二步，是重新拆解案件流程。

我们没有改变律师原有工作方式，而是在原流程中寻找 AI 能够嵌入的位置。以案件前期准备为例：以前律师需要人工通读上千页材料后手动整理案件概要，这一步 AI 可以辅助完成；以前律师需要人工将当事人的口语描述转换为法律语言再进行检索，这一步 AI 可以辅助完成；以前律师需要手动梳理证据关系、人物关系和法律关系，这一步 AI 也可以辅助梳理。通过这样比较细致的梳理，最终我们形成了 7 个标准模块和高质量的法律思维，让重复但是高价值工作可以自动化跑起来。

第三步，是设计 AI 和人的协作方式。

在技术方案上，我们采用了大模型与专业系统分工协作的架构。大模型负责自然语言理解、文本摘要和初步法律推理，它擅长从非结构化材料中提取关键信息，理解律师用自然语言表达的复杂需求。专业系统负责案件知识图谱的管理、法律条文的结构化检索和判例的精确匹配，确保法律引用的准确性和可追溯性。两者通过统一的案件工作空间整合，律师感知到的是一体化的协作体验。

在我们的设计中，AI 负责大量信息处理、分析整理和重复性工作，专业系统承载案件上下文和知识流程，律师负责最终判断、策略选择和专业责任。

我们希望达到的状态是，律师不需要学习复杂的 AI 技巧或提示词工程，他只需要用自己的专业语言表达需求。比如说“基于这些案件材料，帮我分析一下下一步诉讼策略”，“帮我整理一份证据清单”，“帮我形成一份给客户看的报告”，AI 负责完成背后的工作。

第四步，是根据现场反馈持续调整。

我们最初设计的入口是一个智能对话框，律师登录后可以直接向 AI 提问。但在现场观察了一段时间后，一个关键问题浮现：律师每次提问前，都需要向 AI 重新描述案件背景。

一个案件的信息量巨大，律师不可能在每次对话中都完整复述。对话式交互实际上增加了律师的负担。

于是我们调整了设计：将产品入口从聊天窗口改为案件工作台。律师先上传案件材料，系统自动构建案件知识图谱，AI 在完整理解案件上下文的基础上再与律师交互。律师不需要每次解释背景，只需要用专业语言提出具体需求。这个调整让律师的使用门槛明显降低，也让他们更快接受了 AI 的介入。

Q4相比传统方式，使用 AI 后的实际效果如何？

AI 带来的变化首先体现在效率数据上。

有一个案件涉及 14 个被告，按照过去的方式，一个被告对应的请求权基础分析需要 2 到 3 小时，全部整理完成需要 2 到 3 天。在 AI 辅助下，律师把案件材料交给系统，一个晚上就完成了原本需要几天的工作。

还有一个案例让我印象很深。一位律师临时接到案件，距离开庭只有 3 天，但案件材料超过 100 万字。如果完全依靠人工阅读，很可能到开庭前仍无法充分理解案件全貌。通过 AI 辅助，他在一天内完成了案件整体梳理，包括人物关系、法律关系和案件脉络，并进一步制定了开庭策略。材料整理效率相比纯人工方式提升了约 70%。

但效率数据只是表层结果，更重要的变化发生在流程层面。

过去，律师大量时间消耗在执行工作上：阅读材料、整理信息、检索法条。现在，AI 帮助律师完成这些基础工作，让律师能够把精力投入到更高价值的部分：与客户深入沟通、判断案件方向、制定策略、做最终专业决策。律师的角色从执行者向决策者转移。

长期来看，更深层的价值在于让专业能力变得可复制。过去，一个优秀律师的个人经验很难复制给团队，不同律师的经验差异导致交付质量不稳定。现在，通过 AI 系统，优秀律师的专业方法可以被工程化沉淀，让更多律师获得稳定的辅助能力。这是 FDE 工作真正的意义，既提升了单个项目的效率，又让专业能力变得可复用、可规模化。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

第一个挑战，是隐性经验的结构化。

法律行业的难点超越了知识本身。很多时候，关键在于律师如何思考：什么样的事实需要关注？如何把普通人的描述转换成法律语言？哪些法律依据真正匹配？不同证据之间如何形成逻辑关系？这些都是律师多年实践形成的隐性经验。

我们的做法是，投入大量时间和优秀律师一起工作，观察他们的思考过程，拆解他们做判断时的决策逻辑。具体来说，我们梳理了律师在案件分析中常用的思维框架，比如请求权基础分析的三层四步法、证据链构建的逻辑规则，将这些框架转化为系统可以执行的流程节点。这让 AI 能够按照律师的专业思考方式组织信息，超越了单纯的信息输出。

第二个挑战，是产品形态的定义。

很多 AI 产品的形态是一个聊天窗口，但这个形态对法律案件场景并不适用。一个案件更像一个长期项目，需要持续承载大量材料、过程记录和变化中的信息，一次对话根本装不下。

前面提到我们把产品入口从对话框改成了案件工作台，背后有一个关键的设计原则：让用户先建案，再交互。所有分析结果、策略建议、文书草稿都沉淀在案件空间里，形成可追溯的工作记录。律师不需要每次重新解释背景，AI 也不需要反复重建理解。这个设计让 AI 从一次性工具变成了持续陪伴案件全过程的协作系统。

最后一个是用户习惯的转变。

最开始很多律师进入产品，会习惯性地找输入框，想问“我要在哪里输入问题”。因为大家已经习惯了聊天式 AI。但实际使用后，他们发现：如果 AI 已经理解案件背景，自己不需要不断描述问题，效率反而更高。

我们的应对方式是，不强迫用户改变习惯，在用户第一次使用时就引导他先上传材料，让 AI 展示理解了案件背景之后能提供的价值。当律师看到 AI 自动生成的案件概要、自动梳理的人物关系图时，他们自然理解了先建案件再交互的逻辑。这个过程中，我们发现让用户亲眼看到价值，比任何解释都有效。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

第一，从业务问题出发，用业务语言定义需求。

很多团队开始做 AI 时，会先问“我们有什么模型”“我们能调用什么能力”。但真正应该问的是：“谁会使用它”“他为什么需要它”“他的真实工作流程是什么”。不了解业务，就无法判断什么问题值得解决。不了解技术，就无法找到合适的方法。在这个项目中，如果我们一开始就从模型能力出发，可能会做出一个法律知识问答工具，但那只是解决了律师工作中极小的一环，不会真正改变律师的工作方式。

第二，进入现场，与行业专家共同定义问题。

FDE 一定要进入现场。不能通过想象理解用户，必须真正观察用户怎么工作。我们与律师进行深度协同，观察他们工作状态的那段时间，会发现本来我们想象的，并不是真实被需要的。更重要的是，要和行业专家一起工作，找到真正懂业务的人。当自己不了解一个行业时，没有资格替行业定义问题。这个项目中，优秀律师的思维框架是 AI 系统设计的核心输入，没有他们的深度参与，系统无法做到真正有用。

第三，关注落地细节胜过关注模型能力。

AI 项目成功的关键，除了技术效果之外，还有更多维度。用户是否愿意使用？流程是否自然？成本是否能够接受？结果是否真正能够交付？这些问题比模型能力本身更加重要。

FDE 的价值在于连接业务、技术和用户，让 AI 真正进入企业流程并产生价值。AI 只是手段，改变工作方式才是目的。

我认为 FDE 不能每接一个项目就重新定制一次。真正有价值的 FDE，需要在一次次业务落地过程中，把经验抽象成可复用的方法、模块和能力，让下一个项目更加高效。这也是 AI 时代 FDE 能够规模化发展的关键。

从人工研判到智能调度：FDE 用 AI 重构城市规划研判流程

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

城市规划这个行业本身比较特殊。规划设计不是拿到一张表、做几个分析、生成一份报告这么简单，它背后有非常复杂的专业分工。

比如要规划一个方舱医院，首先是总体规划部门判断大概应该落在哪个片区；再往下，要看这个地方有哪些规划约束和规则；真正落到具体地块时，还要进一步考虑道路、水务、市政、公共服务、产业等一系列因素。

所以我们真正要打交道的，有大约 10 个部门。

更复杂的是，这个项目里不仅有普通的业务数据，还有空间数据。

以前我们做很多政务、电商或者其他企业项目，主要处理的是二维业务数据，也就是这个东西叫什么、属性是什么、参数是多少。但城市规划多了一层空间关系。一块工业用地，不仅要知道它的业务属性，还要知道它具体落在地图上的哪个坐标、和周围哪些道路或设施发生关系。

除此之外，每个部门还有自己的专业工具、业务语义、数据规则和工作流。

所以我后来总结，这个场景真正的难点，是把业务、数据、空间、工具这四件事情连起来。

而且最后还有第五件事，就是人。

因为 10 个部门的人工作方式不一样，对同一个指标的理解也可能不一样。你必须把他们真正使用的业务语言、计算规则和工作流程理解清楚，否则 AI 生成出来的东西看起来很专业，真正的规划师一看就知道不对。

为什么这个问题值得做？

因为城市规划本身正在发生变化。过去城市快速扩张的时候，很多规划是在增量空间里做选择；现在更多是在已有城市空间和存量地块里找最优解。规划做得越来越精细，决策涉及的约束也在变多。

而规划师原来的工作流程又非常重。

领导可能只说一句：“帮我看看识别下 xx 区域的潜力用地有哪些？”下面的人就要开始查资料、调数据、做空间分析、跑工具、讨论，最后才能形成报告。

所以我们最开始看到的机会，是能不能先把规划师每天反复做、规则相对明确、数据能够追溯的那部分工作接下来，让人把时间留给真正需要判断和创新的事情。

这也是我后来判断一个场景值不值得用 AI 的一个基本标准：它是不是重复发生？重复成本是不是足够高？工作流能不能定义？背后的事实和数据能不能追溯？涉及的专业工具能不能被调用？

如果这些条件都不存在，只是为了“AI First”硬找一个场景，我觉得没有必要。

Q2在你参与之前，这个问题过去是怎么解决的？

其实规划设计院原来的数字化程度并不低。他们不缺软件，使用的专业软件反而非常复杂。规划师本身也是典型的高数字素养人群。

过去接到一个规划任务后，规划师通常先查大量资料，再进入 GIS 类专业工具，叠加不同图层、运行脚本、做空间计算和标注，然后根据结果形成自己部门的判断。

如果最后是一份综合规划报告，还需要把多个部门的分析再汇总起来。

一个人的单项分析，过去可能需要一个小时左右；一份跨部门的完整报告，专业人员通常也需要 3—5 天，有时候接近一周。

这个时间不能说明他们效率低，真正的原因是城市规划对精度要求非常高。

一条道路画在哪里、一个地块碰没碰到历史文化保护线、一个区域的污水承载能力够不够，这些都不能随便回答。规划一旦出错，后续可能影响真实建设，所以很多结果必须反复核对、修改和讨论。

比如做选址。系统可能先筛出 20 块候选地块，但最后从 20 块里面挑出真正适合的 10 块，过去往往还需要不同部门开几轮会，结合各种专业指标继续判断。

所以传统方式其实有它存在的合理性：专业人员掌握规则，专业工具保证计算精度，人的经验负责最终判断。

问题是随着需要考虑的数据、规则和部门不断增多，这套流程也越发沉重。大量专业人员的时间被消耗在查资料、找规则、切换工具、重复计算、整理报告这些事情上。

这也说明，规划院的数字化工具其实一直在，只是它们解决的是单个环节的计算精度，没有一个角色把业务、数据、空间和工具真正连接起来，于是跨部门、跨工具的流程依旧靠人来串联。

因此我们做 AI 改造的时候，没打算把传统流程推翻。我的思路反而是，原来正确的东西尽量留下，把机器更擅长的部分接过去。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

这个项目对我影响比较大的一个地方，是让我慢慢想清楚了一件事，FDE 要先进入现场，再决定到底应该用什么。

第一步，先把自己逼成“半个规划师”。

城市规划这个行业很专业。刚进去的时候，他们有很多专业册子，非常厚。很多术语如果你不知道，根本没办法跟业务人员继续聊。

比如对方问你“候选地块是什么意思”“潜力用地分析是什么意思”，如果连这些基础业务概念都答不上来，后面其实很难建立信任。

所以我当时给自己的要求是，先把自己变成他们中的一员。我不需要真的达到规划师的专业水平，但至少要知道他们每天在干什么，为什么这么做，一个指标到底代表什么，一种空间计算为什么这么算。

我们会到不同部门去聊，把他们数值的意义、空间计算方式、业务指标、工作流程一点点搞清楚。

这一步看起来不像“做 AI”，但我觉得恰恰是 FDE 最核心的工作。因为只有理解业务，你才知道什么应该交给模型，什么应该交给专业工具，什么必须留给人。

第二步，先不做本市，先把问题缩到足够小。

如果一开始就把全市的数据、所有部门、所有第三方系统、所有业务规则全部接进来，项目很容易陷入一个永远做不完的数据工程。

所以我们后来主动收敛。从整个市，缩到一个区，再缩到类似米市巷这样的具体单元，然后只挑两条明确的业务流验证。

这个决策后来我觉得非常重要，场景足够小，数据才有可能搞干净；数据搞干净，结果才可能足够精准；结果足够精准，业务人员才愿意相信。

所以一期我们没有把所有第三方系统和数据中台全部接进来，只让参与试点的部门先筛选真正需要的数据，把这一小块场景的数据治理好。

第三步，把“数据、知识、报告”三个底座先做扎实。

我们当时为什么敢说 20 分钟生成的报告是“可推敲”的？主要靠的是底下三件事。

第一是数据。报告里的关键数据尽量来自规划院提供的真实数据，并通过专业计算得到，不让模型自己猜。

第二是知识。我们把相关规划规则、专业文档等知识整理出来，通过检索增强的方式让 AI 能够找到依据。比如一个写字楼为什么不能建在某个位置，可能是碰到了历史文化保护线。过去规划师要去大量 PDF 里找相关规定，现在可以更快定位到对应规则。

第三是报告模板。不同部门原来都有自己的报告习惯，我们把各部门模板以及行业里的模板拿过来，最后归纳出一个相对通用的输出结构。

所以最后 AI 是在真实数据、专业规则和固定报告结构里工作，不再凭空写作。

第四步，让 AI 调度专业工具，把计算留给工具。

这个也是我们后面非常重要的一个判断。很多规划计算其实有明确规则。既然有专业 GIS 工具能够精准计算，就没有必要让大模型自己算。

所以我们的分工慢慢清晰起来：模型负责理解和分析，专业工具负责事实和计算，人负责最终决策。

AI 更像一个调度者。比如规划师提出一个选址任务后，AI 理解他的意图，再调用对应的数据和专业工具完成分析，把计算结果返回出来。

对于高频、规则明确的任务，我们更倾向于把它固化成工作流；对于城市研判、潜力用地分析这种长尾、开放性更强的问题，再交给 Agent 处理。

第五步，产品要顺着原来的工作习惯长出来。

我们没有把所有东西都变成一个聊天框。因为规划师真正工作的中心是地图。

所以最后的交互仍然保留了他们熟悉的方式。左边是筛选条件和专业工具，中间是地图，右边才是 Copilot。AI 调用工具或者完成分析后，结果会直接回显到地图上。

这件事情我后来觉得很重要。做 AI 产品很容易陷入一个误区：既然有 Agent，就把所有功能都塞进一个输入框。但 FDE 要考虑的是用户原来怎么工作。

地图才是规划师真正的工作台，AI 就应该围绕地图服务，让规划师继续按原来的方式工作，不必为了 AI 重新学一套工作方式。

Q4相比传统方式，使用 AI 后的实际效果如何？

变化最先反映在时间上。

过去一份跨多个部门的完整规划报告，通常需要 3—5 天，有时接近一周。现在在已经跑通的试点流程里，大约 10—20 分钟就可以形成一份能够继续推敲和交付的报告。

如果只看单个部门，过去一个小时左右才能完成的一些分析和表格，现在大约 5—10 分钟就可以完成。

一期涉及大约 10 个部门，目前大概有 20—30 名专员在使用。

但我后来慢慢意识到，这个项目真正的价值远不止“3—5 天变成 20 分钟”。还有两个变化更重要。

第一个是，规划师开始从大量重复操作里脱离出来。以前很多时间花在查资料、找规则、操作工具和整理结果上。现在这些工作被压缩以后，人可以把更多精力放在真正需要专业判断的事情上。

而且 AI 有时候会给出一些原来工作流之外的潜在分析因子。比如判断一个区域经济活跃度，过去可能看交易、车流等传统指标，但 AI 可能提示还可以观察停车场闸机频率、房屋空置率、人口画像等其他信号。这些建议未必直接就是答案，但它能给规划师提供新的研究视角。

第二个变化，是组织本身开始发生变化。第一期我们陪着不同部门一起梳理工作流。后来有些部门已经开始自己把“识别、计算、处理、输出候选地块”这样的流程沉淀成 Skill。

也就是说，他们已经在学习怎么自己搭 AI 工作流。

对我来说，这才是 FDE 和传统外包很不一样的地方。好的 FDE 项目，是交付结束以后客户自己开始长出 AI 能力。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

当然有，而且真正难的问题很多都不在模型。

第一个挑战，是部门不一定愿意给你数据和规则。

10 个部门里，有人天然支持 AI，也有人心存顾虑，担心这套东西上线以后会影响自己的岗位和价值。所以我们去问业务规则、要数据的时候，有的人回复会很慢，甚至直接说：“这些网上都有，你们自己查。”

但实际上很多规则只有真正做业务的人才知道。这个时候，FDE 不能只靠技术解决。

我慢慢摸清了一个规律，在这种复杂组织里，找到真正能推动项目的“执行一号位”非常关键。项目发起人可能是副院长，但真正能协调 10 个部门、知道谁最难推动、谁掌握什么数据的人，往往是下面那个负责总调度的人。我们必须先跟这个人聊透。

与此同时，我也给方案留了容错空间。如果某个部门暂时不给数据，我不会让整个项目因此停下来。少一个部门，就先少做一个场景；少一类数据，就先让这一部分不参与计算。但是最后整体链路必须能够跑通。

我当时给自己定了一个很简单的交付原则：“一文、一图、一表”必须出来。即使少一个节点，核心交付形态仍然成立。这让我意识到，FDE 做方案不能把每个环节都设计成“缺一不可”，否则一个部门不配合，整个项目就会被拖死。

第二个挑战，是模型能力和数据安全之间的矛盾。

当时因为数据安全要求，生产环境不能随便使用国外模型。但那个阶段可选的本地模型，在一些复杂任务上的效果又没有达到我们想要的状态。偏偏领导还会随时要求演示。

这时候你会发现，做真实项目和做 Demo 完全不一样。Demo 只需要“这一次跑得漂亮”；生产系统则必须考虑安全、稳定、准确、可追溯。

所以我们后来会通过更明确的系统提示、工具封装和工程规则去弥补模型能力，同时把真正需要精准计算的东西尽量交给专业工具，减少对模型自由生成的依赖。技术上，我们选用混合部署，比如推理复杂场景的我们选用运模型，跑固定流程的我们走本地部署模型，比如 Qwen7b。

这也是我后来特别深的一个体会：模型能力只是整个系统的一部分，真正决定能不能上线的，还有数据、工具、评估和兜底。

第三个挑战，是客户想要的“AI 效果”不一定真的是最好的解法。

一开始客户希望做到“一句话出报告”。听起来很自然，但真正深入之后我们发现，如果把它简单理解成意图澄清后，再把问题转成 SQL 去数据库查询，其实很难满足规划业务的复杂性。所以我们建议把“万能问数”先放一放，让 AI 理解任务以后调用真正的专业工具完成处理。

到了后续阶段，又出现过类似的问题。比如大家会期待“多智能体博弈”：法律专家、

经济专家、民生专家坐在一起讨论一个规划议题。听起来很先进。

但我们真正分析业务后发现，有些选址问题最终还是依赖明确的规则和指标计算。这种情况下，强行做多智能体，不但架构更复杂，上下文在多个智能体之间传递还可能带来歧义、丢失和污染，结果反而不够收敛。

所以我们的思路慢慢变成，表面上可以体现不同专业视角，但底层未必真的需要多个 Agent 互相聊天，可以把不同专业能力封装成工具，由一个核心 Agent 统一调度。甚至某些寻找最优解的问题，本身就不一定应该用大模型，传统优化算法可能更加精准。

这个过程让我越发笃定，FDE 的职责是帮客户判断，什么地方真的应该用 AI，什么地方不应该。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这个项目以后，我对 FDE 最大的理解变化，是不再觉得 FDE 首先是一个“懂模型的人”。

第一，先进入业务。

如果做律师业务，就真的跟着律师跑一遍；如果做城市规划，就想办法让自己成为“半个规划师”。很多企业表面上说出来的问题其实不是真问题。只有真正跟着他们把工作流跑一遍，你才会发现，哪些事情每天都在重复，真正贵的成本在哪里，哪些步骤看起来不起眼却决定最后结果。

第二，不要一上来做大。

我们这个项目一开始也可以讲一个很大的故事：整个市、所有数据、所有规划场景全部智能化。但真正让项目跑起来的，是不断收敛。从一个城市缩到一个区域，再缩到一个具体单元，再挑两条工作流。先找到一个足够小、足够真实、能够形成闭环的场景，跑通之后，再扩。

第三，不要迷信技术先进性。

客户要的是解决问题，不是技术框架。硬编码能解决，就可以硬编码；若当前任务固定工作流合适，就用工作流；若当前任务较灵活，Agent 适合开放任务，就用 Agent；若当前任务需颗粒度小，传统算法比大模型精准，就用传统算法。

我现在更看重的是，模型、数据、工具、人和评估怎么组合起来，形成一个真正可交付的系统。尤其是评估和兜底。Demo 很好做，真正难的是，数据错了谁发现？模型给错建议怎么办？计算结果能不能追溯？最后谁对决策负责？这些问题解决不了，再酷的 Demo 也进不了真实业务。

第四，理解 FDE 自己的角色也会变化。

我在这个项目里其实经历了三个阶段。最开始，我像一个新人和助理，先进去学习他们的行业，把自己变成他们中的一员。等我理解业务以后，我开始帮助他们重新定义问题、设计流程、判断哪些地方适合用 AI。再往后，当他们自己已经会做 Skill、会 VibeCoding、会尝试搭自己的 AI 应用时，我的角色又变了。这时候我不一定还要替他们写每一个功能，可以站到更高一点的位置，告诉他们下一步有哪些坑，架构怎么选，哪些方向值得投入。

所以我现在更确定，FDE 最终做的，是陪企业重新审视一遍自己的业务，找到真正的问题，把业务知识变成可执行的流程，再把 AI 放到最适合它的位置上。我们要像“竹子”一样扎进去，当有一天，客户自己开始理解 AI、改造工作流，甚至能够自己做新的 Skill 时，这个项目才真正从一次技术交付，变成了企业内部持续生长的 AI 能力。

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

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

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

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

商家有新品或者营销节点，希望在短时间内找到大量达人帮自己带货，就会先找到 TAP；TAP 再从自己的达人资源里筛选合适的人，推动他们接品、拿样、创作内容，最终把商品挂到达人账号上。这个角色本身解决的是一个很现实的问题：TikTok 上商品太多，达人不可能一个个去翻商品市场，也很难仅凭商品信息判断什么值得带，所以 TAP 需要把商家和达人组织起来。

我们接触这个客户的时候，对方其实没有一开始就把问题定义得特别清楚。最开始他们找到我时，问的是一个很宽泛的问题：“我们团队怎么用 AI 赋能？”所以我没有直接回答，而是先反过来问他们：你们现在的业务到底怎么跑？哪个环节最慢？谁每天最累？

哪里最容易出错？

后来我们去了企业现场，从老板到部门负责人，再到各个小组负责人，基本都访谈了一遍。访谈下来，我发现他们其实已经意识到自己效率不高，但之前所谓的数字化，更多只是“先进团队先用飞书”，真正到了业务层面，依然有大量工作靠人工完成。我把整个业务放在一起看，发现这个问题贯穿了好几个环节。

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

运营人员需要在 TikTok 上寻找、筛选达人，然后主动发消息沟通。以前很像“大海捞针”，运营需要自己找人、看达人信息、判断是不是适合合作，再进行沟通。

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

客户自己的选品池里就有上万个商品，而达人又有不同的内容标签。有的是运动达人，有的是生活方式达人，有的是历史、哲学类内容创作者。到底什么商品应该推给什么达人，本质上是一个匹配问题。

第三是履约，周期长。

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

原来的平均履约周期大概在一个月左右。运营人员大量时间花在“催”上：你的样品到了没有？什么时候拍？什么时候提交？是不是快到截止时间了？

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

这其实是一个更底层的问题。TikTok 上有一部分数据，Excel 里有一部分，财务系统里还有一部分。达人 BD（Business Development，商务拓展）、履约人员和财务各自维护自己的数据，老板想知道一个达人从建联到最终产生 GMV（Gross MerchandiseVolume，商品交易总额）到底经历了什么，并不容易。

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

Q2在你参与之前，这个问题过去是怎么解决的？

业务规模还不大的时候，这套流程主要靠人。一个运营每天维护几十个达人，自己记得住谁聊到哪一步、谁收了样品、谁还没有拍视频，再配合飞书和 Excel，业务就能够正常运转。

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

真正的问题，是业务复杂度上来以后，这套方式开始出现瓶颈。比如选品池从几百个商品变成上万个商品，运营就不可能再靠经验一个个匹配；达人越来越多以后，也不可能每天靠人工翻 Excel 找哪些人要催；数据分散在不同系统里以后，管理者也很难及时看到整个业务漏斗。

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

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我当时做的第一件事情，是把业务流程画出来。从达人进入，到达人建联，到选品匹配，再到拿样、创作、履约，最后到数据复盘，我把整个链路拆开来看：每一步是谁在做？输入是什么？输出是什么？需要什么判断？哪些工作必须由人完成？哪些工作其实可以交给机器？

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

第一步：让 AI 先做“找对人”

达人建联是一个很典型的例子。我们可以利用商品信息、达人标签、内容属性等数据，先筛出一批更值得运营人员关注的达人。

例如，一个商品的主要卖点是什么，它适合什么样的人群；一个达人是什么内容类型，他的受众是什么。系统先把匹配度高的人筛出来，给 BD 一份更精准的名单，这样运营人员就不用从整个 TikTok 里“大海捞针”。

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

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

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

比如一个咖啡产品，它的卖点可能包括口味、气泡、品牌、联名等；如果一个达人本身就是职场、生活方式方向，那么这个商品和他的内容属性可能比较匹配。AI 可以先完成这层筛选，再由人工确认，这就把原本大量依靠人的经验进行的初筛，变成了“AI 先筛、人再判断”。

第三步：用 AI 帮助达人完成内容创作，解决履约动力问题这个环节是我觉得比较有意思的地方。很多时候，达人并不是不愿意带货，他们真正的卡点是拿到商品以后不知道“怎么拍”。因为一个带货视频不是简单地把商品介绍一下就结束了，它需要考虑达人自己的表达方式、商品卖点，以及当前什么样的视频内容更容易获得关注。

所以我们把这几个因素结合起来：达人特点 \+ 商品卖点 \+ 爆款内容参考，系统分析之后，给达人提供几个可选的拍摄脚本。这实际上是在帮助达人完成一部分创作工作，对达人来说是一个“利他”的能力，而不仅仅是 TAP 自己提高效率。访谈中客户反馈，目前达人对这部分能力的接受度比较高。

在这个基础上，未来还可以进一步探索 AI 视频生成，让达人在真实出镜之外，多一种内容生产方式。不过对于个人 IP 型达人，我们仍然认为真实的人和内容是核心。

第四步：把“每天人工催人”变成系统主动提醒这是整个项目里比较容易看到效率变化的一块。过去运营人员需要每天打开 Excel，看哪些达人到了截止时间，再一个个去催。

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

系统先自动提醒，如果达人还是没有履约，再把任务交给人工运营处理。这样一来，人不需要每天从几张表里找工作，系统会直接告诉你：“今天你真正需要处理的事情是什么”，这也是我理解的 AI 落地和普通自动化之间很重要的区别：AI 落地在做的是重新组织人的工作方式。

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

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

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

Q4相比传统方式，使用 AI 后的实际效果如何？

最直接的变化，是履约周期缩短了。过去，从确定合作到达人收到样品、完成创作并提交视频，平均大约需要一个月；项目试运行之后，目前配合的达人平均履约时间已经到了约 18 天。但对我来说，这个数字并不是这个项目最大的价值。

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

于是运营人员可以把更多时间放在真正需要人的地方：和达人沟通、建立关系、处理复杂商务问题。尤其是高价值达人，这种变化更明显，过去运营人员可能把大量精力耗在寻找和筛选上，现在可以把精力集中到真正重要的商务关系上。

另外一个变化，是管理者开始真正看到业务。以前老板很难看清一个达人从建联到 GMV 中间每一步发生了什么；现在至少可以围绕“达人—履约—GMV”形成更完整的业务视角。

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

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

当然有，而且我觉得这些问题恰恰是 FDE 案例最值得分享的部分。

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

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

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

所以如果要做境外业务，我会特别建议 FDE 提前把数据合规和数据流向研究清楚。不要等系统都做完了才发现数据拿不到。

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

这是这个项目里我们反复讨论的问题。比如达人匹配可以交给 AI，建联名单可以交给 AI 初筛，履约提醒可以自动化；但真正和重要达人沟通，我们还是保留人工。

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

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

很多企业一听到 AI，第一反应就是“是不是要替代人”，这个项目里我们其实非常注意这一点。我在推进的时候，会把 AI 的定位明确成“帮助大家解决问题、提高效率”，让大家理解这套系统是要帮忙，不是要替掉谁。同时我们在访谈时也不会只找老板，因为老板决定战略，但真正使用系统的是一线员工。

所以我会同时和上层、中层、基层沟通：老板告诉我们业务目标，一线员工告诉我们每天到底卡在哪里，两边的信息拼起来，系统才有可能真正落地。这也是为什么我一直强调 FDE 的一个核心能力：让这个系统真正进入企业的工作方式。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

我做这个项目之后，一个非常明显的感受是：FDE 真正难的地方，往往不是模型。现在很多 AI 能力其实已经非常成熟了，对于中小规模企业来说，技术选型本身反而没有以前那么难，我们更关注的是成本、稳定性和 ROI（Return on Investment，投资回报率），尽量用成熟的框架和合适的模型解决问题，避免为了技术先进而技术先进。

真正难的是下面几件事。

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

不要一上来问客户“你想做一个什么 AI 产品”，应该问：你的业务怎么跑？谁在跑？哪里最浪费时间？哪里最容易出错？哪个指标最影响业务结果？只有把这些问题问清楚，才能知道 AI 应该放在哪里。

这个项目最开始客户只是说“希望 AI 赋能团队”，但如果我们停在这个层面，最后可能只能给他做一个聊天机器人。真正走进企业之后，我们才发现，最值得解决的是业务链路里的几个具体环节。所以 FDE 的第一项能力，其实是价值识别能力。

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

我现在越来越倾向于把 AI 理解成一种新的生产力。它适合接手高频、重复、有明确规则的事情，但高度依赖信任、关系和判断的工作仍要留给人。这个项目最后，是让 BD 不再把时间浪费在找人和翻表格上，AI 把人从低价值工作里释放出来，人再去做真正高价值的事情。

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

我自己是技术出身，做了十年代码，后来经历了项目、产品等不同岗位。以前我也会犯一个问题，觉得只要把技术讲清楚，客户就应该能理解，但后来发现不是。

很多老板没有时间理解模型、Agent（智能体）、RAG（Retrieval\-AugmentedGeneration，检索增强生成）这些东西，他真正关心的是：“你能不能帮我把这个问题解决掉”。所以 FDE 要做的是把技术语言翻译成业务语言，把业务问题再翻译成可以落地的技术方案。

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

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

我认为 FDE 和传统软件外包最大的区别之一，就是是否对业务结果持续负责。传统项目可能是：需求来了 → 做系统 → 验收 → 交付；但 FDE 更像：进入业务 → 理解问题 → 做

第一版 → 让业务使用 → 根据反馈继续改 → 找到新的业务问题 → 再迭代。

这个项目就是这样，一期做完以后，客户自然会出现二期需求，因为当第一个问题解决以后，企业会发现下一层问题。所以 FDE 要做的，是持续陪着企业把 AI 能力往业务里推进。

最后，我觉得 FDE 一定要做深垂直场景。

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

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

我理解的 FDE，最终是站到业务现场，找到 AI 真正能创造价值的位置，然后一直把它推进下去的人。这也是我觉得这个项目最有价值的地方：我们没有试图证明 AI 什么都能做，我们做的，是通过一次真实业务落地，把“哪些事情交给 AI、哪些事情留给人”这件事重新划分了一遍。当这个边界划对了，AI 才真正开始变成业务生产力。

从经验装车到智能规划：FDE 用 AI 优化跨境物流装载效率

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

这个案例的应用场景是在黑河自贸区中俄跨境贸易中的货车装载优化。

当地很多企业通过公路运输方式向俄罗斯出口机电产品。在跨境物流中，运输成本是企业非常关注的一部分，而货车每一次出境运输，本质上都是一次固定成本投入。

当地很多企业通过公路运输方式向俄罗斯出口机电产品。跨境运输的运费按“方”计算，也就是说，这本质上是一场关于“车厢容积”的生意。

这里有一条非常硬的经济线：一辆约 110 方的货车，老师傅人工装载通常要 5 个小时，能装到 95～98 方；而 98 方就是保本线。更关键的是，每超过保本线 1 立方米，就能额外增收 100 美元运费。所以装载率不是技术指标，是利润开关：装不满 98 方就亏，装得越满、越过保本线越多，赚得越多。

简单来说，一辆货车无论装多少货，都需要支付同样的运输费用，包括司机成本、燃油成本、过境费用等。如果一辆车只装了一部分空间就发出去，剩余空间浪费掉，但运输成本并不会降低。

因此，对于企业来说，提高单车装载量、尽可能利用车厢空间，就意味着同样一趟运输可以承载更多货物，降低单件商品的物流成本，提高整体利润。

但在实际业务中，”把货装满”远不是往车里塞更多东西那么简单，这本质上是一个复杂的空间优化问题。

一开始接触这个项目时，很多人会认为这只是一个简单的装箱问题，只需要计算一下哪些货物怎么摆放，就能提高装载率。但真正进入现场之后，我发现事情远比想象复杂。

过去，企业装车主要依靠经验丰富的老师傅完成。他们根据货物尺寸、数量以及过往经验判断：哪些货物应该放在哪里；哪些空间还能利用；怎样摆放能够装得更多。

但随着跨境贸易规模扩大，这种方式逐渐暴露出问题。

首先，是车辆空间判断不准确。

俄罗斯方面提供的很多车辆信息是车厢外部尺寸，但真正能够使用的内部空间会受到车厢壁厚、保温层等因素影响，实际可利用空间往往比理论数据少 5%～8%。

其次，是空间利用率不高。

过去没有标准化的三维规划方案，装车主要靠人工经验。同样一批货，不同装车人员可能得到不同结果，整体空间利用率通常只有 60%～65%左右，大量空间没有被充分利用。

第三，是复杂场景下人工很难找到最优方案。

比如企业面对不同车型、不同尺寸货物，以及多辆车同时安排运输时，需要同时考虑空间、重量、运输效率等多个因素，这已经超出了人工经验能够处理的范围。

但在调研过程中，我发现最关键的问题其实是算出来以后落地不了：算得出最优解，不代表现场能够执行。

很多算法方案能够告诉企业理论上的最佳摆放方式，但现场工人真正执行时，会遇到很多问题：货物应该从哪里开始放？装载顺序是否合理？是否需要进入车厢内部操作？这样的方案是否符合现场安全要求？

所以，这个问题本质上是连接业务现场、算法能力和执行流程的综合问题，远不止算法优化本身。

攻克技术问题只是第一步，真正要做的是让 AI 进入业务流程并产生实际价值。

Q2在你参与之前，这个问题过去是怎么解决的？

在我参与之前，企业主要依靠经验丰富的装车人员进行规划，但是会耗费时间长一些。

通常一辆车的装车时间是 5\~6 个小并且达不到最优化的装车效果，装车员其实靠的是体力和时间来获得收入，所以通过这样的优化方式，能够提升装车效率。

通常情况下，老师傅会根据过去积累的经验判断：什么货应该放下面；哪些货物可以组合摆放；哪些空间可以利用。

这种方式在业务规模较小时能够运行，但随着跨境贸易规模增加，问题越来越明显。

首先，经验无法复制。

一个优秀装车工人的经验，需要多年积累，新人很难快速掌握。

其次，人工无法解决复杂组合问题。

如果只是几十件货物，人工还能判断。但当车型、货物种类、数量不断增加之后，人工很难快速找到最优方案。

另外，还有一个容易被忽视的问题：过去很多企业尝试过数字化工具，但效果并不好。

原因是这些工具通常只解决计算问题，没有考虑实际执行。

比如系统生成了一个复杂的三维方案，但是现场工人看不懂，最后还是回到人工经验。

所以算法本身不难获得，真正缺乏的是一个连接技术和现场的角色。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

整个解决过程的起点，是先重新理解业务，技术开发要放在后面。

作为 FDE，第一步一定是进入现场。

我需要先弄清楚：工人到底怎么装？为什么这么装？哪些环节影响效率？哪些事情机器可以替代？哪些事情必须符合人的习惯？

通过现场观察，我发现装车流程其实可以拆解成几个步骤：车辆真实尺寸获取、货物信息整理、装载方案计算、多车调度优化、生成装车指导、现场执行以及结果反馈。

其中，前面的规划和计算环节适合 AI 参与，但最终必须回到人的执行。

在方案设计上，我们采用的是“大模型负责调度，专业算法负责计算”的方式。

很多人会误以为大模型可以直接解决所有问题，但实际上三维装箱涉及复杂空间计算，大模型在这方面难以胜任。

所以我们的设计思路是，让大模型理解人的需求并负责调用不同工具，让专业算法完成确定性的计算。

具体来说，大模型负责：理解业务人员提出的问题；解析任务需求；调用装箱算法；解释最终结果。

而真正的三维空间计算，则由 Python 算法完成，包括高度图 3D 空间追踪、贪心放置、

多策略排序和遗传算法等。

另外，在实际落地过程中，我们做了一个非常重要的调整。

最开始，我们希望通过三维可视化系统让工人查看方案。

但现场调研后发现，工人在装车环境中并不适合频繁操作手机或者电脑。

所以最后我们把算法结果转化成更加简单的形式，就是一张工人能够直接使用的装车指导图。里面包含货物编号、摆放方向、截面示意以及装载顺序。

让算法结果真正变成现场可以执行的动作。

Q4相比传统方式，使用 AI 后的实际效果如何？

目前项目已经完成原型验证。在测试过程中，我们针对长 16\.4 米、宽 2\.47 米、高 2\.67 米（内净约 108 方）的真实运输车辆进行模拟装载，并结合 11 种不同规格电动车产品目录进行测试。

从结果看，AI 系统在不依赖老师傅的前提下，实测稳定达到约 99 方，逼近车厢容积上限；更重要的是，它把一个原本要靠老师傅 5 小时经验判断、且结果波动的过程，压缩为分钟级、可复用的标准方案，让“每一车都稳定冲过 98 方保本线”从靠人变成靠系统。

而在现场执行层面，价值更明显：人工装一车通常要约 5 小时，引入 AI 规划与指导后，预计可压缩到约 2 小时，装车效率提升约 100%，同样工时内可装载的车次接近翻倍。工人装完一车不用再等、不用再耗，可以立刻接着装下一车。

这条时间线一旦打通，收益是三层叠加的：第一，工人同样工时能装更多车，按车次计的收入直接增加；第二，物流公司整体周转效率提升、单车装载最大化，运营效率随之提高；第三，货主每一车都稳定越过 98 方保本线、逼近容积上限，按“超 1 方\+100 美元”的计费结构，多出来的每一方都是实打实的增收。

所以，这个项目的意义不是零和博弈里谁省了钱，而是做增量。把 5 小时压成 2 小时，多出来的车次、多出来的方，工人、物流公司、货主三方一起分，三方共赢，做增量部分。

但对我来说，这个项目最大的价值并不只是装载数字本身，更重要的是，它验证了一种可复制的 AI 落地方式：过去企业里的很多经验存在于人的脑子里，现在 AI 可以把它转化成数据和算法，再到最后的可执行方案。原来只有老师傅才能完成的工作，现在可以通过标准化流程复制。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

最大的挑战其实来自业务方面，技术层面的问题相对更为可控。

第一个挑战是算法结果和现场执行之间存在差距。

最开始，算法会优先追求空间利用率最大化。但现场人员告诉我，有些方案虽然理论上更优，但是实际操作很困难。比如需要工人进入车厢内部搬运，或者需要频繁调整货物位置。

所以我们重新调整目标，从追求数学上的绝对最优，转向在效率、安全和操作便利之间找到平衡。

后来我们设计了“截面法”。简单来说，就是按照车厢截面从里向外规划装载顺序。这样工人只需要站在车门位置操作，不需要踩踏货物进入车厢。

第二个挑战是数据获取。

车辆真实内部尺寸是计算准确性的基础。

如果依靠专业扫描设备，成本较高，企业接受度有限。所以我们采用 iPad Pro LiDAR 结合激光测距的方式，在保证精度的同时，把硬件成本控制在约 8500 元。

第三个挑战是让一线人员接受新的方式。

技术方案最终需要人使用。所以我们不断调整交互方式，把复杂算法结果转化成简单的编号卡、截面图和打印指导图。

FDE 的价值就在这里：交付技术只是起点，确保技术真正融入业务流程才是关键。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

从这个项目来看，我认为 AI 落地最重要的一点，是从业务问题和背后多人群的真实需求出发，把技术当作解决手段，而非出发点。

很多企业做 AI 项目时，会先想：“我们能不能接入一个大模型？”

但真正应该问的是：“业务中哪个问题最值得被解决？”

FDE 首先需要具备业务理解能力。只有进入现场，才能知道真实问题是什么。

很多时候，业务人员表达的是：“装不满。”

但技术人员需要进一步拆解：是不是空间数据不准确？是不是规划效率低？是不是执行流程有问题？

第二，需要做好技术和业务之间的翻译。

大模型很强，但需要用对地方。像这个案例，我们让大模型负责理解和调度，把专业计算交给专业算法，充分发挥各自的优势。

第三，要重视落地过程中的细节。

AI 项目最后能不能成功，往往取决于这些小问题：工人愿不愿意用？流程是否改变太大？成本是否企业能接受？

所以 FDE 的角色远不止 AI 开发，其核心价值在于连接业务、技术和用户三者。

第四，也是我在这一行越来越看重的一点：AI 落地要算清“经济账”。运费按方算、98 方保本、每方增收 100 美元，这些商业机制直接决定了装载优化的价值落点。只有既懂算法、又懂业务账的 FDE，才能把技术提升真正翻译成客户可感知的成本节约。这本身也是一种稀缺能力。

第五，好的 AI 落地不是零和博弈，而是做增量。这个项目我的底层商业逻辑，是它让工人、物流公司、货主三方都从“多出来的车次、多出来的方”里受益。把蛋糕做大，比在旧蛋糕里抢份额更有价值，也更能走远。

有幸在黑河这样一个边境小城，碰到跨境物流、自贸区这些真实得不能再真实的业务场景；有幸遇到一批不空谈、愿意跟我一起把 AI 从屏幕里，搬到车间、搬到车门前、搬到一线工人手里的伙伴。所以我一直信一句话：未来真正有价值的 AI，一定长在企业的真实流程里，而不是停在 Demo 上。这也是 FDE 对我最大的意义，让 AI 从电脑，走到真实世界里。

从个人提效到组织能力：FDE 用 AI 推动企业研发转型

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

这个案例发生在一家基金公司。它本身是偏基金投研类的企业，会围绕股票、汽车等不同领域开展基金管理业务。我们面对的是一支需求变化非常快的内部研发团队，和传统意义上几个月做一个大型软件项目的团队很不一样。

他们的一个特点是，需求非常零散，也非常快。内部产品经理或者业务部门一天可能就会提出好几个需求。对他们来说，AI 带来的价值，是把研发人员每天能够完成的功能点从三个提高到十个，和“原来一年做完的项目，现在半年做完”的传统想象并不相同。

所以，在我接触这个项目之前，他们其实已经在用 AI 了，而且有些人用得还挺深。有人用 Codex，有人用 Claude Code，也有人使用其他 AI Coding 工具。问题恰恰出在这里：大家都会用，但企业很难让大家一起用。

每个人都觉得自己的工具最好。“我用这个工具效率高，你让我换另一个，我反而不会干活。”当个人习惯越来越成熟以后，企业如果想统一工具，反而会遇到新的阻力。

而从管理层的角度看，企业需要的显然不只是几个员工个人效率提升。老板希望看到的是整个研发团队的转型，希望 AI 能够成为一种组织能力，而不再只是散落在员工电脑里的个人工具。

所以我当时面对的核心问题，已经超出“怎么教大家使用 AI Coding”这一层，具体是三个层次的问题。

第一，是认知没有统一。大家都在使用 AI，但对 AI Coding 到底能做到什么程度、自己的能力处于什么水平，并没有统一标准。

第二，是工具和方法没有统一。不同的人使用不同的工具，有不同的工作习惯，原来的研发协作方式也没有随着 AI Coding 的出现发生变化。

第三，是组织方式开始出现新的变化。企业管理层看到一些新的研发理念后，希望进一步调整研发角色和流程，但这些理念到底怎么落到自己的团队里，并没有现成答案。

这也是我理解 FDE 和普通技术培训最大的区别：面对这种问题，不能只回答“这个工具怎么用”，而要先判断企业真正要解决的是什么。

Q2在你参与之前，这个问题过去是怎么解决的？

之前就是产品经理按照原来的方式写 PRD，开发人员根据文档进行开发，不同角色按照原来的分工推进。后来 AI Coding 工具出现了，研发人员开始自己尝试各种工具，于是最早出现的是一种非常自然的“个人提效”。

有人发现某个工具好用，就自己用；有人掌握了新的方法，就自己实践。这个阶段其实没有什么问题，因为个人只需要对自己的效率负责。

但当企业希望从“个人提效”进一步走向“团队提效”时，原来的方式就开始出现限制了。

比如，原来大家习惯使用飞书文档写 PRD。后来 AI Coding 的工作方式发生变化，很多内容开始转向 Markdown、TXT 等文件。原来一个人维护一份文档没有太大问题，但当整个团队开始围绕这些文件协作时，新的问题马上出现了：十几份文档到底应该怎么拆？

产品经理写什么？前端写什么？后端写什么？测试和运维又分别负责什么？如果大家同时修改 Markdown，怎么避免冲突？原来的角色边界还能不能继续沿用？

这些都不是单纯学会一个 AI 工具之后自然就会解决的问题。

所以，我没有把过去的方法定义成“错误”。恰恰相反，它是适应原来研发模式的一套成熟方法。只是当 AI Coding 改变了研发方式之后，原来的流程、文档和角色分工也需要重新调整。

这也是我后来越来越明显的一个感受：AI 真正进入企业之后，很多时候改变的不只是工具，还有工具背后的工作方式。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

这个项目最开始，客户已经确定采用阿里的相关能力，但“买了之后具体怎么做”其实并没有特别清晰的答案。

所以我的第一步，是先重新摸需求，再考虑准备课程。

我先把不同角色的需求拆开来看。老板关注的是企业整体转型到底能不能发生，研发人员关注的是这个工具到底能不能真正提高自己的效率，产品经理关注的是原来的研发流程怎么变化，HR 又需要关注培训过程中每一天能够获得什么。

所以虽然最终交付形式是一次五天半的线下培训，我在设计时始终把它当成一次完整的企业 AI 转型实践来做。

我当时做了几件事情。

第一件事，是先把问题边界摸清楚。

在正式开始之前，我准备了大量素材，因为当时并不确定大家到底处于什么水平。

但这里有一个非常现实的问题：企业自己描述的能力水平，经常不等于现场真实能力水平。

所以我后来越来越重视一件事情：不要完全相信前期调研，一定要尽可能通过真实操作、快速原型和现场交流去验证。

第二件事，是把培训变成一条完整的业务故事线。

五天和半天完全不是一个概念。

如果只是讲工具，可能一天就结束了。但如果希望企业真正发生变化，就需要从前到后设计完整路径：为什么企业要转型、研发人员为什么要使用、工具应该怎么进入原有流程、角色怎么变化、最终又怎么沉淀成企业自己的方法。

所以这五天半里，我既是在讲，也是在观察；既是在培训，也是在咨询。

现场发现的问题，我会继续往后调整。

第三件事，是针对真实研发流程做定制。

这是整个案例里我认为最有 FDE 特征的一部分。

比如，原来的研发协作围绕一份 PRD 展开，现在转向多份文档协作，角色分工就不一定还能直接套用。

于是我们开始重新设计 Spec 文档。当时行业里其实没有一个特别成熟、统一的标准可以照搬，我也不知道自己设计出来的东西是不是最优解。

所以我没有一开始就把它当成“标准答案”扔给客户，选择不断拆解、逐步抛出、跟客户确认，再根据反馈继续调整。

最终，我从 0 到 1 整理出了一套 Spec 文档。客户一开始甚至以为这是阿里内部已经提炼好的文档，但实际上，这套东西就是我在这个项目过程中结合客户实际情况逐步搭出来的。

第四件事，是在现场不断调整，让方案跟随现场反馈走。

我们给这家基金公司一共做了三期。

第一期最重要的价值之一，是让我真正看到企业现场到底是什么样。第二期开始，就能够根据第一期积累下来的经验继续调整。到了后续阶段，客户的业务人员、产品经理也逐渐进入进来，整个项目从单纯研发培训变成了更完整的组织转型。

这也是我现在比较认可的一种 FDE 工作方式：先把整个链路跑起来，再根据真实反馈不断迭代，第一次不必追求 100 分。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目的效果，不能简单理解成“用了 AI 之后公司多赚了多少钱”。

这家基金公司没有向我开放可以对外披露的完整 ROI 数据。但从组织变化来看，效果是比较明确的。

过去，AI 更多是一种个人能力，每个人都有自己的方法和工具。

后来企业开始统一工具，并进一步统一研发协作方式。AI 不再只是“某个开发人员会不会用”的问题，而开始进入团队共同的研发流程。

更重要的是，我们把过程中形成的 Spec 文档和相关方法沉淀了下来。它不再依赖某一个人现场演示，能够在企业内部继续复用。

后续在另一个制造业客户的实践中，也出现了比较明确的短期数据：三个小组使用这套 Spec Coding 方法和模板后，统计显示写代码的时间节省了约 1/3，写文档的时间节省了一半多，测试时间则基本持平。

这个数据是客户在短期几天内做的内部统计，因此我认为它可以作为真实反馈，但不应该被理解成长期、完整的 ROI 结论。真正有价值的效果评估，还是需要持续两周、一个月甚至更长时间。

所以对我来说，这类项目最重要的结果，是完成了一个变化：从“大家各自使用 AI”，走向“企业开始形成一套共同使用 AI 的方法”。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

第一个挑战，是 AI 发展太快，而行业标准还没有跟上。

当时大家都在讨论 Spec、AI Coding、研发组织转型，但很多方法还没有经过足够长时间的大规模验证。

我自己也会担心：万一我整理出来的这一套方法不适合现场怎么办？会不会刚拿出来就被客户否定？

我的解决办法，是把不确定性暴露出来，然后通过小步验证降低风险，不假装自己已经知道答案。

我会先做一部分，再和客户确认；再结合外部信息和阿里内部能够获得的信息继续调整。发现不对，就修改。

这其实也是我觉得 FDE 很重要的一种能力：在一个还没有标准答案的领域里，不能因为没有标准就不做，也不能因为自己是技术人员，就假设自己一定是对的。

第二个挑战，是前期调研经常失真。

有一次，我们提前了解到客户团队使用 AI Coding 的能力比较深，所以准备了很多高阶内容。结果真正到了现场，发现大家连一些基础问题都没有解决。

那怎么办？只能现场降级，从基础开始。

反过来也一样。如果提前判断团队能力一般，结果到了现场发现大家已经用得非常熟练，我就会把原本准备的“压箱底”的内容拿出来。

所以现在回头看，我觉得现场能力本身就是 FDE 的重要组成部分。

第三个挑战，是企业一开始就想“大投入”。

比如一上来就买模型一体机、做模型微调，或者强行推翻原有全部工作流。我反而觉得这些方式比较危险。

如果业务可以用轻量级方式快速验证，比如 API、SaaS 或者 Agent 等方式能够先跑起来，我更倾向于先验证业务价值。除非企业有明确的合规、安全等要求，否则没有必要一开始就把投入做得特别重。

投入应该由轻到重，先把业务价值验证出来，再逐步加深。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

我现在越来越觉得，企业部署 AI 最容易犯的错误，是把 AI 当成一个单独的技术项目。实际上，真正落地的时候，技术只是其中一部分。

第一，先理解业务到底想解决什么问题。

很多企业会说：“我要做 AI 转型。”但这句话本身没有办法指导落地。到底是个人提效、

团队提效，还是研发流程重构？不同目标对应完全不同的方案。

第二，不要过度依赖前期调研，快速做原型、跑真实流程。

因为 AI 的使用水平很难通过问卷准确判断，所以我现在更倾向于快速做原型、快速跑一遍真实流程。哪怕第一次只有七八十分，也比坐在那里把方案讨论到 100 分再开始更有价值。

因为真正跑起来之后，背景、痛点、方案和限制条件都会变得更清楚。第二遍再优化，就有机会从七八十分做到八九十分。

第三，接受 AI 落地是一个持续迭代的过程。

尤其是在 AI 发展特别快的领域，没有人能够保证自己第一次设计出来的就是最佳方案。

与其追求一次性解决所有问题，不如先把第一轮跑起来，然后不断修正。

最后，也是我认为 FDE 最重要的一点：不要只站在技术人员自己的视角看问题。FDE 需要同时理解技术、业务和客户。

跟老板沟通，老板关心的是组织效率和投入产出；跟研发人员沟通，他们关心的是工具好不好用；跟产品经理沟通，他们关心的是研发流程怎么变；跟 HR、采购、运维沟通，又会是完全不同的话语体系。

所以我觉得 FDE 更像一个“翻译官”：把标准化的 AI 能力，转化成具体企业、具体团队能够真正使用的东西。

我把 FDE 的价值归纳成一句话：把 AI 的能力翻译成企业真正能用、能跑、能沉淀的工作方式，比单纯把一个 AI 工具带进企业更重要。

从物料难找到精准定位：FDE 用 AI 减少工业企业采购浪费

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

这个案例的客户来自海外。坦白说，我们第一次去客户现场之前，并不知道最后要做什么。虽然前面已经有过几轮沟通，但当时没有一个预设答案，客户到底需要大模型、

Agent，还是其他 AI 能力，谁都不确定。

所以我们没有带着现成产品进去，而是先做了一件看起来很“慢”的事情，访谈。前期对整个客户的业务摸排持续了很长时间，我们跟不同部门沟通，理解组织架构、业务流程，也观察不同业务人员对 AI 的态度。真正进入这个具体案例之后，我们又围绕 ERP 及其上下游团队进行了持续数月的深入访谈。

这家企业属于工业场景，需要管理大量机械设备、物料和资产。小到一副手套、一颗螺丝钉、一副耳塞，大到一辆卡车、一个机械臂，都需要进入 ERP 数据库。跟这套数据库发生交互的团队大概有 15 个，有人负责录入，有人负责采购，有人负责合同，有人负责仓储。

我们把这些团队一个个访谈下来，发现一个非常有意思的现象，几乎所有部门都在抱怨同一件事情，ERP 不好用。但“ERP 不好用”还不能算一个可以直接交给工程师解决的问题。于是我们继续追问，到底哪里不好用，平时是怎么操作的，问题发生在哪一步。

有时候我会直接坐在业务人员旁边，看他实际怎么工作。因为很多问题，如果只在会议室里问，是问不出来的。访谈结束之后，我们自己还会继续研究和拆解，去做根因诊断。

这个过程做下来，我们最后梳理出大约 15 个可以进一步处理的功能点，其中两个问题非常典型。第一个是数据不干净。第二个是搜索能力非常弱。

客户使用的是一套比较老的工业软件。今天大家已经习惯了淘宝、京东、亚马逊这种搜索体验，输入自己想找的东西，很自然就能得到结果。但在这套工业 ERP 里，搜索没有这么顺畅。

业务人员经常遇到一种情况：“我明明知道这个部件数据库里有，我上次还用过，但现在就是找不到。”这句话后来成为我们理解整个问题非常关键的入口。

因为“找不到”本身还不是最终的业务损失，真正的问题发生在后面。当一个员工找不到某个物料时，他可能会认为数据库里没有，于是重新录入一条数据，可这个物料本来就存在。于是形成一个循环：找不到物料 → 重新录入 → 出现重复数据 → 数据越来越脏→ 更难找到正确物料 → 买错、买重或者搞错单位。

到工业采购环节，这就牵扯到真金白银了。消费者买错东西，可以退款。工业采购却常常做不到这一点，东西买错了，往往不会退回去，只能再买一个正确的。错误采购的东西就留在仓库里，一放可能就是几年。

仓库不可能无限存储。几年之后清理库存时，发现这些东西长期没人使用，最后只能按照规则处理掉。企业真正损失的钱，就藏在这里。

所以我们后来把真正要解决的问题，定义为能不能通过改善数据质量和物料查找能力，减少那些原本不应该发生的错误采购和重复采购。

这个问题一旦定义清楚，AI 的价值也从“让系统更智能”，落到了一个真正能够影响企业经营结果的问题上。

Q2在你参与之前，这个问题过去是怎么解决的？

客户的这套 ERP 已经承载了企业长期的库存管理流程，各个团队围绕它形成了自己的工作方式。录入、采购、合同、仓储，各个环节都有明确的职责，企业也一直靠这套流程运转。

问题在于，随着数据不断积累，原有系统本身的限制越来越明显。尤其是工业物料的数据非常复杂。同一个东西可能存在不同名称、不同描述方式、不同单位或者不同录入习惯。如果系统的搜索又主要依赖传统字段和关键词，业务人员就很难快速确认，数据库里到底有没有自己想要的物料。

以前碰到这种情况，业务人员依靠的是经验。知道编码，可以按编码找；知道准确名称，可以按名称找；实在找不到，就按照原来的流程重新录入。

在数据规模还没有那么大、业务链路还没有那么复杂的时候，这套方式能够工作。但随着历史数据越积越多，靠经验兜底越来越吃力，同样的流程开始失效。

所以这笔账，不能算在一线员工头上，先顶不住的是那套搜索系统。企业其实早就把流程装进了 ERP，数字化这一步早就迈出去了。真正卡住的是，这套系统的关键词检索和字段匹配，处理不了工业物料那么多名称、描述和单位，于是数字化的工具本身成了新的瓶颈。

这时候如果只是继续要求员工录入得更规范一点、搜索得更仔细一点，很难从根本上解决问题。于是我们判断，AI 应该在这里介入。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

如果只看最后做出来的功能，这个案例其实一点都不“性感”。无非就是两件事，把已有数据清洗、标准化，再增加语义检索能力。甚至有人会说，这不就是 RAG 或者智能搜索吗。

我觉得这么说技术上没有问题，但如果只看到这里，就把这个案例最重要的部分漏掉了。因为真正困难的事情，从来都在“为什么要做语义检索，以及做完以后究竟改变了什么业务结果”上。我们整个过程大概经历了几个阶段。

第一步，进入现场，先做问题发现。

我们花了数月时间和业务部门沟通，重点看他们真实的工作过程，也听他们说自己希望 AI 帮什么。因为业务人员会告诉你很多需求，但 FDE 不能直接把需求列表变成功能列表。我们需要继续判断，这个问题是否真的存在，根因在哪里，AI 能不能解决，解决之后能产生多少业务价值。

在这个过程中，我们才逐渐把“ERP 不好用”拆解成一个个具体问题，并进一步找到数据质量和搜索这两个值得优先处理的问题。

第二步，把问题放回完整业务链条里。

这是我认为 FDE 和单纯做 AI 功能非常不一样的地方。我们没有停在“搜索不好，所以做一个更好的搜索”这一步，继续往下追，搜索不好到底为什么会产生业务损失。最后才得到这条链路，搜索困难 → 重复录入 → 数据污染 → 错误/重复采购 → 库存积压 → 最终报废 → 产生真实财务损失。只有这条链路成立，我们才知道这个 AI 应用到底值多少钱。

第三步，和所有利益相关方一起确定优先级。

这个案例涉及十几个部门，不可能 FDE 自己拍脑袋决定先做什么。我们把诊断出来的功能点整理成列表，再把不同业务部门的负责人和代表召集起来，一项项确认每个功能到底解决什么问题、是不是业务真正需要的、应该先做哪个后做哪个，还会让业务部门参与投票。

与此同时，FDE 内部也会从七八个维度去评估每个用例，比如数据能不能拿到、数据处理后能不能重新写回业务系统、AI 到底能不能解决、技术难度怎么样，以及最终业务人员是否愿意采用。

因为一个功能技术上做出来，不代表它真的能落地。有时候数据根本不存在；有时候老系统不允许你把处理结果写回去；有时候技术能实现，但业务部门不愿意自己的系统被碰；还有时候业务人员根本不相信 AI 输出的结果。这些问题，都要在真正开始构建之前尽可能摸清楚。

第四步，把技术分工定清楚，让 AI 只做该做的部分。

我们没有把所有事情都塞给大模型。语义检索负责理解业务人员那句“我要找的东西”

背后的语义，把同一个物料的不同叫法对上号；数据清洗和标准化则负责在检索之前先把历史数据里的重复和不一致处理掉，让语义检索有干净的底子。最终是不是采购、采购多少，仍然由业务人员拍板。

第五步，从能快速证明价值的场景开始，允许中途反复。

我不建议一上来就挑最难、最酷的东西做。因为如果一个项目做了几个月还没有结果，客户的耐心和信心都会快速下降。我们更愿意先找容易见效的场景，最好几个星期，甚至两周左右，就能够让业务部门看到一个初步结果。

一旦业务人员看到“这个东西真的有效”，信心就建立起来了，后面才会更愿意主动参加后续的行动。而且这条路不会一直笔直。

过程中经常会反复。有时候做到一半发现问题定义不对，我们会重新回到问题发现这一步；有时候发现范围铺得太大，就重新缩回来。FDE 真正做的，是持续验证“问题、方案、业务价值”三者之间的关系，让每一步都建立在前一步的验证结果上。

最终，我们让业务人员更容易找到已经存在的物料。这样做的目的，是从源头减少重复录入，进一步减少错误采购和重复采购，搜索只是手段。

Q4相比传统方式，使用 AI 后的实际效果如何？

我们衡量效果的方法其实非常明确。最终看的是客户是不是少买错东西了，是不是少重复购买了。模型准确率、员工觉得搜索速度快了多少，都只是过程指标，真正的业务结果是采购行为有没有改变。

在做这个项目之前，客户其实知道错误采购和库存浪费存在，但这个问题在客户那里并不显性。没有人真正把历史数据库里的记录找出来，仔细分析这些错误到底每年造成多少损失。所以我们工作的一部分，是把过去不可见的问题变成可以计算的问题。

我们会从历史数据中建立基线，再通过小规模实验逐步扩大范围。每个阶段都去验证几个问题，AI 有没有减少重复数据，数据库的清洁程度有没有提高，原来因为数据问题造成的错误采购有没有下降，最终对应的采购浪费有没有被避免。

更重要的是，这个价值不能由我们自己宣布。我们最后需要通过严格的计算方式得出结果，而且计算出来的业务价值还需要客户自己的业务人员确认。只有客户说出那句“对，这笔钱确实是因为这个应用被节省下来了”，我们才认为价值真正成立。

所以相比过去，这个案例最大的变化，是把原来“大家都知道有问题，但没人知道问题值多少钱”的状态，变成了一个可以被发现、被干预、被持续衡量的经营问题。这正是我理解的 AI 落地和 AI 演示之间最大的区别。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目真正困难的地方，其实大部分都不在模型本身。

第一个挑战，找到真正的问题需要很长时间。

我们花数月去理解一个看起来和 AI 没有太大关系的 ERP 业务流程。对很多工程师来说，这可能是最难接受的部分，大家更习惯客户给需求、自己写代码。但 FDE 不一样，很多时候客户自己都不知道真正值得 AI 解决的问题在哪里。你必须坐下来理解采购怎么做、

仓储怎么做、数据怎么录、不同部门之间怎么协作，不做这些“脏活累活”，后面的 AI 很可能只是在错误的问题上做得更漂亮。

诊断要深，客户对价值的期待又来得快。如果前面已经花了很长时间做业务梳理，进入实施以后再连续几个月看不到结果，组织很容易失去耐心。所以我们会刻意从容易证明价值的场景开始，先让业务部门看到有效，再逐步扩大。

第二个挑战，跨部门协调难。

这个案例涉及十几个团队，每个团队职责不同，诉求也不同。有些 AI 应用甚至会改变部门之间原来的工作流程，因此天然可能产生冲突，而且很多冲突不会在会议上直接说出来。所以我们会做多轮讨论，不仅开大会，还会提前和不同利益相关方单独沟通，把这些没说出口的顾虑提前化解。

第三个挑战，技术能做，落地却难。

比如数据能不能拿出来，老 ERP 能不能让我们把处理后的数据写回去，业务部门是否允许我们触碰现有系统，最终用户愿不愿意相信 AI 结果。这些问题任何一个解决不了，用例都有可能失败。所以我们在正式构建之前，就会从多个维度给不同场景打分，AI 能不能实现只是其中一项。

上线之后，事情同样没有结束。项目最终要移交给业务部门，由他们决定是否真正采纳。上线以后还要继续看，运行一段时间之后效果还在不在，和项目启动时定义的目标相比有没有变化，如果效果下降，原因是什么，是不是还需要继续优化。

FDE 不能是“东西做完、钱到账、人撤走”。如果业务部门最终不用，或者三个月之后效果消失了，那这个应用就不能算真正落地。整个交付因此会反复回到问题诊断、范围选择和验证环节，很难一条直线走到底。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这个案例以后，我更加确信，FDE 最重要的能力，在于找到真正值得解决的问题，快速做一个 AI 应用反而排在后面。我会总结成几个原则。

第一，不要拿着 AI 去找问题，要先进入业务现场找问题。

很多人做 AI 应用的方式，是手里有一个 Agent、有一个 RAG、有一个工作流产品，然后去问客户，你这里有没有什么场景能用。这很容易变成拿着锤子找钉子。我们更希望反过来。

先长期跟客户接触，理解业务，做问题发现，再判断这个问题应该用生成式 AI、传统机器学习，还是根本不应该用 AI。AI 技术只是手段。

第二，不要停留在用户提出的表面需求，要一直追到根因。

业务人员说“ERP 不好用”，这不是一个问题定义。他说“搜索不好用”，也还不是。继续追下去，你才会发现，“搜索不好用”一路追到底，最后落到了真实的财务损失上。

FDE 需要一直追问，为什么，然后呢，这件事最终影响了什么，直到找到能够和业务结果连接起来的根因。

第三，优先选择能证明价值的用例。

一个 AI 场景值不值得做，我会同时考虑数据获取难度、系统集成难度、AI 可行性、业务复杂度、用户接受程度和潜在价值，最酷的往往先放一放。一开始尤其应该选择能够快速产生结果的场景，因为早期的结果不仅是技术验证，也是建立组织信心的过程。

第四，把 ROI 定义放在项目开始。

很多 AI 项目上线之后才开始问，这个东西到底创造了多少价值，这时候往往已经晚了。

我们会在一开始就问清楚，如果这个问题解决了，企业一年能减少多少损失，这个数字怎么算，数据从哪里来，最后谁来确认。这样到项目结束的时候，我们拿客户认可的业务结果证明自己，模型指标只是过程参考。

第五，先标准化的应该是方法，产品可以先放一放。

我并不反对标准化产品，但现阶段 AI 技术变化太快。如果一开始就想着把某个功能沉淀成一个标准产品，再拿着它去找下一批客户，很容易又回到老路上。

相比之下，我更看重可以复用的方法论。怎么做问题发现，怎么做根因分析，怎么判断用例，怎么定义 ROI，怎么做小规模实验，怎么和业务部门一起验证，怎么持续衡量。

这些东西，比某一个具体的 AI 功能更值得沉淀。因为下一个客户的 ERP 可能完全不同，业务流程也可能完全不同，但解决问题的思维方式是可以复用的。

所以如果让我用一句话总结这个案例，我会说，FDE 真正的工作，是先深入业务，把一个模糊的抱怨还原成一个可以解决、可以验证、可以计算价值的问题，再决定 AI 应该出现在哪里。

这个案例最后落地的是数据清洗和语义检索，但真正创造价值的，在于我们花了足够长的时间，把“一个物料为什么找不到”一直追到了“企业为什么会因此浪费采购预算”。

当这条链路被找到之后，AI 才真正从一个技术能力，变成了业务价值。

从“表哥表姐”到智能执行：FDE 用 AI 重构央国企财务流程效率

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我做的是一个央企科研机构的财务流程 AI 应用。

这个场景其实特别典型。央国企的财务工作有大量规则和流程，很多业务都超过了“把一张发票录进去就结束”的范围。

比如一个员工出差回来要报销一张发票。过去，他可能要先提交报销，然后财务人员去判断这笔费用到底属于什么性质，是差旅费、招待费还是其他费用；如果涉及项目，还要判断它应该记在哪个项目下面；同时还要去找这个人的出差申请、审批记录、所属部门等信息。

这些信息其实分散在不同的业务流程里。真正耗时间的，是填表之前那段判断过程。

而且央国企的财务科目本身就比较复杂，规则多、层级深。再加上付款对象除了员工，也可能是供应商，或者涉及保证金等各种对外的财务流转。所以当业务量越来越大以后，财务人员大量时间都花在重复判断和录入上。

对科研型央企来说，这个问题又多了一层。我们服务的很多企业里有大量科研人员，甚至是博士，他们真正应该投入的是科研工作，但大量时间被消耗在一个报销流程里。

所以我当时看这个问题，看到的是一个很明显的价值错配：让高价值的人去做低价值、

重复性的流程工作，本身就是一种浪费。

这也是我作为 FDE 比较关注的地方。我会先去看：这个业务到底哪里最痛？哪些环节是真正值得被改变的？想清楚之后，再回头匹配对应的能力去解决它。

Q2在你参与之前，这个问题过去是怎么解决的？

过去这套方式其实完全可以运行。

财务人员有自己的专业经验，也有成熟的业务规则。他们知道什么费用应该记在哪个科目，知道什么业务需要关联哪些审批信息，也知道集团系统应该怎么填写。在业务规模和复杂度还没有那么高的时候，它是一套可靠的办法。

问题在于，很多事情必须依赖人工。

前面要有人判断。比如一张发票过来，财务人员需要结合员工的出差申请、部门、项目等信息，判断这笔钱到底应该怎么记。

后面还要有人执行。判断完成之后，财务人员还需要打开集团网站，创建单据，一行一行地填写信息，再提交。

所以整个过程实际上有两个明显的时间消耗：一个是判断时间，一个是执行时间。

过去靠专业人员来完成没有问题，但随着业务量增长，这种方式很难继续线性扩张。业务量增加一倍，就增加一倍的财务人员，这条路很难走得通。

所以我们真正要解决的，是把财务人员从大量重复性的判断和操作里解放出来，让机器去承担那些更加适合机器完成的事情。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我做这类项目，有一个很重要的习惯：直接进业务现场陪跑。

因为你不能期待业务人员把自己的整个业务逻辑完整地告诉你。很多时候，他自己做了十几年，很多判断已经成为了下意识动作。所以我们会跟着业务人员一起做，去看他每天到底怎么处理一笔业务，再把整个流程一点一点拆开。这个项目也是这么做的。

第一步，先把业务逻辑真正梳理出来。

以员工报销为例，员工不需要再关心后面的复杂流程，他只需要在钉钉里告诉机器人“我要报销”，然后把发票发过去。从这里开始，后面的流程就交给 AI。

AI 首先识别发票，然后去关联员工原有的业务信息，比如这个人之前有没有出差申请、

审批意见是什么、属于哪个部门、对应哪个项目。这些信息被拉取出来之后，AI 再结合财务规则进行判断：这笔费用到底应该归到什么科目、哪个项目、按照什么规则进行处理。

这里其实发生了一个很重要的变化：以前是人自己去系统里找信息、判断信息，现在变成 AI 主动把信息组织起来，再辅助完成判断。

第二步，让 AI 负责“判断”，监督机制负责兜底。

财务属于严肃业务，AI 判断得再好，也不能简单理解成“AI 说什么就是什么”。所以我们在里面设计了监督机制，可以把它理解成几个 AI 角色一起工作：一个负责执行判断，一个负责监督，一个负责发现风险。

对于已经比较确定的业务，就直接往后走；如果几个模型判断之后仍然存在不确定性，就进入风险监控，由相关人员重点关注。

这样一来，人的角色也发生了变化。过去是人处理所有事情，机器没有参与；现在变成 AI 处理大部分确定性工作，人只处理真正需要关注的风险和异常。

第三步，让 RPA 负责真正的“手”。

AI 解决了“应该怎么做”，但还有一个问题：谁去把这个动作真正做完？所以我们又把 RPA 引进来了。

AI 判断完成以后，RPA 机器人就开始执行。它可以自动打开浏览器，进入集团对应的网站，创建单据，然后把相关信息填写进去并提交。

所以这个方案实际上是把整个流程拆成了几个部分：业务信息获取 → AI 判断 → AI 监督→ 风险识别 → RPA 执行。

这也是我理解的 FDE 和单纯做技术方案最大的区别：我们想的是怎么把 AI 真正嵌进原来的业务流程里面。

第四步，先做一个“破冰项目”，再逐步扩大范围。

这也是我在项目落地过程中非常看重的一点。我一般会把第一个项目叫做“破冰项目”。

为什么？因为企业第一次接触 AI 的时候，往往需要先看到真实价值，才愿意投入大量资源，尤其是央国企，后面还涉及数据安全、基础设施、预算等问题。

所以我会先找离业务最近、最痛、最容易产生 ROI 的那个场景。就像摘桃子一样：先摘离自己最近、最甜的那个桃子。

让业务人员真正用一次，发现原来 AI 真的可以帮我节省大量时间。当业务团队自己尝到红利以后，他们才会愿意和你站在一起，继续做更大的事情。

Q4相比传统方式，使用 AI 后的实际效果如何？

最直观的变化，就是时间。

过去处理这些财务场景，工作人员可能需要半个月，甚至一个月。现在通过 AI 加 RPA，把一个完整流程跑下来，大概一天、两天就可以完成。

而且这覆盖了不止一个报销场景。在这个项目里，我们最终落地了 10 个 AI 相关应用场景，把财务不同环节都逐步覆盖了进去。

但我觉得，这个项目真正有价值的地方，在于它改变了人的工作方式。

过去科研人员可能需要参与很多与科研本身无关的流程。现在，他只需要在钉钉里把发票给机器人，后面的信息关联、规则判断、系统录入等工作都被隐藏到了后台。人的操作被压缩到了非常短的一步。

而对于企业来说，AI 带来的价值也远超节省几个人工。它实际上是在把一套依赖大量人工经验和重复操作的流程，逐步变成一个可以持续运行的业务能力。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目让我比较深的一点感受是：AI 项目最难的地方，很多时候在技术之外。

在 AI 时代，我甚至认为，一个项目如果单纯从技术上已经能够落地，其实已经成功了 80%。真正容易让项目“死掉”的，是业务、人和组织。

第一个挑战，是业务部门的接受度和推进节奏。

AI 程序本身不会产生价值，真正产生价值的是业务部门。比如 AI 帮他们节省了时间，但最后真正享受到这个效率提升的，是业务人员，所以我们必须想办法让业务部门和我们站在一起。

我特别反对一种方式：让 AI 项目组自己坐在那里设计一个东西，然后让业务部门过来使用。业务人员本来每天已经很忙了，你突然给他增加一个新系统、新流程，他第一反应很可能是“你为什么又给我增加了一个负担？”所以我们的方式是业务陪跑：我会跟着业务人员一起做几天，看他真实的工作流程，把业务逻辑主动梳理出来，让业务人员不必自己整理一份特别完整的需求文档交给我们。

同样，第一次合作也不能大刀阔斧地改流程。如果我跟业务部门说“你们原来的流程全部不要了，我们重新设计一套 AI 流程”，这个项目大概率会遇到阻力，因为业务人员已经有自己的工作习惯，原来的流程之所以存在，也有它自己的原因。

所以我更愿意从一个很小、很痛的场景开始，先把一个点做好，让业务人员看到真实 ROI。当他发现这个东西真的能帮自己省时间，他就会开始主动跟你讨论“这个地方是不是也可以做”。这时候，AI 项目就从“你要让我用”变成了“我希望你帮我继续做”。

第二个挑战，是数据安全和基础设施。

央国企尤其是科研机构，对数据安全要求非常高。财务数据很多都属于敏感数据，不可能简单地丢到公共模型里处理，所以我们必须从底层基础设施开始解决问题，包括算力、模型部署、数据环境等。

我之前就帮企业采购过大型 AI 算力一体机，投入达到两百多万元的量级，让企业具备运行大模型的基础环境。对于敏感财务数据，还需要采用数据不出域的私有化部署方式。

但这里又出现了一个很现实的问题：如果你一开始就告诉甲方“我们先花两三百万元买一台机器”，对方很可能会问“为什么？我还没看到 AI 能给我带来什么价值”。所以这又回到了前面的逻辑：先用小场景证明价值，再推动基础设施建设，不能反过来。

第三个挑战，是不同场景不能强行使用同一个模型。

我在做方案的时候，也不会执着于某一家模型。财务场景需要严谨，科研场景可能需要专业计算能力，有些内容生成场景又更需要开放性。所以我的原则是根据场景选能力：

有些场景可能使用阿里云的模型，有些使用其他厂商的模型，还有一些央国企场景则采用本地私有化部署。

我把这种方式理解成“因材施教”：先确定业务需要什么，再去组合背后的能力。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做了这些项目以后，我越来越觉得，FDE 真正的价值，在于能不能把技术、业务和组织真正连起来，这比“懂多少 AI 技术”更重要。如果让我总结，我会特别强调几个方面。

第一，先进入业务，再进入技术。

FDE 最重要的动作之一，就是业务陪跑。别坐在会议室里等业务人员告诉你需求，真正需要做的是跟着他工作，看他到底怎么做。很多业务规则，业务人员甚至自己都很难一次性讲清楚，但你跟着他做一遍，就能发现大量隐藏在流程里的判断和经验。

第二，先找“最近、最甜”的桃子。

别一开始就做一个宏大的 AI 转型项目，先找一个小场景。这个场景最好同时满足三个条件：业务真的痛、实现相对可控、ROI 能够快速被看见。

先把第一个项目做成“破冰项目”，让业务部门拿到结果、得到表扬，甚至成为集团内部的标杆。有了这个标杆，后面的资源、预算和组织支持都会更容易获得。

第三，要把业务方真正绑到结果上。

AI 项目要跳出“技术团队自己的项目”这个定位。如果最后只是 AI 团队说“我们把系统做出来了”，其实没有意义。真正应该关注的是：业务有没有节省时间？人效有没有提高？业务结果有没有变化？

所以我要想办法让业务团队和我们共同承担结果，甚至在条件允许的时候，把 AI 改造和业务部门的 KPI、OKR 结合起来，让业务部门自己也有动力把项目推下去。

第四，FDE 需要从“技术实现”跳到“业务结果”。

我以前也是架构师出身，但后来越来越觉得，AI 时代不能一直停留在“这个技术怎么实现”。底层很多实现工作，未来很可能本身就会被 AI 完成。

真正需要人来做的是：我为什么做这件事？这个问题到底怎么定义？它对企业有什么价值？怎么设计一个能够支撑企业未来 3 到 5 年的架构？怎么把项目真正推动落地？

所以我认为，一个成熟的 FDE 至少要同时具备沟通能力、架构思维和项目管理思维。

第五，要主动“破圈”和“摸高”。

我自己很看重两个词：破圈、摸高。

破圈，是走出去跟企业一把手、业务负责人、不同产业的人沟通，他们真正关心的是：

营收能不能提高？成本能不能降低？组织管理能不能更透明？业务控制力能不能提升？

摸高，是主动去接触比自己认知更高一点的人，理解他们怎么看问题。你的认知发生变化以后，你解决问题的方式也会发生变化。

最后，我想说 FDE 本身是一个“中间态”。

我现在越来越把 FDE 理解成一个“中间态”：一开始，一个人可能什么都做，先靠解决不同客户的问题活下来；慢慢地，你会发现自己在哪个行业、哪个场景真正有优势，于是开始聚焦；当你能够独立理解业务、设计架构、推动项目落地，你就成为了这个领域的 FDE。

但如果一直停留在“我亲自交付每一个项目”，个人带宽是有限的。下一步就应该把过去积累的交付经验、业务方法和 SOP 沉淀下来，让更多人可以按照这套方法交付；再往后，把反复出现的共性问题提炼成标准产品。

从个人能力，到团队能力，再到可复制的产品能力，这才是 FDE 能力真正放大的过程。

所以如果让我重新定义这次财务案例，它其实超过了一个“AI\+财务”项目的范畴，更像是一次完整的 FDE 实践：先进入业务现场，找到真实痛点；再拆解业务流程，把 AI 放到真正需要判断的位置；让 RPA 去执行重复动作；用监督机制控制风险；最后通过一个小场景证明价值，再逐步扩大 AI 在企业里的应用范围。

这也是我理解的 FDE：真正对一个业务问题负责，直到技术变成业务结果。

从人工核对到智能对账：FDE 用 AI 让线下零售对账又快又准

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我一直觉得，FDE 真正有价值的地方，在于找到一个和企业业务目标足够近的问题。能不能用 AI 做出一个东西，反而是次要的。

这个案例就是这样。客户是一家以线下零售为主的消费品企业，年营收规模达到几十亿元，门店主要开在百货公司和商业综合体里。它的资金结算链路比较特殊：门店自己的收银系统会产生一套数据，商场也会有一套结算数据，最终资金经过商场结算给企业，所以每个结算周期，都需要把两边的数据和单据重新核对一遍。

最开始客户找到我们的时候，提出的其实就是一个非常朴素的问题：对账太费人工了。

这件事情听起来很标准，甚至有点“不值得用 AI”。但我后来发现，恰恰是这种事情值得仔细看。

过去店员或者店长要拿着纸质单据或单据转成的扫描件/图片，从不同系统里把数据拉出来逐项核对。整个过程基本是人工、肉眼完成。如果发现对不上，还要双方重新核对，改完之后可能还会再出现新的差异，于是不断来回拉扯。一个周期下来，可能就要花掉一两个人天。

这背后其实有三层问题。

第一层是业务问题。对账做得不够彻底，意味着有些本来应该收回来的钱可能被遗漏了。

第二层是流程问题。真正承担这项工作的往往是店员或者店长，而他们同时还背着销售指标。对账占用的时间越多，能够投入销售和门店经营的时间就越少。

第三层是信息问题。两边的数据并没有天然打通，纸质单据又增加了人工核对的成本，所以人只能不断在不同信息之间做比对。

真正让我觉得这个问题值得做的，是我们后来发现：它除了省人工，还可能直接影响收入。

过去总部甚至会给门店设一个“容忍区间”，因为大家都知道人工对账太麻烦，如果差异在一定比例以内，就干脆不再追了。可是现在，如果机器能够把这些差异找出来，那么原来被忽略的钱，就有机会重新被识别出来。这个价值就从“节省几个人天”，变成了实实在在的收入增益。

所以从 FDE 的角度看，我最终优先选择的是业务价值最容易被验证的场景，把“AI 最酷的场景”往后放。

Q2在你参与之前，这个问题过去是怎么解决的？

原来的解决方案逻辑非常直接：拉多个系统数据、看总额、看分项、针对差异找原因。

对于一个店或者少量门店来说，人完全可以完成。

但问题是，业务规模扩大以后，人工方式的边际成本越来越高。

一个门店可能还能接受一两个小时甚至一天的核对，但当门店数量增加以后，每个周期都要重复做同样的事情。更麻烦的是，人工除了“慢”，还会产生连续的返工：发现差异、重新确认、修改，再核对；如果员工觉得某些差异不值得继续追，就可能直接放弃了。

所以，过去的方法本身并没有错，问题在于业务复杂度超过了人工方式的承载能力。

这也是为什么我后来越来越觉得，FDE 做 AI 落地的时候，不能上来就说“原来的流程太落后了，我们用 AI 替代”。真正应该问的是：原来的方式为什么能够运行？它在哪个节点开始失去效率？AI 究竟应该接管哪一部分？

在这个案例里，我们没有试图把整个对账流程全部 AI 化，而是先接管最标准、最重复、

最适合自动化的那一轮核对，把人从大量机械比对中释放出来。

这也是为什么员工最后对这个方案的接受度比较高。在他们看来，这更像是“有人已经帮我做完第一轮对账了，我只需要看结果和处理真正的差异”，很少被当成“又一个需要重新学习的系统”。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

这个案例真正让我觉得有价值的，在于我们怎么选这个问题，以及怎么控制交付范围，OCR 或者视觉本身反而排在后面。

第一步，是从客户提出的多个需求里排优先级。

客户当时并不只有对账一个需求，还提出过自动化客服、竞品对比等方向。

如果单纯从“AI 能做什么”来看，这些事情都可以做。但站在 FDE 角度，我会先问一个问题：哪个事情能够最快形成业务上的正反馈？

客服可能同时涉及效率和新增商机，需要积累比较长的数据周期，才能证明商机到底增加了多少；竞品分析则涉及后续多种运营策略，最终业务结果并不容易在短时间内验证。

相比之下，对账的价值非常直接：少花多少人工，可以很快看到；少漏多少钱，也可以直接计算。

所以第一个判断，重点是哪个任务最有可能最快得到正反馈，技术上是否最先进反而次要。

第二步，是把 AI 放在真正适合它的位置。

我们最后采用的是 OCR 加视觉的方式，对纸质/图像单据和相关信息进行识别、比对，再通过自动化工作流按照周期定时运行。简单说，就是让 AI 完成大量重复性的第一轮核对，把已经能够确认的结果先筛出来，再让人处理真正需要判断的部分。

这个方案其实并没有什么特别“炫”的技术。

但我反而认为这很典型：FDE 要做的，是找到一个足够简单、成本足够低、又能真正解决业务问题的方案，而未必是最复杂的技术。

第三步，是从一开始就考虑规模化，不只停留在 Demo。

当时我们只落了上海几个门店，数量还是个位数。但客户整体门店规模比较大，所以我在方案设计时就已经考虑了后续扩展的问题。

几个门店每个周期跑一次，和几百、上千个门店在接近的时间窗口里同时运行，对系统稳定性和 AI 出错后的冗余要求完全不一样。

所以我们一开始就把它拆成两个阶段。

第一阶段尽可能轻量，甚至在 Cherry Studio 加本地电脑的情况下就可以完成；第二阶段如果真正扩展到更大规模，就需要在后端数据和冗余机制上增加更多能力。

我比较看重这一点：轻量化不等于没有规划。可以先用最小成本验证价值，但从 DayOne 开始，就应该知道如果验证成功，下一步怎么走。

第四步，是尽量不给一线员工增加额外负担。

这一点其实很容易被技术团队忽略。一个新的 AI 工具，如果需要员工额外录入数据、重新学习流程、增加操作步骤，那么员工看到的首先是“我又多了一件事”。

所以我们尽量让 AI 出现在原有流程里面，不让员工重新建立一套流程。最终员工拿到的是已经经过第一轮处理的结果，无需再维护一个自己的系统。

我觉得这也是 AI 真正落地时一个很重要的细节：不要让用户先看到自己的投入，再等待未来的收益；尽量让他第一时间感受到收益。

Q4相比传统方式，使用 AI 后的实际效果如何？

最直接的变化，是时间从“人天”变成了“小时”。

过去一个周期可能要花一两个人天，甚至因为反复核对而把周期拉得更长。现在整个过程压缩到几个小时，员工只需要处理真正需要人工判断的部分。

但如果只把它总结成“省人工”，我觉得还是低估了这个项目。

真正让我觉得意外的是，AI 把原来被人工流程掩盖的问题暴露了出来。在实际数据里，有的门店差异在一两个百分点，有的能达到两三个百分点。这里面既有少收，也有多收，最终需要看净差异。但对于一家线下零售企业来说，即使只有一两个百分点，如果落到纯利层面，也已经是一个非常大的数字。

所以这个项目给我的一个很大启发是：AI 的价值有时候在于，让企业终于有能力把过去因为成本太高而放弃的事情重新做起来。现在核对成本降下来了，那部分被放弃的价值就有机会重新捡回来。

目前我们落地的还是上海部分门店，未来还有进一步扩大范围的空间。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个案例本身比较顺，但我们其实踩过不少坑。现在回头看，我觉得主要有三个挑战。

第一个挑战，是高估 AI 能力，低估真实行业的难度。

我们之前做过一个国内电商横向价格对比的案例。

当时我知道这件事情不容易，因为市场上已经有专门做电商比价的公司，人家背后有数据、接口，还有各种数据来源和业务门道。但当时还是有一个判断：我们觉得 AI 应该能够解决其中百分之七八十的问题。

真正开始做之后才发现，现实比想象复杂得多。

国内电商平台的风控和反风控一直在博弈，平台本身对快速价格查询、模拟人为操作等行为有很强的限制。即使找到一个方案，也可能很快被平台策略堵掉。最后导致交付周期拉长，能覆盖的场景也不断缩小。

这件事情让我意识到，AI 能力和真实业务难关之间，必须做匹配。不能因为模型和 Agent 现在很强，就默认现实世界的问题都能解决。

本质上还是行业认知不够。

如果一个行业里已经有公司专门靠某个问题生存，那就应该先认真研究：它到底解决了什么难点？它掌握了哪些信息差？为什么这个事情值得一家公司的长期投入？

第二个挑战，是需求调研不够深，导致后面不断返工。

另一个案例是学校批改作业和智能推题。

这个需求听起来非常顺：先批改，再给分，再分析，然后根据学生情况推题；题目还来自学校自己的题库。

但真正拆开以后，问题非常复杂。

比如准确率到底要多少？批改时效要求是什么？哪些科目？批改频率多高？题库需要结构化到什么程度？推题有什么规则？学生一道难题做错之后，是应该降低难度，还是继续围绕同一个知识点给他更难的题？人工到底在哪个环节介入？

这些问题如果前期没有问清楚，后面就会不断出现需求变化。

以前软件工程时代，这叫产品经理需求没定义清楚，研发不断返工；到了 AI 时代，本质没有变，只不过后面的“返工成本”还可能直接表现成大量 Token 消耗和交付成本。

所以现在我们做 FDE，会比以前更谨慎。技术调研要认真做，方案调研要认真做，业务调研也要认真做。

第三个挑战，是组织和责任边界没有提前对齐。

AI 项目很容易被理解成“老板想要、FDE 来做、一线员工来用”。但实际上老板、中层、

一线员工关注的东西完全不一样。如果前期没有把每个层级的目标、预期、能力边界和责任讲清楚，最后很容易出现“做得不好就是 FDE 的问题”。

所以我现在越来越强调一件事情：不仅要和老板对齐，还要和涉及项目的不同层级分别对齐。

谁负责什么，谁投入什么，做到什么程度算成功，AI 出问题之后谁判断、谁处理，都应该尽可能在前面讲清楚。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

如果让我把这次经历总结成几个最基本的原则，我反而不会先讲模型、Agent 或者工作流。我会先讲价值、优先级和信任。

第一，第一单一定要选对。

一个企业可能同时给你十个需求，但第一个项目不能只看哪个最有意思，需要综合判断：业务价值是不是足够显性、正反馈是不是来得足够快、涉及的人是不是足够少、业务流程是不是足够清晰、用户需要投入多少、技术成本是不是可控、最终价值能不能算出来。

没有所谓的“六边形完美任务”，最终一定是权衡。

对账这个案例之所以适合作为第一步，就是因为它在这些维度上比较平衡：涉及的人少，业务流程相对清晰，价值可以计算，AI 成本也不高，而且员工容易接受。

第二，第一版不要追求完美，要先跑出一个正循环。

我比较建议 FDE 做项目的时候，第一版先解决一个边界清晰的问题。做到客户认可，做到有人真正使用，做到价值能够被看见。

当第一个正循环跑起来之后，信任就建立了。第二个需求的容忍度会更高，再继续扩大，再继续扩大，最后形成一个持续的正循环。

这比一开始就承诺一个“全自动、全覆盖、一次解决所有问题”的方案，要健康得多。

第三，Day One 就要想清楚交付边界。

尤其面对中大型企业，不能做到一半才告诉客户：“这个还需要你买服务器”“这个还需要增加人”“这个还要改一套流程”。

客户的资源和信任都是真实存在的。所以在第一天设计方案的时候，就应该尽可能把技术路线、资源投入、后续扩展路径和可能的边界讲清楚。

第四，不要把 AI 落地简单理解成“替代人”

这是我自己比较坚持的一点。如果 AI 把一个岗位里百分之七八十的事情做掉，很容易让企业产生一个冲动：既然效率提高了，那是不是可以直接裁人？

但我认为，这很容易把 AI 项目变成企业和员工之间的对抗。更好的方式，是把省下来的人工带宽转移到更高价值的事情上。

比如客服人员不一定继续只做客服，可以去做用户研究、销售或者其他与客户交互相关的工作；投流团队不只追求“少几个人”，更看重人均犯错率下降、人均 ROI 提升。

这样 AI 带来的，是组织的业务目标升级，降本反而退居其次。

第五，FDE 最核心的能力，最后还是“懂业务”

AI 真正能够被快速放大的，是后端交付能力；但最难复制的，还是前端的行业认知、需求洞察和组织理解。

所以未来 FDE 可能会出现分层：有一小批人特别懂行业、懂组织、懂咨询，也懂 AI 交付；更多的人则可以在标准化、Agent 友好的任务上，通过成熟的工具完成稳定交付。

但不管是哪一层，最基本的问题都不会变。

我会要求团队一直回答这几个问题：客户真正关心什么？他以前是怎么做的？现在我们做完之后，他是怎么做的？我们到底给他创造了什么价值？和原来的方案相比，我们有什么优点，又有什么缺点？

我觉得这其实就是 FDE 最基本的“商业 101”。

会做就是会做，不会做就是不会做；懂这个行业就是懂，不懂就是不懂。不要因为 AI 和 FDE 现在很热，就把自己的能力边界包装得无限大。

真正好的 FDE，在于知道什么值得做、什么现在能做，以及怎么把能做的事情做到让客户真正看到价值。

当第一个小胜仗跑出来，客户看到了价值，员工愿意使用，业务愿意继续投入，AI 才真正从一个技术能力，变成了企业业务的一部分。

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

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

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

这是一家做外贸礼品的公司，产品包含起瓶器这类小商品，一年销售额大概有几个亿，但整个团队只有十几个人。公司业务跑了很多年，问题在于数据太多、太散，而且其中相当一部分是图片，比规整的文字和表格更难整理。

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

不同文件夹里。

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

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

这些事情单独看都不复杂。但真正的问题，其实藏在这些“小需求”下面。

首先是企业的数字资产并没有真正被组织起来。文件虽然都在电脑里，但 AI 不知道这些文件之间是什么关系，人自己也未必知道。

其次是企业缺少 AI 可以直接运行的环境。你不能说今天买一个大模型账号，明天企业就 AI 化了。网络、电脑环境、权限、文件结构、工作流程，这些都会影响 AI 到底能不能真正进入业务。

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

很多老板已经听过不少 AI 概念，甚至知道 Agent 是什么，但他们不知道这些东西跟自己每天遇到的问题到底有什么关系。所以 FDE 进去以后，我觉得第一件事是找到一个老板真正关心的问题，然后告诉他：这个问题，AI 能不能比你原来的方式解决得更好？

这才是起点。

Q2在你参与之前，这个问题过去是怎么解决的？

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

比如，老板花过大约 5 万元购买相关服务，对方可以基于国际站拿到一些数据，也搭建过外贸网站。这个产品本身有一定价值，但更接近一个标准化产品。企业遇到个性化问题以后，后续没有人继续陪他往下走，也没有人告诉他这个工具怎么和自己公司的工作方式结合。

我后来一直在想，为什么传统的软件和外包方式以前能够运行？

因为过去企业的问题相对明确。我要一个网站，就找人做网站；我要一个 ERP，就买 ERP；我要一个设计稿，就交给美工。一个问题对应一个工具或者一个人。

这种方式本身没有错。但随着业务越来越复杂，老板开始发现，公司里同时存在几十个、几百个非常碎的小需求。如果每一个需求都找一个外包团队开发，成本根本承担不了。

更关键的是，很多问题甚至没有清晰到可以直接写成需求文档。老板知道“这里不太顺”，但他自己都不知道应该开发什么。

我印象很深的是，这个外贸老板当时碰到一个客户需求。客户给了他一个类似三角尺的产品，上面有一排不规则的刻度。他们找过美工，也做过 3D 打样，但一直没有搞清楚这排刻度到底是什么，甚至准备人工照着抄，但又抄不准。

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

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

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

老板当时很惊讶。因为按照他原来的思路，这件事情可能要研究一两天。

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

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

真正开始做以后，我反而没有急着开发功能。

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

我们决定直接使用最顶尖的大模型，但到了企业现场才发现，他们内部的网络环境经过历年来自己不断的调整，非常复杂：4 台路由器、2 台光猫、1 台交换机，还有一个软路由，整个网络串得很乱，也时常不稳定。所以，为了让 Agent 具备更稳定和灵活的内网访问权限和工具，我第一天几乎是在当网络工程师。

这个开头也说明，企业 AI 落地的第一件事，常常是先把以前留下来的基础设施问题解决掉。公司内网不通、设备环境不一致，再好的 Agent 也跑不起来。

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

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

这一步比简单地把文件塞进一个所谓“知识库”要复杂得多。我们的做法，是重新组织散落在各台电脑上的资料，建立文件之间的关系，让 AI 知道哪些文件属于哪个客户、哪个产品、哪个项目，以及不同资料之间是什么关系。

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

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

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

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

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

我们前期花了几十个小时把框架做好，然后让客户侧的 Codex 继续跑大约 40 个小时。跑出来以后，老板开始测试。

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

这个过程对我来说很重要。因为它改变了过去“驻场工程师必须一直守在客户电脑旁边”的工作方式。数据不需要离开企业，开发和适配却仍然可以继续。

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

更重要的是，我们不想永远替企业做这些需求。

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

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

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

Q4相比传统方式，使用 AI 后的实际效果如何？

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

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

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

那个角标尺问题，老板本来以为要研究一两天，我们现场用 AI 大约 10 分钟就找到了产品来源和刻度含义。后来他觉得矢量图很难做，我们又直接问 AI 应该用什么工具，当场把矢量图做了出来。

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

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

一开始，老板只愿意拿一个很小、很具体、试错成本比较低的问题给我们。但在做出一些交付以后，他很快又提出了十几到二十个新的需求。

这个变化比单纯的效率指标更能说明问题。因为它意味着企业已经从“我要不要试一下 AI？”，变成了“我公司还有哪些问题可以这样解决？”

第三个变化，是老板对 AI 的判断开始从“买一个工具”，变成“重新思考公司怎么工作”。

我后来慢慢确信，对这类企业来说，FDE 最大的价值未必是帮他少雇一两个人。

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

尤其是我们接触的很多企业，本身正处于业务快速增长、人力跟不上的阶段。在这个时候，老板如果意识到未来新增业务不一定都要靠增加人力解决，这种认知变化带来的价值，可能远远超过某一个工具本身节省的成本。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

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

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

我们自己的程序在本地跑得很好，到了客户电脑上就会出现各种报错。原因也很简单，每一台电脑的环境都不一样。

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

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

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

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

AI 要真正发挥作用，就必须接触企业最有价值的资料。但恰恰是这些资料，老板最不愿意交出去。

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

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

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

但定制化产品必须有人真正使用，我们才能知道哪里不符合需求。有一段时间，我们甚至一直在催老板：“你有时间用一下，至少给我们留一点记录。”

后来我们自己开发了一个远程通道，让我们的 AI 可以在后台连接客户电脑上的 AI，在不影响员工正常工作的情况下完成一些任务。很多长任务放到晚上跑，双方都节省了大量沟通和等待时间。

回头看，这三个挑战没有一个直接关于模型，但每一个都能决定项目能不能真正跑起来。FDE 必须进入业务现场，原因就在这里。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这些项目，我慢慢看清了一件事：FDE 不能把自己理解成一个“AI 外包”。

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

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

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

不要一上来跟老板讲多 Agent 协作、Harness 或者企业智能体。老板真正关心的是：

“我现在这个问题，你能不能解决？”

而且这个问题最好是他正在为之付出时间、成本，甚至正在影响业务的。把这个问题解决以后，信任自然就会出现。

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

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

现在很多企业老板已经听过太多 AI 概念了。真正有效的是，把他眼前关心的问题拿出来，让他亲眼看到你的思考过程。概念听过以后很容易忘，但一个真实问题被当场解决，老板会立刻知道 AI 跟自己有什么关系。

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

我希望企业以后不用每遇到一个问题都来找我。做完一次项目，企业带走的应该是一套自己继续解决问题的方法，一个具体的工具反而不是重点。这样交付几次以后，企业遇到新问题时，第一反应会从“找人”变成“自己先试”。

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

你可能要修网络，要处理 Windows 环境，要梳理文件命名，要解决权限，要等老板开会回来，要催员工测试。这些看起来都不是 AI 技术，但它们决定了 AI 到底能不能进入真实业务。

FDE 最稀缺的能力，是能不能站在真实业务问题面前，把所有阻碍 AI 发挥作用的环节一个个拆掉。“懂多少个模型”反而是次要的。

最后，我觉得最理想的 FDE，是让客户越来越独立。

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

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

从人工盯图到公司级生产：FDE 用 AI 重塑鞋服电商素材工作流

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我这次进入的场景，是电商商品的内容生产。

我的客户是一家传统鞋服帽电商企业，有自己的工厂和设计师，主要在淘宝、天猫等平台销售产品，在行业里已经属于头部企业，年流水大概 10 亿元。

这种公司的一个特点是 SKU 非常多，而且新品上得很快。

一件商品上架，拍照、上传只是开始。每上一个新品，都要有商品主图、详情素材；现在视频电商起来以后，还要配套挂车视频。SKU 一多，后面的内容生产量就会跟着成倍增长。客户每天都有大量出图、出视频的需求，所以背后长期养着一支规模不小的设计和运营团队。

面对这么大的需求，我一开始也很容易把问题想简单：设计师出图太慢，那就用 AI 帮他出图。但我真正进到现场以后，发现事情没这么简单。

首先是成本问题。传统模式下，企业需要大量设计和运营人员持续处理素材，人力成本本身就很高。

其次，即便企业已经开始用 AI，也不意味着效率问题自然解决了。

他们原来的使用方式比较分散，每个人自己开 AI 账号，自己写提示词。看起来大家都“用上 AI 了”，实际上只是把一个新工具塞进了旧流程里。操作成本没有真正消失，效率也没有出现质的变化。

第三个问题是品控。

设计师的审美、经验和 AI 使用能力不一样，最后生成的东西自然也不一样。能力强的设计师可能很快就能得到不错的结果，但这样的人在任何公司都是少数。企业不可能把整个内容生产体系建立在几个高手身上。

除了成本、效率和品控，还有一个当时客户非常关心的问题：这些内容到底是谁的资产？

以前设计师做出来的图片、视频，很可能就散落在个人电脑里。一个人离职、换岗，素材也可能跟着断掉。对这样体量的企业来说，这意味着大量已经投入成本生产出来的内容，并没有真正变成公司的资产。

所以后来我们重新定义了这个问题。我们要做的，是帮企业解决一个更根本的问题：怎么利用 AI，把原来依赖个人能力、分散运行的内容生产过程，变成一套公司级、可复用、可管理的生产能力。

我做 FDE 时，一直比较看重这一点。我通常站在业务负责人、实际使用者和 AI 技术之间。我要负责的，是先判断客户真正的价值主张是什么，再考虑 AI 怎么进去，怎么重塑流程、整合原有资源。

Q2在你参与之前，这个问题过去是怎么解决的？

在业务规模还没这么大、AI 能力也没有发展到今天这个阶段的时候，用设计师和运营团队支撑内容生产，是非常自然的一种方式。

设计师理解商品，也理解品牌审美。企业需要什么图，他们就做什么图。这套模式已经支撑客户把业务做到很大的规模，本身证明它是有效的。

问题出现在业务复杂度越来越高以后。SKU 越来越多，图片越来越多，视频越来越多。

业务量增长以后，企业想继续扩大内容供给，最直接的方法就是增加人。于是内容产能和人力数量开始越来越强地绑定。

后来 AI 出来以后，客户其实也很积极，并没有完全不用 AI。他们开始让员工自己使用各种 AI 产品，希望借此提高效率。

但这又进入了第二个阶段：以前是“人做图”，后来变成了“人盯着 AI 做图”，人还得自己反复调整。更麻烦的是，这种方式会把人的差异继续放大。

同样一套工具，不同的人用出来，结果完全不同。所以从企业角度看，这依然谈不上稳定的生产能力。

后来我据此判断，单纯给企业采购几个 AI 工具，或者教员工怎么写 Prompt，都解决不了根本问题。AI 真正要改造的，是整条工作流本身。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

这个项目里，我花时间最多的事情，是真需求的挖掘，以及价值主张到底成不成立。写代码反而排在后面，AI 辅助以后尤其如此。

第一步，先到现场，不急着做产品。

项目早期，我会花比较多时间待在客户现场。

因为 FDE 要解决的问题，本质上是怎么把 AI 技术和行业 Know\-how 结合起来。只听老板讲需求是不够的，我必须看到员工实际上怎么工作。

我会先识别整个项目里的关键干系人。老板关注的是企业战略转型，这件事情到底有没有长期价值；管理者关注的是成本、效率和管理；基层员工想的则完全不同，这东西会不会给我增加工作量，做完以后是不是要把我裁掉。这些问题如果不处理好，技术做得再漂亮，也很难真正推下去。

所以我会去观察员工每天到底在干什么，上下游怎么协作，资料怎么流转，大量时间耗在哪里。比如员工会跟我抱怨，每次生图都要写很长的提示词，生成完还有水印，还得再处理。

这些问题对他们来说很麻烦，但对我们来说可能只是一个很小的工具或者流程调整就能解决。我通常会先把这种小问题解决掉。因为员工马上就能感觉到，你来这里，是真的能帮他少干一些重复工作的。这其实是一个非常重要的破冰过程。

第二步，把“想要 AI”变成一个可以验证的价值主张。

我们会通过数据采集、工作流梳理、访谈等方式，把真实需求一点点挖出来。不会花几个月先做一个“大而全”的产品。

需求确认阶段，我们就会借助 AI 快速做 Demo，马上拿给客户看。客户说这里不对，我们就改；员工用了以后发现操作不顺，我们继续调。

所以整个过程的节奏是，调研 → Demo → 使用 → 反馈 → 再迭代。而且反馈也不会聊完就放下，我们会把这些意见沉淀进文档，让客户在指定的位置持续填写。

第三步，重新搭工作流。

做到这里以后，问题已经越过“选哪个生图模型”这个层面。我们开始考虑 AI 生成怎么跟商品、素材和企业原来的生产流程连接起来。

一个很重要的方向，就是把生成出来的图片、视频直接沉淀下来，逐渐形成公司级素材资产；商品本身也要进入统一的商品管理逻辑。这一步在我看来非常关键。

如果 AI 只是帮员工今天多做了十张图，明天还要重新开始，那它只是工具。如果每一次使用都在给企业留下数据、素材、流程和经验，AI 才开始真正进入企业的能力体系。

第四步，把“好看”变成“能商用”。

电商生图跟普通 AI 生图有一个非常大的区别：图好看只是基础，真正要紧的是，卖出去的东西必须就是图上的那件商品。比如一件衣服，AI 可以给你生成一张非常漂亮的模特图，但如果衣服的版型、颜色或者细节变了，这张图越漂亮，商业风险反而越大。

所以我们把“一致性”直接放进验收标准。三个层面分别是人物一致性、服饰一致性和场景一致性，只有这些达到要求，才算通过。

审核我们仍然保留了人工环节。我们的做法是 AI 先做第一道检查，再交给人工确认，因为最终这个素材是否符合品牌审美、能不能真正使用，还是要尊重实际使用者的视觉判断。

这也成了项目里的一条原则：AI 负责规模化，人负责最后的业务判断。

第五步，用 POC 来证明价值。

项目核心功能完成以后，我们进入了 POC 阶段。

这时候要做的，是推动企业内部员工真正使用，光自己坐在那里测不算数。他们试用以后，把优化和改动意见反馈回来，我们再继续迭代。

对我来说，只有到了这个阶段，才开始真正回答“这套东西能不能进入企业日常工作”，Demo 看起来再好看，也回答不了这一点。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目目前仍处于 POC 测试、内部试用和持续迭代阶段。我们现在关注几个实际变化。

第一个变化，是员工开始真正使用。验收的标准，从项目团队自己的感觉，变成了设计师到底有没有把这套能力用起来、它和原来的工作流契不契合。

第二个变化，是内容开始从个人产出变成企业资产。

生成、管理和后续使用逐渐进入统一流程。这个变化短期不一定能直接折算成多少钱，但对企业来说，它解决的是组织能力能不能留下来的问题。

第三个变化，是 AI 生产开始有了明确的质量边界。

现在验收会覆盖还原度、图片质量、视频能否商用，以及前面说的一致性，效果不再高度依赖某一个人的水平。所以我理解的“效果”，已经超出了“以前一小时做几张、现在一小时做几张”。

更重要的是，企业有没有开始形成一套稳定、可控、可以沉淀、可以继续扩大的内容生产方式。这才是我们真正想验证的价值主张。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

我觉得最大的挑战，其实不在模型本身。

第一个挑战，客户对 AI 的认知。

企业里经常会出现两个极端。一种人觉得，“我们现在挺好的，为什么要折腾 AI？它到底对我有什么价值？”另一种恰恰相反，觉得 AI 无所不能，甚至会期待“花 10 万元，就应该给我做出 100 万元的效果”。

这两种认知都会给项目带来问题。

所以后来我反复强调一件事：AI 一定要放进真实产业场景里跑。与其讨论 AI 理论上能做什么，不如回到这家企业今天的业务流程，看哪个环节值得改、能不能改、改完以后价值怎么验证。

第二个挑战，基层员工。

这是很多 AI 项目特别容易忽略的一层。

老板可能非常积极，但真正每天使用产品的是设计师、运营。他们很自然会担心，你做这个是不是准备取代我。如果这种情绪没有解决，你拿到的需求可能都是假的，最后产品上线以后也没人愿意真正使用。

所以我们一进去，没有跟员工讲“AI 转型”这种大词，先把他们眼前的小麻烦解决掉，把关系建立起来。然后再跟核心人员把目标说清楚，AI 是来帮大家从低价值重复劳动里脱身的，让他们把时间用在更有价值的事上。

第三个挑战，AI 本身的不确定性。

生成内容最怕的是“看起来很好，但商品不对”。所以原来如果只是追求“生成效果好看”，这个标准就不够用了。

我们后来把验收标准重新拉回业务本身，前面定下的那几项硬性要求，一项都不能松。

而且不能因为用了 AI，就把审核也完全自动化，最终的业务责任，仍然要交给人。

AI 可以提高效率，但最终的业务责任，不能交给模型。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做完这些项目以后，我愈发确信，FDE 的核心竞争力，早就超过了“会多少 AI 工具”这个层面。真正难的，是找对问题，再让 AI 真正进入业务。

我现在比较看重几个原则。

第一，先判断价值，再决定做不做。

FDE 和传统外包一个很大的区别就在这里。外包接到任务就去把它完成，FDE 会在开始之前先判断，这件事值不值得做，未来有没有拓展性。因为 FDE 最终要为结果负责，“功能有没有按时交付”只是其中一环。

第二，一定要进现场。

很多需求在会议室里是问不出来的。要真正进到现场，看员工每天的时间到底花在哪里，真正的痛点经常藏在这些细节里。

第三，先快速做出东西来验证，不要追求一步到位。

调研之后，尽快做出一个能用的东西，让客户用起来，反馈之后再改。AI 时代给了我们快速试错的能力，应该把这种能力用在产品验证上，让客户早一点看到东西。

第四，把 AI 嵌进流程里。

如果原来的工作方式完全没变，只是每个人多了一个 AI 账号，那谈不上真正的 AI 改造。

真正的改变是，原来的哪一步可以取消，哪一步可以自动完成，哪些信息可以沉淀，谁负责最后判断，新的上下游关系应该怎么连接。

第五，每做完一个项目，都要问自己能不能产生复利。

比如这次做鞋服电商，我们会继续问，只有这家公司需要吗，换一家鞋服企业是不是也有类似问题。如果答案是肯定的，那它就从“一个客户的定制需求”变成了“一个行业级问题”。

既然已经用一个客户完成了 0 到 1 的价值验证，下一步就应该考虑怎么从 1 做到 100，把经验复用出去。所以我们也会有意识地沉淀自己的“家底”。

如果决定深耕电商，就要思考这个行业最基础、最通用的能力是什么。商品中心、订单中心、用户中心这些能力，未来都可能成为下一次交付时可以直接复用的基石。

我理解的 FDE，最终其实有两条飞轮。

一条在客户外部，项目做得越来越多，对产业和客户的理解越来越成熟。另一条在组织内部，每做一个项目，就把方法、组件和经验留下来，再复用到下一个项目。

如果每做完一个 AI 项目，只有客户拿到了一个系统，而 FDE 自己什么都没有沉淀下来，那这个项目其实还没有真正结束。

真正有价值的 AI 落地，既让客户的业务能力沉淀下来，也让 FDE 下一次解决同类问题时，站在一个更高的起点上。

从纸质流程到数据驱动：FDE 用 AI 推动传统消防维保企业数字化转型

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我进入这家企业时，他们主营消防维保业务，主要承接物业等客户的消防检查、维护和维修工作。企业规模不算特别大，但业务稳定，属于典型的传统行业，有大量线下执行环节。

这个行业不缺业务，问题在于业务增长过程中，原有的管理模式越来越难支撑企业发展。

我进入现场后，从两个完全不同的视角看到了问题的全貌。

从老板的角度看，最大的痛点是“看不见”。他知道企业每天在做业务，但无法实时掌握一线情况：哪些项目的维保执行到位了？哪些客户存在消防风险还没有处置？甚至一些影响回款的重要维保记录，也可能因为人员变动、资料遗失而无法及时找到。他只能通过周期性的汇报了解业务状态，而汇报和现场之间，永远隔着一层信息差。

从一线维保人员的角度看，问题又完全不同。他们的核心工作是检查消防设备、完成维修，但大量时间消耗在业务之外：填写纸质表格、整理 Excel 数据、打印传递归档、反复和各方沟通确认。有些时候，一个表格的填写和整理就能占用半天时间。这些工作对他们来说是纯消耗，不产生任何直接业务价值。

更深层的问题是数据割裂。检查记录在纸质表格里，维修记录在 Excel 里，客户信息在某个人的微信聊天记录里，设备档案可能散落在不同文件夹中。这些数据按照监管要求做了保存，但没有形成统一体系，查找困难，也无法支持管理决策。

从 FDE 视角看，这个问题的本质超越了技术层面。消防维保业务中，真正棘手的是业务现场、管理需求和执行流程之间的断层。企业真正缺失的，是一套能够同时连接管理者、一线员工和业务流程的解决方式。

Q2在你参与之前，这个问题过去是怎么解决的？

在我进入企业之前，他们基本没有完整的软件基础设施。

去年企业曾尝试和外部团队合作，引入过一个监控平台，希望迈出数字化第一步。但除此之外，企业内部没有形成完整的数据体系和流程系统，日常运转主要依赖经验驱动。

在业务规模较小的时候，这种方式勉强可以维持。老板靠多年行业经验判断业务状况，员工靠熟悉流程完成工作。但当行业利润空间持续下降、企业希望拓展新业务机会时，经验驱动的模式开始暴露出明显短板。老板意识到需要借助数字化和 AI 提升效率，但并不清楚从哪里入手。

不过，对于传统企业来说，直接购买一个大型系统的成本往往难以负担。很多外部方案功能列表看起来很完善，但没有真正理解企业现场的监管流程和实际执行方式。最坏的情况是，系统上线后变成员工额外增加的一套操作流程，不仅没有减负，反而加重负担。

这家企业也面临同样的困境。他们看到 AI 和数字化的价值，但缺乏一个既懂业务现场、

又能翻译技术方案的角色来帮助判断：到底从哪里开始？什么值得做？什么不需要做？

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我做 FDE 的第一步，是进入现场理解业务。

很多时候，老板自己也不清楚真正的问题在哪里。老板看到的是经营结果，员工面对的是每天具体的流程。如果只通过管理层访谈拿需求，很容易拿到“看起来正确”但实际上偏离核心问题的需求。

所以我直接和维保人员、人事、行政、财务等角色逐一沟通，观察他们真实工作的过程。维保人员怎么填写检查表？资料怎么流转？哪些环节需要反复确认？哪些步骤让他们最头疼？

正是在这个过程中，我发现此前设计的方案存在方向性问题。一开始我们计划建设一个完整的业务平台，但走到现场后发现，企业已经部署了政府监管要求的软件流程，这套流程无法开放接口。如果再增加一个完整系统，意味着员工需要在两套系统之间重复操作。

这意味着原来的方案必须调整。

调整后的思路很明确：在已有流程基础上做最轻量的改造，重新建设一套完整流程既不现实，也会增加员工负担。

整个推进分为两个阶段。第一阶段，先帮助企业完成流程数字化，把原本在纸质表单和 Excel 中流转的数据迁移到线上，让信息能够被记录、沉淀和管理。这一步的目的是先让企业拥有自己的数据基础，为后续 AI 介入创造条件。

第二阶段，在数字化流程中寻找 AI 真正适合介入的环节。判断标准很明确：找到业务流程中真实存在成本的环节，再判断这个环节是否适合 AI 介入。先问“哪里存在真实的业务成本”，再考虑“这里是否需要用 AI”。

举个例子，维保人员填写月检表时，经常需要重复输入类似的问题描述。某些设备长期存在相同异常，每个月都需要复制粘贴几乎一样的内容。这类场景中，AI 可以辅助生成和调用历史记录，减少重复劳动。

在技术方案设计上，我们采用的是分工协作模式：系统负责流程记录和数据沉淀，AI 负责处理复杂信息、辅助生成和降低重复工作，人负责最终判断和业务决策。大模型擅长从非结构化信息中提取和生成内容，但业务流程的完整性和数据准确性必须由专业系统保障，最终的消防专业判断必须由人来做。

Q4相比传统方式，使用 AI 后的实际效果如何？

目前项目仍处于持续推进阶段，尚未形成大规模的业务指标变化，但已经可以看到几个层面的实际价值。

首先，企业管理方式发生了变化。过去企业运转高度依赖老板个人的行业直觉，现在通过数字化流程，企业开始逐步拥有自己的数据资产。管理者可以更清楚地了解业务状态，知道哪些项目在执行、哪些环节存在风险，降低了信息不对称带来的管理盲区。

其次，员工工作方式发生了变化。数字化的目标很明确：减少员工在重复填表、整理资料上的低价值消耗。维保人员如果能把省下的时间投入真正的检查和维修工作，交付质量和客户满意度都会随之提升。

第三，企业能力在长期沉淀。传统企业最大的短板是经验掌握在个人手里，人员变动就可能导致能力流失。通过数据沉淀和流程标准化，企业可以逐步把依赖个人经验的能力转化为组织能力。

此外，我还帮助企业避免了一次无效投入。此前企业曾考虑花费约 10 万元采购一套外部业务系统，但经过现场调研发现，对方方案没有充分考虑行业监管流程和实际执行方式，真正上线后无法使用。经过重新梳理，这笔采购被及时叫停。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

第一个挑战：需求真实性。

在最初沟通阶段，一线员工提出了一些需求，但走进现场深入观察后发现，很多需求偏离了核心问题。原因是员工在正式访谈环境中，很难完全表达真实的工作状态。特别是外勤维保人员，平时很少回公司，如果坐在会议室里面对老板和管理人员，容易产生压力，只会被动回答被问到的问题。

我的做法是调整调研方式。不依赖会议室访谈，走进他们的日常工作场景。看他们怎么填表、怎么交接资料、哪个步骤反复出错、哪些信息需要反复问别人。通过现场流程反推真实痛点，从实际工作中把真正影响效率的问题找出来。

第二个挑战：基层接受问题。

员工最初对数字化心存顾虑。他们担心这意味着更严格的管控，担心自己的工作过程被完全记录，也担心需要学习一套全新的系统。如果只考虑老板需要的数据透明和风险管理，忽略员工的感受，系统做出来也不会有人愿意用。

所以在设计流程时，我们同时兼顾两方诉求。对老板，解决数据透明和风险管理；对员工，解决工作效率和流程负担。让一线人员感受到数字化是在帮他们减负，把时间还给真正的专业工作。只有同时满足双方需求，系统才可能真正落地使用。

第三个挑战：避免过度建设。

在推进过程中，始终面临一个选择：做完整方案还是做最小可用功能？完整方案看起来更专业、覆盖更广，但对传统企业来说，每增加一个功能就意味着员工需要额外学习和适应。最终我们选择了更务实的路径：拥抱飞书等企业已有的基础工具能力，通过小模块、小功能逐步推进迭代。简单方案往往更容易落地，也更容易根据反馈快速调整。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

第一，从业务问题出发，把 AI 放在解决真实问题的位置上。

很多企业看到 AI 后会先问：“我们哪里可以用 AI？”但正确的问题应该是：“我们的业务流程里，哪里存在真实的成本和效率问题？”AI 只是解决问题的手段之一。如果一个问题通过简单流程优化就能解决，就不一定需要 AI。只有当数字化之后发现某些环节仍然存在大量低效劳动，再考虑用 AI 降低成本。

第二，FDE 必须具备业务理解能力，必须进入现场。

FDE 区别于传统技术岗位的关键，在于不能只接受需求文档。很多时候，真正的问题不会被准确描述出来。老板不知道具体需求细节，员工在正式场合未必敢表达真实想法。

只有深入一线，观察真实工作流程，才能把业务语言和技术语言连接起来。在这个项目中，正是现场观察让我发现原方案的方向性错误，及时调整了方向。

第三，AI 项目成功取决于落地细节。

一个 Demo 很容易做出来，但从 Demo 到真正融入日常使用，中间有大量需要验证和调整的环节。需要找真实用户测试，根据反馈快速调整，控制系统复杂度，保证成本可接受。FDE 的核心价值在于连接业务、技术和用户，让 AI 真正进入企业流程并产生价值。

开发工具只是起点，推动工作方式的实际改变才是目标。

未来真正有生命力的 AI 应用，必然深入企业真实业务流程，超越停留在演示阶段的浅层应用。这也是 FDE 存在的意义：让 AI 从实验室走向真实世界。

从技术交付到业务自驱：FDE 用 AI 推动国企工作流程真正落地

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我这个案例的客户，是一家省属国企一级子公司，业务覆盖服装、美妆、3C 等十多个电商业务线，已经完成了比较扎实的数字化建设，有 OA、ERP、数据中台，也有自己的信息化部门。

管理层在 GPT 等大模型出现之后提出了一个很模糊的要求：既然公司的数字化建设在国企中已经领先，能不能再往 AI 走一步？

如果只听这句话，你可能会觉得这不过是一次常见的“企业上 AI”项目。但我们真正进入现场以后，发现这其实不是一个技术问题。

业务在增长，但国企有编制限制，人员并不能跟着业务无限增加。真正懂电商、懂业务的人才也不一定愿意进入国企来从事这方面的工作。所以第一个真实问题其实是：业务要扩张，团队能力却很难同步扩张，怎么办？

第二个问题来自内部管理。国企的合规要求严格，业务越多，法务、财务、纪检等内控岗位的压力就越大。比如法务团队只有两个人，却要面对不同业务线、不同合作伙伴的大量合同。很多事情不能简单靠增加人手解决，因为真正懂业务的外部律师也不好找。

所以我们后来复盘的时候发现，客户说的“AI 化”，背后至少有几个真实需求：业务增长之后如何提效，专业岗位如何承接更多工作，以及企业里大量依赖个人经验的工作，能不能变成一种可复用的能力。

这里面最重要的一步，是把表层需求和真实需求区分开。

高层不会直接告诉你：“我希望法务少招一个人”，“我希望员工的重复劳动减少”。他只会说：“我们要拥抱 AI。”FDE 真正要做的，是进入业务现场以后继续往下问：做什么？为什么现在要做？哪个环节最痛？这个痛点究竟是人不够、流程不清、数据没有沉淀，还是组织机制的问题？

我后来逐渐明确的一点是：先把客户真正的问题找出来，再决定做什么。

Q2在你参与之前，这个问题过去是怎么解决的？

传统企业的软件交付是这么做的：企业有一套相对成熟的软件和流程，技术团队根据客户的实际情况做配置、开发和定制。简单的就配置一下，复杂一点就开发模块。再复杂一点的就要先做咨询，把企业的业务流程梳理清楚以后再交付系统。

这套方式过去完全能跑通，但它的前提是软件行业几十年的最佳实践，能被信息化覆盖的业务部分，是能被讲清楚、流程相对固定。而企业落地 AI 的真正难点，恰恰藏在“几十年的最佳实践”这里。

很多企业知识根本没有被沉淀，被结构化。比如法务以前审核过很多合同，但最终只留下了一份修改后的合同，中间为什么修改、哪些条款是关键、哪些地方不能省，可能都在法务脑子里。客服也是一样，员工可能已经在脑子里形成了一套知识体系，但这些知识并没有真正沉淀到 AI 可以使用的数据系统中。

流程也是同样的问题。一个人把一件事情做了几年之后，会觉得很多步骤“理所当然”，甚至意识不到自己其实是在执行一套复杂流程。可对于 AI 来说，这些步骤如果不被明确梳理出来，大模型就只能自己“生成”。

所以传统方式的真正问题，到业务规模变大、流程越来越复杂以后才暴露出来：靠人、

靠经验、靠传统软件定制的方式，开始越来越难继续扩张。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我们其实是边做边调整的。

最开始进入这家企业，我们也先按传统思路来：以技术人员为主，把技术底座搭起来。

当时我们认为，只要把知识库、模型能力、Agent 这些东西搭起来，再接到客户已有的信息化系统里，AI 就能够逐渐进入业务。

技术上确实能做出东西，但做到一定程度以后，我们发现不对。系统有了，客户的员工没有用起来，业务并没有真的发生变化。真正难的其实是业务知识、数据、流程和人的问题，技术只是其中一部分。

所以我们的做法后来逐渐变成了几个层次。

第一步，先判断这个场景到底值不值得做。

我们不会再看到一个问题就马上做 Agent。而是逐渐形成了一个基本判断：一个场景首先要看价值和可行性。有些事情技术上目前做不好，就不要硬做；还有一些事情虽然技术上能做，但实际价值太低，也没有必要做。

这个判断帮我们避免了很多“做出来没人用”的玩具。随着这套框架逐渐形成，团队现在会先判断场景有没有真正的价值，再决定是不是投入。

第二步，把业务知识真正“挖”出来。

我们发现，单靠技术人员不够。

因为我们虽然懂 AI，但不一定懂客户的美妆批发业务，也不一定知道这个企业具体怎么做合同、怎么审批、怎么管理业务的。所以我们引入了“知识萃取师”这个角色。

知识萃取师和传统咨询不太一样。传统咨询往往有行业案例和成熟模板，可以拿一套方法去判断客户应该在哪个环节提效。但我们需要的是把客户自己脑子里的知识和经验真正萃取出来。

因为企业最了解自己的业务。外部的人即使懂这个行业，也未必知道这家公司为什么这么做。

所以我们开始要求业务人员把原来的工作过程讲出来，到底怎么做、为什么这么做、哪些情况例外、什么情况下必须人工判断。

这个过程本质上是在给 AI 准备“业务世界”。

第三步，把隐性的知识和流程变成 AI 能够理解的东西。

有了知识以后，才谈得上知识库、RAG、Agent 和工作流。

我们会去做知识加工、知识库管理，把原本散落在文档和人员经验里的内容沉淀下来；

同时把一个岗位原来依赖经验完成的工作拆成明确流程。

因为通用 LLM 模型的本质是概率生成（这也是幻觉的来源），它对 A 公司的电商流程理解正确，并不意味着对 B 公司的流程也正确。所以真正进入企业以后，我们不能简单地告诉模型：“你自己理解一下这个业务然后去做。”

流程必须来自企业自己。后来我们会特别强调“先梳理流程，再做 Agent”。

第四步，让员工真正学会用 AI。

这是我们最大的一个转变。

最开始我们以为，董事长要求业务骨干来配合项目，找几个人就可以开始做。结果员工来了以后，我们发现他们可能连提示词是什么都不知道。你让他配合知识萃取，他甚至不知道应该提供什么。

所以我们又增加了培训。与其项目组每个人一点点教，不如直接给相关部门做 AI 通识培训，让业务人员具备基本的 AI 认知，具备组织向 AI 协同转型的认知。

正是这个原因，我们一方面是“IT 部门牵头的技术项目”，另一方面是“人事部门牵头的组织转型项目”。

第五步，让 AI 成为员工的助手。

这是进入大企业以后非常重要的一件事。我们在员工面前从来不强调“AI 替代人”。

一方面，有些业务涉及法务、财务等责任问题，AI 最终不能承担责任，所以真正进入工作流的 Agent，大部分最终都需要人确认。

另一方面，这也是一个组织问题。如果员工觉得：“你让我把我的知识全部交出来，然后 AI 把我的工作替代掉，那我为什么要配合？”那整个项目从一开始就会产生阻力。

所以我们设计的时候，会让 AI 负责大量重复工作，但最终仍然由人确认、签字和承担责任。这样既保证了业务安全，也让员工清楚地知道，AI 是帮自己分担重复工作的助手。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目让我比较深的一个感受是，AI 落地的效果，不一定都应该用“节省了多少人”来衡量。

当然，有些场景可以量化。比如在法务场景里，我们帮助企业根据历史合同和业务信息去识别关键条款、发现风险，再交给法务最终确认。

原来法务需要从头到尾自己看，现在 AI 可以先帮他做一轮筛查，把需要重点关注的内容挑出来。

客户原本至少还还要招一个法务，因为有了 AI 法务助手，这个招聘的编制就节省下来了。并且目前两个法务工作状态也比较正常。如果一定要用人数去折算，那就是一人年的综合成本。

但我觉得更有价值的，其实是另一种变化。

我们做过一个很小的行政场景。企业里有办公用品自助柜，员工可以刷工牌领取电池、

笔、本子等办公用品。自助柜方便了员工，却给行政人员增加了补货管理的工作。

员工到了柜子前发现电池没了，只能发消息给行政人员。行政人员什么时候看到、什么时候补货，也不确定。

这个事情当然可以用传统软件解决。我们完全可以在 OA 里做一个页面或者弹窗。但真正有意思的事情是，这个小工具是负责行政物品的同事自己通过 AI 提示词做的。

在我们全员培训以后，他发现了自己工作中的这个需求，然后通过 AI 平台，基于数据中台的 MCP 能力，用提示词做一个简单的 Agent。员工可以在 IM 上直接问机器人：“我今天要领两节电池，还有没有？”系统去查库存；库存不足时，就提醒行政人员补货。补货完成后发送信息给需要电池的员工。

这个工具本身的业务价值并不大，但它让我们觉得特别重要，有一种特别的含义。

以前这位同事遇到这个问题，需要要找 IT 部门提需求、排期、开发、内部结算工时。现在，他自己已经可以想“这个问题我能不能用 AI 解决？”

这时候，FDE 交付的就多了一层意义：它在企业内部培养出了新的 AI 使用者，新的 FDE。

这可能比我们这些外部团队替他做一个 Agent 更重要。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

我们踩过最大的坑，其实不在技术。

如果让我给企业 AI 落地的难度排个序，我现在的排序是：人最难，其次是组织，再是数据，最后才是技术。以前总说万事俱备差个技术。现在技术反而是现在没有那么难的部分。

第一个挑战，是业务人员不一定愿意把自己的知识变成组织资产。

尤其当员工觉得组织使用 AI 最终是为了替代自己时，他自然不会主动把自己的经验、流程和知识全部告诉你。

所以我们必须从“替代”切换到“助手”，同时让企业的人事制度、激励机制跟上。

正因如此，我们后来一定要让人事部门参与进来。AI 本身就是一个组织工程，需要企业去思考：员工为什么愿意参与？AI 帮员工完成重复工作之后，他接下来做什么？有没有业务增长？有没有晋升路径？有没有新的激励？

第二个挑战，是技术部门牵头并不一定是最好的组织方式。

我们第一年就是 IT 部门牵头，技术底座也做出来了，但后来遇到了瓶颈。

因为 AI 真正深入业务以后，问题的重心从“系统怎么做”，转到了“员工怎么用”“流程怎么改”“组织怎么配合”。

所以今年我们让人事部门牵头，从培训开始重新推进。

这个转变看起来有点反直觉，但恰恰是我们服务两年以后踩坑踩出来的经验。

第三个挑战，是数据并没有我们想象中那么完整。

这家企业是数字化基础很不错的代表，但仍然有大量业务没有结构化沉淀。很多新业务、内控业务和人工操作环节，数据可能根本不存在；即使存在，也未必按照 AI 需要的方式总结归纳。

所以不能因为客户有 ERP、有数据中台，就默认它已经做好了 AI 的准备。

我们后来甚至开始尝试建立自己的企业 AI 成熟度模型，从流程能不能被萃取、数字化程度怎么样、AI 到底能实现到什么程度等维度，去判断一个场景适不适合做 AI。

所以如今再去看一个 AI 项目，我会特别警惕两种极端：一种是客户觉得“AI 什么都不能干”；另一种是客户觉得“既然 AI 什么都能干”。

实际上，很多时候问题出在企业自己的流程没有梳理清楚、数据没有沉淀、组织机制也没有准备好，AI 能力本身反而是次要的。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

如果让我把这两年的经验压缩成几句话，我现在最看重的，其实是怎么把下面这几件事做好，Agent 本身反而排在后面。

第一，先判断问题，再选择 AI。

不要为了 AI 而找场景。一个问题值不值得做，要同时看价值和可行性。技术做不到的不要硬做，做出来没有价值的也不要做。

第二，先把业务流程讲清楚，再谈 Agent。

很多人一上来就问：“这个场景能不能做个 Agent？”我的答案通常是：先别急。

先问这个岗位到底是怎么工作的。把隐性的经验、判断和流程拆出来。因为企业里的很多流程，业务人员自己已经习惯到感觉不到它存在了，但 AI 必须知道这些东西。

第三，不要把 FDE 简单理解成一个“产品经理\+全栈工程师”。

现在回头看，FDE 真正的价值，是打通业务和技术之间的鸿沟。FDE 可以是业务人员往技术方向发展了一点，也可以是技术人员往业务方向走了一点。但这个岗位对于人的要求其实很高。

以目前的现实来看，当前一个成熟的 FDE 交付团队，仍然需要分工。有人负责业务咨询，有人负责知识萃取，有人负责培训，有人负责技术开发，各司其职。

第四，中大型企业的 AI 落地一定是一号位工程。

如果老板只是说一句“我们要 AI 化”，然后把事情扔给 IT 部门，最后很容易变成一个技术项目，最后大概率面临失败。

但真正进入业务以后，人事、业务负责人、团队负责人甚至一号位都需要参与进来。因为 AI 最终改变的，是组织的协作和工作方式。

第五，最终目标是让企业自己长出 AI 能力。

这是我现在觉得最有意思的变化。

我们做那个行政小工具的时候，真正产生价值的，是那个原本不懂技术的行政人员开始意识到，我工作里遇到的问题，也可以自己用 AI 解决。

当企业员工开始主动发现问题、主动拆流程、主动用 AI 解决问题的时候，FDE 才真正完成了从“交付工具”到“改变组织能力”的转变。

所以如果让我重新定义 FDE，我可能不会把它理解成“去客户现场帮他做 AI 的人”。

我更愿意把它理解成：进入业务现场，把企业真正的问题找出来，把 AI 嵌进真实工作流，同时帮助客户逐渐获得自己解决问题的能力。

因为 AI 的技术门槛一定会越来越低。今天我们会写提示词、会搭 Agent，可能是一种能力优势；但过几年，AI 会更成熟，企业员工自己都会用 AI 工具。

到那个时候，FDE 真正留下来的竞争力，就是我比别人更懂你的业务，积累了更多真实场景、流程、知识和交付经验，知道什么值得做、什么不值得做，以及怎么让一个 AI 能力真正进入组织。

这也是我现在做企业 AI 落地时越来越看重的事情：技术会越来越普及，但对业务的理解、长期的客户积累，以及把 AI 真正落到组织里的能力，反而会越来越重要。

从经验写稿到稳定量产：FDE 用 AI 重构本地生活短视频内容生产

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我接触到这家公司时，他们做的是抖音本地生活代运营，自己的客户以餐饮商户为主，而且覆盖多个城市，所以内容需求的量非常大。

最直观的问题就是：每天要写很多文案，而且还不能写得太差。

他们内部其实不缺会写的人。有一些运营人员凭经验，确实能够写出质量不错的短视频文案。但问题在于，这些人的能力很难被规模化复制。一个人可能写得很好，却不可能一个人每天稳定处理几十甚至上百条内容。到了业务规模上来以后，就会变成一个很现实的矛盾：好的内容靠人，规模化生产又离不开人，但人本身就是瓶颈。

当时他们最高峰的时候，一天需要产生两三百条文案。

所以他们最开始找我的时候，提出的问题其实很朴素：有没有可能用 AI，把这件事情接起来？

但我真正开始介入之后发现，问题并不只是“写不够快”。

本地生活内容有一个很特殊的地方：不同商户之间差异很大。可能都是餐饮，有的是高端酒店，有的是连锁餐厅，有的是独立的小店；不同门店的主打菜品、活动、老板表达方式、目标客群都不一样，通用模型按固定模板生成，很难照顾到这种差异。

我后来判断，与其把大量成本放在模型和本地部署上，不如先解决真正影响结果的事情：业务流程到底怎么拆、哪些经验应该交给 AI、哪些地方必须保留人的判断，以及如何让 AI 的输出稳定地贴近这个团队自己的内容标准。

这也是我作为 FDE 最先关注的地方。

我会从客户每天真实发生的工作开始，看哪些事情适合让 AI 承担。

Q2在你参与之前，这个问题过去是怎么解决的？

他们过去主要依靠运营人员的经验来完成内容生产。有人负责文案，有人负责拍摄，有人负责剪辑，再由团队负责人进行协调和审核。对于客户数量还没有这么多的时候，这种方式是完全能够运行的。

因为人有一个优势：遇到不同的商家、不同的菜品和不同的情况，人可以根据经验临时判断。

比如一个运营人员长期服务餐饮客户，他可能知道什么样的老板适合什么表达方式，也知道什么样的菜品应该突出什么卖点。这些东西很多时候就存在于人的脑子里，没有被沉淀成标准化的文档。

所以过去的流程本身没有错，问题在于：规模一上来以后，过去依赖人的经验就很难继续放大。

他们后来也尝试过直接让 AI 写，包括本地部署 DeepSeek，但效果并没有达到预期。简单地把历史文案、写作范式交给模型，并不能解决问题。

我后来在项目里发现，AI 味其实很大程度上来自一种“固定范式”：给 AI 一套固定模板，让它不断模仿。这样做在单个案例里可能有效，但当面对不同商户、不同题材、不同场景时，就容易机械地重复。

所以我把“人工写 → AI 写”这种简单替换放到一边，开始重新看整个内容生产流程。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我做 FDE 规划的阶段有一个比较明确的习惯：先假设 AI 能做，再通过实际测试把它做不到或者做不好的部分逐渐交还给人。

我会先把客户原来的结果拿出来，再用 AI 跑一个小 Demo，把两个结果放在一起比较。

如果 AI 的结果已经可以达到一定水平，就继续往下走；如果某一个环节不稳定，再判断这个环节应该怎么调整，或者最终保留人工。

这个项目大致经历了几个阶段。

第一阶段：先把业务真正看懂

最开始，我和老板以及团队核心成员面对面沟通。

但真正重要的工作其实发生在后面。因为如果只听客户说“我们每天要写很多文案”，你得到的信息远远不够。

我需要知道他们每天具体怎么工作：谁负责什么、一个新客户进来之后怎么开始、什么信息需要提前准备、运营人员怎么判断一条文案好不好、什么情况下需要修改，以及遇到不同商户时哪些地方会变化。

所以前期我会和他们进行现场沟通，观察他们实际的工作流程，把原来比较依赖人的工作方式逐渐沉淀下来。

这一步对我来说特别重要。

因为很多中小企业的问题，归根结底是原本的业务流程本身就没有被很好地数字化和结构化。如果这一步不解决，直接把历史资料扔给 AI，其实并不能真正落地。

第二阶段：把人的经验拆成 AI 能理解的业务字段接下来，我开始把他们原来的经验拆出来。

不同商户虽然文案风格不同，但底层需要关注的东西其实比较接近，比如客户是谁、门店是什么类型、主推什么菜品、有什么活动、希望突出什么卖点，以及最终希望呈现什么样的内容方向。

所以我们把这些信息变成相对明确的输入字段。

这一步实际上是在做一件事：把一个优秀运营人员脑子里的经验，变成可以被系统调用的业务逻辑。

同时，我们也把客户团队里优秀文案人员的写作方式、技巧和参考案例融入工作流。

第三阶段：从“AI 写手”到一条生产流程真正落地的时候，我发现单纯一个 Prompt 或一个 Skill 是不够的。

因为“写出一篇文案”和“稳定地生产可以使用的短视频脚本”其实是两回事。

所以我们把提示词、Skill、业务参数以及校验、审计等 Loop 机制组合起来，让 AI 进入一套更完整的内容生产流程。

我更愿意把它理解成：把 AI 放进员工原来的业务流程里。

最终这一期项目主要落在文案和脚本生产节点上。这里的“文案”还要考虑到后续真正拍摄时的节奏、声画配合等因素，最终形成可以直接拿去使用的脚本框架。

第四阶段：让 AI 先跑，人负责判断我不会追求整个流程百分之百自动化。

我的理解是，AI 更像一个能力不同于人的同事。它特别擅长大规模处理、生成和适配，但在一些需要判断、审美、经验和最终决策的地方，人仍然非常重要。

所以实际流程里，AI 负责大部分标准化工作，人负责最后的审核和判断。

如果某一个节点 AI 做得不好，就把这个节点重新交还给人。这其实就是我所说的“回退机制”。

第五阶段：持续用真实反馈调优真正花时间的地方，其实是后面的调优。

我会周期性给客户提供不同版本，让他们结合平台的数据反馈查看。如果团队觉得“这个味道不对”，平台数据显示某个时间段留存下滑，或者某些客户、某些 SKU 下效果不稳定，就把这些反馈带回来继续调整。

这里面可能调整的是提示词，也可能是系统逻辑顺序、关注点，甚至模型选型。

因为文案这件事情很像“语感”，它很难一开始就被定义成一套绝对标准。所以真正的效果往往来自大量的反馈、比较和迭代。

Q4相比传统方式，使用 AI 后的实际效果如何？

从客户的使用反馈来看，效果非常明显。

首先是内容生产效率提高了。原来大量工作依赖少数经验丰富的员工，现在 AI 可以承接其中相当一部分重复性的生成和适配工作，人不需要从零开始写每一条。

其次是整体内容质量的平均水平提高了。过去可能只有少部分内容能够达到客户比较满意的水平，而现在 AI 把大量内容先做到一个相对稳定的基础水平，再由人进行筛选和优化。

再一个很重要的变化，是客户的工作方式发生了变化。

以前是来了一个需求，就按当天的需求去处理；这套 AI 工作流上线之后，新客户进来时就可以提前把门店、主打菜品、活动等参数规划好，再由系统持续生成内容，把原本容易堆积在某一天的人力需求提前消化掉。

我会把它理解成“削峰填谷”：它真正解决的，是让内容生产不再那么容易卡在“一个人每天能处理多少条内容”上。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目最大的难点，其实不是开发。

第一个挑战，在文案之外。

因为文案看起来只是几百字，但真正拿去做短视频时，它背后还涉及人物怎么讲、情绪怎么表达、画面怎么配、节奏怎么样。客户有时候会觉得“这个不对”，但又很难准确告诉你到底哪里不对。

这时候就不能只靠技术解决。

我需要结合自己的业务经验，去理解客户说的“感觉不对”到底意味着什么，再把这种比较模糊的反馈转成可以调整的提示词、流程或者判断标准。

第二个挑战，是不同客户、不同 SKU 下的稳定性。

原本设计好的提示词，在一个案例里表现不错，换一个商户或者 SKU，可能就会出现偏差。这时候需要回到具体业务里去看，到底是输入信息不够，还是参数、提示词或者流程逻辑需要调整。

第三个挑战，是如何让员工主动学习怎么和 AI 协作。

以前一个运营人员可以直接和同事沟通：“这个客户今天要做三条内容。”现在，他需要把业务要求转成系统能够理解和复用的输入，还要能够把“这个结果味道不对”这样的主观反馈，逐渐变成系统能够吸收的反馈。

这对团队来说其实是一种新的工作方式。

所以我会通过 Demo、测试、反馈和不断迭代，让团队逐渐理解 AI 能做什么、不能做什么。

同时，在项目交付时就提前预留持续迭代的空间，让客户按照 SOP 自己继续优化。这样项目结束之后，所有事情就不会重新回到我这里。

我觉得这也是 FDE 和单纯“交付一个软件”很不一样的地方：交付的不只是一个能跑的东西，还要让企业能够继续用、继续改。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

如果让我总结这个项目，我觉得 FDE 最重要的能力并不是“会不会调用一个模型”，甚至也不完全是开发能力。

第一件事，是从生意的角度先把业务看懂。

我现在做项目时，会默认电脑、手机上能够规模化完成的事情，都值得先尝试 AI。然后再通过实际测试，把做得不够好、不够稳定的节点逐渐交还给人。

所以要先让 AI 跑起来，再用业务结果判断它到底适合做到什么程度。

第二件事，是把 AI 放进业务流程。

企业员工自己用 AI 写一篇文案、做一个 PPT，当然也有价值，但这种价值往往比较有限。

真正能够形成企业级价值的，是让 AI 在流程里承担一个稳定的节点，甚至重新设计整个流程。

这个项目就是一个很典型的例子：如果只是告诉运营人员“以后用 AI 写文案”，效果不会特别明显；但当我们重新梳理客户、SKU、内容参数、生成、校验、人工审核这些环节之后，AI 才真正变成了业务流程的一部分。

第三件事，是把企业自己的 Know-how 留下来。

不同公司的文案看起来可能很像，但真正决定效果的，往往是这个公司自己的判断标准。

所以 FDE 的价值之一，就是把老板、运营负责人、优秀员工身上的隐性经验提炼出来，沉淀成可以复用的流程、参数和判断机制。

在这个案例里，不同餐饮客户最终的文案当然会不同，但背后的字段和基本 Know-how 范式是相通的，而具体取向则可以通过参数调整。这就让一套业务逻辑具备了进一步复用的可能。

第四件事，是一定要给反馈和迭代留位置。

我越来越觉得，AI 项目不是“开发完成”的。

第一版 Demo 往往并不难，真正决定项目能不能落地的，是前期需求理解、后期打磨，以及客户能不能持续参与迭代。

所以我现在做项目，前面会花很多时间做需求确认和业务对齐，中间开发反而没有那么复杂，真正需要持续投入的是后面的测试、反馈和优化。

最后，还有一个我自己越来越强烈的感受：FDE 本质上，是帮助企业找到 AI 和自己业务之间的连接点。

我更愿意把自己的角色理解成一个“AI 应用辅导师”：当客户知道 AI 很重要，却不知道它究竟怎么进入自己的业务时，我需要做的是深入他的业务，理解他的工作方式，再把 AI 真正植入进去。“用 AI 写文案、写汇报、生成海报”这类表层应用，远远不够。

技术能力当然重要，但随着 AI 辅助开发能力不断增强，技术门槛正在下降。反而是理解业务、理解 Know-how、建立客户和团队的信任，以及把人的经验转化成 AI 可以执行的流程，越来越成为真正卡住 FDE 落地的地方。

从人工分析到分钟级洞察：FDE 用 AI 重构电信网络数据分析

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我做的这个案例，客户是一家美国前三大的电信运营商。我们面对的是他们非常日常的一类工作：分析网络数据，回答网络到底发生了什么。

比如，一个很典型的问题就是：现在到底哪个基站坏了？为什么会坏？它的影响有多大？

客户手里有大量网络数据，包括基站、网络等基础数据。过去，这些数据主要还是由数据分析师、数据科学家人工处理。他们可能需要自己写 SQL，甚至进一步建立机器学习模型，从数据里寻找问题，再把分析结果整理出来，给经理或者管理层看。

这件事情真正麻烦的地方，在于分析这件事本身太依赖人工，而且问题永远在变化。

一方面，它非常耗时间。一个新的分析需求出来之后，可能需要一两个人，甚至两三个人一起讨论、写 SQL、分析数据，最后才能得到结果。

另一方面，它也存在人为错误。SQL 一旦写到上百行甚至几百行，中间就可能出现问题。我们在后来的项目中，就发现过一些看起来正确、实际上取错了数据的情况。

还有一个很重要的问题，是传统仪表盘很难真正满足这种需求。

因为领导或者分析师拿到一组数据之后，很自然会继续问：“那如果我把这批人筛出来呢？”“如果换一个条件呢？”“这组数据到底意味着什么？”

仪表盘更适合回答预先定义好的问题，但现实中的数据分析往往是不断追问的。客户真正需要的，其实是一种可以围绕数据持续追问的交互式分析方式，一个静态报表远远不够。

所以从 FDE 的角度来看，我看到的问题在于：客户已经有数据、有分析师，也有很多 AI 工具，但这些东西还没有真正组合成一个可靠的业务流程。

这也是为什么我会认为，Agent 好不好做不是关键。真正难的是，你能不能把它做成一个业务真正敢用、愿意持续用的东西。

Q2在你参与之前，这个问题过去是怎么解决的？

平心而论，过去这套人工分析的办法是走得通的，也不能简单说传统方法“不好”。

最核心的方式就是人工分析。

分析师拿到数据以后，自己写 SQL、跑模型、出报告。对于相对固定的问题，这种方式其实很有效，而且分析师能够结合自己的业务经验判断结果。

后来客户也尝试过一些自动化方式。

比如，他们尝试通过仪表盘自动生成报告，希望减少人工工作；也尝试过直接用一些 Agent 框架去解决问题。甚至在我们介入之前，他们自己已经搭过一个 Agent。

但问题很快就暴露出来了。“能跑起来”和“可以生产使用”，是完全两回事。

客户自己做的 Agent，可能就是给模型一个提示词：“你现在是一个数据分析师，我给你这些数据，请帮我分析。”

看起来非常合理，但真正跑起来以后，结果往往并不令人满意。即使底层用的是很好的模型，也不能保证最终输出符合业务要求。

更麻烦的是，有些方案把问题归结成“大模型本来就是不确定性的，所以答案不一样很正常”。

我并不认同这种说法。

如果我是一个企业老板，我问一个 Agent 两遍“我们公司哪个班的成绩最好”，我希望它在数据没有变化的情况下告诉我同一个人。模型本身具有随机性，不代表我们做出来的业务系统就必须是不稳定的。

所以我们真正需要解决的，是怎么设计一个系统，让模型能够在业务流程里被可靠地使用。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我做这个项目时，先做的第一件事是搞清楚三个问题：客户到底要什么输入？最后需要什么输出？中间到底发生了什么？

因为如果这三个东西没有搞清楚，Agent 写得再漂亮也没有意义。

第一步，重新梳理原来的分析流程。

我们把原来的数据分析过程拆成比较细的不同组件，再重新考虑每一个环节应该使用什么方法、什么结构，最后再把这些组件重新组合起来，让整个 Agent 的输出尽可能达到客户要求的结构和质量。

第二步，把 Agent 定位成一个可以反复运行的业务系统。

我们没有把它做成一个“会聊天的分析师”，而是把它当作一套业务系统来设计。

比如说，客户问一个网络问题，系统需要能够理解问题，然后处理对应的网络数据，再进行分析，最后给出结构化结果。

这中间每一步都需要考虑：数据是不是对的？分析过程是不是可靠？输出格式是不是符合要求？如果同一个问题重复执行，结果是不是稳定？

所以我们最终交付的，从客户角度看可以理解成“一个 Agent”；但从我们的角度，它实际上是一个可以被反复使用的 Agent 系统。

第三步，考虑如何让它可扩展。

客户往往有几十甚至上百个分析师。如果每个人都单独装一个 Agent、单独维护一套东西，这个方案很快就会失控。

所以我们还需要考虑如何把 Agent 放到云端，让它能够被统一控制、监督和使用，同时让不同用户共同产生的数据和经验能够反过来提升系统，包括记忆、语义层等能力。

第四步，尽量不改变客户原来的工作习惯。

我并不认为 AI 落地一定意味着员工必须重新学习一套复杂的系统。

如果架构做得好，它完全可以嵌入原来的使用方式。客户原来怎么使用，就继续怎么使用。可以通过网页应用，也可以通过 Teams、Slack，或者其他已有的框架去调用。

在这个案例里，我们最后让客户继续以聊天的方式使用它。

这其实是我理解的 FDE 很重要的一点：想办法让 AI 进入客户已经存在的工作流。

Q4相比传统方式，使用 AI 后的实际效果如何？

变化首先体现在时间尺度上。

以前一个新的数据分析问题出来以后，可能需要一个人甚至两三个人一起工作，而且是按天计算。

现在很多分析可以在分钟到小时级别内跑完，先得到一份比较完整的数据分析结果，再由人工做最后的质量确认。

我觉得这里不能简单理解成“AI 替代了几个分析师”。

真正的价值在于，原来大量时间被消耗在重复的数据处理和分析过程中，现在这些工作可以先由 Agent 完成。分析师不需要从零开始，可以站在 AI 已经完成的结果上继续判断。

同时，AI 系统还可以减少人工分析中一些容易出现的错误。

当然，我们并没有把人工审核彻底拿掉。因为企业真正需要的，是把人的时间从大量重复劳动中释放出来，集中到更需要判断的地方。

另外一个效果，是交互方式发生了变化。

过去仪表盘更像是“我提前把问题定义好，然后给你看答案”；现在则可以围绕数据继续追问。

这对于电信网络这种数据量大、问题变化快的业务来说，其实比单纯生成一张报表更有价值。

而且从架构角度，我们交付的是一个可以长期运转的 Agent 系统，所以它的价值在于逐渐进入客户日常的数据分析工作。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目里最大的挑战，恰恰是很多 AI 演示不会暴露出来的东西：稳定性、准确性、成本，以及规模化。

很多人做 Agent，第一阶段很容易成功。你给它一个问题，它能回答；换一个问题，它也能回答。于是大家会觉得这个东西已经做好了。

但一旦进入生产环境，问题就来了。比如，同一个问题反复问，答案是不是一致？数据分析过程有没有出现错误？SQL 有没有写错？如果用户数量从一个人变成几十上百个人，成本还能不能接受？

这些问题，才是真正决定一个 Agent 能不能落地的地方。

第一个挑战，是稳定性与准确性。

稳定性尤其明显。前面说过，很多人把模型随机性当成“结果不稳定很正常”的借口。

但我们的做法，是通过系统设计，把这种随机性放进一个相对可控的业务流程里。就像汽油本身不稳定，但汽车工程的意义，就是让汽油可以安全、稳定地驱动车辆。

第二个挑战，是成本。

成本是一个很现实的问题，包含多个层面，“调用模型多少钱”只是其中之一。

如果一个团队不知道怎么做 Agent，可能为了调试一个东西花几千美元；但一个真正有经验的人，可能用十几、二十美元级别的成本就能完成同样的调试。

而进入实际使用以后，还有长期运行成本。如果架构设计得不好，就像一辆漏油的车，你根本不用谈省油，因为油一直在往下掉。

第三个挑战，是对客户业务的理解。

如果没有真正理解客户的业务问题，你可能一开始方向就错了。再加上如果对整个 AI 生态、数据能力、云能力以及软件工程缺乏理解，就很容易出现“手里只有一把锤子，所以什么问题都拿锤子解决”的情况。

所以我一直认为，真正能够做好这类工作的 FDE，不应该只是懂某一个模型或者某一个工具的人。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

关于怎么把 AI 部署到实际业务中，结合这次项目，我想强调几点。

第一，理解客户。

客户到底在解决什么问题？真正的痛点是什么？哪些东西值得自动化？哪些东西不应该自动化？

如果这些问题没有搞清楚，后面的技术选择都没有意义。

第二，不能只懂一个 AI 工具。

我经常会说，如果你只知道自行车，那么你看到一个很远的地方，就只能想办法骑自行车过去。

但如果你同时了解汽车、飞机以及其他交通工具，你才能真正判断什么场景应该用什么工具。

对于企业 AI 也是一样。

你需要同时理解 AI、数据、云，以及基本的软件工程能力。尤其是当你面对的是一个具体业务问题时，你不能因为“我最熟悉这个工具”，就强行把问题往这个工具上套。

第三，不要把“能跑”当成“能落地”。

现在做一个 Agent 并不难，难的是把它做成生产就绪。

它要稳定，要可重复，要控制成本，还要能够进入客户原来的工作流。如果客户有几十、上百个用户，还要考虑怎么统一管理、监督和迭代。

所以 FDE 的价值，在“把工具部署进去”之外。

如果是比较严格意义上的 FDE，它既需要有扎实的技术能力，也需要对客户那些没有被明确表达出来的需求保持敏感。技术能力和软能力，两方面缺一不可。

最后，不要迷信 FDE 这个名词。

现在国内把 FDE 这个概念讲得很宽，从 AI 咨询到方案设计，再到真正的部署，都有人称自己为 FDE。但无论叫什么，最终还是要回到一件事情：你有没有真正用过这些工具，有没有在自己的场景里解决过问题。

以前 Excel 也有类似的“客户成功”或者技术支持角色，有人教你怎么用 VBA、怎么把复杂功能用起来。今天换成了 Claude Code、Codex、Agent 等新工具，本质上并没有发生特别神秘的变化。

真正的区别，只是工具越来越复杂，而一个普通用户往往只会使用它最表层的功能。

一个真正懂这些工具的人，价值就在于把那些普通用户不知道的“下一层、再下一层”

能力带进实际工作里。

所以，用一句话来概括这次经验，我会说：FDE 的使命，是把 AI 真正变成企业正在使用的工作方式。

从老师傅报价到 AI 深度协同：FDE 用 AI 重构非标制造售前链路

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我们这次选的是制造业里一个常见、却经常被低估的场景，非标产品的售前方案和报价。

这家企业大概有两三百人，营业规模在一二十亿元左右，业务属于典型的柔性制造，多品种、小批量，大量订单都是非标需求。它和标准品企业不一样，标准品有固定 SKU 和价格，客户选完产品基本就知道多少钱；非标制造往往需要客户先发一张图纸，企业内部再去判断这个东西要做成什么样、用什么材料、关键尺寸是多少、结构和性能有什么要求、能不能生产、该用什么工艺、成本大概多少。

所以我一直觉得，这个场景只叫“报价”其实并不准确。更准确地说，它是一条完整的链路，图纸解析、需求拆解、研发协同、生产方案、成本核算、报价。

举个具体的例子。客户可能要加工一个轴承零部件，发来的不一定是一份标准数据，可能是 PDF、CAD 文件，也可能是其他不同形式的资料，里面写着材料、尺寸、关键部位要求、结构要求等信息。过去企业需要有人把这些东西打开一项项看，再依靠专业经验，把客户的语言转成企业内部能够生产的语言。

单独看，任何一个动作都不算复杂，真正麻烦的是整条链路非常依赖人。

首先，它占用核心技术骨干。真正懂工艺、懂材料、懂制造可行性的人，在制造企业里通常比较稀缺，但大量非标订单进来以后，他们不得不花很多时间做售前方案、看图纸、拆需求、估成本。

其次，报价准确率直接影响利润。价格报高了，订单可能丢掉；价格报低了，单子虽然拿到，生产时才发现成本覆盖不住，利润空间被挤掉。

第三，还有一个经常被忽略的问题是响应速度。客户的询价不会一直等你，如果某个技术骨干正好在忙，报价卡在那里几天，这个售前节点就可能直接卡死，最后订单流失。

我们选这个场景，并没有从“AI 现在能识别图纸”出发。判断顺序正好反过来，一个场景值不值得做 AI 改造，我通常先看三件事：有没有大量知识型工作，比如分析、判断、设计和经验复用；有没有一定规模的历史数据可以使用；现有流程里有没有非常明确的效率瓶颈。

如果只是简单的自动化流程或者需求价值不高的场景，我觉得根本没必要上 AI。

Q2在你参与之前，这个问题过去是怎么解决的？

在 AI 介入之前，客户图纸过来以后，业务人员、技术人员或者企业里的老师傅打开文件，根据自己的经验理解客户要求，再把信息整理出来，然后去查企业自己的物料、供应商和历史价格。本质上，这是一个纯人工的信息理解、结构化和匹配过程。

之前没有成熟的多模态能力，很难让系统直接理解不同格式的图纸，也很难把大量非结构化资料自动转成结构化信息。企业自己的知识同样不够标准，一个零部件为什么这样报价，很多时候都写在老师傅脑子里，他清楚某个材料应该找哪个供应商，某种工艺大概需要多少成本，什么情况下该给客户留一点余量。

企业过去也试过用系统把这件事接起来，早期上过 ERP 和报价模板，想用固定字段把报价流程管起来。这类系统擅长的是“你把字段填进去，我按规则往下跑”，最难的第一步，也就是把客户五花八门的输入理解成标准数据，始终没人解决。所以系统最后只能覆盖标准件和固定 SKU，非标部分照样回到人，模板反而多填一遍表。

问题真正爆发，是在业务规模和复杂度上升以后。订单越来越多，非标需求越来越多，人的处理能力却不会同比增长。一个关键技术员一天能看的图纸、能处理的询价是有限的，需求一来多，整个售前链路就开始排队。经验长期握在少数人手里，也意味着企业很难把这种能力复制出去。

所以我们真正想解决的，是一个新问题：当业务规模继续扩大时，能不能不再靠增加更多人、更多老师傅来撑住报价能力。报价能力，是影响一个制造业供应链企业生死存亡的核心能力，关系到这个企业的响应速度、服务能力以及利润空间。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

做这个项目，我没有拿着一个模型去问客户“这个模型能帮你干什么”，工作顺序一直是反过来的，先理解业务，再拆流程，再判断哪些环节该用 AI。

我们先去复现传统人工操作的业务流和数据流，通过还原实际 SOP，结合 AI 大模型与 Agent 编排能力，去梳理输出企业 AI 再造后的新业务流程。

FDE 在这里更像一个连接器，一头听懂企业在说什么，一头清楚当前大模型、Agent 和各种 AI 工具能做到什么，再把两边拼成一个能落地的方案。

第一步，是把“报价”重新拆成一条业务链路。

前期我们深入做了需求调研和业务调研。进场之后我先去了车间，看一个订单从图纸到交付到底经过哪些环节，又翻了一批历史报价单，找业务人员和老师傅分别聊，问他们拿到一张图纸后第一件事做什么，谁看图纸，谁做需求拆解，谁定物料，谁判工艺，谁核成本，谁最后报价，不同角色之间怎么交接。只有把这些都搞清楚，才能知道 AI 应该放在哪个位置。

第二步，是先解决非结构化信息的入口。

客户发来的图纸格式不统一，有的 PDF、有的 CAD，所以第一步要利用多模态能力，把图纸里的材料、尺寸、结构要求等关键信息抽取出来。但我们的目标不止于“识别图纸”，识别之后必须结构化，因为只有结构化以后，这些数据才能继续进入后面的业务流程。

第三步，是让 AI 进入企业自己的业务规则。

这一步很关键。AI 提取出客户需求之后，不能直接凭模型自己的知识报价格，企业内部有自己的物料库、供应商体系和长期形成的报价逻辑，所以报价必须基于这家企业自己的条件。我们会把结构化后的客户需求，与企业自己的物料、供应商、历史数据和报价规则做匹配，再通过垂类 Agent 把这些环节串起来。这样出来的结果，才是企业真正可以拿去用的报价。

这个设计也是调整出来的。一开始我们想得比较直接，觉得模型看懂图纸、抽取字段，后面按规则一算就能出价。真正到现场跑起来才发现，端到端直接出价，出来的数字经常对不上真实成本。所以我们改了方案，让模型先只负责把图纸信息结构化，报价环节再回到企业自己的物料和规则库里做匹配，每一单都经过人工校准才对外输出。

第四步，是把老师傅的经验变成企业的数据资产。

企业原来的很多工艺知识都存在人脑里。AI 介入之后，我们开始把这些知识逐步标准化、流程化，哪些物料怎么映射，某类需求通常走什么工艺路线，报价时有哪些判断逻辑，都可以逐步沉淀下来。同时我们设计了人工校准和回填机制，AI 第一次给出的结果不一定完全正确，业务人员会修改，修改完之后就把这次修改重新沉淀到数据、向量数据库或者相关模型里。

这样就形成一个数据飞轮，AI 生成、人工校准、数据回填、下一次结果更好。

第五步，是不等所有需求都搞清楚再开发。

前期调研不可避免，我们也会深入现场、开很多次会，但我一般不会等所有信息都完全掌握之后，再关起门来做几个月。我的方式是边干边改，客户给我一部分输入，我就先给他阶段性产出，可能是 Demo、一个流程，也可能是某个功能，让他先看是不是这个意思、这个东西到底能不能解决他的问题，客户反馈之后我们继续调整。整个过程中可能来回几次，甚至十几次。

B 端项目有一个很现实的问题，有时客户自己都不知道自己真正需要什么，FDE 不能只记录需求，还要不断拿阶段性结果去帮客户澄清需求。

第六步，是先让关键人试用，再逐步推广。

产品做到可以运行之后，我们不会马上让所有人用，先找关键人试，让最懂业务的人拿真实订单跑，发现问题再修改；接下来再让一个业务小组试运行，这个阶段仍然不断收集问题。这个项目里试运行周期大概是 1 到 2 个月，我们围绕几个真实订单不断验证，同时继续调整需求。等到结果基本可用，再做部署、数据集成、启动会和全员培训，最后逐步扩大到整个部门。

整个推广路径就是关键人试用、业务小组试点、真实订单验证、反馈调整、部门推广。

我认为这种方式比一次性开发完成再宣布上线可靠得多。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目刚上线的时候，并没有立刻达到理想状态，前两个月一直处在磨合和微调阶段。因为我们最终看的，是这个结果能不能真正被企业拿去报价，模型能不能输出一个结果反而是次要的。

目前来看，整体效果已经比较明显，至少能减少 50%以上的相关工作量。但如果只把“节省 50%工作量”当成全部价值，还是低估了这个项目。

我们内部评估效果，会看几个层面。第一是响应速度，原来人工完成一套报价要多久，现在通过这套流程要多久；第二是报价结果本身的可用性和准确率；第三是前面图纸解析的准确率；最后还是要回到第四层，它到底给企业运营带来了多少价值。

这里发生了一个很有意思的变化。原来这项工作可能需要 3 到 5 个人参与，AI 介入以后，一部分重复劳动可以由系统完成，实际需要投入的人力明显减少。企业并没有简单地把剩下的人裁掉，这家企业本身处在上升阶段，老板希望做的是把人的生产力释放出来。

原来业务人员很大一部分时间耗在看资料、整理需求、反复核对这些事情上，这部分时间省下来之后，他们可以回到本来的业务工作，去联系更多客户、谈更多项目、接更多订单。企业随后也会相应调整这些岗位的 KPI 和职责，让考核更偏向真正的业务价值。

所以我理解的降本增效，核心是原来 5 个人的大量时间被低价值重复劳动占用，现在把其中一部分生产力释放出来，让人去做更需要判断、沟通和创造价值的事情。这才是 AI 真正进入业务流程之后应该产生的变化。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目真正困难的地方，我觉得不完全是技术。立项之前，能不能做、当前模型能力到什么程度、有什么风险，我们一般会先判断。真正进入项目以后，遇到的坎主要有三个，图纸识别能不能达到报价要求、企业的数据质量、以及组织里人的接受度。

第一个挑战，是图纸识别在真实场景里达不到报价的要求。

客户图纸远比想象中杂，有 PDF、CAD，还有各种扫描件，清晰度参差不齐。模型在干净样例上效果不错，一旦碰到手写标注、特殊符号、非标准图框，抽取字段就经常出错。报价是要对外的，一个尺寸抽错会直接影响成本。我们的办法是给识别加一道人工校准兜底，业务人员只审那些模型把握不大的字段，审完再把修正结果回填到模型和数据里，识别准确率随着真实数据越滚越高，人工要审的部分越来越少。

第二个挑战，是企业的数据远没有想象中标准。

很多中小制造企业的数据基础比较薄弱，进去以后你会发现，各种资料、历史报价、物料信息、供应商信息，很少能天然直接给 AI 使用，所以我们花了大量时间做数据清洗和结构化。更麻烦的是，要从这些数据里重新还原企业真实的业务逻辑，这个物料为什么这样映射，这种情况为什么这样报价，老师傅做这个判断到底依据什么。这些东西不解决，模型再强也没用。

所以 FDE 在这里做的事情，其实很像经验复盘，要从企业现有的数据和人的经验里，把那套真正运行多年的业务规则挖出来，再把它重新变成 AI 能用的东西。

第三个挑战，比数据更难，是人。

这是我现在做企业 AI 项目感受最深的一点。技术是相对静态的，人的反应是动态的。比如一个岗位原来要 3 到 5 个人完成，现在老板说上 AI 以后可能只要 1 到 2 个人，员工第一反应常常是担心自己是不是要被优化、系统上线以后还有没有位置、是不是要被调去不想去的岗位，很少会先想到“这个系统真先进”。这种抵触非常真实。

而作为乙方，我们其实没有权力去安排甲方员工，甚至从员工视角看，我们做的事情本身就威胁到他的岗位，他天然会对我们有抵触。所以这个问题靠 FDE 自己解决不了，企业 AI 转型必须是一把手工程，老板必须真正认可，并且愿意自上而下推动。

这个项目里，我们会在立项前就和老板、项目相关方讨论生产力释放之后怎么办，方向是让省下来的时间转向更有价值的业务，简单裁人从来不是选项。最终这家企业确实重新调整了相关人员的工作安排和 KPI。这件事让我更加确信，AI 落地的最后一道关，往往是组织架构的调整和转型。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做了几个项目之后，我的一个坚定判断是，FDE 真正的功课，是让 AI 变成企业业务的一部分，把它装进企业只是开始。这里面有几条经验对我比较重要。

第一，判断场景，先看它卡住的是不是企业最稀缺的人。

选场景的起点应该是业务瓶颈，模型能力排在后面。报价这个场景之所以值得做，正因为看图纸、拆需求这些重复劳动占满了老师傅和技术骨干的时间，而他们对工艺、材料和可行性的判断，恰恰是企业最难复制的能力。

至于怎么筛，前面提过的三个条件，知识密集、有历史数据、瓶颈明确，缺一不可；用普通自动化就能解决的事，也不必硬套 AI。

第二，别只盯着一个 AI 功能，要看完整业务链路。

如果我们只做图纸识别，这个项目的价值其实很有限。识别只是入口，价值来自识别之后那条已经拆开的链路能不能整体跑通。所以 FDE 要看的是端到端的业务流程，一个孤立的模型节点撑不起业务价值。

第三，数据治理本身就是项目的一部分。

很多人觉得企业把数据准备好之后，我们再来做 AI，现实里往往相反，尤其是中小企业，进去之后很可能会发现数据本身就是乱的。所以数据清洗、结构化、业务规则还原、经验沉淀，本身就是 FDE 必须参与的工作，把它当成前置准备工作会低估它的分量。

第四，拿阶段性结果跟客户对话，小范围验证之后再推广。

B 端客户很多时候并不知道自己到底需要什么，所以我习惯边干边改，快速做出一个阶段性成果让客户看到，再通过真实反馈不断修正。这种方式看起来不够完美，其实更符合真实业务。

落地上也一样，先找关键人和业务骨干用真实订单试，再让一个小组试，等结果稳定以后再扩大到部门，这样既降低技术风险，也降低组织层面的阻力。

第五，AI 转型必须是一把手工程。

企业 AI 落地不是交付一个软件就结束了，当 AI 真正开始改变业务流程，它一定会继续影响岗位职责、KPI、部门协作甚至组织架构，这些事情不是一个乙方 FDE 能独立推动的，老板必须站出来。

所以我理想中的 FDE 合作模式，是成为企业长期的转型合作伙伴，做完一个版本、上线一个系统只是起点。今天解决报价，下一步可能解决生产，再下一步可能进入供应链、

销售或其他业务环节，一个场景一个场景地往前走，最后把整个业务闭环逐步重新设计。

最终我们要实现的，是一种新的组织状态，AI 去承担那些可以标准化、可以重复、可以被数据化的工作，人重新回到判断、沟通、创造和业务增长上，这套系统只是载体。

我觉得这才是 FDE 真正应该推动的事情，把 AI 交付给企业只是过程，帮助企业重新设计人与 AI 一起工作的方式才是目的。

从纸质台账到 AI 经营：一家生物科技上市公司的 0 帧起手数智化

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

这家生物公司可以应用的场景很多，但我们通过 4 维模型帮他们筛选出了价值最高的几个场景做先行试点，销售部门是第一个选中的，团队直销+渠道有 200 多人，专业门槛高，新人要懂行业法律法规、行业规则和大量销售话术，而且一线人员流动不低；销售缺乏信息化支持，不管是个人的工作效率还是中高层的经营分析、团队管理，痛点都很突出，通过信息化增强、数据的统一与智能体的协助，销售团队无论是个人人效还是组织管理都可以得到切实的改善。

这个问题表面上看是“要不要上 AI”，实际卡住的，是销售这条线最基础的数据和系统。

管理层想看清销售大盘，但当时客户、订单、绩效这些数据，并没有形成一个统一的基础。

具体痛点集中在几个地方。

首先，客户关系散落在销售个人手里。谁手里有哪些客户、进展到哪一步，公司层面很难掌握，人一走，客户线索就跟着流失。

其次，销售大盘数据、部门业绩、个人提成等靠 Excel 人工统计。提成计算量大、环节多，效率低，准确率也有限，管理层想实时看销售大盘，数据延迟 1 个月以上是常态，想动态分析基本做不到。

第三，销售培训和招聘面试都在消耗老销售。新人培训周期接近两个月，招聘还要占用老销售的时间，这些事本不该压在业务人员身上。

其他部门也存在类似问题，比如 HR 的人事资料还停在纸质文件柜里。但销售离收入最近、痛点也最集中，所以我们先把切口放在销售上。

这个项目最核心的问题，是企业已经产生了 AI 转型的需求，但销售的数据、系统、人才和认知还没有准备好。这也决定了它不可能是一个接上模型就能上线的单点应用。

Q2在你参与之前，这个问题过去是怎么解决的？

在 AI 介入之前，销售这条线是能跑起来的，只是靠人硬撑。客户关系由销售自己维护，订单、提成、绩效通过 Excel 统计；新人培训靠线下培训会、老带新手把手教，周期性考试；招聘靠 HR 和老销售一起筛简历、面试。过去业务规模没那么大的时候，这些方式都能把事做完。

企业有 ERP 有 OA，但系统老旧，数据不通，大量关键数据不在系统里，很多环节还是退回 Excel 和个人手里，系统并没有解决数据汇总这个根本问题。

这种方式的局限很清楚。

一方面，管理层看不清经营。Excel 算提成，只要业务流程相对稳定还能应付，一旦要实时看不同区域趋势、分析涨跌原因，再把各种销售过程信息结合进来，原来的方式就撑不住了。

另一方面，高价值的人被低价值的事占用。

这个问题的根本，在于企业发展到了新阶段之后，原来的信息化能力已经承接不了新的战略目标。以前 Excel 能算清提成就够了，现在管理层要的是实时经营判断，中间缺的，是一个能把技术和销售现场真正连起来的角色。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

做这个项目，先帮企业看清现状，数据做到什么程度了、哪些环节最痛、哪些真正值得用 AI，然后再决定 AI 从哪里进去。

第一步，是进现场做诊断。

我们逐个部门访谈，看他们的业务流程、系统、数据和真实痛点。销售部门纸面台账和人工计算随处可见，这些现场看到的东西，比任何汇报都更直接。

诊断过程中有一个原则，不要看到一个问题就马上判断它应该用 AI，销售提成就是一个例子。它本质上是信息化和数据问题，我们就先帮企业选购 CRM，把散落在销售个人手里的客户、订单、绩效数据统一进系统，等数据沉淀下来，再交给后面的数据分析和 AI 使用。

第二步，是补数据基础。

企业想做智能化，信息化和数据化是基础，数据必须先能被获取、被汇总、被使用。所以我们在销售端先把 CRM 跑起来，再结合数仓把数据逐步汇总。这一步看起来不像 AI，但它决定了后面的 AI 能不能真正进入业务。AI 有很多上下游依赖，数据都没有，模型再聪明也没有东西可以分析。

第三步，是 AI+BI 做经营分析。

CRM 和数仓搭好之后，我们先通过 BI 把经营数据转化成销售大盘，再让 AI 参与分析，比如不同大区销售趋势怎么样、为什么这个月上涨或下降。除了结构化数据，我们还会把销售日报、周报和客户拜访记录结合进来，让 AI 帮助分析月度、季度销售变化背后的根因。分管销售的管理层因此除了看到结果数字，还能更快理解销售大盘发生了什么，从而辅助下一步经营调整。

第四步，是把人效提起来。

培训和招聘是两块持续在消耗人的环节。过去培训周期很长，招聘也慢，后来我们把这些内容逐步搬进 AI 应用，通过 AI 陪练和电子化考试帮助新人练习；招聘端也做了 AI 简历筛选、打分，并试点自动化一面。

这里有一个调整的过程。一开始我们想得比较直接，先把知识库建起来，新人就能用。

真正跑起来才发现，光有这些还不够，还要和考试、上岗标准、组织方式结合，于是改成把 AI 陪练和电子化考试串成一套完整的闭环，边用边根据新人通过率优化。

第五步，是把企业自己的 AI 团队搭起来。

这是大型企业项目跟很多小项目最不一样的地方。外部 FDE 不应该永远作为企业外部的拐杖，企业要长期转型，一定要具备自己的内部能力。所以第一阶段之后，我们建议董事长扩充内部团队，企业拿出 20 个编制，我们参与人员招聘和团队框架建设。这样一来，项目就从帮企业做几个 AI 应用，进一步变成帮企业逐渐建立继续往前走的能力。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目本身是一个覆盖面比较广的转型项目，所以我们会从多个角度来看效果。

第一个明确的结果是销售人效。新人原来的培训周期接近两个月，把知识内容转化为 AI 陪练、电子化学习和考试之后，培训周期缩短到大约 3 周。对一个 200 多人、流动大的销售团队来说，这意味着新人可以更早进入有效销售状态。

第二个结果是招聘效率。因为销售招聘量大，以前老销售也要和 HR 一起筛简历、参与面试。我们当时测算，一个老销售每个月大概要在这些工作里投入 3-4 个人天。引入 AI 进行简历筛选和打分之后，这部分工作基本能省下来，一个销售把这些时间拿回来，至少可以多去拜访 1-2 个客户。

第三个变化体现在经营分析。管理层除了看到销售结果，还能更快看清各区域趋势以及增长、下降背后的原因，从而更快做经营调整。

所以我评价 AI 项目，习惯先问一句，被 AI 释放出来的时间，有没有重新变成企业的生产力。在这个案例里，答案是有的。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目真正难的地方，大多不在技术。回头看，主要有三个挑战。

第一个挑战，是销售数据散，直接上大模型会做成演示项目。

很多人觉得一家上市公司，还是生物科技企业，数字化程度应该已经比较高。真正走进去才发现，业务领先和数字化领先完全是两回事，销售数据散落在不同系统和个人手里，IT 团队也没有足够的人力承接 AI 转型。这种情况下直接上大模型，很容易变成一次性的演示。

所以我们的做法是接受现实，不跳过信息化和数据化，该补 CRM 就补 CRM，该把销售数据先汇总就先汇总，该建数仓就建数仓。AI 转型的第一步，往往发生在 AI 之前。

第二个挑战，是数据治理难，需要分阶段补底子。

销售数据来源杂，口径不一致，历史数据质量参差，要真正汇总成数仓并不轻松，等于要一边清理历史数据，一边重建业务流程。我们的办法是分阶段推进，先把最关键的数据跑通，再逐步把其他数据接进来，边接入边治理。

第三个挑战，是销售团队对 AI 的恐惧。

这是后来我在企业 AI 项目里特别看重的问题。把一个 AI 工具直接扔给业务人员，他们第一反应往往是这东西是不是要替代我、公司是不是准备裁员。

所以后来做项目，尤其是高层认知对齐时，我第一个建议就是不要一上来把 AI 和裁员绑在一起，高层先明确为什么做 AI，再跟中层讲清楚 AI 上线以后给部门带来什么收益、岗位怎么调整、职责怎么变。如果只是工具变了，绩效考核、岗位职责和产出要求完全没变，很容易出现工具做出来了却没人愿意用。

我们的解决方式，是把 AI 放回整个工作流程里，讨论哪些工作交给 AI 以后，人可以做更高价值的事。这时候员工对 AI 的理解就完全不同了，它从“可能抢我工作的东西”，变成了“帮我减少低价值工作的工具”。FDE 和单纯技术实施的区别就在这里，我们除了让技术上线，还要让新的工作方式成立。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

这个项目让我更加确信一件事，企业 AI 转型，光靠买几个 AI 工具很难完成。

第一，先判断企业处在哪个阶段。

有的企业信息化、数字化基础已经很完善，数据都在统一数仓里，AI 很快就能往上走；

有些企业连信息化时代的课都没补完，这种时候不能因为自己是做 AI 的，就假装那些问题不存在，应该补 CRM 就补 CRM，应该做数据治理就先做数据治理。AI 只是整个企业生产力体系的一部分。

第二，从业务最痛的地方筛选场景。

我们进每一个部门调研之后，重点看几个问题，这个问题到底有多痛、一年发生多少次、占用多少人、影响多少收入或成本、AI 是不是已经足够擅长解决。只有这些条件都比较合适的场景，才值得优先投入。这个案例里销售这条线之所以优先，正因为离收入近、痛点集中。

第三，不要什么问题都硬套 AI。

比如销售业绩，我们选择交给 CRM 和 BI 系统去算，把 AI 留给趋势归因、日报周报分析、

销售陪练、简历筛选这些它真正擅长的地方。FDE 真正重要的能力，是知道哪里不应该使用 AI。

第四，大企业的 AI 转型，本质上一定包含组织建设。

外部 FDE 可以帮助企业启动、诊断、搭框架、做第一批场景，但长期来看企业不能永远依赖外部团队。所以我们后来非常明确地建议董事长建立或者内部培养自己的 AI+团队，这个案例里企业后续要自持算力和行业小模型，我们就协助企业主导了 20 个岗位的招聘和团队搭建。轻度使用的企业，也至少要协助企业在每个业务部门树立一些 AI 提效标兵等方式，培养企业原生 AI+的能力。一个好的 FDE 项目，除了留下几个应用，还应该帮助企业留下继续进化的能力。

第五，一定要重新设计人和 AI 的生产关系。

AI 上线以后，人的职责是什么、绩效怎么变、原来的流程哪里该取消、哪里需要新增人工判断、什么事情让 AI 做、什么事情必须由人负责，这些问题如果没回答清楚，企业买再多工具，也很难真正变成生产力。

所以如果让我总结这个项目，我更愿意说，我们陪着这家生物科技上市公司把销售这条线，从散乱的数据一点点做成可以支撑经营的智能分析，再让 AI 进入培训和招聘，把销售的时间重新还给销售。真正的 FDE 价值，在于站在企业真实能力和真实问题上，判断它今天能迈哪一步，然后让这一步真正走通。

从人工排队到审核前置：FDE 用 AI 重构消费品研发协同与包装审核

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我现在做的是消费品产品生命周期里的 AI 应用，落地在消费品牌和上游工厂下游渠道。

锚定这个行业，是因为我自己真正做过一个消费品牌的产品，从 0 到 1 经历过产品和增长，也在这个过程中尝试用 AI 和 Workflow 提高自己的效率。但真正进入客户现场以后，我才发现，问题比最开始想象的复杂得多——在消费品这类长链条行业，在跨品类跨组织场景下，也有差异化的。

一个消费品企业一年可能要做 100 多个 SKU。一个产品从需求开始，到口味、配方研发，再到包装、合规、中试、渠道上线，中间会经过很多角色。它是一条很长的业务链，中间环环相扣。

更关键的是，这条链路里最重要的东西，很多并不在系统里。

比如，消费者或者渠道提出一个需求，产品经理可能会把它理解成“我要做一个更脆的产品”。但为什么是“脆”？可能来自前面的消费者调研，也可能来自和渠道客户的一次沟通。到了研发环节，研发人员又要把“脆”翻译成具体的配方和工艺。可为什么选择这种配方？可能是过去做了很多次实验之后积累下来的经验。

这些东西如果没有被记录下来，到了 SaaS 系统里，最终留下的往往只是一个结果，缺少“为什么这么做”的过程。

我看到的核心问题，其实有两个。

第一个，是核心资源依赖人。产品经理的判断、研发的经验、渠道的反馈，很多都存在个人脑子里。

第二个，是数据和信息高度分散。过去的 SaaS 更多是在记录结果，但真正影响决策的上下文，大量是非结构化信息，很难被完整沉淀下来。

这时候，我觉得 AI 真正有价值的地方就出现了。

我把问题拆成两个方向：流程自动化和决策高质量化。

比如一个需求提交给研发之前，有些东西其实不需要人来判断。原料有没有、成本有没有可能达到、一些基础规则是否满足，这些都可以提前检查。另一方面，真正需要产品经理、研发人员做判断的地方，则应该让 AI 把历史成功或失败的经验找回来，帮助他们做更充分的决策，把最终判断交给人。

我理解的 FDE 视角，是先看业务到底在哪里损耗了信息、经验和人的判断力，再决定 AI 能做什么。

Q2在你参与之前，这个问题过去是怎么解决的？

过去的方式有它的合理性。

消费品企业已经有很多 SaaS 系统，也有很多成熟的业务流程。企业会购买不同的 SaaS，分别服务研发、生产、渠道等单点环节。

这种方式在过去是有效的，因为它至少解决了“信息有没有记录”的问题。但它有一个天然的限制：系统记录的是结果，人负责输入信息。

只要信息需要人主动输入，就一定会发生损耗。而消费品业务偏偏有大量非结构化的信息，是表单很难承载的。单点 SaaS 产生数据孤岛，要再花大精力去建设数据中台；所以过去的 SaaS 解决的是上一阶段的问题。

当业务规模变大、SKU 不断增加之后，真正的问题从“有没有系统”变成了“整个链路上的上下文能不能流动起来”。

以包装开发流程为例，这个问题特别典型。

一个产品研发出来之后，包装还需要经过审核。随着 SKU 增加，待审核包装不断堆积，排队等审核。

但我们真正把这个流程拆开之后发现，所谓“包装审核”至少涉及四种不同视角：

设计师检查错别字等基础问题；

法律法规人员检查食品法、广告法等硬性要求；

渠道检查自己的规范，比如渠道 Logo 和品牌 Logo 的大小关系；

产品经理判断包装有没有正确表达产品本身。

这时候问题就变得很清楚了。

如果 SaaS 系统只存结果数据，效率和效果依然没有提高，但当 AI 介入链路，这里面错别字、法规等基础问题高度标准化，可以直接交由 AI 执行；有些事情可以随着历史反馈逐渐标准化，比如不同渠道每一次的反馈积累下来，沉淀成标准后交由 AI 完成预审；还有一些事情必须保留人的判断，比如产品经理和设计师对于审美表达的判断，但 AI 可以给人的判断提供更多上下文支持，比如在渠道产品上线后的销售表现，反向指导对包装的迭代。

所以我们重新问了一遍：这个流程里面，到底哪些工作应该由机器做，哪些工作必须留给人？

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我后来确信了一件事，不能带着一个已经做好的方案去客户现场。

这个坑我们自己踩过。最开始，我们也会拿着自己以前验证过的方案去找客户。结果很容易变成一种状态：你是外部的人，却试图告诉内部的人应该怎么做；你觉得方案已经验证过了，但对方的组织、老板、业务模式、决策方式都可能完全不同。

后来我们的方式发生了变化。

第一步，先观察，再解决。

我会尽可能进入客户真实的业务环境。最开始我甚至会直接参加他们的会议、进入飞书群。但后来发现，一个外部的人一直待在里面，其实还是会让业务同学产生压力。

所以我们做了一件很有意思的事情，把一个 Agent 放进业务群里。

它在那里待了两三周，持续收集业务上下文，不急着解决问题。过一段时间，我们再让它总结：最近业务里有哪些问题？哪些东西值得沉淀成经验？哪些地方可能存在可以被 AI 解决的机会？

最后，Agent 自己从真实业务沟通中定位到了包装审核这个问题。

这件事情对我启发很大。Agent 在这里承担了两重角色：既执行任务，也观察业务。它可以相对隐形地获取业务上下文，然后我们再结合人的判断去确定哪些问题真的值得做。

第二步，先定义问题，再定义 AI。

还是拿包装审核这个单点场景为例，我们确定包装审核确实是一个高频、真实存在的问题之后，并没有马上开始写一个“包装审核 Skill”。

因为我们很快又发现，如果完全由我们这些外部的人去定义 Skill，依然容易变成“外行指导内行”。

所以我们换了一个思路。如果过去公司要招一个人来做包装审核，HR 会给他一份岗位说明书。那么现在我们希望 AI 承担这部分工作，AI 同样应该拥有一份“岗位说明书”。

于是，我们借用了 HRBP 的思路，把真正做审核的人找出来，让业务人员自己拆解：他平时到底审核什么？输入是什么？输出是什么？什么情况下需要判断？什么规则可以直接执行？什么事情需要上下文？

这一步非常重要，因为真正懂业务的人开始参与进来，AI 该怎么工作，由他们来定义。

第三步，把业务工作拆成“可以自动化”和“需要决策”两类。

拆完之后，我们就能看到哪些事情可以直接交给 AI。比如错别字、一些法规标准、能量计算等相对确定的问题，可以提前自动检查。

而渠道要求这种东西，虽然最初可能需要人工判断，但每一次渠道反馈都可以被记录下来。下一次遇到类似包装，就不需要重新从零开始。

再往上，产品经理真正需要做的，是判断包装到底有没有把产品表达清楚。

于是，一个原本“所有东西都堆给审核人员”的流程，被拆成了不同层级：确定性问题→ AI 自动处理；历史经验 → 持续沉淀；复杂判断 → 留给人。

第四步，工程化，让 AI 进入整条业务链。

首先，提升单次执行审核的准确率。

包装图上有密集文字段落，有 NRV 能量计算表格，也有艺术字变体设计，单靠模型的视觉理解不够。我们先把包装拆成不同的视觉模块，分别选择更合适的 OCR 和 VLM 方案，再把固定规则脚本化，把热量表和 NRV 的计算逻辑固化成确定性代码，让模型只做解释和补录建议。蛋白质 2.9g、每份 40g、NRV5%对不对这类问题，从此实现可复现地验证。

再补上降级和审计策略。每个模块的审核结果都带来源置信度，每个结论都能追溯到原始数据，人类员工接手时，清楚该信什么、该查什么。

单次审核做准之后，再把它放进包装开发的完整工作流。包装审核的上游是产品需求和包装设计，下游是包材采购和物料生产。接入整个产品生命周期管理的基础设施和上下文之后，审核这个单点 Skill 开始从“看一张图、挑一堆错”，变成常态化的自动预审。

设计稿一提交，Skill 就按规则跑一轮预检，把合规问题、NRV 计算、数字矛盾，在设计师交给下游之前就拦下来。

我们还搭建了包装管理系统，把历史上线经验沉淀下来。每一个最终上线、被市场或监管验证过的包装，都是一份高质量样本。把这些样本的标准、驳回记录、整改闭环放进上下文，就能基于“过去哪些设计最容易踩坑”去评估当前方案，提前告诉设计师，这个渠道的标识位置历史上被退过三次，建议你这么放。

包装开发和审核只是产品生命周期的一个单点，我们后来不太愿意把自己的东西简单叫成“一个 AI 系统”或者“一个中台”。我们真正想做的是先把业务流和信息流梳理出来，然后让不同的 Agent 和应用自然长在产品生命周期业务链上。

比如产品经理接到来自老板或销售渠道的模糊需求，和 Agent 一起讨论，将模糊需求转化为产品概念需求，研发接到产品概念需求之后，调用历史打样版本、当前物料等上下文，和自己的 Agent 讨论怎么把需求转化成可打样的方案。

这样一来，AI 嵌进了流程本身，成为其中的一部分。

Q4相比传统方式，使用 AI 后的实际效果如何？

这件事的第一个变化，是人的时间开始被重新分配。

以包装审核为例，原来法律法规人员会被大量低级错误和重复检查占用。现在可以先让 AI 把这两类问题筛掉，把真正需要专业判断的问题留给人。

这样，法律法规人员可以减少处理低级错误和返工的时间；产品经理可以把更多时间放到“这个包装到底应该怎么表达产品”这样的判断上。

但我认为更重要的变化，其实发生在“经验”这件事情上。

过去，一个产品经理的判断就是这个产品经理自己的经验，一个研发的判断也是这个研发自己的经验。现在，我们开始把每一次决策、每一次渠道反馈、每一次审核经验沉淀下来。

这意味着，AI 带来的价值，是让个人经验有机会变成组织经验，让一个人的经验开始服务于整个组织。

此外，更有价值其实是这个组织的变化，业务人员自己成为 Builder，学习和参与重新搭建自己和 AI 协作的工作流。

我们和客户一起参加食品展会、带客户的高管一起参加了 Datawhale 举办的黑客松还拿了冠军，回来之后又在客户公司内部组织了一场黑客松。我们没有停留在“AI 工具怎么用”的讲解上，直接从组织战略开始，一层层拆到业务流程，再拆到每个人具体的输入、输出和处理方式。引导大家做出自己自己可以真正使用，又能够为组织整体价值链条提效提质的东西，比如电商视频编导、考勤自动清洗等等工具。

我把这次的效果理解成三层：第一层是降本增效，第二层是提高决策质量，第三层是把个人 Know-how 变成组织能力。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

其实非常多，而且很多都是我们必须踩的坑。

第一个挑战，是从承接问题，到定义问题。

能交给 AI 解决的问题，未必都值得做。一个适合 FDE 落地的问题，至少要同时满足几个条件：它必须是业务同学真实存在的问题，必须有业务价值，而且解决之后最好能够找到可以衡量的指标。这几个条件同时成立，其实非常难。

第二个挑战，是从构建软件系统，到定义组织系统。

最开始我们是承接需求的人，对方提出需求，我们负责解决。但做着做着就发现，这个逻辑会让项目没完没了。因为业务方不可能把一个需求完整、准确地定义出来，更不可能期待 AI 稳定地 100%满足一个没有边界的需求。

因此，我们认为 FDE 本质上是在和老板、中层、业务同学，一起共同搭建一个 AI 和人协作的组织系统，并被套一个软件系统，又拆成了三步：

第一，共同梳理业务流，从组织目标，到价值链，到岗位，再到输入输出，最后找到这个岗位可以由 AI 帮助完成什么。可能给老板相对完整的问题和解决方案，然后再一起为这些问题进行价值排序。

第二，共同搭建系统的雏形，我们通过工具和认知的培训，让业务同学一起参与 Build，业务方自己知道哪些知识是重要的，哪些上下游需要调用他的知识库，什么样的 Skill 才能真正符合他的工作方式。

第三，才是 FDE 介入工程化，去让单次执行更稳定，或是和现有软件系统对接起来，再或是在此之上快速搭建新的软件系统，流程 SaaS、插件甚至多维表都只是这些能力的表现形式。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

第一，先解决人的问题，再解决技术问题。

现在大模型、Skill、知识库、Workflow 这些东西越来越容易获得，真正难的是一个组织到底应该怎么用它们。

我把 FDE 的工作理解成“AI HRBP + AI 架构师”。AI 架构师负责底层系统怎么搭，知识库、Skill、Workflow 以及各种 Agent 怎么连接，怎样让它们最终进入真实业务流程；AIHRBP 负责搞清楚这个组织到底有什么问题，不同角色在做什么，他们为什么这么做，哪些经验应该被沉淀，哪些事情应该交给 AI，哪些事情必须留给人。

第二，用“点—线—面”把组织梳理清楚。

我们和甲方一起迭代出了一套“点—线—面”的方法。

面，是组织最终创造什么价值。先看公司的战略目标，以及它最终到底靠什么创造价值。

线，是组织内部的一条条价值链。把战略目标拆成具体的业务流程，看看价值是怎么一步步产生的。

点，是每一个岗位。一个人在这条价值链上到底承担什么角色？输入是什么？输出是什么？哪些事情是他的 Know-how？

当这三层梳理清楚以后，AI 应该放在哪里，反而会变得比较清楚。

第三，技术复用，人的部分个性化。

我现在不太相信“一个 FDE 拿着一套方案，到客户现场部署一下”这种模式。真正的 FDE，应该有自己的技术基础设施和通用架构能力，但到了具体业务里，要做的是技术复用，人的部分个性化。

底层的模型、架构、知识库、Skill 这些能力可以复用；但每一家企业的人、流程、组织、经验和决策方式，都需要重新理解。

FDE 这个职业，未来可能也不会一直独立存在。现在需要 FDE，是因为业务角色还没有普遍具备 AI 能力，需要有人站在业务和技术中间，把两边连接起来。

如果未来 AI 能力像今天的互联网一样，成为每个人的基础能力，那么消费品产品经理、

研发、设计师、销售，可能都会变成某种意义上的“AI 增强角色”。

到那时，真正留下来的，可能从职位名称变成一种能力：既懂业务，又懂 AI，既能发现问题，又能把问题真正落到业务流程里。

从看不清订单到看清经营：FDE 用 AI 让制造企业的经营流程更透明

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我做的这个案例，最开始先跟老板聊他到底想解决什么问题。

这是一家汽车供应链企业，主要向下游销售汽车维修零部件。它的生产形态偏轻，主要从上游采购零部件，再做一些简单加工、组合和组装，最后形成产品交付给客户，跟传统意义上那种重生产线的制造企业很不一样。

表面上看，这家企业其实已经有 ERP 系统，订单、生产任务、采购、库存、发货等数据都有。问题是，这些数据虽然存在，但并没有真正形成老板需要的“经营视角”。

老板真正关心的是：客户下了一个订单之后，企业内部到底怎么往下走？生产任务有没有正常推进？采购有没有多订？库存到底有多少？什么时候能发货？财务现在要付给供应商的钱，到底对应哪些客户订单？

老板每天有大量事情要处理，不可能自己逐条核对，所以很多时候只能问下面的人。

这也是我理解 FDE 和普通软件外包最重要的区别：我先站在老板经营的角度，找到真正影响经营的问题，再据此开始开发。

比如这个企业老板，他真正想要的，是企业能够尽量自动化地运行。他希望自己不用每天盯着工厂，也能知道现在有多少订单进来了、多少正在生产、多少已经收货、多少已经发货、多少已经回款；如果中间出现异常，再主动告诉他。

所以最后我们把问题收敛成了几个很具体的事情：让订单流转变得透明，让不同业务数据能够对应起来，让异常能够被发现，让老板不用再依赖人工询问。

Q2在你参与之前，这个问题过去是怎么解决的？

过去他们其实有自己的解决办法。

企业使用的是管家婆这样的标准化 ERP，里面已经能够看到客户订单、生产任务单、供应商采购订单、库存以及发货等信息。对于标准化的企业管理来说，这套系统本身是能够工作的。

所以我不会说原来的方式“不好”。

问题在于，ERP 解决的是一个标准化的信息管理问题，而老板需要的是一个更加贴近企业经营的判断视角。SaaS 产品为了保持标准化和商业 ROI，本身不会针对每一家企业的经营方式做大量深度定制。

于是就出现了一个很典型的情况：数据都有，但老板还是看不清。

举个很简单的例子。

供应商给企业发来 5000 个扳手，但实际只发了 4980 个，少了 20 个。按照原来的 ERP 逻辑，因为数量没有完全达到 5000 个，这笔订单可能就无法正常入库。

但现实业务不会因为少了 20 个，就把 4980 个扳手退回去。仓库里实际上已经多了 4980 个，只是系统的标准逻辑没有办法很好地表达这种“实际发生了，但标准流程没有完整结束”的情况。

这类问题如果靠人工处理，就意味着员工需要额外记录、解释和沟通；如果老板想知道真实情况，又得再去问人。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我当时做的第一件事，是先把老板的经营诉求拆出来，没有急着写代码。

因为如果直接问老板“你想要什么 AI 功能”，最后很容易得到一堆功能需求。但如果问的是“你每天最担心企业发生什么”“哪些事情你必须亲自盯”“哪些异常一旦发生你希望

第一时间知道”，得到的东西就完全不一样。

这个项目最后形成了一个比较清晰的思路：

第一步，先明确老板要看什么。

老板真正要看的，是企业现在经营到什么状态。所以我们围绕订单、生产、采购、库存、发货、回款这些关键环节，把老板真正关心的信息梳理出来。

第二步，保留原来的 ERP，把必要的数据拿出来重新组织。

我没有去重新开发一套 ERP。原有系统继续承担原来的业务功能，我们在它的数据基础上做二次加工。因为真正的问题在于，“系统里的数据没有按照老板的经营逻辑串起来”。

第三步，让 AI 去做过去大量依靠人工完成的数据匹配和核对。

比如财务要支付供应商 10 万元，过去要回答“为什么要付这 10 万元”，可能需要人工去对应供应商订单、客户订单、库存签收等信息。

这时候 AI 发挥作用的地方，在于做数据之间的匹配、核对和关联。

也就是说，我更愿意把这里的 AI 理解成一个“数据关系处理器”：它帮助系统判断不同业务环节之间到底是什么关系，有没有对得上。

第四步，把异常从“人去发现”变成“系统主动提醒”。

企业正常运行的时候，我希望它自己往下走；只有出现问题的时候，才需要人介入。

所以我们给一些关键业务节点设置判断标准，例如价格是否合理、库存数据是否异常、

应付款能不能和相关业务数据对应起来。一旦出现异常，就通过飞书卡片提醒相关人员。

这实际上形成了一个很简单的闭环：正常情况自动运行 → 数据持续匹配核对 → 发现异常 → 主动提醒 → 人处理异常。

对我来说，这比单纯做一个“AI 助手”更有价值，因为它真正嵌进了原来的业务流程。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目目前上线时间还比较短，所以我会比较谨慎地说：现在还不能证明企业的利润、成本或者其他经营指标已经发生了明确的量化提升。

但有一些变化是已经能够直接感知到的。

以前 ERP 里存在一些“有数据但看不清”的情况，现在已经可以把它重新呈现出来。

还是刚才那个 4980 个扳手的例子。原来的 ERP 可能因为没有达到 5000 个的标准数量，所以没有办法很好地反映真实库存；现在我们可以告诉老板，实际库存里已经增加了 4980 个。

这看起来只是一个很小的变化，但对于老板来说，区别在于：系统开始更接近真实业务了。

另外一个比较明显的变化，是财务应付款的可追溯性。

还是前面财务应付款那个例子。以前老板看到“今天要付给某个供应商多少钱”，可能只能看到一个结果；现在可以进一步追溯，这笔钱对应了哪些客户订单、哪些上游采购，以及为什么形成这笔应付款。

所以目前这个项目更像是完成了从“有没有这个功能”到“经营信息能不能被看清楚”的

第一步。

老板最初想要的三件事情里，“企业能够尽量自动运行”和“出现异常能够通知他”，目前基础功能已经实现；至于减少重复订货等更进一步的经营效果，还需要继续运行一段时间才能验证。

我觉得这一点也很重要。做 FDE 不能为了证明 AI 有效，就把刚上线的项目包装成已经产生巨大经营收益。业务价值需要时间验证，能明确解决什么、还不能证明什么，都应该讲清楚。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目让我比较深地意识到，FDE 真正难的地方，很多时候在 AI 技术之外。我自己总结下来，至少有四个挑战。

第一个挑战，是老板的认知。

我原来是互联网大厂产品经理出身，和制造业老板看问题的方式并不一样。

所以第一步，我先理解他的经营逻辑，同时让他知道 AI 到底能做到什么、不能做到什么。

如果这一步没有对齐，后面的方案很容易跑偏。

第二个挑战，是行业 Know-how。

我现在接触的客户不只有制造业，还有医疗、贸易、物业、集采等，不同行业的业务规律差别很大。

FDE 不一定要成为这个行业最资深的专家，但至少要知道这个行业基本是怎么运转的。

否则你连客户真正的问题是什么都判断不了，更不用说设计方案。

所以我现在越来越觉得，行业理解，是 FDE 进入业务现场的门票。

第三个挑战，是数据。

这也是这个制造业案例目前没有办法直接标准化复制的主要原因。

最开始我也想过，既然这套方案做出来了，是不是可以直接复制给其他制造业企业。

但真正做下去之后发现，即便是同一个行业、规模差不多的企业，底层的数据基础、数据口径、业务流程都可能差很多。我们在这个项目上花了大量时间做数据清理、数据治理和口径整理。

所以最后我反而没有急着把它包装成一个标准化产品。

方法论可以复用，但底层的数据和业务逻辑，未必能直接复制。

第四个挑战，是 ROI。

这是我自己做 FDE 之后越来越在意的一件事情。

以前做大厂产品，我们会习惯把事情做到 80 分、90 分。但到了真实企业场景里，你还得问一句：做到 80 分到底划不划算？

因为 FDE 的核心成本就是人的时间。如果一个项目需要投入大量人力做数据治理、长期维护和定制开发，那么即使客户觉得项目很好，对 FDE 团队来说也不一定是一门好生意。

所以我现在不会只看“这个需求能不能做”，还会看“这个需求值不值得做”“长期维护的成本是什么”“这个项目的 ROI 是不是合理”。

这也是我后来开始主动寻找更加标准化场景的原因。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

我现在越来越觉得，企业做 AI，最容易犯的错误就是为了 AI 而做 AI。

我以前所在的金融机构就发生过类似的事情。

当时业务部门觉得找设计师做营销图片很慢，希望用 AI 提高效率。从业务逻辑上看，这个需求完全合理。但因为金融机构有数据合规要求，不能直接使用外部模型，最后只能做本地部署。

结果就是花了不少钱搭了一套 AI 图片生成系统，但生成出来的图片实际不能用。最后 IT 部门完成了“AI 转型”，合规部门完成了数据安全要求，领导也可以说企业完成了 AI 转型，但业务部门还是回去找设计师做图。

从企业经营的角度看，什么都没有改变。

所以如果让我总结现在做 FDE 的一些经验，我会特别强调几个事情。

首先，AI 转型最好从老板真正关心的经营问题出发。

老板要解决的是降本增效、安全、效率、经营透明度等问题。先把这些问题找出来，再判断 AI 能不能介入。

其次，业务部门必须有动力、有资源。

IT 当然要参与，但不能变成“IT 部门为了完成 AI 转型而推动 AI 转型”。真正每天承受业务问题的人，才最清楚什么地方值得改。

所以最好由老板主导，或者由真正承担业务指标的负责人推动，并且给业务团队足够的资源和权限。

第三，FDE 要同时具备三种能力：懂业务、懂 AI、能落地。

只懂技术，很容易变成技术外包；只懂咨询，又可能停留在方案层面；只懂业务，也很难真正把 AI 落到系统里。

FDE 真正有价值的地方，就是把“经营问题”一路往下拆成“业务流程”，再拆成“数据和系统”，最后才落到具体的 AI 能力。

最后还有一点，是我自己现在特别有感触的：不要一开始就执着于做一个完美的标准化产品。

真实企业的业务往往很复杂，同样一个问题，在不同企业里可能有完全不同的数据基础和处理方式。先进入真实场景，把一个问题真正解决掉，再从多个项目里找到共通的方法，最后再判断哪些部分值得标准化。

我理解的 FDE，本质上就是这么一个过程：从老板的经营问题出发，进入真实业务现场，找到 AI 真正能够创造价值的节点，再把技术变成业务流程的一部分。

AI 降低了过去很多项目的开发和交付成本，让一些以前因为成本太高而被搁置的问题重新变得可行。但企业真正的诉求并没有因为 AI 出现而改变。改变的是，我们现在有机会用更低的成本、更高的效率，把过去那些长期存在的问题真正解决掉。

对我来说，这可能就是 FDE 最核心的价值：帮企业找到“什么问题值得用 AI 解决”，并且一直跟着这个问题走到真正落地。

从人工绘图到智能协作：FDE 用 AI 重塑建筑图纸交付流程

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我们关注的业务场景，是建筑消防施工图的自动生成。

在建筑设计过程中，消防施工图是一类非常典型且高频的专业设计任务。一个常规商业建筑项目，仅消防施工图就可能涉及数百个空间的设施布置。设计人员需要根据建筑 CAD 图纸，逐一完成喷淋系统设计、消火栓布置、灭火器配置以及相关管线规划。

这些工作并不是简单的“画图”。每一处设施的位置、间距、参数都需要对照消防规范进行判断。比如：这个空间属于什么危险等级？应该选用什么 K 值的喷头？喷头之间的间距是否在规范允许范围内？消火栓的覆盖半径是否满足要求？

在这个过程中，我们发现：

第一，大量时间消耗在重复性操作上。同一栋建筑可能有几十个功能相似的空间（如办公室、走廊），每个空间都需要重复类似的消防设施布置流程。设计人员的大量精力消耗在执行重复规则上，真正用于创造性设计的时间被严重挤压。

第二，规范检查占用大量精力。消防规范条目繁多，不同空间类型对应不同参数要求。

设计人员完成初步布置后，还需要逐项检查：间距是否合规、覆盖是否完整、参数是否匹配。这个核对过程往往比绘制本身更耗时。

第三，修改迭代成本高。建筑方案调整是常态，每次平面布局变动，消防施工图都需要同步修改。过去这种修改只能靠人工逐处调整，牵一发而动全身。

所以这个问题的本质在于：如何让 AI 理解建筑图纸这种专业图形信息，并结合消防行业规则完成可用的生成结果，同时让设计人员保持对最终成果的控制权。

Q2在你参与之前，这个问题过去是怎么解决的？

在我参与之前，企业主要依靠设计人员使用 CAD 软件配合消防规范手册完成工作。

这种方式在项目规模较小时能够正常运转。设计人员凭借专业知识和经验，可以灵活应对不同项目的特点。但随着业务量增长，人工方式开始面临瓶颈。

首先，效率天花板明显。一个熟练的设计人员，一天能完成的消防施工图面积是有上限的。当项目集中到来时，只能通过增加人力来应对，但培养一个合格的消防设计人员需要较长时间。

其次，经验难以标准化。不同设计人员对规范的理解和设计习惯存在差异，同类型空间的消防布置可能因人而异。这导致图纸质量不一致，审核环节需要额外投入精力。

另外，还有一个被忽视的问题。行业中也出现过一些数字化尝试，比如消防设计插件或参数化工具。但这些工具通常只解决单点问题（如自动计算间距），无法覆盖从图纸理解到成果输出的完整流程。设计人员仍然需要在多个工具之间切换，实际效率提升有限。

因此，我们希望探索一种新的方式，推动 AI 贯穿图纸理解、规则判断、结果生成的全流程，真正改变设计人员的工作方式，而非停留在做辅助小工具。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

在开始做 AI 应用之前，我们首先需要理解设计人员真实的工作过程。建筑图纸是一种包含空间关系、图形符号、标注信息的专业载体，通用大模型无法直接理解。

整个解决过程分为几个关键步骤。

第一步，解决 AI 理解 CAD 图纸的问题。

建筑 CAD 图纸包含大量专业信息：墙体、门窗、空间标注、面积数据等。系统需要准确识别这些图形元素，理解建筑空间结构，才能为后续的消防布置提供基础。这不仅是图像识别问题，还涉及对建筑制图规范的理解。为此，我们自研了专用模型来处理 CAD 图纸的图形解析，使其能够准确提取空间信息和建筑元素。

第二步，将消防行业规则系统化。

消防施工图是高度规则化的设计工作，不能自由发挥。不同空间类型（办公、商业、车库、设备用房等）对应不同的危险等级；不同危险等级决定喷淋系统的 K 值、喷头间距、保护面积等参数；消火栓的布置需要考虑覆盖半径和消防通道要求。

我们需要将这些规范条文转化为系统可以执行的规则引擎，让 AI 在生成方案时自动遵循行业标准，而非自由发挥。

第三步，设计人机协作的工作模式。

从一开始我们就明确了一个原则：AI 负责生成，人负责决策。

在实际流程中，AI 承担图纸理解、空间识别、规范匹配和初步方案生成的工作；设计人员负责审核生成结果、根据项目特殊情况调整参数、做出最终专业判断。

具体来说，对于常规空间（如标准办公室、走廊），AI 可以使用默认参数快速生成消防布置方案；对于特殊空间或复杂场景，设计人员可以进一步调整危险等级、K 值、喷头间距、布置方式等参数。AI 生成的结果定位为“专业可用的初稿”，最终决策权始终在设计人员手中。

这种设计背后的考量，是尊重专业人员在设计流程中的核心地位，让设计人员把精力集中在真正需要专业判断的环节。

Q4相比传统方式，使用 AI 后的实际效果如何？

AI 应用之后，最直接的变化体现在效率层面。一个大型项目的消防施工图完整绘制原本需要数天时间，设计人员需要逐个空间完成设施布置，再逐条核对规范合规性。在 AI 辅助生成后，项目方反馈，大型项目大约 30 分钟即可生成初步结果，设计人员在此基础上进行调整和确认。

效率提升的背后，是工作重心的转移。

引入 AI 之前，设计人员的工作内容大致是：70%绘制和规范检查等执行类工作，30%专业判断和方案调整。AI 进入流程后，执行类工作由系统承担，设计人员可以将更多精力投入到方案优化、特殊场景处理和整体质量控制上。设计人员的角色从“执行者”向“审核者与决策者”转变。

同时，AI 也拓展了新的业务场景。

例如在投标阶段，企业过去需要投入大量时间准备消防方案和图纸。时间紧迫时，往往只能做一个粗略的方案。现在通过 AI 生成能力，企业可以在短时间内完成更完整的消防方案呈现，提升投标阶段的方案质量。

更深层的价值在于，消防设计经验和规范知识被系统化沉淀。过去，优秀设计人员的经验存在于个人脑中，难以复制和传承。现在通过 AI 系统，规范知识和设计逻辑可以被工程化，让团队整体设计能力更加稳定可控。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

在实际部署过程中，我们遇到了几个关键挑战。

第一个挑战：自动化程度与专业控制权的平衡。

最开始，用户对 AI 的期待是“一键生成完整施工图”，因为这样效率最高。但在实际使用过程中，专业设计人员表达了不同意见：他们希望保留更多调整空间。

原因是消防设计涉及责任问题。设计人员需要对最终图纸的合规性和安全性负责，他们不能接受一个“大概对”，或者“完全黑箱”的生成结果。不同项目存在差异，某些特殊空间确实需要设计人员根据实际情况调整参数。

我们的应对方式是提供分层设计：对于常规空间，提供默认参数的一键生成能力，降低使用门槛；对于专业用户，开放危险等级、K 值、喷头间距、布置方式等参数的调整入口。让系统既能够快速产出，也能够精细控制。

第二个挑战：工程场景对可靠性的高要求。

与通用 AI 应用不同，工程设计场景对准确性要求极高。一个喷头位置偏差可能影响消防验收，这不是“差不多”可以接受的。

因此，我们在系统设计中明确了边界：AI 负责基于规范规则的自动化生成，但不做超出规则范围的“创造性判断”。最终方案必须经过设计人员审核确认，系统在关键节点设置人工确认环节。同时，我们确保基础输入数据（建筑图纸信息）的准确性，因为输入错了，后续一切生成结果都不可靠。

第三个挑战：让设计人员接受新的工作方式。

对于习惯了全手工绘制的设计人员来说，接受 AI 辅助需要心态转变。部分设计人员最初担心 AI 会替代他们的工作，也有一些人对 AI 生成结果的可靠性持怀疑态度。

我们的做法是让设计人员在实际使用中体验价值，而非强行说服。当他们亲眼看到 AI 大幅缩短了初步工作时间，且生成结果质量可控时，态度自然发生转变，自下而上推动我们的的模型和应用产品重塑企业传统工作流。关键是让用户感受到，AI 的角色是帮他们承担执行性工作，让他们去做更有价值的专业判断。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

通过这个案例，我们最大的体会是：AI 落地首先要找到真实业务问题，而不是拿着 AI 能力去找场景。

第一，进入业务现场，理解用户每天在解决什么问题。

对于 FDE 来说，不能坐在办公室里想象用户需求。在这个项目中，只有真正看过设计人员如何在 CAD 里逐条核对规范、如何为一个参数调整反复修改图纸，才能理解哪些环节真正消耗时间，哪些问题值得用 AI 解决。

第二，明确 AI 在业务流程中的角色边界。

不是所有环节都适合 AI 介入。在这个场景中，规范化的绘制和规则检查适合 AI 承担，但最终的专业判断和责任必须保留给设计人员。明确这个边界，既能发挥 AI 的效率优势，也能保证专业质量。

第三，关注落地细节，而不仅是技术效果。

AI 项目的成功取决于多个维度：用户是否愿意使用？工作流程是否需要大幅调整？生成结果的格式是否符合行业交付标准？这些问题往往比模型能力本身更关键。在这个案例中，如果 AI 生成的图纸格式不符合设计院的标准，即使内容正确也无法进入实际流程。

最终，FDE 的核心价值在于连接业务、技术和用户，让 AI 真正进入企业流程并产生实际价值。FDE 需要同时理解业务语言和技术语言，在两者之间做好翻译和桥梁。这也是 FDE 区别于传统 AI 工程师的关键所在：我们从技术交付出发，最终推动的是工作方式的实际改变。

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

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

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

客户是一个十几人的跨境电商团队，主要做东南亚市场，主营服装。服装行业每个颜色、每个尺码都会形成一个独立 SKU，所以 SKU 特别多。按照访谈中的估算，他们每个季度新增 500～800 个 SKU，全年 SKU 大概在 2500～3000 个。对于一个 10～15 人的团队来说，这样的 SKU 数量和平台复杂度已经不低了。

他们过去的库存数据集中在一个多平台聚合 SaaS 里，各个电商平台的库存会汇总进去，但新品开发、部分业务信息又在飞书里，两边没有打通。客户最开始找到我时，说得非常简单，能不能把这个 SaaS 和飞书打通。

我没有急着把它当成一个 API 集成项目。如果只是集成，技术上没有太大障碍，真正要问的是，打通以后谁用，用来解决什么业务问题。

所以我们没有急着开发，连续开了几次会，让客户录屏演示他们实际怎么工作。也正是在这个过程中，我们才逐渐看到，库存只是整条链路上的一个环节。

工厂发货时没有用 RFID 或者扫码枪，物流环节仍然靠拍照、识图，再由员工人工看照片、填写数据，追踪物流单号和进展。数据已经产生了，人还在充当那个“数据搬运工”。

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

广告的问题更直接。他们每天在 Google、TikTok 等平台投广告，广告是持续烧钱的。如果某个 SKU 库存已经很低，广告还在继续跑，客户继续下单，企业却发不出货，广告费用还在继续消耗。

所以我最后看到的，是一条业务链。订单和库存数据 → 物流数据 → 补货决策 → 供应商下单 → 广告投放。

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

Q2在你参与之前，这个问题过去是怎么解决的？

过去这家团队的工具不算少，Excel、聚合 SaaS、飞书都在转。最累的，是那个在各个工具之间来回搬数据的人。

十几人的团队，业务规模还不大的时候，一个人来回搬数据也应付得过来，成本也不高。他们补货也有一套自己的公式，工作人员看 SKU 过去三个月的销售，结合自己的预测逻辑，就能算出下一次该补什么颜色、什么尺码、补多少。这套逻辑是成立的，问题在于它被埋进了一条需要人工反复搬数据的流程里。

所以我们没有重新发明一套库存算法。客户原来的补货逻辑可以继续保留，我们要做的，只是把其中机械、重复、跨系统的动作交给机器。

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

工作人员先把数据从一个系统里扒下来，填进 Excel；Excel 算完，又誊到另一个模板；

物流照片到了，再一张张人工看；广告又在另外的平台上跑。

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

SKU 还在涨。几十个、几百个的时候，人盯得过来；涨到几千个，人一天的时间就大量耗在“看、抄、填、核对”上。规模越大，人越被钉在这些搬运动作上。

我们的改造，是把这条人工链路拆开，看清哪些环节必须由人做，哪些环节机器做得更好，再把机器擅长的部分接上。工具没换，人不用再当那个中间连接件。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

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

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

如果按照传统项目交付的方式，我可能就直接拿需求、评估接口、开始开发。但 FDE 的工作方式不太一样，我需要先判断客户真正想解决什么。

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

第一步，先把数据打通。

我们做的第一件事，是先把数据基础搭起来。

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

这个过程中，碰到了整个项目里最难啃的技术问题。对方 SaaS 的 API 开放程度很低，Key 的机制也满足不了客户多个团队同时共享数据的需求。最后我们增加了一层开源的云端数据库（Supabase）做中转，让数据先进入这个中间库，再从这里同步到飞书。

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

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

数据打通之后，一个非常明显的人工瓶颈冒了出来，物流照片。以前工厂拍完照，上传到多维表，接下来全靠员工一张张看图、回填。

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

所以我们让 Agent 参与“识图\+回填”，同时保留人工确认。AI 负责把原来最耗时间的第一轮识别和数据录入做掉，人只需要最后检查。这一点我很看重，AI 放在这里，是因为这段工作本来就适合它。

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

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

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

人工的角色从“计算员”变成了“审核员”。如果结果没问题，确认之后就可以直接生成 PDF 订单发给供应商。

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

做到这里，客户又自然产生了下一层需求。既然现在已经知道库存了，那是不是可以让库存反过来影响广告？

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

当某个 SKU 库存下降到一定程度时，Agent 可以判断对应广告是否还应该继续投。如果库存不足，就先把广告额度调低，甚至暂停广告，避免一边烧广告、一边发不出货。

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

客户一开始自己也没有把这些需求全部想清楚。很多时候，他只是知道“我现在很痛”，但不知道技术应该怎么解决。FDE 要做的，就是把这种结果导向的需求，拆成可以落地的业务和技术问题。

图 1：东南亚跨境电商场景下的 AI Agent 方案架构（原 PDF 此处配图缺失，未能收录）

Q4相比传统方式，使用 AI 后的实际效果如何？

这个案例有一个特别的地方，交付结束后，客户把我们的团队权限移除了，后续的营收、广告成本和利润数据，我们没有拿到完整的。但时间效率上的变化是比较明确的。

以前处理物流照片和数据，一个人每天大概需要花 4～5 个小时去看图片、写数据。现在 AI 先完成识别和回填，人只需要做最后的核对，整体时间被压缩到了 1 小时以内。

补货也是类似。以前从不同系统扒数据、对数据、填 Excel、计算，再整理成订单，至少需要 2～3 个小时。现在 Agent 把结果算出来之后，工作人员主要负责看一眼、验证一下，确认之后就可以生成订单。

所以我更愿意把这个项目的价值概括成三个变化。

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

尤其第三点，我认为比单纯节省几个小时更重要。

以前库存是一个结果，广告是另一个动作，两边其实是割裂的。现在库存变化可以直接影响广告投放，业务开始从单点自动化走向了流程之间的联动。

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

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

这个项目真正难的地方，其实不在 Agent 怎么写。最难的是两件事，需求，以及现实世界里那些“不好用的系统”。

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

客户一开始说的是“帮我把两个系统打通”。但如果我们就照着这个需求做，可能最后只是交付了一个 API 接口，而没有解决他真正的问题。

所以我们反复让客户演示工作流程，甚至让他录屏。只有把“他每天到底怎么工作”看清楚以后，我们才发现后面还有照片处理、补货、供应商下单、广告投放等一系列问题。

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

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

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

甚至我当时在和技术团队开会之前，会先让 AI 帮我把客户的需求重新梳理一遍，再拿去跟技术人员沟通。这本身就是一种 AI 优先的工作方式，AI 先帮助我提高自己的理解和表达效率，项目本身仍然由我来推进。

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

一开始我们想得很简单，有 API，就可以接。

真正做起来以后才发现，SaaS 方提供的 API 虽然能用，但 Key 有失效机制，一个 Key 也不能被多个团队同时使用。如果 A 团队刷新 Key，B 团队原来的 Key 就会失效，而客户除了我们之外，实际有多个团队需要共享这个 key 去拉数据。

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

这件事让我印象很深，它说明了一个问题，现实世界里的 AI 落地，很多时候卡在模型之外，企业原有系统的开放程度、数据结构和接口限制，往往才是真正的门槛。AI 本身可能已经能做了，但数据根本拿不出来，还是落不了地。

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

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

一些非常确定、规则非常死的任务，其实写一个脚本、跑一个定时任务就够了。只有当任务开始涉及语义理解、跨系统判断，传统脚本比较难覆盖的时候，才需要引入 Agent。

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

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

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

做这个行业越久，我越确信，FDE 真正的壁垒并不在“会不会搭一个 Agent”。

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

我自己总结下来，有几个比较重要的经验。

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

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

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

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

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

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

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

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

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

这个案例里，我们没有追求 100%无人化。图片识别之后，保留人工核对；补货计算之后，人工确认；广告调整也是基于库存情况做业务判断。

我认为这是比较现实的 AI 落地方式，AI 负责处理大量重复工作，人负责最终判断。

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

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

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

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

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

比如表格应该怎么设计、业务流程在哪几个环节最容易出问题、Agent 应该插在哪里、

客户通常会有哪些需求，这些经验都会逐渐沉淀下来。

我认为真正可持续的 FDE，是找到自己最擅长的行业和场景，把一个行业反复做深。

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

这个案例最大的遗憾，就是我们当时交付完以后，没有把后续效果完整追踪下来。主要是我们以往的合作模式也是偏向外包的方式，对于效果的追踪没有那么重视。

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

后来我们也意识到，这其实应该成为 FDE 服务闭环的一部分，交付、使用、反馈、迭代、效果归因，再进入下一轮优化。团队后来也开始探索更系统的回访和数据收集方式。

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

项目上线前，记录人工处理需要多少时间；上线后，再持续记录需要多少时间；补货、

广告、订单等关键环节，也尽量找到可以量化的指标。

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

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

从老板报价到长尾承接：FDE 用 AI 打通工程租赁获客与报价

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我觉得做 FDE，第一件事其实是先把老板真正想解决的问题搞清楚，再判断这里能不能用 AI。

工程租赁就是一个很典型的例子。我们接触到的客户，本身是一个比较典型的中小企业。这个行业有一个很明显的特点：老板往往就是唯一的销售、唯一的调度，很多管理工作也都在老板身上。

这家企业的客户结构也很典型：营收 3000 万的时候，可能 2500 万来自几个大客户，剩下 500 万来自大量的小客户。在业务上行的时候，这 500 万的长尾客户其实可以不管。老板精力有限，大客户就已经够忙了，小客户丢了也就丢了。

但是到了下行周期，情况完全不一样。原来觉得无所谓的 500 万，可能明天就真的没有了。这时候老板就会发现，自己有客户，却没有能力把所有客户都接住。

所以我们真正要解决的，是一个更具体的问题：老板没办法服务的那些长尾客户，能不能被接住？

再往下拆，问题就更清楚了。

比如一个 10 万元左右的小订单，看起来金额不大，但真正报价的时候，远比简单的加减法复杂。客户租什么车、要不要配操作员、油费怎么算、距离多远、运输成本是多少、

具体干什么活，不同作业类型又会影响折价。这些因素叠在一起，最后形成的是一个比较复杂的报价判断。

面对这种情况，我不会纠结方案“是不是纯 AI”，因为真正解决问题的东西，本来就应该是混合的：一部分是模型和 Prompt，一部分是传统的业务规则，还有一部分甚至是运筹学。只要最后能解决老板的问题就行。

Q2在你参与之前，这个问题过去是怎么解决的？

其实过去这种方式完全可以运行，而且在业务增长期甚至是比较合理的。

因为大客户的价值足够高，老板亲自谈、亲自报价，是最有效率的方式。价格不透明、

订单金额大、影响因素复杂，这些事情交给老板判断，反而比做一个复杂系统更靠谱。

真正的问题出现在长尾订单上。

一个小客户进来之后，老板同样要把需求、车型、运输成本、人员、油费这些因素都过一遍，再决定最终价格。如果老板正在谈一个大客户，这个小订单就只能放掉。

所以过去的问题，是随着市场环境变化，原来合理的人工分工开始出现了瓶颈。

尤其进入下行期以后，企业开始重新重视那些过去没有被充分服务的小客户。这个时候，原来的模式就出现了矛盾：老板最应该做高价值客户，却被大量低价值、但不能完全放弃的订单占用了精力。

这也是我觉得 FDE 很重要的地方。

如果只是站在技术视角，可能很容易得到一个“做智能报价系统”的结论。但真正进入业务现场以后，你会发现，问题其实是老板的时间应该花在哪里，以及企业有没有能力把老板不应该亲自处理的事情接下来。

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我们的思路其实比较简单，但真正做起来，比单纯做一个 AI 报价机器人复杂得多。

第一步，是先把整个业务链路梳理出来。

我们先把客户怎么获客、客户从哪里进来、怎么询价、哪些订单老板必须亲自处理、哪些订单其实可以标准化这些问题看清楚，再考虑模型怎么选。

这里面我们甚至会把抖音、快手、小程序这些东西一起考虑进去。因为如果前面没有获客入口，后面做一个很漂亮的报价工具，其实没有意义。对于这类客户来说，让客户为了询价专门下载一个 App 也不现实，所以入口反而应该足够轻，比如直接通过小程序承接订单。

第二步，是把订单做分层。

大客户不能交给 AI。因为大客户的价格不透明，而且订单价值足够高，老板自己判断才是合理的。所以我们的做法，是把大客户和长尾客户分开。

对于相对标准化的小订单，系统先收集需求，再根据车型、操作员、油费、距离、作业类型等因素计算一个合理的报价区间。AI 负责和客户沟通，判断订单能不能快速成交。

如果在这个区间里客户接受了，就可以继续往后走；如果不接受，或者判断这个订单比较复杂，就直接放弃，或者转人工。

甚至我们设想的节奏是：一个订单几分钟内完成判断，能成交的就快速进入调度，不能成交的就不要继续消耗老板的时间。

第三步，是把 AI 放进原来的业务流程，让客户沿用原来的工作方式。

这一点其实特别重要。

除了工厂租赁这个客户，我们面对的很多其他中小企业客户，一线员工可能是中年人，学历也不高，甚至不愿意使用小程序。那如果为了技术上的“最优解”，要求他们换工具、改习惯，最后这个东西很可能根本没人用。

所以我们会围绕客户原来的使用习惯做适配。必要的时候，前端做得足够简单，甚至加入语音或者微信 Bot。技术方案未必最优雅，但在真实业务里，它才能真正跑起来。

这也是我对 FDE 的一个理解：适配的方向，是把 AI 做成适合客户业务的人，有的时候让传统企业客户快速进行组织和流程变革反而会出现大问题。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目目前还比较早，我们实际开始做这类业务只有一个多月。但从已经落地的几个点来看，客户对效率提升的感受是比较明显的，他们也是认可这个结果之后，才愿意继续从这个点往下做。

工程租赁这个案例里，我们解决的核心价值，也远远超过“少用几个人”。真正有价值的是，把原来老板没有精力处理的长尾客户接住。

过去一个小订单进来，老板如果正在处理大客户，很可能直接放弃；现在可以先由系统完成信息收集、报价区间判断和初步沟通。只有真正值得老板介入的客户，才把人的精力重新拉回来。

所以我觉得这里的价值应该从三个层面看。

第一，是效率。

原来一个小订单也要消耗老板的时间，现在很多判断可以由 AI 前置完成。

第二，是增收。

长尾订单被承接之后，本身就带来新增收入，这也是我们和客户谈合作时比较核心的价值。

第三，是人的工作方式发生变化。

AI 在这里的作用，是把人的带宽释放出来。老板可以把更多时间放在真正高价值的客户和决策上，而企业也有可能承接更多订单。

我们和这个客户讨论的，除了按年走的系统维护费，还有增收分成的合作方式。不过增收分成的方式在其他客户那里也并不是很好得到泛化，因为增收分成在实际谈判里比较难量化，所以最后怎么设计更好的商业模式，还在探索。

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

真正落地以后，我发现最大的挑战，很多时候在 AI 之外。

第一个挑战，是需求看起来很简单，但真正做起来很复杂。

比如客户说“我要一个内部数据库，再做一个基于数据的搜索”，听起来好像很简单。

但真正进去之后，你会发现数据库到底怎么搭、数据怎么清、数据量多大、检索怎么做，这些成本都很难提前估算。

有些项目最后真正难的地方，其实是数据库和业务数据的整理，跟 AI 模型本身没太大关系。

所以我们后来会特别注意一个问题：不能因为客户说得简单，就默认交付也简单。

第二个挑战，是客户的接受程度。

中小企业老板通常不会因为你告诉他“这是一套先进的 AI 技术”就愿意大规模改造企业。

相反，大刀阔斧地改内部流程，对他们来说风险很高。

所以我们的打法一直是从一个很小的点切进去。

先找一个客户能看见结果、试错成本比较低的问题，做一个 POC（Proof of Concept，概念验证）。POC 跑通之后，客户觉得你靠谱，再继续往下梳理路线图。这条路是边做、边证明、边挖下一步需求，先让客户看到结果，再去谈更大的蓝图。

第三个挑战，是 AI 工具本身不能决定项目成败。

我们接触的几个案例，其实并没有简单套用一个通用 AI 工具。能用现成工具解决当然最好，但解决不了的时候，我们会自己做工程化。

因为真实业务里，很多东西本来就是混合的，智能报价就是这样，光靠一个通用 AI 工具往往解决不了全部问题。

还有一个很现实的问题：使用率可能很低。

如果老板自己都不用，这个项目基本推不下去。所以我们会把“一号位是否愿意采用”

当成很重要的判断标准。同时，不能指望客户员工突然学会一堆新工具，更实际的做法，是把入口做得足够简单，尽可能嵌入他们已经习惯的工作方式。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

下面是一些我的理解。

第一条，不要先找 AI 场景，要先找业务问题。

我们不会刻意要求自己每个项目都必须“AI 味很重”。如果一个问题用传统数字化就能解决，那就用传统数字化；如果 AI 能够让原来的流程效率提升，那就把 AI 放进去。

比如工程租赁这个项目，真正解决问题的其实是整个获客、询价、报价、调度链路，AI 只是其中的一部分。

第二条，是先做小点，再进入大流程。

尤其对于没有品牌、没有咨询溢价的 FDE 团队来说，上来就告诉客户“我们帮你做一次企业 AI 转型”，基本很难。

更现实的办法，是找到一个足够小、足够具体、又能让客户马上看到效果的问题。

先做出结果，再让客户相信你的能力；有了信任，再去谈更大的路线图。这个过程本身就是 FDE 的价值。

第三条，是不要把“标准化”理解成 100%复制。

我们确实会沉淀一些东西。比如销售 Agent、非结构化数据检索、报价系统等，底层工程框架可以复用，代码和经验也可以沉淀下来，下一次遇到类似问题，交付速度就会更快。

但真正做到一个完全标准化、跨行业直接复制的产品，我觉得很难，且绝对的标准化产品往往竞争烈度也是极高的，且对真正想要做 AI 转型的企业客户来说不够深。因为一旦进入客户真实业务，数据、流程和行业规则都会发生变化。

所以 FDE 更适合做的是：底层能力标准化，业务解决方案保持一定程度的定制化。

最后还有一点，我现在越来越觉得重要：FDE 真正需要的人，是既懂 AI、又懂业务、还能够理解企业经营的人，只会写代码或只懂咨询都还不够。

因为 AI 真正进入企业之后，价值远远超过“少三个人”，员工的工作方式、管理方式、评价体系，以及企业能够承接的业务规模都会发生变化。要看到这些变化，就必须理解客户真正的生意。

所以对我来说，我们正在做的事情，是进入业务现场，找到企业原来做不到、做不好或者没精力做的那一小块，然后用 AI 和工程化能力，把这块真正跑通。跑通以后，再一点点往外扩。

这可能才是 AI 从“技术能力”真正变成“业务能力”的过程。

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

Q1作为 FDE，你应用 AI 的具体场景是什么？在这个场景下遇到的具体问题长什么样？

我所在的团队长期服务跨境贸易和消费品企业，帮助企业处理海外市场的数据分析和业务数字化问题。我本人是快消行业出身，过去几年一直在亚太做快消咨询，帮品牌方做出口和海外市场运营，因此比较清楚企业在进入海外市场时会遇到哪些真实问题。

这个案例服务的是澳洲一家头部乳企，做奶酪。他们拓展海外市场时，选择通过经销商模式进入中国和越南市场。对于很多消费品企业来说，这是非常常见的路径：总部负责品牌、供应链和产品，经销商负责当地销售和渠道运营。总部在澳洲，在这两个市场里一个零售触点都没有，货发出去，过了国境就断了。

但问题也随之出现。

一开始接触这个项目时，很多人会认为这只是一个数据对接问题：把经销商的 Excel 接进来，统一格式就行了。但真正进入现场之后，我发现事情远比想象复杂。

对总部来说，发货量只是中间指标，真正重要的是消费者最后购买了多少产品。在业务里，我们通常会区分两个概念：一个是 Sell In，也就是品牌方把货卖给经销商；另一个是 Sell Through，也就是消费者最终从渠道买走多少。Sell Through 更能反映真实市场需求、营销投入效果和消费者反馈，但在跨境场景下，这类数据往往最难获得。

过去，海外业务的信息流转主要依靠人工：总部把订单、发货信息发送给经销商，经销商再通过 Excel、邮件等方式反馈销售情况，中间还涉及语言转换、业务解释和数据整理。看似只是传递数据，但实际上每一步都会产生损耗。

首先是信息滞后。总部看到的数据可能已经是几周甚至更久之前的数据。

其次是数据失真。比如总部问“销售情况怎么样”，不同角色理解可能不同。有人理解为卖给经销商多少，有人理解为消费者购买多少。如果业务理解不到位，数据口径从一开始就可能错。

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

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

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

Q2在你参与之前，这个问题过去是怎么解决的？

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

传统方式在早期阶段是有效的。经销商规模有限，市场变化不复杂，人工沟通能够支撑业务运行。通常流程是：总部发货 → 经销商接收产品 → 经销商整理销售数据 → 销售人员制作 Excel → 业务人员翻译、整理，再反馈总部。

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

首先，数据标准不统一。不同国家、不同渠道的数据格式完全不同。有些数据来自 Excel，有些来自 PDF，有些甚至是图片或者手写凭证。尤其在销售端，数据非常复杂：

字段名称不统一、销售单位不一致、促销活动规则不同、买赠、返利等业务信息难以结构化。比如，同样是一批销售数据，不同市场可能会用不同方式记录“买多少送多少”

的促销活动，如果没有业务理解，很难判断真实销售情况。

其次，审核成本高。过去很多市场费用、营销费用主要靠人工审核。比如经销商提交市场活动费用，总部人员需要判断：这个费用是否合理？这个活动是否真实发生？这个金额是否符合行业水平？但因为材料很多，人工很难做到精细判断。

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

过去企业也尝试过引入 BI 工具和报表系统，希望把经销商数据统一管理起来。但问题在于，这些工具只能处理已经结构化的数据，而海外经销商的原始数据恰恰是非结构化的。工具上线后，数据清洗和整理仍然靠人工，系统只是换了一个地方看 Excel。BI 解决的是把数画成图，解决不了两个市场口径不一样——把两份不可比的数据画成漂亮的图，只是让不可比这件事更隐蔽了。企业花了钱，但没有解决核心问题。

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

Q3后来你使用 AI 解决这个问题的整体思路和关键步骤是什么？

我的解决思路分为三步。

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

我近距离观察了总部的销售运营团队，看他们日常怎么接收经销商数据、怎么核对、怎么开会沟通；也通过远程方式了解了经销商侧的数据填报流程。摸清全貌之后，我们开始明确：总部需要什么数据？经销商能够提供什么数据？哪些数据可以自动获取？哪些数据必须人工确认？

比如，Sell In 数据相对容易，因为它通常来自总部发货系统，结构比较标准；SellThrough 数据更难，因为它来自渠道末端，数据来源复杂。所以我们的重点是重新设计数据流转方式，从数据源头就把口径对齐。

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

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

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

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

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

整个流程从过去的“人工传递 → 人工整理 → 人工审核”，变成“AI 抽取 → AI 校验 → 风险标记 → 人工最终审核”。简单来说，就是把数据流转从“人为校验”变成“机器辅助校验 \+ 人工决策”。

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

最初我的设想是搭建一个专门的海外数据平台，让经销商数据直接接入新系统。但现场走了一圈后发现，企业总部已经有一套成熟的管理系统在跑，海外业务的员工和经销商都习惯了这套流程。推翻重建不现实，更好的方式是在原有系统上做能力叠加：保留现有的框架和习惯，AI 作为一层能力嵌入其中。另外我们没有一上来就铺大摊子。第一版只做中国、只做一条产品线，只回答一个问题：这条线的钱花得值不值。就这一条线端到端做完整：数据能进来、数字点得开、结论能进周会。跑通了，越南才接进来。

很多 AI 项目失败，是因为最后只是生成一个报告。但企业真正需要的是：销售人员能看到数据，总部能快速判断市场情况，管理人员能发现异常。AI 嵌入已有系统后，总部可以新增数据入口，经销商按照统一字段提交数据，AI 负责处理复杂数据，最终结果进入企业数据看板。数据打通后，业务的人可以用大白话直接问，比如“这个 SKU 为什么掉了”。但我们有一条硬约束：不是模型直接吐一个答案，而是模型帮你定位到那一行原始数据，每个数字都点得开、看得见来源。有些问题模型本来可以答得更漂亮，但溯不回去，我们就不让它答。

Q4相比传统方式，使用 AI 后的实际效果如何？

这个项目带来的价值，主要体现在三个方面。先说明一句，下面的数字做过脱敏，量级是对的，绝对值做了处理。

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

过去企业依靠人工审核市场费用，能够发现的问题比例不到 10%。引入 AI 辅助后，通过异常识别、历史数据对比和行业经验规则，可以发现约 30%左右的问题。虽然不是 100%自动判断，但对于企业来说，已经意味着减少了相当一部分不必要支出。

比如，系统会根据历史活动、区域情况、类似案例进行交叉比较，标记异常费用。最终仍由人工确认，但审核效率明显提高。

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

过去海外业务管理高度依赖个人经验。某个负责人熟悉市场，就能判断数据是否合理；

换一个人，判断能力可能下降。AI 介入之后，企业开始把这些经验沉淀下来：什么数据异常？什么费用合理？什么情况需要进一步审核？企业能力不再只存在于个人身上。最直观的变化是周会。以前的周会，前一个小时是在对数，这个数对不对、你那份和我这份为什么不一样。现在数已经在那儿了，会议直接从要不要动预算开始。提问方式也变了：以前他们说“给我一份报告”，现在直接问“这个 SKU 为什么掉了，是价格、铺货，还是渠道出了问题”。能问出这么具体的问题，说明他们开始信这套东西了。

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

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

Q5在部署 AI 过程中，是否遇到了新问题或挑战？你是怎么解决的？

AI 落地最大的挑战不在模型。我们自己的说法是：难点不在技术层，技术大概只占 20%。

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

很多人认为 AI 项目最难的是模型，但实际落地时，数据才是最棘手的环节。前面提到销售数据来源复杂、格式不一，真正进入开发阶段后，这个问题的难度会被放大：不同国家的数据习惯差异很大，很难用一套规则覆盖所有情况。此外，数据准确性也是落地的关键门槛。比如一张发票可能是 PDF，也可能是图片；可能清晰，也可能手写、折叠、

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

我们的解决方式是双层的。一方面先建立数据规范，再利用 AI 处理非结构化数据，现在视觉语言模型对于图片、票据等内容识别能力提升明显，很多过去需要专门训练的问题可以直接利用成熟模型完成。另一方面，我们建立了一套评估样本，收集正常案例、异常案例和边界案例，持续测试模型在真实场景下的表现。对于 FDE 来说，这套样本非常重要：只有知道模型在真实环境里的表现，才能放心交付。

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

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

我们的做法是分两步走。对总部团队，先让 AI 做辅助标记，保留人的最终决策权。每一处风险标记都附带依据（历史对比、区域参考、行业规则），让审核人员能看到判断逻辑，每个结论都有迹可循。当业务人员发现 AI 确实能帮他们发现之前漏掉的问题时，信任就自然建立起来了。对经销商，我们尽量降低填报门槛，能自动抽取的字段由 AI 完成，经销商只需要确认和补充。两边的磨合花了一段时间，但一旦跨过信任门槛，推进速度明显加快。

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

很多企业已有成熟系统，FDE 不能简单推倒重建。尤其海外企业，权限审批流程比较复杂。所以我们的方式通常是适配已有系统、增加接口、调整流程，避免推倒重建。

Q6根据你的经验，我们怎么才能更好地把 AI 部署到实际业务中？

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

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

很多企业第一反应是：“我们有什么模型？”“我们能不能做 Agent？”“我们能不能接入大模型？”但真正的问题应该是：业务哪里最痛？哪里最浪费时间？哪里过去依靠人工经验？

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

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

一个纯技术工程师，如果不了解行业，很难发现真正的问题。而一个懂业务的人，可以知道哪些数据重要、哪些流程可以优化、哪些结果企业真正关心。FDE 正是需要具备这种业务判断力，才能把技术能力用在真正产生价值的地方。

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

模型能力越来越强，通用能力越来越完善。未来企业之间竞争的重点，将逐渐从模型能力转向对业务的理解深度。FDE 需要关注：用户是否愿意使用？流程是否适配？成本是否接受？结果是否可靠？我们内部把交付固化成五步：诊断、数据审计、窄 MVP、嵌入、扩展。顺序不能乱，理解业务永远在技术选型前面，赢得信任之后才扩面。

模型是入场券。领域加交付，才是护城河。评判一个 FDE 项目，不看 demo 多炫，看客户有没有真的改变决策方式。

整理说明

本页由《DatawhaleFDE案例100》PDF（247 页）重新编排而成：按原书目录切分为 24 个案例；去除页脚页码，修复跨页与段内断行；原文中的配图位置以"图 N：……"图注保留，图片本身未收录。

依据整理要求，全部受访者及致谢名单中的姓名已统一替换为"某某人"；公司、职位与业务信息保留原文。正文为访谈实录，观点归属各案例受访者。

FDE 案例 100 文字整理版

摘要

要点

全文

前言

从师徒带教到 AI 辅助培训：FDE 用 AI 破解制造业经验传承难题

从人工审材料到自动化办件：FDE 用 AI 提升车管所网办效率

从案头工作到智能协作：FDE 用 AI 优化诉讼律师的案件处理能力

从人工研判到智能调度：FDE 用 AI 重构城市规划研判流程

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

从经验装车到智能规划：FDE 用 AI 优化跨境物流装载效率

从个人提效到组织能力：FDE 用 AI 推动企业研发转型

从物料难找到精准定位：FDE 用 AI 减少工业企业采购浪费

从“表哥表姐”到智能执行：FDE 用 AI 重构央国企财务流程效率

从人工核对到智能对账：FDE 用 AI 让线下零售对账又快又准

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

从人工盯图到公司级生产：FDE 用 AI 重塑鞋服电商素材工作流

从纸质流程到数据驱动：FDE 用 AI 推动传统消防维保企业数字化转型

从技术交付到业务自驱：FDE 用 AI 推动国企工作流程真正落地

从经验写稿到稳定量产：FDE 用 AI 重构本地生活短视频内容生产

从人工分析到分钟级洞察：FDE 用 AI 重构电信网络数据分析

从老师傅报价到 AI 深度协同：FDE 用 AI 重构非标制造售前链路

从纸质台账到 AI 经营：一家生物科技上市公司的 0 帧起手数智化

从人工排队到审核前置：FDE 用 AI 重构消费品研发协同与包装审核

从看不清订单到看清经营：FDE 用 AI 让制造企业的经营流程更透明

从人工绘图到智能协作：FDE 用 AI 重塑建筑图纸交付流程

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

从老板报价到长尾承接：FDE 用 AI 打通工程租赁获客与报价

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

整理说明

相关文章