Palantir分析（一）---PLTR究竟是干什么的？（一）

本系列文章将分享对不同公司定性定量分析，希望各位雪友积极交流。以下言论仅个人分享，不构成投资建议。

接下来更新的是Palantir的系列文章，PLTR是去年非常热门的AI概念股，2025年全年涨幅135%。近期股价下跌的也非常厉害，那PLTR究竟是干什么的？商业模式是怎样的？护城河是什么？现在还值得投资吗？后续的系列文章将逐一研究。第一篇主要研究的是PLTR的主要业务。

一、PLTR的主要业务

先说结论：PLTR通过本体构建映射物理世界的业务逻辑与规则，Foundry/Gotham 平台再让这些规则在真实业务里持续运行，并在现实约束下推演出可行行动空间，最终由 AIP 将这些可行路径转化为少数清晰可理解的行动选项，并负责把“人已确认的决定”变成可执行指令，由Foundry/Gotham 在规则约束下完成落地，并将执行结果回流以持续优化未来的决策逻辑，从而形成一个不断进化的决策与行动闭环。

看到这是不是觉得非常抽象，很难理解。PLTR本身业务是To B的，我们日常中接触不到（也没进入中国市场），业务是比较难理解。后面我会通过费曼举例的方式解释其业务，我会举三个不同应用场景的例子，帮助理解。

1、供应链领域的例子

背景：你的 ERP 系统（SAP/Oracle）里有 100 万行数据。 你的物流表里有 5000 辆卡车。 你的仓库里有 20 万个零件。

突然，太平洋上有一艘运载“座椅调节螺丝”的货轮，因为台风晚了 3 天。

1.1没有 Palantir 时：系统里发生了什么？（数据层）

当那艘船晚点时，你现有的系统（SAP, Excel, 传统数据库）是这样记录的：

系统 A（海运表）： Shipment_ID: 9981 → Status: Delayed (+3 Days)

系统 B（库存表）： Part_ID: Screw-X → Current_Stock: 0

系统 C（生产表）： Line_ID: SUV-Assembly → Target: 500 cars/day

关键点来了： 在这些系统里，没有任何人或者代码在尖叫。

海运表觉得：“哦，晚了 3 天，我记录下来了，我的数据是准确的。”

库存表觉得：“哦，现在是 0，我记录下来了，准确。”

生产表还在傻傻地排计划，因为它不知道螺丝没了。

这就是“数据孤岛”——每个系统都说实话，但它们合起来在撒谎。 直到 3 天后，工人站在流水线上喊：“老板，没螺丝了！”你才知道出大事了。

普通软件如Excel / BI / 报表软件像成绩单，告诉你：已经发生了什么，不能告诉你：接下来怎么办，更不能：直接帮你执行。

1.2 Palantir 进场：核心一步---构建本体（Ontology）

Palantir 不只是把这三张表连起来（那是 SQL 做的），它是把现实世界的规则教给电脑。

第一层：定义对象（世界里有什么？）

Palantir 不看“表”，它在系统里建立了对象：

这不是 Shipment_ID: 9981，这是一艘**“正在海上的货轮”**。

这不是 Part_ID: Screw-X，这是一个**“关键零件：座椅螺丝”**。

这不是 Line_ID，这是一条**“一旦停工每分钟亏 1 万美元的产线”**。

第二层：定义关系（谁依赖谁？）

这是最核心的一步。Palantir 把“现实世界的规则”写进系统里，让系统知道“什么是什么、谁影响谁、谁能动谁”。

规则 1： SUV 由 座椅 组成。

规则 2： 座椅 必须有 螺丝 才能组装。

规则 3： 螺丝 必须由 货轮 运送到 港口。

规则 4（最狠的）： 如果螺丝库存 < 生产需求，生产线必须强制停止。

注意： 这一步不是算数，而是现实世界的因果规则，被系统内化了，变成了系统的铁律。

1.3 见证奇迹：因果推演

现在，那艘船在太平洋上刚刚晚点 1 小时。 Palantir 系统里的多米诺骨牌开始倒下（这是 Excel 做不到的）：

感知： 系统捕捉到货轮信号：晚点 3 天。

推理（第一级）： 货轮晚 3 天 → 港口接不到货 → 卡车没东西拉 → 工厂仓库收不到螺丝。

推理（第二级）： 仓库没螺丝 → 座椅厂无法组装座椅。

推理（第三级）： 座椅厂没座椅 → 总装车间无法生产 SUV。

计算后果： 总装车间停工 3 天 → 预计损失 1500 万美元，且无法交付沃尔玛的订单。

客户看到的界面： 你的一天还没开始，手机弹窗了：

红色警报： 预计 72 小时后总装线停产。 原因： 螺丝缺货（源于太平洋台风）。 财务影响： -$15,000,000。

这就是区别： 别的软件告诉你“船晚了”。 Palantir 告诉你“你会亏 1500 万”。

1.4 最后的闭环：决策与行动

你看着那个红色的警告，点开了详情。Palantir 的 AIP（AI 副驾驶） 已经跑了 1000 次模拟，直接给你三个按钮：

