写在前面：本专题不讨论"AI 还有哪些想象空间"，只讨论"为什么我们以为会成功、最后却砸了"。所有内容基于行业公开现象（公开复盘、技术博客、监管通报、财报披露、学术论文复现实验）综合提炼，不杜撰任何未公开的公司机密。案例描述以"现象—根因—教训—防范"四段式呈现，目的是让 FDE 在下一次进现场前，先认得这些坑。

5.56.1 95% 失败率警示：为什么大多数 AI 项目根本走不到生产

业界对 AI 项目失败率的统计长期在 80%–95% 之间徘徊，数字越高，统计口径越偏向"进入生产并持续产生业务价值"这一严格定义：

• Gartner（2019 至 2022 多次口径）：约 85% 的 AI/大数据项目"未能交付"或"交付了但未产生预期价值"，并预测到 2025 年仍会有 60%–70% 的模型在生产环境里"可被管理者接受但未达可衡量业务回报"。
• MIT Technology Review 与 VentureBeat 联合调研（2019 至 2021）：约 85%–90% 的企业 AI 项目"无法从 PoC 走到生产"，大量项目卡在"永远在 PoC"状态。
• RAND Corporation（2024 年报告《The Root Causes of Failure for Artificial Intelligence Projects》）：超过 80% 的 AI 项目失败或半途而废，并把根因归纳为五大类——问题错配、数据错配、基础设施误判、技术债务、治理缺位。
• PocketFlow "95% 失败率" 工程文档（被广泛引用的反面警示）：把数字推到 95%，强调"不是模型不够强，是整个工程-组织系统没准备好"。

一个有用的换算：如果一个组织每年上 20 个 AI 项目，按 85% 失败率，5 年后会沉淀出 17 个"僵尸项目"和 3 个真正活着的系统。这 17 个僵尸不仅是预算黑洞，还会持续占用一线注意力、污染数据、让下一次立项更难通过预算评审。

失败高度集中在 两个时间窗口：

1. PoC 之后、生产之前（"PoC 死亡之谷"）——demo 看起来惊艳，一旦要接真实数据、真实流量、真实审批流，立刻崩。
2. 上线之后 3–12 个月（"上线即巅峰"）——模型指标看着还行，但业务不再使用、数据漂移、成本失控，最终被静默下线。

本专题把公开现象归类为 八种失败类型，每种都给出：典型场景、根因、教训、防范手段。FDE 在任何一个新现场，都应先问自己一句："这个项目最可能死于下面哪一种？"

5.56.2 失败类型一：问题判断错误（做了客户不需要的东西）

典型场景

• "我们想用大模型重构客服"——但真正翻工单发现，70% 来电是"查物流、改地址、退款进度"，这类问题用规则引擎 + 一个查询接口就能解决，根本不需要 LLM。
• "我们要做行业知识图谱"——立项 8 个月，最后业务方只用它做了一个"高管看板"的可视化，知识图谱本体从未被一线检索。
• "我们要做智能投顾"——合规一关就毙了，因为任何"具体建议"都触达持牌边界，最终产品退化成"资讯推送 + 风险提示"。

根因

1. 技术驱动而非问题驱动：团队先有了"要用大模型/知识图谱/RAG"的执念，再去反找业务问题往里套。
2. 决策层与一线的脱节：立项会上是高管拍脑袋，真实工作流的一线员工从未被访谈。
3. 把"演示价值"当成"业务价值"：demo 在投资人/CEO 面前很惊艳，但一线没人愿意把它嵌进自己的日常工作。
4. 跳过了"问题框定"环节：没有用 CDEF 的 Context 勘探 阶段去回答"这是谁、在哪、因为什么、每月损失多少、用现有方案为什么解决不了"。

教训

一个 AI 项目最大的浪费，不是算力账单，而是把一个错误的问题做到 90%。

• **不要相信"用 AI 重构一切"**这句话。先把问题分类：哪些是规则能解决、哪些是检索能解决、哪些确实需要生成式推理。只有当规则和检索都解释不清问题、且收益足以覆盖模型成本时，才动用大模型。
• 永远先做"反向假设"：如果这个项目成功上线，3 个月后业务方会因为什么原因不用它？如果答得出来，那这就是项目真正的死法。
• (PayPal/Stripe 的反例)很多金融反欺诈、支付路由问题，最终的最优解是一棵 GBDT + 几百行规则，不是 LLM Agent。

