企业官网建设流程全解析

前阵子我们的监控值班连续出现两起“指标漏配”事件：一台机器磁盘写满没有触发告警，另一个接口错误率飙到 20% 才发现。翻日志复盘时我发现，Prometheus 的规则文件和巡检脚本都在，但都是上线前人工写死的一套，后续新业务补了不少指标，规则却没人同步更新。

那段时间正好在试用 DeepSeek 处理各种文本生成任务，我突发奇想：能不能让它根据当前的指标清单、业务场景和已有监控配置，自动生成巡检脚本和告警规则？我跟团队说了这个想法，大家的反应很一致：大模型能写 YAML 和 Python，但谁敢直接拿去当监控的准绳？后来我们做了个小范围验证，效果超出了预期，也踩了不少坑。

这篇文章就是这次实践的完整记录：我们用 Prometheus 做指标采集，用 DeepSeek 做配置生成，把日常巡检中最费人力的三类事——脚本编写、规则配置、阈值调优——做成了半自动的流水线。如果你也在维护一套 Prometheus，经常被“规则漏配”“阈值拍脑袋”困扰，这篇文章应该能给你一个可以直接抄作业的起点。我会把 Prompt 模板、脚本示例、规则文件、调参思路和排错经验都展开讲。

1. 先说清楚：巡检脚本和告警规则到底在解决什么问题

1.1 Prometheus 监控体系的日常痛点

很多人以为 Prometheus 部署起来、配上 node_exporter 和几个 exporter，监控就算做完了。但从我的经验看，部署只是十分之一的工作，日常真正消耗精力的其实是三件事：

第一是巡检。Prometheus 自带 Alertmanager 做告警，但告警是“事后通知”，巡检是“事前发现”。比如某个服务的连接池在缓慢增长，按告警阈值还差得远，但趋势已经不对。这时候我需要一个巡检脚本，定时去查一系列 PromQL 表达式，把结果汇总成报告。这个脚本看起来简单，但要维护的查询列表非常多，每接一个新中间件就要手改一次，时间一长就没人愿意动了。

第二是规则配置。Prometheus 的告警规则写起来门槛不高，就是一套 YAML 加 PromQL 表达式。但“不高”和“不容易出错”是两回事。实际环境里，各个服务的业务指标、基础指标混在一起，告警阈值需要区分核心链路和边缘业务，还要考虑周末和工作日流量差异。纯手写规则文件，经常出现缩进错误、变量名写错、正则不匹配，查起来非常耗时间。

第三是规则上线后的验证。写好规则不等于规则正确。Prometheus 提供 promtool 可以做静态校验，但很多团队根本没有把它接入 CI，导致异常规则直接在线上加载，等到半夜误报炸了才发现。

这三个痛点的共同特征是：重复劳动多、上下文依赖强、试错成本高。而 DeepSeek 这类大模型，最擅长的事情之一就是“根据你给出的上下文，批量产出结构化的文本”。它不懂你的业务，但只要你把指标清单、采集周期、业务等级、历史阈值等喂给它，它就能输出一套基础可用的脚本和规则，再由人去审查和微调。这就是整个方案成立的前提。

1.2 为什么选 DeepSeek 来生成配置

选择 DeepSeek，不是因为它比别的模型强多少，而是因为我们需要一个能通过公开接口调用、支持较长的上下文窗口、同时能稳定输出 YAML 和 Python 代码的模型。实际对比过几个选项之后，DeepSeek 在代码生成和中英文混合文本处理上的表现比较均衡，尤其对 YAML 缩进和 JSON 结构这类细节理解得比较到位。

我个人的经验是：大模型生成 Prometheus 规则，最大的障碍不是“不会写 PromQL”，而是“不理解你的监控环境”。DeepSeek 的训练数据里包含大量的 Prometheus 文档、开源规则模板和社区问答，它天然知道常见指标怎么配、for 参数怎么设、label 怎么写。但它不知道你线上到底采集了哪些指标，也不知道你关心的业务指标叫什么名字。所以用它的关键是喂上下文，而不是让它凭空发挥。

我们验证后觉得这个方案的核心价值在于：人工只需要维护“指标清单”和“业务上下文”，让模型去生成“第一版配置”，然后人工做审查。这比从纯白纸开始写要快得多，也比单纯依赖模板要灵活得多。下一节我会详细讲如何准备环境，以及如何设计 Prompt。

