kpi-reporting

KPI 报告

使用此技能，将业务或产品指标转化为可供领导者和团队据此决策的运营简报。任务是明确 KPI 口径，依据恰当的对比基准和目标报告状态，纳入经过验证的驱动因素背景，并清楚说明运营层面的启示。

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

此技能负责 KPI 简报：需要报告什么、如何解读指标、驱动因素背景是否经过验证，以及由此得出什么运营结论。它不负责指标体系设计、调查新的驱动因素，也不负责最终材料的润色。

如果简报需要调查新的驱动因素，请使用 $metric-diagnostics，然后返回此处整理经验证的发现。

技能配置

来源发现与验证

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

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

来源访问防护

在查询来源、构建材料或得出结论之前，先确定答案是否需要特定的事实来源。

如果无法访问必需的来源，请停止该路径。告知用户需要什么来源，请其开放该来源或提供经过审核的备用来源；不要将较弱的替代来源视为等同来源。

如果缺失的来源仅用于可选补充，则继续使用现有最有力的证据；当这一缺口会对答案造成重大影响时，明确标注。

工作流程

1. 明确简报目的

起草前，了解简报面向的对象、要支持的讨论，以及需要报告的内容。以评估期间、用于解读表现的对比基准或目标，以及数据新鲜度截止时间为更新提供依据。

如果补充背景有助于提升简报的准确性或实用性，请向用户询问缺失的信息。

2. 定义指标框架

提取数据前，先确定简报应包含哪些指标，以及每项指标的作用。如果已有指标框架，请确认并采用。如果框架缺失或不够完善，请先使用 $design-kpis，再进行报告。

从主要 KPI 入手，然后仅添加解释状态所需的最少支持指标。支持指标可以解释变化、防范有害的权衡，或展示表现是否符合预期节奏。

优先呈现对受众最重要的指标。不要加入所有可用的细分或对比；只纳入决策者实际使用的指标和切片，以及对理解本次更新有重大帮助的内容。

当主要 KPI 是总体指标、复合指标，或以其他方式无法直接采取行动时，应在解读之前明确其驱动因素分解。若已有指标树，则使用该指标树。否则，找出最精简且有用的一组构成驱动因素，例如分子和分母、数量和比率、组合、漏斗阶段、细分群体、队列或运营输入。若来源定义不支持因果层级，则不要凭空构造。

3. 锁定指标定义和数据来源

在解读表现之前，先确认 KPI 的定义、数据来源、时间窗口、报告截止时间、比较周期，以及任何目标或进度预期。如果缺少目标或进度依据，请先询问，不要擅自将其视为权威依据。如果数据源质量问题可能影响报告指标，请使用 $analyze-data-quality。

对于所有 KPI 更新，起草之前都要对 ~~structured_data、~~company_docs、~~team_communication 和 ~~dashboards_or_bi 进行有针对性的数据源检查。不要因为提示信息很少，就推断没有来自数据源的实际值。使用结构化数据获取实际值、指标定义和比较周期；使用其他数据源渠道获取补充业务背景和权威数据源指引。

如果任何核心定义不明确，请先让用户澄清，再提出具体结论。指标定义发生变化时，在可行的情况下展示经过重述、可进行比较的历史数据；否则，明确指出口径变化。

4. 提取关键实际值

不要根据占位符起草或生成 WBR、MBR、记分卡或 KPI 更新。先查询或检查已连接的结构化数据源，获取核心实际值。如果无法获取实际值或数据不足，请停止并说明需要哪些数据源或访问权限，除非用户明确要求提供模板或示例稿。

先呈现关键实际值，再解释变动或相关驱动因素背景。

对于每项主要 KPI，都要包含当前值、与比较周期相比的绝对变化和相对变化，以及简短解读。

解读变动之前，指出所有会导致当前值难以与上一周期比较的情况，例如跟踪方式变更、数据回填、部分时间段服务中断或缺失日期。

5. 结合背景解读数据

将实际值与有助于解读表现的背景进行比较。如果已定义目标、计划、进度模型、基准、历史区间或相关同类群组，请说明并先将表现与之比较，再评判状态。

如果目标设有截止日期，不要只报告指标高于还是低于目标。还要说明按当前进度能否在周期结束前达成目标。存在进度定义时，使用该定义。如果没有已定义或已找到的进度依据，请询问用户；如果继续使用计算所得的替代依据，请说明该依据是计算得出的，并解释计算方法。

适用时，加入与目标相比的绝对和百分比偏差，并标注红／黄／绿状态。明确说明状态标签依据的是哪种比较或进度标准。

6. 解释经验证的驱动因素

KPI 更新需要包含驱动因素背景，但在将其作为解释呈现之前，必须先验证这些驱动因素。仅凭看似合理的解释并不足够。

如果解读需要解释驱动因素，请使用 $metric-diagnostics 识别并验证驱动因素。如果可信的报告或先前分析已验证这些驱动因素，请使用现有证据，而非重新运行诊断。

7. 补充业务背景和运营影响

