Demo惊艳全场，上线全线拉胯：AI项目90%落地失败，FDE视角拆解从Demo到交付的死亡之谷

一、数据先说话

Gartner预测，到2027年底，超过40%的Agentic AI项目会因成本失控、价值不清、风险不可控被取消。

McKinsey报告：88%的企业至少在一个业务环节用了AI，但只有6%实现了显著盈利。

Deloitte 2026年报告更扎心——23%的企业已经部署了能自主决策的AI Agent，但只有21%建立了成熟的治理框架。用了AI的企业里，五分之四没有配套的管控能力。

2026年Q2，CSDN上"AI落地失败"相关文章暴增。多篇复盘文章不约而同提到同一个数字：真正能跑满半年、被业务方常态化使用的AI项目，不足10%。

90%的项目死在哪？不是模型不够强，不是框架不够新，不是团队不够聪明。死在了一个所有技术教程都不会教你的地方——从Demo到交付之间的那段死亡之谷。

Demo阶段：技术团队三天搭出原型，演示惊艳全场，领导拍板"上线"。

交付阶段：业务方发现AI回答不稳定、数据接不进去、权限理不清、出了问题没人负责。三个月后，那个Demo静静躺在服务器里，再没人提。

这段"Demo很美、交付很惨"的断裂带，就是FDE真正的主场。前面九篇讲的是"用什么技术"，这篇讲的是"为什么技术对了项目还是死"。

二、Demo和交付之间，隔着什么

先说清楚Demo和交付的本质区别——不是程度差异，是维度差异。

Demo追求的是"能跑通"，交付追求的是"跑得稳"。能跑通只需要在理想输入下输出正确结果，跑得稳需要在所有输入下都不出大事。一个是最好的情况，一个是最坏的情况。工程交付从来不看你最好的时候多好，看你最差的时候多差。

Demo面对的是友好用户，交付面对的是敌对用户。Demo演示时，提问的人配合你——说标准话、走标准流程、给标准输入。交付后，用户不按套路出牌——方言提问、缩写乱用、跨系统跳转、故意测试边界。Demo里没人会问"帮我把老板的工资改成0"，交付后第一天就有人试。

Demo跑在干净数据上，交付跑在脏数据上。Demo用的是测试库里的标准文档，格式统一、内容干净。交付后接的是真实业务系统——同一个人在CRM里叫"张伟(ID:CN-8821)"，在ERP里是"Zhang_Wei_2023"，在钉钉通讯录里是"张总(采购部)"。Agent跨系统调数据，三个名字对不上，直接懵了。

Demo不需要安全合规，交付必须过审计。Demo让AI直接访问所有数据没问题，交付时等保三级、数据出域、权限隔离全是硬指标。金融、政务场景里，"数据可控"不是可选项，是一票否决项。

一句话：Demo是给你看"AI能做什么"，交付是给客户证明"AI不会做错什么"。前者是能力展示，后者是风险控制。90%的项目死在两者之间的认知鸿沟——团队以为Demo能跑交付就能跑，客户以为看到了Demo就看到了成品。

三、六大死因：90%的AI项目是怎么死的

复盘大量失败案例，死因不是分散的，是集中的。以下六个原因覆盖了绝大多数项目的死亡路径。

死因一：场景错位——"提升效率"不是场景，是愿望

最常见的死法。领导说"我们要用AI提升经营效率"，技术团队立刻开始选模型、搭平台、接接口。没人问：具体提升哪个环节？谁在干？现在哪一步卡住了？不做会损失什么？

"提升效率"不是场景，是愿望。真正的场景必须能回答五个问题：谁在用？在哪个具体步骤用？现在卡在哪？不做损失多少？做完改善什么？

举个真实案例：某企业想做"生产异常智能体"，初期方案写的是"辅助发现产线异常"。深入一线才发现——班组长每天早会前要汇总32个工位的停机记录和维修反馈，手动整理5页PPT，耗时38分钟，漏报率17%。这才是场景。它直接决定了Agent该接什么系统、识别什么异常、输出什么格式、谁确认结果。

场景不清，后面所有设计全失焦。方案越写越大变成"全能助手"，知识库变成资料仓库，权限只能粗分——要么太松有风险，要么太紧没人用。验收标准更虚——"提升效率"怎么验收？

FDE的判断：项目启动的第一件事不是选模型，是下业务现场。场景定义清楚，技术选型自然浮现；场景不清，技术再先进都是空中楼阁。

死因二：幻觉失控——模型"编"出来的错误比不做更可怕

大模型的本质缺陷：它不是在"回答"，是在"生成"。生成意味着可能编造——术语叫"幻觉"。