2. 环境准备与 Prompt 设计

2.1 最小可用环境清单

先明确一件事：这次实践不要求你有一个很大的监控集群，一个最小可用的 Prometheus 实例就够了。我自己是在一台测试服务器上操作的，配置大概是 4 核 8G 内存，Prometheus 版本用的 2.47 系列，指标来源是 node_exporter 和几个业务应用的 exporter。

如果你的环境还是空的，可以按下面这套命令快速搭起来。我假设你已经安装了 Docker，这是最省事的方式：

mkdir -p /opt/prometheus && cd /opt/prometheus cat > prometheus.yml <<'EOF' global: scrape_interval: 15s evaluation_interval: 15s rule_files: - "rules/*.yml" scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] - job_name: "node" static_configs: - targets: ["localhost:9100"] EOF mkdir -p rules docker run -d --name prometheus \ -p 9090:9090 \ -v /opt/prometheus/prometheus.yml:/etc/prometheus/prometheus.yml \ -v /opt/prometheus/rules:/etc/prometheus/rules \ prom/prometheus:v2.47.0

再启动一个 node_exporter 容器，用于采集基础主机指标：

docker run -d --name node-exporter \ --network host \ prom/node-exporter:v1.6.0

等几十秒后，访问 http://localhost:9090/targets 应该能看到两个 target 都是 UP 状态。这一步非常重要，后续让 DeepSeek 生成规则时，我们得保证至少有一个真实指标的查询结果可以用来验证它生成的表达式是否有效。

如果你已经有现成的环境，可以直接跳到 Prompt 设计。但我强烈建议不要跳过“真实指标验证”这一步，因为大模型生成的 PromQL 再漂亮，最终也要在真实的 metrics 上跑一遍才能确认。

2.2 让 DeepSeek 理解业务背景的 Prompt 设计

很多人在用 DeepSeek 生成配置时习惯把需求一句话丢过去：“帮我写一个报警规则”。这种写法不是不行，但生成出来的内容基本都是通用模板，阈值要么偏高要么偏低，labels 也乱七八糟。原因很简单：模型没有你的指标上下文，只能靠猜测。

我实践下来比较有效的方式是“结构化指令 + 上下文信息 + 输出约束”三段式，并且把上下文字段集中在 Prompt 末尾，防止模型在生成过程中遗忘。下面是我用的一份简化版 Prompt 模板，你可以直接复制去改：

你是一个熟悉 Prometheus 监控体系的 SRE 工程师。 现在需要为一套 MySQL 业务库生成巡检脚本和告警规则。 全局参数： - 采集间隔：15s - 告警评估间隔：15s - 环境：生产环境 - 告警恢复后通知：需要 指标清单（来自实际采集，不要编造）： - mysql_up：mysqld_exporter 暴露，值 1 表示进程存活 - mysql_global_status_threads_connected：当前连接数 - mysql_global_variables_max_connections：最大连接数 - mysql_global_status_aborted_connects：异常中断连接数 - mysql_global_status_slow_queries：慢查询累计值 输出要求： 1. 输出一个 Python 巡检脚本，使用 requests 请求 Prometheus HTTP API。 2. 输出一个 Prometheus 告警规则文件，rules 格式。 3. 阈值需要结合生产环境给出合理默认值。 4. 所有 PromQL 表达式必须严格基于上面给出的指标。 5. 不要生成无关内容。

这个 Prompt 里最关键的是两句话：一是“指标清单（来自实际采集，不要编造）”，二是“所有 PromQL 表达式必须严格基于上面给出的指标”。这两句能显著降低模型瞎编指标名的情况。

为什么要在 Prompt 里把指标名明确列出来？因为 Prometheus 的指标名是半结构化的，模型训练时见过大量相似的命名，它非常容易把 mysql_global_status_threads_connected 想象成 mysql_threads_connected，结果生成一个根本查不到数据的表达式。列出真实采集到的指标名，相当于把模型的搜索空间钉死在一块，后面验证时出错概率会小很多。

另外，我建议在 Prompt 里固定 YAML 的缩进规范。大模型默认输出的 YAML 缩进通常是两个空格，而 Prometheus 的规则文件接受这种格式。但如果是团队规范要求四个空格，你必须在 Prompt 里显式说明，否则生成后还要手动转换。

3. 自动生成巡检脚本的完整流程

3.1 从零写一份“健康巡检”脚本

