有人说FDE和之前的东软,用友驻场开发一样,说还是没法落地,复用,不是一个好生意。说FDE会非常短命,原因1,随着AI越来越强,可能未来AI可以自己解决了不需要FDE这一个中间层;原因2,未来每一个职业都渗透AI了,所谓的AI专家都会失去稀缺性;所以他们说未来FDE可能不会长久,但是定义值钱问题,知道行业knowhow,AI实现能力才是核心竞争力,你认可这个说法吗,详细谈谈课代表的理解

提问

AI根据立正公开的文章和视频整理,不是他本人回复

这个说法把FDE等同于传统驻场外包,忽略了FDE的核心是承担业务结果、反哺产品平台;AI越强,把能力落到真实业务的价值反而越高,但FDE本身会向领域专家演化。

FDE和传统驻场外包的关键差别在结果归属

传统驻场开发通常按人力或工时交付,做完一个项目就结束,经验留在个人身上,很难沉淀成产品。FDE被强调的地方在于:他要对最终业务结果负责,同时把现场问题反哺回产品平台,让简单场景逐渐被模板和资产覆盖,自己则转向更难的领域问题⁠1,2。所以判断FDE是不是好生意,不能只看“人在客户现场”这个形式,而要看这个人做的事有没有变成平台能力。如果一家公司只是把FDE当高级售前或客服,反馈链条变长、判断失真,那确实会退回外包模式⁠3。

AI变强不会消灭中间层,而是抬高落地门槛

模型能力越强,企业越需要一个能上线、符合SOP、控制风险、持续优化的系统,这段距离不会自动消失⁠1。传统行业尤其缺少能把AI用起来的人,FDE做的正是把不确定性变成确定性⁠2。放射科医生的例子说明,AI在某个环节变强,不等于这个职业消失,反而可能因为供给减少而更值钱⁠4。但要注意,这段材料是多人访谈、说话人未逐段确认,不能当作立正本人的判断。

定义问题和行业knowhow确实是更持久的能力

AI推演

“定义值钱问题、懂行业knowhow、能实现”这个判断方向有材料支持:技术复杂度与价值是正交的,价值由市场定义,不是由技术难度决定⁠5。FDE的演化路径也是从做简单交付,转向成为payment、网络或RAG等领域的专家⁠2。但这里有个条件:如果一个人只停留在“会用AI工具”,那确实会随工具普及而失去稀缺性;真正难替代的是理解业务约束、建立信任、把复杂能力落到真实场景的能力⁠1。所以与其说FDE会短命,不如说FDE这个title会变,但“把AI落到业务里”这件事的价值会持续存在。

关于FDE的讨论多来自访谈和社区总结,说话人归属未逐段确认,不能全部算作立正本人的立场;材料也未提供FDE岗位的市场数据或长期跟踪结果。

回到5份原文

FDE和solution engineer、customer success的区别到底在哪?

追问

AI根据立正公开的文章和视频整理,不是他本人回复

FDE 与 solution engineer、customer success 的分界不在是否见客户,而在是否亲手改生产代码、并把现场问题带回产品。

FDE 是产品的一部分,solution engineer 是客服的一部分

材料里的观点

一个常被引用的区分标准是:FDE 必须自己能上手改 production 代码,而不是在客户那边搞完以后提一个 ticket,让家里的工程师改;只有能直接改生产代码的人才叫 FDE。客服的那一部分,叫 solution engineer⁠1。Snowflake 和 Databricks 增长快,和他们的 solution architect/solution engineer 工资跟 SWE 差不多高有关——这些人本身能做 SWE 的活,在客户现场不是“指导”,是 hands-on 直接把事干完⁠1。所以三者的差别更像一条光谱:customer success 关心客户是否用起来、是否续约;solution engineer 关心方案能不能讲清楚、能不能演示和落地指导;FDE 关心代码有没有真的改进去、问题有没有回到平台。

组织归属决定 FDE 会不会退化成驻场外包

材料里的观点

Cresta 把 FDE 放在 Product Engineering,而不是 Customer Success 或 Professional Services,FDE 的 peer 包括做 microservice、cognitive infra 的团队,都汇报给 VP Engineering⁠2。FDE 不只是把客户项目做完,还要回到产品里改 REST API、microservice、UI、CLI、doc;项目中发现平台 bug、gap、抽象不够、工具不好用,要把这些反馈带回产品⁠2。如果 FDE 只是做一次性定制,公司会越来越像咨询公司,项目多了就堆人,很难形成产品公司该有的复利⁠2。反过来,如果 FDE 挂在 Customer Success 下面,考核指标是客户满意度而不是平台复用,就更容易滑向驻场开发。

材料主要来自 Cresta 和 PuppyGraph 的具体组织实践,其他公司的岗位划分可能不同。

回到2份原文

solution engineer 和 FDE 在招聘画像上有什么不同?

追问

AI根据立正公开的文章和视频整理,不是他本人回复

核心差别在是否亲手改生产代码:FDE 是产品工程的一部分,solution engineer 更偏售前支持与客服式协助。

分界线是能不能自己改生产代码

材料里的观点

