前沿部署工程入门——Kevin Bai(Anthropic,前 Palantir、Rippling 创始 FDE)

• Kevin Bai，Anthropic applied AI 团队的 member of technical staff（他说公司严格来说没有职级头衔，所以人人都叫这个）；此前加入 Rippling 帮他们把 FDE 职能从零搭起来，是团队第一个人，一年做到约 25 人；再往前在 Palantir 做过一堆事。他一上来就把话题从公司拽回职能：「罗列公司名单没什么意思，我们今天要聊的是一个『职能』。」全场议程四件事——角色的历史、职能的本质、Palantir 为什么把 FDE 当成 go-to-market（GTM，进入市场的打法）、你怎么搬到自己的组织里。→ 详细

• Foundry 是一个软件平台，作用是让任意规模的组织把所有数据集中到一处、建立一套 ontology（本体——说白了就是把数据变成「专有名词」：手里不再是「表一表二表三」，而是「仓库」就一张表、它就是唯一事实来源），并在这之上构建应用。→ 详细
• 露怯时刻就是高管那句反问：「不错啊，你把我的数据整理干净了，可这对我的实际业务有什么用？」——纯卖技术卡死在这一句上。→ 详细
• 更麻烦的是一笔隐性税：一个「搭应用的平台」，成败取决于客户能把这套软件用得多好，所以客户不光要花钱买平台，还得再花钱把自己的人培训到熟练——「然后，只有到了那一步，他们才终于能开始做东西。这种做生意的方式糟透了。」→ 详细

• 结论是把两样东西捏成一个：「与其只卖服务，或者只卖产品，不如两个一起卖。」客户买的既不是一套软件，也不是某个人的工时，他们买的是一个 outcome（结果）。→ 详细
• 交付链条是三步：派一批非常聪明的人过去 → 让他们真正搞懂客户业务的本质 → 在 Foundry 这个平台之上给客户搭出解决方案，客户最后拿到的就是那个结果。→ 详细
• 为什么买家吃这一套，他用 CPG（快消品）举例：「你关心的是能不能在货架上拿到更多陈列位，或者销售额的吞吐能不能更高——你根本不关心数据是怎么组织的，你也不该关心，那更像是实现细节。」→ 详细

• 他先承认这想法听着离谱：「只要接触过软件工程师——包括我自己在内——都知道我们大概是最不该直接面对客户的一群人。」于是他画了个二乘二矩阵（他叫它 Punnett square，生物课上那种方格），两个维度是：你卖的是什么 × 买你东西的是谁。→ 详细
• 第一格没问题——技术性极强的东西卖给技术型买家：GitHub、Datadog 都是极其复杂的软件，但 ICP（ideal customer profile，理想客户画像）是 CTO、CIO，用户是软件工程师，「他们是有能力吸收这种复杂度并且真正把它用起来的人，因为这本来就是他们工作的一部分」。→ 详细
• 第二格也没问题——不复杂的东西卖给非技术买家：Rippling、Jira、Slack 这类工具「可能是有点复杂，但它们是『可配置』的，不是让你在上面做二次开发的」，卖给不懂技术的买家毫无毛病。→ 详细
• 只有第三格才需要 FDE：技术性极强的东西 × 完全不懂技术的买家。Palantir 就卡在这一格，而且是被 Foundry 的本质推进去的——它是「搭应用的平台」，天然对大科技公司没吸引力（Google、Meta、各家 AI 实验室都有优秀工程师，需要什么应用自己就搭了），可它要打的偏偏是油气这类世界 500 强：「他们说的『管道』不是数据管道，更可能是输送碳氟化合物之类的东西。」→ 详细

• 面对没有工程深度的客户只有两条路：要么赌他们愿意花时间——不光买下平台还得真把它用起来；要么直接说「方案我给你摆好了，我借给你一批非常优秀的工程师，你不用去招、不用去挖、不用管理、也不用操心怎么留住他们」。→ 详细
• 服务标准用高级餐厅打比方：这批人不只受过训练会用平台，还会「跟你贴身协作——就像你在一家高级餐厅里，服务员会照顾到你的每一个需求那样」，先想办法把问题解决掉，再把软件搭出来。这最后就成了 Palantir 攻打全球 500 强的 GTM 方式。→ 详细

• 按 ACV（平均合同价值）看 Fortune 500 里的上市 SaaS 公司：Palantir 第一，400 万美元；ServiceNow 第二，120 万；Workday 第三，60 万；再往下「没有任何一家上市 SaaS 公司的 ACV 能突破 50 万」。他的结论很朴素：「光看这几个数字，我会说这套打法效果相当不错。」→ 详细
• 顺带一句容易被忽略的人效数据：Palantir 现在的估值「已经离谱到某个程度」，而团队规模「也就几千人」。→ 详细

• design partnership（设计合作伙伴）的原型是创业早期那件事：你自己还不知道产品该是什么样，客户也不知道他们到底在买什么，于是你说「我出时间、出精力、出技术、出资源，你只要把你问题的上下文给我，我就给你搭一个真正好用的方案」——至少在 B2B 领域，大多数创业公司就是这么找到 PMF（product-market fit，产品市场契合）的。→ 详细
• FDE 本质上就是把这套东西放大到企业级。Palantir 最核心的断言只有一句反问：「谁说 design partnership 只能用在公司最初那个阶段？为什么不能在企业级、在规模上照样这么干？」→ 详细

