metric-diagnostics

相关技能

如果需要业务背景来理解指标、分析周期、负责人或合理的解释，请使用 $gather-business-context。

如果任务要求在诊断指标变化后提出建议或权衡决策，请使用 $product-business-analysis。

如果仪表板可信度、粒度、数据新鲜度或数据源之间的差异可能影响指标，请使用 $analyze-data-quality。

指标诊断

使用此技能诊断指标为何发生变化或与预期不符。复现指标，定义比较方式，量化变化，验证可能的驱动因素，并说明哪些内容已验证、可能成立、尚未解决，以及接下来可以采取哪些有用的行动。

如果缺少的信息会实质性改变分析框架或建议，请向用户澄清。否则，请作出合理假设，说明该假设，然后继续。

技能配置

数据源发现与验证

将相关语义层作为起始地图，而非边界。

1. 探索所有可能的数据源。 搜索所有可能包含与任务相关的数据，或可能改变解读的已连接或已提供数据源。在每个结构化数据源中，针对相关架构、数据集、表、视图、模型和指标，重新执行目录或元数据发现。已知的数据源、表、仪表板和语义映射都是起点，而非终点。
2. 比较重复和冲突的数据。 当数据源内容重叠或意见不一致时，比较其所有权、新鲜度、定义、粒度、覆盖范围和直接性。使用最权威的数据源，或在必要时组合互补的数据源。指出重要冲突，解释为何所选数据源具有决定性，并在得出结论前通过实时读取验证所选数据。

数据源访问保护措施

在查询数据源、构建产物或得出结论前，确定答案是否需要特定的事实来源。

如果所需数据源不可用，请停止该路径。告知用户需要哪个数据源，请其开放该数据源或提供经审核的替代来源，且不要将较弱的替代来源视为等价来源。

如果缺失的数据源仅用于可选补充，请基于现有最有力的证据继续，并在该缺口会实质性影响答案时予以说明。

工作流

1. 明确诊断问题

明确诊断要回答的问题，以便清楚了解发生了什么变化，以及哪种比较能够证实这一点。

明确以下内容：

• 指标在业务上的含义
• 用于衡量变化的时间范围和比较方式
• 决定统计范围的群体和粒度
• 负责定义该指标的数据源
• 要回答的诊断问题，例如变化、集中情况或对账

如果需要业务背景来理解指标含义、分析周期内发生了什么变化，或哪些解释较为合理，请使用 $gather-business-context。

2. 验证指标定义和数据源

在解释变化之前，先确认指标定义正确，且源数据能够可靠地衡量该指标。

确认指标定义、粒度、聚合逻辑、筛选条件、联接、排除项、数据新鲜度、血缘关系，以及可信数据界面之间是否存在分歧。将数据源检查聚焦于可能改变答案的问题。

将当前上下文、指定的语义层和熟悉的表名视为候选数据源，而非已选定的数据源。对于宽泛的指标问题，在选择主导数据源之前，先对可用表、仪表板、指标文档、语义层或其他事实来源进行实时数据源发现。如果两类数据源都可用，至少检查一个面向业务或呈现顶层指标的数据界面，以及一个较低层级的数据源界面，然后说明为何所选数据源应作为答案的依据。

如果数据新鲜度、粒度、联接、缺失情况、架构漂移、异常值、意外类别或分布变化可能影响可信度，请使用 $analyze-data-quality。

如果需要新鲜的 SQL、Python、统计建模、可复用计算或多步骤分解，请使用 $jupyter-notebooks，以便留下可检查的分析记录。

3. 确定指标模式

在寻找驱动因素之前，先确定诊断需要解释的指标模式。量化相关时期和范围内的指标。如果问题包含比较，则复现该比较。

在验证模式的幅度、时间和范围之前，不要寻找原因；如果尚未验证，则明确标注存在不确定性。

4. 选择诊断方案

选择最少的一组切分和检查，以解释该模式或增强可信度。

根据指标的运作逻辑、业务上下文和数据源结构来选择驱动维度。优先考虑业务通常会监控或能够采取行动的驱动因素，而不是数据源中的所有字段。如果不清楚哪些驱动因素相关，请使用当前上下文、指定的语义层或 $gather-business-context，了解业务如何解释该指标，以及分析时期前后发生了哪些变化。

