Palantir 创始工程师深度分享：FDE 模式是 Agent 时代的 PMF 范式

01.

到底什么是 FDE？

 Host： 几个月前 Bob 参加了 YC 组织的一个 AI 会议，一个有意思的现象是，他原本以为所有的创始人都会来找他谈论 ChatGPT，但结果所有这些创始人都想和他谈 Palantir 的 FDE。到底什么是 FDE，以及为什么今天 FDE 变得如此重要？

Bob: 不只有那一次会议是这样。在过去一年我为 AI 初创公司提供咨询时，他们中的很多人几乎只关心 FDE 策略是如何运作的。

FDE 通常是一位技术人员，他会驻扎在客户现场，填补产品功能与客户需求之间的差距。

作为创业公司，你首先会有一个产品，然后你去接触一个新客户，并与新客户尝试合作，他们希望你解决的问题是你以前从未解决过的问题。

在这个过程中，你相信只要通过努力就可以为这个特定客户解决特定的问题，并且你会为他们提供一个非常有价值的成果 （outcome）。

所以 FDE 是带着现有的产品，并在产品团队的帮助下，想办法交付那个成果，构建对客户有价值的用例 （use case），以一种对客户真正有效的方式交付你已经构建的软件。

 Host: 复盘一下 Palantir 是如何发明 FDE 这个策略模式的？

Bob: Palantir 刚创立的时候，公司的重点是为情报部门搭建软件系统。这件事的挑战是，我们不认识任何情报工作人员，现实世界生活中几乎没人认识，并且即便我们找到这样一个人，如果询问对方：“你的工作内容具体是什么？” 对方也不可能告诉你的。这倒逼我们必须采取一种在当时非常不寻常的方法来完成工作。

我们是从构建一个 demo 开始做这项任务的，先尝试把那个 demo 展示给情报界的潜在客户、收集反馈。

Palantir 的创始人之一 Stefan Cohen 就做过这件事，他给潜在客户展示 demo，问他们：“你们觉得怎么样？” 对方说：“这个产品太糟糕了，和我们做的事情完全没关系。” Cohen 就会继续问：“那你们希望它有什么不同？” 然后他们会说：“你能做这个改动和那个改动吗？” 于是 Cohen 就把所有这些都记下来。

理想状态下，创业早期我们必须得大量做无法规模化的事，走出去拜访客户、研究用户，等到找到 PMF 后，我们的策略就会改变，变成与用户拉开距离、专注于规模化、并对所有客户一视同仁。

如果某个创始人所处的行业能这样顺利实现规模化，那么他根本不需要 FDE。但对于当时的 Palantir 来说做不到。

FDE 的做法其实是 Shyam Sankar（Palantir 早期成员，现任总裁兼 CTO）提出的。

我们发现每家客户要的东西都所有区别，与其给每一家单独做一个版本，或者补一堆只适用于特定一家客户的功能，不如把产品做成高度可定制的平台，这样一来，就必须把员工派驻到现场，深入理解用户并做本地化改造。

按传统观念，这些都算服务（Services），在 PMF 范式的框架里最好少做。

但 Shyam 把这套逻辑倒过来：让 FDE 充当产品探索（Product discovery）的过程。

FDE 带着现有的产品进场，去填补产品能力与实际需求之间的 gap，把路线先铺成一条“碎石路”（Gravel road）。总部的产品与工程团队再把这些现场做法抽象、泛化，修成能服务接下来五到十个客户的“高速公路”（Paved superhighway）。

 Host：在 Palantir 是工程师们直接面向企业客户而非专业销售，这是怎么形成的？ 尤其当我们面对的客户是政府和国防部门时，大多数人会倾向于去雇佣一批经验丰富的、长期和政府官员打交道的销售人员，但 Panaltir 并没有这么做？

Bob: 有两个方面的原因：

一方面，我们早期和很多那样的人接触过，他们的反应是：“我为什么要去和一个硅谷公司合作，而不去和五大国防承包商之一合作？”

