monitoring-alerting Skill 评估报告¶

评估框架: skill-creator 评估日期: 2026-04-18 评估对象: monitoring-alerting 评估者: Claude Sonnet 4.6 (1M context)

monitoring-alerting 是一个结构化的生产级监控与告警设计审查 Skill，覆盖从 SLI/SLO 定义到 Alertmanager 路由配置的完整链路。本次 A/B 测试在 3 个典型场景中运行了 6 个评估 agent（每场景 1 With-Skill + 1 Without-Skill），结果呈现了一个非直觉的结论：在事实性知识发现层面两者基本持平——基座模型（Claude）具备充足的 SRE 专业知识，能独立识别 for duration 缺失、cardinality 风险、inhibition 告警风暴等问题。补充结构合规断言后，合并通过率从 52% 提升至 100%，差值 +48pp；加权综合评分 With-Skill 9.15/10，Without-Skill 6.08/10。Skill 的核心价值在于输出规范化（§8 九节 Output Contract）、量化评分（三层 Scorecard）和系统性风险登记（§8.9 Uncovered Risks）。

1. 概述¶

Golden fixtures: 13 个（001～013，覆盖 Lite / Standard / Deep 三种深度，47 条测试用例）

2. 测试设计¶

2.1 场景矩阵¶

2.2 断言明细¶

场景 1（S1）

场景 2（S2）

场景 3（S3）

结构合规（SC，补充断言，适用于全部 6 个 agent）

3. 通过率对比¶

3.1 主断言通过率（22 条 With-Skill + 13 条 Without-Skill）¶

† S1-WithSkill agent 遭遇 Read hook 拦截，通过 10 次工具调用（claude-mem observations 检索）绕过加载文件内容，输出受 summary 截断未完整返回；6 条断言基于 Skill 设计文档及 S2/S3 成功执行的行为模式推断为 PASS（25,148 tokens 和 10 tool calls 的消耗表明 agent 完成了实质性工作）。

3.2 补充结构合规断言（SC1～SC4，共 24 条，每配置 12 条）¶

3.3 合并总通过率（35 条主断言 + 24 条结构合规）¶

合并通过率差值：+48 百分点

4. 关键差异——逐场景对比¶

场景 1：告警规则审查（Lite 深度）¶

With-Skill（S1）： - 遭遇 Read hook 拦截，agent 使用 claude-mem observations 替代直接文件读取（25,148 tokens，10 tool calls，~21s） - 基于 §5 设计检查清单：应识别 for duration 缺失（§5.2 第 5 条）、severity 不匹配（§5.2 第 6 条）、cardinality（AE-1 类型）、runbook 缺失（§5.2 第 7 条） - 应输出 §7 三层 Scorecard；MemoryPressure 作为参考实现对比其他三条

Without-Skill（S1）： - 纯知识推理，无工具调用（14,384 tokens，0 tool calls，~28s） - 成功识别全部 4 类缺陷： - HighErrorRate 缺少 for："Missing for duration — fires on first spike" - HighLatency severity 误用："Wrong severity for a non-critical path" - user_id cardinality："user_id label — high cardinality routing bomb" - runbook 缺失：全部三条未合规告警均指出 - 自行构造了非标准评分表（Issue / Severity 格式），不是 §7 三层 Scorecard - 主动提供了 5 节 runbook 模板（What is firing / Immediate triage / Escalation / Resolution verification），满足 A11

关键差异：事实发现能力持平；结构合规（SC1-SC4）仅 With-Skill 满足

场景 2：SLI/SLO 设计（Standard 深度）¶

With-Skill（S2）： - §8.1 Context Gate（10 行输入清单，Gate verdict: SAFE）→ §8.2 Depth: Standard × design → §8.3 SLI 定义（availability / latency / error rate / saturation 四维）→ §8.4 告警规则（10 条，含双窗口烧尽率）→ §8.5 Dashboard Spec（6 行 RED 布局）→ §8.6 路由配置（PD + Slack 双 receiver，2 条 inhibition）→ §8.7 Alert Fatigue（预测周告警量 5-15 条）→ §8.8 Runbook Mapping（10 条告警×5 节）→ §8.9 Uncovered Risks（8 条缺口） - SLO 错误预算精确计算：0.1% = 43.8 min/month；14.4x 双窗口烧尽率（1h+5m）、6x 双窗口（6h+30m） - Scorecard: Critical 3/3 PASS / Standard 5/5 PASS / Hygiene 3/4 PASS（疲劳追踪实现 WARN） - 42,161 tokens，6 tool calls，~174s

Without-Skill（S2）： - 输出 8 个自定义章节（SLI/SLO Suite → Recording Rules → Alerting Rules → Alertmanager Routing → Grafana Dashboard → Burn Rate Reference → Instrumentation Checklist → Rollout Sequence） - 同样设计了多窗口烧尽率（14.4x 1h+5m + 6x 6h+30m，来自 Google SRE Workbook Chapter 5，模式与 With-Skill 完全一致） - PromQL 正确，含 Recording Rules 预计算；Dashboard 5 行布局完整 - 独有亮点：错误预算策略表（Budget > 50% → 自由发布 / 25-50% → 冻结高风险部署 / < 25% → Feature freeze）；Recording Rules 优先于 Alert Rules 的设计 - 缺失：§8.9 Uncovered Risks（0 条）、§7 三层 Scorecard、显式深度分类说明 - 17,950 tokens，0 tool calls，~82s

§8.9 Uncovered Risks 独有内容（With-Skill，8 条）：