防范

• Context 勘探强制产出"问题账本"：列出当前流程的 5–10 个具体痛点，每个标注"业务损失金额/月、现有替代方案、为什么替代方案不够"。
• 设立"反方角色"（Red Teamer）：立项评审时必须有人专门负责说"这个项目不该做"，并要求项目方给出反驳。
• 两周一次的业务方复核：每两周让真实一线用户（不是 IT 部门）对 demo 打分——"如果今天上线，你会用吗？为什么不用？"

5.56.3 失败类型二：数据地基崩塌（数据不可用）

典型场景

• 标注一致性灾难：医学影像项目，3 位放射科医生对同一张 CT 的标注一致率只有 62%，模型在"标准答案"本身就矛盾的情况下训练，准确率天花板被封死。
• 训练-生产分布漂移：2018 年起反复出现的现象——金融反欺诈模型在疫情前训练，疫情后消费行为剧变，召回率在 3 个月内从 92% 跌到 71%，但因为缺乏监控，团队直到 6 个月后才发现。
• 数据"看起来有但其实没有"：客户说"我们有 5 年的客户工单数据"，现场一看，70% 是空字段、20% 是脏数据、剩下 10% 才可用。FDE 经常在第一周发现"所谓的大数据资产其实是个空仓库"。
• 标签泄露（Label Leakage）：训练集准确率 99%，生产环境暴跌到 60%——根因是训练时把"未来才会产生"的字段（如结案时间、处理人最终结论）当成了输入特征。

根因

1. 数据所有权与项目方分离：项目团队不掌握数据产生链路，无法判断数据质量。
2. 未做数据探查（EDA）就开始建模：跳过"先看数据"这一步，直接堆模型。
3. 训练/验证/测试集划分错误：时间序列用了随机切分而不是时间切分，导致"用未来预测过去"。
4. 没有数据漂移监控：模型上线后从未跟踪输入分布变化。

教训

模型质量上限 = 数据质量上限。垃圾进，垃圾出，没有任何模型架构能绕过这条定律。

• 第一周必须做"数据现实核对"：把客户声称的数据资产实地抽样 200–500 条逐条看，统计空值率、重复率、字段一致性、时间跨度。
• "看 100 条原始数据胜过读 100 页需求文档"——这是 FDE 进入任何新现场的铁律。
• 标注质量比数据量更重要：1000 条高质量标注 > 10000 条低质量标注。标注一致性（Cohen's Kappa）低于 0.6 就该停下来，先去对齐标注规范，而不是去调模型超参。

防范

• 建立数据健康度看板：字段完整率、标注一致性、分布漂移指标（KS 检验、PSI）每周更新。
• 强制时间切分：所有涉及时间的数据，训练/验证/测试集必须按时间先后切分，禁止随机切分。
• 冷启动期用"弱标注 + 主动学习"：先用规则 + 人工抽检建立基线，再让模型主动挑出最不确定的样本交给专家标注，而不是一开始就堆 10000 条盲标。

5.56.4 失败类型三：技术方案不落地（理论好，生产崩）

典型场景

• 延迟灾难：用 70B 参数模型做实时风控，单次推理 3.2 秒，而风控系统要求 <200ms。PoC 时离线 batch 跑得很好，一上实时链路立刻 OOM。
• 离线指标好、线上指标崩：推荐系统离线 AUC 0.92，上线后 CTR 反而下降 12%——因为离线评估用的是"已曝光用户的点击"，存在严重的样本选择偏差。
• 长尾 case 失控：客服对话模型在常规问题上准确率 95%，但遇到"用户带情绪、连续追问、跨业务切换"等长尾场景，幻觉率飙升到 30%+，而恰恰是这些长尾场景最容易引发投诉。
• 可观测性缺失：模型上线后没有任何监控，团队直到客户投诉才知道"过去两周模型一直在胡说八道"。

根因

1. 离线指标与业务指标脱钩：优化的是 AUC/F1，而业务关心的是转化率、客诉率、NPS。
2. 未做压测和延迟分析：demo 在 10 QPS 下跑通，生产 1000 QPS 立刻挂。
3. 没有兜底机制：模型置信度低时没有 fallback 到规则或人工的开关。
4. 缺乏 A/B 测试文化：直接全量上线，没做对照组比较。

