FDE 是什么？为什么 AI 项目的胜负不在模型

FDE 和普通工程师、售前顾问的区别

差别不在技能，在位置和责任：FDE 对「业务结果」负责，而不是对「功能开发完成」负责。

企业 AI 项目失败的四种方式

• 场景太大：从全公司整体规划起步，半年出不了结果，全员失去信心。
• 数据没准备：项目开始了才开始找数据、对口径，工期全耗在找数上。
• 没人对结果负责：内部没有明确的业务对接人，供应商按功能交付，用不起来也算完成。
• 交付即结束：系统上线后无人复盘调优，模型与口径慢慢失准。

这四种失败的共同点：不是模型不够强，而是没有人在客户现场，把技术和真实流程接起来。这正是 FDE 角色存在的原因。

FDE 的工作方式

业务与交付两人一组全程驻场：第一周完成业务访谈与数据摸底，锁定一个够重要、能验收、范围可控的场景；两到四周完成部署；验收指标双方事先确认，实测达标才算交付。同一组人从调研做到验收，中途不换人，验收之后继续复盘调优。

我们把这套方法写成了一本书：《FDE：AI 的胜负不在模型》。

我们组的 FDE 双人小组怎么分工

业务侧（ECHO）：驻场做流程诊断、把业务语言翻译成可实现的口径、对验收标准与客户对齐。交付侧（DELTA）：数据接入、应用部署与调优，对技术实现负责。两人全程在场——业务侧不会「调研完就走」，交付侧不会「开发完才出现」，所有交接成本都被内部消化。

一个 FDE 项目的时间线

以我们常见的节奏为例（不同项目会有出入）：

• 第 1 周：业务访谈与数据摸底。弄清流程现状、系统里有什么数据、口径是否一致。
• 第 2 周：方案锁定与口径确认。场景、验收指标、数据对应关系，双方书面确认。
• 第 3-4 周：驻场部署与联调。系统接上、跑通真实数据，开始试运行。
• 验收周：按事先约定的指标实测，达标交付，不达标继续调。

周期看着不长，是因为功夫花在了前两周：场景选得小而准，后面才快得起来。

以报价场景为例，FDE 的四周是怎么过的

第一周：访谈发现报价卡在内勤翻 Excel——价格版本对不上是主要返工点。第二周：与财务和销售确认价格与账期的计算口径，写成交付文档。第三周：接入 ERP 数据，部署按规则自动算价的报价能力，开始试运行。第四周：销售在真实询盘上使用，按事先确认的指标验收。

四周里没有一周在「演示概念」，每一周都在客户的真实数据上推进。

FDE 团队走之后，系统谁管

验收合格不等于甩手。标准的做法是三步交接：交付文档（口径、规则、部署结构）全部移交客户指定的 IT 对接人；运维清单写明哪些要定期看、异常了找谁；之后进入售后支持期，季度复盘一次——模型会漂移，规则会过时，复盘是为了持续有效。

选服务商时可以直接拿这一条去问：验收之后谁负责、支持期多长、怎么收费。答不清楚的，慎选。

常见问题