本文件说明 alert-engine 的计划方向，以及明确不做的事。
8 阶段降噪管线已完整可用：
for_min → dedup → silence → mute_timing → dependency_inhibit → inhibit → baseline → event_bus
配套能力：时间窗口聚合、告警评分、分级升级策略、症状路由、事故摘要、 补丁编排、SQLite 记忆存储、多源采集适配器接口、CLI。
| 优先级 | 事项 | 说明 |
|---|---|---|
| P1 | 真实采集适配器实现 | Zabbix / n9e / InfluxDB 目前是占位实现（fetch 返回空）。需要补真实 API 对接 |
| P1 | 降噪效果可观测 | 补「降噪前后对比」指标导出，让线上能回答「今天压掉了多少、误杀了多少」 |
| P2 | 基线持久化 | 基线目前只在内存，重启丢失。需支持落盘 + 定期校准 |
| P2 | 多实例一致性 | 指纹与基线的跨进程共享（Redis 或类似），解决多副本部署降噪打折 |
| P2 | 规则配置化 | 静默/抑制规则从代码内建改为外部配置文件（YAML/JSON）加载 |
| P3 | 事故摘要接 LLM | incident_summary 已预留接口，需接具体模型并处理超时与降级 |
| P3 | 规则命中率分析 | 统计每条规则实际命中/误杀次数，指导阈值调优 |
写在这里是为了避免反复讨论：
- 不做告警存储系统（不替代 Prometheus / Loki / Elasticsearch）。 本项目只做「过滤 + 聚合 + 评分」，原始告警的存储交给现有平台。
- 不做告警规则 DSL（不提供 PromQL 式的表达式引擎）。 规则匹配保持「键值相等 + cron 时间窗」这一档，够用且可预测。
- 不做多租户 / 权限体系。这是嵌入式库，不是 SaaS。
- 不做告警路由到 IM 的原生集成。路由层交给 alertmanager， 本项目产出的是「哪些告警值得推」这个判定结果。
- 不追求覆盖所有采集源。每加一个适配器都要长期维护，只做常用的几个。
- 不提供云端托管服务。这是可嵌入任意系统的库。
- 可解释优先：每个告警被丢弃时都要能说出「被哪条规则、因为什么」丢弃。
- 零误杀优先于降噪率：宁可少压一点，也不要压掉真告警。
- 不引入重量级依赖：核心管线只用标准库 +
click/rich。 - 规则可解释、可回滚：阈值与规则要有明确来源与变更记录。
优先欢迎：
- 真实采集适配器实现（带测试）
- 降噪效果度量与可观测能力
- 规则配置化
- 文档与示例（含中文场景的告警样本）