别让大模型对着文档瞎猜:看看 Palantir 在车企怎么干

一家欧洲大型汽车零部件供应商碰上一个质量问题，一开始圈出来的受影响车辆有 200 万辆。最后精确缩到 3.5 万辆，质量成本从 4.9 亿欧元降到 850 万欧元。

数字来自 Palantir 2023 年的汽车质量白皮书，客户没点名。帮他们把范围缩小的，是一张把每辆车、每个零件批次、每家供应商、每条索赔都连起来的“地图”。Palantir 管这张地图叫 Ontology，在上面跑大模型的平台叫 AIP。

这篇拆三个汽车案例，再讲这套东西怎么一步步搭起来。判断先放这儿：企业 AI 落地，先缺的是地图，模型排第二。

Ontology 这个词本来是哲学里的“本体论”，听着很玄。Palantir 官方文档说得很直白：它是一家企业的数字孪生，把散在各个系统里的数据，对应到真实世界的东西上，工厂、设备、产品、客户订单都算。

放到车企里，这张地图只有三样东西。

第一样是对象。一辆车（带 VIN 码）、一个零件、一家供应商、一条产线、一张订单、一条保修索赔，各是一个对象，带着自己的属性：生产日期、批次号、当前状态。

第二样是关系。这辆车装了哪个批次的零件，这个批次是哪家供应商供的，这条索赔对应哪辆车。这些信息车企本来都有，只是散在 ERP、MES、质量系统、经销商系统里，没人把它们连起来。

第三样是动作。批准一个排程、关闭一条警报、发起一次工程变更。谁能做、做完写回哪个系统，都定义在地图上。

第三样是它和普通数据看板拉开差距的地方。看板只能看，这张地图能改。Palantir 文档里有句话：“The Ontology represents the decisions in an enterprise, not simply the data.” Ontology 表达的是企业里的决策，光有数据不够。

那 AIP 呢？全称 Artificial Intelligence Platform，Palantir 的 AI 平台。说白了，就是让大模型在这张地图上干活：它查的是地图上的对象，调的是地图上的计算逻辑，做的是地图上定义好的动作，权限跟人一样管。

J.D. Power 的例子最好懂。这家汽车数据公司 2023 年在 Palantir 的 AIPCon 大会上演示一个选车助手，首席数字与技术官 Bernardo Rodriguez 先吐槽：你去问 ChatGPT 训练数据截止到什么时候，它说 2021 年 9 月，这样的 AI 怎么帮我现在买车？他们的做法是把 Ontology 放在中间，提示词里直接写死只用 J.D. Power 的车辆数据：“don’t go crazy and go back to 2021”，别发疯翻回 2021 年去找资料。

大模型的聪明还在，可它说的每句话都得落在地图上。这就是 Ontology 加 AIP 的基本思路。

Palantir 博客里还有一层说法，我很认同：每上线一个 AI 助手，就当来了个新同事。默认情况下它只能“拟”动作，比如改工单状态、推一版调配方案，交给人做最后复核；用久了、信得过的流程，再慢慢放手让它自己闭环。

Lear 是美国最大的汽车供应商，做座椅和电子电气系统。它给主机厂干的是 JIT，just in time，准时化生产：主机厂下了确定订单，Lear 只有 4 小时，座椅就得出现在对方总装线的安装工位上。

难在哪？Lear 全球先进制造副总裁 Jennifer Johnson 在 AIPCon 上算过：一套座椅平均要拣齐 350 个不同料号的零件，每小时发运 60 套，一天 24 小时、一周 5 天地跑。Lear 全球有 175 家以上 JIT 工厂，每天要做几千个决策。

他们先把地图接起来：产线状态、从二级供应商那边在路上的来料、物料清单（BOM）和标准工时、成品库存还剩多少位置。这些在一个“控制塔”界面里一屏看完，旁边的异常看板上，计划员专门处理缺料和生产警报。

最见功夫的是急单。客户临时在 4 小时窗口里插一单，原来的排程就得打乱。现在的流程是这样：AIP 先发出急单提醒；计划员运行一个排程 Agent，也就是能自己调工具、跑流程的 AI 助手，它对照 BOM 和标准工时，给出这个班次里怎么插单，顺带算清对排程和库存的影响；运营团队审核方案，对比次优方案，批准或者上报；确认后，任务排进计划，写回 Lear 的 MES，也就是车间执行系统。

Johnson 的原话是：“Foundry delivers the decision layer while the plant operations team brings practical product and supply chain and manufacturing know-how.” Foundry 提供决策层，工厂运营团队带来产品、供应链和制造上的实战经验。Foundry 是 Palantir 的数据平台，Ontology 就建在它上面。

她说最有成就感的是那种豁然开朗的时刻：一个生产计划员发现，自己不用再每天花几个小时翻 Excel、开电话会，跟墨西哥的同事对库存了。

结果呢？Lear 已有 11,000 多名员工 在用这套东西，2025 年 9 月又把合作扩大了 5 年。Lear 还说，它的 IDEA 转型计划 2025 年上半年省了 3,000 多万美元，Palantir 在里面“发挥了重要作用”。这笔账算在整个转型计划上，别全记在 AI 头上。

车企最贵的一类麻烦，是质量问题在用户手里冒出来。Palantir 的白皮书写，车企每年保修支出超过 10 亿美元并不罕见；质量问题通常在发生 15 周以后才被发现，从出问题到彻底解决，平均要 36 周。

慢在哪？索赔进来，常常要过好几天甚至几周才有人手工处理。网联车回传的大量故障码和传感器数据，多半没人用，因为它们跟索赔、车辆配置、供应商信息不在一处。

