案例档案

十个案例一览

找到案例，核对等级，先读每行的后半句，再读前半句。每个案例名都链接到下文的完整条目。

纽约市 MyCity 聊天机器人

发生了什么。纽约市于 2023 年秋天上线了 MyCity 商业聊天机器人。The Markup 和 THE CITY 在 2024 年的测试发现，它会“自信地提供错误且可能有害的信息”，包括暗示房东可以歧视持有第八条款（Section 8）租房券的租户。市政府表示会加以改进。新任市长称它“在功能上无法使用”，而 The Markup 在 2026 年 2 月 4 日的更新中报道，“beta 测试已经结束”（The Markup，2026）。

等级。测试部分是 T1：The Markup、Documented 和 THE CITY 亲自做了测试，独立于任何销售这套系统的人。成本，按市长的说法“大约 50 万美元”，是 T3。

能证明什么。在受监管的领域里，一个自信的错误回答可以从外部测出来，测量者完全不需要接触供应商。它也展示了慢慢枯萎的过程：证据公开了将近两年，才有一位有权拍板的人叫停。

不能证明什么。测试测的是聊天机器人的回答，而不是背后的项目。它没有说明谁拥有这套系统、构建团队知道什么、为什么没有修好，本书也不认为它是一次 FDE 交付。在这十个案例中，它是唯一一个有独立测量结果的，而它测到的是一次失败。本档案里没有任何一个成功案例背后有 T1 级别的结果。

引用于。《如何使用本书》（T1 的例子）；《当交付失败时》（慢慢枯萎）。

摩根士丹利财富管理

发生了什么。摩根士丹利与 OpenAI 一起，为财富管理顾问打造了一个助手。在 OpenAI 负责前线部署工程的 Colin Jarvis 说，“主要的技术难关大概在 6 到 8 周内就解决了”，随后又花了“差不多 4 个月做试点、收集评测、反复迭代”，顾问们才信任它（Altimeter 访谈，2025 年 11 月）。OpenAI 的企业指南介绍了最初的三项评测：翻译、摘要，以及“人类训练师”，后者把模型的回答与资深顾问的回答做对比（OpenAI，AI in the Enterprise）。该公司的 David Wu 说，他们被问到的第一个问题，就是“我们的信息”会不会被用来“训练公开的 ChatGPT”，而 OpenAI 团队“愿意确保零数据保留，这一点影响非常大”（OpenAI 客户故事）。

等级。T2：供应商在访谈、指南和客户故事中描述自己的客户。ZenML 对同一场演讲的摘要是 T3，只是那场演讲的回声，而不是第二个来源（ZenML LLMOps 数据库）。

能证明什么。关于“能用的构建”和“被信任的构建”之间的差距，这是最好的公开记录：信任期是构建期的两到三倍，而且这段时间花在用户身上，而不是模型上。它还说明了几点：评测开始得早，并且是和客户的专家一起做的；首个成果选在这家银行最大的业务之一上，而不是边缘工作流程；一家受监管的公司在问质量之前，先问的是训练和数据保留。

不能证明什么。没有独立方测量过采用率。那个最常被引用的采用率数字是回声数字：摩根士丹利自己的新闻稿说“98% 的财务顾问团队已经采用”（摩根士丹利），OpenAI 的指南则把它变成了“98% 的摩根士丹利顾问每天都在使用 OpenAI”。采用了某个工具的团队，和每天使用它的个人，是两种不同的测量。时间线是一位供应商高管对一个客户的回忆，说明不了别处建立信任要多久。

引用于。《如何使用本书》（98% 的回声数字）；《划定范围与首个成果》（高利害）；《安全、治理与模型风险》（零数据保留的问题，以及合成案例）；《评测：证明它真的有效》（从评测开始，以及漫长的爬坡）；《上线与交接》（信任期，以及合成案例）；《反哺产品》；《压力下的判断》（非确定性）。

Klarna 客服

发生了什么。Klarna 在 2024 年 2 月宣布，它的助手上线第一个月就处理了“Klarna 三分之二的客服对话”，“相当于 700 名全职客服的工作量”（Klarna）。按 Jarvis 的说法，OpenAI 团队给每个意图都套上了各自的评测，这让系统得以从大约 20 条政策扩展到大约 400 条，并把这套方法做成了一个框架 Swarm，后来开源，又为 OpenAI 的智能体 SDK 提供了基础（Altimeter 访谈）。上线大约十五个月后，Klarna 的 CEO 对彭博社说，结果是“质量更低”，并且“投资于人工客服的质量，才是我们的未来方向”（Entrepreneur，2025 年 5 月）。

