市面都在帮你做 AI，没人帮你查 AI 还灵不灵

📖 摘要：市面上的服务几乎都是「帮你做 AI」，很少有人做另一件事：查你已经上线的 AI 应用还灵不灵。这篇讲清 AI 应用体检本身——检什么（环境、应用、Agent 三层资产）、凭什么判定（一份可校准的参考范围，不是拍脑袋）、价值落在哪一层（从后台界面看不到的运行记录挖到链路根因：44 条问题集实测查出 6 条误拒，逐层定位到意图分类节点的 JSON 解析失败），以及一条容易被忽略的边界：诊断和修复是两件事。文末附体检频次与基线重建规则。这篇是「体检科」，同系列的下一篇讲「修复科」：拿到报告之后怎么逐项修到可验收。

一、上线三个月之后，谁在盯它

先说一个具体画面。

项目交付完、验收通过、应用上线，双方都松了一口气。三个月后你再去问一句「最近用得怎么样」，得到的回答通常是：「还行吧，没人反馈问题。」

这句话听起来像好消息，其实是这个领域最典型的盲区。

AI 应用的劣化是慢性的、隐形的。它不像服务器宕机那样有人打电话找你，也不像接口报错那样在日志里留下红色记录。它更像是：回答的准确率从 92% 掉到 88%；多轮对话偶尔丢一句上下文；知识库里那份三个月前就改版的手册还在被引用。用户用着别扭，但不会正式提出来——「感觉不太准」，然后慢慢不用了。

所以先把判断摆在这儿：AI 应用最常见的故障形态不是崩，是悄悄变差。 崩了有人修，变差了没人知道。

再往下看一层，会发现这不是技术问题，是编制问题：企业内部通常没有「盯着 AI 应用」这个岗位。IT 部门管的是系统基础设施，不管 AI 怎么用起来；业务部门有感受，但没有排查手段；真要招一个能看懂的，贵、难留，而且可能一年用两回。

这件事需要被外化成一个固定动作：定期给它做一次体检。

二、为什么「看不出来」是结构性的

很多人第一反应是：我经常用，有问题我能感觉到。这个自信值得拆一下——「看不出来」不是马虎，是结构决定的，至少有四个原因。

第一，它不报错。 这是 AI 应用和传统软件最根本的差别。传统系统挂了会抛异常、会告警；而 AI 应用最典型的缺陷——检索没召回（知识库里明明有，回答却是「未找到」）、多轮丢上下文、降级链断裂、敏感信息没脱敏——流程照常成功、状态照常显示「已完成」。黑盒点几下，永远发现不了。

第二，它没有对照组。 「变差」是一个相对结论，没有基线就得不出来。没有历史数据，你只能说「今天这个回答不太好」，说不出「比上个月掉了 4 个点」。而后者才是能驱动决策的信息。

第三，后台界面不告诉你真相。 平台后台通常会展示消息数、访问量这类表层指标，但它展示的是「流量」，不是「健康」。真正的问题藏在运行记录和节点执行状态里。

第四，使用量和使用效果是两件事。 用得少不等于没问题（可能是不好用），用得多也不等于效果好（可能一直在被人绕开）。这两个指标必须分开看。

这四条加起来，就是「体检」这件事存在的理由：它不是把后台数据再看一遍，它是换一套证据去回答一个后台答不了的问题。

三、体检检什么：三层资产，不是只看回答对不对

一提体检，很多人以为就是「问几个问题看它答得对不对」。那只是其中一层。我们实际检的是三层资产，因为 AI 应用的健康状况由三层共同决定。

环境层——服务器运行环境。 磁盘与内存水位、容器健康与重启记录、服务探活、SSL 有效期、公网暴露面，以及备份。这一层最容易被忽略的是备份核查：见过不止一个「配置了备份任务但实际早就失败」的情况，而它平时完全没有存在感。环境层是基础条件，不进健康总分，但它的严重问题优先级高于总分——服务器上什么都没有，谈应用健康没有意义。