另一方面，这类人的背景看似可以胜任这个工作，但我们其实很清楚他们无法融入我们的文化，也无法真正成功。当我们尝试那样做时，几乎从未成功过。

所以我们发现了一种非常不同的方式。我认为销售主导的产品探索和 FDE 主导的产品探索之间的区别在于，销售主导的产品探索是你从外部与人交谈。而 FDE 主导的产品探索更有效，因为 FDE 是从内部解决这些问题。

要专注于解决领导层确定的关键问题。如果你解决的不是 CEO 的前五大 priority 之一，那可能就不会成功，他们没有精力坚持走完这条更具挑战性的路线，也就是把一个全新的产品能力按他们的场景真正落地。

一旦你解决了第一个关键问题，那么 FDE 就可以在企业中发现其他关键问题，有时可能是比你最初目标更有价值的问题。也许 Palantir 或你的公司能否解决这些问题并不明显，但一旦你在那里，你就能通过产品洞察力看到你实际上可以做到这一点。然后再去解决那些问题。

所以，这就从“我如何向每个客户销售同样的东西”转变为“我如何落地并扩张”（land and expand）。

 Host: 进一步讲讲 Palantir 的 FDE 模式是如何运作的 ？

Bob: 首先需要思考的第一个问题是 FDE 团队是如何构建的，这里面有两个关键角色，我们称之为 Echo 团队和 Delta 团队。

Echo 团队具体来讲是 embedded analysts，他们会去客户现场，与用户交谈，试图找出什么样的 demo 或 use case 对这个场景的用户真正有价值，可以解决的关键问题是什么。与此同时他们也是客户经理 （account managers），所以他们也会是管理客户关系的人。

Delta 团队作为部署工程师，实际上就是软件工程师，这些人通常非常擅长快速编写代码，是把那些想法带入现实世界落地的人，他们构建解决方案、原型，然后落地为能实际运行的产品，最终为客户进行部署。

所有这些都会在很短的时间内完成。FDE 团队带着一个要做的项目的想法进去，并设定好几个月后要向领导层做一次 demo，展示他们的进展，如果那次演示顺利，就会真正部署，走向客户的全组织范围。

02.

如何构建一个 FDE 团队

 Host: 这两个角色的有趣之处在于，他们是完全不同类型的人，有不同的背景。你如何找到合适的人来担任这些角色，因为不是随便一个普通工程师就能胜任 FDE，他们需要更多与用户交谈的能力，或者 Echo 团队也需要更强的技术背景，而不仅仅是客户经理。Palantir 是如何建立 FDE 团队的？

Bob:  Echo 团队的理想人才画像是某个领域的专家。比如可能是一位前陆军军官，或者是在医疗保健领域有深度工作经验的人。他们有深厚的领域知识。除此之外，还有一点非常重要，Echo 团队成员需要具备“反叛者（rebel）”的特质，，Sham 甚至会称他们为“异端 （heretics）”，这些人不仅了解现有的做事方式，而且能够认识到这种方式不够好的点在哪里。因为如果看不到问题，就永远无法想出新软件以及它们带来的那种阶跃式变化。

对于 Delta 团队，我们需要的是非常擅长做原型 （prototyping） 的人。

Delta 的错误人选是那些有完美主义的工匠型人才，这种人很擅长写代码，喜欢抽象 （abstractions） 层面的绝对正确，希望他们构建的软件在未来十几年都能维护。

而我们真正想要的是那种能想办法进行产品实现的人，即便他们写的代码很粗糙。有时候，如果找到了对的人，他们写的代码也很优美，但大部分情况下不是，并且这件事不是 Delta 团队的核心，Delta 团队是能在规定时间线内以软件形式实际交付成果的人。即便他们写的第一个版本质量并不高、要推倒重来，但他们很擅长做原型，这是这个团队的关键技能。

 Host: Echo 和 Delta 的人才画像听起来很像一个创业团队。Palantir 会招聘一些前创业公司创始人，让他们来担任这些角色吗？还是说情况大多是反过来的？

