Palantir与本体论 · 番外六：为什么不存在一个"完美的本体论产品"？

凯叔Kev

发布于 2026-07-15 16:43:41

前面几篇反复出现一个现象：很多企业想买一个"本体论驱动的产品"，开箱即用，三个月上线，半年见效。但Palantir的实际做法恰好相反——FDE先在现场铺一条土路，跑通了再让产品团队修成高速公路。甚至FDE有权绕开产品路线图，直接给客户做新功能。

这意味着一件事：在Palantir的逻辑里，产品不是建模的起点，而是建模的终点。

预定义的范畴框架，在非标场景中必然失效

第三篇给出的判断是：ontology不是数字孪生，是认知眼镜。眼镜的度数因人而异、因场景而异。一个近视500度的人和一个近视200度的人，不可能用同一副眼镜。

产品预设的是一套固定的范畴框架——实体类型、关系、可触发的动作，全部是产品团队在办公室里定义好的。但每个企业的业务世界不一样。番外二用CRM商机客户和ERP成交客户的例子讲过这个问题——同样叫"客户"，在不同系统里的含义、粒度、生命周期阶段完全不同。

在标准化程度高的场景里——财务记账、薪酬计算——预定义的范畴框架是可行的，因为这些领域的范畴已经被行业标准固化了。但在非标、高度动态、需要跨域推演的场景里，没有人能替你预定义范畴。一个号称"开箱即用的本体论产品"，本质上是一个认知牢笼——它替你预设了世界的结构，你只能在它定义的范畴内活动。

产品是土路的固化，不是土路的起点

Palantir的产品演进路径跟传统软件公司完全不同。

传统路径：产品团队设计功能→工程团队开发→销售团队卖给客户→实施团队部署上线。产品在客户之前就已经定型了。

Palantir的路径：FDE驻扎在客户现场→在真实场景中发现需求→现场搭建解决方案→方案被验证有效→产品团队把它抽象成通用功能→这个功能成为产品的一部分→下一个客户可以复用。

产品是土路的固化，不是土路的起点。为什么不能跳过土路直接修高速公路？因为直接做大规模标准化，相当于在不知道方向对不对的时候就重资产投入——跑错了，昂贵的高速公路就是负资产。FDE铺土路，本质上是用最低成本做认知试错。

那Palantir自己的Gotham和Foundry又是什么？如果不存在完美的本体论产品，它们算什么？

答案是：它们不是"产品"，而是"造产品的平台"。Gotham面向国防和情报机构，Foundry面向商业企业——但两者的核心逻辑一样：它们提供的是一套可以在上面构建ontology的基础设施——数据接入管道、对象类型定义工具、关系建模能力、动作触发引擎、安全权限控制。但它们不预设你的业务世界长什么样。里面没有一个现成的"供应链模板"或"反恐分析模板"等着你开箱即用。

FDE进入每一个客户现场，用的是同一套平台工具，但构建出来的ontology完全不同——因为每个客户的业务世界不同、决策问题不同、关键实体不同。Gotham和Foundry是镜框，不是镜片。镜框是标准化的，但戴上之后你能看清什么，取决于FDE在现场帮你配的那副镜片。

更关键的是，当镜框本身不够用时，FDE有权直接改镜框。Palantir内部的原则是"对前线团队的激进信任"（radical deference to teams in the field）——当客户的真实需求超出了现有产品的能力边界时，FDE不需要等总部排期，可以直接开发新功能甚至新模块。Palantir内部对FDE的定位是"一个客户对应多种能力"，而产品工程师是"一个能力服务多个客户"。两者的反馈闭环是：FDE在前线造出粗糙但有效的解决方案（土路），产品团队判断哪些方案具有通用性，把它们抽象固化为平台的标准能力（高速公路）。

这也是为什么Palantir的竞争壁垒不在产品代码里，而在FDE这个角色和他们在无数个客户现场积累下来的"配镜"经验里。平台可以被模仿，但二十年积累的场景认知很难被复制。

有人会问：说了半天"产品不是起点"，那Palantir到底是软件公司还是咨询公司？一个数字可以回答这个问题：Palantir 2025年的毛利率是84.65%，远超咨询公司的32%（埃森哲），甚至高于SaaS标杆的66%（Snowflake）。这证明它卖的是平台，不是人头。但这个平台不是开箱即用的产品——它是一套需要FDE在现场构建范畴框架的基础设施。

换句话说，Foundry和Gotham是已有能力的沉淀，但不是能力边界的限制。每一次FDE在新场景中构建出新的范畴框架、开发出新的功能，被验证有效后就会沉淀为平台的一部分。平台因此越来越厚——但它的厚度是用来支撑下一个新场景的，不是用来框死下一个新场景的。具体来说，Foundry的厚度不是预设了多少功能组件，而是沉淀了多少处理数据冲突、适配异构系统、保障安全权限的底层共性逻辑。这使得FDE在面对新场景时，不必从零开始搭基础设施，而可以直接在成熟的底座上构建业务范畴。这跟那些预定义了行业模板的产品有本质区别：模板越厚，限制越多；平台越厚，可能性越大。产品不是建模的起点，而是建模的终点。

这里面还有一层容易被忽略的逻辑。FDE在现场捕捉到的"现场知识"是有时效性的——业务在变、人在流动、场景在演化。如果这些知识不能被及时归纳为产品的通用能力，它就会随时间贬值。产品团队的职责不是"发明功能"，而是"归纳现场已经验证有效的认知"，在它贬值之前把它固化下来。

还有一个值得思考的问题：FDE是不是一种过渡态？随着平台能力增强、行业认知沉淀，FDE在单个客户的工作量理论上应该逐年递减。如果三年下来工作量没有明显下降，要么是平台的产品化做得不够，要么是这个客户的需求本身就不适合用平台化的方式解决。但至少在当下，AI能辅助FDE但还不能替代——番外三讨论过这个问题。所以"不存在完美的本体论产品"这个判断，目前仍然成立。

买方应该看什么

如果你是一个想引入ontology的企业，这个逻辑对你有三个直接的含义。

第一，不要指望买一个产品就能解决问题。

你买到的是一个平台——一套可以在上面构建范畴框架的工具。但范畴框架本身需要有人在你的业务现场构建出来。番外一讲过，800万买了软件但配镜师派了个实习生——这就是把产品当终点而不是起点的后果。

第二，警惕那些号称"开箱即用的本体论产品"。

如果一个产品说它已经预定义好了你的行业的ontology模板，那它做的不是ontology，而是传统的行业解决方案换了个名字。好的供应商应该提供的是"认知的脚手架"——帮你更高效地构建自己的范畴框架——而不是一个替你预设好答案的认知牢笼。

第三，评估供应商的时候，看他的人，不只是看他的产品。

具体看三个维度：他的团队有没有从混乱的业务现实中提取核心实体的“抽象能力”——能不能在工厂车间蹲三天搞清楚产线瓶颈？他的方案是否允许在运行中调整范畴定义的“容错边界”——当业务发生变化时，是需要推倒重来，还是可以通过微调ontology结构快速适配？一个好的平台应该支持平滑重构，而不是牵一发动全身。现场的定制化功能多久能转化为平台的底层组件的“反馈回路”——土路变成高速公路的周期是多长？

如果供应商只能给你演示一个漂亮的产品界面，但在这三个维度上说不清楚，那这个产品对你来说大概率是数字盆景。