作者：Marc Andrusko

编译：DeepTide TechFlow

深潮之浪：硅谷目前正经历一股“Palantir 化”风潮——AI 初创公司纷纷效仿 Palantir，派遣工程师驻场客户现场，提供高度定制化的服务，并拿下七位数的合同。

a16z 合伙人 Marc Andrusko 给这股风潮泼了冷水，他指出，大多数公司只是在模仿表面功夫，最终会沦为披着 SaaS 外衣的咨询公司。本文剖析了 Palantir 模式中真正可复制的要素，以及哪些方面只是美丽的幻象。

正文内容：

如今，初创公司的商业计划书（BP）里流行着这样一句话：“我们基本上就是 X 领域的 Palantir。”

创始人们热衷于派遣“前沿部署工程师”（FDE）驻场客户现场，构建深度定制化的工作流，运营方式更像特种部队，而非传统软件公司。今年，“前沿部署工程师”的招聘职位数量暴涨了数百个百分点，因为所有人都在复制 Palantir 在 2010 年代初开创的这套模式。

我理解这种商业模式为何有吸引力。企业客户如今被“该买什么软件”这个问题搞得焦头烂额——一切都宣称自己是 AI，要从噪音中分辨出有意义的信号从未如此困难。Palantir 的做法非常诱人：把一个小团队部署到混乱的环境中，整合各种孤立的内部系统，并在几个月内交付一个定制化的工作平台。对于一家志在拿下首个七位数订单的初创公司来说，“我们会把工程师派进你的组织，把事情办成”这一承诺是极具吸引力的卖点。

但我对“Palantir 化”能否被推广为一种通用方法论持相当怀疑的态度。Palantir 是一个“独一档”的存在——看看它的股票是怎么交易的就知道了！大多数只模仿其表面做法的公司，最终会变成昂贵的服务提供商，顶着软件的估值倍数，却没有任何可复利的竞争优势。这让我想起了 2010 年代，当时每家初创公司都自称是“平台”，但实际上真正的平台公司极为罕见，因为构建平台的难度实在太大了。

本文旨在厘清 Palantir 模式中哪些部分真正可迁移、哪些是独一无二且无法复制的，为那些希望将企业软件与高接触服务相结合的创始人提供一份更务实的路线图。

“Palantir 化”究竟意味着什么？

“Palantir 化”开始被用来指代几件相互关联的事情：

一线嵌入式工程

一线部署工程师（在 Palantir 内部称为 "Delta" 和 "Echo"）会深入驻扎在客户组织中（通常长达数月），理解业务场景、整合各类系统，并在 Foundry 平台（在高安全等级环境中则是 Gotham 平台）上构建定制化工作流。由于定价采用固定费用模式，传统上没有“SKU”——工程师负责构建和维护这些能力。

高度强势的集成平台

Palantir 的产品本质上并非一组松散连接的工具，而是一个在数据集成、治理和运营分析方面目标明确的平台——更像是用于组织数据的“操作系统”。其目标是将碎片化的数据转化为实时、高置信度的决策。

高端、高接触的销售模式

“Palantir 化”还描述了一种销售风格：面向任务关键型环境（国防、执法、情报等）的漫长、高接触销售周期。监管的复杂性以及行业中“利害关系”的巨大规模是特性而非缺陷。

销售成果，而非许可证。

收入来自多年期、基于成果的合同，将软件、服务和持续优化结合在一起。与单个客户的合同每年可达数千万美元。

最近的一份分析将 Palantir 定义为“独一无二的一个类别”，因为它同时在三个方面表现出色：(a) 构建集成产品平台，(b) 将精英工程师嵌入客户运营中，以及 (c) 在任务关键型的政府和国防环境中证明自己。大多数公司可以做到其中一两项，但无法同时做到这三项。

但到 2025 年，人人都想搭上这一模式成功的顺风车。

为什么现在人人都在试图复制 Palantir？

三股力量正在汇聚：

1. Enterprise AI faces a challenge in "implementation."

相当大比例的 AI 项目在进入生产环境之前就陷入停滞，原因往往是数据混乱、集成难题以及缺乏内部领导力。尽管购买热情依然高涨（董事会和高管层自上而下施加了“要用 AI”的真实压力），但实际部署和实现投资回报往往需要大量亲力亲为的工作。

2. The front-line deployment engineer seems to be the missing link.

媒体报道和招聘数据显示，今年 FDE（全栈部署工程师）职位出现了爆发式增长——不同来源的统计显示增幅在 800% 到 1000% 之间——AI 初创公司正通过嵌入工程师的方式让真实世界的部署成为现实。

