launchdarkly-metric-choose

LaunchDarkly 指标选择

你正在使用一项技能，它帮助用户在设置实验、受控发布或发布策略之前选择正确的指标。你的工作是了解功能上下文，呈现哪些内容会从现有项目策略中自动附加，盘点哪些指标可用且健康，并生成清晰、带类型的推荐。

本技能仅提供建议。它不会创建指标、将其附加到实验，或配置发布。对于这些任务，请参阅本文档末尾的相关技能。

前提条件

本技能要求在你的环境中配置远程托管的 LaunchDarkly MCP 服务。

必需的 MCP 工具：

• list-metrics — 盘点可用指标及其类型和事件键
• list-metric-events — 检查哪些事件键最近有活动

可选的 MCP 工具（增强工作流）：

• list-release-policies — 获取项目级策略，这些策略配置哪些指标会自动附加到受控发布。用于受控发布和发布策略路径。

工作流

步骤 1：确定上下文

预先提出两个问题：

1. 这是用于什么？

   • (a) 实验 — 使用标志变体测试假设
   • (b) 受控发布 — 通过自动回归检测逐步发布变更
   • (c) 发布策略 — 创建或编辑项目范围的策略，为所有符合特定条件的受控发布配置默认指标

2. 变更是什么？

   • 标志键（如适用）
   • 通俗语言描述："发布新的结账流程" / "测试新的推荐算法"

步骤 2：获取现有配置（仅限受控发布和发布策略）

对于实验 — 跳过此步骤。 没有需要呈现的既有配置。

对于受控发布和发布策略工作，先调用 list-release-policies：

list-release-policies(projectKey)

在提出任何建议之前呈现结果：

Your project has 2 release policies:

Policy: "Production guardrails" (applies to: environment=production)
  Auto-attaches to guarded rollouts:
    ✓ api-error-rate  (count, LowerThanBaseline)
    ✓ p95-latency     (value, LowerThanBaseline)
    ✓ [Metric group] Core Platform Health (3 metrics)

Policy: "Default" (applies to: all environments)
  No metrics configured.

这会在用户选择任何额外内容之前，告知他们已经覆盖了什么。对于受控发布，这些指标会自动出现 — 推荐是关于在此基础上添加什么，而不是从头重建。

如果不存在策略，或没有任何策略配置了指标，请注明所有指标都必须手动选择。

步骤 3：盘点可用指标及事件健康状况

调用 list-metrics 查看项目中的所有指标，然后与 list-metric-events 交叉引用。

组织为两组：

组	标准	备注
健康	事件键出现在 list-metric-events 中	可以安全推荐
有风险	事件键未出现在 list-metric-events 中	警告：可能不会产生数据

在推荐之前展示此盘点 — 它可能揭示用户心中所想的某个指标没有事件流入。

步骤 4：推荐

推理方式因上下文而显著不同。

---

(a) 实验

从假设开始，而不是从指标列表开始。

在查看可用指标之前，请让用户补全这句话：

“如果这项变更成功，[指标] 将会 [上升 / 下降]。”

主要指标必须直接衡量该假设——不是代理指标，不是相关性。如果用户无法补全这句话，先帮助他们做到这一点。

提出一个主要指标。 它必须：

• 直接衡量该假设
• 有事件正在持续流入
• 具有明确的成功方向（HigherThanBaseline 或 LowerThanBaseline）

提出带类型的次要指标。 对每种适用的类型，至少建议一个：

类型	用途	示例
护栏	这项变更是否破坏了什么？	错误率、崩溃率、延迟 p95
反向指标	A 的改善是否以 B 为代价？	如果主要指标是转化率，则加上支持工单数或会话时长
支持性信号	相关行为是否证实了该假设？	如果主要指标是注册量，则加上引导流程第 2 步完成率

每种类型各一个通常是合适的量。更多次要指标会增加噪声和解读负担。

---

(b) 受保护发布

受保护发布是安全机制，不是实验。你添加的每个指标都是一个潜在的自动回滚触发器——如果它在发布完成之前越过阈值出现回退，LaunchDarkly 可以停止并还原该发布。