Bob: Palantir 孵化出了数量惊人的创业公司，这并非巧合，因为 FDE 培训就是成为创业公司创始人的培训，你其实正在学习所有创业公司创始人的技能。当年我们刚开始做这个的时候，并没有大量的创始人可供我们选择。

你说的很对， FDE 团队在每个客户现场所做的事情确实有点像是一个创始人，但 FDE 成员的区别是他们一个可以接触到一些非常强大的产品杠杆 （product leverage） 的创始人，这让你的工作更容易。我认为这是很好的培训，这也可能是为什么市场上现在会看到这么多来自 Palantir 的创始人 。

03.

FDE 不是咨询，做通用产品同样重要

 Host: 那些不太了解 FDE 的人经常会说：“这只是用花哨的营销话术包装起来的咨询业务。” ，为什么这种说法是错的？

Bob: 客观来说 FDE 确实存在着成为那种情况的风险。如果在 2015 年和人们谈论 Palantir，你可能会主要听到两件事：

• 第一， Palantir 是邪恶的（Palantir is evil）（备注：Palantir 早期和情报部门合作，做的是间谍有关的业务），

• 第二，这是一个永远无法规模化的咨询业务，它不是一个软件公司，而是咨询公司。

在过去我们其实花了很多时间试图理解这种评价是否正确。

从商业模式上，我们会看到的一个关键趋势是：当我们去一个新客户那里做新项目部署时，在一开始我们可能实际上是在亏钱的，但随着我们在客户那里待的时间变长，我们的产品因为产品探索而变得更适合客户的需求，从而我们不再需要一个庞大的团队在客户现场搞清楚客户需要什么。同时会像 Sham 所说的那样，我们会逐渐赢得接触客户现场的更重要问题的权利。

所以最后的结果是我们会看到交付成果的单位价值成本 （cost per value） 在下降。也就是说我们的利润率 （profit margins） 开始时是负的，但最终在一段时间后，可能是一年，也可能是几年后，会变成正的。

如果从这个角度看，我们就会发现我们实际上在交付真正可重复的价值。产品团队是能让这个模式运作起来并降低成本的一个关键。

 Host: 产品团队是如何与 FDE 团队合作的？

Bob: Palatir 有两个核心团队，一个是 FDE 团队，另一个是产品管理 （product management） 团队。

我们构建的产品不是高度垂直化的，不是 Airbnb 那样可以同时支持数百万人需求的标准流程。产品团队的角色是去真正地把握产品愿景 （product vision）。所以他们必须思考，在客户现场看到一个新问题时，它的通用形态会是什么样的，什么样的版本可以应用于接下来的 10 个客户。

一个典型的失败例子就是，就是 FDE 为一个客户实现了一些东西，然后就直接把它引入到所有产品中。结果是 FDE 构建的东西对于其他客户来说过于特化了。这里的关键在于拥有能够构建更通用产品的能力的产品人员。

 Host: 所以需要一些 know-how 来判断它是只适用于这个垂直领域，还是可以推广，给我们举个具体例子？

Bob: 可能最好的例子就是 Palantir Ontology 的发明。

当我们最初考虑与美国政府，尤其是情报机构合作时，本能的做法是：给“人”建一张表，给“资金”再建一张表……

但很快就发现，沿着这条路走，一旦要在不同机构和客户间部署，就会遇到无法通用的问题。于是我们把抽象层级拉高，不再预设具体对象类型，而是让 FDE 按每个客户的语境去定义。底层只提供通用的对象、属性等，Palantir Ontology 就是在这种思路下诞生的。

 Host: 现在 Ontoloy 是如何运作的？是有一个包含像人和钱这样通用可复用对象的基础数据库模式 （database schema），然后根据每个站点进行定制吗？

Bob:  数据库模式本身极其通用，只保留：对象（objects）、属性（properties）、媒体（media）以及对象之间的链接（links）。

