AI 项目烂尾的七个征兆，你经历过哪些？

📖 摘要：AI 项目最典型的烂尾形态不是崩掉，而是「还在跑、还能演示、但已经不产生价值」——静默烂尾。本文给出七个可自查的征兆，覆盖需求、组织、数据、交付、运行、运营到度量，每一条都配真实项目里查到的证据（含一次真实体检：健康分 41/100、13.6% 的问题被系统故障拒答、知识库 24.3% 是碎块、响应 P95 42 秒）。自查完给你三条路——救、重建、还是放弃；最后讲清「AI 应用体检」到底查什么、报告长什么样、权限怎么给，以及它和独立验收怎么分工。适合：已投入 AI 应用交付、但对效果存疑的企业决策者与项目负责人。

一、先说一个「还在跑」的烂尾项目

2026 年 9 月，我们给一个 AI 问答应用做了一次体检。

它服务一家网络设备厂商，用来回答自家产品的故障排查问题——设备告警怎么处理、板卡型号有哪些、链路建立失败怎么查。从外面看，它一切正常：页面能打开、问题能回答、演示流畅。它甚至有一个漂亮的数字——上线至今的运行统计里，失败次数是 0。

体检做完，结论是 41 分（满分 100，D 档）。

七个问题被翻出来，其中五个是肉眼看不出来的：

• 服务器上没有任何数据库备份——一次误删、一次勒索，全部应用、知识库、对话记录不可恢复；
• 44 条真实问题里，6 条被系统故障拒答（占 13.6%），而用户收到的是「您的问题似乎不在故障诊断或配置查询范围内」；
• 故障手册知识库里，1401 个分段中有 341 个是代码碎块（24.3%）——检索命中碎块，答案就是半截；
• 响应时间 P95 达到 42 秒（100 次请求中 95 次快于这个数、5 次更慢；实际问答多在 20-40 秒）——用户以为系统坏了，其实它只是慢；
• 以上这些，没有任何人知道。因为没有人看过。

这就是今天要说的第一件事：AI 项目最典型的烂尾形态，不是崩掉。

崩掉反而是好事——宕机、报错、页面打不开，问题可见，大家都会来救。真正麻烦的是另一种：系统还在跑、还能演示、统计数字甚至很漂亮，但它已经不产生价值了。没有人拍桌子说停，它就这么被养着。

我们更愿意叫它静默烂尾——它不出声。

所以这篇文章给你七个征兆，都是可以立刻自查的信号。每一条都配我们在真实项目里查到的证据——不写「一般来说会怎样」，只写「我们查到了什么」。自查完，给你三条路；最后讲清怎么把问题查清楚。

先说适用边界：这篇写给已经投入了 AI 项目、或者正准备投的企业决策者与项目负责人——尤其是心里有「做完了但没效果」「业务方不用」「不知道钱花哪了」这类疑问的人。如果你的项目刚立项、还在选型，这篇同样有用：七个征兆里有五条可以在立项阶段就避开。如果你想要的是「AI 能做什么」的科普，这篇不是。

二、七个征兆

先给你 60 秒版：对着下面七条扫一遍，数一数中了几条。

中三条以上：建议做一次正式体检（第三节讲三条路，第四节讲体检具体查什么）。 中五条以上：优先做一次正式诊断，再决定是否继续投入——不建议直接砍预算或换供应商。

另外说明一点：七条不是互斥关系，它们经常叠加出现、互为因果（比如「没有人负责」会同时导致「需求一句话」和「没有基线」）。所以不必纠结自己中的是哪一条——看总数和组合。

下面是每一条的展开：为什么是病灶、我们查到的证据、以及怎么自查。

征兆一：需求只有一句话

先说一个我们听过太多次的开场。

「我们想做一个 AI 客服。」 「解决什么问题？」 「就是客服答疑，自动回复。」 「怎么算做成功？做到什么程度算可以了？」 沉默。

如果追问一年前立项时是怎么说的——答案是一样的。「做个 AI 客服，提升服务效率」。

这不是需求，这是口号。

为什么这是病灶：AI 项目和普通软件项目有一个根本区别。软件项目把功能清单写清楚就能开工，验收时对清单——功能在，就是完成了。但 AI 项目的产出是「效果」，而效果必须先被定义：要回答哪些问题、答到什么程度算对、答错了怎么兜底、谁来判定。需求只有一句话，就意味着没有可验证的成功标准，也就没有任何人能判断「做没做对」。项目的终点会自动退化成一条：能演示就行。