教训

离线准确率高，不等于业务能用。FDE 必须把"业务指标"而不是"模型指标"作为唯一验收标准。

• 延迟预算先行：进现场第一件事就问"这个场景的延迟红线是多少？"——如果是实时风控 <200ms，就别想 70B 模型，老老实实做蒸馏 + 规则。
• 必须设计 fallback 链：模型置信度 < 阈值 → 规则 → 人工。任何没有 fallback 的 AI 系统都是定时炸弹。
• 真实流量灰度：从 1% → 5% → 20% → 50% → 100% 灰度，每档至少观察 1 周，对比业务指标而非模型指标。

防范

• 压测在 PoC 阶段就做：不要等到上线才发现 OOM。用 Locust/k6 模拟生产 QPS，测出 P50/P95/P99 延迟和 GPU 显存峰值。
• 影子模式（Shadow Mode）：模型先在线上跑但不参与决策，只记录输出，对比人工结果。至少跑 2 周再切流量。
• 建立业务指标看板：上线后跟踪的不是 AUC，而是"客诉率、转化率、人工接管率、单次交互成本"。

5.56.5 失败类型四：忽视合规被叫停

典型场景

• 跨境数据传输违规：某出海 SaaS 项目把用户对话数据传到海外模型 API，触发《数据安全法》《个人信息保护法》和欧盟 GDPR 双重审查，项目被监管叫停、罚款、数据被强制本地化迁移。
• 生成式内容合规问题：客服 Agent 在压力下生成了医疗建议（"您这个症状建议立即停药"），直接触达《互联网诊疗管理办法》和《药品管理法》红线，整个客服 AI 被合规部门叫停。
• 个人信息处理未告知：用客户历史行为数据训练推荐模型，但用户协议里没有"用于模型训练"的授权条款，被用户投诉后被监管要求删除模型、回滚数据。
• 算法备案缺失：根据《互联网信息服务算法推荐管理规定》《生成式人工智能服务管理暂行办法》，面向公众的推荐算法和生成式服务必须做算法备案。多家团队产品已上线，备案没做，被迫下架整改。

根因

1. 合规部门介入太晚：项目快上线才找合规，问题已经定型，整改成本极高。
2. 对法规无知：团队以为"AI 是技术问题"，不知道《个保法》《数安法》《算法推荐规定》《生成式 AI 办法》已经把 AI 全链路纳入监管。
3. 境外模型 API 的隐藏成本：调用海外 API 看似方便，但触发的数据出境评估、安全评估成本远高于自建模型。
4. 缺少"红线清单"：没有在立项时就把"绝对不能碰的场景"列清楚（医疗诊断、法律建议、金融投资建议、未成年人内容、政治敏感）。

教训

合规不是 AI 项目的"附加项"，是"准入证"。没有合规闭环的 AI 项目，不是"可能失败"，是"必然失败"。

• 合规介入在 Context 阶段，不是 Engineer 阶段：FDE 进现场第一周就要拉着法务一起做"合规影响评估（DPIA）"。
• 境外模型 API 谨慎用：除非业务明确允许跨境，否则优先选已完成备案的境内模型。
• 生成式场景必须有"护栏"：医疗/法律/金融/未成年人/政治——这五类场景要么不做，要么必须有强规则拦截 + 人工兜底。

防范

• 每个项目建"合规红线清单"：列出涉数据的字段、流向、存储位置、保留期限、跨境情况、用户授权情况、备案情况，逐项确认。
• 强制算法备案：面向公众的服务，上线前完成网信办算法备案和（如适用）生成式 AI 服务备案。
• 生成内容护栏：输入端做敏感词过滤，输出端做事实核查 + 规则拦截，关键场景（医疗/法律/金融）强制人工复核。

5.56.6 失败类型五：组织变革失败（一线不用）

典型场景

• "系统上线了，但没人用"：花了 8 个月做的智能审核系统，一线审核员仍坚持用 Excel 手工操作。原因：新系统要点击 7 次才能完成一次审核，Excel 只要点 2 次。
• 变革阻力来自中层管理者：AI 系统提升了一线效率，但中层担心"自己团队人数缩减、权力下降"，于是消极抵制——不培训、不考核、不改流程。
• KPI 错配：AI 系统上线后，一线 KPI 仍然是"处理件数"，而 AI 的价值是"减少处理件数"。一线越用 AI，KPI 越难完成，于是主动绕开 AI。
• 培训缺失：系统上线当天扔给一线一份操作手册就走了。没人现场陪着用 2 周，一线遇到第一个坎就退回老流程。

