为什么中国企业AI落地更需要FDE？

对今天的中国企业来说，模型似乎已不是AI落地中最明显的瓶颈。

7月14日，月之暗面发布总参数2.8万亿的Kimi K3；几天后，阿里千问预览总参数2.4万亿的Qwen3.8-Max-Preview。不到一周，两款总参数超过2万亿的国产模型相继出现，企业能够调用的技术能力又向前走了一截。

模型固然决定着AI能力的上限。

但是，当模型供给在短时间内变得如此丰富，企业需要作出的决定实际上并没有随之减少，反而很快从“选哪个模型”延伸到一连串更具体的问题：模型的能力边界又突破到了哪里，业务上下文数据在哪套系统里，哪些人有权调用，模型出错以后由谁接管，生成结果能不能直接进入业务，以及业务人员是否要改变已经沿用了多年的工作方式等等。

我们经常说AI赋能千行百业，但是千行百业参差多态，具体负责AI落地的人，往往最先想听到的还是一个最佳实践：有没有同行已经做过，用了什么模型，最后效果怎么样。

最佳实践可以证明一个方向值得尝试，却很难把另一家企业的数据、权限和工作流程一起复制过来。当这些条件还没有理清，最容易被复制的往往只是产品的样子。于是，过去两年，企业里最容易完成的AI项目，往往还是一个Demo。找一批资料接入知识库，再给大模型做一个自然语言入口，几个星期便能让系统回答问题。

Demo和真实环境的差距显然是巨大的。

上线当天看起来什么都能做，过了一段时间却没有人继续使用，也不再产生模型调用。月抛型、周抛型，甚至日抛型Agent非常多见。

面对这种落差，人们很容易把原因归结为大型企业行动太慢。可在过去几十年的企业IT建设中，“慢”原本就是一种合理常态，而且很多时候，它也是大型组织控制风险的办法。在国内，央国企行事尤其秉承这个思路。

在WAIC 2025世界人工智能大会期间，国资委发布了首批40项央企人工智能战略性高价值场景，有一个很有意思的提法，叫推动“盆景式”试点落地到“雨林式”规模应用。所以，有什么“快捷方式”能实现这个跳跃？一家企业既要寻找AI的目的地，又要把系统建设到生产环境，谁来承担中间那段过去很少有人完整负责的工作？

今年WAIC 2026，就这个问题，我们和多家科技企业的负责人，包括阿里云智能集团副总裁霍嘉等做了一些交流。一个可以从中得出的结论是，大家正逐渐将答案聚焦于一个此前相对陌生，却已存在许久的岗位——FDE。

FDE走上前台

Forward Deployed Engineer，国内通常译作前沿部署工程师或者前线部署工程师，简称FDE。这个名字并不是大模型出现以后才有。

十多年前，Palantir已经用它称呼一批深入客户现场的解决方案和集成工程师。他们一头连接客户正在处理的问题，一头连接公司的平台研发。

到了大模型时代，FDE重新变得显眼。以几个AI实验室为例：OpenAI对这个岗位的职责描述，已经从业务发现、项目界定和系统设计，一直延伸到开发、生产上线与采用效果。2026年5月，它又成立Deployment Company，把工程师进入复杂组织、与客户共同改造关键工作流程，做成一条正式业务线。Anthropic等模型公司也在多个地区设置了相近岗位。

FDE的回潮首先是一种全球现象，但国内AI落地似乎更需要FDE。

我们常说中国拥有丰富的AI应用场景。场景丰富当然是一种优势，但换到落地一侧，它也意味着很难用一套标准答案解决所有问题。

中国既有高度数字化的大型企业，也有大量仍在补基础课的公司；即使在同一家集团内部，新建的数据平台、运行多年的业务软件、不同厂商提供的系统和分散在各部门的数据，也可能同时存在。AI进入这样的企业，并不会绕过过去留下的系统关系，而会在读取数据、调用权限和改变流程时逐项遇到它们。

即使企业内部数据在物理层面统一了，数据本身还有责任边界的问题。

金融、能源、交通、医疗和大型工业企业处理的信息，往往涉及个人信息或者重要生产数据。模型能够看见什么，数据是否可以离开本地环境，生成结果由谁审核，系统怎样留痕和回退，都要在项目里落实。

最后大语言模型为代表的现代AI看起来使用简单，但背后的技术原理和实现工程复杂无比。霍嘉讲了一个体感，现实中甚至能将Transformer架构说清楚的人，占比也并不高。知其然，不知其所以然，如何能做好AI落地？

FDE的意义很大程度上就在这里。

它不只是增加一类工程师编制，而是让懂AI架构和能力边界的人提前进入场景，与掌握业务、数据和生产责任的人共同工作。

