#视频文稿 #FDE #企业软件 #AI工程
说明：本文基于 AI Engineer 官方校正英文逐字稿完整翻译，并按语义合并为段落级时间戳。口头填充词和机械重复已适度清理，现场互动、问答、数字及案例均予以保留。文中的商业数据和判断均为 Kevin Bai 在演讲中的陈述，未作独立核验。
Kevin Bai 解释了前沿部署工程（FDE）如何把复杂技术平台与工程服务结合成客户可购买的业务结果，并指出企业只有在必须向非技术买家销售复杂产品、且已有或愿意建设共享平台时，才适合建立 FDE 团队。
[00:00] 【欢快的音乐】好，我们开始。
[00:16] 非常感谢 Basil 的介绍。现场的各位观众，大家好，也非常感谢大家今天来参加。我叫 Kevin。严格来说，我们并没有什么职级，所以我是 Anthropic 应用 AI 团队的一名技术人员。在此之前，我加入 Rippling，协助建立他们的 FDE 职能。我是加入该团队的第一个人，一年之内，我们把团队扩大到了大约 25 人。
[00:40] 这件事挺酷的。再之前，我在 Palantir 做过不少事情。不过，一串公司名字其实没那么有意思，对吧？因为我们今天讨论的是一种职能。我希望大家来这里，是想了解前沿部署工程。如果你是来听评测，或者想看小猫视频，那大概应该去隔壁房间，而且这些话题我也没资格讲。
[01:05] 今天我想给大家讲一堂“前沿部署工程 101”。我会带大家回顾这个岗位的历史、这项职能的本质，以及 Palantir 为什么选择用 FDE 作为市场进入方式，然后再延伸到你们可以怎样把它应用到自己的组织和业务中。如果时间允许，最后我也很愿意回答任何问题。听起来怎么样？
[01:36] 观众：好。Kevin：好吗？这也太没精神了。听起来怎么样？观众：好！Kevin：这就对了。天啊，这是会议，又不是葬礼，打起精神来！好，我们先从宏观上看，Palantir 是做什么的？Palantir 是一家技术公司，打造了一个名为 Foundry 的技术平台，也就是软件平台。
[01:57] Foundry 能让任意规模的组织把所有数据集中到一个地方，建立一套本体。它的意思是，从数据中创建出具有业务含义的专有对象。这样一来，如果你拥有多个仓库，面对的不再是表一、表二、表三，而是一张关于仓库的统一数据表，作为单一事实来源。在此基础上，Foundry 还能让公司构建应用。
[02:33] 如果我向某位行业领袖这样解释，对方可能会说：“不错，你把我的数据整理好了，但这对我的实际业务有什么用？”如果只销售技术，问题就出在这里。还有一个很有意思的地方：作为应用构建平台，Foundry 成功与否，取决于客户能不能用好这款软件。
[02:52] 因此，这里还有一笔巨大的额外成本。客户不仅要花钱投资这个平台，还必须培训自己的员工，让他们熟练使用平台；只有到那时，他们才能真正构建东西。
[03:03] 这是一种非常糟糕的生意方式。我们很快意识到，不应该只卖服务或只卖产品，而应该把两者合在一起销售。客户买的既不是一套软件，也不是某个人的一段工时，而是一个结果。你派出非常聪明的人，去理解客户业务的本质，在 Foundry 平台上为客户构建解决方案，最终交付的就是那个业务结果。
[03:35] 因为如果你是行业领袖，比如在消费品行业工作，你在意的是争取更多货架陈列位置，或提高销售吞吐量。你并不真正关心数据是怎么组织的，也不应该关心，那只是实现细节。那么，这种把工程师派到前线的荒唐想法究竟从何而来？我敢肯定，在座各位只要熟悉软件工程师，就会知道，包括我自己在内，我们可能是最不应该面向客户的一群人。
[04:03] 所以我想把这件事讲得非常清楚。你可以把它想象成一个类似潘尼特方格的二维矩阵，其中两个维度分别是你卖的东西，以及向你购买的人。
[04:15] 如果你销售的是技术性很强的平台或产品，先暂时不谈 Foundry，比如你卖的是 GitHub 或 Datadog，那会是极其复杂的软件。但你的理想客户画像（ICP）是 CTO、CIO，实际用户则是软件工程师。他们能够理解并消化这种复杂性，也能用好产品，因为这本来就是他们工作的一部分。
[04:40] 另一种情况是，你卖的东西没那么复杂，买家也没那么懂技术，这同样没有问题。比如 Rippling、Jira 或 Slack，这些工具或许复杂，但都可以通过配置来使用，并不是让客户在其上继续开发。因此，把它们卖给非技术买家完全可行。
[05:03] 只有像 Palantir 这样处在一种特殊情形中，也就是必须向非技术买家销售高度技术化的产品时，才需要 FDE。那么，从历史上看，Palantir 为什么会处在这种情形？难道 Palantir 不想把事情做得简单一点吗？这是因为 Foundry 本质上是一个应用构建平台，所以对大型科技公司的吸引力自然没有那么大。
[05:26] Google、Meta，以及如今的各类实验室，都拥有优秀的软件工程师，可以自行构建组织所需的任何应用。但是，如果你面对的是一家从事石油和天然气业务的《财富》500 强客户，他们通常没有那么深的软件工程能力。他们的管道可不是数据管道，里面流的更可能是碳氟化合物之类的东西。要让他们充分获得平台价值，你可以相信他们会花时间购买并使用平台，也可以直接说：“我们是这样安排的，会借给你们一些很优秀的工程师，你们不用招聘、录用、管理或想办法留住他们。”
[06:06] 这些工程师不仅受过平台使用培训，还会与你密切合作。这就像你去高级餐厅，服务员会照顾你的各种需求。他们会找出如何解决你的问题，再为你构建软件。这最终成为 Palantir 面向全球《财富》500 强企业的市场进入方式。那么，这种方式的效果怎么样？
[06:31] 我不能只是站在台上说“这太酷了”，再讲一堆细节，所以给大家看几个数字。如果观察《财富》500 强中的上市 SaaS 公司，并用 ACV，也就是平均合同价值来衡量，看的就是任意一位客户会向某个供应商花多少钱。
[06:52] 据我最近一次查看，Palantir 以 400 万美元排第一，接下来是 ServiceNow 的 120 万美元，再下一家我记得应该是 Workday，大约 60 万美元。除此之外，没有一家上市 SaaS 公司的 ACV 能突破 50 万美元。仅从这些数字来看，我会说这种方式很有效。Palantir 现在的估值高得离谱，而员工人数只有几千人。好，那么 FDE 到底是什么？
[07:19] 这种模式究竟是什么，又意味着什么？现场有初创公司的人，或处在创业早期阶段的人吗？有？好，我看到有人举手。那你们应该熟悉“设计合作”这个概念。
[07:30] 初创公司早期，你不知道自己的产品是什么，客户也不知道自己买的是什么。这时你会说：“让我和你紧密合作，弄清楚你究竟需要什么。我会投入自己的时间、精力、技术和资源，你只需告诉我问题的背景，我会为你构建一个非常好的解决方案。”至少在 B2B 领域，大多数初创公司通常都是这样找到产品与市场匹配点的。FDE 基本上就是把设计合作的概念扩展到企业级规模。
[08:01] Palantir 的核心主张是，谁规定设计合作只能存在于公司的早期阶段？为什么不能在企业市场规模化地做这件事？
[08:13] 在座一些非常聪明、观察敏锐的人可能会说：“Kevin，你不能在企业市场这么做，因为根本维护不了。如果为每个客户定制一套东西，你就得同时应付一大堆各行其是的系统，还会积累一堆烂代码。没有工程师愿意来替我工作，因为这些东西无法维护，也没人想学习 55 个代码仓库。”你完全说对了。如果建立 FDE 职能时，每名 FDE 都从零开始构建，那么朋友们，你拥有的不是 FDE 团队，而是一家定制开发公司。
[08:42] 当然，这本身没有错，定制开发也可以是非常赚钱的生意。但 FDE 项目之所以不同，是因为他们在平台之上构建，绝不会从零开始写软件。平台已经提供了一组原语，他们可以把这些原语组装成应用、工作流或解决方案，为客户创造极高的价值。
[09:05] 这才是其中真正关键的要素。否则，你只是在一遍又一遍地从头造轮子。很快，维护成本就会在损益表（P&L）上把你吞噬，前提是你的工程师还没有先全部辞职。
[09:20] 好，我感觉刚才一口气说了太多。大家大致明白我在讲什么了吗？有吗？看到有人举手。很好，太好了。天啊。
[09:29] 我的进度比预想中快。现在你可能会说：“Kevin，故事挺有意思，你也给了一些框架，但我来这里不只是为了听你讲话。我想知道怎样把它应用到自己的组织和业务里，怎样把它带回团队。”那么，该怎么做？
[09:50] 首先，也是我给每个思考前沿部署工程的人最重要的建议，认真问自己：“我需要 FDE 职能吗？”问的是需不需要，而不是想不想要。人们很容易想要流行的东西，也很容易因为其他人都在做，就想做 AI。但你真的需要吗？你的业务中，是否存在某个特殊场景，迫使你必须把技术上很复杂的东西推向市场，卖给非技术买家？如果没有，FDE 很可能不适合你。
[10:25] 如果采用技术导向的市场进入方式，可以通过 DevRel 和一支优秀的开发者互动团队做很多事情。如果做的是较为传统的 SaaS，也可以采用销售驱动的方式。只有在前面所说的特殊情形里，你才需要 FDE，这是第一点。第二点是，我有没有一个平台？换个说法，我愿不愿意投资建设一个平台？
[10:49] 我可以向你保证，无论让工程师直接为你赚钱听起来多么诱人，如果他们不是在一个拥有若干共享原语的平台上构建，后面都会非常痛苦。即使已经拥有稳健的平台，团队承担的维护负担也大到难以强调，更不用说没有平台的情况了。
[11:12] 所以，从 FDE 入门的角度，我非常建议大家思考两个问题：我是否必须向非技术买家销售复杂的东西？我是否拥有一个能让 FDE 在其上构建的平台？
[11:28] 接下来谈谈 AI，毕竟现在是 2026 年。从 Palantir 大约在 2004 或 2005 年进入市场到现在，发生的变化是，人工智能让构建东西、编写代码以及为客户开发复杂的可定制软件都变得非常容易。现场有多少人在做“面向某领域的智能体”？保险、法律或其他领域，对吧？这个问题我甚至不需要看有多少人举手。
[12:02] 变化并不是全世界突然意识到 Palantir 的 FDE 模式是个绝佳主意，所以都应该照着做。我个人的假设是，真正改变的是软件行业做生意的本质。如今几乎每个平台都具备智能体能力，这意味着几乎每个平台都可以定制，也意味着你们几乎所有人都会遇到这种情况：客户根本不知道你实际上能做什么。
[12:35] 如果把产品的成败完全交给客户，取决于他们自己的实施能力，我可以向你保证，无论你想向更高端市场销售，还是横向或纵向扩张，这都不会是一条轻松的路。
[12:51] 好，我讲得够多了。接下来非常想听听现场的问题。什么都可以问，只有我目前的工作除外。谢谢大家。【观众鼓掌】有人举手吗？好，那边。
[13:10] 观众：你提到需要共享原语，能否再具体一点？比如这些原语应该细化到什么程度？能不能举个例子？Kevin：这是个非常好的问题。主持人：能先复述一下问题吗？Kevin：可以。问题是，我们谈到了共享原语，那么共享原语应该细化到什么程度，它具体意味着什么？
[13:33] 如果你销售的平台涉及数据模型，那么一个起点也许是，不必每次都从头定义数据模型。不过我得给出一个很像律师的回答：这取决于你具体进入的领域。在很多行业和场景中，你可以采用功能相当完备的原语。
[14:02] 比如，应用本身已经完成了约 60%，人们只需定制剩下的 40%。但在某些行业、领域和特定用例中，这样并不合适，你需要粒度极细的配置能力和工具。
[14:18] 一个大家应该都熟悉的平台例子是 AWS。我相信现场很多人都是非常优秀的工程师。如果你愿意，当然可以买自己的服务器机架，把它们接入网络，再自行维护。但从 20 世纪 90 年代之后，还有多少人真的这么做？在 AWS 内部，它为你提供了一组共享原语，比如 DynamoDB，这样你就不必从头发明一个数据库。不过，这是因为 AWS 要服务极其广泛的客户群，所以答案取决于你的用户群。还有其他问题吗？好，那边。
[14:52] 观众：没有麦克风。我想问，你见过来自两家不同公司的两名 FDE 合作吗？如果见过，这种合作的摩擦如何，会发生什么？
[15:05] Kevin：你的问题是，如果两名或多名 FDE 在一个项目上工作，他们采用什么协作机制。我认为这非常值得鼓励，是一种很好的模式。尤其是为客户做定制工作时，最不希望出现的就是单点故障，也就是只有一个人掌握全部信息，等他去休假，其他人就彻底抓瞎了。
[15:29] 观众：我是说来自两家不同公司。Kevin：两家不同公司？观众：对。比如 AWS 派一名 FDE 做项目，你则从 Palantir 过来。Kevin：你是说在同一个项目上工作，像竞标比拼？观众：对。Kevin：明白，或者说是合作，像合作伙伴？观众：对。Kevin：是的，这种模式也存在。它和引入承包方没什么不同，你必须弄清楚在这种情形下谁扮演承包方的角色。这大致就是理解它的思维模型。好，后面那位。
[15:58] 观众：你好。需要作出某项改动时，决策过程是怎样的？你如何判断这个改动应该发生在平台一侧，还是前沿部署一侧？
[16:10] Kevin：这是个非常好的问题。问题是，哪些工程改动应该进入平台，哪些应该留在前沿部署一侧。任何只为某个特定客户量身定制、独一无二的东西，都应该只存在于那个客户的实现中。
[16:30] 任何可以泛化的能力，长期来看都应该被泛化。刚开始开展 FDE 工作时，你很可能没有多少种原语，但这没有关系，因为 FDE 也是一种很好的前线侦察方式，可以帮助你发现还能建设哪些额外的产品和服务，进一步推动业务成功。我们的时间怎么样？还好吗？哦，不，时间不够了。主持人：最后一个问题。Kevin：好，好，最后一个问题。那边那位。
[16:56] 观众：理想的 FDE 人才画像是什么？Kevin：这个问题太好了。理想的 FDE 人才画像是什么？我最后送给大家一句概括：FDE 无非就是面向客户的软件工程师。因此，这个人首先得是你愿意招进团队担任软件工程师的人，同时，你也要愿意在某种场合或工作中放心地让他直接面对客户。
[17:25] 至于其他部分，就只能边做边摸索了，因为我们的时间已经到了。非常感谢大家。【观众鼓掌】【欢快的音乐】
原始字幕保存于 raw_subtitles/KwhgfwOSToQ.official-transcript.en.md。本稿以 AI Engineer 发布的官方校正英文逐字稿为准，完整覆盖 00:00 至 17:25 的 97 条字幕，网页界面文字未纳入正文。时间戳按自然段保留每段首条字幕的时间，视频总时长为 17:48。