我过去两年接手和复盘过不少半死不活的AI项目。有些是帮着收拾残局，有些是给团队做事后审计，还有几个是别人在我面前隆重炫了一波demo，然后隔几个月悄悄把项目下线。见得多了以后，我发现一个挺反直觉的事实：真正烂尾的AI项目，极少是因为“算法搞不定”而死的。模型精度不够、效果不好，反而容易暴露问题，最后被救回来；反而是那些看起来很顺、很主流、很“有前途”的项目，静悄悄地就没了声息。
究其原因，大家踩来踩去就是同几个坑。这篇我就把这几道坑一个一个刨开，讲讲它们长什么样、为什么这么坑、用什么方法能绕过去，以及如果你手里已经有一个在烂尾边缘的项目，应该怎么止损和自救。无论你是做AI产品、算法研发，还是搞AI工程落地，这篇文章应该能帮你省下至少一次彻夜改PPT、向老板解释“为什么模型效果很好但业务不买账”的时间。
1. 先看清失败的全貌：烂尾项目通常烂在哪里
1.1 我复盘时看到的三个典型烂尾现场
先说三个我反复在不同团队里看到的场景。
场景A：项目立项时热血沸腾，老板说“我们要做一个基于大模型的智能客服”，算法团队花三个月微调模型，产品经理画了一堆流程图，前端做了个很漂亮的对话窗口。上线后的第一周，业务方反馈“用户根本不用”，因为每次回答都要等五六秒，而且答非所问。又过了一个月，项目没有迭代，没有用户量，没有新的里程碑。再往后，代码库还在，团队已经散了，项目被归入“战略储备”。
场景B：项目在代码层面其实做得不差，有模型服务，有后台管理，有数据统计。但核心业务指标的报表上，始终只有“模型调用量”和“平均响应时间”，至于这个AI到底帮公司省了多少人力、提升多少转化率、解决了什么业务问题，没人能说清。管理层开始质疑投入产出比，项目预算被砍，团队转入维护模式，经费烧完，项目自然雪藏。
场景C：项目最热闹的时候，技术demo视频在公司群里疯转，所有人都觉得这是“年度黑科技”。结果进了生产环境，同一个模型在开发集上的准确率是92%，真实数据上直接跌到63%。业务方丢过来几十个bad case，其中有一半是开发阶段完全没见过的新问题。算法工程师解释“数据分布变了”，但用户不在乎这个，他们只知道“这东西不好用”，于是项目口碑崩盘，再没人愿意用。
这三个场景看似是三个问题：没人用、没价值、效果差。但顺着藤摸上去，摸到最后都是同一批根因。我这篇文章就把这些根因拆成五道坑，每一道坑单独拿出来看都不太难，但五道坑叠在一起，项目就必烂无疑。
1.2 所有烂尾项目的共同结构
如果给这些项目画一张共同的地图，结构大致是这样的：先有一个模糊的“AI灵感”或者领导指示，然后快速组建团队，跳过需求论证直接进入技术选型，再然后在有限的标注数据上训练模型，做出demo后迫不及待上线，最后被真实环境打脸，然后进入“低效修补—预算耗尽—无声退场”的循环。
值得注意的是，这个循环里几乎没有“模型再强一点就能成”的环节。换句话说，把LLM从13B换成70B，把RAG流程改得更花哨，把AI Agent从一个单智能体改成多智能体协作，都无法挽救一个需求本身不成立、数据评估一团糟、工程链路一推就倒的项目。我在后面每一章里都会强调这个结论：AI项目失败是系统性的失败，技术只是其中一环。
2. 伪需求：拿着大模型锤子找钉子
2.1 伪需求是怎么被制造出来的
这是我见过最多、也最致命的一道坑。很多团队立项的理由，根本不是“用户有某个具体问题需要解决”，而是“我们有大模型能力，不用白不用”“别人都在做AI Agent，我们也做一个”“领导在行业会议上看到了趋势，回来要求必须落地AI”。这些动机本身没有错，但问题在于，它们容易让你带着答案找问题，拿着锤子找钉子。
我举一个真实复盘过的例子。某项目组想做一个“智能销售助手”，定位是根据客户聊天记录自动生成跟进摘要和建议话术。听起来很实用对吧？结果一调研，销售团队真正的痛点是CRM系统录入太繁琐、跨部门沟通链路太长，而且销售们根本不相信AI能读懂他们跟客户之间那些微妙的潜台词。功能上线后，销售宁可用两分钟手打跟进记录，也不愿把聊天记录交给AI生成一段“不一定符合真实情况”的摘要。
这种项目的问题在于，需求的提出者是在“会议室想象用户”，而不是在“一线观察用户”。伪需求看上去往往很合理，描述的时候也很有画面感，甚至能画出完整的用户流程图，但真实用户解决这个问题的意愿和付费意愿都极低。判断需求真伪最狠的一个指标，就是看用户是否愿意在你这个东西还不成熟的时候，付出额外成本来用你——包括学习成本、替换旧工具的成本、甚至是在团队里被嘲笑“用AI偷懒”的成本。
2.2 立项前不花钱就能做的需求验证
我自己的习惯，是在写任何一行代码之前，先做三轮最廉价的需求验证。
第一轮叫“行为观察法”。不要问用户“你需要AI帮助你吗”，而是到他们工作的环境里，安静看四五个小时：他们每天哪些事情花了最多时间，哪些环节抱怨最多，哪些动作是重复机械的。AI最适合切入的永远是那些又高频又痛苦又低风险的重复劳动。
第二轮叫“点击付费测试法”。做一个最简陋的落地页或小程序按钮，上面就一句话“AI帮你做XX，现在预约体验”，然后看有多少人真的点击、真的留下联系方式。哪怕最后你根本没做出AI功能，点击率本身就能说明需求热度。如果点击率低得可怜，趁早调整方向。
第三轮叫“人工扮演法”。也就是传说的“羞羞的绿野仙踪”式MVP：后台根本没有模型，是真人假扮AI在回复用户需求。用一个人工客服先撑起整个流程，记录用户在真实使用过程中的话术、期待和耐心阈值。人工跑通一两周，有了真实交互数据，再决定要不要训练模型。这一步能极低成本地验证“用户是否愿意通过对话方式解决这个任务”。
很多团队跳过这三步直接上大模型微调，等于花几十万训练成本去验证一个本来几百块就能验证的问题，这是伪需求成为烂尾项目第一大坑的根本原因。
2.3 真需求的两个底层特征
作为技术人，我们可以不研究玄乎的“痛点理论”，但有两个底层特征非常好用：高频和刚需。
高频意味着用户会经常使用，产品有话语权和迭代空间；刚需意味着用户不依赖你就有明显损失，离开代价高。举个例子，一个“帮工程师写周报”的AI助手，频率不低但不够刚需，因为周报写差了最多挨顿说；但一个“帮客服团队自动分类工单”的AI，每天几千次调用，分类错了整个流程都会堵住，这才值得做成AI项目。
如果你手里的项目一周用不到几次、每次用不到几分钟、不用也没什么后果，那基本可以判断为伪需求。别急着优化模型，先回去重新定义一个更具体、更痛、更频繁发生的任务。
3. 数据与评估欠账：没有标尺就谈不上模型迭代
3.1 只看“准确率”的自我欺骗
第二个高频大坑，是把“模型准确率到90%”当成项目成功的标准。我见过太多项目推进会上，算法负责人意气风发地放出一张PPT：准确率从78%涨到92%，F1值稳稳提升，bad case减少了。台下老板频频点头，但真正跑业务的人心里在嘀咕：这些指标是在哪里测的？测试集是不是已经过拟合？这92%的准确率，能扛住双十一的流量吗？
这里有一个经典翻车案例。某项目做一个法律咨询领域的问答助手，算法团队在自建测试集上准确率达到89%，结果上线后的第一周，用户问了大量关于“诉讼时效中断的具体计算方式”这类细节问题，模型要么引用错法条，要么直接报“我不确定”，业务部门统计的真实准确率只有54%。问题出在测试集构建得太干净了：全是编辑规范过的标准问题，没有错别字、没有方言口音、没有口语化表达。而真实用户的语言，永远比测试集脏得多。
3.2 标准的评估体系至少包含三件套
做AI工程实践这么多年，我认为一套合格的评估体系至少要包含三个部分。
第一部分是数据隔离。训练集、开发集、测试集必须严格隔离，而且测试集应该定期从真实用户会话里抽样补充，而不是永远用同一批固定数据。很多烂尾项目的悲剧，就是从“测试集永远不变”开始的，模型在旧数据上越来越准，但真实世界的用户需求早就变了。
第二部分是分层评估。不要只报一个综合准确率，要按问题类型、用户意图、输入长度、紧急程度等维度拆开看。例如一个智能客服，普通问候语的准确率99%没有意义，真正影响业务的是“退款流程”和“投诉处理”这两类问题的准确率。如果只拿整体指标掩盖了核心场景的烂，那项目就埋了一颗定时炸弹。
第三部分是过程化指标。除了准确率、召回率，更要盯住拒答率、超时率、转人工率、用户满意度这些“体验指标”。一个模型如果遇到不确定的问题就直接拒绝回答，准确率可能很高，但用户体验很差，因为用户被反复踢皮球。这些过程指标才决定了生产环境里的真实体验。
3.3 没有多模态、没有大数据，怎么冷启动
很多团队卡在第一步：产品还没上线，没有用户数据，拿什么训练和评估模型？我的建议是别嫌数据脏，先跑规则系统或人工流程，把“种子数据”攒出来。
举一个契约文档辅助生成项目的例子。项目组想做“用AI辅助起草标准合同条款”，一开始没有真实用户输入，他们就先让业务专家手动写了两百份样例，再让算法工程师用规则模板做了一版极粗糙的“弱AI版”，内部流转收集反馈。三个月下来攒了五千多组真实改写记录，才正式训练模型。这个项目最后成了，而同期另一个团队直接在没有任何数据基础的情况下开始微调大模型，烧了预算却没有可以迭代的反馈闭环，一年后还是原地踏步。
冷启动的关键就一句话：让业务流程先转起来，把每一次人工操作当成一次免费的数据标注。AI项目不是“等数据齐了再开工”，而是“开工了才有数据”，这一点经常被团队搞反。
4. 技术选型与团队错配：杀鸡用了牛刀，牛刀还绑在不稳的刀柄上
4.1 大模型不是万能的，规则系统也不是耻辱
技术选型这道坑，常常表现为两个极端：一种是不管三七二十一，什么问题都上大模型微调、做什么都要搭AI Agent；另一种是到了2025年还在用if-else写规则，拒绝任何AI能力。前者烧钱烧得莫名其妙，后者则白白浪费了技术红利。
我的选型逻辑很简单，分三层看。第一层，如果任务有明确规则、状态有限、不允许含糊，那就用规则系统或传统脚本，比如工单状态流转、定时提醒、格式校验，这类任务上大模型不仅贵，而且不可控。第二层，如果任务需要理解语义但没有太高创造要求，比如文本分类、情感分析、要素抽取，用中小尺寸模型或者传统的机器学习方法就够了，性价比高、延迟低、易排查。第三层，如果任务需要开放式生成、复杂推理、多轮对话，再考虑大模型、RAG乃至AI Agent多智能体协作。
有人觉得项目不用上大模型、不用AI Agent，就不够“AI”。但实际生产环境最讨厌的就是技术炫技。AI Agent这个东西听起来很美好，多智能体协作、自主决策、工具调用，但每一个环节都可能出错：意图识别错了、工具选错了、上下文被截断了、循环出不来了。一旦你没有一个强大的工程团队去兜底，Agent很容易变成“失控的表演”。
4.2 团队结构错配：算法全明星救不了交付
还有一种很常见的烂尾结构：团队里清一色算法工程师，个个名校毕业、顶会论文在手，但没有一个做AI工程化的人，也没有一个愿意泡在一线理解业务的产品经理。让这样一支团队做项目，结果就是模型训练得很漂亮，但没有容器化封装、没有服务化部署、没有性能优化，跑一次推理要三秒，别人一压测就崩。
反之，有些团队工程很强，但没有算法人员，遇到效果问题只会堆规则，系统越来越复杂，最后维护成本高到崩溃。AI项目最健康的团队拼图，按我的经验是三分之一业务/产品、三分之一算法/数据、三分之一后端/工程。尤其是AI工程实践类项目，光有算法或者光有工程都不行，必须有人在中间做翻译，把业务问题翻译成模型问题，再把模型问题翻译成工程接口。
4.3 成本估算里的隐藏漏项
我经常在预算复盘时发现，团队把90%的预算花在了“训练大模型”上，却几乎没给“数据标注”“模型调优”“线上监控”留钱。真实AI项目的成本结构，往往应该是训练占30%、数据占30%、推理和运维占20%、评估和返工占20%。如果你把大头全砸在最开始的那一次模型训练上，后面一旦效果不达标，连返工的余地都没有。
另外，推理成本不能只看单次调用价格。一个每天调用10万次的AI服务，单次延迟多200ms可能没用，但单次成本多个两毛钱，一个月就是几十万。我在帮团队做方案时，习惯把成本拆到“每完成一次业务任务需要多少推理次数”，然后用这个颗粒度去压预算。比如一个AI Agent自动处理客服工单，表面上一次任务只调一次大模型，实际上可能涉及意图识别、知识检索、内容生成、安全合规判断四五次调用，成本瞬间翻好几倍，这些一定要在立项时算清楚。
5. 工程化缺席：Notebook里的神一进生产环境就现原形
5.1 Notebook和线上环境之间的鸿沟
很多AI项目的demo是在Jupyter Notebook里跑通的：数据是挑过的、加载是单线程的、输入是提前清洗好的，一切看起来完美。但上线之后，要面对的是并发、脏数据、超时、限流、网络安全、依赖冲突。这中间的差异，大概等于把一个赛车手从赛车场直接扔进早晚高峰的环路上，再要求他保持同样的平均速度。
我见过一个做视频画质增强的项目，模型效果不错，算法同学在开发环境用单张图片反复验证，峰值信噪比很漂亮。结果上到生产环境，用户传上来的是各种分辨率、各种码率、各种编解码参数的视频，甚至有横屏转竖屏、带字幕水印、手机拍的晃动画面。模型要么预处理崩溃，要么处理一帧要好几秒，最后只能靠大量排队机制“假装在线”，用户等不起就流失了大半。工程化的第一步，永远是先跟脏数据共存，而不是跟漂亮demo共生。
5.2 推理链路上的“安全带”：超时、熔断、降级、兜底
生产环境里的AI服务，必须默认“什么都有可能出错”。强依赖外部大模型API时，网络抖动、供应商限流、响应超时都是常态。我的做法是给每一次模型调用都加三层保护：第一层是超时控制，宁可快速失败也不要让用户无限期等待；第二层是降级策略，核心链路断了就切到规则回答或者转人工，绝不能让用户面对一个永远转圈圈的聊天框；第三层是兜底机制，所有AI回答都保留一个“这条回答仅供参考/一键转人工”的出口。
有一次我在复盘一个AI销售助手的项目时，发现它的转人工按钮藏得很深，用户要翻三层菜单才能找到。结果模型答错几轮后，用户根本不知道怎么找人，只能关掉页面，带着一肚子火走了。真正懂AI工程的人，会把“AI做不到时怎么办”当成和“AI能做到什么”同等重要的问题设计。
5.3 可观测性：别等老板发现问题才去翻日志
一个没有监控的AI项目，就像一辆没有仪表盘的跑车。快是快，但你不知道什么时候会爆缸。那些踩坑的人经常会问：“为什么上线两周后效果越来越差，却没人发现？”答案往往不是没人发现，而是根本没有任何指标能发现：没有token消耗趋势、没有平均延迟变化曲线、没有bad case自动采样、没有用户反馈数据回流。
我建议每个AI服务至少要盯住四类指标：调用量、成功率、延迟分布、拒答/转人工率。再往下，还要定期做数据漂移检测——看看线上输入跟训练集分布是不是已经越来越不同。这个工作一开始就做，成本极低；等项目烂了再补，等于重新开一个新项目。AI项目失败不是一夜之间发生的，它是在指标失明的情况下，一点一点滑下去的。
6. 预期管理失控：老板以为AI能通神，用户拿它当工具
6.1 三层预期，每一层都要对齐
我复盘过的一个AI项目，死得特别冤。论技术、论数据、论工程都不差，但败在没人管理预期：老板以为AI能完全替代20个人力，客户以为AI能回答所有刁钻问题，一线用户以为AI是万能的，任何答错都等于十恶不赦。结果项目上线后三天，老板的兴趣就凉了，因为“AI不但没替代人力，反而让客服团队更忙了”。
预期管理这件事，必须分三层对齐。第一层是给决策层的预期：AI能降本增效，但通常需要3到6个月磨合期；第二层是给业务方的预期：AI能处理70%的常规问题，剩下30%复杂场景仍然需要人介入；第三层是给终端用户的预期：AI是辅助工具，不是真人，它的上限取决于产品和流程设计。这三层只要有一层没对齐，项目就注定在“被误解”和“被失望”中挣扎。
6.2 用业务收益说话，别用技术指标说话
价值交付的失败，是很多AI项目“看上去成功，实际上烂尾”的原因。算法团队交出一个准确率提升2%的模型，但老板真正想听的是“客服人力成本降低15%”“用户问题平均解决时长从两小时缩短到二十分钟”。如果你不能把AI输出翻译成业务语言，那么你在老板眼里就是一个只会烧钱的成本中心。
我自己的习惯，是在项目启动的第一天就定义好两个数字：基线值和目标值。基线值就是“没有AI的时候，当前业务表现是什么样的”，比如客服平均响应时长、工单积压量、销售线索转化率；目标值就是“用了AI之后，我们计划把它优化到什么程度”。后续每一次迭代，都拿真实业务指标对比基线，而不是拿模型指标自嗨。这样项目做到第90天的时候，汇报材料根本不用润色，数据自己会说话。
6.3 拒绝瀑布式憋大招
很多AI项目烂尾，是因为整个团队闷头做了四个月，憋了一个“终极完整版”，结果一上线发现方向根本不对，却已经没有时间再掉头。延期发布、演示Demo永远在“即将完成”、周围人开始失去耐心，是这类项目最常见的状态。
更好的做法是，把项目切成14天一个周期的可感知版本。第一个版本哪怕只做一条最简单的生成链路，也要让真实用户用起来；第二个版本再叠加反馈机制；第三个版本才开始优化质量。这样做既能持续验证需求方向，又能让老板和客户在项目没有烂尾前就看到阶段性价值。AI项目本质上是在“探索—反馈—修正”的循环里滚大的，最忌一次定终身。
7. 从“为什么会烂”到“怎么自救”：一份完整的排查与止损链路
7.1 一个典型烂尾项目的完整复盘推演
为了让你更直观地看到这些坑如何串联起来，我虚拟复原一个典型的烂尾项目，你可以拿它当镜子照照自己手头的项目。
某公司要做“AI文档智能问答系统”，目标是让用户对几十页的合同文档随意提问，AI给答案。立项时，需求来源于领导在行业大会上的见闻，没有做过任何用户访谈。算法团队选型时直接上了大模型+RAG+Agent工作流，试图让系统多步骤检索、多源融合、自动生成答案。评估只做了80条人工构造的问题，准确率看着有90%。上线后，用户问的很多是表格里的金额、日期、百分比，RAG检索经常抓错片段，Agent在多个工具之间循环跳转，回答速度慢而且经常答出“看起来合理但完全错误”的内容。两个月后，团队士气崩了，项目被降级为“实验性功能”。
我们顺着排查链路倒推：需求层面，没有人真正确认过“用户在合同文档场景下，是不是能接受一个回答经常出错的AI”；数据层面，没有收集过真实合同和真实提问；评估层面，测试集没有覆盖表格、长文档、跨章节引用这些高价值场景；技术层面，Agent工作流的复杂度远超团队维护能力；预期层面，项目组从第一天就没有定义“回答正确率多少才叫可用”。五道坑，一步都没绕开。
7.2 止损三问与快速行动清单
如果你现在手里已经有一个不太妙的AI项目，先不要急着优化prompt，更不要急着换更大模型。按下面三个问题过一遍。
第一，这个需求有没有真实用户在用，还是只有团队自己在演示？如果没有真实用户数据，立刻把内心的“demo思维”抛掉，回到2.2节的方法做最小验证。
第二，模型效果有没有系统化评估，还是靠肉眼判断几组bad case？如果评估集还没建立，马上切片分层，从真实会话里抽100条重新标注，用真实准确率和拒答率说话。
第三，工程链路能不能支撑连续运行7天？如果连基本的监控、超时、兜底都没有，先停工搭建基础设施，再谈效果优化。
按照这三个问题排查下来，你会发现80%的项目该做的是“往回收”，而不是“往前冲”。减少功能范围、砍掉炫技模块、把Agent改回单模型、把自主决策改回固定工作流，虽然听起来不够酷，但这是止损最快的方案。
7.3 复盘沉淀：把坑变成启动新项目的清单
最后，每一个失败项目都不该白白死掉。我每次做完复盘，都会把问题整理成一张“下个项目启动检查单”：需求是否被真实行为验证？评估集是否覆盖关键长尾场景？技术方案是否有备选的降级路线？工程埋点是否在上线前就位？预期数字是否与老板对齐？团队是否有人能把算法和业务语言互译？
有了这张单子，AI项目虽然不能保证一定成功，但至少能避开那些反复出现的烂尾坑。你甚至可以把这张单子贴在工位上，每次立项会前逐条打钩，它能帮你省下来的远不止几百万预算。
最后说一点个人体会。我复盘过那么多AI项目，发现团队在项目失败时最常说的一句话是“技术不行”，但我几乎从来没有见过真正纯粹因为技术不行而死的AI项目——大多数烂尾项目，都死在人没有诚实地面对需求、数据、评估和预期。所以如果你即将启动一个AI项目，我建议你做的第一件事不是选框架、不是选模型、不是搭Agent，而是先诚实地回答一个问题：这个东西，到底有谁真的需要它，并且愿意在它不完美的时候就开始用？把这个问题想明白了，后面那些技术选型、数据标注、工程化打磨，才真正有意义。