我这里指的是 Palantir 的政府产品（也是我们的第一个产品）。至于每个客户场景下的具体语义，则由 Ontology 来编码，例如把某个实体标注为“人”、把某个实体标注为“船”、或把一组关系标注为“资金流”。

如果我们只面向某一家客户构建功能，就会被这个客户的表述方式绑架，比如就会去想“对于人我们就这样做”。而正确做法是把抽象层级再往上提：思考“我们是否有一个对所有拥有某种属性的对象都适用的通用操作？”，比如“人”和“船”也许都具备某种属性，但付款记录并不具备，那处理逻辑就不能一刀切。这要求你始终在更高的抽象层上思考。

我们很长时间都没有招聘产品经理，等到需要招产品经理时，我面试过不少在其他公司非常优秀的人，但让他们在这种抽象层级上思考并不容易。很多人会直接落到“给这个客户设计一条具体流程”上，但这件事在 Palantir 的模式里是错的。他们需要把视角抬到本体层，思考在本体框架下该如何调整建模，使某个专用功能能够跨客户复用。

04.

为什么 FDE 是 Agent 时代的 PMF

 Host: 今天几乎这些 AI 公司都在大规模招聘 FDE，你认为背后的原因是什么？为什么上一代 SaaS 公司们没有这样做？即使在 Palantir 成功并且 FDE 模式变得更加知名之后，FDE 仍然被视为一个特例，因为大家认为 Palantir 是一家独特的公司，是向政府销售的公司。

Bob: 我也很惊讶于这个趋势。但我对于那些在考虑尝试 FDE 策略的人的建议是：如果不是一定需要 FDE，就不要真的亲自尝试这个，因为有可能会最终变成做服务（service）。如果经过一系列尝试发现不做 FDE 就一定会失败的话，那么 FDE 可能是你所在市场唯一可能行得通的方式，并且它可能对你来说就是一条护城河。

至于今天的 AI agent 市场中为什么会出现 FDE 这个趋势，也许可以回到这个问题上进行讨论，为什么 Palantir 必须采纳这个模式。

Palantir 的市场不是一个单一连贯的市场，我们与国家情报机构、国家执法机构、军方合作。尽管所有这些组织都有一些类似的项目， 但即使是反扩散工作流程（counterproliferation workflow）和反恐工作流程（counterterrorism workflow）之间，也存在差异很大差异，一个是查明谁在制造核弹，一个是查明谁在制造简易爆炸装置 ，它们在运作方式上实际上有很大的不同。

所以这里存在着巨大的异质性 （heterogeneity），我们应该把市场看作是不同的细分市场 （segments），在每个细分市场内部，你可以构建一些东西，《跨越鸿沟》的故事在一定程度上可以适用。

开始时似乎什么都不起作用，突然间你在某个细分市场找到了 PMF ，你可以部署给做这类工作流程的人。然后在下一个客户那里，你发现同样的人在做类似的工作流程，你可以用很少的定制化就完成部署。

所以现在你想去攻克一个不同的细分市场，你必须开发一项新技术，然后这项技术可以在其他细分市场中被引用。一个细分市场不一定等同于一个客户，特别是在企业或像政府这样非常大的企业中，一个客户可能意味着数万名用户。在那种情况下，FDE 策略就很重要了，因为你在做无法规模化的事情，但你是可扩展地、一遍又一遍地为你进入的每个细分市场做这件事。

我认为 Palantir 的另一个独特之处在于，我们正在构建一种全新类型的产品。

用户习惯于用一种看起来像 PowerPoint 的工具来做分析和追踪人员，他们通过互相来回发送这些文件进行协作。但我们构建的产品基本上是说：“当你在绘制那个链接图时，你不仅仅是在编辑一个文件，你实际上是在改变一个数据库，而且每个人都有同一个数据库。” 虽然对用户来说，这看起来是在他们正在做的工作之上的一个小改动，但对于我们销售的企业、组织来说，这是一个完全不同的市场类别。