我们查到的证据：接盘诊断的第一问总是「这个项目当初要解决什么问题？现在这个问题还存在吗？」——相当一部分项目的答案是「提升效率」「做 AI 化」。这类情况在归因里叫「伪需求」：要解决的问题要么不存在，要么不该用 AI 解决，要么早就消失了。更常见的变体是「需求漂移」——做出来的是 A，业务要的是 B，做到一半方向变了，没人拉回来。

自查信号：现在问你的团队「这个项目成功的样子是什么」，能一句话答出具体业务指标吗？比如「客服一次解决率从 40% 提到 70%」「值班工程师查手册的时间从 20 分钟降到 2 分钟」。如果答出来的是「更好用」「更智能」「用起来方便」，那就中了该病灶。

征兆二：没有人对最终效果负责

第二个征兆藏得更深——它不在系统里，在组织里。

典型画面：需求在群里改，产品说「客户要加个功能」，开发说「那我改一下」，效果好不好没人评。上线后出问题，找到谁谁都说「这块不是我负责」。

为什么这是病灶：AI 项目是「持续收敛」的过程——第一版效果一定不完美，靠一轮轮「跑起来 → 看效果 → 调」慢慢逼近目标。这个过程必须有一个对结果负责的人：他定义什么叫好、他决定要不要继续投、效果不达标时他能拍板改方向。没有这个人，每次讨论都是平权投票，方向就会漂。更隐蔽的代价是：出了问题也找不到人复盘——因为它「没有坏」。

我们查到的证据：在项目失败归因里，这一类叫「无人拍板」，是烂尾的头号组织原因。我们在接盘决策矩阵里把它列为独立判定轴——项目资产再好、技术问题再明确，只要「没有能拍板继续投钱的人」，结论就是不接。原因很简单：修好之后它还会再烂一次。

自查信号：谁最终对这个系统的效果负责？追问一句：他最近一次看系统数据是什么时候？如果回答是「IT 部门在管」，再追一层——管到什么程度？如果 IT 的职责是基础设施（服务器、网络、账号），那「答得对不对」仍然没有归属；如果 IT 同时是数字化的归口部门，那责任是清楚的。所以关键不在哪个部门，而在「效果」这件事有没有落到一个具体的人头上。

征兆三：数据是「传上去」的，不是「喂对」的

「知识库是怎么建的？」 「把手册、文档都传上去了。」 「传完之后呢？」 「就……能用了吧。」

为什么这是病灶：知识库问答类应用（RAG——让模型先查资料、再基于资料回答）的答案质量上限，由语料决定。检索命中什么，模型就只能基于什么回答。语料脏、碎、过时——命中碎块就答半截，命中过时内容就给错答案。而这些表现，全都会被归因到「模型不行」上——于是一批人开始换模型、加参数，钱花了，问题还在。

我们查到的证据：那次体检里最典型的发现——故障手册库 1401 个分段中，341 个是代码块被切碎的残片，占 24.3%。问题出在源文档的代码块格式，切分时被拆散；命中的是半截代码，答案自然残缺。更值得注意的是：这个库此前重建过一次，残片依然在——因为从头到尾没有人验证过分段质量。

自查信号：最近一次检索质量验证是什么时候？两个具体问题：一是有没有算过分段质量（碎块占比、异常分段比例）；二是有没有拿真实问题回归测过「该召回的召回了没有、答对了几条」。两个都答不上来，就是没验证过——知识库是你项目里最贵也最脏的一环，而它从建成那天起就没被检查过。

征兆四：验收只看「跑通」，不看「跑对」

「演示的时候挺好的呀。」

这句话我们听过太多遍。它背后是一整条被省略的验收链。

为什么这是病灶：演示验证的是「主流程能走通」，验收验证的是「边界和异常下还靠不靠谱」——这两件事之间隔着一整条河。AI 应用是概率系统：同一个问题问两次，答案可能不一样；靠打开页面点几下，测不出问题。我们做过一组意图分类的测试：同一批问题跑下来，失败率达到 33%。而演示时它是「正常的」。

我们查到的证据：一次典型的交付翻车——文件上传的边界条件一碰就崩、异常输入的回答一本正经地胡说、多轮对话里状态串了线。而客户很困惑：「演示的时候不是好好的吗？」问题不在演示作假，在于演示和验收本来就是两件事，多数项目只做了前者。

自查信号：翻出验收单或者合同附件，看看上面写的是什么。是「完成开发、功能可用」，还是「达到什么标准算好」——每条要求都带可验证的判据？只有前者，等于没有验收。还有一个更直接的问题：你的验收用例是谁写的？如果是开发方自己写自己跑，那不叫验收，叫自测。