等级。上线数据和“每个意图一套评测”的方法是 T2（客户和供应商自报）。后来的反转是 T3（一家杂志转述一次采访）。其中还带着一个回声数字：Entrepreneur 的报道把最初的占比写成了 75%，而不是三分之二。

能证明什么。按意图划分的回归套件，正是让一次交付能安全扩大范围的东西。一线的工作可以变成产品，而在这里，它是在第二个、更难的客户（T-Mobile）只做少量改动就用上了这个框架之后，才变成产品的。还有一点：智能体承担的工作占比，并不能证明工作做得好。这次成功是凭一个自动化指标宣布的，后来又被推翻了。

不能证明什么。没有任何公开资料说明，那些按意图划分的评测测的是问题解决率，还是只测了拦截率，所以这个案例无法告诉你，更好的评测能否发现质量问题。严格来说，它也不是一次 FDE 交付：Jarvis 自己称之为“一次解决方案架构师的交付，但很大程度上是 FDE 式的交付方式”，而 Pragmatic Engineer 说，这个框架是 OpenAI 的解决方案架构团队创建的（Pragmatic Engineer，2025 年 8 月）。在把这个故事讲给客户之前，先把这一点说清楚。《当交付失败时》同样没有把这次反转算作 FDE 交付。

引用于。《评测：证明它真的有效》（每个意图一套评测）；《反哺产品》（第二个客户规则，以及推动采用）；《当交付失败时》（反转，以及合成案例）。

OpenAI 与一家欧洲半导体公司

发生了什么。Jarvis 讲过 OpenAI 与一家未具名欧洲半导体公司的交付，对方的要求刻意放得很开：审视整条价值链，“拿下浪费最大的那几块”。团队“驻场，花了差不多两周时间，非常细致地了解他们的业务”，覆盖设计、验证和出货后的性能测量。最后选中了验证环节，那里的工程师“要花差不多 70%、80% 的时间”修 bug；测试在夜里跑，每位工程师早上到岗，面对的是几百个 bug。评测的第一步，是“和客户的专家一起，基本上就是定一组五个”（Altimeter，2025-11-26）。

等级。T2：供应商描述自己的交付，客户未具名。“一组五个”被当作信条引用，在《评测：证明它真的有效》中定为 T4。

能证明什么。这是在现场做需求挖掘的最佳公开 FDE 案例：先在现场待几周，再决定在哪里下手，而且选择依据是工程师的时间损失在哪里，而不是模型擅长什么。它也展示了有意挑一个大问题（“你得挑一个大的、很大的问题来解决”），以及一个从与客户专家的一次对话开始的评测集。

不能证明什么。各章没有报告它的任何结果。客户没有具名，所以 OpenAI 以外的人无法核实这段叙述，而且这只是一次交付，由执行它的团队自己讲述。不要把它和斯坦福研究里的那家半导体公司混为一谈，后者的智能体“在演示里能用，在生产中不行”（见次要案例）。

引用于。《需求挖掘》（以及“这家保险公司，第一周和第二周”中的合成案例）；《划定范围与首个成果》；《评测：证明它真的有效》。

Palantir AIP 训练营

发生了什么。2023 年，Palantir 把商业试点改成了“训练营”。按 2023 年第三季度财报电话会的说法，训练营“在五天或更短时间内，基于客户的真实数据交付真实的工作流程，而我们传统的试点通常需要一到三个月”；Shyam Sankar 称之为“要证明，不要概念验证”（2023 年第三季度电话会）。到下一次电话会时，它报告“迄今已在 465 家机构举办了 560 多场训练营”（2023 年第四季度电话会）。之后的电话会给出了转化的例子：一家医疗公司在 12 月参加训练营后五周就完成转化，签下一份年合同价值 2,600 万美元的五年协议（2025 年第一季度）；另一家“去年夏天和我们一起完成了两场训练营，签下了一笔 9,600 万美元的交易”（2025 年第四季度）。

等级。T2：供应商在自己的财报电话会上向投资者报告。

能证明什么。对一部分客户，供应商可以把签约前的阶段从几个月压缩到几天，而这些客户中有一部分很快签下了大合同。即使形式不能照搬，原则也能迁移：客户的真实数据和真实工作流程在第一周就出现，评判标准是工作流程能不能跑通。

