当交付失败时

这个阶段为了什么，又会怎样失败

这是第 II 部分中唯一不对应日程表上某个阶段的一章。一次失败的交付可能出现在任何一周，从试点条款到上线几个月之后。前面每一章都让某一种失败更不容易发生；这一章讲的是它照样发生了怎么办。原因总是那几个：

• 问题选错了。客户提出的是一个解决方案，而它背后的问题从未被找到（“需求挖掘”）。
• 没有数据。这项工作需要的数据不存在、拿不到，或者无法及时拿到。
• 没有负责人。东西做成之后，客户方没有人为结果负责，于是它能用，却没人用。
• 发起人变了。想要这个结果的人换了岗位，或者换了优先级。
• 阈值没有共识。没有人定下“够好”是什么意思，或者定下了，但这项工作达不到（“划定范围与首个成果”）。

这些都不是模型的失败。TNW 报道了 OpenAI 前线部署工程负责人 Colin Jarvis 的估计：在企业 AI 举步维艰的案例中，大约 80% 的问题出在部署上；另外 20%，客户说模型还做不了这件事（TNW，2026 年 9 月；T3，记者转述供应商的估计，数字背后没有方法）。把它当作一个内行的看法来读。

对失败的处理会以三种方式出错。慢慢枯萎：会越开越少，没人把话挑明，交付就这么一路拖着，直到续约日期逼出这个问题。叫停太晚：终于有人叫停了，但钱和信任都已经耗光。追责式复盘：复盘写出来是为了判定是谁的错，于是下一次尝试开始时，既没有带上教训，也没有带上发起人。

慢慢枯萎最常见，而记录最完整的例子是公开的。纽约市的 MyCity 商业聊天机器人于 2023 年秋天发布。The Markup 和 THE CITY 在 2024 年的测试发现，它会“自信地提供错误且可能有害的信息”，包括暗示房东可以歧视持有第八条款（Section 8）租房券的租户。市政府说会改进。新市长称它“实际上无法使用”，The Markup 在 2026 年 2 月 4 日的更新中报道，“beta 测试已经结束”（The Markup，2026）。测试是 T1，记者自己的测量；成本，用市长的话说“大约五十万美元”，是 T3。教训在时间线上：证据公开了将近两年，才有一位有权拍板的人把它叫停。

有一处要坦白的空白。没有任何公开的一手叙述，讲一位 FDE 主动结束一次客户交付并说明所用的标准；本书背后的研究找过，一份也没找到。失败的交付在保密协议之下悄无声息地结束。下面的做法建立在相邻的证据上：从业者访谈、公开的关停和反转，以及一项研究成功案例、并追问它们之前那些失败的研究。从证据转向建议的地方，本章会明说。

合成案例：停滞的扩展

这段情节里的三点，就是本章的全部要义。没有人取消任何东西；失败只表现为错过的会议、一个没有具名的负责人，以及一项停滞的标注工作。规则在任何人需要它之前就写好了，所以它不评判任何人的投入程度。而从财产险撤出，并不等于从客户那里撤出。

别拿基础失败率说事

迟早会有人搬出一个失败率：“反正 95% 的这类项目都会失败”，可能来自你自己这边的客户经理团队，也可能来自正在收回预算的发起人上司。流传的这些比率比看上去要弱，复述它们的 FDE 会被人抓住把柄。

RAND，2024（T1，有附加说明）。RAND 访谈了 65 位经验丰富的数据科学家和工程师，问 AI 项目为什么失败（RAND RR-A2680-1）。它测量的是从业者相信什么，而不是结果。有两个发现要紧：“84% 的受访者举出了一个或多个”由领导层造成的根本原因，“作为 AI 项目会失败的首要原因”；50 位业界受访者中有 14 位说，高层领导低估了做出一个有效模型需要多长时间。它那句“超过 80%”的失败率并不是它自己的测量，而是一句引用《财富》的“据某些估计”：正如“需求挖掘”一章指出的，这是一个回声数字。

MIT NANDA，2025（T2）。“95% 的组织获得的回报为零”出自一份文件名为 v0.1、标题为“初步发现”的报告（MIT NANDA，2025 年 7 月）。它依据的是对 52 家机构的访谈、对 153 位高层领导者的调查，以及对 300 多个公开项目的回顾。它把成功定义为“超出试点阶段、并有可衡量 KPI 的部署”，在试点后六个月测量回报，并称其数字“方向上准确，依据的是个别访谈，而非公司的正式报告”。Futuriom 的 R. Scott Raynovich 写道，这个 95%“只用一句话呈现”，没有说明来源细节，并引用了沃顿商学院 Kevin Werbach 的话：“95% 这一说法似乎没有任何进一步的支撑”（Futuriom，2025 年 8 月；T3）。