征兆五：系统在悄悄拒答，而没人知道

这个征兆最危险，因为它伪装成「业务正常」。

场景还原：体检的 44 条问题里，有一条是「设备温度过高告警怎么处理」。这个问题手册里明明有答案，系统回复的是：「您的问题似乎不在故障诊断或配置查询范围内。」

用户会怎么想？——「可能这个不在知识库里吧。」然后就过去了。

真相是：我们把这条链路逐层拆开查了——这也是整份体检里最花功夫的部分：

根因是三层叠加的：

1. 直接根因：意图分类所用的模型存在概率性输出漂移（历史基线约 8%，本次批量测下来 6/44 ≈ 13.6%——这是 44 条抽测的比例，样本量小，不宜直接外推为长期故障率），配置了重试也没有消除；
2. 最关键的缺陷：系统故障和「业务拒绝」共用同一句话——仪器坏了，却告诉用户「你没病」；用户于是把系统故障理解成业务判断，问题被掩盖；
3. 分类盲区：「XX 的过程是怎样的」这类原理性问题，分类规则没有覆盖，被归到「其他」。

而这一切，在运行统计里的表现是「0 失败」。

为什么这是病灶：AI 系统的故障不会像服务器宕机那样报警——它会把错误包装成业务结论发出去。没有可观测性，就没有人知道它在悄悄拒答、悄悄答错。你以为它在工作，它只是在回答。

自查信号：问一个问题——最近 30 天，系统回复「未找到 / 不在范围内 / 我无法回答」多少次？这里面有多少是业务判断（确实没有这个内容），多少是系统故障（它坏了）？如果分不出来，就是没有可观测性。

征兆六：上线即弃管

上线那天是项目的高光时刻，往往也是最后一天有人认真看它。

为什么这是病灶：AI 系统是活物，不是买回来的软件。有三件事一直在发生：

• 知识会过期——手册改版了、产品线换了、政策更新了，知识库还停在建库那天；
• 规则要调优——业务变了，分类规则和引导话术还按老规则走；
• 质量会漂移——没人测量，好坏全靠感觉。

上线即弃管，退化就开始了——而且是静默的：它不会报错说「我过时了」，只会慢慢给出过时的答案、不准的判断，而大家以为它还在正常工作。

我们查到的证据：那次体检里，内容新鲜度、索引状态这类指标，客户是第一次看到。而「上线三个月后效果悄悄退化」是我们见过最多的一类——系统和三个月前长得一模一样，但它给出的答案已经不是三个月前那个世界的了。

自查信号：谁负责上线后的效果？上线以来做过几次效果评估？如果答案是「上线后就没动过」，那它已经在退化路上了——只是你还不知道。

征兆七：没有基线，说不清「好」长什么样

最后一个征兆，是其他征兆的放大器。

「这个系统现在怎么样？」 「还挺好用的，用户反馈还行。」

为什么这是病灶：没有基线，就无法度量改进，也无法证明价值。更实际的麻烦是：你没法回答「这版改动有没有变好」，也没法回答「钱花得值不值」。决策只能靠感觉——而感觉在预算会上打不过一张 Excel 表。

我们查到的证据：那次体检最重要的产出，其实不是翻出了几个问题，而是建立了一个基线——41 分、七个异常项，每一项都带数据和证据。有了基线，后面每修一项才能说清楚：通过率 69.4% → 85%、异常拒答 6 条 → 0 条、响应 P95 42 秒 → 15 秒以内。没有基线，这些都说不出来；修好了，也只是「感觉好多了」。

自查信号：你能说出这个系统三个月前的关键指标吗——回答率、准确率、响应时间、日均使用量？说不出来，你后来做的优化多半是盲改。

三、自查出问题之后：三条路

中了三条以上的，先别急着换方案、换供应商、加预算。先做一件事：把病在哪一层弄清楚。

先说一个反常识的判断：诊断的价值不在于「能修」，而在于「值不值得修」。 我们见过的烂尾项目里，相当一部分不该修——不是因为修不了，是因为修好了也没价值。敢说「别救了」的人，才有资格说「这个能救」。

判定六问

三种结论，三种动作

几个典型信号（对着客户原话看）

三条边界（很重要）

1. 拿不准，别急着拍板——升级为正式诊断，用证据说话；
2. 修复方案必须带防复发设计——如果主因在运维层（没人维护、衰减无人管），方案里必须包含持续维护机制（如定期复检）。否则半年后它会再烂一次，而这一次依然不会被发现；
3. 先算清楚再动手——修复成本和重建成本的对比要在开工前完成；做到一半才发现「不如重建」的代价，远比事前多花几天评估大。