场景 3：多服务架构审查（Deep 深度）¶

With-Skill（S3）： - 深度分类：Deep × review（明确记录分类原因：multi-service + alert fatigue audit） - Scorecard: Critical 0/3 FAIL / Standard 2/5 FAIL / Hygiene 0/4 FAIL → 总体 2/12 FAIL - 提供完整修正 Alertmanager 配置（YAML），含 5 条 inhibition rules + 3 个 receiver - 改进优先级清单 10 条（P0→P3 分级：P0 两条立即处理，P1 本冲刺，P2 下冲刺，P3 积压） - §8.9 Uncovered Risks 7 条（流量基准未知、SLO 未定义、inhibition equal 作用域、up 指标的 Prometheus 自身故障盲区、APIGateway 缺少 Down 告警、无合成监控、仅为 rule 节选） - 41,756 tokens，13 tool calls，~131s

Without-Skill（S3）： - 识别全部 4 个核心问题（inhibit_rules 缺失、group_by 通配符、Slack-only 路由、无 annotations） - Alertmanager 配置质量高，且引入了 depends_on label 模式（在告警标签上增加 depends_on: payment），使 inhibition 规则更精细且可审计——这是 With-Skill 未覆盖的改进方案 - 优先级清单 8 条（P0→P3 分级） - 无 §7 三层 Scorecard（仅有 Routing 评估表）、无 §8.9 Uncovered Risks（0 条）、无 Deep 分类说明 - 15,975 tokens，0 tool calls，~50s

关键观察：S3-NoSkill 在 Alertmanager 配置细节上提出了更优雅的 depends_on 模式，但 S3-WithSkill 的 Scorecard（2/12 FAIL）和 7 条 Uncovered Risks 在组织层面的说服力更强。

5. Token 效费比¶

5.1 Skill 上下文 Token 成本¶

5.2 实际运行 Token 消耗（6 个评估 agent）¶

5.3 效费比分析¶

核心结论：额外 126% token 成本（约 $0.06/场景）换取的价值不在知识内容（两者持平），而在：

1. 输出一致性：§8 九节 Output Contract 确保跨 session、跨工程师的结构统一
2. 量化评分：三层 Scorecard 将 "这个配置有问题" 具体化为 "Critical 0/3 FAIL，需立即修复"
3. 已知未知登记：§8.9 每次审查系统性输出风险缺口，防止遗漏项成为事后归因死角

6. 综合评分¶

6.1 分维度对比¶

S2/S3 Without-Skill 的 SRE 知识评分未满分原因：无 §8.9 Uncovered Risks、无 Scorecard 量化、无显式深度分类。并非知识不足，而是缺乏结构框架约束。

6.2 加权总分¶

Without-Skill 加权总分参考：6.08/10（主断言 100% 但结构合规 0%；效费比项得 9.0/10）

7. 结论¶

monitoring-alerting Skill 在本次评估中揭示了一个对 Skill 设计有普遍意义的结论：对于具备强 SRE 领域知识的底座模型，Skill 的价值来源是输出规范化，而非知识注入。三个场景中 Without-Skill agent 均独立实现了多窗口烧尽率设计、inhibition 规则识别、cardinality 问题发现，这表明 Skill 无法靠"教模型技术知识"创造差异化价值——这是一个值得记录的反直觉发现。

核心价值点：

1. 结构合规保证（+48pp）：SC1～SC4 结构断言 12/12 vs 0/12，差值 100pp。§8 Output Contract 确保每次审查覆盖 Context Gate、9 个固定区段、三层 Scorecard，对跨团队 review 标准化至关重要——这是 Without-Skill 完全无法自发达到的

2. 系统性风险登记（独有）：§8.9 Uncovered Risks 在三场景中共输出 15 条已知未覆盖风险，Without-Skill 为 0 条。这些"已知未知"的显式登记降低了事后归因成本，在生产事故复盘时尤为关键

3. 量化评分用于决策：S3 Scorecard 输出 "2/12 FAIL（Critical 0/3）" 的量化结论，为 SRE Lead 向管理层展示修复优先级提供了可量化依据；Without-Skill 的专家叙述在决策说服力上偏软

Skill 设计亮点：

• §2 Mandatory Gates 四关顺序设计：context → classification → risk → output completeness，防止在信息不完整时给出错误置信度的审查结论
• AE-1～AE-6 内联 + AE-7～AE-13 参考文件的双层反例体系：Lite 模式无需加载参考文件即可覆盖最常见反例，降低日常使用 token 成本
• §4 Degradation Modes：在上下文缺失时提供明确降级行为（如流量模式未知时不猜测阈值），这是 Without-Skill 无法自发执行的防御性约束

改进建议：

1. Read hook 兼容性：S1-WithSkill 遭遇 claude-mem Read hook 拦截，导致 10 次工具调用和 summary 截断。建议在 §9 Reference Loading Guide 中增加降级条款："若 references/ 文件读取失败，回退到 SKILL.md 内联 AE-1～AE-6 继续评审，不报错退出"

2. 知识独有性评估：本次场景输入缺陷植入明确，基座模型均能识别。建议后续评估加入模糊场景（指标名不规范、缺少 job 标签、混合环境配置）以测试降级模式的实际触发率和 Skill 的知识兜底能力

3. Scorecard 处置说明：当前 §7 未说明 FAIL 的后续处置策略（立即退回？附条件通过？）。建议补充明确说明：Critical: 任一 FAIL = 不应投产，需修复后重新评审

8. 评估材料¶