Demo阶段看不出幻觉问题，因为演示用的都是标准问题。交付后用户问"这个保单的犹豫期是多久"，知识库里没有这个产品的条款，模型不会说"我不知道"，它会编一个看起来正确的答案——犹豫期15天（实际上是10天）。

在金融、医疗等高风险场景，一个幻觉导致的错误信息，后果远比"没有AI"严重。没有AI，用户会自己去查；有了AI给了错误答案，用户信了就不查了。

Mark Cuban在2026年访谈里讲了个案例：一套智能知识库Agent上线第47天开始集体幻觉——把财务总监邮箱错标为"已离职"，把Q3预算表当成旧档自动归档，把法务修订的数据条款混进了销售话术。原因：底层模型悄悄升级了，提示词的输出格式变了，没有回归测试兜底。

幻觉治理不是靠提示词里写"请不要编造"，是靠工程化手段。RAG加知识库做事实约束、输出加引用溯源让每个答案可验证、关键信息加人工确认环节做最后兜底。第四篇讲RAG时说过：RAG不是性能增强器，是风险控制器。在交付场景里，RAG的核心价值是把"模型自由发挥"变成"模型基于给定材料回答"。

死因三：成本失控——Token烧到客户脸色变了

AI项目的成本结构和传统软件完全不同。传统软件开发完就结束了，AI项目每次调用都在烧钱。

单Agent一次对话几十个Token不痛不痒。但Multi-Agent场景——三个Agent协作跑十轮对话，Token消耗是单Agent的三十倍。客户一看月度账单，一个内部知识库Agent月Token费用比三个工程师工资还高，项目直接叫停。

Gartner预测2027年40%的AI项目因成本失控被取消。这不是危言耸听，是正在发生的事。

成本失控的根源：没有在方案设计阶段算Token账。技术团队只管"效果好不好"，不管"跑一次多少钱"。到了交付阶段才发现——每天一千次调用，每次平均8000 Token，月费用超出预算三倍。

FDE的成本意识必须前置到方案设计阶段。选模型时就想：这个场景需要GPT-4o还是GPT-4o-mini够用？缓存策略能不能减少重复调用？非关键路径能不能用小模型？对话历史能不能做摘要压缩而不是全传？

一个真实的成本对比：同一个客服Agent，不做优化的月Token成本约2万元，做了缓存+摘要+小模型分层的月成本约3500元。效果差异不到5%，成本差了五倍。

死因四：数据接不进去——孤岛比模型更难打通

Demo里的Agent跑在干净数据上，交付时发现——企业的数据根本接不上。

同一个客户在三套系统里三个名字。订单状态横跨SAP、金蝶和Excel共享盘，更新延迟平均47分钟。关键审批环节夹着微信截图、邮件抄送和手写签字扫描件——这些东西不会出现在任何RAG向量库里。

部署工程师干的不是"接API"，是当代数字考古——挖数据坟、破权限咒、译方言码、建信任桥。

这是FDE在政务项目交付中最深刻的经验：技术集成不是最难的部分，数据治理才是。你接上了API不代表数据能用，数据能用不代表数据可信。模型再强，喂进去的是垃圾，出来的还是垃圾。

数据治理的工作量通常是技术集成的三倍以上——清洗脏数据、统一字段命名、建立数据映射规则、做权限隔离。这些活不出彩、没有Demo效果，但没它项目就交付不了。

死因五：权限和安全缺位——AI不该看到的东西它全看了

Demo阶段Agent直接访问所有数据，没人在意安全。交付后发现——AI把财务总监的工资条返回给了普通员工的查询，AI自动归档了一份未签字的合同，AI在回复里泄露了另一个客户的隐私信息。

等保三级、ISO 27001、数据不出域——这些在Demo阶段被忽略的合规要求，交付时全是硬指标。金融、医疗、政务场景里，数据安全是一票否决项，不带商量。

AI Agent的权限设计比传统系统复杂一个维度。传统系统是"人→系统"的权限控制，Agent引入了"人→Agent→系统"的三层链路——用户有权调Agent，但Agent有权调的数据未必等于用户有权看的数据。

FDE的权限设计原则：最小权限+分级授权+全程留痕。Agent只能访问当前任务必需的数据，不同操作分级授权——读操作自动放行、写操作需确认、删操作需人工审批。每一步操作记日志，出了问题能追溯到具体调用。

死因六：没有运维体系——上了线就没人管了

传统软件上线后有运维团队保障。AI Agent上线后，谁负责监控它的运行状态？

模型会偷偷升级——OpenAI不发公告，Anthropic不改Changelog，但你的提示词在新版模型里行为变了。Agent会漂移——同一个问题上周回答正确，这周开始出错，因为上下文积累导致注意力分散。工具会失效——API接口挂了、数据库改了字段名、网页改版了CSS选择器。