选项 A： 坐以待毙。后果：亏 1500 万。

选项 B： 空运紧急补货。

系统解释： 我找到了韩国的一家备用供应商，他们有货。空运成本 50 万美元，但能保住生产线。

净收益： 挽回 1450 万美元。

选项 C： 调整生产计划。

系统解释： 这 3 天改生产不需要这种螺丝的轿车。

最关键的动作—写回（Write-back）： 你按下了 “执行选项 B”。

Palantir 系统立刻、直接做了以下事情（这就是所谓的“操作系统”）：

自动给韩国供应商发了采购单（写入 SAP）。

自动给 DHL 发了空运单（写入物流系统）。

自动通知财务部门预留 50 万空运费（写入财务系统）。

而且系统会记住：谁点的、为什么点、当时看到的是什么信息。这叫“可追责决策”。

看完这个例子有没有清晰一点？上面这个例子是PLTR在商业领域的应用。PLTR不是单纯的分析工具，是可以落地到执行的系统，而且出事是可以追责的，企业和政府才敢用。

2、战争领域的例子

人物设定：你是某国联合部队的战区指挥官。

目标：72 小时内推进 40 公里，占领一座关键交通城市。

兵力：3 个主战旅 + 1 个装甲旅

后勤假设（极关键）：所有主力通过 X 河上的主桥，补给车 10 小时一趟，前线燃料安全库存：24 小时。

你的判断基础：地图、各兵种系统、情报汇总会议

突发事件：凌晨 03:10，情报回传：X 河主桥被炸毁，预计 48 小时无法通行。

2.1 没有 PLTR 的战争：系统如何一步步失控。

1）你马上“知道了事实”，做出经验判断（看起来完全合理）

你下意识会做三件事：

命令部队 绕行南侧备用路线

后勤单位 增加补给车出车频率

前线部队 继续推进，避免节奏中断

👉 在这一刻，你并没有犯错。

2）系统开始“悄悄变形”（你看不到）

现实中同时发生的是：

绕行路线：距离 +60%；单次补给时间从 10h → 18h

燃料消耗：装甲旅消耗 ↑30%

补给节奏：你“想加快”，但物理上做不到

⚠️ 此时没有任何“报警”，系统只是变慢。

3）部队状态开始分化（但你只看到局部）

12 小时后：

A 旅：推进慢，但补给尚可

B 旅：推进最快，燃料下降到 30%

装甲旅：仍在前压，但补给线被拉长

你看到的是：“整体还能打。”

你看不到的是：三个旅已经不在同一个系统状态里了。

4）敌军利用“你没意识到的窗口”

敌军并不需要知道你的全盘计划。

他们只需要观察到：你补给车的路线固定了，你侧翼的防御变薄了，你前线节奏出现不一致

于是他们选择：夜袭补给线，打击最缺油的装甲旅。

5）局部问题 → 全局战略崩溃

48 小时内发生：装甲旅被迫停滞，前线推进被切断，你被迫从“进攻”转为“止损”

这场战争并不是输在战术。而是输在：

你从未真正看清系统已经不可逆地失衡。

2.2 同一场战争，有 PLTR 会发生什么？

1）同样的事实进入系统（没有魔法）

桥被炸。PLTR 并不“更快知道”，它做的是下一步。

2）把“桥”放进整个作战系统

情报融合：把“不同来源、不同格式、不同可信度的战场信息”，融合成一个“可被决策使用的现实画面”。包括但不限于无人机实时画面、敌军位置点、己方火炮、部队状态，历史命中与失败记录。

系统立刻计算：哪些补给路线失效、各旅的燃料 / 弹药消耗曲线

在 T+12 / T+24 / T+36：哪支部队进入危险区、哪条补给线暴露

👉 你第一次看到的不是“现在”，而是“未来形态”。

3）并行推演你的所有选择，你不需要拍脑袋。

系统直接给你三条路径的结果：

方案 A：全军绕行，36 小时后：装甲旅断油概率 70%

方案 B：暂停 24 小时

风险：敌军反击概率上升

方案 C：收缩装甲旅 + 重构补给节奏，推进速度慢，但系统稳定

⚠️ PLTR 不说“选哪个”，它只告诉你：哪些选择会“必炸”。

4）敌军被当成“策略体”而不是变量

系统同步模拟：

如果你放慢推进 → 敌军是否敢出击

如果你改变补给路线 → 敌军是否还能预判

你第一次看到的是：敌军“最有可能”的反应区间。

5）你提前改写战略假设

你做出的调整：主动放弃原定 72 小时目标，重构补给与推进节奏，把“系统稳定”放在“速度”之前

结果：没有部队被打残，敌军错失窗口，战争进入你可控的节奏。

现代战争，本质是一场“对复杂系统未来形态的认知竞赛”。枪炮只是执行器，真正的战场在决策之前。

现代战争不是“谁打得更狠”，而是：谁能在行动之前，看见系统将走向哪里。

而 PLTR 干的那件事只有一句话：把“人类看不见的未来”，提前摊在决策桌上。

