AI 项目烂尾的七个征兆自查清单与三条出路AI 项目交付 · 独立篇 | 基于 Dify 1.17 Hermes Agent v0.21 实测2026-09DeepSeek 摘要AI 项目最典型的烂尾不是崩掉而是「还在跑、还能演示、但已经不产生价值」——静默烂尾没有人拍桌子说停。本文给出一份七条自查清单覆盖需求、组织、数据、交付、运行、运营、度量每条都配真实项目里查到的证据一次 AI 问答应用体检健康分 41/100、13.6% 的问题被系统故障拒答、知识库 24.3% 是碎块、响应 P95 42 秒——而它的运行统计里显示「0 失败」。自查之后给你三条路救、重建还是放弃最后讲清 AI 应用体检到底查什么、报告长什么样。适合已投入 AI 项目、但对效果存疑的企业决策者与项目负责人。相关AI 系统上线三个月后开始悄悄退化——为什么 AI 项目不是一锤子买卖本文讲「怎么发现坏了」这篇讲「为什么一定会坏」一、先说一个「还在跑」的烂尾项目2026 年 9 月我们给一个 AI 问答应用做了一次体检。它服务一家网络设备厂商用来回答自家产品的故障排查问题——设备告警怎么处理、板卡型号有哪些、链路建立失败怎么查。从外面看它一切正常页面能打开、问题能回答、演示流畅。它甚至有一个漂亮的数字——上线至今的运行统计里失败次数是0。体检做完结论是41 分满分 100D 档。七个问题被翻出来其中五个是肉眼看不出来的服务器上没有任何数据库备份——一次误删、一次勒索全部应用、知识库、对话记录不可恢复44 条真实问题里6 条被系统故障拒答占 13.6%而用户收到的是「您的问题似乎不在故障诊断或配置查询范围内」故障手册知识库里1401 个分段中有 341 个是代码碎块24.3%——检索命中碎块答案就是半截响应时间 P95 达到 42 秒100 次请求中 95 次快于这个数、5 次更慢实际问答多在 20-40 秒——用户以为系统坏了其实它只是慢以上这些没有任何人知道。因为没有人看过。这就是今天要说的第一件事AI 项目最典型的烂尾形态不是崩掉。崩掉反而是好事——宕机、报错、页面打不开问题可见大家都会来救。真正麻烦的是另一种系统还在跑、还能演示、统计数字甚至很漂亮但它已经不产生价值了。没有人拍桌子说停它就这么被养着。我们更愿意叫它静默烂尾——它不出声。所以这篇文章给你七个征兆都是可以立刻自查的信号。每一条都配我们在真实项目里查到的证据——不写「一般来说会怎样」只写「我们查到了什么」。自查完给你三条路最后讲清怎么把问题查清楚。先说适用边界这篇写给已经投入了 AI 项目、或者正准备投的企业决策者与项目负责人——尤其是心里有「做完了但没效果」「业务方不用」「不知道钱花哪了」这类疑问的人。如果你的项目刚立项、还在选型这篇同样有用七个征兆里有五条可以在立项阶段就避开。如果你想要的是「AI 能做什么」的科普这篇不是。二、七个征兆先给你 60 秒版对着下面七条扫一遍数一数中了几条。#征兆一句话自查1需求只有一句话说得出「成功的样子」吗——具体到业务指标2没有人对最终效果负责谁签字他最近一次看系统数据是什么时候3数据是「传上去」的最近一次检索质量验证是什么时候4验收只看「跑通」验收单上写的是「完成开发」还是「达到什么标准算好」5系统在悄悄拒答近 30 天「未找到 / 不在范围」多少次——分得清系统故障和业务判断吗6上线即弃管上线以来做过几次效果评估7没有基线说得清三个月前的关键指标吗中三条以上建议做一次正式体检第三节讲三条路第四节讲体检具体查什么。中五条以上优先做一次正式诊断再决定是否继续投入——不建议直接砍预算或换供应商。另外说明一点七条不是互斥关系它们经常叠加出现、互为因果比如「没有人负责」会同时导致「需求一句话」和「没有基线」。所以不必纠结自己中的是哪一条——看总数和组合。下面是每一条的展开为什么是病灶、我们查到的证据、以及怎么自查。征兆一需求只有一句话先说一个我们听过太多次的开场。「我们想做一个 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 前置改写问题改写节点输出正常2 查询兜底查询构造输出正常3 意图分类分类节点状态异常——模型输出的不是预期的结构化格式解析直接失败4 兜底分支异常分支正常触发——异常被路由到「其他问题引导」5 用户感知最终回答「您的问题不在范围内」根因是三层叠加的直接根因意图分类所用的模型存在概率性输出漂移历史基线约 8%本次批量测下来 6/44 ≈ 13.6%——这是 44 条抽测的比例样本量小不宜直接外推为长期故障率配置了重试也没有消除最关键的缺陷系统故障和「业务拒绝」共用同一句话——仪器坏了却告诉用户「你没病」用户于是把系统故障理解成业务判断问题被掩盖分类盲区「XX 的过程是怎样的」这类原理性问题分类规则没有覆盖被归到「其他」。而这一切在运行统计里的表现是「0 失败」。为什么这是病灶AI 系统的故障不会像服务器宕机那样报警——它会把错误包装成业务结论发出去。没有可观测性就没有人知道它在悄悄拒答、悄悄答错。你以为它在工作它只是在回答。自查信号问一个问题——最近 30 天系统回复「未找到 / 不在范围内 / 我无法回答」多少次这里面有多少是业务判断确实没有这个内容多少是系统故障它坏了如果分不出来就是没有可观测性。征兆六上线即弃管上线那天是项目的高光时刻往往也是最后一天有人认真看它。为什么这是病灶AI 系统是活物不是买回来的软件。有三件事一直在发生知识会过期——手册改版了、产品线换了、政策更新了知识库还停在建库那天规则要调优——业务变了分类规则和引导话术还按老规则走质量会漂移——没人测量好坏全靠感觉。上线即弃管退化就开始了——而且是静默的它不会报错说「我过时了」只会慢慢给出过时的答案、不准的判断而大家以为它还在正常工作。我们查到的证据那次体检里内容新鲜度、索引状态这类指标客户是第一次看到。而「上线三个月后效果悄悄退化」是我们见过最多的一类——系统和三个月前长得一模一样但它给出的答案已经不是三个月前那个世界的了。自查信号谁负责上线后的效果上线以来做过几次效果评估如果答案是「上线后就没动过」那它已经在退化路上了——只是你还不知道。征兆七没有基线说不清「好」长什么样最后一个征兆是其他征兆的放大器。「这个系统现在怎么样」「还挺好用的用户反馈还行。」为什么这是病灶没有基线就无法度量改进也无法证明价值。更实际的麻烦是你没法回答「这版改动有没有变好」也没法回答「钱花得值不值」。决策只能靠感觉——而感觉在预算会上打不过一张 Excel 表。我们查到的证据那次体检最重要的产出其实不是翻出了几个问题而是建立了一个基线——41 分、七个异常项每一项都带数据和证据。有了基线后面每修一项才能说清楚通过率 69.4% → 85%、异常拒答 6 条 → 0 条、响应 P95 42 秒 → 15 秒以内。没有基线这些都说不出来修好了也只是「感觉好多了」。自查信号你能说出这个系统三个月前的关键指标吗——回答率、准确率、响应时间、日均使用量说不出来你后来做的优化多半是盲改。三、自查出问题之后三条路中了三条以上的先别急着换方案、换供应商、加预算。先做一件事把病在哪一层弄清楚。先说一个反常识的判断诊断的价值不在于「能修」而在于「值不值得修」。我们见过的烂尾项目里相当一部分不该修——不是因为修不了是因为修好了也没价值。敢说「别救了」的人才有资格说「这个能救」。判定六问#问题关键信号1当初要解决的问题现在还存在、还值得解决吗问题消失 / 伪需求 → 直接放弃2资产还在吗数据、文档、代码、账号全丢 → 无从救起只能重建3病在哪一层需求层 / 技术层 / 运维层主因在需求层 → 修了也白修4修复成本 vs 重建成本修复超过重建的 60% → 重建更划算5有能拍板的人吗没有 → 修好还会再烂一次6你对「成功」的定义现实吗期望离谱要通用大模型干垂直精活→ 先校准再谈三种结论三种动作结论什么情况动作救需求真实、主因在技术层配置/数据/链路可修、资产可复用、有拍板人出修复方案逐项病灶、修复路径、工期、验收标准、预期效果重建需求真实但技术层烂到根架构错配 / 数据不可用 / 前任黑盒无文档或修复成本 ≥ 重建的 60%推倒重来但旧资产数据、文档、部分模块要列复用清单——重建不等于从零放弃问题已消失 / 无人拍板 / 预算时间窗不合理 / 期望无法校准书面理由 替代建议不用 AI或换一个更小的方案诊断结论六问判定救出修复方案逐项病灶 修复路径 验收标准 预期效果重建旧资产列复用清单按新项目重做放弃书面理由 替代建议几个典型信号对着客户原话看你听到的话倾向「当时想做个 XX现在团队都换人了 / 业务砍了」放弃「功能其实能用就是没人用 / 效果一般」救——运维层、调优层的病「数据都丢了 / 代码在跑路的乙方手里 / 没有文档」重建「每次问 AI 都答得乱七八糟」但语料是齐的救——检索和数据工程的问题这一层最好治「领导说要 AI 化我们也不知道要啥」放弃或先做需求咨询不是接盘三条边界很重要拿不准别急着拍板——升级为正式诊断用证据说话修复方案必须带防复发设计——如果主因在运维层没人维护、衰减无人管方案里必须包含持续维护机制如定期复检。否则半年后它会再烂一次而这一次依然不会被发现先算清楚再动手——修复成本和重建成本的对比要在开工前完成做到一半才发现「不如重建」的代价远比事前多花几天评估大。四、怎么查清AI 应用体检自查靠感觉定案靠证据。这一节讲清楚体检查什么、怎么查、报告长什么样、权限怎么给。4.1 为什么「自己看看」不够三个盲区只看得见界面——效果好不好、有没有拒答、检索命中了什么界面全都不显示。你看到的是整条链路的最后一环前面全在黑盒里没有基线——没有历史数据说不清现在算好还是差改完也说不清有没有变好无法取证——「用户说答得不准」「业务方觉得不好用」这类反馈落不到节点、落不到数据。而 AI 应用的问题只有追到链路层才能定案就像前文那条被拒问题的五层拆解。4.2 体检查什么三层采集 真实问题实测环境层备份 / 磁盘 / SSL / 端口 / 容器应用层用量 / 知识库内容健康 / 配置快照 / 查询记录Agent 层约束文件 / 能力可达性 / 记忆一致性真实问题实测L1-L440 条体检报告健康分 总检结论异常项详解问题 / 证据 / 影响 / 建议根因诊断链路级拆解层查什么典型发现环境层服务器资源、数据库备份、SSL、端口、容器状态数据不可恢复风险那次体检的头号问题就是「没有任何备份」应用层用量与活跃、知识库内容健康分段质量 / 破碎率 / 新鲜度 / 索引状态、应用配置快照、真实查询记录知识库碎块 24.3%、检索命中差、配置漂移、实际上没人用Agent 层AI 助手自身约束文件结构、能力可达性、记忆一致性记忆条目互相冲突、约束文件失效而不自知另外三类容易被忽略、但同样在检查范围成本token 消耗与趋势——AI 系统的「电费」、安全合规AI 内容标识、越权访问、提示注入防护、使用采纳上线之后到底有没有人在用、用了多少次。4.3 关键一步拿真实问题去问它体检不是「看看配置」是拿问题去实测。问题分四层出L1 存活与基础能力你好 / 你能做什么L2 库内真实问题手册里确实有的内容L3 多轮追问问到第三问它还记不记得上下文L4 边界与异常空白输入 / 越界问题 / 诱导40 多条问题跑下来每条记录四样东西响应状态、耗时、会话 ID、回答内容。然后逐条判定答对、部分答对、答错、被拒。被拒的要逐条追根因——是被系统故障拒的还是真的不该答。这一步是整份体检里最花时间、也最有价值的地方。前文那条「设备温度过高告警」被拒的问题就是从这里翻出来的如果只看统计数字它是 0 失败只有逐条追链路才能看到系统故障被包装成了业务拒绝。三个口径说明。第一本文引用的实测数据来自一次快照式体检——44 条问题集一次性实测加上近 20 小时的全量节点执行记录462 次。比例会随样本量和时间窗波动它的用途是定位问题不是长期统计结论。第二「失败」必须分类看接口层报错、系统故障拒答、业务拒答库里确实没有、安全拒答越界或注入被拦——把它们混在一起算成一个「失败率」是很多项目自评失真的根源。第三实测用真实问题调用真实应用会产生真实的会话记录与模型消耗计入你自己的账号——担心与业务数据混淆的可指定测试应用或测试环境来跑。4.4 报告长什么样报告的核心是三样东西第一健康分 一句话总结。比如那份报告「健康分 41/100D 档。回答质量本身扎实——库内 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 它和「独立验收」不是一回事这是最常被问到的问题一次说清独立验收应用体检时机上线前 / 交付时点上线后 / 运行中对象交付物应用本身运行中的系统应用 数据 环境 Agent输入材料如应用配置文件、用例真实环境访问 真实问题实测回答的问题这个应用能不能上线这个系统现在健不健康、病在哪一层产出验收报告缺陷清单 上线评估体检报告健康分 异常详解 根因 医嘱一句话上线前用验收把关上线后用体检巡诊。两者都不动手改——修是第三个环节。五、收口回到开头那个 41 分的项目。它现在还在跑。体检之后客户拿到的是七个异常、每个异常的根因、修复路径和优先级——以及一个基线。接下来是修、是重建、还是先放着是他的决定但至少这个决定建立在数据上而不是感觉上。七个征兆如果你中了三条以上我建议你先别动方案、别动预算——先花点时间把「病在哪一层」弄清楚。大多数 AI 项目的钱不是花错了地方是根本没搞清楚该花在哪。项目烂尾不是轰的一声是嘘的一声。它不会通知你。对照着上面七条你中了几条常见问题静态检查和运行态检查能发现的问题有什么不同静态检查看的是交付物应用结构、节点配置、链路完整性能在文件层面发现问题——缺验签、密钥硬编码、分支边漏接运行态检查看的是运行中的系统能发现数据层与环境层的问题——知识库分段质量、真实问答的命中与拒答、响应耗时分布、备份与资源风险。两者不重叠也不冲突一个回答「设计对不对」一个回答「跑得好不好」。一个常见现象是静态检查全绿、运行态一测就露馅——配置正确不等于效果正确。问题集该怎么出题才算有效按四层出L1 存活与基础能力你好、你能做什么L2 库内真实问题必须来自真实语料主题不能编造L3 多轮追问问到第三问看上下文还在不在L4 边界与异常空白输入、越界、提示注入。三个要点一是 L2 的题必须基于真实知识库内容测试点才有意义二是要包含历史踩坑的重现题曾经出过的问题回归看有没有复发三是判定要能落到节点——测完追不到根因的题等于没测。为什么「被拒」必须逐条追根因、分类统计因为「被拒」至少分四类接口层报错、系统故障节点异常走兜底、业务拒答库里确实没有、安全拒答越界或注入被拦。把它们混成一个「失败率」结论必然失真——我们遇到过的一次表面上像「知识库覆盖不足」逐条追下去发现主因是意图分类节点的输出漂移修检索根本治不好。没有基线第一次体检该怎么做第一次体检本身就是建立基线选一组稳定的问题集比如 40 条分层题、固定判定口径、把关键指标记下来通过率、异常数、响应分位、内容健康指标。下一次用同一组题、同一口径复跑前后对比才有意义。最忌讳每次换一套题——那样得不到趋势只能得到「今天看起来还行」。频率上知识和业务变化快的季度一次变化慢的至少半年一次另外大的改动上线后一定要补做一次——确认没改坏。健康分和传统测试的通过率有什么区别通过率只反映一个维度而且容易被稀释——95% 听起来不错但剩下的 5% 如果全是核心问题呢健康分按功能、异常处理、性能、安全、可靠性五类加权计算并且单项短板不倒挂某个维度分数再高也拉不回一个红灯项内容健康、使用采纳、环境风险单列、不计入总分。差别在于通过率回答「答对了多少」健康分回答「整体健不健康」而短板定位靠的是异常项详解和根因诊断。 这七个征兆你中了几条哪一条最难自查出来评论区聊聊。相关文章AI 系统上线三个月后开始悄悄退化——为什么 AI 项目不是一锤子买卖静默退化的成因本文的姊妹篇AI 应用交付靠不靠谱看它的用例质量——用例是长出来的不是写出来的上线前把关的起点AI 应用上线前怎么验一套可复用的验收方法论验收方法论完整版 更多实战记录见我的博客鱼日先生本文基于 Dify 1.17 Hermes Agent v0.21 实测。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。 
长河君 · 2026/9/14 21:55:12 · 阅读 1.2k AI项目烂尾的七个征兆，你经历过哪些？
AI 项目烂尾的七个征兆自查清单与三条出路AI 项目交付 · 独立篇 | 基于 Dify 1.17 Hermes Agent v0.21 实测2026-09DeepSeek 摘要AI 项目最典型的烂尾不是崩掉而是「还在跑、还能演示、但已经不产生价值」——静默烂尾没有人拍桌子说停。本文给出一份七条自查清单覆盖需求、组织、数据、交付、运行、运营、度量每条都配真实项目里查到的证据一次 AI 问答应用体检健康分 41/100、13.6% 的问题被系统故障拒答、知识库 24.3% 是碎块、响应 P95 42 秒——而它的运行统计里显示「0 失败」。自查之后给你三条路救、重建还是放弃最后讲清 AI 应用体检到底查什么、报告长什么样。适合已投入 AI 项目、但对效果存疑的企业决策者与项目负责人。相关AI 系统上线三个月后开始悄悄退化——为什么 AI 项目不是一锤子买卖本文讲「怎么发现坏了」这篇讲「为什么一定会坏」一、先说一个「还在跑」的烂尾项目2026 年 9 月我们给一个 AI 问答应用做了一次体检。它服务一家网络设备厂商用来回答自家产品的故障排查问题——设备告警怎么处理、板卡型号有哪些、链路建立失败怎么查。从外面看它一切正常页面能打开、问题能回答、演示流畅。它甚至有一个漂亮的数字——上线至今的运行统计里失败次数是0。体检做完结论是41 分满分 100D 档。七个问题被翻出来其中五个是肉眼看不出来的服务器上没有任何数据库备份——一次误删、一次勒索全部应用、知识库、对话记录不可恢复44 条真实问题里6 条被系统故障拒答占 13.6%而用户收到的是「您的问题似乎不在故障诊断或配置查询范围内」故障手册知识库里1401 个分段中有 341 个是代码碎块24.3%——检索命中碎块答案就是半截响应时间 P95 达到 42 秒100 次请求中 95 次快于这个数、5 次更慢实际问答多在 20-40 秒——用户以为系统坏了其实它只是慢以上这些没有任何人知道。因为没有人看过。这就是今天要说的第一件事AI 项目最典型的烂尾形态不是崩掉。崩掉反而是好事——宕机、报错、页面打不开问题可见大家都会来救。真正麻烦的是另一种系统还在跑、还能演示、统计数字甚至很漂亮但它已经不产生价值了。没有人拍桌子说停它就这么被养着。我们更愿意叫它静默烂尾——它不出声。所以这篇文章给你七个征兆都是可以立刻自查的信号。每一条都配我们在真实项目里查到的证据——不写「一般来说会怎样」只写「我们查到了什么」。自查完给你三条路最后讲清怎么把问题查清楚。先说适用边界这篇写给已经投入了 AI 项目、或者正准备投的企业决策者与项目负责人——尤其是心里有「做完了但没效果」「业务方不用」「不知道钱花哪了」这类疑问的人。如果你的项目刚立项、还在选型这篇同样有用七个征兆里有五条可以在立项阶段就避开。如果你想要的是「AI 能做什么」的科普这篇不是。二、七个征兆先给你 60 秒版对着下面七条扫一遍数一数中了几条。#征兆一句话自查1需求只有一句话说得出「成功的样子」吗——具体到业务指标2没有人对最终效果负责谁签字他最近一次看系统数据是什么时候3数据是「传上去」的最近一次检索质量验证是什么时候4验收只看「跑通」验收单上写的是「完成开发」还是「达到什么标准算好」5系统在悄悄拒答近 30 天「未找到 / 不在范围」多少次——分得清系统故障和业务判断吗6上线即弃管上线以来做过几次效果评估7没有基线说得清三个月前的关键指标吗中三条以上建议做一次正式体检第三节讲三条路第四节讲体检具体查什么。中五条以上优先做一次正式诊断再决定是否继续投入——不建议直接砍预算或换供应商。另外说明一点七条不是互斥关系它们经常叠加出现、互为因果比如「没有人负责」会同时导致「需求一句话」和「没有基线」。所以不必纠结自己中的是哪一条——看总数和组合。下面是每一条的展开为什么是病灶、我们查到的证据、以及怎么自查。征兆一需求只有一句话先说一个我们听过太多次的开场。「我们想做一个 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 前置改写问题改写节点输出正常2 查询兜底查询构造输出正常3 意图分类分类节点状态异常——模型输出的不是预期的结构化格式解析直接失败4 兜底分支异常分支正常触发——异常被路由到「其他问题引导」5 用户感知最终回答「您的问题不在范围内」根因是三层叠加的直接根因意图分类所用的模型存在概率性输出漂移历史基线约 8%本次批量测下来 6/44 ≈ 13.6%——这是 44 条抽测的比例样本量小不宜直接外推为长期故障率配置了重试也没有消除最关键的缺陷系统故障和「业务拒绝」共用同一句话——仪器坏了却告诉用户「你没病」用户于是把系统故障理解成业务判断问题被掩盖分类盲区「XX 的过程是怎样的」这类原理性问题分类规则没有覆盖被归到「其他」。而这一切在运行统计里的表现是「0 失败」。为什么这是病灶AI 系统的故障不会像服务器宕机那样报警——它会把错误包装成业务结论发出去。没有可观测性就没有人知道它在悄悄拒答、悄悄答错。你以为它在工作它只是在回答。自查信号问一个问题——最近 30 天系统回复「未找到 / 不在范围内 / 我无法回答」多少次这里面有多少是业务判断确实没有这个内容多少是系统故障它坏了如果分不出来就是没有可观测性。征兆六上线即弃管上线那天是项目的高光时刻往往也是最后一天有人认真看它。为什么这是病灶AI 系统是活物不是买回来的软件。有三件事一直在发生知识会过期——手册改版了、产品线换了、政策更新了知识库还停在建库那天规则要调优——业务变了分类规则和引导话术还按老规则走质量会漂移——没人测量好坏全靠感觉。上线即弃管退化就开始了——而且是静默的它不会报错说「我过时了」只会慢慢给出过时的答案、不准的判断而大家以为它还在正常工作。我们查到的证据那次体检里内容新鲜度、索引状态这类指标客户是第一次看到。而「上线三个月后效果悄悄退化」是我们见过最多的一类——系统和三个月前长得一模一样但它给出的答案已经不是三个月前那个世界的了。自查信号谁负责上线后的效果上线以来做过几次效果评估如果答案是「上线后就没动过」那它已经在退化路上了——只是你还不知道。征兆七没有基线说不清「好」长什么样最后一个征兆是其他征兆的放大器。「这个系统现在怎么样」「还挺好用的用户反馈还行。」为什么这是病灶没有基线就无法度量改进也无法证明价值。更实际的麻烦是你没法回答「这版改动有没有变好」也没法回答「钱花得值不值」。决策只能靠感觉——而感觉在预算会上打不过一张 Excel 表。我们查到的证据那次体检最重要的产出其实不是翻出了几个问题而是建立了一个基线——41 分、七个异常项每一项都带数据和证据。有了基线后面每修一项才能说清楚通过率 69.4% → 85%、异常拒答 6 条 → 0 条、响应 P95 42 秒 → 15 秒以内。没有基线这些都说不出来修好了也只是「感觉好多了」。自查信号你能说出这个系统三个月前的关键指标吗——回答率、准确率、响应时间、日均使用量说不出来你后来做的优化多半是盲改。三、自查出问题之后三条路中了三条以上的先别急着换方案、换供应商、加预算。先做一件事把病在哪一层弄清楚。先说一个反常识的判断诊断的价值不在于「能修」而在于「值不值得修」。我们见过的烂尾项目里相当一部分不该修——不是因为修不了是因为修好了也没价值。敢说「别救了」的人才有资格说「这个能救」。判定六问#问题关键信号1当初要解决的问题现在还存在、还值得解决吗问题消失 / 伪需求 → 直接放弃2资产还在吗数据、文档、代码、账号全丢 → 无从救起只能重建3病在哪一层需求层 / 技术层 / 运维层主因在需求层 → 修了也白修4修复成本 vs 重建成本修复超过重建的 60% → 重建更划算5有能拍板的人吗没有 → 修好还会再烂一次6你对「成功」的定义现实吗期望离谱要通用大模型干垂直精活→ 先校准再谈三种结论三种动作结论什么情况动作救需求真实、主因在技术层配置/数据/链路可修、资产可复用、有拍板人出修复方案逐项病灶、修复路径、工期、验收标准、预期效果重建需求真实但技术层烂到根架构错配 / 数据不可用 / 前任黑盒无文档或修复成本 ≥ 重建的 60%推倒重来但旧资产数据、文档、部分模块要列复用清单——重建不等于从零放弃问题已消失 / 无人拍板 / 预算时间窗不合理 / 期望无法校准书面理由 替代建议不用 AI或换一个更小的方案诊断结论六问判定救出修复方案逐项病灶 修复路径 验收标准 预期效果重建旧资产列复用清单按新项目重做放弃书面理由 替代建议几个典型信号对着客户原话看你听到的话倾向「当时想做个 XX现在团队都换人了 / 业务砍了」放弃「功能其实能用就是没人用 / 效果一般」救——运维层、调优层的病「数据都丢了 / 代码在跑路的乙方手里 / 没有文档」重建「每次问 AI 都答得乱七八糟」但语料是齐的救——检索和数据工程的问题这一层最好治「领导说要 AI 化我们也不知道要啥」放弃或先做需求咨询不是接盘三条边界很重要拿不准别急着拍板——升级为正式诊断用证据说话修复方案必须带防复发设计——如果主因在运维层没人维护、衰减无人管方案里必须包含持续维护机制如定期复检。否则半年后它会再烂一次而这一次依然不会被发现先算清楚再动手——修复成本和重建成本的对比要在开工前完成做到一半才发现「不如重建」的代价远比事前多花几天评估大。四、怎么查清AI 应用体检自查靠感觉定案靠证据。这一节讲清楚体检查什么、怎么查、报告长什么样、权限怎么给。4.1 为什么「自己看看」不够三个盲区只看得见界面——效果好不好、有没有拒答、检索命中了什么界面全都不显示。你看到的是整条链路的最后一环前面全在黑盒里没有基线——没有历史数据说不清现在算好还是差改完也说不清有没有变好无法取证——「用户说答得不准」「业务方觉得不好用」这类反馈落不到节点、落不到数据。而 AI 应用的问题只有追到链路层才能定案就像前文那条被拒问题的五层拆解。4.2 体检查什么三层采集 真实问题实测环境层备份 / 磁盘 / SSL / 端口 / 容器应用层用量 / 知识库内容健康 / 配置快照 / 查询记录Agent 层约束文件 / 能力可达性 / 记忆一致性真实问题实测L1-L440 条体检报告健康分 总检结论异常项详解问题 / 证据 / 影响 / 建议根因诊断链路级拆解层查什么典型发现环境层服务器资源、数据库备份、SSL、端口、容器状态数据不可恢复风险那次体检的头号问题就是「没有任何备份」应用层用量与活跃、知识库内容健康分段质量 / 破碎率 / 新鲜度 / 索引状态、应用配置快照、真实查询记录知识库碎块 24.3%、检索命中差、配置漂移、实际上没人用Agent 层AI 助手自身约束文件结构、能力可达性、记忆一致性记忆条目互相冲突、约束文件失效而不自知另外三类容易被忽略、但同样在检查范围成本token 消耗与趋势——AI 系统的「电费」、安全合规AI 内容标识、越权访问、提示注入防护、使用采纳上线之后到底有没有人在用、用了多少次。4.3 关键一步拿真实问题去问它体检不是「看看配置」是拿问题去实测。问题分四层出L1 存活与基础能力你好 / 你能做什么L2 库内真实问题手册里确实有的内容L3 多轮追问问到第三问它还记不记得上下文L4 边界与异常空白输入 / 越界问题 / 诱导40 多条问题跑下来每条记录四样东西响应状态、耗时、会话 ID、回答内容。然后逐条判定答对、部分答对、答错、被拒。被拒的要逐条追根因——是被系统故障拒的还是真的不该答。这一步是整份体检里最花时间、也最有价值的地方。前文那条「设备温度过高告警」被拒的问题就是从这里翻出来的如果只看统计数字它是 0 失败只有逐条追链路才能看到系统故障被包装成了业务拒绝。三个口径说明。第一本文引用的实测数据来自一次快照式体检——44 条问题集一次性实测加上近 20 小时的全量节点执行记录462 次。比例会随样本量和时间窗波动它的用途是定位问题不是长期统计结论。第二「失败」必须分类看接口层报错、系统故障拒答、业务拒答库里确实没有、安全拒答越界或注入被拦——把它们混在一起算成一个「失败率」是很多项目自评失真的根源。第三实测用真实问题调用真实应用会产生真实的会话记录与模型消耗计入你自己的账号——担心与业务数据混淆的可指定测试应用或测试环境来跑。4.4 报告长什么样报告的核心是三样东西第一健康分 一句话总结。比如那份报告「健康分 41/100D 档。回答质量本身扎实——库内 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 它和「独立验收」不是一回事这是最常被问到的问题一次说清独立验收应用体检时机上线前 / 交付时点上线后 / 运行中对象交付物应用本身运行中的系统应用 数据 环境 Agent输入材料如应用配置文件、用例真实环境访问 真实问题实测回答的问题这个应用能不能上线这个系统现在健不健康、病在哪一层产出验收报告缺陷清单 上线评估体检报告健康分 异常详解 根因 医嘱一句话上线前用验收把关上线后用体检巡诊。两者都不动手改——修是第三个环节。五、收口回到开头那个 41 分的项目。它现在还在跑。体检之后客户拿到的是七个异常、每个异常的根因、修复路径和优先级——以及一个基线。接下来是修、是重建、还是先放着是他的决定但至少这个决定建立在数据上而不是感觉上。七个征兆如果你中了三条以上我建议你先别动方案、别动预算——先花点时间把「病在哪一层」弄清楚。大多数 AI 项目的钱不是花错了地方是根本没搞清楚该花在哪。项目烂尾不是轰的一声是嘘的一声。它不会通知你。对照着上面七条你中了几条常见问题静态检查和运行态检查能发现的问题有什么不同静态检查看的是交付物应用结构、节点配置、链路完整性能在文件层面发现问题——缺验签、密钥硬编码、分支边漏接运行态检查看的是运行中的系统能发现数据层与环境层的问题——知识库分段质量、真实问答的命中与拒答、响应耗时分布、备份与资源风险。两者不重叠也不冲突一个回答「设计对不对」一个回答「跑得好不好」。一个常见现象是静态检查全绿、运行态一测就露馅——配置正确不等于效果正确。问题集该怎么出题才算有效按四层出L1 存活与基础能力你好、你能做什么L2 库内真实问题必须来自真实语料主题不能编造L3 多轮追问问到第三问看上下文还在不在L4 边界与异常空白输入、越界、提示注入。三个要点一是 L2 的题必须基于真实知识库内容测试点才有意义二是要包含历史踩坑的重现题曾经出过的问题回归看有没有复发三是判定要能落到节点——测完追不到根因的题等于没测。为什么「被拒」必须逐条追根因、分类统计因为「被拒」至少分四类接口层报错、系统故障节点异常走兜底、业务拒答库里确实没有、安全拒答越界或注入被拦。把它们混成一个「失败率」结论必然失真——我们遇到过的一次表面上像「知识库覆盖不足」逐条追下去发现主因是意图分类节点的输出漂移修检索根本治不好。没有基线第一次体检该怎么做第一次体检本身就是建立基线选一组稳定的问题集比如 40 条分层题、固定判定口径、把关键指标记下来通过率、异常数、响应分位、内容健康指标。下一次用同一组题、同一口径复跑前后对比才有意义。最忌讳每次换一套题——那样得不到趋势只能得到「今天看起来还行」。频率上知识和业务变化快的季度一次变化慢的至少半年一次另外大的改动上线后一定要补做一次——确认没改坏。健康分和传统测试的通过率有什么区别通过率只反映一个维度而且容易被稀释——95% 听起来不错但剩下的 5% 如果全是核心问题呢健康分按功能、异常处理、性能、安全、可靠性五类加权计算并且单项短板不倒挂某个维度分数再高也拉不回一个红灯项内容健康、使用采纳、环境风险单列、不计入总分。差别在于通过率回答「答对了多少」健康分回答「整体健不健康」而短板定位靠的是异常项详解和根因诊断。 这七个征兆你中了几条哪一条最难自查出来评论区聊聊。相关文章AI 系统上线三个月后开始悄悄退化——为什么 AI 项目不是一锤子买卖静默退化的成因本文的姊妹篇AI 应用交付靠不靠谱看它的用例质量——用例是长出来的不是写出来的上线前把关的起点AI 应用上线前怎么验一套可复用的验收方法论验收方法论完整版 更多实战记录见我的博客鱼日先生本文基于 Dify 1.17 Hermes Agent v0.21 实测。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实实测记录。