根因

1. 把"技术上线"等同于"项目成功"：以为代码部署完就万事大吉，忽略"人会不会用"才是真正的终点。
2. 未做工作流融合：AI 系统是独立的，没有嵌入一线的日常工作流，需要"额外打开一个系统"，注定被冷落。
3. 未调整激励结构：旧 KPI 与新系统目标冲突，但项目方没有推动 KPI 改革的权限。
4. 未做变革管理：没有变革冠军（Champion）、没有种子用户、没有持续陪跑。

教训

AI 项目失败，70% 是组织问题，30% 才是技术问题。

• 真正落地的标志不是"上线"，而是"一线自愿使用 3 个月后还在用"。
• FDE 必须懂"变革管理"：技术交付只是 30%，剩下 70% 是陪跑、培训、流程改造、激励对齐。
• 永远不要相信"我们培训过了"——真正的培训是 FDE 在一线现场陪着用户用满 2 周，遇到每一个问题当场解决。

防范

• 嵌入工作流：AI 系统必须长在一线已有的工具里（CRM、ERP、企业微信、内部系统），不要让用户"额外打开"。
• 找"变革冠军"：在每个业务团队找 1–2 个一线 KOL，让他们成为种子用户和内部布道者。
• 同步调整 KPI：把"处理件数"改成"质量 + 客户满意度 + AI 协作度"，让一线因使用 AI 而受益。
• 2 周陪跑期：FDE 在系统上线后驻场至少 2 周，每天和一线一起工作，收集反馈、修复问题、改进体验。

5.56.7 失败类型六：能力衰退（上线即巅峰）

典型场景

• 数据漂移导致模型衰退：电商推荐模型上线时 CTR 提升 15%，6 个月后回到基线以下——因为流行趋势、用户偏好、商品池都在变，模型还在用 6 个月前的分布推理。
• 概念漂移（Concept Drift）：风控模型在监管政策变化后失效——以前合规的交易结构变了，模型对"新合规但旧违规"的判断完全错位。
• 反馈循环污染：推荐模型上线后，用户的点击行为本身被模型影响，再用这些数据训练新模型，形成回声室效应，模型越训越偏。
• 冷启动衰退：上线初期因为没有用户反馈，模型只能基于先验，效果差；但团队期望"上线就有显著提升"，3 个月没达预期就被砍预算。

根因

1. 没有持续学习机制：模型上线后从未再训练，相当于让 2020 年的人去判断 2026 年的事。
2. 没有漂移监控：没人跟踪输入分布、特征重要性、预测分布的变化。
3. 反馈数据采集缺失：用户真实反馈没有被结构化采集，无法形成闭环。
4. 重训练 vs 重部署混淆：有的团队频繁重训练模型但不敢上线新版本（怕引入新问题），导致训练-生产脱节越拉越大。

教训

模型上线不是终点，是起点。AI 系统是活的，需要持续喂养（数据）和持续体检（监控）。

• 没有 MLOps 的 AI 项目，注定上线即巅峰。模型生命周期管理（监控、再训练、版本管理、回滚）必须和模型开发同等投入。
• "模型衰退"比"模型错误"更隐蔽——前者是温水煮青蛙，等发现时业务已经流失。

防范

• 三层监控体系：
  1. 输入监控：特征分布（PSI > 0.2 告警）。
  2. 输出监控：预测分布、置信度分布。
  3. 业务监控：转化率、客诉率、人工接管率（业务指标是最终裁判）。
• 定期再训练 + 灰度切换：每月/每季度做一次再训练，新模型先在影子模式跑 1 周，业务指标不退步才切换。
• 建立"模型生命表"：每个模型记录上线时间、当前指标、漂移程度、计划退役时间——像管理资产一样管理模型。

5.56.8 失败类型七：成本失控（ROI 为负）

典型场景