Gartner（是预测，不是测量）。2024 年 7 月，Gartner 预测“到 2025 年底，至少 30% 的生成式 AI（GenAI）项目会在概念验证之后被放弃”，原因是“数据质量差、风险控制不足、成本攀升或业务价值不明确”。2025 年 6 月，它预测“到 2027 年底，超过 40% 的智能体 AI 项目会被取消”，同时附上一项 2025 年 1 月对 3,412 位网络研讨会参会者的投资额调查（Gartner 新闻稿，2024 年 7 月和2025 年 6 月；T4，属于分析师预测）。两者都被当作结果反复引用，而本书的研究没有找到任何后续测量来检验第一个预测是否成真。

所以当会上有人提起某个比率时，用这次交付来回答，而不是用一个更好的统计数字：“像这样的项目，没有人有可靠的失败率。我们有的是自己的五个条件，下面是每一个现在的状况。”基础失败率无法告诉你这一次交付是否正在失败。只有它自己的信号能。

五种失败，以及检验每一种的那个问题

每一种失败都会提前几周发出信号，每一种都有一个你这周就能问的问题，把一种感觉变成“是”或“否”。

问题选错了。信号是一场不错的演示之后，没有人问下一步。这是 RAND 的第一个根本原因，“需求挖掘”一章讲过（T1）。检验：“如果它达到了阈值，你们下一次经营回顾里哪个数字会动？”如果答案说出的数字与范围文件里的不同，或者根本说不出数字，那么这个范围服务的是一个业务已经不再关心的问题。回到需求挖掘，而不是回到模型。

没有数据。信号是一个日期。如果到第一周结束时还没有接近生产的数据接入，试点就只能靠测试样本和侥幸撑着。RAND 的第二个根本原因是组织缺少“充分训练一个有效 AI 模型所需的数据”（T1）。对 FDE 来说，更常见的形式是数据存在，却无法及时拿到。检验：“谁必须批准这项权限，他们每个人都看到申请了吗？”“交付开始之前”中的试点条款规定，权限延误时计时暂停；用上这一条，并把这些人的名字交给发起人。

没有负责人。信号是一个没人回答的问题：我们走了以后谁来运行它？斯坦福对成功部署的研究里有一家半导体公司，它早先的智能体“在演示里能用，在生产中不行”。诊断是：“问题不在技术”；而是“没有共同的标准，也没有人为采用负责”（Pereira、Graylin 和 Brynjolfsson，2026；T2，访谈中的自述，报告标注为草稿）。那里的挽救来自一位把问题上报到 CEO 的领导者。检验：“我们走了以后它出了故障，谁的电话会响，他们现在知道吗？”一个团队的名字不算答案；一个人才算。没有这个人，一个能用的系统会在第一次预算审查时被关掉。

发起人变了。信号是出席情况。RAND 的受访者描述了这样的组织：“高层领导每隔几周或几个月就迅速切换优先级”，以至于进行中的项目“在有机会展示真实成果之前就可能被丢弃”。一位受访者把代价说得很准：“模型交付时，往往只有它本可以达到的 50%”（RAND，T1）。注意力已经转移的发起人很少会明说。他们把指导会委派给别人，不再读进展更新，然后问这项工作能不能“暂停一个季度”。检验由负责人当面问，而不是发邮件：“这个 KPI 还是你这半年被考核的那个吗？如果不是，是哪个？”大多数发起人会诚实回答，因为这事关他们自己。

阈值没有共识，或者达不到。信号是一个始终定不下来的数字，或者一个定在目标之下、并一直停在那里的数字。“评测”一章讲了麦当劳得来速的测试：报告的准确率“在 80% 出头”，而目标是“95% 以上”，测试在合作开始大约两年半之后结束（Nation's Restaurant News，2024；T3，准确率数字是二手的）。“评测”一章定了重新测量的日期；这一章补上更难的那个问题。检验：“如果到那天我们仍然低于阈值，我们怎么办？”如果没有人愿意回答，这段爬坡就没有尽头，而这本身就是失败。

