失败模式

如何使用这份目录

先找到你所处的阶段，再在它的表格里找你能看到的症状。多数症状只属于一个阶段，但有几个会在后面的阶段换个样子重现：缺失的数据通路、没人负责的阈值、没有日期的退出。这类症状只列一次，放在修起来最便宜的地方，它的“怎么做”一栏会链接到提到它的其他章节。“交付全程”（C.11）收录的是任何一周都可能出现的症状。

如果你只有五分钟，而不是五十分钟，就问“五种失败”里的五个问题。每个问题检验五种反复出现的失败中的一种，每个问题都把一种感觉变成“是”或“否”：

• 问题选错了（C.3）：“如果它达到了阈值，你们下一次经营回顾里哪个数字会动？”
• 没有数据（C.5）：“谁必须批准这项权限，他们每个人都看到申请了吗？”
• 没有负责人（C.9）：“我们走了以后它出了故障，谁的电话会响，他们现在知道吗？”
• 发起人变了（C.11），由负责人当面问，而不是发邮件：“这个 KPI 还是你这半年被考核的那个吗？如果不是，是哪个？”
• 阈值没有共识，或者达不到（C.4、C.7）：“如果到那天我们仍然低于阈值，我们怎么办？”

一个症状是噪声。任意四周之内出现两个，就是一种模式。《当交付失败时》里的规则是：在第二个信号出现时就安排复盘，而不是等到第五个。这是本书的经验法则，不是经过测量的触发条件。复盘对照的是签过字的条款和“挽救还是撤出”规则里的五个条件，而不是对投入程度的印象。复盘模板见第 13 章。

这里说的都不是智能体在运行时出错。线上系统给出错误答案、陷入循环或工具报错，那是事故，不是交付失败；本 wiki 的失败分类与分诊一页讲的就是如何给这类失败归类和分派。两者只在一个地方相接：在同一类别里反复出现的运行时失败，会变成评测问题（C.7）；如果它在多个客户那里反复出现，就会变成产品问题（C.10）。

这份目录背后的证据很薄，各章也都说明了这一点。没有任何公开的第一手记述，讲一位 FDE 结束一次交付、并说明所用的标准。这些症状来自从业者和供应商的证词（多为 T2 到 T4），并对照 RAND 的访谈（T1，但它测量的是从业者相信什么，而不是结果）以及斯坦福对成功部署的研究（T2，草稿）加以核对。每张表格下列出的公开案例，在各自的章节里分了级。

交付开始之前

这些症状在第一天到场之前就看得见。出现一个，就该重新谈条款。出现两个或更多，不管合同怎么称呼，这个试点实际上就是一次没有资金的概念验证。

第 4 章里有两个症状放到了后面，放在动手修复的地方：第 2 周之前还没有数据权限（C.5），以及安全审查“等试点之后再做”（C.6）。案例：Palantir 的 S-1 展示了实验室继承下来的模式：试点亏本运行，销售周期“通常……六到九个月”（T2，公司自报）。IDC 发现，每 33 个 AI 概念验证中有 4 个进入了生产，诊断是“资金严重不足，或者根本没有资金”，这是一种相关性（T3）。两者都在“这个阶段为了什么”里；S-1 的分级见附录 A。

需求挖掘

这些在第一周修起来很便宜。到了第四周，每一个都已经变成返工。

案例：RAND 的定价例子：领导者要的是卖得最多的价格，真正需要的却是利润最高的价格，而这个错误直到集成时才暴露（T1，访谈）。见“需求挖掘为了什么”。

划定范围与首个成果

这些通常在头两周显现。第一行会在后面的阶段换个说法重现；无论它何时出现，对策都一样。

案例：Jarvis 对比了两类客户：一类挑的是“一种……偏在公司一边的边缘用例”，另一类挑的是“真正高利害的东西”，他举的例子是摩根士丹利（T2，供应商描述自己的客户）。见“划定范围为了什么”。

数据接入与集成

这些在头三周显现，那时还来得及行动。第一个是第 13 章所说的“没有数据”最常见的形式：数据存在，却无法及时拿到。

案例：Qureshi 讲述的 Palantir 试点：“8 到 12 周”都花在“光是拿到数据权限”上，“最后一周手忙脚乱地凑点东西来演示”（T4，一位前员工的说法）。见“这个阶段为了什么”。

安全、治理与模型风险

这些在头三周显现。每一个在架构图上修，都比在代码里修便宜。

