产品总监最近很烦。
倒也不是最近才烦，只是最近这个问题被放大了。销售要他去做技术支撑，客户要他去讲方案，项目要他到现场拍板，研发要他定义边界，产品团队等他做规划，团队成员还要他培养。
单独看，每件事都合理。合在一起，就变成一个很现实的问题：他几乎没有整块时间做“产品总监应该做的事”。
一开始规划得很好：少量时间支持客户和项目，日常不深度参与，只负责兜底；更多时间放在产品规划、底座能力、团队建设上。
但真到了客户现场，销售、产品、研发、交付这几个系统会全部叠在一起。业务问题、系统问题、组织问题、技术问题、交付问题混成一团。客户要成功，价值要落地，产品要有生命力，技术还要讲得通。
最后只能靠产品总监去兜住所有不确定性。
这个问题表面上是产品总监太忙，往深一层看，是组织里缺少一个能在客户现场承接复杂度的结构性角色。也正因为如此，最近很多人又开始讲 FDE。
大家期待的其实很朴素：当客户现场越来越复杂时，有没有一种角色，能在第一时间承接问题、判断边界、推动收敛？
一、原版 FDE 到底在干什么
讨论国内 FDE 之前，得先把原版语境放出来。
否则它很容易被理解成“会写代码的售前”“更懂业务的开发”“能下现场的产品经理”或者“高级实施工程师”。这些说法都沾边，但都不完整。
这里先说明一点：原版 FDE 也不是所有海外公司都能跑通。它依赖高客单价、强平台能力、客户成熟度和组织投入。本文讨论的不是地域优劣，而是同一个角色模型放到不同商业结构里，成立条件会完全不同。
从几个典型公司的岗位描述看，FDE 至少有几个共同点：
- Palantir 的 FDSE 强调工程师直接嵌入客户现场，理解客户最难的问题，并架构、构建解决方案。
- OpenAI 的 FDE 强调 discovery、technical scoping、system design、build、production rollout，并直接和客户工程团队、业务团队合作。
- Anthropic 的 FDE 强调在客户系统里构建生产级 AI 应用，交付 MCP servers、sub-agents、agent skills 这类技术产物，同时把可重复的部署模式反馈给产品和工程团队。
拆开来看，原版 FDE 至少包含四件事。
第一，真问题来自现场。
它不能坐在公司里听销售转述需求，也不能拿一份需求文档远程开发。它得贴近客户业务现场，理解真实问题是怎么发生的。
第二，真干活需要工程能力。
它不能只会讲概念、写方案、做汇报。它需要能判断技术边界，能配置系统，能做原型，能写代码，把抽象需求往可运行系统上推。
第三，真能用要走到生产落地。
售前讲完就走，产品写完文档就走，开发写完代码就走，这些都会让问题断在中间。FDE 要把问题发现、范围界定、系统设计、构建实现、上线落地串起来。
第四，真回流要反哺产品和工程。
这一点很关键。为某个客户做一次定制交付，本身价值有限。FDE 还要从客户现场提炼可重复的部署模式、产品问题和工程经验，反哺平台能力。
所以原版 FDE 成立，有一个隐含前提：客户场景足够复杂，客户价值足够高，客户愿意为复杂问题定义、深度共创、工程部署和生产落地支付足够高的价值。
否则，这个角色的成本很难覆盖。
二、FDE 的三块能力
如果再把 FDE 拆细，它其实是三块能力的动态组合：
- 技术实现
- 解决方案
- 交付闭环
这三块的比例不是固定的。
平台能力越强的公司，FDE 越可以往技术实现侧走。因为底座已经比较成熟，现场更多是在客户系统里做集成、构建、上线。
平台能力越弱的公司，FDE 越要先靠交付闭环获得客户信任。因为很多能力还没产品化，只能先靠人把项目兜住。
解决方案能力则是中间的关键连接层。客户的问题通常不会天然长成“需求文档”的样子，它需要被翻译、抽象、拆解、确认，再变成能落地的技术方案。
这也是 FDE 容易被误解的地方。
它看上去像一个“全能人”，但更准确地说，它是一个能在现场完成闭环的人。它未必每一块都是专家，但必须知道每一块在哪里会出问题。
很多团队做到这里会卡住：他们以为找一个能写代码的人去客户现场，就叫 FDE。结果这个人听不懂业务，也判断不了组织流程，最后只能做成驻场开发。
反过来，如果找一个很会讲方案的人去现场，但他不理解技术边界，不知道系统集成、数据质量、权限模型、上线验收这些东西的坑，也会把项目带进交付黑洞。
FDE 的难点就在这里：它不是单点能力强，而是能把几个系统串起来。
三、长得像外包，底层是产品逻辑
只讲岗位职责还不够，还要看商业模式。
FDE 的工作形态很像定制开发或者人员外包：人下现场，给客户写材料，做系统，改方案，追上线。
但它和外包的底层逻辑不一样。
人员外包赚的是人头费。项目制定制赚的是一次性交付费。这两种模式下，每个项目都要从 0 到 1 重新打一遍，边际成本很难降下来。
原版 FDE 预设了一条成本曲线：前期很重，甚至收不回成本；但通过产品能力回流，越往后做，定制化成本越低，后续客户能摊薄前面的投入。
这个逻辑更像产品。
前期重投入研发，靠后续复制摊薄成本。只不过 FDE 型公司卖的产品，不只有软件或硬件本身，还包括“底座能力 交付模式”这套能力产品。
现场遇到的问题、踩过的坑、做过的方案、搭过的原型、跑通的流程、沉淀下来的部署模式，都会被提炼、固化、回流，变成下一个客户可以复用的资产。
很多公司学 FDE，最容易漏掉这一点：交付不一定只是成本中心，它也可能是可沉淀、可复用、可产品化的能力来源。
但这件事有两个非常苛刻的前提。
第一，公司真的要打造这套能力产品。
这意味着一线现场经验、方案、部署模式、技术组件要持续沉淀回产品和平台。背后需要产品平台、工程团队、复盘机制和组织耐心。
第二，要有资金环境撑住前期亏损。
打造能力产品很贵，前期派高配置人员下现场也很贵。这笔钱要么客户愿意付，要么公司有长期资本或利润空间支撑。
放到国内多数项目制 B 端场景里，这两个前提都不容易满足。
四、国内 B 端的拧巴结构
做过国内 B 端项目的人，大概率有类似体感：客户最需要乙方投入判断的阶段，往往是签合同之前。
合同前，什么都可以聊。方案先写一版，PPT 先改一版，技术路线先讨论一下，原型最好也有一点。领导要汇报，材料也帮忙写一下。客户内部要立项，理由也帮忙梳理清楚。
如果是重要客户，产品总监、解决方案专家、技术负责人最好都到现场。
这在乙方视角看，很像白嫖。
但客观一点看，甲方也不是没事折磨乙方。甲方花的是组织的钱，买的是一个不确定结果。平台建设项目，尤其是 AI 项目，大家都知道重要，但到底能不能做成、做出来有没有用、乙方靠不靠谱，都有不确定性。
所以签约前那些动作，在甲方眼里是验证：你说你懂业务，你说能落地，你说技术可行，那先让我看到证据。
问题也在这里：FDE 最值钱的工作，恰恰发生在最难收费的阶段。
很多人一听 FDE，先想到驻场技术交付。好像 FDE 就是更懂业务的交付工程师，或者会现场写代码的解决方案。
但最值钱的部分，经常在更前面：现场定义问题。
客户说：“我们想上 AI，想做创新。”
这句话没有任何可交付性。真正有价值的是继续往下拆：
- 你到底想解决什么业务问题？
- 这个问题原来靠什么流程处理？
- 现在卡在哪个环节？
- 是认知问题、效率问题、流程问题，还是数据问题？
- AI 在里面替代谁、增强谁、监督谁？
- 需要什么有效数据？
- 没有数据时替代方案是什么？
- 需要哪些系统集成？
- 第一阶段能做什么？
- 哪些一开始做就会变成交付黑洞？
这些问题，传统上很多时候是产品总监在做。
所以国内很多公司的真实情况是：一遇到重要客户、复杂需求、AI 项目、大客户汇报，产品总监就会被拉到客户现场。
名字不重要，活已经在那里很久了。只是以前它叫产品总监兜底、解决方案专家支撑、技术负责人陪访、交付负责人救火。
五、独立 FDE 岗位为什么难大规模成立
说实话，我不太看好 FDE 作为一个标准岗位，在国内多数项目制 B 端公司里大规模成立。
不是这个能力不重要，恰恰相反，是它太重要、太贵了。
国内 B 端项目的付费结构，很难支撑一个完整授权、完整定价、完整职业路径的 FDE 岗位。
可以用一个粗略的体感模型看这件事。不是严格行业统计，但做过项目制 B 端的人，大概能感受到这个结构。
一个项目真正拿到的钱，往往会被三块吞掉。
第一块，大约一半花在营销拓客和售前方案上。
找客户、找项目、建关系、写方案、改材料、做汇报、做原型、陪客户内部走流程。真正成交的客户只是少数，一个成交项目的利润，要覆盖前面多个没成交项目的探索成本。
甲方以为自己拿到了一些“免费前置支持”，但这些成本最后往往会被摊回整体报价。
第二块，大约三成花在交付兜底上。
项目签下来以后，并不会按方案顺顺利利做完。需求会变，客户会补，系统要集成，材料要验收，问题要响应，售后要兜底。
于是交付目标经常变成：别出事，别投诉，能验收。
第三块，大约两成才留给生产和创新。
生产是为了让销售有东西卖，创新是为了让销售持续有东西卖。但在不少项目制公司里，这部分很容易被短期销售目标牵引。
一旦售前打了水漂，交付又超支，最先被挪去填窟窿的就是这部分预算。
FDE 的尴尬就在这里。
FDE 是高密度、高投入、高现场能力的角色。但很多国内 B 端项目的交易结构，是重度前置探索、重度售前、最低限度交付。
重的地方收不到钱，能收钱的地方又只敢做最低。
FDE 吃的是探索预算、共创预算、问题定义预算、现场闭环预算。而国内很多项目真正愿意付费的，是最终交付结果。
这两件事天然拧巴。
理论上，随着产品能力回流，FDE 的定制成本应该快速下降，最终降到客户预算线以下。但在国内真实结构里，能沉淀成产品能力的预算非常少，成本曲线很难降下来。
最后只能考核单项目利润。
那就会出现一种很常见的变形：用一线工资，提总监级要求。
国外公司敢让 FDE 下现场，是因为给的是高级工程师甚至技术负责人级别的定价，背后还有平台、工程团队和商业闭环支撑。
国内很多公司只学到了“一个人下现场解决问题”，没学到“用高配置的人解决高价值客户的复杂转化”。
结果伪 FDE 变成万能补位岗：售前要管，开发要管，交付要管，产品要管，锅也要背。
这样的人很难培养，即使培养出来，也很难留住。
所以，国内不容易成立的是一个被完整复制、完整付费、完整授权的 FDE title。
但 FDE 型能力的需求一直存在。
六、AI 让能力拆解变得现实
国内 B 端一直都在要求一线角色具备类似能力，只是过去没人叫它 FDE。
售前不能只会讲 PPT，产品不能只在办公室画图，开发不能只闷头写代码，交付不能只照文档实施。
每个岗位都在被推向更靠近业务现场、更懂技术边界、更能推动落地的方向。
这套要求本质上很重。它要求一个人同时像产品总监、解决方案专家、咨询顾问、技术负责人、项目经理和交付负责人。
过去只能靠少数牛人硬扛，很难规模化。
AI 改变的不是“人人都能变成 FDE”，而是让部分能力可以被拆解、辅助、训练、复盘。
举个经过脱敏处理的内部案例：一个高合规、高流程约束的安全运营类 Agent 项目。
安全运营本身强管理、强流程。这个项目不是做个功能、接个系统，而是要吃透客户的组织分工、运营流程、处置规则、风险边界、审批机制和留痕要求。
客户当时的要求很直接：如果不是产品总监亲自做，这个项目就不给。
客户真正要的，是产品总监背后那套能力：听懂业务，判断哪些流程要保留，哪些能优化，哪些动作有风险，哪些必须审批，哪些能交给 Agent，最后还能交付高质量结果。
也就是 FDE 型能力。
我们的做法，是把产品总监脑子里的隐性方法拆成一条 AI 辅助流水线。
| 步骤 | AI 做什么 | 关键产出 | 红线规则 |
|---|---|---|---|
| 业务咨询 | 处理访谈和材料记录，拆术语，列补采问题 | 上下文、术语表 | 私域词必须区分“通用义 / 本项目义”，存疑就标出来 |
| 业务方向抽象 | 从动作、流程片段往上抽象成组织级方向 | 业务方向清单 | 材料不够只能标“暂不足以确认”，不许把话写圆 |
| SOP 建模 | 把现有运营流程还原成 SOP 卡片 | SOP 卡片库 | 封禁、盖章、上报等高风险动作，AI 不许自动补全，必须审批留痕 |
| 问题诊断与需求映射 | 诊断流程问题，映射成功能需求 | 需求清单 | 每个需求必须追溯到一条已确认 SOP 和一个真实问题 |
| 方案与低保真原型 | 基于已确认的 as-is，设计 to-be，输出原型 | 方案草案、原型 | 原型用于对齐认知，不用于炫技 |
这里最重要的是三条红线：
- 存疑必须标记确认
- 高风险动作不能自动补全
- 功能必须追溯到真实问题
它防住了 AI 项目最常见的死法：客户随口一提，乙方觉得能做，AI 又写得漂亮，最后堆出一片悬空功能。
跑完之后，分工也发生了变化：
| 角色 | 负责内容 |
|---|---|
| AI | 整理、抽象、追溯、检查、生成 |
| 产品助理 | 执行流程、补采信息、整理产出 |
| 产品总监 | 关键判断、边界控制、客户确认 |
这套流程产出的术语表、SOP 模板、需求映射规则、诊断清单，会继续沉淀进业务咨询知识库，成为下一个项目能复用的资产。
这就是“现场经验反馈回产品和工程”的国内版本。
但要强调一点：能下放的是结构化信息处理，比如拆术语、还原 SOP、整理需求、出初稿。
真正的判断权没有下放。
业务方向对不对，哪些需求能接，哪些设计会爆雷，哪里必须让客户拍板，仍然压在资深人员身上。
AI 和流程接走的是体力活、整理活、初稿活。拍板活接不走。
这个案例说明一件事：AI 可以把资深复合型人才的隐性方法，拆成一线人员能执行、AI 能辅助、客户能确认、过程能追溯的工作流。
它没有解决独立 FDE 的商业模式问题，但让 FDE 型能力开始可以被拆解和扩散。
七、个人该补哪一块
前面说的“四真”和“三块能力”，可以对应起来看：
- 真问题：对应解决方案能力
- 真干活：对应技术实现能力
- 真能用：对应交付闭环能力
- 真回流：对应组织沉淀能力
前三项是个人能练的。第四项主要靠组织承接。
如果公司没有知识库、复盘机制、平台团队，也没人为“把现场经验沉淀成资产”买单，个人再努力也只能把经验留在自己脑子里。
所以，对个人来说，问题不是“我要不要转成 FDE 这个岗位”。
更实际的问题是：你原来站在哪一块？缺的那一块是什么？
你可能会讲方案，理解客户需求，会写 PPT，但不知道什么能做、什么不能做、做出来要多少成本、落地后会不会变成交付黑洞。
你可能能写功能、搭生产系统，但不知道客户为什么要这个功能，这个问题对业务意味着什么，客户内部怎么验收和汇报，AI 在业务流程里到底替代谁、增强谁、监督谁。
你可能很会推进项目，但不理解技术边界，也不具备方案抽象能力，最后只能做进度管理，无法参与关键判断。
不管从哪一块往里补，有一项能力会先变成公共底座：业务咨询。
业务咨询听起来有点虚，但落到 AI 项目里，其实很硬。它要把客户现场那些模糊、零碎、说不清的问题，翻译成可定义、可验证、可交付的项目。
以前这件事高度依赖资深产品经理或行业专家。现在 AI 能把进入陌生业务场景的门槛拉低一截：快速补背景知识、整理客户口述、拆术语、生成访谈提纲、做需求追溯、还原流程。
但边界也要讲清楚。
AI 能帮你更快形成初步理解，不能替你承担业务后果。它可以辅助归纳，不应该替你拍板。尤其在高合规、高风险、高组织约束的场景里，AI 的产出必须可追溯、可确认、可回滚。
八、FDE 型能力不只在甲乙方之间
FDE 原本更多出现在乙方服务甲方的语境里。
但如果把它理解成“现场闭环能力”，适用范围会更宽。
它同样适用于公司内部复杂项目：
- 内部 AI 提效项目
- 流程 Agent 化
- 跨部门系统建设
- 业务部门和技术部门之间的需求翻译
- 一线经验沉淀成 SOP、Workflow、数据规范、知识库和智能体
这些看起来是内部项目，本质上仍然需要一类人完成：
现场理解、问题定义、方案设计、原型验证、技术实现、推动落地、持续迭代。
只不过客户从外部甲方，变成了内部业务部门；交付对象从外部客户，变成了内部组织；预算逻辑从项目合同，变成了管理投入和组织效率。
下面这张图，就是 AI 开发实习生按照业务咨询逻辑整理出来的标书 Agent 规划图。它未必完美，但比很多业务口头表达已经更结构化。
但范围越宽，越要设边界。
什么活都往 FDE 上套，这个概念就会失效。
判断一个场景值不值得用 FDE 型能力，可以看四个问题：
- 有没有真实现场问题，而不只是文档需求？
- 有没有技术实现压力，而不只是方案包装？
- 有没有生产落地要求，而不只是 Demo 演示？
- 有没有经验回流价值，而不只是一次性交付？
四个条件都满足，FDE 型能力才值钱。缺得太多，就只是普通需求或普通项目，没必要动用重武器。
九、FDE 实际是什么
如果按岗位说，FDE 在国内很难被完整复制。
如果按能力说，它会被越来越多岗位吸收。
我更愿意把 FDE 型能力理解成：
在真实现场里，把业务问题、AI 能力、产品方案、技术实现和交付闭环连接起来的能力。
这句话拆开，就是三块硬动作。
解决方案这一块，核心是在现场把问题定义清楚。
技术实现这一块，核心是判断什么能做，并做出来给人看。
交付闭环这一块，核心是让从需求到上线的链路不断掉。
还有一项短期内很难被 AI 替代：复杂人际关系和组织关系的处理能力。
很多 B 端项目真正难的地方，不是写代码，也不是画原型，而是让客户内部不同部门达成一致，让技术、业务、管理、合规之间能形成可执行的共识。
这一块，AI 只能辅助信息处理，不能替你处理组织博弈。
十、FDE 的来龙去脉
| 维度 | 原版 FDE | 国内现状 | 未来扩散方向 |
|---|---|---|---|
| 定位 | 独立岗位，昂贵的组织接口 | 分散的补位者，伪 FDE 容易变万能背锅岗 | FDE 型能力被各岗位吸收 |
| 商业模式 | 产品逻辑，前期重投入，靠能力产品飞轮摊薄成本 | 项目逻辑，一次性交付，交付常被当成本中心 | 把交付当产品投，从成本变资产 |
| 真正产品 | “底座能力 交付模式”这套能力产品 | 生产和创新多服务于销售，能力沉淀预算不足 | 隐性方法拆成工作流、SOP、知识库 |
| 能力结构 | 技术实现 解决方案 交付闭环 | 三块被拆在不同部门，常靠产品总监兜住 | 每个人按自己的位置补另外两块 |
| 交易前提 | 客户愿意为探索、共创、问题定义付费 | 客户多为最终交付付费，前置阶段靠摊销 | 能力成本内部化，成为组织能力投资 |
| 成本曲线 | 前期重，后期随复用快速下降 | 前期更重，后期下降慢，容易微亏 | AI 辅助拆解、沉淀、训练，降低成本 |
| 现场形态 | 从 discovery 到 production rollout 全链路 | 售前承诺、低成本交付、售后兜底 | 拆分成可执行节点，AI 辅助整理和追溯 |
| 能力反馈 | 现场经验持续反哺产品和平台 | 经验留在个人脑子里，人走经验走 | 知识库 工作流 复盘机制 |
| 个人要求 | 高薪酬、高授权、权责利匹配 | 一线薪酬、总监级要求，容易流失 | 按自身底牌补齐缺口 |
| 规模化方式 | 高配置人才 能力产品飞轮 资本支撑 | 靠少数牛人硬扛 | AI 降低跨界门槛，让能力可训练 |
我的判断是：国内真正需要的，不一定是一个叫 FDE 的标准岗位。
至少在多数项目制 B 端公司里，它很难被完整复制。因为它依赖高客单价、强平台能力、客户共创预算、长期组织投入和能力产品飞轮。
但国内真正需要的是 FDE 型能力。
它原本藏在产品总监、资深方案、资深交付、技术负责人、项目经理这些少数复合型人才身上。过去这类能力很难培养，也很难规模化，只能靠少数人硬扛。
AI 带来的变化，是让一部分现场闭环能力开始被拆解、辅助、训练、复盘。术语整理、SOP 还原、需求追溯、方案初稿、原型验证这些工作，可以逐渐从资深个人经验里拆出来，沉淀为组织能力。
未来不一定每家公司都有 FDE 岗位，但很多岗位都会越来越需要 FDE 型能力。
回到开头那个被偷走时间的产品总监。
他不会消失。但他身上那套“一个人兜住业务、产品、技术、交付”的能力，会被拆成三块，长到更多人身上。
到那时，可以被拉到现场的，就不只是他一个人了。
附录：哪些岗位适合补 FDE 型能力
前面讲的“技术实现 / 解决方案 / 交付闭环”三块，落到具体岗位，大致对应三种方向：
- 方案型 FDE：解决方案能力强
- 技术型 FDE：技术实现能力强
- 交付型 FDE：交付闭环能力强
下面这张表不是转岗承诺，更像是一张能力补全地图。你已经占住哪一块，缺的那块，就是下一阶段要补的方向。
| 原岗位 | FDE 转型方向 | 已有优势 | 主要短板 |
|---|---|---|---|
| 技术售前 | 方案型 FDE | 接近客户一线，懂痛点、预算、决策链、演示、POC | 容易停在 PPT 和 Demo，要补生产落地能力 |
| 解决方案顾问 | 方案型 FDE | 会把业务问题包装成方案，懂行业场景和客户语言 | 要补技术实现，如 AI 工具链、数据流、系统集成 |
| 产品经理 | 方案型 FDE | 会需求分析、流程抽象、原型设计、验收标准设计 | 要补技术验证能力，不能只会写需求 |
| AI 产品经理 | 方案型 FDE | 懂大模型边界、RAG、Agent、Workflow、知识库 | 要补工程交付、评测、上线机制 |
| 咨询顾问 | 方案型 FDE | 会访谈、诊断、方案设计、组织推进 | 要补技术实现和交付闭环，形成可交付作品 |
| 行业运营 / 业务专家 | 方案型 FDE | 最懂真实业务流程、用户问题、行业规则 | 要补工具化、产品化、工程化表达 |
| 后端 / 全栈开发 | 技术型 FDE | 能写代码、接 API、做数据处理、部署系统 | 要补客户沟通、需求判断、业务抽象 |
| 数据分析 / BI | 技术型 FDE | 懂数据口径、指标体系、报表、业务分析 | 要补 AI 应用搭建和自动化执行链路 |
| 运维 / DevOps | 技术型 FDE | 懂环境、权限、稳定性、监控、故障处理 | 要补业务流程理解和产品化表达 |
| 低代码 / RPA 工程师 | 技术型 FDE | 熟悉流程自动化、系统连接、表单审批、任务编排 | 要补大模型能力和复杂业务判断 |
| 测试 / QA | 技术型 FDE | 天然懂验收、边界条件、异常 Case、回归测试 | 要补业务方案设计和 AI 应用搭建 |
| 实施顾问 | 交付型 FDE | 懂客户现场、流程配置、系统上线、培训和验收 | 要补 AI 原理、工具编排、接口集成 |
| 项目经理 | 交付型 FDE | 懂排期、资源协调、风险管理、跨部门推进 | 要补技术判断力，不能只做进度管理 |
| 客户成功 / 售后 | 交付型 FDE | 懂客户使用情况、续费逻辑、问题反馈和价值呈现 | 要补方案改造能力，不能只做关系维护 |
说到底，你现在站在哪一型，决定了你的底牌。
你缺的那一型，决定了你未来几年的天花板。
