第二课　先别招FDE：用一张二维图判断是否真的需要

平台不会自动变成业务结果

Bai用Palantir的Foundry解释产品与结果的距离。平台可以提供数据组织、本体和应用构建能力，但企业不会因为“拥有一个平台”就自然得到结果。有人必须把客户的流程、数据和目标映射到平台上，搭出真正可运行的解决方案。

Foundry对一家企业的承诺，大致可以拆成三层。第一层是把散落在不同系统里的数据集中起来；第二层是建立ontology，把“表一、表二、表三”变成仓库、产品、设备、订单等业务人员认识的专有名词；第三层是在这些对象之上构建应用。对工程师而言，这三层已经构成一套能力很强的平台，但一位消费品公司的负责人听完以后仍会问：它能不能提高门店铺货率？能不能减少缺货？能不能让销售更快找到问题？

这不是客户“不懂技术”，而是买方与卖方衡量价值的单位不同。平台团队谈数据模型、计算和应用框架，业务负责人谈销量、吞吐量、成本和风险。客户也不应该为了证明自己配得上软件，先招聘一支平台工程团队，再花几个月学会供应商的内部概念。Bai把这部分额外投入称为客户承担的“培训税”：客户先为平台付费，再为培养会使用平台的人付费，最后才有机会构建真正想要的东西。

Palantir的解决办法，是不把产品和服务分开卖。客户既不是买一张软件许可证后独自研究，也不是按人天租一队咨询顾问，而是购买一个业务结果。供应商暂时“借”给客户一批已经熟悉平台的工程师，他们进入业务环境、理解问题，再用Foundry搭出方案。Bai把这种体验比作高级餐厅：顾客不需要研究厨房设备和烹饪流程，服务人员的责任是理解需要，并把最后的体验送到桌上。

这也解释了Palantir式模式与传统咨询的差别。客户既不是购买一套拿来即用的固定成品，也不是按人天购买完全从零写起的软件项目；它购买的是建立在共享平台之上的业务结果。FDE处于中间：用平台已有能力完成大部分工作，再针对客户环境做必要延伸。

Bai还用合同价值说明这种模式为什么值得付出昂贵的人力。他在演讲中引用了一组近似的公开市场比较：普通上市SaaS公司的平均客户合同价值很少达到几十万美元，而Palantir的大型客户合同可以高出一个数量级。具体数字会随统计口径和时间变化，但方向很清楚——当客户购买的是与核心经营直接相关的结果，而不只是若干账号时，合同可以覆盖高强度的工程投入。FDE不是免费附赠的“白手套服务”，而是产品定价和进入市场方式的一部分。

一张2×2的判断图

Bai提出两个维度。第一，产品本身是简单成品，还是技术复杂的平台；第二，买家和用户是否具备足够技术能力。图中的GTM是go-to-market，指产品怎样被客户发现、购买、部署并持续使用；DevRel是developer relations，即通过文档、示例、社区和技术沟通帮开发者用好产品。

技术产品卖给技术用户时，开发者关系、解决方案架构和清晰文档可能已经足够；简单产品卖给非技术用户，可以依靠传统SaaS实施；简单产品卖给技术用户，往往更适合自助。最需要FDE的是左上角：产品复杂，用户却不以软件工程为本职。

GTM与DevRel都能缩短产品与客户的距离，但不一定像FDE一样对客户的生产结果持续负责。

Bai给了几组便于辨认的例子。GitHub是代码托管与协作平台，Datadog是监控应用与云基础设施的可观测性平台；它们本身相当复杂，但主要用户是开发者、运维人员和CTO，他们的本职工作就包括吸收这种复杂度，供应商可以通过文档、开发者关系和解决方案架构帮助他们。Rippling主要管理人事、薪酬和企业IT，Jira用于追踪工作项与软件项目，Slack是团队消息与协作工具。它们也可能有丰富配置，但面向的是更广泛的业务用户，核心交付形态仍是可配置成品，而不是要求客户在底座上开发一个新应用。

