很多企业现在已经不缺大模型了。
模型可以买，API 可以接，知识库产品也很多。真正麻烦的是后半段：怎么把模型放进客服、销售、研发、财务、法务、供应链这些真实流程里，让它稳定地产生结果，而不是停在演示页和试点项目里。
这个问题正在变得越来越明显。
BCG 在 2025 年的研究里提到，全球只有约 5% 的公司真正从 AI 中获得显著价值。另有 60% 的公司虽然投入不少，但还没有看到实质性的收入增长或成本下降。
麦肯锡 2025 年的 AI 调研也有类似结论。生成式 AI 要真正影响企业利润，关键在于工作流有没有被重构。但在使用生成式 AI 的组织里，只有 21% 表示已经从根本上重构了部分工作流。
这就是今天企业 AI 转型的尴尬：模型越来越强，但企业内部能把模型接进业务的人不够。FDE，Forward Deployed Engineer，前线部署工程师，就是为了解决这个问题出现的。
◆ FDE 到底是什么
OpenAI 对 FDE 的描述：FDE 要把 AI 放到复杂的真实生产环境里，不是先做一个通用产品再交给客户用，而是在企业现场构建定制化 AI 系统，并处理安全、权限、治理、合规、运营控制和遗留系统这些现实问题。
来源
https://openai.com/business/the-openai-deployment-company/
这和传统售前不一样。售前通常负责解释产品、做方案、做 Demo；咨询顾问更擅长路线图和方法论；系统集成商可以完成项目实施，但往往沿用传统软件项目的交付方式。
FDE 的工作更靠近现场。它要理解业务流程，也要能写代码、接系统、做评估、调模型、上线和迭代。
Anthropic 的 FDE 岗位描述里写得更具体些：这个角色要嵌入战略客户团队，帮助客户构建基于 Claude 的生产级 AI 应用，并交付 MCP servers、sub-Agents、agent skills 等可以进入生产流程的技术产物。
来源
https://job-boards.greenhouse.io/anthropic/jobs/5012991008
Cursor 的 FDE 岗位强调，这不是一个做 Demo 的角色。FDE 要发现真实瓶颈，定义指标，构建工作流，上线系统，并承担生产支持。
FDE 更像 AI 时代的“业务工程师”。它既不是纯业务顾问，也不是只接需求写代码的外包工程师。
◆ 企业 AI 为什么总卡在 PoC
企业 AI 项目常见的问题，是试点看起来不错，但很难进入生产。
业务部门说“提升客服效率”，这句话听起来清楚，落地时却要拆成一串工程问题：客户意图怎么识别，知识库怎么检索，答案怎么引用来源，工单怎么生成，权限怎么控制，错误怎么兜底，质检怎么做，日志怎么留。
业务语言和模型语言之间，需要有人翻译。
还有 Demo 和生产系统之间的距离。一个聊天框很容易做出来，但企业要的不是聊天框。企业要的是 AI 能进入 CRM、ERP、OA、数据库、知识库、审批流和权限系统。
OpenAI 在 Frontier Alliances 公告里提到，企业 AI 价值受限的地方不只是模型智能，还包括 Agent 如何在组织里被构建和运行。真正落地还需要领导层对齐、工作流重构、系统和数据集成、变革管理。
第三个问题是评估。很多企业说 AI 有用，但说不清到底节省了多少时间、减少了多少人工、提高了多少转化，或者降低了多少错误率。
麦肯锡的调研提到，跟踪清晰定义的生成式 AI KPI，与企业获得底线收益有关。但少于五分之一的受访组织表示，他们在跟踪生成式 AI 解决方案的 KPI。
还有一个更现实的问题：AI 应用不是一次性交付。
Prompt 会变，知识库会变，业务规则会变，用户习惯也会变。模型能力本身也在变。Databricks 的 AI FDE 岗位要求就包括构建 RAG、多 Agent、Text2SQL、微调等 GenAI 应用，并强调生产级部署、评估和优化。
传统项目制很难适应这种持续变化。FDE 的价值在这里就出来了：它不是交付完就撤，而是围绕真实业务效果持续调整。
◆ 为什么 AI 时代更需要 FDE
云计算时代，企业买的主要是基础设施。算力、存储、数据库、网络、安全，这些东西可以高度标准化。迁移当然不简单，但很多问题能通过产品、文档和最佳实践解决。
大模型不同。
同一个模型，放到客服、销售、研发、法务、财务里，做法完全不一样。每个场景都有自己的数据、权限、流程、风险和考核指标。AI 的通用能力，必须被重新包装成具体工作流。
Google Careers 上已经出现多个 GenAI 相关的 Forward Deployed Engineer / Architect 岗位。比如面向中国市场的 “Forward Deployed Architect, Generative AI, Google Cloud”，要求候选人能构建生产级方案，处理结构化和非结构化数据，使用向量数据库和 RAG 架构，并参与技术发现、数据主权、合规和模型治理。
这说明 FDE 处理的不是“调用一下模型 API”。它处理的是模型、数据、流程、安全和组织之间的连接问题。
OpenAI 在2026年5月宣布成立 OpenAI Deployment Company，也是在补这块能力。OpenAI 表示，这家公司会把 FDE 嵌入复杂问题和高要求环境中的组织，和业务领导、一线团队、运营团队一起寻找 AI 的影响点，重构关键工作流，并把收益转化为可持续系统。OpenAI 还提到，收购 Tomoro 后会带来约 150 名 Forward Deployed Engineers 和 Deployment Specialists，并以超过 40 亿美元初始投资启动。
这不是一个岗位热词。AI 大厂正在把它当成企业落地能力来建设。
◆ 国内也开始出现 FDE 模式
国内最明确的一手来源，是阿里云。
阿里云帮助中心已经有“FDE 大模型技术服务”页面。它把这项服务定义为“技术+业务”的深度落地服务：深入客户现场，主导 RAG、Agent 等大模型应用的 POC 验证、工程集成、效果调优，解决私有化部署和数据适配问题，并把业务痛点转化为技术方案。
来源
https://help.aliyun.com/zh/document_detail/3030376.html
阿里云列出的服务内容包括业务现状调研、方案设计、Demo 验证、API 集成、部署环境支持、模型微调、提示词调优、评测指标构建、问题排查和项目验收。
字节跳动也开始招聘“豆包AI大模型FDE（Forward Deployed Engineer）-火山方舟MaaS”岗位，职责包括面向行业头部客户理解业务场景、识别流程痛点、设计并实施 Agent 架构和 Workflow 工作流，弥合大模型 Demo 与实际业务价值之间的差距。
方向已经很清楚：国内企业 AI 落地，也在从“卖模型、卖平台、卖项目”，走向“进入现场、共同构建、持续优化”。
◆ 企业需要的不是一个岗位名称
对大多数企业来说，现在不一定要立刻招聘一个叫 FDE 的岗位。更现实的做法，是建立一套 FDE 型组织能力。
这套能力至少包括几件事。
要有人能进入业务现场。AI 场景不是开几次需求会就能定义出来的。很多真实流程藏在一线员工的日常操作里：哪些步骤是系统规定，哪些是经验判断，哪些看起来低效但其实承担风控作用。FDE 要能看见这些细节。
要有人能把模型接进系统。光懂业务不够，光懂模型也不够。Cursor、Anthropic、Databricks、Google 的 FDE 岗位都把生产级工程能力写进了要求里，包括工作流构建、系统集成、RAG、Agent、评估和部署。
还要有评估机制。阿里云 FDE 服务里明确写到，需要构建评测指标，量化模型在客户场景下的准确率、召回率或业务价值达成度。没有评估，AI 项目很容易变成主观感受：有人觉得好用，有人觉得不好用，最后谁也说不清它到底有没有产生价值。
最后是把以上模式沉淀下来。OpenAI 提到，FDE 团队会从真实客户问题中识别可重复模式，并把这些模式演化为产品能力。
这点决定了 FDE 不是“高级定制开发”。好的 FDE 项目，应该越做越能复用。
◆ 企业可以怎么开始
最小可行的方式，不是先成立一个很大的 AI 中台，而是围绕一个高价值场景组一个小队。
这个小队里，至少要有业务负责人、AI 产品或 FDE Lead、应用工程师、数据或集成工程师、IT/安全负责人，以及一组真实的一线用户。
先别追求全公司铺开。选一个流程，最好是高频、高成本、结果可衡量的流程。比如客服工单处理、销售线索整理、研发代码审查、合同审核、财务报销初审、内部知识检索。
进入现场，看真实流程。 做原型，用真实数据验证。 定义指标，看是否真的节省时间或提高质量。 接入系统，小范围上线。 收集失败样本，继续调整。
OpenAI Deployment Company 的描述也是类似路径：先诊断 AI 能创造最大价值的位置，再选择少量优先工作流，由 FDE 在组织内部设计、构建、测试和部署生产系统，把模型连接到客户的数据、工具、控制和业务流程中。
这比“全员上 AI 工具”慢一点，但更接近真实转型。
◆ 结语
企业 AI 转型最难的地方，不是找到一个更强的模型，而是让模型进入具体业务。
这件事需要懂业务的人，也需要懂工程的人。还需要有人愿意待在现场，把那些看起来琐碎、混乱、难标准化的流程一点点拆开，再重新接起来。
FDE 模式的价值，就在这里。
说白了，FDE 做的是一件很具体的事：把模型能力变成业务结果。对企业来说，这可能正是从 AI 试点走向 AI 生产最缺的一环。
