不少运维团队已经在用大模型：不会写 PromQL 时问一下，遇到陌生报错时贴进去解释一下，复盘结束后再让它帮忙整理文档。看起来效率提高了，但真正进入故障现场，值班人员还是要在监控、日志、工单和聊天窗口之间来回切换。
问题不在模型够不够聪明，而在于它不认识眼前这套系统。你必须先告诉它告警内容、规则定义、数据源、机器标签和历史趋势；信息少了，答案容易泛化，信息多了，整理上下文本身又成了一项工作。
夜莺 v9 做 Nightingale AI，真正想改变的是这一点：AI 不再站在监控系统外面等人喂材料，而是进入告警、查询、配置和排障流程，在当前用户权限范围内使用夜莺已经掌握的上下文。
从“帮我解释这段文字”到“帮我看这条告警”
通用聊天工具看到的是用户粘贴的一段告警消息。夜莺里的 AI 可以围绕当前事件继续读取相关规则、机器、数据源和历史告警，再结合指标查询形成证据。
这两种工作方式的差别很大。前者擅长解释概念，后者更接近值班现场：规则里的 PromQL 在查什么，阈值和持续时间如何设置，同一业务组是否还有其他异常，主机近期 CPU、内存或网络趋势有没有变化。AI 可以把这些材料组织成事件解读和下一步检查建议，但最终判断仍由人完成。
对值班人员来说，最直接的收益不是答案写得更漂亮，而是少做一轮信息收集。对新人来说，当前事件与规则被放在一起解释，也比只看到一条压缩后的通知消息更容易理解。
一句话建规则，价值不只是少点几次鼠标
夜莺 AI 也能处理配置类工作。用户可以用自然语言描述业务组、指标、阈值、持续时间和通知需求，AI 生成 PromQL，并创建告警规则、屏蔽规则、订阅规则、通知规则或仪表盘。必要信息不足时，页面会要求补充业务组、数据源等字段，而不是随意猜一个值。
这类能力最适合“逻辑不难，但字段很多”的工作。例如，为生产环境主机创建一条 CPU 持续高于阈值的告警，或者临时屏蔽某台机器两小时。过去的成本不只在填表，还包括查指标名、确认标签、寻找通知规则以及避免漏填。AI 把自然语言转换成配置草稿，再由用户确认，能减少重复操作和新人犯错的机会。
当然，AI 创建配置不等于免审。阈值是否符合业务容量、通知是否会打扰错误的团队，仍需要负责人判断。越接近生产写操作，越应该保留人工确认和变更记录。
AI 出现在真正需要它的输入框旁边
v9 没有把所有能力都塞进一个独立聊天页。全站可以随时唤起助手，告警事件详情、通知模板、PromQL、SQL 和日志查询等场景也有对应入口。页面还能依据当前位置推荐提示词，让用户不必先研究“AI 能问什么”。
背后使用的模型由企业统一管理。夜莺支持 OpenAI 兼容协议、Anthropic Claude 和 Google Gemini，可以接公网 API、企业内部 LLM 网关，也可以连接 Ollama、vLLM 等私有化模型。配置完成后，AI 助手、事件分析和事件流水线中的 AI 总结可以复用同一套模型配置。
不配置大模型，夜莺原有的监控告警能力仍然正常工作。这一点很重要：AI 是提高效率的可选层，不是把监控系统运行权交给外部模型。
22 个 Skill 决定它不只是自由问答
夜莺 v9 正式版内置 22 个 Skill，覆盖规则创建、主机健康诊断、告警排障、数据查询、通知配置和仪表盘分析等常见任务。Skill 会为特定场景提供相对稳定的步骤、工具和输出要求，减少大模型每次自由发挥。
企业还可以把自己的 SOP 写成 Skill，让 AI 按团队认可的排障顺序工作。通用模型负责理解和推理，夜莺提供现场上下文，Skill 约束具体方法。三者缺一，AI 都容易退化成“说得有道理，但不能直接拿来值班”的问答工具。
谁值得启用，谁可以先等等
规则多、数据源多、值班人员经验差异大的团队，会最容易感受到收益，因为它们每天都在为上下文切换和重复答疑付费。只有少量规则、值班人员固定的小团队，也可以先使用 PromQL 生成和文档问答，不必一次性开放全部能力。
数据敏感的团队应优先接入内网模型，并审查模型能看到的数据范围；对写操作保持谨慎，先从只读查询和事件解释开始。模型的质量、延迟和成本也会影响体验，不能把所有效果都归因于夜莺本身。
Nightingale AI 最有价值的地方，不是“监控系统也能聊天了”，而是少了一道把现场人工搬给 AI 的工序。如果 AI 仍然需要你复制一切，它只是一个更贵的搜索框；当它认识当前事件、权限和配置时，才开始像一个真正的 SRE 副驾驶。