Palantir落在最困难的象限：它把高度可塑的应用平台卖给不以软件开发见长的企业。大型科技公司本来就有强大的工程团队，未必需要外部平台替它们构建内部应用；石油、制造、消费品等行业拥有深厚业务能力，却不一定储备同等规模的软件人才。Bai开玩笑说，油气公司的“pipeline”首先是输送原料的管道，而不是数据管道。客户真正缺少的，正是把业务知识和平台能力接起来的人。

AI让更多公司进入这个象限。Agent平台越来越通用，可以连接多种工具、重写工作流、处理自然语言政策。它们“能做很多”，却因此更难直接拿来即用。银行、制造、医疗或财务用户了解自己的业务，却不一定知道怎样设计Agent、工具权限、评测和异常处理。

这也是Bai对FDE在2026年突然升温的解释。他不认为全行业只是迟了二十年才发现Palantir的做法高明。更根本的变化是，AI让几乎每一套软件都获得了某种“可编程性”：模型可以理解自然语言、调用工具、生成代码，并根据客户上下文改变行为。这里的Agentic特性，是指系统能围绕目标调用工具、连续采取多步行动，而不只回答一次问题。平台越具备Agentic特性，就越不像一件边界固定的成品；可定制空间越大，客户越难仅凭产品界面弄清它到底能为自己做什么。过去只有少数平台公司面对的交付难题，开始出现在大量AI公司身上。

没有平台，FDE会变成开发公司

二维图只回答有没有需求，还没有回答商业模式能否成立。Bai给出第二个检查：公司是否已经拥有，或愿意建设一套共享平台。

假设每次交付都从空白代码库开始。第一个客户的收入可以支付构建成本，但第二个客户提出另一套需求，团队又从头开始。随着客户增加，代码库、维护义务和人员数量线性增长，毛利被长期支持吞噬。公司名义上卖产品，实际上经营的是项目制开发。

Bai把边界说得很直白：如果每名FDE都从零开始为客户写一套独立软件，这家公司拥有的不是FDE团队，而是一家开发外包公司。开发公司完全可以盈利，问题在于它与软件平台的经济模型不同。每个新项目会带来新的代码库、部署方式和知识孤岛；几十个客户之后，工程师要同时理解几十个仓库，维护成本会先吞掉利润，再吞掉团队的耐心。

可持续模式需要“原语”（primitives）：认证、数据连接、工作流、策略、评测、界面组件等可组合能力。Bai举了一个示意比例：约60%的能力来自共享平台，约40%按客户场景组合和扩展。这个比例不是行业标准，重点是定制必须站在共用底座上。

“原语应该做多大”是现场问答里最实际的问题之一。做得过粗，FDE只能在一个几乎完成的应用上改颜色和字段，遇到新行业就无能为力；做得过细，工程师仍要从大量低级组件开始拼装，平台没有节约多少工作。答案取决于客户的相似程度：如果场景高度一致，平台也许可以预先完成六成甚至更多；如果客户跨度很大，就需要更细的配置和工具。

Bai用AWS作类比。企业当然可以购买机架、接入网络、自己维护硬件，但云平台把计算、存储、数据库等重复问题封装成服务。DynamoDB是AWS全托管的无服务器NoSQL数据库；NoSQL泛指不以传统关系表结构为唯一组织方式的数据库。使用者不用自己安装、打补丁和扩容数据库服务器。DynamoDB不替客户决定最终应用，却让客户无需重新发明数据库。FDE平台也需要找到自己的“DynamoDB”：它们不是最终方案，却是每个方案都会依赖、由平台统一维护的可靠积木。

这带来一个很实用的投资顺序。公司不能因为已经招到能赚钱的现场工程师，就一直推迟平台建设。越早获得客户，越容易被短期交付牵着走；如果没有明确预算把重复部分抽回平台，团队会在收入增长的同时积累更快的维护负债。FDE人数增加不是平台成熟的替代品，反而应该让共性更快浮现。

