AI 排查生产问题：从单次帮忙到系统沉淀

前面讲了 AI 怎么从一个 bug 顺着链路挖出 5 个关联 bug。这篇把视角拉远——看 AI 排查的完整链路：它能做什么、经验怎么沉淀、踩过哪些坑。

三个真实案例，一个案例库的诞生，四个典型的坑。

一、三个案例，三种角色

案例一：数据缺失——AI 当配置审计员

现象：某产线检测页面，约一半的对象缺少温度数据。

让 AI 查后端日志，发现关键报错：批量读取传感器数据时，会话被设备主动断开。进一步让 AI 查读取配置——代码一次读取 100 个数据点，但该设备处理能力较弱，扛不住批量请求。

根因：批量读取的点位数超出设备承载能力。改为 30 个后恢复正常。

AI 做了什么：从日志报错出发，定位到读取配置不合理。人工也能做，但 AI 能在几秒内从海量日志中筛选出关键错误，再关联到配置代码。

案例二：数据显示为零——AI 当时序分析师

现象：首页多个产线的流量数据全部显示为 0。

让 AI 批量查询多个产线的数据，发现只有某条产线的流量为 0，而且数据在变化——第一次查有值，第二次查变成 0。让 AI 对比两个参数的入库时间：流量参数比主参数晚 46~56 秒才写入数据库。但实际生产流程是先采集流量、后采集主参数——入库顺序和采集顺序反了。

根因：不同参数的入库延迟不同，导致页面查询时流量数据还没入库。

AI 做了什么：跨多张表关联查询，同时对比多个时间线，发现入库顺序异常。人工写 SQL 也能做，但 AI 更快。

案例三：温度显示异常——AI 当逻辑对比器

现象：某对象的温度显示为 1546，正常应该是 154.6——四位数，明显异常。

让 AI 对比两个代码文件：质量判定代码对温度做了 ÷10 处理，页面展示代码没有。再查数据库确认：传感器原始数据单位是 0.1℃，存储时未转换。

根因：同一份数据在"判定"和"展示"两个环节被不同地解读。

AI 做了什么：并排读两个代码文件，逐行对比温度处理逻辑，精确指出差异在哪一行。人工翻两个几百行的文件容易遗漏，AI 秒级完成。

三个案例的共同点

AI 不是单独做了某一件事，而是把查数据、读代码、串逻辑三件事同时做了。人工排查时这三步是分开的，AI 把它们合成了一个连续的动作。

但这三个案例都是单次排查——下次遇到类似问题，又得从头教 AI。能不能把经验沉淀下来？

二、把经验沉淀成案例库

第一步：固定格式

把历史排查经验按 8D 报告格式整理：

• 现象：发生了什么
• 短期措施：先怎么止血
• 根因分析：5Why 追到底
• 长期措施：怎么彻底解决
• 预防措施：怎么防止再发生

关键是固定格式。散落在各处的经验，只有写成统一格式，AI 才能检索和匹配。

第二步：加权匹配

有了案例库，AI 根据用户描述的问题自动匹配最相似的历史案例。匹配不是关键词搜索，而是按维度加权：

比如用户说"某产线温度异常，昨天下午开始的"，AI 匹配到一条历史案例："温度异常，根因是传感器校准偏移"，置信度 85%。

第三步：实时验证

光匹配历史案例不够——案例的根因不一定适用于当前问题。匹配到案例后，AI 不会直接下结论，而是先查该设备最近一小时的实时数据，和案例中描述的异常模式对比。比如案例库中有一条"温度异常→传感器校准偏移"的记录，AI 匹配到后，查该设备的温度趋势——如果趋势一致，确认根因；如果趋势不一致，排除该案例，提示其他可能。

• 实际数据和案例根因一致 → 确认根因，高置信度
• 实际数据和案例根因不符 → 排除该案例，提示其他可能
• 数据有异常但无匹配案例 → 基于数据模式提出新假设

案例库提供方向，实时数据验证结论。 两者配合，比单独用任何一个都准确。

案例库初期可以从小规模开始——每次排查完顺手把 8D 格式填完，一天 5 分钟。重点是"开始做"，不是"做完美"。

三、四个典型的坑

用 AI 排查不是一帆风顺的。挑四个有代表性的。

坑一：API 响应格式被包装

让 AI 写脚本调 API 获取设备数据，脚本直接遍历返回值，报错：'str' object has no attribute 'get'。

所有 API 的响应都是包装格式 {"code": 0, "msg": "success", "data": {...}}，不是直接返回数组。AI 不知道这个包装层，直接对整个响应做遍历。

教训：AI 不了解你的 API 约定。第一次调用时要告诉它响应结构，或者给一个示例返回值。

坑二：前导零导致匹配失败

用户输入"水2"，API 返回的名称是"水02"——带前导零。AI 写的匹配逻辑直接用 == 比较，结果为空。

教训：任何和 API 返回值做名称匹配的场景，都要考虑前导零兼容。

坑三：温度值单位不一致

查询温度数据，某产线返回 9~11℃，明显偏低。不同产线的传感器原始数据单位不同——有的就是实际温度，有的需要 ÷10。AI 默认假设"同类数据同一种处理方式"，这个假设在工业场景里经常不成立。

教训：同一类数据在不同产线/设备上的处理逻辑可能不同。

坑四：字段名差一个字母

让 AI 读取设备的设置温度，返回值全部为空。API 字段名是 settingTemp，AI 代码里写的是 setTemp——差了三个字母。没有任何报错，只是静默返回 null。

教训：字段名错误不会报错，只会返回空值。看到"数据全部为空"，第一反应应该是检查字段名。

四个坑的共同特征

都是 AI 不知道的"隐性规则"——API 有包装层、名称有前导零、单位不统一、字段名有细微差异。这些规则没有写在任何文档里，只有踩过才知道。

这四个坑现在已经写进了知识库。下次 AI 遇到类似场景——比如调用带前导零的名称——它会先做前导零兼容，而不是直接比字符串。踩过的坑变成规则，这就是从"单次帮忙"到"系统沉淀"的意义。

写这篇文章的时候，正好测试发现一个问题丢给AI帮我分析。AI 的排查过程：

写在最后

从单次排查到系统沉淀，三步递进：

1. AI 帮你查：单次排查中，AI 同时做查数据、读代码、串逻辑三件事
2. 你教 AI 查：把排查经验按固定格式整理成案例库，AI 自己检索匹配
3. 踩过的坑变成规则：隐性规则写进知识库，AI 下次不再犯

AI 排查的价值，不只是帮你找到一个 bug，而是帮你把找 bug 的经验变成系统——踩过的坑写进知识库，下次遇到类似场景，AI 就不会再掉进去。