我认为这就是 AI agent 正在发生的事情，这是一个全新的市场类别。

如果你在实施一个标准的 SaaS 产品，你用一种不同的支付账单的方式取代了另一种支付账单的方式，每个人都明白那个市场是什么。这样的细分市场没有那么多细小的划分，也没有那么多的同类项产品的探索，你尝试做一个比现有产品更好的产品，并通过取代现有产品来做规模化。

当对于 AI agent，没有现成的产品。构建 AI agent 实际上可能意味着很多不同的事情，而我们还不知道那些是什么，我们得去弄清楚。甚至可能五年后我们回过头来看，会觉得 AI agent 根本就不是一回事，我们实际上在做所有这些不同的事情。

所以这就是我认为为什么你看到 FDE 模式正在兴起，因为有太多的产品探索工作要做，而且你只能从企业内部去做。

 Host: 这和经典的 YC 建议“do things that don't scale” 之间有什么关系？

Bob: 那是 YC 给早期创始人的建议，而 FDE 模式实际上是在大规模地做那些不规模化的事情。

 Host: 现在很多人都在尝试采用 FDE 模式，包括很多没有在 Palantir 工作过的人，你有看到人们在哪些方面做错了吗？

Bob: 我目前看到的最成功的做 FDE 模式的创业公司，都有来自 Palantir 的人去负责运营 FDE 模块。

就像我说的，工程团队通常非常相似，但实际的 FDE 运作机制：如何建立这些客户，如何定义结果等等这些与标准软件公司实际上有很大的不同。

其中一个关键的区别，也是我认为人们很难理解的一点是：如何选择一个问题，然后如何为那个问题定价。从根本上说，用 FDE 模式销售的不是具体某个软件的安装过程，你销售的是一个成果。就像 Sham 会说的，你销售的是你解决了一个问题。

 Host: 在 SaaS 时代，你会根据使用量、订阅或席位来定价。而 FDE 完全不同，是基于成果，所有这些 AI 创始人应该如何为他们的解决方案定价？

Bob: 是的。我认为 FDE 模式和标准 SaaS 模式之间一个非常重要的区别是，对于 SaaS 模式和 PMF，人们趋向于非常简单、可重复的合同，非常简单、可重复的定价，这在所有客户中都说得通，而且通常 SaaS 团队对小金额合同会很满意，因为部署的边际成本 （marginal cost） 非常低。

而在 FDE 模式下，业务交互则会被推向越来越大规模的合同。就像我们前面谈到的，随着时间推移，每个客户的合同额都会增长。因为产品需求很复杂，合同也会很复杂，而且产品和合同也需要更灵活（flexible）和有弹性来适应复杂度。

 Host: 一些 YC 公司也开始这样做了，比如  Kastle 是为银行客户提供抵押贷款服务的 AI 语音 agent，他们把成功处理所有这些抵押贷款请求的电话数量作为衡量成果，合同规模也在逐步增加。Happy Robot 主要是做物流领域的 AI 语音 agent，和 DHL 这样的大公司合作，情况类似。

Bob: 这里存在一种创业公司和销售对象（通常是大企业）之间的不对称性。

当 startups 向大型企业进行销售时，首先企业客户经常不相信自己真的能完成任何事情，那是因为他们经常有很多失败的大型项目，并且他们也不相信创业团队能完成任何事情，因为他们认为你这个创业公司和他们一样。

而创业公司知道自己实际上能够执行能够落地，所以，在早期，创业公司承担所有风险是合理的，然后提出，“我们就是相信我们自己的执行力，我们会承担风险，如果成功了你再付钱给我们，或者当我们能够扩张时你再付钱给我们。”

 Host: 这一点可能出错的地方是，如果 startup 做的东西需要部署到企业内部，做 on-premise，甚至只要其中任何一部分需要在本地，就会出现需要和企业内部 IT 团队之间的争论和协调。

