5.6 案例：Palantir 与 Airbus —— 本体如何撑起一个行业平台
承前：前五节我们围着一张青禾的沙盘转，这一节把视角拉到产业史里最著名的一次"本体工程"——Palantir 与 Airbus 从 2015 年开始的合作，以及它长出来的行业平台 Skywise。这个案例的价值不在"大厂真厉害"，而在它把本章所有概念（本体、语义层、驻场交付、遗留集成、安全边界）在一个极端环境里推到了极限：五百万个零件、四个国家、互相竞争的航空公司要共享数据。看完你会对"本体与语义层的天花板在哪"有体感。
5.6.1 起点：A350 产能危机（2015）
故事的开局是一个生产问题。2015 年底，空客急需提升 A350 宽体机的产量——这是一架由约 500 万个零件组成、由分布在四个国家八座以上工厂的数百个团队协作制造的飞机。驱动生产的数据（排程、班次、零件到货、工单、质量缺陷）同样散落各国各团队。
产能不能靠加人解决——数据不通，瓶颈看不见。空客的工程师们被简单的问题困住：某个缺陷发生的频率是多少？它下游会造成多少返工和延误？哪个维修任务其实已经完成了？每个问题都要跨系统、跨团队、跨国家去拼答案。
Palantir 的法国团队从 2015 年起进驻空客——不是远程交付，是把工程师派进图卢兹的工厂里，和制造团队一起上班。有亲历者回忆自己在图卢兹驻场一年、每周四天泡在产线旁，做出的第一个产品是"A350 生产的 Asana"——一个建在制造数据本体上的工单协作工具。据 Palantir 官方合作资料与亲历者公开叙述。
这个开局值得每个 FDE 记住：**平台级合同的第一行代码，往往是给一线工人写的一个工单工具。**先在真实工作流里赢一次小的，才有后面的一切。
5.6.2 Foundry Ontology 在其中做了什么
把排程、零件、缺陷数据整合起来，技术上不是"灌进一个数据仓库"就完事。Palantir 路径的核心是 Foundry 的本体（Ontology）层：把散落的表映射成对象（飞机、零件、工单、缺陷）、链接（这架飞机装有这个零件、这个工单处理这个缺陷）、动作（完成工单、升级缺陷）——分析、协作工具、决策应用全部挂在这同一套语义上运行。
按 Palantir 官方文档的表述：本体是集成进平台的数据资产与其现实对应物之间的映射——从设备、产品到客户订单、财务交易，许多场景下本体的角色是"组织的数字孪生"，语义元素（对象/属性/链接）加动力元素（动作/函数/动态安全）支撑各类用例。
在空客的场景里，本体的价值具体化成三件事：
- 缺陷分析有了统一语言：某类缺陷在哪个工厂、哪批次零件、哪些机队上发生——问题从"问五个团队拼三天"变成"对象查询几分钟"。Palantir 披露空客得以在平台上每天测试数百个场景、把根因定位压缩到小时级，维护优化对应的价值据其估算达数百亿美元量级（据 Palantir 合作资料）。
- 决策与执行合一：发现缺陷 → 决定处理方案 → 派工单，全部走本体的 Action 类型——受权限管控、有审计、提交后对所有应用生效。排程的变更不是一个部门 Excel 里的一行，而是本体上一个留痕的事务。
- 安全内建于语义：谁能看哪个机队的数据、哪个供应商能看到自己零件的缺陷——权限不是外挂在报表层的补丁，而是本体粒度的属性（动态安全）。这一点是下一节 Skywise 能成立的前提。
5.6.3 Skywise：从一家工厂到一个行业
2017 年，双方把合作扩大为 Skywise——面向整个民航业的数据平台。空客提供航空制造与在役数据（工单、备件消耗、部件数据、机队构型、机载传感器数据、航班计划），Palantir Foundry 做数据底座，航空公司把运营数据汇入这个"安全生态"。据 Palantir 官方案例页与空客新闻稿。
Skywise 要成立，最难的不是技术，是信任：让互相竞争的航空公司把运营数据放进同一个平台。这里本体+安全模型的价值被推到极限——每家航司的数据在自己的安全围栏内，分析在受控的聚合层进行；一家航司的运营细节不会泄漏给竞争对手，但全行业的基准数据（同型号机队的故障率分布）人人可查。"隔离下的共享"是数据平台的最高境界，也是青禾案例里"三个部门不信任彼此的数"的极端放大版——Palantir 用本体粒度的权限体系回答了"凭什么信你"。
规模数据（均据 Palantir / Airbus 官方与合作资料披露）：A350 交付节奏在合作推动下提升（Palantir 合作资料称加速 33%）；Skywise 已接入超过 100 家航空公司，日常依赖该平台的用户超过 50,000 人（2026 年续约新闻稿口径），覆盖计划、供应链、飞机构型与航司运营。2026 年 2 月，双方续签多年协议，Foundry 继续作为 Skywise 的数据底座，并明确支持向主权云环境的迁移——数据主权成了欧洲产业平台的采购硬条件，这个趋势值得每个做 To B 的人记住。
5.6.4 对 FDE 的四个可迁移启示
**启示一：本体是"长"出来的，不是"设计"出来的。**Palantir 不是先画一张完备的航空业本体再请空客用——是从 A350 产线的工单、缺陷这两个对象开始，在真实工作流里长，长到机队、长到全行业。青禾同理：从会员、订单、券四个对象起步，不要追求一步到位的企业级本体。本体的完备度应该追随用例，而不是追随蓝图。
**启示二：驻场的本质是"用客户的工作流学语义"。**Palantir 工程师在图卢兹工厂里学的不是代码，是"缺陷"在空客车间里到底指什么、"完成"在夜班和白班有什么不同——这些语义任何文档里都没有，只能靠驻场吸收。这是 FDE 存在的根基性理由，也是本书 W2 访谈方法论的行业级印证。
**启示三：数据平台的护城河是治理不是算法。**Skywise 十年长盛不是因为模型多好，是因为"互相竞争的航司愿意把数据放进来"——这是权限体系、审计、安全边界的胜利。你做的 Agent 项目同理：客户三个月后还在用，靠的是口径有 owner、动作有围栏、建议有证据，而不是模型代际。
**启示四：平台化是后见之明，不是第一天的目标。**2015 年没有人说"我们要做行业平台"——只有一架要加产的飞机。平台是持续解决具体问题的副产品。给青禾做"建议型 Agent"的你，别在 W5 就开始畅想"零售行业数据平台"——把半沉睡会员唤醒这一个闭环做到采纳率 60%，行业化的种子自然在其中。
在把 Airbus 剧本压回沙盘之前，先补一块 FDE 视角的关键拼图：Palantir 的交付模式正是"前置部署工程师"（Forward Deployed Engineer）这个词的行业出处。Palantir 从创立早期就坚持工程师驻场、在客户业务现场写代码的交付形态——它卖的不是软件 license，而是"平台 + 驻场工程"的组合。这套模式 2015-2026 在 Airbus 身上跑了十年以上：从一队工程师解决一架飞机的产能问题，长成一个行业平台和多年续约。这正是本书第 1 章讲 FDE 职业时反复引用的行业原型——而 OpenAI 2025 年组建 Deployment Company、Anthropic 组建企业 AI 服务团队，走的是同一条已被 Palantir 验证过的路。
5.6.5 落到沙盘：如果青禾要走"平台化"
把 Airbus 的剧本压回青禾尺寸，能看到一条清晰的路径可能性（仅作教学推演，不是青禾的实际规划）：
- 阶段一（已发生）：一个用例（半沉睡唤醒）跑通最小闭环——对应 A350 产线上的工单工具；
- 阶段二（v1 可见）：扩展到新客、流失预警、门店补货建议等用例，全部挂在同一套本体+语义层上——用例变多，本体随之"长"出新对象（商品、库存）；
- 阶段三（远期推演）：如果青禾是连锁加盟模式，加盟店与品牌方之间的数据共享困境（总部看不到门店实时库存、门店不信任总部的券策略）就是"迷你版 Skywise 问题"——隔离下的共享、本体粒度的权限、双向对账。那时 5.2 节的本体和 5.3 节的语义层就从"项目资产"升格为"企业基础设施"。
这个推演的教学价值在于校准野心：阶段一的采纳率没到 60% 之前，所有关于阶段三的讨论都是娱乐。Palantir 用了两年才从一架飞机走到行业平台——平台的每一层都要下一层用真实使用喂饱之后才能开工。
5.6.6 To B 常识补课：产品、定制、二开，私有化与 SaaS
Palantir 案例还能带出一组 To B 采购常识，做 FDE 迟早要用：
**产品 vs 定制 vs 二次开发。**产品（product）：标准功能，卖license，厂商升级你跟着走——最便宜但合身度最低。定制（custom/bespoke）：从零为单个客户造——合身但贵、慢、后续维护责任纠缠。二开（extension on a platform）：在标准产品提供的扩展点（API、本体注册、工具注册）上叠加客户专属逻辑——这是 Palantir 的实际形态（Foundry 是产品，空客的本体和用例是客户侧资产），也是本书一直教你的形态：标准 Agent 底座 + 青禾本体/语义层/Action。你的项目价值大部分沉淀在"客户侧资产"里，这决定了交付物要按资产标准（版本、文档、owner）移交。
**私有化 vs SaaS。**SaaS：厂商云上多租户，快、便宜、自动升级，但数据出客户的墙。私有化（self-hosted/on-prem）：跑在客户自己的基础设施里，数据不出门，但升级、运维都要人扛。判断题只有一道：数据主权与合规要求。航空（Skywise 走主权云）、金融、政务天然偏私有化；青禾这类零售企业试点期用 SaaS/托管完全够，全量推广时再议。注意 2026 年续约里"主权云迁移"是显性条款——欧洲市场这已经是采购的门槛条件，中国市场的数据出境与等保要求同理。做方案时把这条边界提前问清楚，能省掉后期一次架构返工。
5.6.7 要点总结
- Palantir-Airbus 从 2015 年 A350 产能问题起步：工程师驻场图卢兹，从工单工具做起——平台的第一行代码常是给一线写的小工具。
- Foundry Ontology 把排程/零件/缺陷数据整合为对象/链接/动作的"数字孪生"：缺陷分析统一语言、决策执行合一（Action 事务化）、安全内建到本体粒度——三件事共同支撑了 Skywise。
- Skywise（2017 起）证明"隔离下的共享"是数据平台最高境界：100+ 航空公司、5 万+ 用户同平台，竞争者共存靠治理不靠算法；2026 年续约与主权云条款显示数据主权已成采购硬条件。
- 四个可迁移启示：本体随用例生长不追随蓝图、驻场是为了吸收文档里没有的语义、护城河是治理、平台化是副产品。
- To B 常识：产品/定制/二开三档，你的交付价值沉淀在客户侧资产；私有化 vs SaaS 的判断题只有数据主权一道，提前问清省一次返工。
参考资料
- Palantir Impact: Airbus and Skywise（官方案例页） — A350 五百万零件、四国八厂的挑战描述与 Skywise 定位的一手来源。
- Palantir and Airbus Extend Strategic Collaboration（Palantir IR 新闻稿，2026-02） — 多年续约、50,000+ 用户、主权云迁移条款的官方口径。
- Palantir-Airbus Partnership Overview（Palantir 官方 PDF） — A350 交付加速 33%、100+ 航司接入、平台价值估算的官方合作资料。
- Palantir Foundry Ontology 官方文档：Overview — 对象/链接/动作与动态安全、"数字孪生"定位的权威定义。
- Airbus launches Skywise（新闻稿） — 2017 年 Skywise 发布的原始报道：数据源清单（工单/备件/构型/传感器/航班计划）与"开放数据平台"定位。