第 8 章 · 不是新名字，而是旧角色在前线汇合

FDE 火起来以后，最常见的争论不是它该做什么，而是它以前叫什么。

有人说，这不就是实施顾问吗？

有人说，明明是解决方案架构师。

也有人觉得它只是会写代码的售前，或者愿意驻场的全栈工程师。

这些说法都碰到了一部分，又都不完整。

FDE 不是凭空创造了一套新技能。它更像把企业软件里原本分散的几种角色拉到同一张桌上，然后告诉他们：这次先别急着交接，跟到结果出来再说。

每个旧角色，都守着一段路

售前最早接触客户。

他要理解客户大概有什么问题，把产品能力讲明白，也要帮助销售判断机会值不值得追。但合同签完以后，项目通常会交给实施或交付团队。

解决方案架构师负责把系统拼起来。

他考虑接口、数据流、权限、性能和部署，确保方案技术上能成立。可业务到底采用多少，往往不是他的主要指标。

实施顾问最懂客户现场。

他配置系统、梳理流程、培训用户、处理上线问题。做得好的实施顾问，本来就很像今天说的 FDE。区别在于，很多实施项目的边界仍由功能清单和验收节点决定。

产品经理负责共性。

他要决定什么进入产品主干，什么只是个别客户需求。离客户太远，容易做出没人用的功能；离单个客户太近，又可能把路线图变成定制清单。

数据工程师和软件工程师把方案做成能跑的系统。

他们对代码、数据和生产稳定性负责，却不一定有机会参与最早的问题定义。等需求到手，方向可能已经定了。

客户成功接最后一段。

上线以后谁在用、为什么不用、客户会不会续约，轮到他关心。但很多产品问题到这时已经很难重做。

这套分工并不落后。大公司必须分工，不可能让每个人从销售做到运维。

问题出在交接。

一个问题每经过一次交接，就会丢一点上下文。最初说的是“减少订单争议”，到了方案里变成“建设异常看板”，到了研发手里变成几个接口和页面，客户成功最后发现用户仍然在线下处理。

每一棒都按要求跑完，接力棒却不是最初那一根了。

FDE 要把几段路临时接起来

OpenAI 对 FDE 的公开岗位描述很具体：从发现问题、技术范围界定、系统设计、构建一直负责到生产上线；成功要看生产采用、可衡量的工作流影响，以及能反过来改变产品和模型路线的评估反馈。

这段描述里，最重要的不是会哪些框架，而是几个平时分开的动作连在了一起。

发现问题的人参与构建，构建的人跟到生产，生产反馈还能回到产品和研究。

这就是 FDE 的基本形状。

它不要求一个人永远包办所有角色。复杂项目仍然需要业务专家、安全团队、产品、研究和客户自己的工程人员。FDE 的作用，是保证这条链中间没有一段变成“那不归我管”。

有时是一个强工程师承担，有时是一支两三人的小队。重点不是英雄，而是整条链上必须有人持续拿着上下文。

“前线”不是坐在客户办公室

驻场不等于前线。

一个工程师每天坐在客户会议室里，按需求单写代码，仍然可能离问题很远。另一个人通过远程方式查看真实工作流、与操作人员一起调试，并对上线结果负责，反而更接近前线。

前线指的是离三样东西近：

离真实工作近，能看见文档外的例外；
离生产系统近，知道代码出错会发生什么；
离结果近，能判断交付有没有改变业务。

少一项，角色都会变形。

只靠近工作、不碰生产，容易停在咨询；只碰生产、不懂结果，容易变成外包开发；只谈结果、不具备工程能力，又会回到售前承诺。

FDE 的难处，正是三项都不能完全推给别人。

中国早就有人在干同构的活

在 FDE 这个名字流行以前，中国企业软件现场一直有一批跨界的人。

有的实施顾问能直接写脚本，有的系统分析师跟业务一起梳理流程，有的数据负责人既做架构又向老板解释投入产出。项目出问题时，客户首先找的往往不是职位最高的人，而是那个知道系统、业务和历史原因怎样连起来的人。

他们未必拥有 FDE 这个头衔，也未必具备今天的大模型能力。但工作形状已经很接近：问题边界模糊，必须进入现场，技术与业务不能分开。

承认这段历史，不是说 FDE 只是旧岗位换名。

AI 带来的原型速度、概率性风险、工具调用和持续评估，让现场角色必须具备新的工程方法。过去一个懂业务但不会写生产代码的顾问，可以把需求交给研发；今天如果原型每天变化、模型行为必须现场测试，交接成本会变得很高。

旧角色提供了骨架，AI 改变了节奏和责任密度。

不是所有客户项目都需要 FDE

FDE 也容易被滥用。

标准产品已经成熟、客户需求清楚、配置和培训就能完成的项目，没有必要派一支昂贵的跨职能团队。硬套 FDE，可能只是增加成本。

更适合 FDE 的场景通常有几项特征：

问题重要，但客户自己还说不清；
数据、流程和权限横跨多个系统；
需要边做边验证模型能力；
失败代价较高，不能交完原型就走；
现场发现有机会沉淀为产品能力。

这里面最后一项很关键。

如果每个客户的问题都只对自己有用，FDE 团队再强，也会被无穷定制拖住。前线必须既服务当前客户，又替产品寻找可复用的模式。

这是一种双重责任，天然会冲突。

客户希望你只看他，产品团队希望你带回共性。FDE 要做判断：什么是这家客户的上下文，什么是整个行业反复出现的问题。

判断得好，现场成为产品的眼睛；判断不好，产品成为项目的仓库。

新的不是能力清单，是责任没有那么容易切开

把 FDE 归到哪个旧岗位，最终没有太大意义。

企业不会因为职位名称更准确就得到结果。它关心的是，当问题从会议室走到生产环境，是否有人一直知道为什么做、做成什么样、出了问题怎么办。

FDE 的价值，就在这段连续性。

它把过去几次交接之间掉下去的东西捡起来：客户实际怎么工作、技术实现的限制、上线后的采用、现场对产品的反馈。

也正因为责任被接长了，评价 FDE 不能只看代码、上线速度或客户满意。

下一章要问的是：如果“上线”不再等于完成，这份新的交付契约到底应该以什么为终点？

本章资料

场景说明：本章角色交接示例用于说明职责边界，不对应某一家公司的固定组织结构。