有一个陷阱出现在上线之后而不是之前：凭自动化指标宣布成功，然后反转。Klarna 在 2024 年 2 月宣布，它的助手在第一个月就处理了“Klarna 三分之二的客服聊天”，“相当于 700 名全职客服的工作量”（Klarna；T2，自报）。大约十五个月后，它的 CEO 对彭博社说，结果是“质量更低”，并说“投资于人工支持的质量，才是我们的未来之路”（Entrepreneur，2025 年 5 月；T3，转述一次采访）。注意这里的回声数字：那篇报道把最初的比例写成了 75%，而不是三分之二。澳大利亚联邦银行宣布 45 个客服岗位将由一个 AI“语音机器人”取代，随后撤回了这次裁员，称其评估“没有充分考虑所有相关的业务因素”，“这一错误意味着这些岗位并非冗余”。工会说，来电量一直在上升（Information Age，2025 年 8 月；T3）。两者都不是 FDE 交付。两者都说明了应当白纸黑字点明的风险：智能体承担的工作份额，并不能证明这份工作做得好。

本 wiki 的失败分类与分诊一页，对智能体的运行时失败做的是同样的事。这份清单是交付层面的版本，附录 C 把两者相互对照。

趁还能行动时叫停

复盘通常是在尸体上做的。这一次要在还活着的病人身上做，趁还有时间挽救，并且在任何人有理由把结论说得委婉之前，先把它写下来。

什么时候。在第二个信号出现时，而不是第五个。错过一次指导会是噪音。错过一次会，再加上一个没有具名的阈值负责人，就是一种模式。本章末尾那张表里的信号，在任意四周之内出现两个，就足以安排复盘。这是本书的经验法则，不是经过测量的触发条件。

谁来叫停，向谁叫停。通常是 FDE，因为信号最先被他看到：不再回复的标注员、卡在队列里的数据申请、没有任何高层出席的演示。先向你自己的负责人叫停，书面的，当天就做，再让负责人去找发起人；FDE 如果直接去找发起人，就会把供应商层面的决定变成个人投诉。四行就够了：范围、两个带日期的信号、你认为缺失的条件，以及请求（在下一张发票或下一个里程碑之前做一次复盘）。第 3 章的技能地图把及早叫停失败放在判断力的最高一级，因为很少有人做到。

对照什么。对照签过字的文件：试点条款、范围、阈值、退出标准，以及那条规则。而不是对各方投入程度的印象。如果条款从来没有写下来，那就是第一条发现。

不追责。在这一点上，证据异常直接。斯坦福对 51 个成功部署的研究发现，“61% 的成功项目之前至少有过一次失败”，“在每一个我们能确认失败尝试和成功尝试是否由同一位高管发起的案例中，答案都是肯定的”，并且“在我们研究的案例中，没有任何人因为一个失败的 AI 项目而受罚”（斯坦福，T2）。样本里只有成功案例，作者也点明了这一局限：“偏向正面结果的选择偏差”。所以它无法证明不追责的复盘导致了挽救。它能说明的是，那些卷土重来的项目，是带着同一位发起人回来的，而这位发起人没有为第一次尝试付出代价。让发起人难堪，你就耗掉了最有可能把这项工作带回来的那份资产。

挽救还是撤出：决策规则

每一次交付都立在五个承重条件上，上面每一种失败对应一个：

1. 发起人所在的业务仍然在意的问题；
2. 一条走得通的数据通路；
3. 客户方有一位结果的负责人；
4. 一位对这个数字负责、并且仍然有时间顾及它的发起人；
5. 一个有共识、有负责人、并且达得到的阈值。

在开始时就把它写下来，写进范围文件或试点条款。五个条件都成立，就继续。缺了一个或多个，而且对每一个缺失的条件，客户方都有一位具名的人承诺在某个日期前恢复它，就重置。只要有任何一个缺失的条件没有人愿意在旁边写上自己的名字和日期，就撤出。这是本书的建议，不是经过检验的方法。它背后的证据，是 RAND 对领导层造成的失败如何展开的描述，以及斯坦福对被救回的项目有何不同的描述。

有两个细节决定这条规则能不能真正起作用。恢复者必须对缺失的东西有决定权：发起人的副手承诺财产险主管的时间，就不算恢复者。而日期必须近，几周之内，并且在下一张发票或下一个里程碑之前，这样错过日期触发的是规则，而不是又一场讨论它的会。

