先说结论：两个前提缺一不可
公司要不要组建FDE团队（Forward Deployed Engineer，前向部署工程师，派驻客户现场并对业务结果负责的岗位）？判断是两步检查：先用”产品复杂度 × 用户技术能力”的 2×2 图确认需求存在，再确认公司拥有或愿意建设可复用的共享平台——两个前提缺一不可。方法来自 Anthropic 技术团队成员 Kevin Bai 在 2026 年 6 月 30 日 AI Engineer World’s Fair 的演讲《Forward Deployed Engineering 101》；他曾在 Palantir 做 FDE，后在 Rippling 从第一名成员组建FDE团队，约一年扩展到 25 人。岗位背景见《FDE 是什么岗位》。
一张2×2图：你的产品落在哪个象限
横轴是用户技术能力，纵轴是产品复杂度，只有左上角需要 FDE：产品复杂，用户却不以软件工程为本职。
| 用户技术能力低 | 用户技术能力高 | |
|---|---|---|
| 产品复杂度高 | FDE 核心区：Palantir 把高度可塑的平台卖给油气、制造、消费品企业 | 技术 GTM / DevRel：GitHub、Datadog 靠文档、开发者关系、解决方案架构 |
| 产品复杂度低 | 传统 SaaS 交付：Rippling、Jira、Slack 这类可配置成品 | 自助 / 产品主导增长：开发者自己注册、试用、集成 |
GitHub 和 Datadog 的用户是开发者、运维和 CTO，本职就包括吸收复杂度。Palantir 落在最困难的象限，Bai 开玩笑说，油气公司的”pipeline”首先是输送原料的管道，其次才是数据管道——客户缺的是把业务知识和平台能力接起来的人。模式拆解见专文。
五个判断问题
图只给方向，组队前再过五个问题，任何一个答不上来都应暂缓。
- 产品复杂到客户无法自行配置吗？ 消费品负责人听完平台演示仍会问能不能提高门店铺货率——Bai 把客户学会平台的额外投入称为”培训税”。
- 买方缺工程能力吗？ 平台团队谈数据模型，业务负责人谈销量、成本和风险，双方衡量价值的单位不同。
- 单客价值覆盖高触达吗？ Bai 演讲中引用的公开市场比较：普通上市 SaaS 平均客户合同价值很少达到几十万美元，Palantir 大型客户合同可高出一个数量级（数字随口径变化）。行情见FDE 薪酬与前景。
- 有可复用平台吗？ 经济前提，下一节算账。
- 现场知识能改变路线图吗？ FDE 的价值在”发现—交付—抽象”循环，现场反馈进不了产品，投入就只剩交付本身。
经济账：没有平台的FDE会变成开发外包公司
没有平台原语的 FDE 团队商业上不可持续：每个客户一套独立代码库，维护义务随客户数线性增长，毛利被长期支持吞噬。Bai 说得很直白——如果每名 FDE 都从零开始为客户写一套独立软件，这家公司拥有的不是FDE团队，而是一家开发外包公司——几十个客户之后，没人看得住几十个代码库。
可持续模式需要”原语”（primitives）：认证、数据连接、工作流、策略、评测、界面组件。Bai 给的示意比例是约 60% 能力来自共享平台、约 40% 按客户场景扩展——他强调这是示意比例，非行业标准。他类比 AWS 的 DynamoDB：全托管、不替客户决定最终应用，却让人无需重新发明数据库——FDE 平台也要找到自己的”DynamoDB”积木。所以不能招到能赚钱的现场工程师就推迟平台建设，没有预算把重复部分抽回平台，维护负债会比收入涨得更快。
资产回流：第三次出现的共性才进平台
回流规则一句话：客户特有配置留在客户侧，共性能力在第三次出现时迁回平台——过早抽象把偶然差异固化进产品，过晚抽象让现场团队重复造轮子。独有业务规则、数据映射、审批链留在客户空间，仍要有测试和版本；连接器、权限模式、评测框架这类多客户共需的，迁回核心平台。共性第一次出现只是”客户特例”，第二次发现术语不同但底层动作相似，第三次才确认是平台能力；现场代码先作探针，证明问题真实、方案有效，再谈迁移。
组织设计：结对、对照与三种团队形态
深入现场的最大组织风险是关键知识集中在一个人：缩写、历史妥协、批准权都在他脑子里。Bai 的对策是结对：两人不必投入相同工时，但重要会议、架构与决策至少有第二人理解，辅以文档、代码审查和轮换。招聘底线朴素：先达到软件工程师的技术标准，再谈面对客户。能力路径见如何成为 FDE。
| 形态 | 适用阶段 | 优点 | 主要风险 |
|---|---|---|---|
| 创始人型 | 客户少、产品未定型 | 最强工程师直接部署，学习极快 | 英雄依赖、无边界承诺 |
| 专门FDE团队 | 客户与模式增多 | 责任连续，方法与平台接口明确 | 与产品工程分裂成”接需求”和”做正事”两类人 |
| 全工程前向化 | 自助能力成熟 | 产品工程师轮转进现场，反馈直接 | 路线图被高声量客户绑架 |
Bai 的收束是 FDE “不过是一个面向客户的软件工程师”；形态之间可以移动，标准是产品成熟度、客户复杂度和知识回流速度。
九道关口：把判断写成可审阅的产物
组队之后，用九道关口管理每次部署，每道关口有明确产物和责任人。五道最值得展开：
- 选客户。 优先选同时满足三点的客户：问题价值高、愿意开放真实流程与数据、需求可能代表更广市场。产物：客户选择简报。
- 利益相关者地图。 关键是区分”提出需求的人”和”承受工作的人”——销售要仪表板，周一早上操作的人也许只要一条告警。产物：逐人的目标、权限与替代办法。
- 两张流程图。 一张画官方流程，一张画真实流程（异常、绕行、个人记忆），要问”出错时怎么办""上次例外什么时候”。产物：现状地图。范围追问清单见范围界定专文。
- 结果合同。 可验证结果要包含对象、行为、基线、目标、时间和边界，并写反指标（自动解决率升但投诉也升，不算成功）。产物：各方签认的一页成功定义。
- 复利指标。 至少看四组：客户结果、交付速度、产品回流、组织韧性。
其余四道（最短行动闭环、人机控制面、生产就绪清单、分类回流账本）分别管范围压缩、自动化等级、回滚与人工接管、资产四篮子分类。
收尾只有一个问题：第十次部署是否比第一次更快、更稳、更少依赖特殊人物？ 答案长期为否，增长只是项目数量增加。
常见问题
什么样的公司适合组建FDE团队？
同时满足两个条件：产品复杂到非技术买家无法自行驾驭，公司拥有或愿意建设可复用平台；面向开发者的产品先做 DevRel，传统 SaaS 用标准实施。
没有共享平台能先做FDE吗？
能开工但不可持续：每客一套代码库让维护义务随客户数线性增长，毛利被长期支持吞噬，实际经营的是开发外包。尽早建预算，把重复部分抽回平台。
FDE团队和开发外包团队怎么区分？
看代码落在哪：外包每个项目从空白代码库开始；FDE 在平台原语上组装，客户配置留现场、共性回平台。再看第十次部署是否比第一次更快更稳。