现在几乎所有可观测性产品都在讲 AI。
AI 告警总结。
AI 日志分析。
AI 根因定位。
AI 巡检报告。
AI 自动生成仪表盘。
AI 辅助配置告警。
这些方向都没错。
但我觉得很多讨论忽略了一个更底层的问题：AI 真正能不能帮上忙，不首先取决于模型有多强，而取决于它拿到的上下文是否足够好。
如果 AI 看到的只是几条告警文本、几段日志、几条指标曲线，它能做的事情非常有限。
它可以解释日志。
它可以总结告警。
它可以猜测一些可能原因。
它可以给出“建议查看数据库、网络、依赖服务”的通用建议。
但这离真正的故障根因分析还很远。
真正的根因分析，需要 AI 理解系统。
它要知道当前异常对象是什么，属于哪个业务，在哪个系统层级，有哪些上游和下游，健康指标是什么，异常发生在哪个时间段，应该查哪些日志，应该看哪些 Trace，最近有没有变更，历史上有没有类似故障。
这些东西，不是模型凭空知道的。
需要可观测性平台提前把它们组织好。
这就是我理解的 AI-Ready 可观测性。
AI 不缺推理，缺上下文
很多团队试 AI 根因分析，最开始都会很兴奋。
把一段日志丢进去，让 AI 分析。
把一条告警丢进去，让 AI 总结。
把一段 PromQL 结果丢进去，让 AI 解释趋势。
效果通常也不错。
至少比纯人工读日志快一点。
但到了真实生产事故，问题就出现了。
一条告警很少能代表完整故障。
一段日志通常只反映局部现象。
一条 Trace 只能说明一条请求路径。
一张大盘只展示某个维度的指标。
一个报错关键字可能有很多不同原因。
如果 AI 只拿到这些碎片，它很容易输出看起来合理、但没有针对性的结论。
比如：
“可能是下游服务延迟导致。”
“建议检查数据库连接池。”
“建议查看应用日志和 Trace。”
“可能存在网络抖动或资源瓶颈。”
这些话并不一定错。
但如果值班人已经在事故现场，这些建议帮助不大。因为人真正需要的是更具体的判断：
哪个下游服务？
哪个数据库实例？
哪类错误码？
哪个时间点开始？
和哪次发布有关？
影响哪些接口和业务？
下一步应该先处理谁？
AI 要回答这些问题，必须拿到系统上下文。
而大多数企业的上下文，是散的。
架构图在文档里。
服务归属在 CMDB 里。
指标在 Prometheus 里。
日志在 ES、Doris、SLS 或 CLS 里。
Trace 在 SkyWalking、Jaeger、ARMS 或 Flashcat APM 里。
告警在监控系统或 On-call 平台里。
变更记录在发布平台、Jira、Git 或群消息里。
历史经验在人的脑子里。
人可以靠经验把这些东西拼起来。
AI 不行。
至少不能稳定地凭空拼起来。
什么叫 AI-Ready 的可观测数据
AI-Ready 不是说把所有数据都喂给大模型。
那既不现实，也不可靠。
日志量太大。
指标太多。
Trace 太长。
事件太杂。
权限和安全也很难处理。
真正的 AI-Ready，是把数据整理成 AI 能理解、能调用、能推理的结构。
我认为至少需要四层上下文。
第一层是对象上下文。
AI 要知道当前分析的对象是什么。是接口、服务、数据库、缓存、消息队列、Pod、主机、网络链路，还是一个业务系统。
第二层是健康上下文。
AI 要知道这个对象为什么异常。是成功率下降、延迟升高、无数据、慢查询增多、消费堆积、实例不可用，还是多个指标同时异常。
第三层是关系上下文。
AI 要知道这个对象和其他对象的关系。它依赖谁，谁依赖它，它属于哪个业务，在哪个分层，是否有共同上游或共同下游。
第四层是数据路径上下文。
AI 要知道该去哪里查证据。查哪个日志源，用哪个字段过滤；查哪个 Trace，用哪个 service 和 operation；打开哪个仪表盘，带什么变量；看哪些事件和变更。
没有这四层上下文，AI 只能做泛泛分析。
有了这四层上下文，AI 才有机会做真正的故障分析。
灭火图为什么适合做 AI 上下文
Flashcat 的灭火图，本质上就是在整理这四层上下文。
它先把系统拆成观测对象。
接口、服务、组件、基础设施，都可以变成卡片。每张卡片代表一个具体对象，而不是一条孤立指标。
它再给每个对象定义健康状态。
卡片为什么飘红，背后有指标和异常条件。比如接口成功率低、响应时间高，数据库慢查询多，服务错误率升高，消息队列消费堆积。
它还把对象组织成层级结构。
功能接口层、微服务层、标准组件层、基础设施层。底层对象异常可以向上聚合，形成全局健康视图。
最后，它通过下钻规则把数据路径挂到对象上。
对象异常后，可以下钻到日志、Trace、仪表盘、其他卡片、事件和变更。
这意味着，灭火图不是给人看的一张状态图那么简单。
它实际上把系统知识结构化了。
AI 要分析一个异常卡片时，不需要从零猜测。它可以基于卡片上下文知道：
这是什么对象。
它为什么异常。
它在哪个分层。
它的上游和下游是谁。
应该查哪些指标。
应该查哪个日志入口。
应该用哪些标签查 Trace。
应该看哪些关联事件。
历史健康状态如何。
这才是 AI 根因分析需要的基础。
所以我说，灭火图是 Flashcat AI-Ready 的核心。
没有灭火图，AI 面对的是碎片数据。
有了灭火图，AI 面对的是一个被组织过的系统。
为什么“直接让 AI 查日志”不够
很多团队会从日志分析开始尝试 AI。
这很自然。
日志是最接近故障细节的数据，里面有错误信息、堆栈、请求参数、状态码、trace_id、用户 ID、实例名等线索。
但只让 AI 查日志，很容易遇到几个问题。
第一，范围太大。
如果不知道当前对象是什么，日志查询范围就很难收敛。一个生产日志库可能每分钟有大量日志，AI 不可能无差别读取。
第二，字段不统一。
不同应用的服务名字段、接口字段、错误码字段可能不一样。AI 如果不知道该用哪个字段，很容易查错。
第三，缺少健康状态。
日志告诉你发生了什么，但不一定告诉你这个问题是否影响业务。某些错误日志很多，但业务无影响；某些错误日志不多，却集中影响关键接口。
第四，缺少关联路径。
日志只能看到局部。要判断是不是下游依赖、数据库、缓存、网络、发布导致，还需要指标、Trace、事件一起看。
灭火图的价值，是先把“要查哪个对象”确定下来。
然后通过下钻规则告诉 AI：这个对象对应哪个日志源、用哪些标签过滤、时间范围是什么、还应该结合哪些其他数据。
这样 AI 查日志才有方向。
为什么“直接让 AI 看大盘”也不够
大盘同样有价值，但也不能直接等同于 AI-Ready。
一张大盘里可能有很多图。
CPU、内存、QPS、错误率、延迟、连接数、缓存命中率、数据库指标、队列指标都放在一起。
人看大盘时，靠经验判断哪些图重要。
AI 看大盘时，也需要知道这些图之间的语义。
这个图对应哪个对象？
这个指标是原因还是结果？
这个阈值是否合理？
这个对象的上游和下游是谁？
这个曲线异常是否影响核心业务？
如果缺少对象上下文，大盘只是图表集合。
如果大盘挂在灭火图卡片下，它的意义就清楚很多。
MySQL 卡片下钻到 MySQL 大盘，AI 就知道这些指标都围绕当前数据库实例。
服务卡片下钻到服务大盘，AI 就知道这些指标都围绕当前服务。
接口卡片下钻到接口质量大盘，AI 就知道这些指标和当前接口有关。
这时，大盘从“展示页面”变成了“对象证据”。
AI 才更容易判断。
FlashAI 真正做的不是聊天
很多人看到产品里的 AI 按钮，会自然理解成聊天窗口。
但对可观测性产品来说，聊天只是入口。
真正重要的是 AI 能不能基于当前页面、当前对象、当前时间、当前数据路径工作。
FlashAI 在 Flashcat 里的几个入口，正是围绕这个思路设计的。
在灭火图卡片飘红时，可以一键触发 AI 分析。AI 不需要用户手写 Prompt，就能读取卡片上下文和下钻数据。
在告警通知里，可以带上 AI 分析入口。收到告警后，不只是进入一个详情页，而是直接进入基于异常对象的分析流程。
在对话窗里，AI 会结合当前页面上下文，提供查询、分析、创建、操作、探索等常用任务。
在智能定时任务里，可以把自然语言指令配置成周期任务，让 AI 每天或每周自动巡检灭火图、生成 HTML 报告并发送邮件。
这些能力背后的关键，不是“有一个聊天机器人”。
而是 FlashAI 能访问 Flashcat 已经组织好的系统上下文。
这也是为什么灭火图重要。
如果没有对象、健康状态、下钻路径，AI 只能回答“你可以去哪里看”。
有了这些上下文，AI 才能开始执行“我已经帮你看了什么”。
知识库补的是业务语义
灭火图解决的是系统结构和数据路径。
但还有一类上下文，平台很难自动知道。
比如：
这个业务系统为什么重要？
某个接口对应哪个业务流程？
哪些指标在活动期间可以波动，哪些不能波动？
某个错误码是否可以忽略？
历史上类似问题是怎么处理的？
遇到某类故障应该先通知哪个团队？
报告输出应该按照什么格式？
这些属于业务语义和组织经验。
FlashAI 的知识库就是用来补这部分信息的。
知识库可以描述灭火图代表的业务含义、分层和卡片含义，也可以解释仪表盘指标、记录历史 case、沉淀故障处理 SOP，甚至约束 AI 输出格式。
这点非常关键。
因为 AI 根因分析不是只看技术信号。
同样是支付成功率下降，普通日常时段和大促活动时段，判断方式可能不同。
同样是某个接口错误率升高，如果它是非核心接口，优先级和核心交易接口不同。
同样是数据库慢查询，如果历史上有相同 SQL 的处理 SOP，AI 应该优先引用历史经验。
灭火图给 AI 系统结构。
知识库给 AI 业务语义。
两者结合，AI 分析才会更贴近真实生产环境。
AI-Ready 不是一次性建设
很多团队希望买一个 AI 功能，然后马上实现智能运维。
这个预期不现实。
AI-Ready 可观测性不是打开一个开关，而是一套逐步建设过程。
第一步，数据要接进来。
指标、日志、链路、事件至少要覆盖核心系统。没有数据，AI 只能空谈。
第二步，数据要有上下文。
服务名、实例、环境、集群、接口路径、trace_id、span_id、团队、业务线这些标签要尽量规范。否则数据之间很难串起来。
第三步，系统要对象化。
把接口、服务、组件、基础设施变成灭火图卡片。让平台知道“当前异常的是哪个对象”。
第四步，健康状态要定义清楚。
每类对象的核心健康指标是什么，什么情况下算异常，什么情况下算未知，阈值是否符合业务实际。
第五步，下钻路径要补齐。
每类对象异常后，应该看哪些日志、Trace、仪表盘、事件、上下游卡片。没有下钻，AI 没有稳定证据来源。
第六步，补业务知识。
用知识库沉淀系统说明、业务影响、历史 case、SOP、报告格式。
第七步，再让 AI 自动分析和巡检。
这时 AI 才不是在数据海里盲猜，而是在一套结构化上下文里工作。
这个顺序很重要。
如果前面没做，直接上 AI，很容易变成“能演示，但不敢信”。
AI-Ready 的价值不只在故障现场
很多人一提 AI 运维，就只想到故障根因分析。
其实 AI-Ready 的价值更广。
第一，日常巡检。
FlashAI 可以定期巡检灭火图，分析最近 24 小时或 7 天的异常卡片、异常时间分布、反复出现的问题和潜在风险。
第二，稳定性周报。
AI 可以基于灭火图健康状态、告警事件、SLO 达标情况生成报告，让管理者看到稳定性趋势，而不是只看零散告警。
第三，建设 review。
AI 可以检查哪些卡片缺少下钻规则，哪些分层缺少告警，哪些服务没有日志或 Trace，哪些核心对象还没有进入灭火图。
第四，平台操作。
FlashAI 不只是分析，还可以帮助创建卡片规则、下钻规则、告警规则、北极星指标、仪表盘、定时任务。
第五，知识答疑。
新同学可以问“这个空间的灭火图怎么建设”“某个卡片为什么飘红”“这个指标是什么意思”“应该如何配置告警”。
这些能力的共同前提，还是上下文。
AI 不只是要能回答问题，还要知道问题发生在哪个系统、哪个页面、哪个对象、哪个时间范围。
如何判断你的可观测性是否 AI-Ready
可以用几个问题自查。
第一，AI 能否知道当前异常对象是什么？
如果告警只是一段文本，AI 不知道它对应哪个接口、服务、组件或基础设施对象，那上下文还不够。
第二，AI 能否知道这个对象为什么异常？
是否有明确健康指标和异常条件，而不是只给它一堆曲线。
第三，AI 能否自动找到证据？
它是否知道该查哪个日志源、哪个 Trace、哪个仪表盘、哪些事件，还是只能建议人去查。
第四，AI 能否理解对象关系？
它是否知道上游、下游、依赖组件和影响范围。
第五，AI 能否利用业务知识？
它是否知道哪些接口核心、哪些错误可忽略、历史故障怎么处理、报告应该如何输出。
如果这些问题的答案都是否定的，那么当前系统还不是 AI-Ready。
这时，盲目追求更强模型，效果不会稳定。
更应该先补对象模型、标签规范、下钻路径和知识库。
不要把 AI 当成替代品
还有一点需要说清楚。
AI-Ready 可观测性，不是让 AI 替代 SRE、运维或研发。
在生产系统里，最终判断和处理仍然要由人负责。
AI 的价值是减少机械查询、整理上下文、发现关联线索、生成初步判断、输出巡检报告，让人更快进入正确问题。
它不是替代责任。
如果 AI 没有证据链，只输出一个结论，人也不应该信。
好的 AI 运维应该让结论可追溯。
为什么这么判断？
看了哪些指标？
查了哪些日志？
关联了哪些 Trace？
参考了哪些事件？
命中了哪些历史经验？
这些证据能展开，AI 才能进入生产流程。
灭火图和下钻路径，正好为这种证据链提供结构。
最后
可观测性进入 AI 时代以后，竞争点不会只是“谁接了哪个大模型”。
真正的竞争点是：谁能把系统上下文组织好，让 AI 有东西可看、有路径可走、有证据可引用。
模型很重要，但模型不是全部。
没有上下文，AI 只是一个能说会道的日志解释器。
有了上下文，AI 才有机会成为真正的 SRE 助手。
Flashcat 的灭火图，正是在做这件事。
它把系统拆成观测对象。
它给对象定义健康状态。
它把对象组织成层级结构。
它通过下钻把指标、日志、链路、仪表盘、事件串起来。
它通过知识库补充业务语义。
它让 FlashAI 可以围绕具体对象做分析、巡检和操作。
这就是可观测性的 AI-Ready 之路。
不是先问“AI 能不能替我定位根因”。
而是先问：我的系统有没有被组织成 AI 可以理解的样子？
如果答案是否定的，那第一步不是换模型。
第一步是建设灭火图。