这条规则也改变了谈话的性质。“我们觉得你们已经没兴趣了”是一句指责。“月底之前能不能定下一位阈值负责人？”是一个只能回答“能”或“不能”的问题，对照的是发起人早已同意过的标准。如果发起人说不能，做决定的就是他们；负责人的工作是让这个决定变得容易。

重置是什么样子。斯坦福最清楚的挽救案例，是一家专业服务公司的招聘系统。第一次尝试“以为 AI 能修好有问题的流程”。第二次改了三件事：“CEO 亲自负责，而不是委派给 CTO”，“他们先修好流程，再用 AI”，以及“他们瞄准的是真正的痛点”。用一位高管的话说：“不是‘嘿，这个会很棒’，而是‘我快被淹死了’。”（斯坦福，T2；案例中的结果数字是自报的。）每一项改变都恢复了五个条件之一：一位有决定权的负责人、正确的问题，以及一位需要这个结果的发起人。只换了模型或提示词的重置，什么都没有恢复。

重置不是什么。“继续做做看。”没有重新检查日期的重置，只是多了几页文书的慢慢枯萎。

什么时候撤出是对的。如果缺失的条件，没有任何一个有权恢复它的人能够恢复，撤出就是对的。它让客户不必为一项无法落地的工作买单。“划定范围”一章引用过 RAND 的建议：让一个团队至少用一年时间专注于一个问题。在这里把它倒过来读：如果客户方连未来几周都不肯指定一个具名的人，他们就不是在承诺那一年，这个范围就应该停下。撤出的是范围，不是客户。已经在生产环境中运行的东西留下，关系也留下。

体面地撤出

你怎么离开，决定了你能不能回来。

• 让能用的东西继续运行，并且有人负责。如果这次交付有任何部分已经在生产环境中，它就留在那里，由客户的团队负责，按照“上线与交接”中的运行手册来运行。
• 交出进行中的工作。标注好的数据、测试样本、范围草稿和评测框架，属于客户的下一次尝试，不管由谁来做。
• 书面确定停止计费的日期。负责人和客户经理告诉发起人计费何时结束。没有这个日期的撤出，只是一次暂停。
• 写下回来的触发条件。把放弃的范围放进“暂不做”清单，附上一个具体的触发条件：一位具名的负责人、一份标注好的样本、一位有时间的发起人。
• 留住发起人。把复盘先发给发起人，再给任何其他人看，并且让它把做成了什么讲得和没做成什么一样清楚。斯坦福的证据表明，如果还有下一次尝试，发起人很可能还是同一位。

三个客户卡在同一个集成上，是一个产品缺口，而不是三次糟糕的交付。“反哺产品”讲的是怎样把一线证据变成一份产品反馈简报，而一次失败的交付是很好的证据，因为没有人有动机去粉饰它。

模板：交付复盘

第 1 节取自签过字的文件，包括那条规则，这样在任何人填写第 3 节之前，规则就已经固定。在出现两个信号时，或者在交付结束后，做这次复盘。

ENGAGEMENT POST-MORTEM                            version / date: ____
Run: during | after the engagement     Facilitator: ______________

1. WHAT WE AGREED (copy from the signed terms and scope)
   Sponsor and KPI:       _________________________________________
   Scope and threshold:   _________________________________________
   Threshold owner:       _________________________________________
   Exit criteria:         _________________________________________
   Decision rule:         continue if all five conditions hold;
                          reset if each missing one has a named
                          restorer + date; walk if any has none

2. WHAT HAPPENED (dated facts, no adjectives, no names to blame)
   when: ______  ___________________________________________________
   when: ______  ___________________________________________________
   when: ______  ___________________________________________________

3. THE FIVE CONDITIONS        At start    Now         Evidence
   Problem still matters      yes/no/?    yes/no/?    ______________
   Data path working          yes/no/?    yes/no/?    ______________
   Owner for the result       yes/no/?    yes/no/?    ______________
   Sponsor owns the number    yes/no/?    yes/no/?    ______________
   Threshold agreed, owned    yes/no/?    yes/no/?    ______________

4. MAIN CAUSE (one only: the one that explains the others)
   wrong problem | no data | no owner | moving sponsor |
   unagreed threshold | too hard for AI | other: _______________