还是接着上面 MySQL 的例子。我们让 DeepSeek 基于指标清单生成巡检脚本，它的第一版输出大致是这样的结构：一个 Python 脚本，先用 requests 请求 Prometheus 的 /api/v1/query 接口，把几个核心指标拉下来，然后做阈值判断，最后输出一个文本报告。

我实际用下来感觉这个结构的思路是对的，但直接可用性只能算 70 分。主要问题是它生成的脚本把“查询 Prometheus API”和“判断告警条件”混在一起，一旦指标多了就很难维护。我建议在大模型生成的脚本基础上，做一次小重构：把 PromQL 查询列表独立成一个常量字典，每个指标对应一个查询表达式和一个判断规则。这样做的好处是，下次让模型新增一个巡检项时，只需要改这个字典，不需要动主逻辑。

下面是我整理后的一份简化版巡检脚本，你可以直接跑起来试。这个脚本本身是 DeepSeek 辅助生成、我手工调整后的结果，我加了比较详细的注释：

#!/usr/bin/env python3 # -*- coding: utf-8 -*- import requests import json from datetime import datetime PROMETHEUS_URL = "http://localhost:9090" # 巡检项配置：名称 -> (PromQL表达式, 告警阈值, 说明) CHECKS = { "mysql_up": ( "mysql_up", 1, "MySQL exporter 是否存活", ), "connection_rate": ( "mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100", 80, "当前连接数占最大连接数的百分比", ), "aborted_connects": ( "rate(mysql_global_status_aborted_connects[5m])", 5, "5分钟内平均每秒异常中断连接数", ), "slow_query_rate": ( "rate(mysql_global_status_slow_queries[15m])", 2, "15分钟内平均每秒慢查询数", ), } def query_promql(expr: str) -> float: resp = requests.get( f"{PROMETHEUS_URL}/api/v1/query", params={"query": expr}, timeout=15, ) resp.raise_for_status() data = resp.json() if data["status"] != "success": raise RuntimeError(f"Prometheus query failed: {data}") result = data["data"]["result"] if not result: # 没有数据时返回 None，方便上层区分“正常”和“没有监控数据” return None return float(result[0]["value"][1]) def main(): now = datetime.now().strftime("%Y-%m-%d %H:%M:%S") lines = [f"[巡检报告] {now}", "-" * 40] has_error = False for name, (expr, threshold, desc) in CHECKS.items(): try: value = query_promql(expr) except Exception as exc: has_error = True lines.append(f"[异常] {name}: 查询失败 - {exc}") continue if value is None: has_error = True lines.append(f"[警告] {name}: {desc} - 无数据返回，检查 exporter 是否正常采集") continue status = "OK" if value <= threshold else "异常" if status == "异常": has_error = True lines.append(f"[{status}] {name} | {desc} | 当前值: {value:.4g} | 阈值: {threshold}") lines.append("-" * 40) lines.append("结论: " + ("存在异常，请人工确认" if has_error else "全部正常")) print("\n".join(lines)) return 1 if has_error else 0 if __name__ == "__main__": raise SystemExit(main())

这个脚本的核心逻辑很简单，但有个细节容易忽略：当某个 metrics 没有返回数据时，脚本应该返回“异常”而不是“正常”。很多巡检脚本只做阈值判断，忘了处理空值。Prometheus 查询一个不存在的指标并不会报错，它只是返回空 result。如果你不做空值判断，巡检报告里会出现“当前值 0、阈值 80、状态 OK”的假象，这恰恰是监控最危险的情况。

所以我在 Prompt 里特别说明了一句“所有指标都来自实际采集清单，不要编造”，同时在脚本里对 None 做了显式处理。这个设计是这次实践中我认为最值得保留的部分。

3.2 把脚本接到定时任务和人工巡检入口

脚本写好后，下一个问题是：怎么让它定期跑？我采用的是最传统也最稳定的方案：cron 定时任务加日志输出。

# 每 10 分钟执行一次巡检，结果写入日志文件 */10 * * * * cd /opt/prometheus-check && /usr/bin/python3 check_mysql.py >> /var/log/mysql_check.log 2>&1

如果你不想每天清理日志，可以在脚本里加一个简单的大小控制，比如超过 20MB 就截断。这个逻辑没必要让大模型生成，手动几行就能搞定，但很多同学第一次做的时候容易忽略。

