为什么企业 AI 必须深入业务定制？FDE 正在改变企业智能化落地方式

人工智能模型的能力正在快速进步。模型能够理解复杂指令、分析资料、生成内容、编写代码，也能够通过 Agent 调用工具完成多步骤任务。企业因此投入大量资源开展 AI 试点，希望把这些能力转化为效率提升、成本优化和业务增长。

但在真正进入业务现场之后，许多企业会发现：模型能够完成演示，不代表它已经能够稳定完成工作；AI 能够回答问题，也不代表它已经融入企业的业务流程。

我们可以把这段距离称为 Deployment Gap（部署鸿沟）：模型在测试环境中表现出的能力，与员工在真实工作中能够稳定使用并产生结果的能力之间，仍然存在差距。

真实企业环境远比演示环境复杂。业务资料分散在不同系统和团队中；同一流程存在例外情况；数据定义可能不一致；操作权限和审批规则各不相同；用户还需要在日常工作中理解、信任并采用新系统。

因此，模型能力要变成业务价值，至少还需要解决六类问题：业务上下文、数据质量、系统集成、工作流设计、生产可靠性，以及组织采用与责任治理。

通用 AI 工具适合知识问答、内容生成、资料总结和个人效率提升。对于边界清晰、风险较低的任务，标准化产品往往已经足够。企业不应该为了定制而定制。

但当 AI 需要参与核心业务流程时，通用工具可能不了解企业内部的产品定义和业务规则，无法访问关键系统，无法处理特殊审批，也无法满足行业特定的质量、安全和审计要求。

这并不意味着所有企业都必须开发专属 AI 平台。正确做法是优先复用成熟模型、标准产品和通用能力；只有当真实业务需求、系统环境或可靠性要求无法由标准方案满足时，再开展有明确边界的定制工程。

FDE 是 Forward Deployed Engineering 的缩写，中文统一称为“前沿部署工程”。它强调工程人员与客户业务团队紧密协作，深入真实工作场景，理解问题和约束，设计并构建解决方案，再通过实际使用和生产环境验证其价值。

FDE 不是把开发人员简单派驻客户现场，也不是传统外包项目换了一个名称。它是一种以业务结果为起点、以工程实现为核心、以真实部署和持续迭代为路径的协作模式。

OpenAI 在 2026 年 10 月 22 日发布的 FDE 说明中，将其工作目标描述为弥合“部署鸿沟”：模型能力进步很快，但把能力转化为人们能够可靠用于工作的系统和流程，需要深入客户问题、与客户共同构建，并将有效做法变成可复用能力。

OpenAI 的企业 FDE 介绍也强调，FDE 与客户团队共同观察工作流程、定义业务结果、连接系统与上下文、在生产环境验证，再把有效方案沉淀为可复用能力。

FDE 与传统定制开发、系统集成和咨询服务存在交集，但重点不同。传统项目通常围绕预先定义的需求和功能清单开展交付；FDE 更强调先理解业务目标和真实工作方式，再与客户共同探索 AI 在具体场景中能够可靠完成什么。

FDE 不意味着所有工作都必须从零开发。成熟模型、通用组件、已有 Agent、标准连接器和可复用工作流应尽量复用。工程团队真正需要定制的，是企业独有的业务上下文、系统连接、工作流程、评估标准和治理机制。

FDE 的交付过程不应从“客户想要一个 AI 系统”开始，而应从“客户希望改善什么业务结果”开始。一个可执行的过程可以分为七个阶段。

1. 发现业务现场 — 与管理者、业务专家和实际使用者共同梳理流程，观察系统、资料、任务交接和例外情况，找到真正影响效率或质量的环节。

2. 定义业务结果 — 确定目标指标、现状基线、适用范围、成功标准和项目边界。例如处理时间、质量、吞吐量、人工工作量或客户体验。

3. 构建关键原型 — 选择最有价值的关键路径，利用现有模型和组件快速构建原型，让真实用户尽早参与测试。

4. 连接数据与系统 — 接入必要的企业知识、业务数据库、CRM、ERP、内容平台或其他系统，同时建立身份、权限和数据访问规则。

5. 真实任务验证 — 使用代表性任务和困难案例测试准确性、稳定性、成本、延迟、异常处理和人工审核机制。

6. 生产部署 — 完成环境部署、监控、日志、权限、预算、运行责任和用户培训，使方案进入真实业务。

7. 知识转移与规模化 — 交付文档、配置、评估集、操作手册和维护能力，将验证成功的流程沉淀为可复用模块，并支持客户团队独立运营。

这七个阶段不是僵硬的瀑布流程。真实项目会在原型、集成和验证之间反复迭代。关键是每次迭代都要回到业务结果和真实用户反馈，而不是只追求技术演示效果。

企业 AI 定制工程通常需要多个技术层共同工作。模型只是其中一层，不能替代业务知识、系统集成、工作流、运行环境和治理。