Bob: 我们也在一些公司看到了这种情况。这个问题可能是，一个 FDE 项目的成功需要赢得组织内部的那些支持？ 因为那些人不像创业公司那样思考，他们和终端用户利益不一致。所以必须想办法绕过他们。

这就是为什么创业公司要做 FDE 的话必须聚焦于解决 CEO 的前五大问题之一这点很重要，因为在遇到组织内阻碍时，需要能够从高层引入某个人说：“是的，给他们操作的权限、他们需要使用这种特定类型的数据库......”

 Host: Palantir 是如何在合作中获得对方企业高管支持 （executive buy-in） 的？

Bob：核心是需要在 FDE 团队中有非常出色的领导力，才能有那种纪律，并且分享有效的方法，在一个客户那里实践这个纪律和方法。

我认为这并不是特别神奇而难以做到的事情。我看到的做得最好的公司，都是从那些以前做过的人那里借鉴来的，这是可以学会的，我们就是学会的。

 Host: YC 有一个概念叫 Collison install，我们基本上把它归结为，不要等着人们来你的网站，你要去找他们，让他们安装软件，亲自去他们那里，去他们的办公室，坐在他们旁边。我觉得这一直是一个很好的起步策略。

但大多数创业公司一开始并不能拿到大合同。所以实际上，他们不得不停止这种手动、高接触度 （high-touch） 流程的原因是，如果没有一个能够规模化的产品，你根本无法维持增长率。这有点像我们之前谈到的，在某个时候，你希望你构建的产品足够好，人们可以自己搞定，然后你所有的问题就只是规模化的问题了。

而对于 AI，不同之处在于，因为这些合同现在非常大，你实际上可以通过做这种高接触度的事情走得很远。我经常被问到的一个问题是：“我能把这种方式推得多远？” 我的建议大体上是：“为每个客户做定制工作是可以的，你只是希望每个客户的定制化程度越来越低。”

对于这件事你是怎么看的？你怎么知道继续以这种高接触度的方式增加新客户是可以的，还是说实际上我需要开始抽象化，构建一个真正的产品了，什么时候需要改变策略？

Bob: 是的。我认为这其实概括了 PMF 策略和 FDE 策略之间的关键区别。

在 PMF 策略中，团队会希望为每个客户做的工作越来越少、降低成本，保持合同规模不变。

但在 FDE 策略中，预期会变成提高合同规模，提高合同规模意味着你为这个客户以及未来的客户做越来越有价值的工作。因为你正在做更有价值的工作，所以没关系，你可以保持每个客户的定制化程度不变。

 Host: 所以 KPI 是合同规模，而不一定是他们为每个客户做了多少定制工作？

Bob: 这里有两件有用的事情。

第一，你能衡量的事情，是合同规模。我甚至会说得更通用一点，即你交付的成果的价值，因为那才是真正的东西。如果你能够为客户交付越来越有价值的成果，那么你就做对了。

第二部分是产品的价值。所以要衡量的另一件事是，你是否正在获得越来越多的产品杠杆来放大那个成果。

当我们身处其中时，这一切都非常反直觉。

如果正在做 FDE 模式，或者领导了一个 FDE 团队，有很多必须做的事情看起来非常反直觉，这非常困难，因为你必须为客户构建他们没有要求但实际上想要的东西。

而在产品方面，则需要去想，如何做一个对每个客户都非常容易使用的产品。因为如果要关注用户体验，就必须这样做，但与此同时也必须记住你的另一个关键客户是 FDE。你的产品最终应该在 FDE 定制后为用户提供好东西，产品应该为在客户现场交付那个成果的 FDE 提供杠杆，而且产品杠杆的数量应该随着时间的推移而增加。

 Host：就像 FDE 应该能够用你的产品为客户交付更多价值，而不需要 FDE 去再拉三个工程师进来才能做到。

