售前、售后、产品、研发：六个岗位到 FDE 的转型路径对照

FDE 实战手记 · 第 4 篇

上一篇结尾我留了预告，这一篇要回答「售前离领域型 FDE 有多近」。动笔之前我改了主意——只写售前，这个问题就写窄了。

真正的问法应该是：围着企业级产品干活的这一圈人——咨询顾问、售前、售后技术支持、实施项目经理、产品经理、研发——

谁离这个位置近？

近在哪？

缺什么？

缺的那块补得上吗？

六个岗位都摆上桌，比出来的结论才站得住。

先把结论放这儿：售前工程师是距离领域型 FDE **最近的岗位。**但其余五类岗位也各有清晰可行的转型路径。下文完整展开对比推导过程。

一、先立一个前提：FDE 是经验岗，不是毕业生岗

翻各家官方 JD，会看到一条高度一致、优先级也很高的要求：**这是一个长在经验之上的岗位。**OpenAI 的 FDE 要求 5 年以上工程或技术部署经验，且明确要求「包含面对客户开展的工作」；Anthropic 同类岗位常见要求 3–7 年；Google Cloud 2–5 年起步；AWS 高级岗示例要求 6 年以上。唯一的例外是 Palantir——它从应届生招起，但那靠的是一套跑了十几年的内部人才培养体系；这一轮跟进的 AI 厂商等不起，做法高度一致：直接去找已经被客户现场熬过的人！

所以，FDE 是一个「二次职业」，必须叠在另一段职业之上。问题就变成：六类前置岗位里，哪一条职业路径能为转型领域型 FDE 打下扎实的能力底座？

二、比什么：七个维度

用什么标尺来横向比较？我把六家国际厂商 FDE 类 JD 里反复出现的职责，对照第 3 篇领域型 FDE 的定义，蒸馏成七个维度：业务理解——客户的流程怎么跑、组织权责如何划分、KPI 和预算走哪条线；

领域知识——掌握赛道业务全景，包括竞品、行业标准和上下游生态；

产品与技术深度——掌握产品能力边界和底层机制；

现场嵌入——以客户现场为日常工作场景，而不是偶尔拜访；

问题定义——把客户的模糊诉求变成一个可验收的任务；

工程实现——亲手把东西构建出来，并跑通客户的生产环境；

结果责任——以客户业务价值为终点，而不是以自己的交付物为终点。

三、一张对照表

六个岗位逐维度对比（✓ 已具备 / ◐ 半具备 / ✗ 缺口）。以下是我基于这些年与这几类岗位共事的观察给出的判断，欢迎对号入座，也欢迎反驳：

逐岗位速评几句：

咨询顾问：最会梳理客户痛点、最会讲价值的一群人，业务理解不输任何人。短板也硬：没有产品底座，报告交出去，系统不归自己建。

售前：七个维度里四个 ✓，唯一的 ✗ 是工程实现能力。领域知识那个 ✓，我想单独说一句——售前是全行业少有的「跨产品物种」。为了打单，连竞争对手的产品都门儿清，参数、架构、许可模式如数家珍。回看第 3 篇：领域型 FDE 聚焦客户业务问题域，而不是自家产品功能清单；售前是天然跨过「只懂自家产品」这道坎的人。

售后技术支持：产品深度和生产环境排障经验是六个岗位里最扎实的，现场也常驻。差的是往上走的那半截：把故障语言翻译成业务语言，把「系统正常」变成「问题解决」。

实施项目经理：就是在客户现场负责整个项目推进落地的那种。他们手里攥着一张别人都没有的牌：对项目最终验收结果负责，驻场属性直接拉满。差的是深度：领域和产品都懂一些，但通常是在「推进别人定义好的范围」，而不是自己定义任务。

产品经理：定义客户业务问题是本职，产品深度自不必说。最大的 ✗ 是现场——对客户的理解多数隔着一层转述，依赖售前、客服和调研报告。

研发：唯一在工程实现上打 ✓ 的岗位，产品深度也够。但业务理解和现场嵌入是两个 ✗，而这两点恰恰是 FDE 岗位每天必须直面的核心工作。

四、六条终点线，没有一条画在客户业务结果上

表里「结果责任」一行值得单独看：五个 ◐ 加一个 ✓。为什么几乎全是半分？因为六个岗位各自的工作收尾，没有一个落在客户的业务结果上——咨询以报告提交收尾，售前以合同签订收尾，售后以工单关闭收尾，项目经理以客户验收盖章收尾（离得最近，所以给 ✓），产品以功能上线收尾，研发以代码合入收尾。

而领域型 FDE 的任务终点只有一个：任务跑在生产上，结果被验证，客户在用。无论从哪类岗位转型到 FDE，人人都要把自己的终点线往后延伸——这一条对六个角色是公平的，谁也没占便宜。