不能证明什么。没有披露转化率；2023 年第四季度电话会谈到“把训练营转化为企业交易”，却没有给出比率。这些例子是管理层挑出来讲给投资者听的。它们没有说明训练营里做的工作流程是否进入了生产，也没有说明一次转化花了多少 FDE 工时。大多数供应商根本办不了五天的训练营。

引用于。《交付开始之前》。

Palantir S-1 中的试点经济账

发生了什么。Palantir 2020 年的 S-1 招股文件说，它获取客户的方式是“以免费或低成本向客户提供我们软件平台的短期试点部署”，并且“在这些短期试点期间，我们的客户账户是亏损运营的”，销售周期“通常……六到九个月”（Palantir S-1）。它把客户分为获客（Acquire）、扩展（Expand）和规模化（Scale）三个阶段。2019 年，获客阶段的客户带来 60 万美元收入，“由此产生 6,540 万美元的贡献亏损”；扩展阶段的贡献利润率为 (43)%，规模化阶段为 55%，规模化阶段中排名前四分之一的客户为 87%，全部客户为 21%。它直接点出了这个角色，说 FDE“亲眼观察用户面临的挑战”。

等级。T2：公司在监管文件中的自报数据。

能证明什么。亏损在先，而且是刻意为之；利润率的转折，取决于那些部署工作不再比收入增长得更快的客户。此后半年里，扩展阶段客户的贡献利润率从 (43)% 升至 35%。这是最早的公开记录，表明免费试点是供应商主动选择承担的成本，而这正是《交付开始之前》要对付的问题。

不能证明什么。87% 是按结果挑出来的：它是规模化客户中按利润率排名最好的那四分之一。各阶段本身就是按结果定义的，所以这张表说明不了有多少客户在阶段之间流动，文件也没有给出转化率（“无法保证我们能够把客户从获客阶段推进到后续阶段”）。贡献利润率没有计入研发和管理费用。Qureshi 后来说的“2023 年 80% 的毛利率”没有出处，它在别处的再次出现是回声数字。

引用于。《如何使用本书》（T2 的例子）；《交付开始之前》（以及合成案例）；《起源与经济账》（以及怀疑者的看法）。

NHS 联邦数据平台

发生了什么。The Register 报道，截至 2024 年底，在英格兰 215 家医院信托中，“不到四分之一（45 家）在实际使用”这个由 Palantir 构建的平台，“已有 72 家作为分阶段推广的一部分上线”，“超过 120 家 NHS 信托已经签约”，另有 880 万英镑付给 KPMG 用于采用支持（The Register，2025 年 5 月）。Palantir 的 Louis Mosley 对议员们说，回写到 NHS 系统“比从这些系统读取更有挑战，尤其是那些非常老旧的系统”，而人工回写会损失“大量效率”；一家信托的首席数字信息官也表示认同（The Register，2025 年 7 月）。

等级。T3：记者转述 NHS 的数据和向议员提供的证词。供应商有把责任推给老旧系统的动机。

能证明什么。采用率需要一个各方认可的定义：已签约、已上线、在实际使用，是同一个项目的三个数字，争论的每一方都可以挑对自己有利的那个。回写比读取难；当最后一步是一个人把决定手工敲进系统时，大部分收益就丢了。

不能证明什么。付给 KPMG 的钱说明买方有多重视采用，而不说明这笔钱花得有没有效果。这些数字没有一个是对使用情况的独立测量，这个案例也无法说明平台值不值它的花费。它是本书在交接问题上唯一一个记录充分的反例，而不是“什么让交接得以持久”的证据。

引用于。《如何使用本书》（T3 的例子）；《数据接入与集成》（回写，以及合成案例）；《上线与交接》（采用率，以及有计划地离开）。

MD Anderson 与 IBM Watson

发生了什么。MD Anderson 癌症中心与 IBM Watson 合作打造的肿瘤专家顾问系统（OEA），在四年多里花费了“6,200 万美元”。据 Network World 的报道，德克萨斯大学的审计发现，医院在 2016 年把病历系统迁移到 Epic 之后，“OEA 一直没有更新以与现行系统集成”，并且“没有投入临床使用”。医院付给 IBM 将近 4,000 万美元，付给普华永道 2,100 多万美元，“几乎全部未经董事会批准”；承包商“无论最初合同约定的工作范围是否完成都照样拿到了钱”；而范围从一种白血病扩大到六种，又扩大到肺癌（Network World，2017 年 3 月）。