Bob: 是的。如果你部署的第一个客户需要大量工作，然后如果你想把同样的成果卖给另一个客户，那么应该会容易得多。当你一个客户一个客户地做下去时，应该会变得越来越容易。

但是记住 FDE 应该是去构建一个平台，所以你做的不仅仅是一堆垂直用例的叠加。你需要去正确地抽象出了你真正在构建的核心概念，这样你做事情也会更容易，你会有更多的产品杠杆，即使你不是在做那个用例，而是在做一些类似的事情。或者你会发现，如果你的产品真的很好，你的 FDE 们能想出一些新的方法来使用你构建的技术，去解决一些完全不同的问题。

 Host: 这几乎像是一种内部市场动态在起作用。如果你构建得非常好，那么 FDE 应该会选择使用它，你应该会看到 FDE 对使用你那种抽象产品的需求，而不是他们自己去做一个一次性的解决方案。

Bob: 是的。不过我想指出，这对所有相关人员来说都是一个非常痛苦的过程。在 FDE 的世界里，我可能用再多痛苦这个词都不够。

有很多次，我构建了一些我认为很棒、很漂亮的东西，还没到那一步，但我认为它真的能帮助 FDE 们，只要他们有能力看到它。我会说：“请用我的产品。”他们会说：“不，这工作量太大了，根本没用。”

老实说，大多数时候可能是我错了，我为他们构建了错误的产品，我应该看到这一点。但有时我也是在正确的轨道上，只是我做得还不够，没有让 FDE 们更容易使用。所以，我会派开发人员到现场去部署那些早期的解决方案，帮助它们过关。

 Host: FDE 是持续有效的吗？还是说，创始人有时应该自上而下地决定，说：“我就是想让你这样做”？

Bob: 这两种做法在不同情境下都可能是对的。这里的正确答案在很大程度上是一个判断问题。

回到这个关于产品愿景的问题，从一个客户到接下来三个，再到接下来十个，什么样的产品才是正确的通用产品？ 当你看到第一个客户时，你真的没有回答这个问题所需的信息。所以这纯粹变成了一个判断问题。

 Host: 在 SaaS 领域，工程师们很抵触 demo 驱动的产品开发 （demo driven product development） ，但在 FDE 语境中，demo-driven 是很重要的？

Bob: 实际上，我认为如果你有正确的产品类型，demo 驱动的开发效果非常好。

在 Palantir 的早期，我们实际上只有一个 demo，是一个你正在阻止恐怖分子阴谋的流程。我们开始时只用了一个功能，每次我们集成一个新功能时，我们都要思考，我如何展示这个新功能，是对于正在经历这个演示、正在阻止这个阴谋的分析师来说是真正有帮助的？ 当我们集成直方图时，我们必须说，我们实际上如何使用它，它如何与我们已有的功能协同工作？ 我们集成地图时，也有同样的问题。

如果你从“我正在构建什么”的角度来看世界，那么你考虑的是你的能力，你可能会单独考虑每个功能以及如何构建这些功能的最佳版本。但当你在构建一个 demo 时，你是从客户的角度来思考的。

一个好的 demo 是，你展示给客户，并且你在客户心中创造了对你所做事情的渴望。他们必须看到你所做的，并且就是想要伸手去抓住它，把它带入他们的生活。如果你看到这一点，那么你就知道你已经发现了客户的一个真正痛点。通过这样做，也迫使你开发更好的产品，因为你不仅在思考每个功能单独来看是否有意义，而且还在思考它们如何协同工作。

如果我要一遍又一遍地展示这个 demo，即使只是从一个功能移动到另一个功能这样简单的事情，也必须非常直接。这些都是你经常会看到，但通常是在你真正部署给客户之后才会看到的产品痛点。所以 demo 的作用是，它改变了你思考的焦点，从思考“我能构建什么”转变为“客户想要什么”，以及“我是否正在为客户解决那个痛点？”

 Host: 听起来这有点像，你必须在这个非常非常高维、多维的空间中持续进行梯度上升 （gradient ascent），并且不断改变变量（一个数学比喻）。