定时任务只是“被动巡检”。我更推荐把它做成一个人工巡检入口，也就是在运维平台上提供一个按钮，点一下就能立即执行脚本并输出报告。我们这个项目里因为平台开发排期太长，临时用了一个取巧的方式：写了一个简短的 Web 接口，封装脚本执行，页面就是最简单的文本输出。后来验证效果不错，才把这个能力并进了正式平台。

这一步提到 Web 接口，主要是想强调：DeepSeek 生成的脚本本身是死的，真正的价值在于它能不能作为一个原子能力被嵌入到更大的工作流里。如果只是每天 cron 跑一下、日志丢在服务器上没人看，那这个自动生成的意义会大打折扣。我建议所有做监控巡检脚本的同学，都要有一个“主动触发”的入口。

4. 告警规则配置生成与调优

4.1 直接可用的告警规则模板

巡检脚本解决的是“周期性人工确认”，告警规则解决的则是“7x24 自动通知”。两者可以共用同一套阈值和 PromQL，但告警规则文件有它自己的语法结构：groups、rules、expr、for、labels、annotations。

我让 DeepSeek 基于同一份 MySQL 指标清单生成规则文件，第一版就有模有样，但有个问题：它把 for 参数全设成了 0m。for: 0m 的含义是“只要表达式成立就立刻触发告警”，这在高频采集且指标抖动明显的场景下会严重误报。比如线程连接数偶尔秒级冲到 85% 又回落，这种瞬时的尖峰大多不影响业务，不需要立刻告警。

我们最终采用的规则文件如下，我加上了注释说明每个 for 和阈值的调整理由：

groups: - name: mysql_availability rules: - alert: MySQLUpDown expr: mysql_up == 0 for: 1m labels: severity: critical env: production annotations: summary: "MySQL exporter 不可用" description: "Prometheus 已无法从 mysqld_exporter 采集数据，持续超过 1 分钟。" - name: mysql_performance rules: - alert: MySQLConnectionHigh expr: | mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 > 80 for: 10m labels: severity: warning annotations: summary: "MySQL 连接数过高" description: "当前连接占比 {{ $value }}%，持续 10 分钟，需要关注是否有连接泄漏。" - alert: MySQLAbortedConnectsHigh expr: rate(mysql_global_status_aborted_connects[5m]) > 5 for: 15m labels: severity: warning annotations: summary: "MySQL 异常中断连接较多" description: "5 分钟窗口内异常中断速率约为 {{ $value }}，可能是账号密码错误或网络不稳定。" - alert: MySQLSlowQueryHigh expr: rate(mysql_global_status_slow_queries[15m]) > 2 for: 15m labels: severity: warning annotations: summary: "MySQL 慢查询速率偏高" description: "最近 15 分钟慢查询速率约为 {{ $value }}，建议检查慢查询日志并优化 SQL。"

这个文件有几点我想特别说明：

第一，expr 用了多行写法，Prometheus 的 YAML 支持这种形式，但在表达式内部要注意 PromQL 的优先级。比如连接占比这个表达式，如果不加括号，> 80会被解析成作用于整个除法结果，这没问题。但如果你写的是a > 80 or b < 20这样的复合表达式，就非常容易因为 or 的优先级产生误解。这也是大模型最容易犯错的地方，后面我会单独讲。

第二，labels 里的 severity 和 env 不是 Prometheus 内置必须的，但它们会传到 Alertmanager，你的告警分组和路由规则通常依赖这两个字段。所以在 Prompt 里我要求模型在生成规则时同时生成 labels，不然后续 Alertmanager 的 route 没法按级别分流。

第三，annotations.description 里用的{{ $value }}是 Go 模板语法。这个细节大模型一般知道，但偶尔会写成{{ value }}少掉美元符号，导致告警消息渲染失败。生成后要重点检查这个位置。

4.2 rule 文件加载与告警路由对接

规则文件生成后，不是丢到 rules 目录就完事了。我习惯先用 promtool 做一次静态校验，再通过 Prometheus 的 API 实时重载配置，最后观察告警状态。

先看静态校验：

# 在 Prometheus 二进制所在目录执行 ./promtool check rules /opt/prometheus/rules/mysql_rules.yml

如果输出没问题，再把规则文件挂载到容器，或者直接复制进去，然后触发热加载：

curl -X POST http://localhost:9090/-/reload

