FDE 能否规模化，取决于共用平台而不是工程师人数
整理 Kevin Bai 对前线部署工程的判断框架，说明何时需要 FDE、共用平台如何承接定制工作，以及扩编前必须付出的维护成本。
你把一套要在上面开发才能用的平台卖进企业，合同签了，第一场导入会议也开了。投影屏幕上却只有一张空白的工作流程图。客户知道要改善商品上架率或销售吞吐量，却不知道该怎么把平台组成可用的方案。
眼前的问题是交付边界。当客户买得起平台，却没有工程能力把它变成成果时，供应商应该交付多少定制化，又要如何避免每个项目变成新的维护负债？
FDE 交付的是平台上的客户成果
FDE 是 Forward Deployed Engineering 的缩写，指工程师直接和客户合作，在现有软件平台上完成客户需要的方案。Kevin Bai 在演讲结尾把这个角色浓缩成一句话：“面对客户的软件工程师”。公司必须愿意用软件工程师的标准聘用这样的人，也愿意让他们直接面对客户。
本文整理的是 AI Engineer World’s Fair 2026 的演讲 Forward Deployed Engineering 101。官方页面记录的片长是 17 分 48 秒。Bai 在开场自我介绍时说明他任职于 Anthropic 的 applied AI 团队，先前是 Rippling FDE 团队最早加入的成员，更早以前任职于 Palantir。这些经历决定了他的观察视角；本文讨论的是这场演讲，不是 Anthropic 目前的工作。
Bai 在 3:03 到 3:35 说明 FDE 的交付物。客户同时取得软件与工程服务，最后验收的是建立在平台上的商业成果。工程师要理解客户的业务，再用平台完成应用、工作流程或解决方案。本文会用 GTM（go-to-market）这个词汇，指公司用什么方式触及客户、完成成交并持续服务。
产品复杂度要和买家能力一起看
Bai 借用 Punnett square（生物学用的 2×2 对照表）说明 FDE 的适用条件。两个轴分别是使用产品需要多少技术能力，以及买家能不能消化这份复杂度。他在 4:03 到 5:15 谈了其中三种组合。
| 产品与平台 | 买家或用户 | 复杂度由谁处理 | 演讲中的判断 |
|---|---|---|---|
| GitHub、Datadog 这类技术产品 | CTO、CIO、软件工程师 | 技术用户自行学习与操作 | 不需要 FDE |
| Rippling、Jira、Slack 这类可配置工具 | 非技术买家与用户 | 用户通过设置完成工作 | 不需要 FDE |
| 需要在其上开发的技术平台 | 非技术业务买家 | 供应商派工程师完成客户方案 | 适合评估 FDE |
这张表是 Bai 在演讲里的分类，不是对这些产品完整能力的评测。演讲也没有讨论第四种组合，本文因此不自行补上第四个象限，也不把推测当成讲者的结论。
关键落在第三行。买家需要的结果明确，却没有能在平台上开发的工程团队。供应商若只交出工具，客户还得自行招聘、培训与管理工程师。Bai 在 6:00 形容 FDE 是把熟悉平台的工程能力借给客户。
共用平台把定制需求限制在可维护范围
FDE 会写定制代码，但不从空白项目开始。Bai 在 8:42 到 9:05 说，工程师应在现有的共用平台能力上组装应用与工作流程。这些能力由产品团队共同维护，客户方案只处理差异部分。
Foundry Ontology 是演讲中唯一点名的例子。Palantir 官方文档 将 Ontology 描述成位于数据集、虚拟数据表与模型之上的操作层。它把数据映射成业务对象、属性与关系，也提供动作、函数与动态权限。FDE 因此可以直接使用已维护的数据与操作能力，不必为每个客户重建同一套基础。
定制工作仍要有边界。Bai 在 16:10 到 16:48 提出一个简单原则：只服务单一客户的行为留在该客户的实现；能服务多个客户的能力，长期应回到共用平台。演讲没有提供“几个客户算可共用”的数字，这个门槛仍要由产品团队决定。
把 FDE 当成人力外派会看错成本结构
一句常见但不准确的说法是：“FDE 就是把工程师派到客户那里接活。”Bai 在 8:13 到 8:52 直接画出界线。每位工程师若替每个客户从头搭建一套系统，公司经营的是开发服务，而不是他所说的平台型 FDE。
真正改变成本结构的是定制代码共享了多少已维护的能力，而不是工程师坐在哪里。没有平台时，每张新合同都带来另一套依赖包、部署流程与支持责任。演讲用“工程师不想学 55 个 repo”形容这个维护局面，接着指出维护成本会侵蚀损益。
同样叫 FDE，底层平台会改变工程师每天维护的东西。
演讲中的财务数字也不能直接证明这套模式的获利能力。Bai 在 6:39 到 7:07 以 ACV（average contract value，平均合同价值）比较几家公司。他口头列出 Palantir 400 万美元、ServiceNow 120 万美元与 Workday 60 万美元，并用了“上次查看”与“印象中”这类限定语。官方校订稿 明确注记这些数字没有测量日期、计算方式或独立排名。它们只能说明讲者的商业论证，不能当成一致口径的公司比较。
平台只控制维护成本，不能消除它
即使有共用平台，仍然要维护客户方案。Bai 在 10:38 到 11:12 把平台列为组建 FDE 团队的必要条件，同时强调就算平台健全，维护负担仍然可观。平台能减少重复建造，不能让客户差异消失。
知识分散是第二项成本。在 15:05 到 15:29 的问答中，Bai 建议让多位 FDE 共同参与项目，避免全部上下文集中在一个人身上。团队要为交接、支持与建立共同理解保留时间。
人才条件也不会因为角色贴近客户而降低。Bai 在 16:59 到 17:25 对理想人选的要求有两项：通过软件工程师的招聘标准，以及让公司放心把客户沟通交给他们。这代表 FDE 编制不能直接用售前或客服的人力替换，招聘与培养方式都要覆盖工程与客户沟通。
两道门槛决定公司需不需要 FDE
Bai 在 9:50 到 11:12 提出两道门槛。第一道是公司是否必须把技术复杂的产品卖给非技术买家。第二道是公司是否已经有共用平台，或愿意投入资源建设一个。
| 第一道：产品与买家的缺口 | 第二道：共用平台 | 判断 |
|---|---|---|
| 存在 | 已有，或确定要投资 | 可以评估小规模 FDE 团队 |
| 存在 | 没有，也不准备建设 | 暂停扩招，否则定制工作会变成各自维护的项目 |
| 不存在 | 不需判定 | 技术买家可由开发者关系（DevRel）团队支持；可配置产品可沿用一般销售与导入流程 |
AI 没有取消这两道门槛。Bai 在 11:28 到 12:35 明确把一段话标注为个人假说。他认为 AI 降低了写代码和制作定制软件的难度，也让更多平台具备可定制能力。演讲并未提供跨行业数据可以证明“几乎所有平台”都会走向同一方向。本文只把 AI 当成重新检查两道门槛的理由，不把它当成组建 FDE 团队的充分条件。
用一张表跑一次 FDE 决策
这份推导流程尚待验证。它能排除明显不适用的情况，不能估算人力、合同毛利或部署周期。
先把演讲中的三类产品代入两道门槛，结果如下：
| 例子 | 产品需要开发 | 买家能自行吸收复杂度 | 有共用平台 | 推导结果 |
|---|---|---|---|---|
| GitHub、Datadog | 是 | 是 | 不需判定 | 技术型 GTM，不需 FDE |
| Jira、Slack | 以配置为主 | 否 | 不需判定 | 一般销售与导入，不需 FDE |
| Foundry 与非技术行业买家 | 是 | 否 | 是 | 符合 FDE 的两道门槛 |
要套用到自己的公司，就拿最近一个企业销售机会，把下面五个字段填完。只写已经知道的内容，空白字段本身就是下一步的调查工作。
| 字段 | 要填的内容 |
|---|---|
| 客户成果 | 客户用什么业务结果验收，不写产品功能名称 |
| 开发需求 | 这个结果是否需要在产品上写代码，还是设置即可完成 |
| 客户能力 | 客户是否具备能完成并维护这段开发工作的工程团队 |
| 共用能力 | 数据模型、权限、动作与部署方式中，哪些由平台集中维护 |
| 长期归属 | 客户特有行为留在哪里，可共用能力由哪个产品团队接手 |
产品需要开发、客户缺少工程能力，而且共用能力已经存在时，才进入 FDE 的小规模试点。前两项成立但平台栏仍是空白时，先定义平台投资与维护责任。产品与买家之间没有能力落差时，沿用现有 GTM 方式会更直接。
我的判断
上面的逐字稿、平台文档与两道门槛都可以核对；接下来是我的判断，现有证据不足以证明它能套用到所有 B2B 软件公司。我把 FDE 视为产品架构与 GTM 的共同决策，工程师人数只是这项决策之后的编制结果。
如果产品团队没有定义哪些能力集中维护、客户差异留在哪里，以及前线需求如何回到平台，先招聘 FDE 只会增加客户项目的分支数。相反地，平台边界清楚之后，FDE 才能把工程时间用在理解业务和组合方案，而不是重建基础能力。
AI 让代码生成得更快，却没有替公司决定支持责任由谁承担。这也是产品架构必须和 GTM 一起设计的原因。定制化变便宜时，公司更需要说清楚哪些程序由谁长期维护。
先验证交付缺口，再开岗位
当客户买得起平台，却没有工程能力把它变成成果时，供应商应该交付多少定制化，又要如何避免每个项目变成新的维护负债？
FDE 可以把交付延伸到客户成果，但定制代码要建立在共用平台上。只服务单一客户的差异留在该客户的实现，可重用的能力则回到平台团队。这条边界决定公司交付的是可维护的方案，还是一批各自演进的项目。
挑一个最近的企业销售机会，填完上一节的五个字段。只有产品与买家确实存在能力落差，而且共用平台能承接重复工作时，FDE 才是需要验证的下一步。
延伸阅读
- Forward Deployed Engineering 101：官方页面提供校订稿、完整时间戳与演讲提到的资源，适合逐句核对本文的分类与限制。
- Palantir Ontology overview：文档列出 Ontology 的对象、关系、动作、函数与权限，可具体理解 Foundry 提供哪些共用平台能力。
- What Is a Forward Deployed Engineer?：Kevin Bai 的补充文章把 FDE 拆成顾问、产品经理与工程师三种工作，并强调这个角色应该用在高价值且定义模糊的问题上。