3、航空业的应用

上面供应链和战争的例子是PLTR两个典型的应用场景，航空业是另一个典型例子。

3.1 帮助空客解决产能爬坡危机

上面两个例子应该已经清楚的说明了PLTR到底是干什么的。下面的航空业例子会简单带过，重点是看PLTR怎么成为了航空业Skywise平台的底层技术供应商。

1）真实的痛点（2015年）： 空客 A350 的产能爬坡危机是真实的。核心问题在于 “数据割裂”。

制造一架飞机涉及几百万个零件、几千家供应商。

工程变更（CAD）、库存（SAP）、排产（MES）系统各自为政。

结果：当设计图纸改了一个螺丝规格，仓库不知道，采购不知道，产线直到装配那一刻才发现螺丝对不上。导致A350 在 2015 年前后确实遇到严重产能爬坡问题。

2）Palantir 真正做的事情（The "Ontology" Work）： Palantir 派出了 FDE（前瑞部署工程师） 进驻空客。他们并没有去拧螺丝，也没有去设计飞机，他们做的是数据层面的“本体构建”：

打通底层： 强行将不同系统的数据（设计、库存、进度）拉到一个逻辑层面上。

建立对象： 在 Foundry 系统里，定义了“飞机”、“工位”、“缺件风险”这些对象。

赋予因果： 系统能计算出：“如果这个设计变更生效，哪些在途的零件会报废？哪架飞机的交付会推迟？”

3）结果：生产效率提高33%

在特定的瓶颈环节（例如总装线的某些关键节点），通过消除“因缺件等待”的时间，实现了显著的效率跃升。

Palantir 是这个提速过程中的关键赋能工具（Enabler），因为它让管理层第一次看清了瓶颈在哪里。

3.2 航空业Skywise平台建立

时间： 2017年 - 至今 转折点： 空客和 Palantir 意识到一个巨大的机会——既然能用数据帮空客“造”飞机，为什么不能用数据帮航空公司预测性维护等多场景应用？

于是，Skywise 平台诞生了。

以前：在传统模式下，航空公司主要基于自身机队数据进行维护决策。由于许多关键部件的失效属于低频事件，仅依靠单一航司的数据，往往难以及时识别潜在风险。

现在： Airbus 主导搭建平台，Palantir 作为关键技术与交付伙伴参与早期和扩展阶段，让全球的航空公司都在Skywise 平台上面跑数据。（从“单航司经验”到“群体经验”）。

核心应用场景：预测性维护 (Predictive Maintenance) 这又是 Palantir “把 AI 变成行动”的经典例子。

没有 Skywise： 一架飞机飞到伦敦，降落后飞行员报告：“3号液压泵坏了。” 后果： 航班取消，几百名旅客滞留，连夜从总部调零件，亏损几十万。

有了 Skywise (Palantir)： 飞机还在大西洋上空飞着。 飞机上的传感器（像智能手环一样）每秒传回几千个数据：温度、震动、压力。 Palantir 的本体模型捕捉到一个微小的异常信号（比如震动频率稍微高了一点点）。 系统推演： “虽然现在没坏，但根据全球 10,000 架飞机的历史数据，这个震动意味着液压泵将在 5 次飞行后 失效。”

行动（Action）： 航空公司基于这些预警信息，由工程与维修团队进行评估和决策，提前准备备件，并将维修安排在对航班影响最小的时间窗口（如夜间停场或计划性过站）

结果： 旅客没有任何感觉，航班准点起飞。这就是航空公司愿意付大钱的原因——消灭延误。

通过提前规划维修，航空公司显著降低了非计划停飞和技术性延误的发生概率。对乘客而言，航班按计划起飞；对航司而言，运营更加可控、成本更低。

总结一下：PLTR像一本把“这个组织在什么情况下，应该怎么做事”写成代码的说明书。

而且这本说明书有 4 个特点：

谁能看什么，写死在系统里（权限）

每一步决策都有记录（审计）

AI 给建议，但人来点确认（可追责）

出事后能回放全过程（复盘）

很多公司：“我们有 AI！”

但问题是：AI 说的对不对？谁来负责？能不能用在生产环境？

PLTR 的 AI（AIP），不是让 AI 自由发挥，而是：把 AI 关进“组织的笼子”里。

这个“笼子”包括：权限（你能问什么）、数据边界（你能看什么）、输出约束（你能建议什么）、审计（你说过什么）。

👉 所以 PLTR 的 AI 是“可用在真业务里的 AI”，不是 demo。

AIP 可以：帮你算方案、帮你预测结果、帮你发现风险。

但：它不能越权、它不能偷偷做决定、最后的按钮，必须是人按的。

这正是政府和大公司敢用它的原因。

看完上面的三个例子，是否只是对PLTR具体是干什么的多了一点了解呢？下一篇将结合PLTR的四个平台，具体分析PLTR的系统是如何运转的。

以上是关于PLTR公司的业务分析，欢迎大家多多交流。

声明：文章内容仅供参考，不构成投资建议。投资者据此操作，风险自担。