Palantir 案例｜6500 家餐厅，一个 Execute 按钮

作者：Nick Zhu

这个案例最重要的启发，不是 AI 取代了供应链团队。Palantir 帮助 Wendy’s 的 Quality Supply Chain Co-op 把餐厅订单、库存位置、生产约束、建议方案与可执行动作，连接成一个决策系统。在公开演示中，仍然由人审阅建议并点击 Execute。

标题所指的是这个界面时刻，并不表示一次点击完成了端到端流程。公开演示展示了不止一次由人触发的 Execute 行动，响应过程从建议订单继续推进到原料订购。

这是一篇基于客户、供应商、监管披露与媒体公开资料的案例分析，不是独立审计，也没有揭示 QSCC 未公开的技术架构、权限配置、模型逻辑、项目成本或企业级投资回报。

供应短缺在事后很容易描述：一个配送中心库存不足，网络其他地方还有货，于是应该调一些过来，或者再订一些。

真正困难的是运营问题。哪些餐厅可以少分一点？哪些餐厅必须保留分配，才能撑到下一辆卡车到达？其他节点能释放多少库存？还需要生产多少？原料是否足够？谁有权把建议转成订单？执行后的新状态又在哪里成为权威记录？

2025 年 3 月，在 Palantir AIPCon 6 上，时任 QSCC 总裁兼 CEO Pete Suerken 用一次 Thin Mints Frosty 糖浆短缺，展示了这些问题如何被连接起来。他表示，演示中的处理大约用了 5 分钟；一年前，同样的工作需要 15 个人忙一整天，第二天还要重新来过。

这个对比很有吸引力，但它仍然是一次客户大会演示中的客户自述，不是经过独立审计的生产率结果。与其把“5 分钟”扩张成通用承诺，不如拆开看清这 5 分钟背后的运营设计。

这不是一个总部在优化 6500 家直营门店

QSCC 是服务 Wendy’s 美国和加拿大体系的独立、成员所有、非营利性采购合作社。根据 QSCC 自身介绍，它拥有近 40 亿美元的采购力。Wendy’s 的监管文件进一步说明，公司并不控制 QSCC 的决定与活动；参与合作社的加盟商最终控制这家合作社。

公开口径也会随时间与场景变化。2024 年 8 月的合作公告写的是 6400 多家餐厅；2025 年演示使用了约 6500 家餐厅的实际订单。本文以“6500 家”作为演示口径的约数，不把它写成固定不变的数量，也不把它误作 Wendy’s 全球全部餐厅。

这一区分很重要，因为协调问题跨越了多个组织边界：餐厅产生需求，合作社协调采购，配送中心保存并调度库存，供应商与生产点形成供给，原料又约束着能够生产什么。挑战不只是把更多数据收进一个组织层级，而是让分布式的运营状态变得足够清晰，从而支持协同决策。

案例结构 · 公开资料视图

一个跨组织边界的决策网络

1. 01餐厅订单与本地库存信号
2. 02QSCC合作社协调与决策工作
3. 03配送中心库存位置与分配
4. 04供应商与生产可用箱数与生产计划
5. 05原料限制可生产数量的条件

需求向上游移动；供给、分配与证据再沿网络返回。

这张图只表达公开资料中可见的关系，不是 QSCC 披露的 Palantir Ontology、系统架构、合同流程或权限模型。

换成文字：餐厅订单与库存信号连接到 QSCC 协调、配送中心分配、供应商与生产能力，以及原料约束。需求向上游移动，供给决策与证据再沿网络返回。

5 分钟演示中究竟发生了什么

当时的促销产品是 Thin Mints Frosty。演示首先接入了约 6500 家餐厅对 Frosty 产品的实际订单。

系统发现 Oregon 配送中心存在风险：Thin Mints 糖浆手头有 11 箱，在途 70 箱。但整个网络仍有大约 4 天的供应量。问题不只是总量不够，而是库存放错了位置。

