很多团队有一长串 KPI，却说不清三件事：什么叫成功、当前是否在轨、下一步该做什么。指标数量增加，判断力反而下降。
Data Analytics Skills 把这件事拆成两个 Skill：Design KPIs 负责定义成功，KPI Reporting 负责把实际表现、目标、驱动和行动组织成经营读数。两者合起来，才是一条从度量契约到持续经营的闭环。
本文基于公开 Skill 文档做结构化解读。文中的 AI 数据分析 KPI 是教学示例，不是 OpenAI 官方指标；Skill 文本描述的是预期方法与边界，不代表任何真实业务基线。
先明确决定，再选择指标
指标不是越多越好，也不是越漂亮越好。Skill 原文要求先回答：这套指标要支持谁、在什么节奏下、做什么决定。
这个顺序很容易被跳过。团队通常先问“我们该看哪些指标”，于是把能算的都算出来，再挑几个看起来重要的放进看板。结果是每个指标都有人负责解释，却没人对“成功”负责。
原文给出的筛选标准有六项，可以当作候选指标的过滤器：
| 标准 | 要回答的问题 |
|---|---|
| 反映真实目标 | 它是结果本身，还是只是容易涨的替代量 |
| 能改变决定 | 数值变动后，团队会做什么不同的事 |
| 及时给出信号 | 在决策节奏内能看出变化，而不是一年后才揭晓 |
| 有可控杠杆 | 团队是否有办法影响它 |
| 可稳定测量 | 能否持续、一致地计算，而非一次性手工统计 |
| 不易刷高 | 提升它是否会悄悄损害质量、信任或成本 |
最后一条最容易被低估。“不易被误导性地改善”意味着指标本身要带防作弊结构：如果提升转化率可以通过放宽资格实现，那么这个转化率就必须和资格指标一起看。
原文建议收敛到 1–3 个主 KPI，每个主 KPI 在有助于诊断时配 1–2 个驱动指标，在存在权衡时配 1–2 个护栏。除此之外的指标，只有在能实质改善决策时才值得加入。
三层结构：结果、驱动与护栏
指标体系不是平铺的清单，而是三类关系：
- Outcome（结果）：最终想改变什么。
- Drivers（驱动）：通过哪些可控路径影响结果。
- Guardrails（护栏）：哪些底线不能被牺牲。
以一个 AI 数据分析产品为例，教学设定可以是：
| 层级 | 示例指标 | 它负责回答 |
|---|---|---|
| Outcome | 决策可用的分析完成率 | 分析是否真的支持了决定 |
| Drivers | 首个有效答案耗时、可验证来源覆盖率 | 哪些环节决定结果 |
| Guardrails | 返工与错误率、单任务成本、端到端延迟 | 代价是否可接受 |
这个结构比“一个总分”更有用，因为总分无法告诉你该改哪里。结果下滑时，驱动指标说明是慢了还是错了；护栏指标说明修得对不对。原文同时提醒：不要在没有来源定义支持时凭空发明因果层级。驱动关系应该来自业务实际如何运作，而不是为了让图好看。
汇报前，锁定六个口径
KPI Reporting 在拉数之前要求明确六件事：定义、来源、时间、比较、目标、受众。
| 口径 | 需要写清楚的内容 |
|---|---|
| 定义 | 分子分母、粒度、包含与排除规则 |
| 来源 | 哪个系统或数据集控制这个数字 |
| 时间 | 统计窗口、数据截止时间、时区 |
| 比较 | 环比、同比、对目标，还是对基准 |
| 目标 | 目标值、计划值、节奏定义 |
| 受众 | 谁看、看完要做什么决定 |
这些不是文档洁癖。定义变更、回填、分母漂移、缺失日期、埋点调整，任何一种都会让两个数字不可比。原文的要求是：在解释变化之前，先把“不可比”的原因说明白。
如果某个核心定义不清楚，正确动作是问清楚，而不是先给一个精确结论。
经营读数要能判断状态
有了数字之后，KPI Reporting 规定的顺序是：
- 复现实际值、绝对变化、相对变化和单位。
- 放入目标、计划、基准或历史区间。
- 判断是否在轨，并说明差距、截止日期、所需速度和状态依据。
第 3 步是最常被省略的。只报“完成 62%”没有意义，除非同时说明：目标是 100%、还剩 40 天、平均每周还需推进约 6.65 个百分点（38 ÷ 40 × 7）。
原文还有一条硬约束：不要用占位数字起草经营汇报。如果实际数据被阻塞或不足，应当停下来说明需要什么来源或权限，除非用户明确只要模板或示意。这一点在 Agent 场景里尤其重要，因为模型很擅长生成“看起来很合理”的数字。
原因需要验证，不能现场编
业务事件与指标变化同时发生，不等于因果。这是 KPI Reporting 里最清晰的一条边界：它负责组织已验证的状态和驱动，不负责凭空发明根因。
当读数需要解释驱动时，原文要求进入 Metric Diagnostics，量化主要贡献、已知非驱动和未解释残差，再结合业务背景判断。如果已有可信的既有分析验证过驱动，可以直接引用，不必重跑。
读数的写法也因此分成三类：
- 已验证：有量化贡献和证据支撑。
- 可能解释：时间与人群吻合，但缺少决定性证据。
- 未解释：残差尚未定位，需要进一步诊断。
把三类混在一起写，是经营汇报最常见的失真方式。读者无法判断哪句话可以拿去决策。
交接前的检查清单
KPI Reporting 在交付前要求把以下内容显式写清，再交给报告环节：
- 头条状态与经营含义
- 实际值、目标、节奏依据与比较期
- 已验证的驱动与未解决的不确定性
- 受众、节奏与交付面
- 有助于说明读数的图表意图
它也明确划了边界：这个 Skill 不直接渲染图表，视觉选择与质检交给 Visualize Data；它也不负责最终的排版与发布。责任分开，是为了让每个环节的失败都能被定位。
设计自己的 KPI 系统时
如果把这套方法搬到自己的团队，可以先从三个问题开始：
- 这套指标要改变谁的决定？如果答案是“给领导看看”，那它还不是 KPI。
- 每个主 KPI 是否都有对应的驱动和护栏？只有结果没有护栏，等于鼓励用代价换数字。
- 口径变更时，历史数据是否还能对齐？如果不能，读数就只能描述当下，无法判断趋势。
指标设计建立度量契约，经营汇报让它持续服务行动。每个读数都应该让人更清楚：现在在哪里，接下来怎么做。