5. WHAT STILL WORKS, AND WHO OWNS IT (a person, not a team)
   - system / artefact: ______________  owner: ____________________
   - system / artefact: ______________  owner: ____________________

6. DECISION:  continue | reset | walk          decided by: ________
   If reset:  condition: ________  restorer: ________  by: ________
              re-check date: ________
   If walk:   billing stops: ________
              handed over: ________________________________________
              return trigger: _____________________________________

7. WHAT GOES BACK TO PRODUCT
   - _______________________________________________________________

8. SIGN-OFF
   Sponsor:        __________   date: ______
   Vendor lead:    __________   date: ______
   FDE:            __________   date: ______

下面是按合成案例为财产险扩展填好的版本。按合成案例的规则，每个数字都是区间或相对日期。

ENGAGEMENT POST-MORTEM: property expansion      version 1 / month 8
Run: during the engagement             Facilitator: vendor lead

1. WHAT WE AGREED (copy from the signed terms and scope)
   Sponsor and KPI:       COO; claims cycle time
   Scope and threshold:   property FNOL triage, propose only;
                          threshold to be set by head of property
   Threshold owner:       head of property claims (no number yet)
   Exit criteria:         no labelled set or threshold within a
                          few weeks of scope sign-off
   Decision rule:         as written in the month-6 scope

2. WHAT HAPPENED (dated facts, no adjectives, no names to blame)
   when: month 6  property scope signed; labelling plan agreed
   when: month 7  board cost programme; COO takes it on
   when: month 7  steering meeting moved twice, then skipped
   when: month 7  property adjusters moved to backlog; a
                  fraction of the sample labelled
   when: month 7  check: exit criterion met; call deferred
   when: month 8  finance asks for auto figures to justify
                  adjuster cuts

3. THE FIVE CONDITIONS        At start    Now         Evidence
   Problem still matters      yes         ?           not in the
                                                      cost plan
   Data path working          yes         yes         replica OK
   Owner for the result       yes         yes         claims
                                                      director
                                                      (all lines)
   Sponsor owns the number    yes         no          meetings
                                                      skipped
   Threshold agreed, owned    pending     no          no number
                                                      after weeks

4. MAIN CAUSE (one only: the one that explains the others)
   moving sponsor

5. WHAT STILL WORKS, AND WHO OWNS IT (a person, not a team)
   - auto FNOL triage (live)    owner: claims director (behaviour);
                                platform ops lead (service)
   - auto eval harness          owner: claims director

6. DECISION:  walk (property only)             decided by: COO + lead
   If reset:  offered: narrower property slice, owner and labelled
              set within a few weeks; COO could not name an owner
   If walk:   billing stops: end of month 9
              handed over: partial labelled set, fixtures, draft
              scope, labelling guide
              return trigger: named threshold owner and a fully
              labelled property sample

7. WHAT GOES BACK TO PRODUCT
   - labelling capacity, not data, was the bottleneck: ship a
     labelling plan with the triage template
   - auto metric is speed, not staffing: say so in every readout

8. SIGN-OFF
   Sponsor:        COO             date: month 9
   Vendor lead:    lead            date: month 9
   FDE:            FDE             date: month 9

填好的版本里有两处是刻意的。原因写的是“moving sponsor”（发起人变了），尽管阈值也缺失了，因为阈值是随着发起人的注意力一起消失的：选那个能解释其他原因的原因。还有，第 6 节记下了那次被提出又被拒绝的重置，这样等财产险回来时，它当初为什么停下，已经白纸黑字写在那里。

失败信号

四周之内出现任意两个，就足以安排复盘。它们大多看起来像日程安排问题，这正是它们被忽视的原因。

进入下一阶段

当每一项都打上勾，这次交付，或者其中失败的那部分，才算妥善收尾：

• 决定（继续、重置或撤出）已经写下，连同据以做出它的那条规则。
• 重置时，每一个缺失的条件都有一位具名的恢复者、一个日期和一个重新检查的日期。
• 生产环境中的任何东西，在客户方都有一位具名的负责人，以及一份他们用过的运行手册。
• 进行中的工作已经交给客户，没有扣留，放弃的范围已定好停止计费的日期。
• 在客户经理团队以外的任何人之前，发起人已经读过复盘。
• 放弃的范围已经放进“暂不做”清单，附有具体的回来触发条件。
• 这次失败给产品的教训，已经归档到产品团队会读的地方。