接下来的处理穿过了多个层次：

1. 应用建议削减或取消库存超过 3 天的餐厅订单。
2. 它按照每家门店距离下一辆卡车到达的时间判断是否可以少分货。演示中的说法是 3–4 天后，不是下午 3–4 点。
3. 系统并未一刀切。Suerken 展示了一家订购 5 箱的餐厅；由于它需要库存撑到下一次配送，系统仍然为它保留 2 箱。
4. 分析从 Oregon 的局部例外扩展到整个网络，再进入供应商可用量、生产需求与原料约束。
5. 应用把原料订购、生产、供应商配送中心与 QSCC 配送中心之间的响应组织成 10 个步骤。
6. Suerken 审阅建议并点击 Execute。订单状态变为已下单，随后他又触发了原料订单。

从信号走向行动，才是这个案例的核心。短缺没有停留在数据看板上的红色单元格，也没有成为演示文稿里的一条建议。应用把例外、门店级选择、网络替代方案、行动计划、人的决定与改变状态的执行连接在一起。

Thin Mints Frosty · 演示顺序

从局部短缺信号到订单下达

1. 01实际订单约 6500 家餐厅
2. 02局部例外发现 Oregon DC 风险
3. 03门店订单保护刚需，削减富余
4. 04网络搜索寻找其他节点供给
5. 05生产计划暴露原料约束
6. 06人工审阅检查建议方案
7. 07Execute 行动由人触发下单并更新状态

这是对公开 AIPCon 演示的重建，不证明 QSCC 的每个例外都遵循完全相同的顺序，也不代表所有行动均为自动执行。

换成文字：餐厅实际订单暴露配送中心的局部例外；应用调整门店订单、搜索整个网络、进一步展开生产与原料计划、提交人工审阅，并把获准建议转成由人触发的订单与状态更新。

3500 与 2800 属于两个不同层次

这段案例很容易被误读，因为多个数字在演示中紧密出现。

在网络供给层，应用显示全网短缺 10200 箱，同时显示有 8300 箱可用供给；系统建议立即订购 3500 箱。公开演示没有把这三个数字表达成一道简单减法，因此不应该据此反推一个未披露的优化规则。

在生产层，网络需要生产 5800 箱，而现有原料只够覆盖 3000 箱，由此形成 2800 箱的原料缺口。

公开演示没有证明 2800 的缺口决定了 3500 的订单。一个数字描述为计划生产补足原料的缺口，另一个数字是网络层面的立即订购建议。把两个层次分开不只是算术严谨，也说明为什么决策系统需要连接库存、地点、生产与原料之间的关系，而不是只显示一个短缺总数。

数字地图 · 两个不同层次

不要把两个决定合并成一道算式

网络供给层

重新分配与订购

显示的短缺

10,200

显示的可用供给

8,300

建议立即订购

3,500

生产层

生产与原料采购

需要生产

5,800

现有原料可覆盖

3,000

原料缺口

2,800

所有数字均为客户演示中的箱数。两栏描述不同的运营层次；公开资料没有披露底层目标函数、约束或计算逻辑。

换成文字：网络供给层显示短缺 10200 箱、可用供给 8300 箱，并建议立即订购 3500 箱；生产层显示需要生产 5800 箱、现有原料可覆盖 3000 箱，因此原料缺口为 2800 箱。它们属于两个运营层次，公开演示没有披露两者之间的计算关系。

运营转变：从共同图景到可执行决定

2024 年合作公告把第一阶段描述为将分散数据连接成一个“共同运营图景”。第二阶段列出了 Dynamic Inventory Management（动态库存管理）、Demand Deviation and Allocation（需求偏差与分配），以及 Variance and Gain Information for Restaurants（餐厅差异与收益信息）等目标用例。连接供应商、分销商与餐厅的未来生态，则被描述成发展方向，而不是已经完成的状态。

我对 2025 年演示的理解是，实际改变不只发生在可见性上，还包括五个方面：

