By 黄金金枪鱼 
AI 观察室 · Day 12 · FDE vs PM vs Sales 角色对比
与公众号「数字员工在岗」news-7 同步选题；本文为深度技术 + 商业解析版
引子：当三个角色坐在同一张桌子上
2026 年 6 月，旧金山一家估值 30 亿美元的 AI Agent 创业公司里，三个人的职位卡上分别写着 Forward Deployed Engineer、Product Manager、Account Executive。他们在同一场客户 kickoff 会上坐到了一起——客户是德国一家中型银行的 CRO（首席风险官），目标是把客服中心 60% 的工单自动化。
但三天过后，这个项目的归属开始模糊：
- FDE 觉得「产品定位不对」，因为客户实际的痛点是「信贷审批时的反欺诈规则」，不是客服自动化；
- PM 觉得「FDE 在越权」，因为重新定义需求应该由 PM 来做，不应该由驻场工程师决定；
- Sales 觉得「这两个工程师和 PM 在拖节奏」，因为客户 CRO 已经在合同里写了 90 天交付，现在改需求会丢掉这笔 240 万美元的 ARR。
这种「三方拉扯」在 2026 年的 AI 公司里几乎每周都在发生。**根本原因是：FDE、PM、Sales 这三种角色的边界，在 AI 时代的「嵌入式交付」模型下已经彻底模糊了。**
传统 SaaS 时代，三者的分工非常清晰：Sales 拿单、SE（Solutions Engineer）做 PoC、PM 定义产品、客户内部团队实施。FDE 把 SE 和实施两层折叠成「嵌入式工程师」，直接把 PM 的部分职能（定义成功标准）和 Sales 的部分职能（识别 upsell 信号）吸收进了自己的角色。
今天这篇文章，我们用一张 mermaid 图、一个真实场景、五个拆解维度，把 2026 年 AI 公司的「FDE、PM、Sales」三方权责边界画清楚。
文章最后会给出三条对每一方都实用的判断标准：**什么时候该由 FDE 接手、什么时候该把决定权交回 PM、什么时候该让 Sales 把节奏权拿走**。
一、FDE、PM、Sales 在 AI 时代的真实工作流
1.1 传统 SaaS 时代的三段式分工
在 2015-2022 年的传统 SaaS 模型里，三个角色的工作流是串行的：
1. **Sales** 找到客户决策人，签下 ARR 合同；
2. **SE（Solutions Engineer）** 在 2-4 周内做 PoC 验证「产品能解决客户问题」；
3. **实施团队**（多数时候是第三方咨询公司）花 3-6 个月把产品上线；
4. **客户内部 PM** 接管运维，第三方撤退。
这串行结构里，**PM 的边界非常清晰**：他只对「产品路线图」负责，不参与具体客户的实施细节。Sales 也只对「签单 + 续约」负责，不参与 PoC 之后的工程交付。
1.2 AI 时代的「折叠式」分工
到了 2024-2026 年，这串行结构被「**折叠**」了。三家代表性公司的招聘页清楚说明了这一点：
- **Palantir** 的招聘页（palantir.com/careers/forward-deployed-engineer [200]）把 FDE 描述为「需要能坐在客户工厂地板上、把客户的脏数据用 8 周变成一个能跑的生产系统的人」；
- **Anthropic** 的 Applied AI 岗位（anthropic.com/careers [200]）强调 FDE「需要能直接面对客户的工程团队、定义成功标准、并写出 production-grade 代码」；
- **HFS Research 2026 年 3 月报告**（hfsresearch.com/research/fde-optional-ai-flywheel-spin [200]）把 FDE 定义为「**The Services-as-Software flywheel requires an embedded execution layer**」——把 LLM、Agent、AI Coding 这些加速器真正接入企业生产系统的「嵌入式执行层」。
折叠之后，**FDE 同时承担了 SE 的售前 + 实施的工程交付 + PM 的部分成功标准定义 + Sales 的部分 upsell 信号识别**。
这就直接导致了文章开头那张桌子上三方拉扯的现象。
1.3 工作流的 mermaid 全景图
上面这张图描绘了一个典型的 AI 时代客户交付链路：
- **Sales 阶段**：拿到 LOI（Letter of Intent，意向书），但还没签正式合同
- **FDE 介入点**：在 LOI 之后、合同之前介入，做 1-2 周的「discovery」——这不是 SE 的 PoC，而是「**判断这个客户到底值不值得做**」
- **PM 介入点**：在 FDE 完成 discovery 之后介入，定义产品的 success metric 和 release scope
- **生产交付**：FDE 带着 1-2 个工程师驻场 8-12 周
- **客户培训 + 撤离**：FDE 培训客户的内部运维团队，然后去下一个客户
- **续约 + 扩展**：Sales 在合同到期前 60 天介入，谈续约和 upsell
**关键洞察**：FDE 是这条链路上**唯一同时连接客户工程团队、公司 PM 团队、公司 Sales 团队**的人。PM 和 Sales 都不直接面对客户的技术现实。
二、五维深度拆解：FDE vs PM vs Sales
下面从决策权、考核指标、技术深度、客户接触频次、退出条件五个维度，把三种角色拆开看。
2.1 决策权维度
| 决策类型 | Sales | PM | FDE |
|---------|-------|-----|-----|
| 「这个客户要不要接」 | 弱建议权（受 KPI 驱动） | 无 | **强否决权**（基于工程现实） |
| 「产品应该做什么」 | 无 | **强主导权**（路线图 + 成功标准） | 弱建议权（基于客户真实痛点） |
| 「客户应该付多少钱」 | **主导权** | 无 | 弱建议权（基于实施成本估算） |
| 「这个功能上线时间」 | 无 | **主导权**（产品 release calendar） | 弱建议权（基于驻场进度） |
| 「客户内部团队谁来运维」 | 无 | 弱建议权（基于产品复杂度） | **主导权**（亲自培训） |
**典型冲突**：当 FDE 在客户现场发现「客户真正需要的功能不在公司路线图上」时，PM 会坚持「我们不能为单一客户改路线图」，FDE 会坚持「不做这个功能客户就会流失」。**最终决策权通常在 CEO/CTO 手里**，但 FDE 的现场报告权重越来越大。
2.2 考核指标维度
- **Sales** 的 KPI：ARR、ACV（平均合同金额）、pipeline velocity、win rate
- **PM** 的 KPI：产品 OKR（DAU、retention、feature adoption）、NPS、release frequency
- **FDE** 的 KPI：**客户能否独立运维**（这是核心）、客户 NPS、production workload 增量、upsell 转化率
**关键差异**：FDE 的核心 KPI 是**能力转移**——客户内部团队能独立运行这套 AI 系统的那一天，才是 FDE 的「胜利日」。这跟传统 SE 的「PoC 通过就赢」完全相反。
2.3 技术深度维度
| 角色 | 要求的最低技术深度 | 通常来自的背景 |
|------|-------------------|---------------|
| Sales | 能听懂技术 demo，能向非技术决策人翻译 | 商科 / MBA / 销售背景 |
| PM | 能写 SQL、能用 API 跑 prototype、能读懂架构图 | CS / EE / 产品经理 |
| FDE | **能写生产级 Python/TypeScript**，能调 LLM API、做 ETL、debug GPU 推理 | CS / EE / OR / 工业工程 |
2.4 客户接触频次维度
- **Sales**：售前 3-5 次接触 + 续约前 2-3 次接触
- **PM**：每个客户 1-2 次（kickoff + 中期 review）
- **FDE**：每个客户 **20-50 次**（每周 3-5 次 onsite 或视频会议）
**关键洞察**：FDE 是**公司里唯一长时间持续观察客户真实使用情况的人**。PM 看到的客户需求是「客户高管在 kickoff 上说的」，FDE 看到的是「客户一线员工在第 6 周真实使用的」。这两个图景经常完全不一样。
2.5 退出条件维度
- **Sales**：合同签完 + 首付款到账
- **PM**：feature 上线 + 客户可以自助使用
- **FDE**：**客户内部团队独立运维 30 天无重大事故**
第三个退出条件是 FDE 模式与传统 SE 模式最本质的区别。FDE 卖的不是 license 席位，是「能力转移」。
三、一个真实场景的三方协作推演
为了把这三种角色的边界讲清楚，我们用一个**虚构但贴近现实**的场景走一遍。
**场景**：一家德国中型银行的 CRO 想用 AI 把客服中心 60% 的工单自动化。供应商是一家估值 30 亿美元的 AI Agent 创业公司。
3.1 第 1 周：Sales 阶段
- Sales 与 CRO 接触 4 次，识别出 CRO 的真实诉求是「**降低 30% 客服人力成本**」
- 签下 LOI，金额 240 万美元 / 18 个月
- Sales 把 LOI 转给 FDE 团队和 PM 团队
3.2 第 2-3 周：FDE Discovery
- FDE（2 人）飞到法兰克福，与客户 8 个团队（客服、IT、合规、数据、风险、产品、采购、HR、CFO 办公室）分别访谈
- FDE 在第 14 天发现：「**真正的高 ROI 场景不是客服自动化，是反欺诈规则审核**」。客服自动化的 ROI 是 1.8 倍，反欺诈审核的 ROI 是 4.6 倍
- FDE 立刻把这个发现同步给 PM 和 Sales
3.3 第 4 周：三方决策会
- Sales 视角：改需求会拖慢 6 周，可能丢掉合同（销售已经向上级承诺 90 天交付）
- PM 视角：产品路线图是「客服自动化」，反欺诈不在 scope，要做的话得排到 Q4
- FDE 视角：如果坚持客服自动化，客户的 ROI 不达标，3 个月后客户不会续约
3.4 三种不同的处理方式
**方式 A：让 Sales 主导**（最常见于 2024 年前的传统公司）
→ Sales 强行推客服自动化 → 3 个月后客户 ROI 不达标 → 18 个月后不续约 → ARR 损失 240 万美元
**方式 B：让 PM 主导**（最常见于产品文化重的公司）
→ PM 拒绝改 scope → FDE 在客户现场强推客服自动化 → 客户内部团队勉强上线 → NPS 评分 4.2/10
**方式 C：让 FDE 主导 + 三方共担**（2026 年最成熟的 AI 公司模式）
→ FDE 与 CRO 直接对齐「改做反欺诈」→ PM 把反欺诈模块排到下个 sprint → Sales 把合同条款改成「90 天 + 60 天双阶段交付」→ 客户 18 个月后续约 + 扩到 480 万美元
**关键洞察**：方式 C 不是「FDE 赢了」，而是「**FDE 的现场发现被纳入了产品路线图**」。这是 AI 时代「嵌入式交付」模型的核心机制。
四、协作图：什么决策该谁拍板
这张决策图给出了五个常见决策点的归属：
1. **「这个客户值不值得做」** → FDE 主导 + Sales 否决权（如果 ARR 太低）
2. **「产品功能范围」** → PM 主导 + FDE 强建议权
3. **「客户应该付多少钱」** → Sales 主导 + FDE 成本估算输入
4. **「功能交付时间表」** → PM 主导 + FDE 实施反馈
5. **「客户能否独立运维」** → **FDE 单一主导权**（这是 FDE 的「看门人」角色）
五、对每一方都实用的判断标准
下面三条判断标准，分别给 Sales、PM、FDE 三方使用。
5.1 给 Sales 的判断标准
**当 FDE 反馈「客户真实需求和 LOI 写的不一样」时，问自己三个问题**：
1. 这个改动是「**场景级调整**」（换场景但保留 ARR）还是「**目标级调整**」（连客户要解决的问题都换了）？
2. 如果坚持原 LOI，客户的 18 个月留存概率是多少？
3. 如果接受调整，需要给 PM 多少额外的工程资源？
**判定原则**：如果 FDE 提出的调整是「场景级 + 18 个月留存能提高 20% 以上 + 工程资源增加可控」，**接受 FDE 的判断**。
5.2 给 PM 的判断标准
**当 FDE 反馈「客户想要的功能不在路线图上」时，问自己三个问题**：
1. 这个功能是「**单客户定制**」还是「**3 个以上客户的共性需求**」？
2. 这个功能进入路线图后，**对其他客户的影响**是什么？
3. 这个功能能否**抽象成通用模块**，让多个客户受益？
**判定原则**：如果满足「3 个以上客户 + 不损害其他客户 + 可抽象成通用模块」，**把它排进下个季度路线图**，而不是作为「单客户定制」拒绝。
5.3 给 FDE 的判断标准
**当你在客户现场发现「真实需求和 LOI 不一致」时，问自己三个问题**：
1. 你的判断是**基于客户一线员工的反馈**，还是**基于客户高管的反馈**？
2. 如果客户高管知道了你的判断，他们会**支持**还是**反对**？
3. 这个调整需要 PM 团队**额外多少工程资源**？你是否已经评估过成本？
**判定原则**：FDE 的现场判断**必须基于一线反馈 + 提前与 PM 估算成本**，不能仅凭直觉否决原 LOI。
关键点总结
- 🎯 **FDE、PM、Sales 的边界正在「折叠式」重构**：传统 SaaS 的串行分工（Sales→SE→实施→客户 PM）被压缩成「Sales→FDE 主导 + PM 共担」的并行结构
- 🔍 **FDE 的核心 KPI 是「能力转移」**：客户内部团队能独立运维的那一天，才是 FDE 的胜利日
- 📊 **决策权不是「谁职位高」，而是「谁掌握信息」**：FDE 掌握客户现场信息、PM 掌握产品路线信息、Sales 掌握 ARR 信息
- 💼 **三方冲突的根源是「信息不对称」**：传统 SE 模式靠「串行」避免冲突，FDE 模式必须靠「**三方共担 + CEO/CTO 最终仲裁**」解决
- 🚀 **2026 年最成熟的 AI 公司模式是「FDE 主导 + 三方共担」**：FDE 的现场发现被纳入产品路线图，而不是被当成「单客户定制」拒绝
- ⚖️ **「嵌入式执行层」是 AI 时代的核心价值**：HFS Research 把 FDE 定义为连接 LLM、Agent、AI Coding 这些加速器与企业生产系统的「embedded execution layer」
行业影响与未来展望
2026 年下半年，FDE、PM、Sales 三方边界还会继续演变。从公开的行业信号来看，至少有三个趋势值得关注：
**趋势 1：FDE 的「职业天花板」会被打破**
传统观点认为 FDE 的职业路径是「FDE → 工程经理 → 工程总监」，但 2026 年已经出现「FDE → 客户成功 VP → CRO」的横向路径。这是因为 FDE 掌握了公司里**最完整的客户-产品双向信息**。
**趋势 2：PM 角色的「技术深度」要求会大幅提高**
当 FDE 可以直接修改客户的功能 scope 时，PM 必须能用 SQL/代码验证 FDE 的判断是否合理。这会推动 PM 岗位从「MBA + 商业直觉」向「CS 背景 + 商业直觉」迁移。
**趋势 3：Sales 角色会向「战略客户经理」演化**
当 FDE 接管了大部分技术售前工作，Sales 的核心价值会从「签单」转向「**识别 ARR 长期增长机会 + 协调内部资源**」。这会推动 Sales 岗位向「客户战略顾问」演化。
结语：边界的本质是「信息」
FDE、PM、Sales 的边界之争，本质上不是「谁的权力大」的问题，而是「**谁掌握哪一类信息**」的问题。
- FDE 掌握「**客户真实使用情况**」的信息
- PM 掌握「**产品能力边界 + 未来路线**」的信息
- Sales 掌握「**客户商业决策链 + 长期增长机会**」的信息
三方在 AI 时代的最佳协作模式，**不是去争夺决策权**，而是建立一套让这三类信息「**无延迟双向流通**」的机制。这也是 HFS Research 在那份 2026 年 3 月报告里说的「**Services-as-Software flywheel**」——只有当 FDE、PM、Sales 三方形成飞轮，AI 公司才能从「demo 公司」变成「recurring revenue 公司」。
下一篇 FDE 系列将继续拆解 2026 年下半年的招聘趋势——哪些公司在大规模招 FDE、FDE 的薪酬区间如何变化、FDE 的简历应该怎么写。
参考资料
官方文档
- Palantir: Forward Deployed Engineer 招聘页 [200] - FDE 职位定义原文
- Palantir: Compass 平台 [200] - Palantir 企业 AI 平台
- Anthropic: Careers（Applied AI / FDE 岗位） [200] - Anthropic 招聘入口
- Anthropic: Newsroom Index [200] - 官方新闻索引
开源项目 / GitHub
- pierpaolo28/Awesome-FDE-Roadmap [200] - FDE 转型路线图，508 stars
- libaice/Awesome-FDE [200] - FDE 资源 / 公司 / 技能清单，74 stars
- suboss87/FDEOps [未验证 - 代理不可达] - FDE 方法论与规范
行业报道 / 分析报告
- HFS Research: Stop treating FDE as optional [200] - 2026-03，FDE 是企业 AI flywheel 的必备执行层
- a16z: Marketplace 100 [200] - a16z 年度市场报告
- kairollmann.de: Forward Deployed Engineer, the new full-stack developer [200] - 2025-11，FDE 作为新全栈开发者
社区讨论
- HN Algolia: Forward Deployed Engineer 搜索 [200] - HN 反向搜索入口
- HN: Rise of the Forward Deployed Engineer [200] - HN 讨论帖索引
- HN: Ask HN: Why is the term forward deployed engineer (FDE) popular all of a sudden? [200] - HN 讨论帖索引
- Reddit r/MachineLearning [未验证 - 代理不可达] - Reddit ML 板块
对比基准 / 学术研究
- arXiv: Agentic AI for Intent-Based Industrial Automation [200] - 2025-06
- arXiv: FieldWorkArena [200] - 2025-05
- arXiv: Human-AI Teaming Smart Manufacturing [200] - 2022-01
- arXiv: AI-Driven Customized Manufacturing Factory [200] - 2021-08
**本文由 AI 生成**。内容基于公开资料整理，可能存在事实偏差，引用链接请以原始来源为准。