3. Rapid growth has become the norm (it is easier to achieve quick expansion by securing seven-digit large orders than by accumulating five-digit small ones).

如果通过空运把工程师派到现场，就能从财富 500 强企业或顶级政府机构手中拿下超过一百万美元的订单，那么许多早期公司愿意用毛利率换取发展势头。投资者也越来越能接受较低的毛利率，因为全新的 AI 体验往往需要高昂的推理成本。这场豪赌的关键在于：你能否赢得客户领导层的信任与支持，交付“成果”，然后据此定价？

于是叙事变成了：“我们要走 Palantir 的路。我们会派出一支精英团队创造一些神奇的东西，然后随着时间推移，把它打造成一个平台。”

这个故事在非常特定的条件下是成立的。然而，有一些创始人往往一笔带过的硬性约束。

类比的失效之处

想从第一天起就出售“成果”。

Palantir 的旗舰产品 Foundry 是数百个微服务的组合，它们共同服务于同一个成果。这些微服务构成了产品化、有明确主张的解决方案，用于解决各领域企业面临的常见问题。在过去两年里，我见过数百位 AI 应用创始人，我可以告诉你这个类比在哪里失效了：初创公司一上来就兜售一套宏大的、以成果为导向的目标，而 Palantir 则是有意识地先构建微服务，这些微服务构成了其核心能力的基石。这正是 Palantir 与普通咨询公司的区别所在（也解释了为什么它的估值高达明年收入的 77 倍）。

Palantir 拥有一系列核心产品：

• Palantir Gotham 是 Palantir Technologies 开发的软件平台，主要用于数据集成：一个国防与情报平台，帮助军事、情报和执法机构整合并分析碎片化数据，用于任务规划和调查。
• Palantir Apollo 是 Palantir Technologies 开发的软件平台，主要用于数据集成：一个软件部署与管理平台，能够安全、独立地向任何环境（多云、本地部署、离线环境）交付更新和新功能。
• Palantir Foundry 是一个为构建和运营关键任务系统而设计的综合性软件平台。它使组织能够集成一个跨行业的数据运营平台，整合数据、模型和分析，以驱动企业运营决策。
• Palantir Ontology 指 Palantir Technologies 所使用的结构化框架或数据模型，该公司以其……而闻名：一个动态的、可操作的数字模型，刻画现实世界中的实体、关系和逻辑，为 Foundry 内的应用和决策提供支持。
• Palantir AIP 指 Palantir 的人工智能平台。Palantir 是一家以(AI 平台)闻名的科技公司：通过 Ontology 将 AI 模型(如大语言模型)与组织的数据和运营相连接，从而构建可用于生产环境的 AI 驱动工作流和 AI Agent。

引用 Everest 报告：“Palantir 的合同从小规模起步。初期合作可能只包括一个简短的训练营和有限的许可证。只有在价值得到验证之后，才会增加更多用例、工作流和数据领域。随着时间推移，收入结构从服务转向软件订阅。与咨询公司不同，服务只是推动产品采用的手段，而非主要收入来源。与大多数软件厂商不同，Palantir 愿意预先投入自己的工程时间来赢得有价值的客户。”

一方面，我现在看到的 AI 应用公司往往直接签下七位数的合同。另一方面，这主要是因为它们采用完全定制化的模式——它们解决早期客户抛来的任何问题，希望从这些经验中提炼出主题，日后构建核心能力或"SKU"。

并非每个问题都是"Palantir 级别"的问题。

在 Palantir 早期部署的领域，备选方案是“什么都行不通”：反恐、欺诈检测、战场后勤以及高风险医疗操作。解决这些问题的价值以数十亿美元、挽救的生命或地缘政治后果来衡量，而不是边际效率的提升。

如果你向一家中型 SaaS 公司销售产品，帮它把销售流程提升 8%,你就无法承担同等水平的定制化现场部署。ROI 根本无法证明数月的现场工程投入是合理的。

大多数客户不想永远当你的研发实验室。

Palantir 的客户默认接受产品与公司共同演进；他们之所以能容忍很多，是因为利害关系重大且备选方案有限。

大多数公司，尤其是国防和受监管行业之外的公司，不想感觉自己身处一个没完没了的咨询项目之中。他们想要可预测的实施、与现有软件工具的互操作性，以及快速见效。

人才密度和文化无法一概而论。

