FDE 资料库

外观

组织与商业模式 ​

五种组织模式，以及“服务 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 对各岗位的价值。

来源：https://openfde.net/zh/docs/org-and-business（OpenFDE，抓取于 2026-09-21）。© 2026 OpenFDE · 明确标注的开放内容采用 CC BY-SA 4.0，代码采用 MIT；案例及第三方材料不在上述开放许可范围内，使用须另行授权。