没有公开的失败案例。这一章的证据是一些调查，讲的是有什么挡路；外加一项研究，讲的是幸存者后来怎样了。斯坦福的草稿发现，在它的所有成功案例中，安全“都不是项目杀手”，并称这笔安全税是“前置的”（T2）；而一个只有成功案例的样本，恰恰检验不了这一点。见“审查为了什么”。

评测

这些在汇报会之前显现，大多出现在从第一个快速得出的数字爬向阈值的那段漫长爬坡里。

案例：麦当劳与 IBM 合作的语音点餐测试，报告的准确率“在 80% 出头”，目标是“95% 以上”，测试于 2024 年结束，始终没有定下爬坡必须成功的日期（T3，准确率数字是二手的）。LinkedIn 的团队一个月就做到了 80%，之后又花了四个月试图突破 95%，他们写道，早期的进度“制造了一种‘就快到了’的错觉”（T2）。两者都在“从 80% 开始的漫长爬坡”里；麦当劳的分级见附录 A。

在客户的环境里构建

这些在构建期间显现，通常在团队之外的任何人察觉之前。

没有公开案例。这一章是全书证据最薄的章节之一：没有任何经过测量的研究说明，在客户环境里哪些架构能成功。见“构建为了什么”。

上线与交接

这些大多在上线前后的几周里显现，那时你还没离开，还来得及修。第一行和最后一行，是第 13 章所说“没有负责人”的两副面孔。

案例：Tryolabs 所说的“常见模式”：一个工具三个月后“就那样放着没人用”（T4）；以及 Alpine Edge 提出的交接失败的警示信号：“只有那位工程师能操作它”（T4）。两者都在“上线为了什么”里。至于信任要多久：在摩根士丹利，技术问题用了几周，而顾问们信任它之前的试点和评测又花了大约四个月（T2）。关于裁员，Klarna 宣布它的助手完成了“相当于 700 名全职客服的工作量”（T2，自报），其 CEO 后来却说结果是“质量更低”（T3）。澳大利亚联邦银行撤回了它归因于一个语音机器人的 45 个岗位裁减，称其评估是一个“错误”（T3）。两者都在“五种失败”里。附录 A 为摩根士丹利和Klarna分了级。

反哺产品

这些在上线之后显现，通常那时 FDE 已经去了下一个交付，有些只有坐在管理者的位置上才看得到。所以它们很容易被漏掉。

案例：一位工程师接下 FDE 的工作，发现那是“典型的 IT 服务思维”，于是“4 周后就辞职了”（Pragmatic Engineer，T4，两位匿名工程师）；以及 Jarvis 把“过早泛化”列为他的团队犯过的最大错误之一（T4）。两者都在“反哺产品为了什么”里。

交付全程

第 13 章列出了五种反复出现的失败，没有一种是模型失败：问题选错了、没有数据、没有负责人、发起人变了，以及阈值没有共识或者达不到。它们的症状都放在了修起来最便宜的地方：问题选错了放在需求挖掘（C.3），没有数据放在 C.5，没有负责人放在 C.9，阈值放在 C.4 和 C.7，发起人变了就放在这里。这一章还列出了三种处理方式上的失误：慢慢枯萎，没有人把那个词说出口；叫停太晚，钱和信任都已耗尽；以及追责式的复盘，让下一次尝试失去了发起人。下面这些症状可能出现在任何一周，而且大多看起来像排期问题，这正是它们被无视的原因。

案例：纽约市的 MyCity 聊天机器人就是慢慢枯萎：测试发现它会“自信地提供错误且可能有害的信息”（T1，记者自己的测量），而这些证据公开了将近两年，才有一位有权力的人把它叫停（见“这个阶段为了什么”，分级见附录 A）。斯坦福研究里的那家半导体公司是“没有负责人”：智能体“在演示里能用，在生产中不行”，而“问题不在技术”（T2，草稿）。同一项研究里的招聘挽救案例，展示了一次恢复的是条件、而不是模型的重启（T2）。它们在“五种失败”和“挽救还是撤出”里。RAND 描述的那些“每隔几周或几个月就迅速切换优先级”的领导者，就是发起人变了（T1，访谈）。

职业，以及职业周围的团队

最后这些失败来得更慢，也更私人：一个原来是服务工作的角色，一个靠耐力爬上去的职级，一个按利用率经营的团队。前五行写给 FDE，后三行写给管理者。

案例：还是 C.10 里那些失望的入职者，这次从工程师这一侧来看：这样的 FDE“不会把东西回馈到平台里”（T4，一份新闻简报转述的两则轶事）。两个人算不上一次调查，但所有权检验正好能预测这种抱怨。见“质疑者说对了一部分”。