应用层——应用本身与知识库。 这是主体，覆盖六个维度：

这六个维度不是随便凑的。最容易漏的是「异常」和「压力」——因为主流程测通了很容易觉得「差不多了」，而这两类问题恰恰只在坏输入和高并发时才现形。

每一项检查里都有更细的指标。以功能维度为例，它拆成四条：问题集通过率、拒答合理性（库外问题是否诚实拒答而不是编）、误拒答率（该答的有没有被拦）、主链路完整。其中「误拒答」是最容易被忽略的一条——因为从系统视角看，用户只是得到了一句「这个问题我不太确定」，流程是成功的。

Agent 层——如果应用背后挂了 Agent，它本身也是一份要体检的资产。 这一层是多数人没想到的。检查项大致是七类：

约束结构（是结构化写法还是散文式铁律堆砌）｜层级完整（身份、能力、记忆、执行链是否齐全）｜冲突与越界（规则之间有没有互斥、有没有管到自己职责之外）｜上下文预算（约束文件占多少上下文、会不会挤压任务空间）｜技能框架（每个技能的描述能否自解释触发条件）｜引用可达（技能与资源有没有断链）｜记忆健康（有没有过期、互相矛盾的条目）。

Agent 不会报错说「我的约束自相矛盾了」，它只会做出让人看不懂的决定。所以这几项只能靠人对着文件走查。

四、凭什么算「有问题」：参考范围，不是感觉

体检最容易走偏的地方，是判定。

医院体检之所以可信，是因为检验单上有「正常值范围」——白细胞 4 到 10，高了低了都有明确含义。AI 应用体检要立住，也得有这东西：每一项检查都要有参考范围和判定口径，而不是「我看着还行」。

判定的标记用三档：正常、关注、异常。下面是几个指标的参考范围示例，这些值是工程判断加样板实测校准出来的，不是行业标准，用之前要按自己的业务重定：

为什么这几个指标值得盯？因为它们分别代表四种不同的失效方式：答不对（通过率）、该答不答（误拒答）、慢到用户以为坏了（P95）、以及「平时看不出、出事要命」（备份）。

健康分怎么来的，也要说清楚，否则它就是一个玄学数字。 规则是三条：

总分 100，等于六个维度的权重乘以各自的得分率，再相加。每个子指标按判定给分——正常 100、关注 55、异常 15，不适用的剔除不计。

关键在第二条：一个维度的得分率，取的是这个维度里最差的那一项，不是平均。 为什么？因为一个异常项代表真问题，不该被一堆正常项稀释掉——这跟医院「一项指标异常就要解读」是一个道理。

最后按总分分档：90 以上健康，75 到 89 良好，60 到 74 带病运行，60 以下需要干预。

还有两个容易搞混的地方，一次说清：

判定档和严重度不是一套词。 判定档是「正常 / 关注 / 异常」（指标层面的状态），报告里的严重度是「高 / 中 / 低」（问题的处置优先级）。对应关系是：判定异常 → 高优先级，判定关注 → 中优先级，观察区的小问题 → 低优先级。之所以在报告里换成另一套词，是因为决策者要看的是「先动哪个」，不是「这个指标叫什么」。

报告形态：主报告出结论，附件放证据。 主报告是给决策者的——健康分、全部检查项的判定汇总、每个异常项的证据与影响、下一步建议；附件是给要复核的人看的——采集明细、问题集实测记录、专项报告、基线快照。像医院一样，医生给结论，检验单你自己翻。

五、价值真正落在哪一层：从表面现象挖到链路根因

上面讲的都是设计。这一节说实际挖出来过什么——这也是一份体检报告和一次后台浏览之间，真正的差别。

案例一：44 条问题集，6 条「该答没答」。