识别可能的驱动因素后，使用 $gather-business-context 查找有助于解释发生了什么以及这对解读意味着什么的业务背景。根据驱动因素分析确定要查找的背景，并且只有在证据支持关联时，才将背景与指标联系起来。

将证据、驱动因素分析和业务背景转化为对业务运营的影响。说明这一变动是否令人担忧、应采取哪些后续步骤或行动，以及主要 KPI 是进展正常、存在风险还是超前于计划。只有在证据支持时才建议采取行动；否则，请指出下一步需要进行的验证。

8. 验证解读内容

完成分析后，在整理最终解读内容之前，使用 $validate-data 检查数字、方法、注意事项和证据是否支持所述状态、驱动因素和影响。分享之前解决重大问题；仍存在的限制应在解读内容中说明。

9. 移交数据解读

除非用户明确要求仅在聊天中简短作答、不生成任何产物，要求不要创建报告／文件／产物，或选择了其他主要产物，否则请在最后将已验证的 KPI 数据解读移交给 $build-report。快速状态更新、简要数据解读或要求在聊天中提供发现，都属于直接回复的选择；除非用户同时要求报告、文档、演示文稿或可留存的产物。如果没有得到用户明确豁免，就必须移交报告；不要仅仅因为用户没有使用“报告”一词，就自行推断用户豁免了报告。

移交前，明确说明数据解读的内容：

• 标题状态及其对运营的影响
• 实际值、目标、进度计算依据和比较时段
• 已验证的驱动因素和尚未解决的不确定性
• 已知时的受众、频率和要求的交付形式
• 有助于阐明数据解读的图表或图示

移交前加载 references/report-templates.md，并将匹配的模板作为 $build-report 的源说明。告知 $build-report 这是 KPI 数据解读，并传递上述状态、进度、驱动因素、不确定性、受众、频率、交付形式和可视化指导。不要通过此技能直接绘制图表；应将可视化意图和支持证据交给 $build-report，以便由 $visualize-data 负责图表选择和质量检查。

对于原生幻灯片或演示文稿请求，先使用 $build-report 创建 HTML 报告，因为 $report-to-google-slides 需要已有的本地 HTML 分析报告，无法直接转换实时 MCP 应用报告。然后对该 HTML 报告调用 $report-to-google-slides。如果只有 MCP 应用报告，则使用相同的源证据另行构建 HTML 报告，再进行转换。

标准

指标标准

• 如果 KPI 的定义、来源、时间窗口或比较依据不明确，切勿将其呈现为精确值。
• 当计算逻辑、纳入或排除规则、粒度和时间处理方式会影响解读时，应明确说明。
• 尽可能核对总数，并与之前的报告进行比较。
• 不要比较定义上不兼容的时段、分类或目标。当定义变更、数据回填、分母变化或日历因素影响指标变动时，应予以说明。

状态和进度标准

• 除非用户要求更简略的数据解读，否则应包含核心结论、当前实际值、相关比较、目标或进度背景、驱动因素摘要及其影响。
• 有可用数据时，将实际值与目标、计划、基准或基线并列展示，让读者立即判断表现。
• 如果目标有时限，应使用提供的进度定义，或明确说明采用了计算得出的替代方法，并展示当前表现是否符合进度预期。
• 每次运行时保持重复指标部分的一致性。如果因数据、定义或验证不可用而缺少用户要求的部分，应简要说明原因。
• 仅在有助于确定行动优先级时使用红黄绿状态。颜色应配有文字说明，并说明状态的判定依据。
• 统一数字的舍入方式，标注单位，并在注意事项会改变解读时明确指出。

驱动因素标准

• 在证据支持的情况下，量化驱动因素；不要用描述性文字代替影响幅度的估算。
• 报告有助于解读 KPI 变动的少数关键驱动因素、贡献因素或已知非驱动因素。
• 对于顶层 KPI 变动，将已验证的驱动因素整理为简洁的分解：顶层实际值、组成驱动因素、最大贡献因素或非驱动因素，以及剩余或尚未解释的变动。只有在各组成部分能够准确对账时才使用加总桥接；否则应说明它们之间的关系及不确定性。
• 将已验证的驱动因素与业务背景或假设分开。
• 除非时间、受影响群体和测得的变化都支持这种关联，否则不要将业务事件提升为原因。
• 如果变动是普遍存在还是集中于某些方面会影响运营层面的判断，应明确说明。
• 如果驱动因素的证据仍未明确，应指出不确定之处或后续诊断工作，而不是编造解释。

展示标准

• 面向快速浏览的高管和运营人员撰写：先给出结论，再展示证据。
• 使用便于业务阅读的数字和简洁格式，例如 123k (+8% w/w, +19% m/m)。
• 用能够支撑判断的指标证据替代 strong、healthy 或 soft 等泛泛形容词。
• 将限定条件放在其所影响的论断附近，并省略不会改变解读的限定条件。
• 仅在图表、表格、记分卡或 KPI 卡片能让结论更易理解，且在最终交付场景中仍清晰易读时使用。