从自动附加的内容开始。 在第 2 步展示发布策略结果之后，问：“自动附加的指标够用吗，还是你想为这次特定的发布添加更多指标？”

在推荐额外指标时：

• 偏向可靠性——选择基线稳定、可预测的工程指标（错误率、延迟、崩溃率）
• 避免噪声大或在回归分析下难以解读的探索性产品指标
• 越少越好。 两到三个高信号指标是合适的规模。超过五个会产生误报回滚风险。
• 只推荐有事件正在持续流入的指标。 受保护发布中的高风险指标要么不产生任何信号，要么更糟——由于数据质量问题而非真实回退，触发误回滚。

任何受保护发布的建议起点（如果尚未被某个策略覆盖）：

1. 错误率——我们在新变体中看到更多错误吗？
2. 延迟 / 响应时间——新变体更慢吗？
3. 一个与变更所影响的核心用户操作相关的领域特定指标

---

(c) 发布策略

发布策略适用于项目中匹配其条件的每一次发布。这是最高的门槛。

从当前状态开始。 在第 2 步展示现有策略之后，问：“你正在编辑哪个策略，还是想创建一个新策略？它将应用于哪些环境或标志条件？”

在推荐策略指标时：

• 最多 2–3 个指标。 超过这个数量会让策略成为每一次发布的负担，包括那些指标不太适用的发布。
• 只推荐具有长期、稳定事件历史的指标。 如果一个事件已经可靠地流入数月，它就是安全的项目级默认值。偶发的缺口在规模化时会带来问题。
• 对新增指标提出异议。 如果用户提出超过 3 个，问他们会移除哪些。做出选择的纪律正是关键所在。
• 解释范围条件。 范围限定为 environment=production 的策略只适用于生产环境发布。帮助用户思考他们是否希望在预发环境（基线可能不同）中使用相同的指标，还是使用单独的策略。

典型的强策略候选：错误率、一个核心转化或参与度指标、延迟。

第 5 步：交付建议

输出一份清晰、已命名的列表。明确说明每个指标的用途以及已覆盖的内容：

Recommended metrics for: new checkout flow guarded rollout (environment: production)

AUTO-ATTACHED (from "Production guardrails" policy):
  ✓ api-error-rate    (count, LowerThanBaseline)
  ✓ p95-latency       (value, LowerThanBaseline)

ADDITIONAL — recommended for this rollout:
  ✓ checkout-conversion  (occurrence, HigherThanBaseline)
    → Confirms the rollout isn't degrading the core conversion the feature targets

⚠ page-load-time — no recent events. Instrument the event before including it,
  or remove it from the list to avoid a false rollback trigger.

然后以下一步行动收尾：

• 如果用户需要的指标不存在 → 使用 metric-create skill
• 如果事件没有上报 → 使用 metric-instrument skill
• 列表确认后 → 配置受控发布或实验（通过 LaunchDarkly UI 或 API）

重要背景

• 实验进行中修改指标需要重启。 LaunchDarkly 会在实验启动时对指标配置进行快照。启动后添加、删除或修改指标都需要停止实验并重新启动——变更前的历史数据不可比较。如果用户提到他们正处于实验进行中，请立即提出这一点。
• 没有事件的主指标比没有主指标更糟。 实验不会产生任何统计输出。事件健康是主指标的硬性要求。
• CUPED 与百分位分析不兼容。 如果实验使用 CUPED 方差缩减，基于百分位的指标（例如 p95 延迟）会静默降级为基于均值的分析。如果用户在启用 CUPED 的实验中选择了百分位指标，请指出这一点。
• 上下文类型不匹配会导致数据缺失。 如果指标事件使用 device 上下文进行追踪，但实验按 user 进行随机化，事件将无法正确归因。请确认 track() 调用中的上下文类型与实验的随机化单元一致。
• 发布策略中的指标必须共享相同的上下文类型。 受控发布发布策略中的所有指标都必须使用相同的随机化单元。如果用户提出的指标上下文类型不匹配，请在他们尝试配置策略之前指出。

相关 Skills

• launchdarkly-metric-create — 创建一个尚不存在的指标
• launchdarkly-metric-instrument — 添加一个 track() 调用，让事件开始上报