• 大模型推理账单失控：用 GPT-4 / 顶级大模型做客服，初期单次对话成本 ¥0.8，业务方还能接受；用户量上来后月账单冲到 ¥80 万，而客服人均成本只要 ¥30/小时，ROI 直接为负。
• GPU 闲置浪费：为峰值流量采购了 8 张 H100，实际峰值只用到 2 张，剩下 6 张闲置但折旧照算。
• 隐性成本被忽略：标注成本、数据清洗成本、运维成本、合规成本——这些都没进 ROI 测算，最后发现**"模型便宜，养模型贵"**。
• PoC 阶段不计成本，生产阶段算到肉疼：PoC 时用最贵的模型最贵的硬件不计成本跑出好结果，生产时发现同等结果需要 1/10 的成本，但没有人重新优化。

根因

1. 没有 TCO（总拥有成本）测算：只算 API 调用费，不算数据、运维、合规、机会成本。
2. 过度工程：能用小模型解决的问题上了大模型，能用规则解决的问题上了模型。
3. 没有成本看板：业务方根本不知道每次调用烧多少钱。
4. 峰值采购而非弹性扩缩：硬件按峰值买，闲置率极高。

教训

AI 不是越贵越好，最合适的才是最好的。

• 小模型优先：能用 7B 解决的别用 70B，能用规则解决的别用模型。每一次"上大模型"决策都必须有成本-收益测算支撑。
• ROI 测算必须包含全成本：API/算力 + 数据标注 + 运维 + 合规 + 机会成本 + 退役成本。
• 建立成本看板：每个 AI 服务的单次调用成本、月度总成本、对应业务收益，透明可见。

防范

• 三层模型架构：规则 → 小模型 → 大模型，只有规则和小模型都解释不了的问题才路由到大模型。
• 弹性算力：用云上 Spot 实例 + 自动扩缩容，只为实际使用的算力付费。
• PoC 阶段就做成本建模：在 Context 阶段就预测生产成本，如果预测 ROI < 1，要么砍功能，要么换方案，不要等到生产账单出来才发现亏本。

5.56.9 失败类型八：Agent 失控（幻觉、越权、烧钱）

典型场景

• 幻觉生成虚假事实：法律咨询 Agent 引用了不存在的判例；客服 Agent 给出不存在的退款政策；编程 Agent 调用了不存在的 API。这些都是公开被反复报道的现象。某公开案例中，航空客服 Agent 自行虚构了一项"哀悼折扣政策"，导致用户持此主张索赔，公司被迫承担责任。
• 越权操作：Agent 被赋予了工具调用权限（数据库写、邮件发送、文件删除），在没有充分护栏的情况下执行了未授权的破坏性操作——例如删除了不该删的记录、给错误的人发了邮件。
• 无限循环烧钱：Agent 在复杂任务中陷入重试循环，调用工具上百次仍未收敛，单次任务烧掉数十甚至上百美元。公开案例中有多起"Agent 失控烧光 API 额度"的复盘。
• 提示词注入攻击：用户输入或外部文档中嵌入恶意指令，劫持 Agent 执行攻击者意图——读取机密数据、执行未授权操作。

根因

1. 把 LLM Agent 当成"能自主决策的智能体"：误以为模型能自我约束，没有设计显式的权限边界。
2. 工具调用没有沙箱：Agent 直接在生产数据库、生产系统上操作，没有 dry-run、没有审批、没有回滚。
3. 没有成本上限：Agent 的最大调用次数、最大 token 消耗没有硬限制。
4. 越权场景设计错误：把"读权限"和"写权限"放在同一个 Agent 上，破坏性操作没有二次确认。

教训

Agent 不是"自主决策者"，是"被严格约束的执行器"。任何没有护栏的 Agent 都是定时炸弹。

• LLM 永远会幻觉，关键场景必须有事实核查机制——外部检索 + 规则验证 + 人工兜底，三层缺一不可。
• 破坏性操作必须有二次确认：写、删、发送、转账——这些操作的 Agent 必须强制人工审批，不能让模型自主完成。
• Agent 必须有"刹车"：最大调用次数、最大 token、最大时长、最大成本——任何一项触发立即熔断。

防范

• 工具沙箱化：Agent 调用工具时先在测试环境 dry-run，输出经审核后才在生产执行。
• 角色分离：只读 Agent 和可写 Agent 分开，可写 Agent 强制人工 in-the-loop。
• 提示词注入防护：用户输入和外部文档作为"数据"而非"指令"处理（system prompt 中明确隔离），对工具调用做白名单校验。
• 成本熔断：每个 Agent 任务设置硬上限（如单任务最多 20 次工具调用、最多 10 万 token、最多 5 美元），超限立即终止并告警。
• 可观测性：Agent 的每一步决策、每一次工具调用、每一次中间结果全量日志化，事后可追溯、可审计。