Bob: 是的。也许这是一个非常关键的点，那就是你必须建立的公司类型是一家学习型公司 （learning company），我想每个人都想建立一个学习型公司。

但如果你是像谷歌或 Meta 这样的公司，不学习是很容易的，因为你现在做的事情正在奏效。如果你只是继续做下去，市场在增长，每个人都想做你正在做的事情，你可以就这么靠着同样的策略混下去（Coasting），而且它还在为你带来回报。

我对那些考虑加入哪家公司的人的建议是，我告诉他们加入一家年轻的公司，不一定是小公司，而是一家年轻的公司。因为一家年轻的公司还在摸索，还在学习，它还没有成功。如果你刚大学毕业，你应该加入一家成长非常快的年轻公司，然后你就会看到成功是什么样子的，这正把你定位为以后自己公司的创始人。

这就是为什么 Palantir 孕育了那么多其他创业公司的原因，因为它即使作为一家非常大的公司，它仍然是一家每个人都在一直学习、专注于学习的公司，并且总是和创业公司一样勤奋工作。

 Host：你最近加入了另外一个超大组织，美国陆军预备役。有哪些来自 Palantir 的经验可以在这段经历中得到应用？

Bob: 陆军领导层与我们在 Palantir 早期与他们合作时的感觉非常不同，在当时（2005 年或 2010 年左右），陆军管理层已经阐明了陆军转型的计划，他们明确知道军队需要从伊拉克、阿富汗的战争形态转变为今天在乌克兰的战争形态，或者说如果我们在太平洋面临大规模作战行动会是什么样子。

当他们引入 Palantir 时，他们给我们指明了陆军的优先事项，给我们每个人分配了一个我们应该运作的领域，但他们也给了我们自由，去四处寻找问题，直接与基层的军官合作解决那些问题，或者如果需要，就上报给领导层并解决它。

所以我认为其中一件非常有趣的事情是，在很多方面，这确实很像在陆军上运行 FDE 策略。我们得以看到，什么是领导层的五大优先事项？我们能否在这些方面取得进展？但同时，在一个你看到领导层想要的和 20 年来的实施方式之间存在脱节的世界里，改变需要很长时间。所以，我们正在帮助他们做出改变。我真的很渴望能有机会在那里做出贡献。

 Host：你认为现在对创业公司创始人来说最好的机会是什么？

Bob：我认为这真的回到了为什么 AI agent 正在采用 FDE 策略这个问题上。

今天我们看到的趋势是 AI 能力提升实际上非常快。有观点说人们在 GPT-5 之后觉得 AI 有些停滞不前了，但如果看 2024 年 4 月最好的模型，GPT-4o 的发布，到 2025 年 4 月 o3 的发布之间这段时间，其实是一个非常快的进步速度。我认为这个趋势继续下去，我们将看到 AI 模型能力继续快速发展。

但真正令人震惊的是，但 AI 采用速度（adoption）远没有能力进展快。极大可能是，未来 5 年世界 AI 能力不断飞速前进，但我们在现实世界却感觉越来越平庸。这就现在我们坐在 Waymo 里不会想“天哪，无人驾驶已经实现了！”，而是“交通真堵，真慢”。

FDE 的机会在于当下一个很好的填补 AI 能力实际上能做什么和客户能够采纳什么之间 gap 的 timing。AI 被大规模应用是需要方法论的，它不是自己就会发生的事情，这件事要求人类的创造力、探索，以及应对大量的问题才能实现。所以我认为，看看现在有哪些能力，但如何让它们对人们真正有用，这方面有巨大的机会。

 Host：我想到一个类比，可能有点牵强，但就好像 OpenAI 是本部产品团队，而创业公司们是 FDE，在外面想办法让 OpenAI 在本部办公室里研发出来的研究成果被采纳。

Bob：我认为这个类比一点也不差。我认为，这也许是让整个 FDE 策略再次变得热门的原因。