四、怎么查清：AI 应用体检

自查靠感觉，定案靠证据。这一节讲清楚：体检查什么、怎么查、报告长什么样、权限怎么给。

4.1 为什么「自己看看」不够

三个盲区：

1. 只看得见界面——效果好不好、有没有拒答、检索命中了什么，界面全都不显示。你看到的是整条链路的最后一环，前面全在黑盒里；
2. 没有基线——没有历史数据，说不清现在算好还是差；改完也说不清有没有变好；
3. 无法取证——「用户说答得不准」「业务方觉得不好用」这类反馈，落不到节点、落不到数据。而 AI 应用的问题，只有追到链路层才能定案（就像前文那条被拒问题的五层拆解）。

4.2 体检查什么：三层采集 + 真实问题实测

另外三类容易被忽略、但同样在检查范围：成本（token 消耗与趋势——AI 系统的「电费」）、安全合规（AI 内容标识、越权访问、提示注入防护）、使用采纳（上线之后到底有没有人在用、用了多少次）。

4.3 关键一步：拿真实问题去问它

体检不是「看看配置」，是拿问题去实测。问题分四层出：

40 多条问题跑下来，每条记录四样东西：响应状态、耗时、会话 ID、回答内容。然后逐条判定：答对、部分答对、答错、被拒。

被拒的要逐条追根因——是被系统故障拒的，还是真的不该答。这一步是整份体检里最花时间、也最有价值的地方。前文那条「设备温度过高告警」被拒的问题，就是从这里翻出来的：如果只看统计数字，它是 0 失败；只有逐条追链路，才能看到系统故障被包装成了业务拒绝。

三个口径说明。第一，本文引用的实测数据来自一次快照式体检——44 条问题集一次性实测，加上近 20 小时的全量节点执行记录（462 次）。比例会随样本量和时间窗波动，它的用途是定位问题，不是长期统计结论。第二，「失败」必须分类看：接口层报错、系统故障拒答、业务拒答（库里确实没有）、安全拒答（越界或注入被拦）——把它们混在一起算成一个「失败率」，是很多项目自评失真的根源。第三，实测用真实问题调用真实应用，会产生真实的会话记录与模型消耗（计入你自己的账号）——担心与业务数据混淆的，可指定测试应用或测试环境来跑。

4.4 报告长什么样

报告的核心是三样东西：

第一，健康分 + 一句话总结。 比如那份报告：「健康分 41/100（D 档）。回答质量本身扎实——库内 31 条可直接回答的问题中 18 条答对、拒答诚实、安全规则有效；但意图分类节点系统性不稳，导致 6 条本可回答的问题被拒，响应 P95 达 42 秒，服务器无任何备份——属「带病可治」。

以那次 41 分的体检为例，五类维度的实际判定是：功能类（实测通过率 69.4%）❌、异常处理类（L4 边界 6 条全过）✅、性能类（响应 P95 42 秒）❌、安全类（注入与越界通过，但缺 AI 内容标识）⚠️、可靠性类（44 条中 6 条节点异常）❌——加权之后得到 41 分。哪一类拖了后腿，一眼能看出来。

第二，异常项详解表。 每一项都有六列：问题、所属、严重度、证据、影响、建议。其中证据是硬要求——「分类节点 6 条实测异常」「1401 个分段中 341 个是残片」这种颗粒度，不允许出现「建议优化一下」这类没有证据的结论。

第三，根因诊断。 对关键异常做链路级拆解，就像前文展示的那张五层追查表——每层都用运行证据说话，最后落到「改什么、预期什么效果」。

关于健康分的口径：它由功能、异常处理、性能、安全、可靠性五类维度加权计算（权重按业务影响分配，且单项短板不倒挂——某个维度分数再高，也拉不回一个红灯项）；内容健康、使用采纳与环境风险单列、不计入总分。这是经验性评分，用途是纵向对比（同一系统前后变化）和横向定位（短板在哪一层），不是行业标准认证——我们也没打算把它包装成认证。分数按区间分 A-D 四档，用于快速判断系统处于什么状态。

这里有一个刻意的设计：「没人用」不会因为不进总分就被漏掉。使用采纳、内容健康这类观察区指标虽然不加分，但会在报告里单列披露、关键信号在总检结论里点名——比如「健康分 72，但使用采纳红灯：日均调用 3 次，未产生业务价值」。一个答得挺好、但没人用的系统，不该被判为健康；扣不扣分是评分口径的事，说不说清楚是结论的责任。

