OpenFDE 雨燕OpenFDE
组织与洞察13 / 16

组织与商业模式

五种组织模式,以及“服务 vs 产品复利”的核心张力。

FDE 不是一个孤立岗位,而是一种组织设计。它要同时回答两个问题:用什么团队结构把工程师送进客户现场,以及如何在"深度定制"与"规模化毛利"之间不被拖垮。答错任何一个,FDE 都会退化成低毛利的项目制服务。

前提:团队本身得是 AI Native

AI 时代的 FDE,必须是 AI Native 的团队 / 组织。下面这五种形态只是结构外壳——真正决定成败的,是这支队伍自己做 discovery、写代码、上线、回流的方式是否 AI 原生:用 Agent 压缩交付周期、用 eval 管住质量、把现场信号持续喂回模型与产品。否则组织图画得再漂亮,也只是把传统 SI 换层皮。

五种组织模式

不同公司根据产品、客户与商业模式,演化出五种典型的 FDE 组织形态。

Palantir 模式:平台 + FDSE + Deployment Strategist

强平台作底座,FDSE(Delta)负责现场定制与工程实现,Deployment Strategist(Echo)负责业务、产品、关系与扩展。优点是客户价值创造快、现场反馈强、平台持续吸收一线经验;风险是高度依赖人才密度、服务成本高、易堆积定制债务。

AI Lab 模式:Research / Product / FDE 闭环

OpenAI、Anthropic、Mistral 的形态:Research 提供模型能力,Product 提供 API 与平台,FDE 把能力部署到客户场景,field feedback 回流到模型与产品。适合模型能力快速变化的环境——客户真问题能最快暴露平台缺口。

云厂商模式:Cloud + AI Platform + Customer Engineering

Google Cloud 的形态:在云平台上把 Gemini / Vertex AI / Agent 能力落地到客户生产环境,串起云基础设施、数据仓库、既有系统、Agent / RAG / workflow 与安全治理。FDE 在这里更像生产级 Agent / 企业集成工程师。

独立部署公司模式

2026 年出现的新形态:模型公司用独立或半独立的部署服务组织把落地能力规模化。OpenAI Deployment Company 嵌入 FDE 触达大量企业,Anthropic 的企业 AI 服务公司聚焦中型企业把 Claude 带入核心运营。本质是回答"AI 能力变化太快,传统 SI 和客户 IT 跟不上"。

Startup 模式:早期工程师天然就是 FDE

很多 AI startup 早期没有专职 FDE,但创始人和早期工程师实际在做 FDE 的事:陪 discovery、写定制代码、接数据、做 PoC、上线、收反馈、改产品、再复制给下一个客户。正如 Bob McGrew 所说,FDE 培训本质就是创始人培训。

核心张力:服务还是软件?

引述

客户需要深度定制,但软件公司需要规模化毛利。

FDE 模式的全部组织设计,都是为了化解这一张力。它的好处很实在:更快找到真实需求、更快证明 ROI、更容易拿下大客户、缩短销售周期、增强粘性,并把部署经验沉淀为产品。但风险同样致命——

!
最危险的失败:沦为低毛利服务

人力成本高、毛利低于纯软件、定制代码难维护、scope 容易失控、工程师被客户 support 消耗、现场团队与核心产品团队割裂,最终变成"伪产品公司、真咨询公司"。a16z 反复提醒:如果不能把现场经验沉淀成产品复利,FDE 就会滑向 services business;Bob McGrew 的建议更直接——如果不是非做 FDE 不可,就别碰,因为很可能最后变成做服务。

产品化阈值与正确的 KPI

化解张力的关键是一个"产品化阈值"思想:前 1–3 个客户做深度定制,之后每个客户的定制化程度必须越来越低。 Bob McGrew 在复盘 Palantir 时给出了反直觉但关键的判断标准——

KPI 是合同规模 / 成果价值,不是定制工作量

FDE 模式下衡量成功的不是"为每个客户做了多少定制",而是两件事:一是你交付的成果价值(通常体现为不断增长的合同规模);二是你是否在获得越来越多的产品杠杆去放大那个成果。换句话说,每个客户的合同会越来越大,因为你在交付越来越有价值的成果,而好的产品让 FDE 不必每次都再拉三个工程师进来。海外独角兽

这与标准 SaaS 截然相反:SaaS 追求"为每个客户做的工作越来越少、合同规模不变";FDE 追求"合同规模越来越大、定制化程度可以不变",因为你做的是越来越有价值的工作。底层那个高度可定制的通用产品(如 Palantir Ontology)正是让这一切成立的杠杆。

防止 FDE 变成外包团队的 7 个机制

最危险的组织模式是:销售承诺一堆定制,FDE 疯狂救火,产品团队不吸收。健康的组织会用机制把"产品化"固化下来。

1
Productization review

每个项目结束必须判断哪些要产品化。

2
Reusable asset quota

每季度强制沉淀连接器、模板、eval、playbook。

3
Field RFC pipeline

FDE 可以直接向产品团队提交 RFC,让现场反馈有正式入口。

4
Custom code sunset plan

定制代码必须有维护和替代方案,避免无限堆积技术债。

5
Scope governance

销售不能无限承诺 FDE 定制,scope 要有治理。

6
Deployment metrics

不仅看收入,也看复用率与部署效率。

7
Rotation

FDE 和核心产品工程师定期轮换,防止现场与产品割裂。

成熟的现场小队不是孤胆英雄,而通常包含 FDE lead、FDSWE / full-stack、applied AI / ML engineer、technical deployment lead / strategist、solution architect 或 cloud specialist、customer success / adoption owner,必要时再加 security / data engineer / PM。这套组织模式的原型,来自 Palantir 的 Echo / Delta 起源;而它在产品组织里如何与 PM 协作、避免被当成"万能定制团队",见 FDE 对各岗位的价值