1. 状态被连接起来。 餐厅需求、库存位置、配送时间、生产与原料能够被共同考虑。
2. 例外拥有运营上下文。 Oregon 的警报可以与全网供应，以及每家餐厅还能等待多久一起判断。
3. 替代方案变成行动。 系统从发现问题推进到准备重新分配、订购与生产步骤。
4. 权力仍然可见。 在演示中，由一个可识别的人审阅并触发高重要性行动。
5. 执行写回新状态。 触发之后，建议订单变为已下单，下一轮决策因此拥有新的运营状态。

这就是案例与 AI 原生运营模式连接的地方。价值不是在业务之上放置一个抽象的智能层，而是在一个有界回路中，让数据、关系、决定、权力、行动与证据保持连接。

Palantir 的通用 Ontology 文档解释了平台如何表达对象、属性、关系、行动与函数，但 QSCC 的真实对象模型、集成、行动定义与安全配置没有公开。所以下图是我对演示的运营模式解读，不是客户披露的实施架构图。

Nick 的解读 · 不是已披露架构

演示背后的决策回路

1. 01运营状态订单、库存、时间、生产与原料
2. 02关系哪些餐厅、DC、供应商与原料相互影响？
3. 03例外网络在哪里超出了预期边界？
4. 04响应选项重新分配、订购、生产或保持
5. 05人的权力审阅并触发高重要性行动
6. 06行动与写回改变订单并保留新状态

执行后的状态成为下一次运营决定的证据。

这是可迁移的分析框架，不是 QSCC 精确数据模型、软件顺序或治理设计的证据。

换成文字：相互连接的运营状态与关系暴露例外；系统准备响应选项；人对高重要性行动行使权力；执行写入新状态，再成为下一次决定的证据。

一个 Execute 按钮不等于无限自主

界面上的瞬间很有视觉力量：审阅计划，点击 Execute，订单状态随即变为已下单。但这个按钮不能被误读成治理已经消失。

公开演示支持三个有边界的判断：系统发现并分析了例外；它准备了一组多步骤响应；屏幕中的高重要性订单由人触发执行。

公开资料没有披露谁能访问哪些数据、适用什么批准阈值、哪些行动需要第二位审阅者、点击前后是否有步骤自动运行、如何中断一项行动，或由谁承担合同责任。Palantir 平台可以支持细粒度的行动权限与对象权限，但产品能力不等于 QSCC 已采用某种具体配置的证据。

在 2024 年 11 月 Bloomberg 的报道中，让较小的库存与订货任务实现自主处理，仍被描述为未来方向。这并不与 2025 年演示冲突，反而帮助我们看清边界：系统可以越来越强，但高重要性权力仍然需要被明确设计，而不能被默认交出。

权力边界 · 已观察与未知

Execute 瞬间证明了什么，又没有证明什么

演示中已观察

系统准备，人来触发

• 发现例外
• 建模替代方案
• 准备多步骤响应
• 人触发 Execute 行动

公开表达的方向

较小任务可能走向自主

• 面向未来的表述
• 没有公开阈值
• 不证明全面自主

尚未公开披露

真实治理配置

• 角色权限
• 批准阈值
• 覆盖与恢复规则
• 合同责任

案例支持演示场景中的人工触发执行，不证明存在一种通用批准模型，也不证明端到端无人值守自动化。

换成文字：演示显示系统发现例外并准备响应，然后由人点击 Execute；较小任务自主化是公开表达的未来方向；真实角色权限、批准阈值、覆盖规则与责任归属并未披露。

公开证据可以证明什么，又不能证明什么

这个案例拥有不止一种公开证据，但不同来源的证明力并不相同。

合作关系、机构角色、初始项目范围、餐厅数量与演示顺序都有公开记录。QSCC 与 Palantir 报告了更快的决策工作、实时订单与库存跟踪、资源重新分配，以及库存效率改善。Wendy’s 的 2024 年企业责任报告表示，系统使用单店销售趋势改善订货预测，以减少过量库存、浪费并节省费用。

