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