• 模型与多模态能力 — 根据任务选择语言、推理、图像、语音或其他模型能力。

• 企业知识与上下文 — 通过 RAG、结构化数据和业务规则，让系统理解企业产品、客户、流程和历史经验。

• Agent 与 Skill — 将专业职责和经过验证的工作方法封装成可复用能力。

• Tools & Connectors — 连接 CRM、ERP、数据库、文件、营销平台和企业内部系统。

• Workflow & Orchestration — 管理任务顺序、条件、Agent 协作、审批、交接和异常分支。

• Harness & Runtime — 管理任务状态、工具执行、超时、重试、预算、暂停恢复和运行追踪。

• Governance & Evaluation — 建立权限、安全、审计、质量评估、成本监控和人工接管机制。

FDE 的工程价值，是根据客户业务把这些能力组合成一套完整系统。既要尽量复用成熟能力，也要对企业独有的业务逻辑进行必要的工程适配。

深入客户业务意味着会接触企业数据、流程、系统权限和核心经营知识。因此，FDE 不能只关注“能否做出来”，还必须从项目开始明确谁拥有成果、谁负责运营，以及合作结束后客户是否能够独立维护。

Gartner 在 2026 年 9 月 29 日发布的预测指出，到 2028 年，70% 的企业将放弃由供应商 FDE 模式构建的 Agentic AI，原因包括成本上升以及企业无法自行演进系统。这个预测针对企业放弃由供应商 FDE 构建的 Agentic AI 的情况，并不代表所有 FDE 项目都会失败。它提醒行业：项目结构和长期所有权设计与技术实现同样重要。

Gartner 特别强调，FDE 合作应明确治理、业务价值、知识产权归属、项目共同所有、知识转移和退出策略。

• 业务目标与范围 — 定义要解决的问题、指标、交付范围和变更流程。

• 数据与访问权 — 明确数据控制者、处理目的、访问范围、保存期限和安全责任。

• 知识产权与代码 — 明确既有平台能力、客户专属成果、第三方组件、模型服务和新开发代码的权属与许可。

• 共同交付与责任 — 明确客户业务负责人、技术负责人、FDE 团队和运营负责人的决策边界。

• 知识转移 — 交付架构文档、配置、评估集、运行手册和培训。

• 退出与独立运营 — 明确供应商退出、系统迁移、凭据交接和客户独立维护路径。

一个成熟的 FDE 项目，不应该让客户永远依赖最初的工程团队。成功的标志之一，是客户逐渐具备自己维护、扩展和管理系统的能力。

FDE 不是所有 AI 项目的默认交付方式。它更适合业务价值高、工作流程复杂、系统环境独特、需要多轮验证或现有标准产品无法可靠满足的场景。

判断是否需要 FDE，最简单的标准是：如果现有产品和模型已经能够可靠完成任务，就优先使用现有能力；如果关键障碍来自业务上下文、系统集成、流程重构、生产可靠性或组织采用，再考虑深入工程部署。

在 AIEASE，我们将 FDE 定位为企业 AI 定制开发与工程落地服务，而不是单纯的软件外包。它连接 AIEASE 的共享技术底座、数据智能、商业构建和企业实际业务。

• DI — Data Intelligence — 帮助识别市场机会、业务数据、证据来源和企业经营问题，为项目发现和需求分析提供数据基础。

• VENTURE — AI Venture Building — 当企业需要构建新业务或新产品时，协助完成机会研究、商业模式、产品规划和 MVP 路线。

• BASE — AI Capability Layer — 提供 Agent、模型、RAG、Workflow、Skill、Tools、Harness 和治理等共享 AI 能力。

• FDE — Business-specific Engineering — 深入客户业务流程，完成需求发现、系统集成、专属 Agent、业务工作流、评估、部署和现场验证。

• MANAGE — Long-term Operations — 通过持续运营、运行监控、成本管理、数据反馈和迭代优化，让系统长期创造价值。

这套方式既避免每个项目重复建设基础 AI 能力，也不会用一套通用产品强行覆盖所有企业的独特业务。通用能力尽量复用，企业差异化部分深入定制。

未来企业不会缺少 AI 模型和工具。真正稀缺的，是能够把 AI 能力转化为稳定业务流程的工程能力。

FDE 让工程团队走进业务现场，与企业员工共同理解问题、设计流程、构建系统、验证结果，并将有效实践沉淀为长期能力。

它要求技术团队理解业务，也要求企业愿意开放必要的业务上下文、安排领域专家参与，并明确项目目标、责任和所有权。

对企业而言，最重要的不是追逐一个看起来先进的 AI 系统，而是找到真正值得改变的业务流程，并通过可验证、可维护、可扩展的工程方式完成转型。

FDE 不应成为企业对外部工程团队的永久依赖，而应成为企业建立自身 AI 能力、加速业务转型和持续创新的起点。