Palantir 花了十多年时间招募和培养极其出色的通才工程师，他们能编写生产级代码，轻松驾驭官僚体系，并能与上校、CIO 和监管者坐在同一间屋子里进行有实质内容的讨论。离开这一岗位的人形成了一个被称为"Palantir 黑手党"的创始人和高管群体。其中许多人后来成为独角兽级创业者，因为他们既具备深厚的技术功底，又在与客户打交道时极为高效。

大多数初创公司无法假设自己能雇到成百上千这样的人才。在实践中，“我们要组建一支 Palantir 式的 FDE 团队”往往会退化为：

• “售前解决方案工程师”的头衔被改名为“FDE”。
• 初级通才被要求同时负责产品开发、实施落地和客户管理。
• 领导层从未近距离见过 Palantir 的部署，只是喜欢那种氛围。

必须明确的是，外面有很多极具天赋的人才，而且像 Cursor 这样的工具也在让非技术员工能够编写代码。然而，要大规模复制 Palantir 模式，需要商业与技术才能的极其罕见的结合。在 Palantir 工作过尤其有帮助，因为它是一家非常独特的公司。但拥有这种背景的人数量有限！

服务陷阱是真实存在的。

Palantir 的成功源于定制化工作背后有一个真正的平台。如果你只复制嵌入式工程师模式，最终会得到数以万计难以维护或升级的定制化部署。即使在一个 AI 工具能让企业在这种模式下实现软件级毛利率的世界里，过度强调一线部署而缺乏强大产品骨架的公司，也可能无法实现规模递增效应，也难以构建持久的护城河。

挑剔的投资者可能会看到合同价值从 0 到 1000 万美元的曲棍球杆式增长，便急于入局。但我一直在问的问题是：当几十家——甚至上百家——这样的 1000 万美元级初创公司，带着完全相同的说辞开始互相碰撞时，会发生什么？

到那时，你不会是“X 领域的 Palantir”。你会是“X 领域的 Accenture”，只是前端更漂亮一点。

Palantir 做对了什么？

如果剥去神话的外衣，有几个要素值得仔细研究：

1. Platform-first, rather than project-first.

Palantir 的前沿部署团队基于一小组可复用的原语（数据模型、访问控制、工作流引擎、可视化组件）来构建系统，而不是为每个客户编写完全定制的系统。

2. Have clear opinions on how the work "should" be carried out.

这家公司不只是将现有流程自动化，它常常推动客户转向新的工作方式，而软件本身就体现了这些原则。这对一家供应商来说是难得的勇气，也让复用成为可能。

3. Long-term Vision and Capital

成为一家 Palantir 式的公司，需要在平台和销售模式成熟的过程中，忍受长期的负面情绪、政治争议以及短期变现的不确定性。

4. A very specific market portfolio

在情报和国防领域的早期定位是一个特性，而非缺陷：客户付费意愿高、转换成本高、利害关系重大，且客户数量极少但体量极大。更不用说还有一批老牌竞争对手，几十年来在几乎没有竞争的情况下锁定了合同。

换句话说，Palantir 不仅仅是一家“软件公司 + 咨询公司”。它是一家“软件公司 + 咨询公司 + 政治项目 + 极度耐心的资本”。

这不是简单地把它嫁接到某个垂直 SaaS 产品上就能一概而论的东西。

一个更现实的框架：什么时候“Palantir 化”是合理的

与其问“我们怎样才能变得像 Palantir？”，不如问一系列门槛问题：

1. The Critical Nature of the Issue

这个问题是“任务关键型”的（人命、国家安全、数十亿美元），还是“锦上添花型”的（10-20% 的效率提升）？利害关系越大，前沿部署模式就越合理。

2. Customer Concentration

你是向几十家大客户销售，还是向成千上万的小客户销售？嵌入式工程在客户集中、ACV（年度合同价值）高的客户群体中扩展性更好。

3. Degree of Domain Fragmentation

不同客户之间的工作流程是否相似，是否使用相同的软件工具，还是每次部署在根本上都不同？如果每个客户都是独一无二的“雪花”，就很难构建一个一致的平台。一定程度的同质性是有帮助的。

4. Regulation and Data Gravity

你是否在一个高度受监管、数据集成挑战巨大的领域运营（国防、医疗、金融犯罪、关键基础设施）？这正是 Palantir 式的集成能够创造真正价值的地方。

如果你在这些维度上大多处于左下象限（关键性低、客户碎片化、集成相对简单），那么完整的“Palantir 式”方法几乎肯定是错误的模式。这类情况更适合自下而上的 PLG（产品驱动增长）策略。