这些是有价值的客户与供应商披露，但没有公开基线、测量方法、改善百分比、合同成本或独立审计。我所查看的监管文件也没有披露可归因于 Palantir 项目的企业级库存降幅、缺货率降幅、浪费降幅、工时节约或已实现投资回报。

这不代表一切都不确定，而是意味着主张边界需要更严格。

证据边界

公开案例中的三类证据状态

01 · 有公开记录

公共结构与演示

• 合作关系与项目范围
• 来自约 6500 家餐厅的订单
• 箱数与行动顺序
• 人工触发 Execute 行动

02 · 来源方报告

客户与供应商的绩效表述

• 5 分钟对比 15 人一整天
• 实时跟踪与重新分配
• 减少过量库存与浪费

03 · 尚未披露

架构与独立测量结果

• 目标函数与模型组合
• Ontology 与权限
• 项目成本与合同经济性
• 经审计的企业级 ROI

“来源方报告”并不等于不真实；它意味着应该保留来源归属，不能升级成已经独立验证或适用于整个企业的结果。

换成文字：公开资料记录了合作、规模、演示数字、行动顺序与人工触发执行；客户与供应商报告了速度与库存收益，但没有独立测量；精确架构、权限、经济性与经审计的企业级 ROI 仍未披露。

可迁移的设计模式，是从例外到行动

如果要迁移 Wendy’s 案例，我不会从“数字孪生”、Ontology 工作坊，或自动化整个网络的目标开始。最小而有用的起点，是一个反复出现、目前仍需要人跨系统与跨组织拼接状态的真实例外。

建立一份 Exception-to-Action Record

针对一个真实运营例外，记录：

1. 例外： 什么发生了变化？哪条运营边界可能被突破？
2. 权威状态： 哪些订单、库存、承诺、政策与时间戳可以被信任？
3. 关系： 哪些客户、地点、供应商、产品或原料受到影响？
4. 响应选项： 哪些内容可以重新分配、订购、生产、延后或保持不变？
5. 约束与证据： 什么让一个选项可以接受？什么证据会排除它？
6. 决定权： 谁可以建议、批准、执行、覆盖与验收结果？
7. 行动与写回： 哪个系统会被改变？新状态记录在哪里？
8. 下一次触发： 什么证据应该重新打开决定，或改变工作流？

这份记录不是 Palantir 实施规格、自动化评分，也不主张更广的系统永远更好。它的用途是在选择技术架构之前，先检验运营回路是否已经被定义。

AI 原生转型：从局部提效到业务重构帮助判断最小充分变更应该发生在任务、工作流还是更广的业务系统；AI 原生运营模式：从组织架构到工作图谱进一步让结果、决定、上下文、行动、证据、例外与最终责任变得可以检查。这个案例则展示了这些概念在一个公开运营场景中的具体形态。

如果团队内部还无法定义这条从例外到行动的回路，FDE Delta 运营合作可以在业务边界清楚之后，成为一个克制的下一步。它不代表 Palantir 实施、系统选型、架构认证或结果保证。

来源与方法

主要案例来源包括 Palantir 与 QSCC 的合作公告、AIPCon 6 客户演示、QSCC 的机构介绍、Palantir 当前案例摘要，以及 Wendy’s 2024 年企业责任报告。我也使用 Wendy’s 监管文件核对合作社与加盟体系背景，用 Bloomberg 核对公开表达的自主化方向；Palantir 产品文档只用于区分通用平台能力与客户特定披露。

公开资料大多来自客户与供应商传播。我保留了来源归属，纠正了两处常见的转录误读——2800/3500 的数字层次，以及“3–4 天”——并避免推断未公开的算法、权限、架构或 ROI。六张图均为我在公开证据边界内重建或形成的分析视图，没有一张被描述成客户提供的系统图。