4.5 体检的前提与边界

体检有一个硬前提：能访问运行环境——读运行数据、拿真实问题去实测。没有这个前提，能做的只有静态检查（应用结构、配置、链路），那属于另一个环节，不是体检。

另外两种情况先别做体检：

• 还没上线：没有真实用户、没有运行数据，查不出运行态的问题；
• 需求还没定：说不清要解决什么问题、什么算成功，先做需求梳理——体检能告诉你「系统哪里不够好」，回答不了「该往哪做」。

体检解决的是「已有系统健不健康」，不是「该不该做这件事」。

4.6 它和「独立验收」不是一回事

这是最常被问到的问题，一次说清：

一句话：上线前用验收把关，上线后用体检巡诊。 两者都不动手改——修是第三个环节。

五、收口

回到开头那个 41 分的项目。

它现在还在跑。体检之后，客户拿到的是：七个异常、每个异常的根因、修复路径和优先级——以及一个基线。接下来是修、是重建、还是先放着，是他的决定；但至少这个决定，建立在数据上，而不是感觉上。

七个征兆，如果你中了三条以上，我建议你先别动方案、别动预算——先花点时间把「病在哪一层」弄清楚。大多数 AI 项目的钱不是花错了地方，是根本没搞清楚该花在哪。

项目烂尾不是轰的一声，是嘘的一声。它不会通知你。

对照着上面七条，你中了几条？

常见问题

静态检查和运行态检查，能发现的问题有什么不同？

静态检查看的是交付物（应用结构、节点配置、链路完整性），能在文件层面发现问题——缺验签、密钥硬编码、分支边漏接；运行态检查看的是运行中的系统，能发现数据层与环境层的问题——知识库分段质量、真实问答的命中与拒答、响应耗时分布、备份与资源风险。两者不重叠也不冲突：一个回答「设计对不对」，一个回答「跑得好不好」。一个常见现象是静态检查全绿、运行态一测就露馅——配置正确不等于效果正确。

问题集该怎么出题，才算有效？

按四层出：L1 存活与基础能力（你好、你能做什么）；L2 库内真实问题（必须来自真实语料主题，不能编造）；L3 多轮追问（问到第三问，看上下文还在不在）；L4 边界与异常（空白输入、越界、提示注入）。三个要点：一是 L2 的题必须基于真实知识库内容，测试点才有意义；二是要包含历史踩坑的重现题（曾经出过的问题，回归看有没有复发）；三是判定要能落到节点——测完追不到根因的题，等于没测。

为什么「被拒」必须逐条追根因、分类统计？

因为「被拒」至少分四类：接口层报错、系统故障（节点异常走兜底）、业务拒答（库里确实没有）、安全拒答（越界或注入被拦）。把它们混成一个「失败率」，结论必然失真——我们遇到过的一次：表面上像「知识库覆盖不足」，逐条追下去发现主因是意图分类节点的输出漂移，修检索根本治不好。

没有基线，第一次体检该怎么做？

第一次体检本身就是建立基线：选一组稳定的问题集（比如 40 条分层题）、固定判定口径、把关键指标记下来（通过率、异常数、响应分位、内容健康指标）。下一次用同一组题、同一口径复跑，前后对比才有意义。最忌讳每次换一套题——那样得不到趋势，只能得到「今天看起来还行」。频率上：知识和业务变化快的，季度一次；变化慢的至少半年一次；另外，大的改动上线后一定要补做一次——确认没改坏。

健康分和传统测试的通过率，有什么区别？

通过率只反映一个维度，而且容易被稀释——95% 听起来不错，但剩下的 5% 如果全是核心问题呢？健康分按功能、异常处理、性能、安全、可靠性五类加权计算，并且单项短板不倒挂（某个维度分数再高也拉不回一个红灯项）；内容健康、使用采纳、环境风险单列、不计入总分。差别在于：通过率回答「答对了多少」，健康分回答「整体健不健康」，而短板定位靠的是异常项详解和根因诊断。

相关文章：AI 系统上线三个月后，开始悄悄退化——为什么 AI 项目不是一锤子买卖（本文讲"怎么发现坏了"，这篇讲"为什么一定会坏"）｜AI 应用交付靠不靠谱，看它的用例质量——用例是长出来的，不是写出来的（上线前把关的起点）｜AI 应用上线前怎么验：一套可复用的验收方法论（验收方法论的完整版）

本文基于作者在 AI 应用交付与体检中的真实实测记录，文中案例已脱敏。AI 参与创作声明：本文由 AI 辅助写作。