售前占比变大，项目总时间反而缩短

从阿里云得到的实践反馈，FDE的介入，确实缩短了项目周期，也提高了客户的获得感。

因为项目售前（项目论证）占比变长了，但从想法到上线的总时间反而缩短了。

这里用了两把尺子。

一把量的是项目里的时间怎样分配，另一把量的是整个项目究竟持续多久。

如果用一个近似的20%和80%来描述，传统企业项目通常先用20%左右的时间确认需求、设计方案和签订SOW，剩下的大部分时间才用于开发、集成、测试、部署和验收。这样的安排延续了确定性工程的思路：售前阶段尽快固定范围，合同签完以后，建设团队沿着已经画好的路线向前走。

AI项目里的比例正在反过来。

正式建设之前，FDE等团队要进入业务现场筛选场景，检查数据和权限，做出MVP（最小可行产品/方案），让实际使用者跑一遍，再判断技术路径是否成立、投入产出是否合理。一个场景没有价值，或者数据条件根本不支持，就应该在这个阶段停下来；方向在真实环境里跑通之后，开发、部署和上线才有可能迅速展开。

于是，在一个已经缩短的项目周期里，大约80%的时间可能被用来找对方向，剩下20%才用于方向明确后的建设。

这并不是把原来半年或一年中的80%原样搬到售前。传统流程里，一个错误假设可能直到开发、集成甚至验收时才被推翻，需求再沿着组织层级返回，前面的投入跟着变成返工。而FDE先用一两周的小规模试验，让最容易失败的判断在真实数据和流程中暴露出来。

总时间也就被压缩了。

只把验证提前，还不足以得到这种速度。MVP做完以后，如果需求仍然要依次交给销售、解决方案架构师、产品经理、开发和交付团队，试验中刚刚获得的理解，还会在一次次转述中损失。

阿里云的FDE实践是把客户侧的业务、数据和IT人员，与厂商侧的产品、算法和工程人员组成One Team。重点不在于大家是不是坐进了同一间办公室，而是能够作出不同判断的人进入了同一个工作现场。

上世纪七十年代，MIT学者Thomas Allen研究研发组织中的沟通网络，发现物理位置会显著影响技术交流；他后来把那些连接组织与外部技术世界的人称为“gatekeeper”。阿里云的FDE就成了这个AI时代的“gatekeeper”。

如果说前面的变化压缩了项目时间，这里被缩短的就是组织空间。

模型训练和推理中，通信开销是新的瓶颈， AI落地的组织协同也是如此。

两个项目，检验FDE的三种能力

谈完FDE的前世今生，接下来我们通过三个阿里云的案例，感受一下FDE的成效。

第一个是央视体育客户端的世界杯“AI观赛助手”。

世界杯有一个不会等待项目流程的时间表，比赛持续发生，赛程、球员和比分随时变化，用户提问的时间又可能与数据更新时间错开。系统既要及时回答，也要以官方信源为依据，避免大模型编造内容。阿里云团队用一周左右把应用推入生产环境，让真实用户和实时数据尽早进入验证。

一周上线当然很快，但快并不是这个案例的全部意义。传统项目喜欢在交付以前尽量消除不确定性，这个项目则把真实使用本身变成了验证的一部分。系统先进入比赛，再根据现场问题，在结果可控的情况下不断优化调整。

第二个项目来自中石油昆仑数智。

常减压装置是炼化生产的第一道工序，后续环节建立在它稳定运行的基础上。AI应用进入这类系统，面对的不只是一次回答是否准确，还要考虑连续运行、异常处置以及与原有系统的协同。据阿里云转述客户反馈，这是其系统内第一个在生产系统中24小时运行的AI应用。到了这里，FDE要证明的已经不再是模型能不能回答，而是AI能不能留在核心业务里。

第三个来自于北京大学国际医院。

FDE团队仅用3周即完成7大患者服务场景的AI Agent全链路交付——从架构设计、24个业务系统接口联调到微信小程序"小安"AI健康管家灰度上线，意图理解与召回准确率均达90%，让150万患者实现7×24小时"挂号-导诊-报告解读-随访"一站式智能服务。验证了"小切口快速落地、标准化方案跨院复制"的MaaS交付模式，为医疗AI患者服务从单点试点走向规模化普惠提供了可参照的落地样本。

三个项目当然不是一条所有企业都能照搬的标准路线。它们却呈现出高价值场景的一些共同信号：AI应用能够Always On，使用过程持续产生新的高质量数据，基础模型升级以后，业务效果还能继续获益。

中国FDE，更需要科技大厂牵头