FDE 被要求自己能上手改 production 代码,而不是在客户现场发现问题后提 ticket 交给后方工程师。只有能直接改生产代码的人才算 FDE,所以 FDE 属于产品的一部分,而不是客服的一部分;客服那一部分才叫 solution engineer⁠1。这也解释了为什么 FDE 招聘不放心招 junior:需要三年以上工作经验、本身是很好的工程师,做过 founder、co-founder 或 consulting、customer facing 经历是加分项⁠2。

组织位置不同,决定了招人标准不同

在 Cresta,FDE 放在 Product Engineering,而不是 Customer Success 或 Professional Services,peer 包括做 microservice、cognitive infra 的团队,都汇报给 VP Engineering。FDE 不只是把客户项目做完,还要回到产品里改 REST API、microservice、UI、CLI、doc,把现场发现的平台 bug、gap、抽象不够带回产品⁠3。而 solution engineer 的定位更接近客服式支持:Snowflake、Databricks 的 solution architect / solution engineer 工资接近 SWE,是因为这些人本身能做 SWE 的活,在客户现场是 hands-on 把事干完,而不是只做指导⁠1。

材料里对 solution engineer 的招聘画像只有零散旁证,没有专门展开它的完整画像;FDE 的三年经验和 founder 背景来自多人未分轨字幕,说话人未逐段确认。

回到3份原文

FDE 和 customer success 的日常分工具体怎么划?

追问

AI根据立正公开的文章和视频整理,不是他本人回复

FDE 亲手改生产代码、把现场问题带回产品,属于产品工程;customer success 不碰代码,负责客户关系、采用与续约。

分界线是能不能自己改生产代码

材料里的观点

FDE 与 customer success 的日常差别,不在谁见客户多,而在遇到问题时怎么解决。FDE 必须自己上手改生产代码,而不是在客户现场记下需求、回头提一张工单让家里的工程师改;只有能直接改生产代码的人才算 FDE,它是产品的一部分,不是客服的一部分。客服那一侧对应的角色是 solution engineer,偏售前支持与协助。按这个标准,FDE 的日常是写代码、修平台 bug、补抽象不足,customer success 的日常是推动客户采用、维护关系、盯续约和满意度⁠1。

组织上 FDE 归工程,不归客户成功

材料里的观点

Cresta 把 FDE 放在 Product Engineering,而不是 Customer Success 或 Professional Services,FDE 的 peer 是做微服务、认知基础设施的团队,一起汇报给工程 VP。这个归属决定了日常:FDE 不只是把客户项目做完,还要回到产品里改 REST API、微服务、UI、命令行和文档;现场发现的平台 bug、能力缺口、抽象不够、工具不好用,都要带回产品。这样设计是为了避免公司变成咨询公司——客户要什么就做什么、项目多了就堆人。FDE 在客户现场先把项目做成,再把重复问题抽象成平台能力、模板和最佳实践,下一次类似场景就不用从零开始,FDE 也能去做更难的事⁠2。

材料主要讲 Cresta 和 PuppyGraph 这类公司的做法,不同公司对 customer success 的职责定义差别较大,具体分工还要看所在组织的岗位设置。

回到2份原文

但是每个企业的业务数据都不同,可以变成平台能力吗这点存疑;以及如果我想往FDE方向走,应该先补行业knowhow还是先补工程能力?

追问

AI根据立正公开的文章和视频整理,不是他本人回复

平台能力不是把每家的业务数据搬上来,而是把重复出现的定制问题抽象成模板和资产;往FDE走,先补工程能力更稳妥,因为行业knowhow可以在现场积累,而改生产代码的门槛不补就进不去。

平台能力来自抽象重复问题,不是搬走业务数据

业务数据各不相同,这一点不构成对平台化的否定。Cresta的做法是:FDE在客户现场先把项目做成,再把反复出现的问题抽象成平台能力、模板、资产和最佳实践,下一次类似场景就不用从零开始⁠1。判断能不能变成平台能力,看的不是数据是否一样,而是问题是否重复:如果每家客户都要从头定制、做完就走,公司会越来越像咨询公司,堆人而没有复利⁠1。反过来,简单用例被模板和资产覆盖后,FDE才能腾出手做更难的领域问题,比如支付、网络或RAG方向⁠2。所以“数据不同”只说明不能指望一套通用方案直接套用,不说明沉淀不出平台能力。

先补工程能力,行业knowhow在现场补

AI推演

FDE的硬门槛是自己能上手改生产代码,而不是提个ticket让后方工程师改;只有能改生产代码的人才是产品的一部分,而不是客服的一部分⁠3。这个门槛不补,行业knowhow再深也只能把问题传回公司,反馈链条变长、判断失真⁠3。行业knowhow则可以在真实系统、真实数据和真实业务约束里逐步积累,客户现场本身就是产品定义的一部分⁠3。所以如果工程能力还没到能独立改生产代码的程度,先补它更划算;如果你已经能改代码、缺的是某个行业的理解,顺序可以反过来。一个可试的做法:挑一个你熟悉的小业务场景,自己动手把AI能力接进去跑通,看卡住你的是写代码还是不懂业务,这个反馈比空想更能定顺序。

材料没有给出“先补哪块”的统一答案,顺序取决于你现有工程能力与目标行业的差距;相关判断来自对Cresta和PuppyGraph的访谈转述,不是针对个人情况的评估。

回到3份原文