使用较低层级的表时，不要将驱动因素分析局限于首次查询所展示的字段。应重建或联接回答问题所需的业务分组，例如模型系列、模型超系列、细分市场、地区、群组、产品分类体系或客户层级。如果无法重建分组，应在简化分析之前说明这一点。

选择适合问题的解释模式。常见示例：

• 指标变化：将重点窗口与基线比较，按细分市场贡献排序，检查同类对象或历史背景，并测试是组合变化还是细分市场内部变化。
• 峰值、回归或事件：确定开始时间、峰值、恢复情况，检查分布形状而不只是平均值、受影响的切片、退化是广泛还是局部，以及流量或故障行为是否发生变化。
• 最大贡献者或集中度：定义“最大”的含义，为实体排序，比较总占比和变化，并查找主要变动者、新增项和退出项。
• 对账或差异分析：对齐定义、筛选条件、粒度、分子、分母和排除项；量化解释差距的组成部分，并说明任何残差。

5. 分解并验证驱动因素

量化主要驱动因素，并验证它们是否能解释这一模式。

使用最有力且易于获取的证据，衡量每个主要驱动因素。说明它是否能解释这一模式、相对于相关基数、趋势或差距有多大、影响范围广泛还是集中，以及在正确的比较或范围下是否成立。

不断迭代驱动因素假设，直到解释能够以与业务相关的方式回答“为什么”。当有希望的交叉切分和下钻分析可能揭示关键解释时，应继续跟进；当进一步切分不太可能改变结论或显著提高信心时，就停止分析。

结合背景解读驱动因素结果：

• 使用相关基数、比较对象或总量占比，让驱动因素更有意义。
• 对于比率，检查变化是由分子、分母还是两者共同造成的。
• 对于可加总指标，如果计算贡献占比能让结论更清晰，就进行计算。
• 如果区分构成效应与细分群体内部的表现效应会改变解释，就将两者分开。
• 当需要解读可加总贡献时，优先使用互斥的驱动因素类别；精确核对分解结果，或衡量并说明残差。

将测量问题视为可能的解释，而不只是需要清理的细节。例如，这一模式可能源自日志记录变更、近期数据不完整、行重复，或分母变化，而非业务本身发生变化。

让解释的确定程度与证据相符，并明确呈现重要的不确定性。在会影响解读时，应提供背景信息，例如这一模式是常见、异常、符合预期，还是与已知变更有关。

如果图表能让诊断结论更易理解或核实，请使用 $visualize-data。

6. 说明影响并提出后续行动

先回答诊断问题，再在证据支持的情况下说明实际影响。

回答应清楚说明：

• 所解释的模式
• 最有力的驱动因素解释及其支持证据
• 该模式对业务的重要性
• 对这一解释应有多大信心
• 最重要的影响、下一步行动或后续工作

如果用户需要的是建议或权衡决策，而不只是诊断结论，请使用 $product-business-analysis。

应明确区分影响判断与经过验证的事实报告，让读者清楚证据止于何处、解读始于何处。不能仅凭时间上的先后关系就声称存在因果关系；如果某种解释只是合理假设，应明确说明。

如果指标结果明确，但需要业务背景来解读“那又怎样”或确定切实可行的后续行动，请使用 $gather-business-context。

如果在分享前需要审查方法、计算、注意事项或诊断结论的证据支持，请使用 $validate-data。

不要把对产物或报告的验证当作分析验证。交接前，请确认分析包含核心指标变化、驱动因素的贡献占比或效应大小、来源与时间窗口核对结果、所用查询的确切 SQL 或查询引用，以及可能改变解读的注意事项。

除非用户明确要求仅在聊天中简要回答且不制作产物、要求不要创建报告／文件／产物，或选择了其他主要产物，否则应将诊断的核心结论及支持证据交给 $build-report。没有明确的人工豁免时，必须执行此交接；不能因为用户提出了直接的诊断问题，或没有使用“报告”一词，就推断用户豁免了交接。由 $build-report 负责报告呈现、展示润色、可复现性处理和分享交接。