5.56.10 失败复盘方法论：目标—结果—原因—SOP 四段式

光知道"有哪些坑"还不够，关键是会复盘。FDE 推荐使用以下四段式复盘框架：

第一步：还原目标（What did we aim for?）

不要用今天的认知去评判当时的决策。

• 立项时真实的业务目标是什么？（不是"用 AI 提升效率"这种空话，而是"3 个月内把客诉处理时长从 8 小时降到 2 小时"这种可衡量的）
• 投入的资源是什么？（人、钱、时间）
• 当时的约束条件是什么？（数据、合规、组织、技术）
• 当时为什么相信这个目标可达？把立项依据逐条列出来——后面要检验。

第二步：对照结果（What actually happened?）

• 实际业务指标 vs 目标指标（差距多少）
• 实际成本 vs 预算（超支多少）
• 实际周期 vs 计划周期（延期多少）
• 一线使用率（真实使用 vs 设计使用）
• 不要粉饰——复盘的价值在于诚实，粉饰过的复盘等于没做。

第三步：根因分析（Why did it happen?）

避免停留在表面原因。推荐用 "5 Whys" + 鱼骨图：

• 表面原因："模型准确率不够" → 追问 5 层
• 第 1 层：为什么准确率不够？因为训练数据分布和生产不一致。
• 第 2 层：为什么不一致？因为训练用的是历史数据，没有覆盖新场景。
• 第 3 层：为什么没覆盖？因为数据采集流程没有持续更新机制。
• 第 4 层：为什么没有机制？因为项目交付后没有 MLOps 团队接管。
• 第 5 层：为什么没有接管？因为立项时只算了开发预算，没算运维预算。
• 根因：ROI 测算缺陷 + 组织职责缺位。

鱼骨图从 人、机、料、法、环、测（人员、技术/工具、数据、方法、环境、度量）六个维度分类根因，避免遗漏。

第四步：沉淀 SOP（How do we not repeat it?）

复盘不产出的 SOP，等于白复盘。

每一条根因必须对应：

1. 新的检查项（Checklist）：下次进现场，这件事必须在 Context 阶段就被检查。
2. 新的工具/模板：例如"数据健康度评估模板""合规红线清单""ROI 测算表"。
3. 新的角色/职责：例如"每个项目必须有 MLOps 负责人""每个 AI 服务必须有业务指标看板 owner"。
4. 新的培训内容：把这次教训写进 FDE 入职培训。

SOP 的验收标准：另一个 FDE 拿到这份 SOP，能在下一次进现场时自动避开同一个坑。

5.56.11 从失败中学习的组织文化

技术问题有标准答案，组织文化没有。一家真正能从 AI 失败中学习的组织，通常具备以下特征：

特征一：心理安全感（Psychological Safety）

• 失败可以被公开讨论，不会被追责、不会被嘲讽。
• 复盘会的基调是"我们一起搞清楚发生了什么"，不是"找出谁该背锅"。
• 没有"心理安全感"的组织，所有复盘都会被粉饰，教训永远沉淀不下来。

特征二：建立"失败案例库"

• 每个项目（成功的、失败的）结束后，必须提交一份结构化复盘报告进内部知识库。
• 案例库按"失败类型"分类（本专题的八类就是现成分类法）。
• 新立项项目的第一步：检索案例库，看历史上有没有踩过同类坑。

特征三：复盘仪式化

• 固定节奏：项目上线 1 个月、3 个月、6 个月各做一次复盘。
• 跨团队分享：每季度办一次"失败案例分享会"，让最有教训的项目方上台讲（而不是只让成功项目讲）。
• 复盘和绩效解耦：复盘质量本身可以纳入绩效，但复盘出的失败本身不扣分——否则没人会诚实复盘。

特征四：把教训写进流程，而不是写进 PPT

• 复盘产出的 SOP 必须变成立项检查项、模板、工具，而不是停留在 PPT 里的"经验总结"。
• 下一次有人想跳过某个检查项，必须经过升级审批——让流程强制执行教训。

特征五：FDE 的角色定位