某企业交换机故障诊断助手做首次体检时，问题集实测 44 条，其中 6 条明确属于知识库内容范围的问题被拒答了——用户问「设备温度过高告警怎么处理」「S12500 的板卡型号」，手册里明明有，系统回答「您的问题似乎不在故障诊断或配置查询范围内」。功能项有效统计 31 条，通过率 69.4%。

这 6 条不是靠客户投诉发现的，是靠固定问题集跑出来的。而找到「为什么被拒」，靠的是链路级逐层取证——把那次运行里每个节点的实际输入输出都拉出来看：

定位到第三层，问题才露出来：分类节点的模型输出是概率性的，偶尔会不按约定格式输出结构化结果，解析失败就走了兜底分支。而兜底分支和「真的不属于业务范围」共用同一句话术——于是一次系统内部故障，被说成了「你没资格问」。

顺手还发现了第三层原因：剩下那 1 条被拒的（问「IS-IS 邻居建立过程是怎样的」）不是异常，是分类器把「原理、过程、是什么」这类问法归到了「其他」——它的分类提示词只覆盖了「故障现象、配置命令」这两类问法。

这就是链路级取证的价值：同一句「不在范围内」的回复，背后可能是三种完全不同的原因（系统异常、分类误判、内容确实没有），修法也完全不同。 只看最终回答，这三种情况长得一模一样。

案例二：24.3% 的知识库残片。

同一个应用的知识库，1401 个段落里有 341 段是结构残缺的——代码围栏被从中间切开、表格跨段断裂，占 24.3%。这些残片不会在界面上显示任何异常，但它们被检索命中之后，模型拿到的就是半截内容：要么答一半，要么干脆说「未找到」。

这类问题的隐蔽性在于：它不降低系统可用性，只降低答案质量。 后台看一切都好，用户那边是「这个 AI 好像不太行」。

案例三：42 秒的 P95。

还是这个应用：44 条实测的耗时分布是 3.5 秒到 42.6 秒，P95 达到 42 秒，正常回答大多在 20 到 40 秒之间。这个数字不报错、不告警，但它决定了另一件事——演示场景和真实使用场景都会流失，因为用户会以为系统卡死了。

有意思的是，这个应用的回答质量其实不错：库内问题直接答对 18 条，拒绝场景诚实得体（问其他厂商设备时明确拒答并给出本厂商的替代引导），安全规则实测有效（提示词泄露注入、越权索取数据都被拦住）。「质量不错」和「体验不合格」在同一个系统上同时成立——这正是体检要分层看的原因。

顺带说一个口径问题，来自另一次体检（我们自己的演示站，不是上面这个应用）：同一段时间里，会话消息 234 条，工作流运行 881 次。两个数字差了近三倍，因为不同应用类型产生的记录落在不同的表里——对话类应用留下消息，工作流类应用的主体在运行记录里。只看消息数会得出「几乎没人在用」的结论，两个口径都采才知道真实使用量。 这两个数字单位不同，不能直接相除比较，但都不能漏看。

六、多久做一次，什么时候必须加做

体检不是一次性动作，它是循环。频次建议是这样定的：

常规节奏：季度做一次全面体检（问题集核心集 20 到 30 条），中间两个月各做一次快检（5 到 10 条关键指标）。季度全量保覆盖，月度快检保灵敏度——退化是渐进的，间隔越长发现越晚。

首次体检要建基线，把当时所有指标值、知识库指纹（文档数、段数、索引状态）、应用版本固定下来。之后的每一次复检，都是跟这份基线对比。保留最近四次快照，就能覆盖一年的趋势。

基线要在这些时刻重建：应用配置改过、知识库全量更新过、约束文件改过、模型或平台版本升级过。基线重建不是走过场——指纹变了，旧结论就不再可比，拿旧基线去比新状态，得出的「变好/变差」全是噪声。

还有一条经验性的建议：刚上线后的两到四周，值得做一次早期体检。 那个时间点业务反馈还没积累起来，但真实使用已经开始，能更早发现「设计时没想到、一用就现形」的问题，比等到三个月后再看要好。