• 他主动把最强的反对意见替听众说出来：企业级根本维护不过来——「如果你给每一个客户都定制一套东西，那你就等着像赶一群猫一样疲于奔命吧，你会攒下一堆烂到家的代码，再也不会有工程师愿意为你工作——因为根本没法维护，没人想去搞懂 55 个代码仓库。」然后他回了一句：你说得完全没错。→ 详细
• 判定线因此非常硬：「如果你搭出来的 FDE 职能是每个 FDE 都从零开始造轮子，那么朋友们，你根本没有 FDE 职能，你有的是一家 dev shop（外包开发公司）。」他还补了一句这没什么不好——「那也是很赚钱的生意」，只是别管它叫 FDE。→ 详细
• 真正的区别只有一条：FDE 是在平台之上做东西，从来不从零写软件。 平台上已经有一整套 primitives（原语/基础构件——预先造好、可反复复用的零件），FDE 只负责把它们组装成某个应用、某条工作流、某个解决方案，而这个方案「对客户来说价值可以高到没有上限」。他把这叫「真正关键的那味配料」。→ 详细
• 不这么干的代价他说得很具体：「否则你就是在一遍又一遍地重新发明轮子，等你回过神来，光维护成本就能把你的 P&L（损益表）吃干抹净——如果你的工程师还没先集体跑光的话。」→ 详细

• 第一问：我是「需要」还是「想要」？ 这是他给每个琢磨 FDE 的人的第一条建议——「想要一个当下正流行的东西太容易了，想要搞 AI 也太容易了，因为别人都在搞。」真问题是：我的业务里是不是真有那么一个特殊角落，让我不得不把一个技术上很复杂的东西 GTM 给一个不懂技术的买家？没有这种处境，FDE 大概率不适合你。→ 详细
• 第二问：我有没有平台，或者愿不愿意投入去建一个？「不管『养一批能替我赚钱的工程师』这件事听起来多诱人，只要他们不是构建在一个有一定数量共享 primitives 的平台之上，你就有得受了。」他强调即便你已经有一个足够健壮的平台，那份维护负担有多重他都没法形容——更别说根本没有平台的情况。→ 详细

• 时间坐标：Palantir 大约 2004 或 2005 年进入市场；到今天，人工智能让「写代码」变得非常非常容易，也让「为客户构建复杂的、可定制的软件」变得非常非常容易——台下做「某某领域的 agent」（保险的、法务的）的人多到他说「这个我都不用看举手」。→ 详细
• 他的个人假说是全场最锋利的一刀：变的不是全世界突然醒悟过来觉得 Palantir 那套 FDE 打法真香，而是「软件行业做生意这件事本身的性质」变了——因为现在几乎每一个平台都是 agentic（智能体化）的，这意味着几乎每一个平台都是可定制的。→ 详细
• 推论直接落到在座每个人头上：「你们几乎所有人都会遇到这样一种局面：你的客户压根不知道你到底是干什么的。」而如果你把产品的成败交到他们手上、交给他们自己去实现的能力，那么无论你想往上打大客户市场（up market），还是想横向、纵向扩张，「这条路绝对不会好走」。→ 详细

本片没有 lightning round，收尾是约 5 分钟的现场问答（他开场说「什么都可以问，除了我现在手上做的工作」）。

Q1 · 共享 primitive 该拆到多细的粒度？（能举例吗）

• 他的回答自嘲是「一个特别像律师的答案：这取决于你做的是什么」。一个可操作的起点：如果你的平台涉及数据模型，那就让用户不必从零定义数据模型。→ 详细
• 两端都成立：有些行业和场景你完全可以提供非常厚实的 primitive，应用相当于已经搭好 60%，客户只定制剩下的 40%；另一些行业这么做根本不合适，你必须提供极其细粒度的配置能力和极其细粒度的工具。→ 详细
• 参照物是 AWS：「你们真想干的话，完全可以自己买一堆服务器机架、接上网、自己维护。但从 90 年代以后，还有几个人真这么干？」AWS 给你 DynamoDB 这类共享 primitive，你就不用从零发明一个数据库——但它之所以拆得这么细，是因为它要服务的客户面极其广。结论：粒度取决于你的用户群体。→ 详细

Q2 · 多个 FDE 一起做一个项目，协作机制是什么？

• 同一家公司的多个 FDE 协作：非常鼓励，是个好模式。尤其做定制工作时，「你最不想要的就是出现单点故障——所有信息都只有一个人知道，他一休假你就抓瞎了」。→ 详细
• 提问者追问的其实是两家不同公司的人在同一个项目上（是比稿式的 bake off，还是伙伴式协作）。他的答案：这种模式也存在，「跟你请一个外包承包商没什么区别——你得先搞清楚在这种局面里谁是承包商的角色」。→ 详细

Q3 · 哪些工程改动该沉淀进平台，哪些该留在前置部署这一侧？

• 规则两句话：凡是为某个客户量身定做、只对他独有的东西，就应该只存在于那一个客户那里；凡是可以泛化的东西，长期都应该被沉淀成通用能力。→ 详细
• 他也回答了冷启动焦虑：刚开始做 FDE 时你手上大概率没多少现成 primitive，但这没关系——「FDE 本身就是一种很好的『探路』方式，帮你发现还可以补哪些产品能力和服务，来进一步支撑业务成功。」→ 详细

Q4 · 什么样的人是最合适的 FDE？（最后一问，也是收尾金句）

• 他留给全场的 tagline：「FDE 无非就是一个『面向客户的软件工程师』。」判据是双重的——这个人你愿意把他当软件工程师招进团队，同时你又敢让他以某种形式直接站到客户面前。「剩下的就得你自己边做边摸索了，因为我们时间到了。」→ 详细