五、关键不是数 ✓，是看缺口的性质

如果只数 ✓，售前赢了，文章可以结束了。但真正的关键在另一层：缺口和缺口不一样。

把表里的 ✗ 归归类，其实就两种：

一种是工程类缺口——咨询、售前、项目经理、产品经理都缺的「亲手构建」。这个缺口在 2024 年之前是死穴，现在不是了：AI 编程工具把实现门槛降到了「能把需求说清楚就能动手」，这是第 2 篇整篇论证的事。剩下的工程习惯——测试、版本、部署等纪律——可以学习，而且比学一门编程语言快得多。

另一种是认知类缺口——研发缺的业务理解，以及研发和产品经理缺的现场嵌入。这种缺口，AI 一点忙都帮不上。因为 AI 降低的是「实现」的门槛，不是「理解」的门槛：客户的组织怎么运转、一个变更要过几道审批、会议室里多方角力怎么周旋——这些东西不在任何文档里，只能靠常年扎根客户现场泡出来。

所以这张表真正说的是：短板集中在「工程落地」的岗位，路被 AI **修短了；缺少「客户现场」和「业务认知」的岗位，路还是原来那么长。售前恰好是唯一一个硬缺口落在「工程落地」上的岗位——缺的那一块，补齐成本正在持续走低。再加上售前手中「业务理解」和「领域广度」这两张攒了十几年的底牌，这就是我判定售前距离领域型 FDE 最近的完整理由：自身的业务****理解 × AI 的工程能力 = 一个完整的领域型 FDE。**这个公式的前一半，售前已经攒了十几年；后一半，正在变得前所未有地便宜。

六、其他五条路，一句话一条

说售前距离 FDE 最近，不等于别人没有转型的路。每个岗位的路径，恰恰写在各自那一列的缺口里：

售后技术支持：离得第二近。向上补齐业务抽象、总结和价值表达能力即可；或者干脆和售前搭伙——一个管问题定义和客户协同，一个管构建、部署和验证。这是传统厂商起步最现实的双人小组。

实施项目经理：手握其他人难以企及的核心竞争力——对完整项目结果负责。在自己最熟的一个领域往深里扎，从「推进项目既定范围」走到「自主定义任务」，推进力就会变成 FDE 端到端的交付力。

咨询顾问：绑定一个专业产品域，把单纯输出「建议书」升级成可交付的「跑起来的系统」——需求梳理能力配上补齐的工程落地闭环，是很强的能力组合。

产品经理：把工位搬到客户现场去。现场泡上一年，把二手转述变成一手客户经验，产品思维能力在 FDE 岗位上是稀缺品。

研发：唯一不需要补硬技能的人，要补的是走出工位——去客户现场、听懂业务诉求。这条路 AI 帮不上忙；但愿意走的研发，转型成功后会是综合能力最完整的一类 FDE。

七、真实的另一面：转型存在明确门槛

把话说满就不真实了，不能把转型路径说得过于理想化。不管从哪个岗位出发，有两类人这条路走不通：一类是坚决不肯碰键盘的——AI 降低的是门槛，不是零门槛，你至少要愿意动手；另一类是不愿把终点线挪到业务结果上的——FDE 的成功标准是方案被采用并让业务真正受益，而不是自身岗位的阶段性交付物。

反过来，如果你打单时喜欢自己搭环境做 demo，排障时忍不住琢磨客户的业务到底堵在哪，看到问题没被真正解决会觉得难受——不管你名片上印的是六个岗位里的哪一个，你离领域型 FDE 都远比自己想象中更近。

——

下一篇聊点方法层面的东西：这两年指挥 AI 干活，我给它立了几条规矩——把 AI 当员工管，而不是当神拜、当玩具玩。

我在研究这件事，也在做这件事。慢慢写，欢迎同行来聊。

引用与参考来源

六厂 FDE 类岗位要求对照，基于各公司官方招聘页与官方项目材料（OpenAI Careers、Anthropic Greenhouse、Google Careers、amazon.jobs、Microsoft 官方项目材料、Palantir Careers），于 2026 年 7 月采集整理；职责表述为中文改写，非原文搬运。

OpenAI FDE 的官方硬性要求（5 年以上经验，包含面对客户开展的工作、约 50% 出差）出自其官方招聘页，2026 年 7 月在招。

「领域型 FDE」定义与「售前、售后转型路径」见系列第 3 篇及笔者研究手册《领域型 FDE 基础认知》；FDE 投入与薪酬数据见系列第 1 篇文末来源清单。

文中七维度对照表与各岗位评分，是笔者基于公开 JD 与个人从业观察作出的分析判断，不代表任何公司立场，也无意评价任何岗位本身的价值——比较的是到领域型 FDE 的「路径远近」，不是岗位高低。