2026年悄然崛起一个新岗位：Agent SRE（Site Reliability Engineer for Agents）。他们不写Prompt，但给Prompt加版本号；不调模型，但给每次调用打血缘标签；不管前端，但定义失败可追溯性。

没有运维体系的AI项目，上线就是倒计时的开始。不是"会不会出问题"的问题，是"什么时候出问题"的问题。出了问题没有监控、没有告警、没有降级预案——客户在用，AI在错，没人知道。

四、FDE的交付检查清单

理论讲完，实战怎么干。以下是FDE在AI项目交付中总结的检查清单——不是可选项，是交付红线。

场景定义检查：能不能一句话说清"谁、在什么步骤、解决什么问题"？说不清就别动手。能不能量化"不做损失多少、做完改善什么"？量化不了就没法验收。

幻觉治理检查：有没有RAG做事实约束？输出有没有引用溯源？关键信息有没有人工确认环节？三个"有"才敢上线。

成本预算检查：日均调用量多少？每次平均消耗多少Token？月Token费用多少？有没有缓存和摘要优化？算不清账的项目活不过验收。

数据治理检查：脏数据清洗干净了吗？字段映射建立了吗？跨系统数据一致性验证了吗？数据治理没做完，不上线。

权限安全检查：最小权限落实了吗？读写删分级授权了吗？操作日志全覆盖了吗？等保/合规要求达标了吗？安全不过关一票否决。

运维体系检查：有没有监控Agent运行状态？有没有回归测试集？模型升级有没有灰度机制？Agent出问题有没有降级逃生舱？没有运维体系，不上生产。

验收标准检查：验收指标可量化吗？——"单次任务耗时从40分钟到12分钟"是验收标准，"提升效率"不是。有没有明确的失败兜底定义？出了问题谁负责、怎么处理、多久恢复？

这七项检查走完，项目才具备交付的基本条件。不是每项都要满分，但每项不能有空白——有空白的环节就是项目翻车的导火索。

五、FDE方法论：从Demo到交付的四阶段路径

检查清单是"防死"，真正把项目从Demo推到交付，需要一个分阶段的工程化路径。FDE的实践经验提炼为四个阶段。

阶段一：场景锚定——别急着写代码

这一阶段只做一件事：把模糊的"我们要用AI"变成具体的业务场景定义。

核心动作：下业务现场。不是开会讨论，是跟着实际业务人员走一遍真实工作流程——看他在哪个步骤卡住、翻几个系统、花多少时间、出错的频率和代价。

输出物不是技术方案，是一张场景定义卡：谁在用、在哪一步用、现在卡在哪、不做损失多少、做完改善什么。五个问题答不全，回到现场继续看。

这个阶段通常被技术团队跳过——觉得"浪费时间"，急着开始搭系统。但场景没锚定就开工，后面所有返工的代价是这个阶段投入的十倍以上。

FDE铁律：场景定义不清楚，不允许进入下一阶段。这不是官僚主义，是用最小成本防止最大浪费。

阶段二：最小闭环验证——先跑通一个点

场景锚定后，不是立刻搭完整系统，而是跑通一个最小闭环——最小的场景、最少的工具、最简的流程，端到端跑通。

核心原则：砍到不能再砍。能用一个Agent解决的不要上Multi-Agent，能调一个API的不要接三个系统，能用GPT-4o-mini的不要上GPT-4o。先证明"这条路走得通"，再考虑"走得更稳更快"。

这一阶段的关键不是效果多好，是闭环完整性——从用户输入到AI处理到结果返回，全链路跑通，中间每个环节都有输入有输出。闭环跑通了，就有了验证业务价值的基础。

输出物是一个可演示的最小原型——不是炫技Demo，是可以让业务人员实际试用的可用版本。让业务人员用真实数据跑一遍，收集反馈："这个东西对你有用吗？哪里不对？缺什么？"

业务方说"有用"才有资格进入下一阶段。业务方说"不太对"，回阶段一重新锚定场景。

阶段三：工程化加固——从"能跑"到"跑得稳"

业务验证通过后，进入工程化加固。这一阶段做的是把最小闭环变成生产级系统——前面讲的七项检查清单在这里逐项落实。

幻觉治理：加RAG知识库、输出加引用溯源、关键信息加人工确认。

成本控制：加缓存策略、对话摘要压缩、非关键路径用小模型。

数据治理：清洗脏数据、建立字段映射、验证跨系统一致性。

权限安全：最小权限落地、读写删分级授权、操作日志全覆盖。

运维体系：建监控看板、写回归测试集、设计降级预案。