等级。T3：媒体对一份内部审计的报道，本书没有读过审计原文。

能证明什么。没人维护的集成会腐化：不管模型能做什么，它已经读不到医院的病历了。它也说明，治理失败可以与模型毫无关系：审批和付款都没有与范围或证据挂钩。

不能证明什么。这个案例很老，早于今天的模型，也不是一次 FDE 交付。它展示的是集成腐化和审批松散的机制，而不是这两种情况有多普遍。

引用于。《数据接入与集成》；《安全、治理与模型风险》。

麦当劳得来速语音点餐

发生了什么。麦当劳与 IBM 合作，在大约 100 家门店测试语音点餐。2022 年的一份分析师报告称，准确率“在 80% 出头”，而目标是“95% 以上”；测试在 2024 年结束，距合作开始大约两年半（Nation's Restaurant News，2024 年 6 月）。

等级。T3，而且准确率数字是二手的。

能证明什么。一场始终够不到阈值的爬坡，本身就是一次失败。没有人定下必须成功的期限，也没有人事先说明，如果不成功会怎样。

不能证明什么。准确率数字出自一位分析师，经一家行业媒体转述，公开记录也没有说明测试为何结束。它不是一次 FDE 交付，也无法告诉你目标是否可以达到。

引用于。《评测：证明它真的有效》；《当交付失败时》（一个够不到的阈值）。

空客 A350 与 Palantir

发生了什么。Nabeel Qureshi 在 Palantir 的第一个真正的客户交付是空客：他“搬到图卢兹住了一年，每周四天在工厂里和制造人员一起工作”。软件把“分散的数据来源——工单、缺件、质量问题”汇集到一处，他称之为“基础的软件活儿”（Qureshi，2024 年 10 月）。另外，Pragmatic Engineer 报道说，在 Palantir 做了七年 FDE 的 Anjor Kanekar“曾驻在航空航天制造商空客的总装线上”，他的同事们所在的环境中也包括物理隔离的环境（Pragmatic Engineer，2025 年 8 月）。

等级。Qureshi 的部分是 T4，一位前员工的回忆。Kanekar 的部分是 T3，基于访谈的二手报道。

能证明什么。驻场工作在最字面的意义上是什么样子；以及价值来自贴合真实工作流程的朴素软件，而不是来自聪明的设计。

不能证明什么。任何结果。Qureshi 说 A350 的生产节奏提高了“4 倍”，但没有给出方法；不要把它当作结果转述。两位 Palantir 前员工的叙述，算不上一次测量。

引用于。《在客户的环境里构建》（以及最不花哨的东西）。

次要案例

这些案例各自只在一两章里支撑一个论点。大多数是 T3，或者只是单个团队的叙述；没有一个有独立测量的结果。只用它们来说明列出的那一点，不要引申。

公开案例没能说明的事

空白和案例同样重要，因为它们标出了本书哪些建议只是推荐，而不是研究发现。

• 没有关于交付如何进行的 T1 记录。关于 FDE 交付的独立测量证据几乎不存在。供应商发布自己的成功，客户发布自己的采用率数字，而双方之外几乎没有人测量任何东西。关于需求挖掘、范围划定、评测或交接实际进行得如何的每一份叙述，都来自供应商或参与者（《如何使用本书》）。关于 FDE 需求挖掘本身，没有任何独立研究（《需求挖掘》）。
• 唯一的 T1 结果是一次失败。在上面十个案例中，唯一有独立测量结果的是 MyCity，而测到的是它给出了错误的回答。这里的每一个成功，都是供应商或客户对自己最好的叙述。
• 没有 FDE 亲手终止一次交付的一手叙述。没有任何公开来源描述过 FDE 主动结束一次客户交付，以及当时依据的标准；本书背后的研究找过，一份也没找到。失败的交付在保密协议之下悄然结束，所以《当交付失败时》里关于退出的建议，是从相邻的证据中搭建起来的。
• 没有交接一年后的测量。没有任何公开来源独立测量过 FDE 构建的系统的采用率，也没有人核查过 FDE 离开一年后它是否还在运行、还有人用（《上线与交接》）。

如果你能公开发布其中任何一项，附上日期、数字以及由谁测量，它的价值会超过又一个成功故事。