• FDE 不只是"技术交付者"，更是**"组织学习的搬运工"**——把每一次现场踩的坑，结构化地搬回组织。
• FDE 的价值，不是"做了多少个项目"，而是"让下一次项目少踩多少坑"。

5.56.12 八种失败类型速查表

失败类型	一句话根因	最早可识别阶段	关键防范手段
一、问题判断错误	技术驱动而非问题驱动	Context 勘探	反向假设 + Red Teamer
二、数据地基崩塌	未做数据探查就建模	Context 勘探	第一周抽样核对 + 数据健康看板
三、技术方案不落地	离线指标≠业务指标	Design 设计	延迟预算 + 影子模式 + 灰度
四、忽视合规被叫停	合规介入太晚	Context 勘探	第一周 DPIA + 红线清单
五、组织变革失败	把上线当终点	Feedback 反馈	嵌入工作流 + 变革冠军 + 2 周陪跑
六、能力衰退	无 MLOps	Feedback 反馈	三层监控 + 定期再训练
七、成本失控	无 TCO 测算	Design 设计	三层模型架构 + 成本看板
八、Agent 失控	无护栏	Design 设计	沙箱 + 角色分离 + 成本熔断

一句话总结：前四类失败决定"项目能不能启动"，后四类失败决定"项目能不能活下去"。 FDE 在任何一个新现场，第一周就要对着这张表自问一遍。

本专题小结

• AI 项目失败率长期处于 80%–95% 区间，这不是模型不够强的问题，是工程-组织-合规系统没准备好的问题。把失败归结于"AI 还不成熟"是逃避，真正的根因 70% 在组织、流程、数据，30% 才在技术。
• 失败高度集中在 八种类型：问题判断错误、数据地基崩塌、技术方案不落地、忽视合规、组织变革失败、能力衰退、成本失控、Agent 失控。每一种都有明确的前置信号和防范手段，没有一种是"不可预见"的。
• 失败的前四类（问题、数据、方案、合规）属于"先天不足"，必须在 Context 勘探和 Design 设计阶段就识别并规避；后四类（组织、衰退、成本、Agent）属于"后天失调"，必须在 Engineer 工程和 Feedback 反馈阶段持续治理。
• 复盘不是"找出谁背锅"，而是用"目标—结果—根因—SOP"四段式把每一次失败转化为组织资产。没有沉淀为 SOP 的复盘，等于没复盘。
• 一家能从失败中学习的组织，必须具备心理安全感、结构化案例库、仪式化复盘、流程化教训、FDE 作为搬运工五个特征。FDE 的最高价值，不是做了多少项目，而是让下一次项目少踩多少坑。
• 最后一句话送给所有 FDE：进现场前，先认得这些坑；进现场后，把它们写进你的检查清单。AI 项目失败不是宿命，是可以被工程化对抗的概率事件。

本专题来源

• RAND Corporation（2024）：《The Root Causes of Failure for Artificial Intelligence Projects》——AI 项目失败率 >80%，五大根因（问题错配、数据错配、基础设施误判、技术债务、治理缺位）。
• Gartner 多次研究（2019–2024）：约 85% 的 AI 项目未能交付预期价值；2025 年仍有 60%–70% 模型"未达可衡量业务回报"。
• MIT Technology Review / VentureBeat 行业调研（2019–2021）：85%–90% 企业 AI 项目无法从 PoC 走到生产。
• PocketFlow 工程文档（公开）："95% AI 项目失败率"警示与工程化根因分析。
• 中华人民共和国法律法规：《个人信息保护法》《数据安全法》《网络安全法》《互联网信息服务算法推荐管理规定》《生成式人工智能服务管理暂行办法》《互联网诊疗管理办法》——合规红线与算法备案要求。
• 公开行业复盘与技术博客：航空客服 Agent 虚构折扣政策案、跨境数据传输监管叫停案、大模型推理账单失控案例、Agent 失控烧光 API 额度案例、推荐系统回声室效应研究等——综合提炼为通用失败模式。
• MLOps / LLMOps 公开方法论：数据漂移监控（PSI/KS）、影子模式、灰度发布、三层模型架构、Agent 护栏（沙箱、角色分离、成本熔断）等工程实践。
• CDEF 方法论体系：Context 勘探 → Design 设计 → Engineer 工程 → Feedback 反馈——本专题八种失败类型与四阶段防护的对应框架来源。