去 Prometheus UI 的 Alerts 页面，你应该能看到规则列表。此时规则状态应该是 Inactive，等几分钟如果触发了会变成 Pending，再持续一段时间变成 Firing。Pending 和 Firing 的区别很重要，Pending 表示“条件满足但在 for 等待期内”，Firing 才是真正进入告警。

如果 Prometheus 和 Alertmanager 已经对接，你还需要确认 Alertmanager 的 route 规则能识别 labels 里的 severity 和 env。比如下面这段简化配置：

route: group_by: ["alertname", "env"] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: "default" routes: - matchers: - severity="critical" receiver: "page-critical"

这里最重要的是 group_by 和 repeat_interval 的配合。如果不做 group_by，同一故障触发的多个告警会分别发送，夜间连续收二三十条消息的情况就是这么来的。我们曾经因为没配置 repeat_interval，一个持续告警每 20 分钟重复推送一次，把值班同学搞得非常崩溃。这部分不是 DeepSeek 生成的，但它是整个告警链路里必须人工把关的一环。

4.3 阈值调优不是拍脑袋，要基于数据回放

上一节提到 for 参数和阈值，这里我想单独展开一个很多人容易忽略的点：阈值应该怎么定？

最差的方式是拍脑袋。比如“连接数 80% 告警”，这个 80 从哪来的？如果最大连接数设置得太高，可能 80% 已经对应几百个连接，业务早就卡死了；如果太低，可能平时业务高峰就是 70%，告警天天发，大家习以为常。

我推荐的方式是：把已经接入 Prometheus 的历史指标做一次回放，统计一段时间内的基线。DeepSeek 可以帮你生成查询基线值的 PromQL，但基线判定必须由人来做。比如：

# 近 7 天，连接占比的平均值 avg_over_time( mysql_global_status_threads_connected / mysql_global_variables_max_connections * 100 [7d:1m] )

拿到平均值和 p95 之后，再把告警阈值设为“略高于 p95”，而不是“拍脑袋 80%”。这个逻辑听起来很简单，但实际操作中很少有人这么做，因为要花时间去看历史数据。大模型的价值在于它可以把“计算 p95 的查询表达式”快速生成出来，省去了写 PromQL 的调试时间。

我自己遇到过一个真实案例：某服务的错误率平时是 0.1%，偶尔抖到 1%，只有发布时才会到 5%。如果阈值定 5%，发布时的错误很容易被忽略；如果定 1%，日常抖动会频繁触发。后来我让 DeepSeek 生成了一套“双阈值”方案：1% 持续 30 分钟触发 warning，5% 持续 5 分钟触发 critical。这就是借助模型把“一个阈值”扩展成“分级阈值”，比单纯写一条规则要合理得多。

5. 常见问题与排查技巧实录

5.1 生成代码能用但不符合预期怎么办

这是最常遇到的情况。DeepSeek 生成的脚本和规则第一眼看起来都挺正常，一跑发现：要么查询结果和预期差了十万八千里，要么 YAML 加载失败，要么告警规则根本没被 Prometheus 识别。

我的处理顺序是固定的，按照从外到内的顺序排查：

第一步，先用 promtool 检查规则文件格式。Prometheus 的规则文件错误大多出在缩进和列表结构上，比如 rules 下面少了一个- alert:的短横线，或者 expr 的值没加引号导致解析异常。promtool 会把具体的行号错误直接抛出来，这是定位问题最快的方式。

第二步，去 Prometheus UI 的 Alerts 页面看规则状态。如果规则列表里没有出现你新增的规则，大概率是 rule_files 路径配错了，或者热加载没生效。这时我会执行curl -X POST http://localhost:9090/-/reload并检查 Prometheus 容器日志，热加载失败通常会有明确报错。

第三步，针对 PromQL 本身做单点验证。打开 Prometheus 的 Graph 页面，把模型生成的表达式粘贴进去，看有没有数据。没有数据时，一种可能是指标名不存在，另一种可能是表达式里用到了还没被采集到的新指标。这时候回过头去核对指标清单，比在代码里瞎猜高效得多。

我个人的经验是：大模型生成的脚本如果报错，不要直接让它“重写整个文件”，而是把报错信息原样贴给它，并且只要求它定位和修改报错那一部分。这样做准确率更高，因为大模型在长上下文中重写时，很容易把之前调好的内容也改坏。我用的是“局部修改”模式：把错误信息、出错行、相关配置一起发给 DeepSeek，明确说“只改这段，不要动其他部分”。