Palantir 的质量方案叫 QMOS，质量管理操作系统。它也是先画地图，喂进去的东西包括：保修索赔、经销商读出来的故障码、车辆遥测、OTA（远程在线升级）记录、每辆车的配置和供应商信息、下线检测数据、换件记录，连售后呼叫中心的记录都有。它从 ERP、质量系统里读，也写回去，原来的系统不用换。

AI 在这上面干两件事。一是给索赔打标签、自动分类，规则可以人定，也可以由 AI 生成；二是把相似的问题自动聚成一类，每个新聚类直接告诉你：路上跑的车里可能有多少受影响，建议怎么处理。

供应商那边配套的东西叫 CPM，零部件性能监测器。主机厂和供应商在同一张地图上协作，权限按零件切：供应商的质量工程师只看得到跟自己零件有关的车辆数据，数据的主人决定给谁看什么。

白皮书里给了几组结果，客户都没点名。一家欧洲标杆主机厂，问题识别和验证平均缩短 8 周，也就是 50%；试点 8 周内，37% 的索赔实现了自动分类。开头那家欧洲供应商，用的是 CPM 的追溯能力：受影响车辆从 200 万辆精确圈到 3.5 万辆，质量成本从 4.9 亿欧元降到 850 万欧元。

200 万到 3.5 万，模型推理再强也推不出来。它靠的是“这辆车装的是哪个批次的哪个零件”这条关系，在地图上真实存在。没有这条线，再聪明的模型也只能猜。

第三个案例在电池厂。松下能源北美（PENA）造动力电池电芯，产线设备多，坏了得修。

麻烦在于经验散得到处都是：大约 100 万张历史维修工单，几千份复杂的机器图纸和 PDF，大量设备传感器数据，分别存在工单系统、资产文档、传感器系统和停机记录里。技术员修一台机器，得在好几个应用之间来回翻。

他们的 Ontology 把这些揉到一起：历史和当前的工单、同事之间的往来沟通、以前试过哪些修法、设备告警，还有对应这台机器的 PDF 和修复方案。界面上，每台机器的数字版本和车间里那台实物一一对应。

AI 这层，技术员直接提问，AIP 翻完全部历史，给出摘要和推荐动作。底下是语义搜索，覆盖 10 万多张工单、1,400 多份 PDF 和设备监控数据。技术员觉得建议好不好用，点个赞、点个踩，或者写一句话，反馈写回去，建议越用越准。

结果：从做用户访谈到车间里见效，不到 6 个月；每张工单的维修作业时间降低 10–15%，而他们每月有几万张工单。一位二级维修技师的评价很接地气：“[This platform] is not a PowerPoint, it helped me solve a real issue this morning.” 这个平台可不是 PPT，今天早上就帮我解决了一个真问题。他还说，这东西让初级技师和资深技师站到了差不多的起跑线上。

这里 AI 也在读 PDF。差别在于，每份 PDF 都挂在一台具体的机器上，跟它的工单、告警、修理记录连在一起。同样是喂文档，一种做法是把文档倒进知识库让模型自己捞，另一种是让文档长在地图上。

三个案例看下来，搭法其实差不多。我把它归成四步。

第一步，挑一个要命的决策。别一上来就“建数据中台”。Lear 的起点是一小群人做的第一个用例：先做生产支持，再接 MES、做监控，再进供应链，最后才到 JIT 动态排程。PENA 的起点是技术员修机器太慢。

第二步，只画这个决策用得上的那块地图。Palantir 文档有个很好懂的类比：一个对象类型约等于一张表，一个对象约等于一行，属性是列，关系是表与表之间的关联。不同的是，地图上的东西叫车、零件、工单，业务的人一看就懂。画小一点没关系，PENA 的电极控制塔，第一个能跑的模型一周就出来了，整个用例一个月交付。

第三步，定动作和权限。谁能批准排程，改完写回 MES 还是 ERP，供应商能看到哪些数据。QMOS 读写原来的系统、不替换；CPM 按零件切权限；Lear 的排程最后写回 MES。这一步决定了 AI 将来能碰什么、不能碰什么。

第四步，让 AI 上岗，人来拍板。AI 先给方案、拟动作，人审核、批准或上报，反馈再写回地图。跑顺了的环节，再逐步放权。

顺序为什么不能反？看 Stellantis。这家旗下有 14 个品牌的车企，跟 Palantir 的合作从 2016 年就开始了。2026 年 3 月续约时，它开始部署 AIP，官方新闻稿专门写了一句：AIP 的集成，以 Stellantis 在 Foundry 里已经建好的 data ontology 为基础。地图早就在了，AI 是后来请进来的。

很多人以为企业上 AI，就是“接个大模型”。可真正卡人的，往往是第二步：一辆车、一个零件、一张工单，在系统里到底长什么样，谁也说不清。这一步跳过去，后面的 Agent 就只能对着一堆文档猜。

也别把它想得太轻松。Lear 那位副总裁在台上说得很实在：“It’s not an out-of-the-box solution. It’s not a flip the switch project.” 它没法开箱即用，也没有一个开关一按就成。价值来自跟 Palantir 团队的深度合作，加上企业内部长期投入时间和资源。

Palantir 官网说，全球前十大车企里的大多数、30 多家主要零部件供应商在用它的软件。可翻完公开案例你会发现，大多集中在质量、供应链和制造这些对象清楚、动作明确的环节。地图好画的地方，AI 先落地。

所以，如果你的公司也在琢磨上 AI，先别急着问用哪个模型。先问一句：我们那张地图在哪？

这是 Palantir 行业案例系列的第一篇。下一篇聊飞机制造：一架空客 A350 有约 500 万个零件，交付速度提了 33%，那张地图又是怎么画的。

关注「17点59分」，后台私信关键词「FDE」领取 FDE 学习资料。

如果觉得这篇文章有用，欢迎转发给更多人看。