FDE 到底是什么：别把它理解成高级驻场

FDE 最容易被误解成“高级驻场”。尤其在中文企业软件语境里，只要听到工程师去客户现场，很多人马上会想到外包、实施、人天、定制开发。这种联想有历史原因，但如果用它理解 FDE，很容易学偏。

真正的 FDE，不是换了名字的驻场。

售前和 FDE 不一样。售前的主要任务是赢单，核心作品通常是方案、演示、报价和客户信心。售前要让客户相信这件事能成。FDE 的主要任务是赢结果，核心作品应该是跑在真实环境里的系统。FDE 要让事情真的成。

外包和 FDE 也不一样。外包通常按人力交付，客户要什么做什么，边界由需求和工时决定。FDE 不能只是客户需求的执行者，它要先判断客户提出的是不是正确问题。如果客户一上来要一个很大的 AI 平台，但数据基础和组织条件都不成熟，FDE 应该把问题切小，甚至劝客户先别做。

咨询和 FDE 也不一样。咨询擅长诊断、分析、建议和路线图，但很多咨询项目不直接对系统运行负责。FDE 不能停在建议，它要进入部署、调试、评估、迭代和使用。它交付的不应该只是“应该怎么做”，而是“已经跑起来并证明有价值”。

普通产品工程师和 FDE 也不一样。产品工程师面对的是抽象用户、通用需求和产品路线图。FDE 面对的是一个具体客户、一个具体部门、一条具体流程、一组真实数据，以及一堆没有写进文档的现实约束。它既要解决眼前客户的问题，也要判断哪些经验值得回流为产品能力。

所以 FDE 的关键词不是驻场，而是结果、现场、复用。

结果，意味着它不能只对功能负责。客户真正买的不是功能清单，而是效率提升、风险下降、收入增长、成本降低、流程变快。现场，意味着它不能只靠二手需求判断。很多真实信息只存在于现场使用、真实数据和组织习惯里。复用，意味着它不能每个客户从零定制。每一次交付都应该让下一次更容易。

判断一个团队是不是真的在做 FDE，不要看它有没有人坐在客户办公室，而要看三个问题：它是否对业务结果负责？它是否从真实现场发现问题？它是否把交付经验沉淀成可复用资产？

如果这三件事不成立，FDE 只是一个好听的新包装。

对中国团队来说，最实用的判断标准是看收费和交付边界。如果你卖的是工程师驻场时间，客户临时提什么就做什么，项目结束后没有可复用资产，那就更接近外包。如果你卖的是某个阶段结果，比如两周内完成一个真实流程的最小可行部署，并把过程中形成的连接器、评估集、流程模板沉淀下来，那才更接近 FDE。

还有一个判断标准是汇报对象。真正的 FDE 不应该只向销售目标负责，也不应该只向项目经理负责。它至少要和产品、工程、客户成功有强连接。因为它既要交付客户结果，也要把现场信号带回产品团队。如果一个“FDE 团队”只被当成售前资源池或交付人力池，它很快会被组织机制拉回旧模式。

所以讨论 FDE，不要先问“这个岗位叫什么”，而要问“这家公司如何处理现场学习”。现场学习如果能回到产品，FDE 就是护城河；现场学习如果只消耗在人天里，FDE 就只是成本中心。

这一篇最好专门给出一张对照表：售前看签约，FDE 看结果；外包看工时，FDE 看复用；咨询看方案，FDE 看系统；产品工程师看通用需求，FDE 看具体现场。读者一眼就能明白，FDE 的价值不在“更高级”，而在职责边界不同。

真正要问的是：这个人有没有权力拒绝错误需求？有没有能力直接改系统？有没有责任追踪业务指标？有没有机制把现场经验带回产品？四个问题都回答是，才算接近 FDE。