很多 AI 根因分析看起来很聪明，但到了真实故障现场，结论经常不够用。它能解释一段日志，能总结一条告警，也能根据几条指标曲线猜一个方向。问题是，这些能力只是“理解数据片段”，还不是故障定位。故障定位要回答的是更具体的问题：哪个对象异常，异常从什么时候开始，影响了哪些上游业务，下面关联哪些指标、日志和 Trace，有没有共同下游、共同实例或共同变更，下一步应该先处理谁。
AI 要稳定回答这些问题，不能只靠模型本身。它需要一个入口，一个能把异常对象、健康状态、下钻证据和系统关系组织起来的入口。在 Flashcat 里，这个入口就是灭火图。灭火图把接口、服务、组件、基础设施这些观测对象组织起来，用健康状态表达异常，用下钻规则关联指标、日志、链路、仪表盘、事件和其他卡片。FlashAI 从灭火图发起分析时，不是凭空问模型“你觉得哪里坏了”，而是沿着卡片、健康度、下钻数据和系统关系去查证据。
这才是 AI 在可观测性场景里真正能落地的地方。
从异常卡片开始，而不是从一段 Prompt 开始
很多团队第一次用 AI 排障，会从 Prompt 开始：把告警文本复制进去，把错误日志贴进去，把 PromQL 查询结果贴进去，再问一句“请分析根因”。这当然可以作为辅助判断，但它有一个根本问题：上下文是人临时拼出来的。人贴了什么，AI 就看什么；少贴了发布事件，AI 不知道刚刚变更过；少贴了下游依赖，AI 不知道慢调用集中在哪里；日志没有带时间窗口，AI 也不知道这些错误和当前事故是否相关。
这类分析最容易生成一种看起来合理、但无法直接行动的结论。比如“建议检查数据库、网络和下游依赖”，这句话没错，但对值班人几乎没有帮助，因为它没有告诉你先看哪个对象、用哪个时间窗口、查哪类证据、证据之间能否互相支持。
FlashAI 从灭火图卡片发起分析时，起点不一样。当一张卡片飘红，卡片本身已经说明了几个关键信息：它代表哪个观测对象，属于哪个空间、哪一层、哪类系统，为什么异常，是成功率下降、延迟升高、慢查询增多、无数据，还是实例不可用；它也知道异常发生在什么时间窗口，可以下钻到哪些数据源。这意味着 AI 不需要从空白上下文开始猜，而是可以先围绕异常对象提问：这张卡片为什么红，它的证据在哪里，相邻对象是否也红，下钻数据是否支持某个根因判断。
读取相关证据，而不是读取所有数据
AI 排障还有一个常见误区：以为把数据喂得越多越好。把最近 24 小时日志、服务所有指标、几十条 Trace、几百条告警都丢进去，看起来很充分，工程上却不可控，分析上也未必更准。日志太多会稀释关键错误，指标太多会让相关性变得模糊，Trace 太多会混入大量正常请求，事件太多会把真正相关的变更淹没。
更合理的方式，是让 FlashAI 通过灭火图和下钻规则读取相关证据。比如一张 payment-service 卡片飘红，FlashAI 不需要先扫完整个平台的数据，而应该围绕这张卡片读取健康指标、时间窗口、日志证据、链路证据、关联对象和事件变更。健康指标告诉它异常形态，是错误率升高、P99 延迟升高、请求量突增、实例数下降，还是依赖调用失败；时间窗口让指标、日志、Trace 和事件能放在同一个现场里看；日志提供错误类型、关键字段和异常模式；Trace 告诉它慢在哪里、错在哪里、传播路径是什么；关联对象帮助它判断这是孤立故障还是传播链；事件墙则把发布、配置变更、扩容缩容、Kubernetes 事件和告警事件拉进同一条时间线。
这里的关键不是“数据越多越好”，而是相关、对齐、可解释。相关，意味着数据围绕异常对象和相邻对象展开；对齐，意味着所有证据使用同一个时间窗口；可解释，意味着每个判断都能追溯到指标、日志、Trace、事件或对象状态，而不是只给出一句模型推断。
下钻规则决定 AI 能不能查到证据
FlashAI 能不能从灭火图拿到有用证据，很大程度取决于下钻规则是否建设好。这也是很多 AI 排障项目容易失败的地方：大家先关注模型，后关注数据路径。但在可观测性平台里，数据路径往往比模型更重要。模型再强，如果只能看到一张“服务异常”的卡片，也只能给出泛泛建议；下钻规则完整时，它才能从异常卡片自动读取指标、日志、链路等数据，形成证据链。
一张服务卡片要想让 AI 查日志，卡片标签需要能映射到日志字段。比如卡片上有 service=payment-service，日志里也要有对应的 service 或 service_name 字段。一张接口卡片要想让 AI 查 Trace，卡片需要提供 service、operation、接口路径、方法等上下文。否则 AI 只能打开链路系统，却不知道该查哪类请求。一张 MySQL 卡片要想让 AI 分析慢查询，卡片要能关联实例地址、集群、库名或慢日志数据源。基础设施卡片要想关联容器、主机和应用，标签里也要有集群、命名空间、Pod、实例、主机等关键维度。
这听起来像配置细节，但它决定了 AI 分析的上限。建设 FlashAI 根因分析，第一步不是写 Prompt，而是检查灭火图下钻路径。每类对象至少要问清楚：飘红后应该先看哪几个指标，日志应该查哪个数据源和哪些字段，Trace 应该按什么 service、operation 或接口路径查询，仪表盘是否能带变量跳转，是否能跳到上游、下游或关联组件卡片，异常时间窗口能不能在下钻过程中继承。把这些问题回答清楚，AI 才能真正沿路径分析。
一个支付接口异常的分析路径
假设某电商系统的支付接口卡片在 14:03 飘红。健康指标显示，请求量正常，但成功率从 99.8% 降到 91%，P99 响应时间从 300ms 升到 6s。值班人点击卡片上的 AI 分析按钮，FlashAI 可以先确认异常形态：这不是无流量，也不是接口完全不可用，而是成功率下降叠加延迟升高。这个形态通常指向下游依赖、资源瓶颈或外部服务超时，而不是入口流量消失。
接下来，FlashAI 通过下钻规则，使用卡片上的接口路径、服务名和时间窗口查询网关或应用日志，发现 5xx 错误集中在支付确认接口，错误信息主要是 timeout waiting for connection。它再按 service 和 operation 查询异常时间段的慢 Trace，发现耗时最长的 span 集中在 payment-service -> mysql-payment 调用，数据库查询阶段占用了大部分时间。继续沿对象关系下钻，它从支付接口卡片跳到支付服务卡片，再跳到 MySQL 支付库卡片，发现 MySQL 卡片也在同一时间窗口飘红，活跃连接数接近上限，慢查询数显著增加。
最后，FlashAI 对照 14:03 前后的事件墙，发现 13:55 刚发布过 payment-service 新版本。结合日志、Trace 和数据库指标，它可以进一步提示：这次事故更像是新版本引入低效 SQL，导致数据库慢查询增加，连接池等待变长，最终影响支付接口成功率。这个结论不替代人的最终确认，但它把值班人的工作从“到处找数据”压缩成“验证一条证据链”。这就是 AI 在故障现场的价值。它不应该只会聊天，它应该帮人把指标、日志、Trace、事件和系统关系快速组织起来。
AI 分析结果应该长什么样
一个有用的 FlashAI 根因分析结果，不应该只有一段自然语言总结。它至少要包含四部分：异常对象、证据链、可能根因和处理建议。异常对象要列出哪些卡片异常，属于哪个分层，异常持续多久，影响范围是什么。证据链要说明每个判断来自哪里，比如某个指标升高、某类错误日志增加、某段 Trace 耗时异常、某个组件卡片同步飘红、某个发布事件和异常时间重叠。
可能根因要有置信度和边界。好的表达不是“数据库异常”，而是“更可能是 MySQL 慢查询导致连接池等待，证据是支付接口 P99 上升、应用日志集中出现连接等待超时、慢 Trace 耗时集中在 mysql-payment 调用、MySQL 卡片同窗口飘红”。如果证据不足，也应该明确提示还缺什么数据。处理建议也要可执行，比如先回滚某次发布、临时扩容连接池、检查慢查询 SQL、切换故障实例、屏蔽抖动告警、补充某类下钻规则，而不是简单说“建议进一步排查”。
这也是区分“AI 总结”和“AI 辅助排障”的关键。总结只需要把看到的内容说顺，排障需要把证据组织成行动顺序。
前置建设决定 FlashAI 的效果上限
FlashAI 不是魔法，它依赖前置建设质量。如果灭火图对象划分混乱，AI 很难判断影响范围；如果卡片健康规则太粗，AI 只知道“异常”，不知道异常形态；如果日志没有结构化字段，AI 很难做维度聚合；如果日志里没有 TraceID，日志和链路之间就断了；如果 Trace 只覆盖少数服务，AI 很难还原完整调用路径；如果事件墙没有接入发布和配置变更，AI 会漏掉很多真实根因；如果知识库没有补充业务背景，AI 也很难理解“支付成功率下降”和“某个内部接口失败”之间的业务优先级。
所以，想让 FlashAI 根因分析稳定发挥作用，建议先做几件朴素但关键的事：把核心业务系统的灭火图建起来，至少覆盖接口、服务、关键组件和基础设施；为每类对象补齐下钻规则，让卡片能下钻到日志、Trace、仪表盘和关联卡片；治理日志字段和 TraceID，把请求上下文打通；把发布、配置变更、Kubernetes 事件和告警事件接入事件墙；最后，把系统架构、依赖关系、核心业务指标、常见故障处理经验补进知识库。
这些工作不是为了“喂 AI”。它们本来就是现代可观测性平台应该做的基础建设，AI 只是把这些基础建设的价值放大了。
从“问 AI”到“让 AI 沿路径工作”
可观测性里的 AI，不应该停留在问答层。真正有价值的方式，是让 AI 沿着产品里已经沉淀好的排障路径工作：灭火图提供对象入口，健康状态告诉 AI 哪里异常，下钻规则告诉 AI 去哪里查证据，日志和 Trace 提供细节，事件墙补上时间线，知识库补充业务背景。这些东西组合起来，FlashAI 才能从“解释一段数据”变成“辅助定位一次故障”。
如果你正在评估 AI 根因分析，不要只看模型回答是否流畅。更应该看三件事：它能不能从异常对象自动找到相关数据，而不是要求人手工复制粘贴；它能不能把指标、日志、链路、事件放到同一个时间窗口里分析；它能不能输出带证据链和处理顺序的结论。能做到这些，AI 才真正进入了排障流程。否则，它只是一个看起来很聪明的旁观者。
验证 FlashAI 在自己系统里的效果，也不需要从一个宏大的 AI 项目开始。选一个核心业务链路，建设一张覆盖接口、服务、组件和基础设施的灭火图，补齐日志和 Trace 下钻规则，再用一次真实历史故障或压测异常来跑 AI 分析，看它能不能从一张飘红卡片出发，把证据链串起来。这比泛泛地问“AI 根因分析准不准”更有意义，因为真正的问题不是 AI 会不会回答，而是你的可观测性平台有没有给 AI 一条可以走的路。
