★ FEATURED ARTICLE 我过去两年接手和复盘过不少半死不活的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给答案。立项时需求来源于领导在行业大会上的见闻没有做过任何用户访谈。算法团队选型时直接上了大模型RAGAgent工作流试图让系统多步骤检索、多源融合、自动生成答案。评估只做了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而是先诚实地回答一个问题这个东西到底有谁真的需要它并且愿意在它不完美的时候就开始用把这个问题想明白了后面那些技术选型、数据标注、工程化打磨才真正有意义。
阅读完成 · 觉得有帮助？
