第 22 章：从项目经验到平台能力

Palantir 最关键的商业化问题，不是它能不能服务一个复杂客户。

而是：

它能不能把服务复杂客户的经验，变成下一次服务类似客户的产品能力？

如果不能，它就是项目公司。

如果能，它才可能成为平台公司。

从项目经验到平台能力，中间需要一条抽象链。

1. 项目经验如何抽象成对象模板

每个客户都有自己的特殊性。

但同一行业中，也一定存在共性。

制造业里反复出现设备、产线、工单、库存、供应商、质量事件。

医疗里反复出现病人、医生、药品、检查、风险、诊疗路径。

国防里反复出现任务、目标、资产、地点、威胁、行动。

能源里反复出现井、管线、设备、维护、交易、事故。

Palantir 要做的是把项目中的对象经验抽象成对象模板。

下次进入类似客户时，不必从零定义对象世界。

这就是行业 ontology 的雏形。

2. 行动经验如何抽象成 Action 模板

客户现场不仅有对象，还有动作。

比如：

•创建工单；

•派发任务；

•调整排产；

•触发审批；

•拦截交易；

•更新风险等级；

•启动维修；

•发送预警；

•写回 ERP。

这些动作在不同客户之间会有差异，但也有共性。

如果 Palantir 能把这些动作抽象成 Action 模板，就能提高复用率。

Action 模板越丰富，AIP 越容易从“回答问题”进入“执行流程”。

3. 权限经验如何抽象成治理模板

复杂组织最难复用的部分之一，是权限。

但权限也有模式。

比如：

•按角色授权；

•按部门授权；

•按对象关系授权；

•按敏感等级授权；

•高风险动作需要审批；

•跨部门动作需要复核；

•AI 自动动作需要人类确认；

•关键系统写回必须留痕。

这些可以抽象成治理模板。

如果 Palantir 能在行业中沉淀权限和审计模板，它进入新客户时就不必从零设计治理结构。

这对高复杂行业尤其重要。

4. 部署经验如何抽象成 Apollo 能力

部署经验也必须产品化。

复杂客户有不同环境：

•云；

•私有云；

•政府云；

•边缘设备；

•断网环境；

•高安全环境；

•多版本系统；

•多权限隔离。

如果每个客户部署都靠人工解决，规模化会很难。

Apollo 的意义，就是把部署、更新、版本控制和运行管理变成平台能力。

部署经验产品化，是 Palantir 从项目公司走向平台公司的关键环节。

5. 行业经验如何抽象成行业 ontology

最终，所有经验都应该沉淀为行业 ontology。

行业 ontology 不只是对象模板，还包括：

•对象；

•属性；

•状态；

•关系；

•规则；

•权限；

•Action；

•Workflow；

•审计；

•行业指标；

•风险模型；

•最佳实践。

行业 ontology 越成熟，Palantir 越能快速进入类似客户。

这就是“深度客户经验”真正变成“平台资产”的过程。

6. 这条抽象链决定 Palantir 是平台公司还是项目公司

判断 Palantir 的核心，不是看它项目有多复杂，而是看它能否抽象。

项目经验如果不能抽象，就只是项目经验。

客户理解如果不能复用，就只是客户理解。

FDE 如果不能反哺平台，就只是交付人员。

行业知识如果不能产品化，就只是咨询知识。

Palantir 能否成为平台公司，取决于这条链：

项目经验 → 对象模板 → Action 模板 → 治理模板 → 部署能力 → 行业 ontology → 平台复用。

这条链越强，Palantir 越像平台。

这条链越弱，Palantir 越像系统集成商。