在调研中，我们发现任何接触FDE概念的人，开始都会产生一个疑问。

如果岗位的责任已经改变，支撑这些人的合同却仍然大多按照项目、人天和交付物计算。一支由资深工程师组成的FDE团队成本不低，如果每个客户都需要从头投入相同的人力，这种方法越成功，厂商背负的交付压力反而越大。

所以，如何让FDE成为一门可持续的生意？

这里至少有三本账要同时算得过来。

客户先要从应用中得到可以观察的价值：节省了多少时间，增加了多少收入，降低了多少风险。上线、验收和准确率只是中间指标，持续使用与业务结果才会决定下一年是否续约。

客户持续使用以后，厂商才可能获得模型调用、算力供给、数据平台和运维服务带来的长期收入，让FDE不必完全依靠一次性项目费存活。

与此同时，FDE在现场积累的经验、在授权与合规边界内形成的数据反馈，以及行业know-how，还要反哺模型、Agent平台和相关云产品。产品因现场实践变得更好，又可以服务更多客户和行业，FDE创造的效益便不再停留在单个项目里，后续项目的交付也有机会变得更轻。

客户价值、厂商收入和产品复用，少了任何一项，FDE都很难从一批成功项目变成可持续的产业机制。

付费方式也可能随之变化。眼下常见的仍是一次一单，双方在合同里写清需求、周期和交付物。可当一个新场景用一两周便能判断是否值得继续，重新立项、招标、报价和验收所花的时间，可能比试验本身还长。

因此，按年签订持续服务合同，可能会比一次次购买项目更适合FDE：客户购买的是一支在约定边界内不断发现、验证和上线高价值场景的团队，一个方向失败以后，可以把资源转向下一个。

再往前一步，理想状态是按结果付费，即现在讨论很多的Result as a Service。客户购买的不再是工程师投入了多少人天，也不只是交付了几个智能体，而是周转时间缩短、故障率下降、收入增加或者风险减少。

但这一步显然还需要更成熟的条件。企业要有可以比较的业务基线，双方也要分清哪些结果来自模型，哪些来自流程调整、数据质量和组织配合；厂商能够控制多大范围，才可能为多大范围的结果负责。安全责任、极端事件和长期收益如何定价，也需要更多案例数据。

项目费用、长期服务合同和结果付费，更像逐步演进的三种关系，不会在所有企业中同时完成切换。

也正因为这套循环要求前线经验能够迅速回到模型、Agent平台和产品研发，中国FDE的落地，科技大厂可能是更合适的牵头者。

Palantir把这套机制称为 “人类反向传播”。FDE不是为每个客户永远手工解决问题，而是要把反复出现的问题带回研发体系。第一个项目里需要工程师处理的缺口，如果在第二个项目里变成平台的标准功能，现场服务才可能越来越轻。

一个企业提出的要求可能只是定制，多个行业反复遇到的权限、评测、高可用和数据治理问题，才值得被做成标准能力。平台公司既可以跨客户观察这种重复，也拥有把它送进产品路线图的研发资源。如果前线只能按照既定范围实施，却无法影响产品，它所做的工作更接近高级交付。

企业AI的生产问题又很少停留在单一层面。一次响应缓慢，背后可能是模型推理、算力调度或者数据库的问题；一个Agent无法进入流程，也可能牵涉数据治理、安全权限和生产运维。FDE不必亲自解决每一层问题，但要在组织内找到相应的产品团队。

拿阿里云来说：它拥有从基础设施、模型服务、AI开发平台到数据库、安全和运维的产品体系，现场问题因此有了比较完整的回流路径。全栈的意义并不是向客户方案里塞入更多产品，而是跨层问题能够找到责任人，也有机会沉淀进模型、Agent平台和云产品，在下一个项目中不再重新解决。

应用真正运行以后，还会持续产生模型调用、Token、算力、数据库和平台服务的需求。云厂商可以用工程服务推动采用，再从持续使用中获得回报，也就不必完全依靠出售工程师人天覆盖成本。

翻看工业革命史、经济史里有一段与今天的AI落地颇为相似。

19世纪末，工厂开始使用电动机，很多厂主最初只是把蒸汽机换成电机，厂房里的皮带、传动轴和机器布局却原封不动。

经济学家保罗·戴维研究电气化历史时指出，更大的生产率提升是后来才出现的：每台机器拥有自己的小电机以后，工厂不再必须围绕中央传动轴布置，机器位置、物料运输和生产流程都可以重新安排。

真正的生产力释放不在模型发布那一天，而在AI按照业务逻辑重新排列工作流程的那一刻——FDE正是推动这个重新排列的人。

直通车game推荐阅读
OKX下载	交易所排行	比特币平台下载