面向企业客户的B2B（企业对企业）创业公司在产品尚未成形时，通常会找几家设计合作伙伴。双方都承认答案尚不清楚：客户提供问题、数据和高频反馈，创业公司投入创始人和工程资源，共同找出有价值的产品。多数公司把它视为从零到一的临时阶段，等产品稳定后便转向标准销售。

Palantir更激进的假设是：为什么设计合作只能发生在创业早期？大型企业的问题同样会变化，通用平台也不可能预先知道每个行业的所有工作流。FDE就是把设计合作保持到企业规模。这里真正需要扩张的不是为每个客户永久养一支独立项目组，而是发现—交付—抽象的循环。每个新客户既贡献收入，也帮助平台看见下一组应该产品化的能力。

什么留下，什么回到产品

FDE在现场写出的东西可以分两类。

第一类真正属于客户：独有的业务规则、专用数据映射、内部审批链、品牌语言。这些内容留在客户空间里，但仍要有测试、版本和维护责任。

第二类是多个客户都会遇到的能力：某种连接器、权限模式、评测框架、配置界面或工作流原语。这类内容应该迁回核心平台，由产品团队维护。如果它长期停留在客户分支里，公司就错过了复利。

判断的难点在于，共性不一定在第一次出现时就显而易见。FDE需要记录需求形状、比较不同部署，并与产品工程保持短反馈周期。

第一次出现的需求通常只能被称作“客户特例”。第二次出现时，团队会发现两家客户使用不同术语，但底层动作相似；第三次出现时，才可能确认它是一项平台能力。过早抽象会把偶然差异固化进产品，过晚抽象则会让多支现场团队重复造轮子。FDE的产品判断，正是在这两种成本之间选择时机。

Bai在问答中给出的原则很简洁：真正只属于一个客户的东西留在客户侧，能够一般化的东西最终应进入平台。但“最终”不等于“立即”。现场代码可以先作为探针，证明问题真实存在、方案确实有效，再由核心团队决定稳定接口、兼容范围和长期维护责任。

别让客户只认识一个人

深入现场带来另一种风险：关键知识集中在一名FDE身上。这个人知道客户内部缩写、历史妥协、谁拥有批准权，也知道系统里哪些“临时”代码不能动。一旦离开，团队面对的是一片没有地图的生产环境。

Bai建议用结对方式降低风险。两个人不必全程投入相同工时，但重要会议、架构与决策至少有第二人理解；再配合共享文档、代码审查和轮换，让客户关系从个人英雄变成组织能力。

结对还有一个不那么明显的作用：阻止现场共识变成未经审视的事实。长期驻在一个客户里的FDE，很容易接受客户自己的术语和历史妥协。第二名工程师既是备份，也能追问“这真是行业必需，还是这家公司恰好如此？”这种对照正是把客户特例提炼为产品原语所需要的距离。

当然，不是所有公司都应该建立FDE团队。Bai反复强调要问“是否必须”，而不是“是否想要”。如果产品面向技术用户，可以优先建设开发者关系和开发者教育；如果是边界清楚的传统SaaS，标准销售、实施和客户成功可能更高效。只有当公司必须把复杂、可塑的技术卖给非技术买家，并且愿意建设共享平台时，FDE才是合理的进入市场方式。

他的收束非常朴素：FDE“不过是一个面向客户的软件工程师”。这句话不是把工作说轻，而是在提醒公司别用神秘光环掩盖基本要求——仍然要写可靠软件，只是这名工程师必须把客户结果一起放进工程边界。

所谓理想画像，也因此不需要神秘化。候选人首先应该达到公司对软件工程师的技术标准；其次，团队要相信他能够进入客户会议，承认不知道的事情，理解非技术语言，并在商业压力下保持工程判断。行业知识、咨询技巧和产品直觉可以继续培养，但如果公司为了“善于面对客户”而降低工程门槛，平台很快会用维护事故收回这笔账。

确定公司需要FDE，只解决了组织设计问题。工程师真正进入客户之后，面对的往往不是清楚的问题，而是一份已经写好的解决方案。下一课从一次失败的数据库设计和一份47页需求文档开始，讨论怎样越过客户给出的答案，找到工作真正卡住的地方。