5.2 告警频繁误报和漏报的调参经验

告警规则上线后，最常见的反馈是“天天半夜响，都麻木了”或者“这个告警从来没响过”。这两种情况看着相反，本质是一样的：阈值和业务节奏不匹配。

我总结了一套调参流程，供你参考：

先看告警触发记录，找出时间规律。如果告警总在每天固定时段触发，比如凌晨的定时任务、整点的缓存清理，那就说明这个指标本来就有周期性高峰。处理办法不是盲目调高阈值，而是给这条告警增加“静默时间”。Prometheus 本身不直接支持时间维度静默，但可以通过 PromQL 的表达式或者 Alertmanager 的 mute 时间区间实现。如果用的是 Alertmanager，可以在 route 规则里为这个 alertname 单独配一条接收 “null” 的静默路由。如果不想维护额外的静默配置，就只能在生成规则时把阈值按照流量高峰来标定，但这会牺牲敏感度。

再检查 for 参数是否太短。我见过很多误报都是 for 设置成 0m 或 1m，而实际指标只是瞬时抖动。一般来说，CPU、内存、连接数这类指标建议 for 至少 5 到 10 分钟，错误率这类直接影响业务的指标才建议 for 短一点。for 不是越小越灵敏，太小了反而让值班团队疲惫，真正严重的问题被淹没在低等级告警里。

漏报的调法不太一样。漏报往往不是阈值太高，而是表达式设计有问题。比如你用rate(metric[5m]) > 5，如果指标本身是 Counter 类型，没问题；但如果指标是 Gauge 类型，rate 算出来就非常奇怪。这类问题大模型不一定能识别，因为它的训练数据里没有你 exporter 的指标类型说明。最好的办法是人为确认指标类型，并在 Prompt 里写明类型。比如mysql_global_status_*绝大多数是 Counter，但mysql_global_variables_max_connections是 Gauge。这些信息不喂给模型，它就很容易生成不合理的表达式。

5.3 大模型生成配置的“幻觉”边界与控制方法

最后说说大模型生成的固有风险。我在前几节反复强调“只使用给定指标”，就是因为在实践中遇到过多次模型幻觉。最典型的表现是：它生成一个 promql 表达式，指标名看着很像但实际上不存在，比如把 mysql_global_status_threads_connected 写成 mysql_global_status_threads_connect_count。Prometheus 对不存在的指标不会报编译错误，只是查询结果为空。如果你的规则文件里混了三四个这种空查询指标，告警就会全部变成“无数据”，而很多人会把“无数据”误判为“正常”。

控制幻觉的方法，我实践下来最有效的是“分步生成 + 逐步验证”。

第一遍只让 DeepSeek 生成 PromQL 表达式清单，并强制要求它逐条列出依据的指标名。第二遍让它对每个 PromQL 去查询 Prometheus API，返回真实值。这一步不能靠模型，必须用脚本或者 Prometheus UI 验证。第三遍才让它生成完整的 YAML 规则文件。也就是说，把“写表达式”和“写规则文件”拆成两个阶段，而不是一次生成一大块。

还有一个技巧是给 DeepSeek 提供“反例”。在 Prompt 里明确写：“不要使用指标清单之外的任何指标名，如果你拿不准，请输出 NOT_SURE。”我印象很深的一次，模型本来打算用一个不存在的指标，看到这个约束后主动返回 NOT_SURE，并说明原因。虽然它最后还是给出了一个备选方案，但这个“拒绝编造”的行为，比生成一个看起来很专业但实际无效的规则要安全得多。

最后，所有生成的规则和脚本都必须走版本控制，并且在合并前至少过一个真实场景验证。我建议至少在 staging 环境跑一段时间，等规则稳定了再上生产。大模型是提效工具，不是质量保证工具。这一点想明白了，整个方案就能稳定运行。

如果后续你有精力扩展这个玩法，可以考虑把“指标清单维护”也做成半自动：让 DeepSeek 定期读取 Prometheus 的 /api/v1/status/tsdb 或者用 promtool 分析指标使用情况，自动生成“未使用指标”和“疑似新指标”的清单。这样规则配置的维护就不会停留在“这次上线配一次”的状态，而是形成一个持续更新的循环。至少在我自己的环境里，这一步已经开始做了，效果还在持续验证中。