有什么值得学习的？

尽管我怀疑并非每家早期公司都能成功套用 Palantir 模式，但这种做法中有几个方面值得考虑：

1. Treat the front-line deployment as scaffolding, not the final building.

以下做法当然可能是正确的：

• 嵌入工程师和早期设计合作伙伴，协同工作。
• 不惜一切代价让前 3-5 个客户进入生产环境。
• 利用这些合作对你的基础组件和抽象进行压力测试。

但约束条件需要明确：

• 有时限的部署（例如“90 天冲刺上线”）
• 明确的比例（例如“每 100 万美元 ARR 可以分配多少工程全职人力”）
• 每季度将定制代码转化为可复用的配置或模板的目标。

否则，“我们以后会把它产品化”就会变成“我们从来没有腾出时间去做”。

2. Built on powerful primitives, not custom workflows

Palantir 给我们的真正启示在于产品架构：

• 统一的数据模型和权限层
• 通用的工作流引擎和 UI 基础组件
• 尽可能用配置代替代码。

前沿部署团队应把时间集中在“挑选”和“验证”要组装哪些基础组件上，而不是为每个客户从零构建全新的东西。把全新组件的构建工作留给工程师。

3. Make FDE a part of the product, not just a delivery.

在 Palantir 的世界里，前沿部署工程师深度参与产品探索和迭代，而不仅仅是实施。强大的产品组织和平台团队，正是由 FDE 在一线学到的东西滋养而成的。

如果你的 FDE 被放在一个独立的“专业服务”部门，你就会失去这个反馈闭环，并逐渐滑向一家纯粹的服务公司。

4. Be honest about your profit structure.

如果你的融资叙事假设软件毛利率超过 80%、净收入留存率达到 150%，但你实际的销售模式需要长期驻场项目，那就坦率地说明这些权衡——至少在内部要透明。

对于某些品类而言，一种结构性毛利率较低但 ACV（年度合同价值）更高的模式是完全合理的。问题出在那些假装自己是 SaaS（软件即服务）、实际上是运行在平台之上的服务型公司身上。投资者通常寻找的是通往最高绝对毛利的路径，而实现这一目标的方式之一，就是更大规模的合同结合更高的 COGS（销货成本）。

我会如何对一家“Palantir 化”的初创公司做压力测试？

当一位创始人告诉我“我们是 X 领域的 Palantir”时，我笔记本上的问题大致是这样的：

• 给我看看一个立场清晰的平台边界。共享产品到哪里结束，客户定制代码从哪里开始？这个边界移动的速度有多快？
• 当然，我可以带你了解部署时间线。不过，我需要更具体的信息来了解你所指的项目或系统。能否请你提供以下细节：1. **项目** 从签约到首次生产使用需要多少工程师月？哪些组件必须定制？
• 一个成熟客户在第三年的毛利率是多少？随着时间推移，在前沿部署上的投入是否显著下降？如果没有，为什么？
• 如果明年签下 50 个客户，系统会在哪里崩溃？招聘？新员工培训？产品？支持？我想看到模式在哪里被打破。
• 你如何决定“不”做定制？对定制工作说“不”的意愿，往往是产品公司与那些拥有漂亮演示的服务公司之间的关键区别。

如果这些答案清晰、基于真实部署且在架构上连贯，那么某种程度的 Palantir 式一线部署确实可能成为真正的优势。

如果答案含糊不清，或者每次合作显然都完全独一无二，那么我们就很难认可其可复制性或真正可扩展性的潜力。

结论

Palantir 的成功营造出一种强大的光环，主导着风险投资和创业圈：一小队精英工程师空降到复杂环境中，连接碎片化的数据，交付能够改变组织决策方式的系统。

人们很容易相信每一家 AI 或数据初创公司都应该长成这个样子。但对于大多数品类而言，彻底的“Palantir 化”是一个危险的幻觉：

• 问题不够关键。
• 客户过于分散。
• 人才模式无法规模化。
• 经济账目悄然坍缩为服务公司。

对创始人而言，一个更有用的问题不是“我们如何成为 Palantir？”，而是：

“为了弥合我们所在品类的 AI 采用鸿沟，我们需要多少次 Palantir 式的一线部署——以及我们多快能将它们转化为真正的平台业务？”

如果你能做对这一点，你就可以借鉴这一方法中真正重要的部分，而不必继承那些会压垮你的部分。