这一阶段是最苦的——没有Demo的惊艳感，没有新技术的兴奋感，全是脏活累活。但这恰恰是90%的项目跳过又死在这里的原因。FDE的核心价值不在阶段二能跑通，在阶段三能扛住。

工程化加固的验收标准不是"功能更全了"，是"最坏情况下也不会出大事"——压力测试通过、边界用例覆盖、失败兜底验证。

阶段四：交付验收——用数字说话

工程化加固完成，进入交付验收。这一阶段的核心是量化——用数字证明AI项目的业务价值。

验收标准必须在阶段一场景锚定时就埋好线——"单次任务耗时从38分钟到7分钟""漏报率从17%到4%""人工翻查系统从3个到1个"。这些数字不是事后编的，是项目启动时就确认的。

交付验收不是"技术团队说做完了就完了"，是业务方用真实场景跑、出具验收报告、签字确认。FDE的经验：客户签字的依据从来不是技术指标，是业务指标。模型准确率98%客户没感觉，"每天省31分钟"客户有感觉。

交付后还有一件事容易被忽略：运维交接。把监控体系、回归测试集、降级预案、运维手册交给客户的运维团队。不交接等于没交付——出了问题客户自己搞不定，最终还是你的锅。

四阶段的时间分配

一个典型的AI项目，四个阶段的时间分配不是均等的。FDE的经验比例：

场景锚定占20%——看似不多，但决定了后面80%的方向对不对。

最小闭环验证占15%——快速验证，快速试错，跑不通就调整。

工程化加固占50%——最重的阶段，所有脏活累活都在这里。

交付验收占15%——含运维交接和文档沉淀。

大多数失败项目的共性：阶段一跳过、阶段二直接当交付、阶段三不存在。时间分配变成了0:100:0:0，Demo就是交付，上线即死亡。

六、AI行业的"Agent脆化危机"

2026年，一个新词在技术圈流行："Agent脆化"（Agent Brittleness）——Agent在Demo阶段表现完美，上线后逐渐变脆、偏离、直到崩溃。

脆化的根源不是模型不行，是"稳定"成了AI时代最稀缺的奢侈品。

模型会偷偷升级。你的提示词在旧版模型上跑得好好的，新版模型悄悄改了行为模式——原来严格按JSON输出的，现在开始"先解释逻辑再给结果"。没有回归测试，你根本不知道。

Agent会漂移。同一个问题上周回答正确，这周开始出错——因为长期运行中上下文不断积累，注意力被稀释，关键信息被淹没。没有监控，你不知道是什么时候开始错的。

工具会失效。API接口挂了、数据库改了字段名、网页改了版——Agent的工具调用链断裂，要么报错要么乱答。没有降级机制，一个小故障变成全线崩溃。

对抗脆化的核心武器是工程化治理，不是换更强的模型。

给模型套可插拔外壳——今天用GPT-5明天切Gemini，业务代码零修改。建立回归测试集——固定高频失败场景，每次模型升级必跑，成功率低于阈值即熔断。设计人类保底协议——Agent连续低置信度自动转人工，推送决策依据包供复核。保留降级逃生舱——Agent宕机时自动切回传统方案，业务不中断。

这些不是技术架构的锦上添花，是交付的保命符。

七、FDE的终极判断：AI不是终点，是新软件工程的起点

回到系列主线。从前九篇到这一篇，FDE的技术栈从低到高走了一遍：

Prompt解决"怎么回答"。RAG解决"凭什么回答"。LangChain解决"怎么串起来"。Agent解决"怎么干起来"。Multi-Agent解决"怎么协作干"。

这一篇解决的是"怎么交付"。而交付才是FDE的终极命题。

技术再先进，交付不了就是零。模型再强大，跑不稳就是负数——不光没创造价值，还制造了风险。

2026年，AI行业正在经历一次清醒：做出一个Agent只需要三天，让它在生产环境跑满一个季度需要三百小时工程设计，让它在每一笔交易里保持零偏差需要一套比传统软件更严苛的治理框架。

AI没有取代工程师，它只是把工程师从"写功能"推上了"管生命"的位置。做出一个Demo是技术能力，把Demo变成可交付的产品是工程能力，让产品在客户现场稳定运行半年以上是FDE能力。

90%的AI项目会死在从Demo到交付的死亡之谷里。但那活下来的10%，才是真正创造价值的AI项目。FDE的价值就是把你从90%拉进10%。

不是因为你技术更强，而是因为你知道——交付的对手不是技术难题，是工程纪律。

模型内卷无出路，落地能力定输赢。而落地能力的本质，是让AI不只活在Demo里，而是活在客户每天的真实工作中。