七、边界

最后说清几条边界，因为它们决定体检结论可不可信。

诊断和修复是两件事。 体检只负责说清楚：什么状况、什么原因、影响多大、建议怎么处理。至于修不修、怎么修、修到什么程度算好，那是另一个动作——它有自己的一套流程（改前快照、逐项修改、单项验收、整体复检）。把两件事分开的好处很直接：出报告的人的动机是「把话说准」，而不是「让问题看起来很多」。 一份永远在报问题的报告，和一份永远在说没问题的报告，信息量是一样的。

再说一遍这组关系：体检、修复、验收，像一家医院里的三个位置——体检科出指标和诊断，修复按单处理，验收是交付时点上的独立把关。分开不是因为流程好看，而是它们各自要守的标准不一样：体检守的是「说得准」，修复守的是「修到位」，验收守的是「敢上线」。

安全是轻查，不是渗透。 体检会看配置层（系统提示里有没有明文密钥、对外页面有没有 AI 生成标识、知识库里有没有明显敏感字段），也会用若干注入样例验证约束有没有被绕过。但它不做渗透攻击、不做深度合规审查——那是专项。

结论只对这个时点的快照有效。 报告出具时的应用配置、提示词、知识库内容，都是结论的前提。任何一项变了，以新的体检为准。

压力维度可能没测。 压测要单独安排，运营体检默认不做。没测就明确写「未覆盖」——不能用「其他项都好」代替「这项没测」。

还有一个技术上的硬前提：体检要能看到运行环境和运行记录，否则只能做静态检查（看配置、看结构），症状背后的原因就查不下去。前面那三个案例，全都建立在「能看到运行记录和节点执行状态」这个前提上。

常见问题

AI 应用体检和上线前的验收有什么区别？

时点不同，答案不同。验收发生在交付节点：回答的是「这个应用现在能不能交付、能不能上线」，结论是三态（通过 / 有条件通过 / 不通过），锚定的是交付时的版本。体检发生在运行期：回答的是「已经在用的应用，现在还灵不灵、哪里在变差」，它是重复动作。两者共用同一套测试框架与判定口径（同一套六属性、同一套问题集思路），都靠节点级证据——只是一个是一次性闸门，一个是周期性复查。

问题集该怎么出题，出多少条？

出题的原则是「按缺陷形态反推」，不是按功能点罗列。必须覆盖四类：库内标准问法、库内但表达冷门的问法（这一类专门抓意图路由的误拦）、库外问题（检验它会不会编答案）、边界输入（空白、超长、乱码）。条数按用途分档：快检 5 到 10 条，常规体检 20 到 30 条，首次体检要建基线则更多（上面案例里那次是 44 条）。核心题固定下来保证可比性，另外备一批轮换题——全用固定的，优化容易只针对这批题过拟合。

健康分是怎么算的，为什么不能只看通过率？

通过率只反映功能这一个维度，健康分是六个维度加权后的综合结论——每个维度取该维度里最差的那项指标分，再加权求和。为什么不能只看通过率？一个答得又准又慢又贵、遇到坏输入就崩、知识库半年没更新的应用，通过率可能很好看，但它离健康很远（上面案例里的应用就是这样：答对率 69.4%，而响应 P95 达到 42 秒）。反过来说，健康分也必须能拆回维度——报告里每个维度都要有判定，不能用一句综合结论盖过去。

相关文章：体检报告出来之后，怎么把问题一项一项修好：修复的门禁与复检（同系列下一篇：拿到报告之后怎么修）｜AI 应用上线三个月后，开始悄悄退化：为什么 AI 项目不是一锤子买卖（退化的三个原因与维护的两层）｜AI 应用交付靠不靠谱，看它的用例质量：用例是长出来的，不是写出来的（体检与验收共用的那套用例标准）

本文基于真实交付与运维项目记录撰写（2026-09），体检流程、参考范围与判定口径在实际项目中应用并验证。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。