产品经理的工作里，最难的不是想功能、画原型、写 PRD。是把”这个功能上了之后到底有没有用”这件事说清楚。大多数团队的数据看板上密密麻麻几十个指标，但能真正驱动决策的，一只手数得过来。
Anthropic 在知识工作插件套件里放了一个叫 metrics-tracking 的 Skill。名字很直白，做的事情也很直白：帮 PM 定义、追踪、分析产品指标。但它不是那种列一堆 API 和命令行的工具文档，是一套关于”怎么想产品指标”的认知框架。
从北极星指标的定义方法，到 L1 健康指标的分类维度，再到 OKR 设定的评分标准，这套框架把产品数据分析这件事从头到尾拆了一遍。没有一行代码，但比大多数数据分析工具手册更有价值。
说真的，这篇文章不是来教你怎么”用”这个 Skill 的。是把这个框架本身剥开来看，看它为什么值得一个 PM 花半小时读一遍，即使你完全不用 Claude。
环境准备
这个 Skill 的安装是标准的 npx 一条命令：
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill metrics-tracking
在 Claude Code 或任何兼容 Agent Skills 标准的工具中运行即可。如果你用的是 Smithery 平台，搜索 metrics-tracking 直接追加到已有 Agent。
安装后的使用方式跟所有 Agent Skill 一样：用自然语言对话触发。你跟它说”帮我给新的 SaaS 产品定义一套指标”，或者”看看我现在的看板缺了哪些维度”，Skill 就会按框架输出分析。
前置条件几乎是零：不需要装数据库，不需要连 BI 工具，不需要准备数据。它不吃数据，吃的是产品逻辑和业务语境。这实际上也是它跟传统分析工具最大的区别。
但有一个容易被忽略的卡点：你得先把自己的产品逻辑想清楚。Skill 问你的第一件事通常是”你的产品解决的核心问题是什么”，如果连这个问题都答不上来，后面的指标拆解根本跑不下去。
操作流程
这个 Skill 的交互不是线性的”输入产品名，输出指标列表”。它是一套引导式对话，每一步都在逼你回答一个产品决策问题。
第一步是定义北极星指标。Skill 会推给你四条判别标准，每条都在追问”这个指标真的值得被当北极星吗”：
-
价值对齐：指标涨的时候，用户是不是真的得到了更多价值 -
引领性：能不能预测长期商业成功，而不是反映过去 -
可行动：团队能不能通过自己的工作直接影响这个指标 -
可理解：公司里随便拉一个人，他能不能说清这个数字是什么意思
然后按产品类型给参考，比如协作工具是”每周有 3 个以上成员在贡献的活跃团队数”，市场平台是”每周完成交易数”。这些参考不是让你照抄，是让你理解什么叫”最能捕捉核心价值的单一指标”。
第二步是展开 L1 健康指标，覆盖用户生命周期的六个阶段：
-
获取：新用户从哪来，转化率怎么样 -
激活：新用户有没有体验到核心价值 -
参与：活跃用户在干什么，频次和深度如何 -
留存：用户会回来吗，D1 / D7 / D30 的留存曲线长什么样 -
变现：价值有没有转化为收入，MRR、ARPU 的趋势 -
满意度：用户感受如何，NPS、CSAT 怎么走
每个阶段 Skill 会列出 4-5 个典型指标和它们的测量重点。这一步的难点不是选指标，是忍住不要全选。SKILL.md 明确建议 L1 指标控制在 5-7 个，多了看板就废了。
第三步是设定目标。Skill 用的是 OKR 框架，但比市面上大多数 OKR 模板多了一层：目标基线分析。你要先回答四个问题：
-
当前的基线值是多少 -
行业对标水平如何 -
现有趋势的斜率是向上还是向下 -
你准备投入多少资源去推这个指标
然后才能定出”承诺目标”和”挑战目标”。
关键设计
这个 Skill 最聪明的地方，不在于它列了多少指标。在于它对”什么不应该是指标”有明确态度。
最典型的是仪表板设计反模式章节。它列了六类常见错误，每一条都是真实团队反复踩过的坑：
-
虚荣指标：总注册数永远在涨，但跟产品健康没有任何关系 -
信息过载：看板需要滚动才能看完，等于没人看 -
裸数字：只展示当前值，没有对比基线，没有趋势，无法判断好坏 -
产出替代结果：用”关了多少 ticket”替代”用户留存有没有变化” -
一张看板试图服务所有人：高管、PM、工程师需要的信息根本不同 -
看板半年不更新：放在那里没人维护，渐渐变成摆设
这些不是什么新发现，但从一个官方 Skill 里系统性地列出来，等于帮 PM 省掉了”自己踩一遍再总结”的时间。
另一个值得关注的设计是三层警报体系。阈值警报管突变，趋势警报管持续下滑，异常警报管偏离预期。三条线的核心逻辑是”只对你能行动的事设警报”，这个约束直接把 90% 的无效告警拦在外面。
但框架本身有一个明显的局限：它假设产品已经有可追踪的数据基础设施。对于一个连埋点都没做好的早期产品，这套方法论落地时会卡在”我需要定义激活率，但根本没办法追踪用户行为”这一步。Skill 没有给出这个阶段的替代方案。这不是设计缺陷，是它的定位决定了它解决的是”有数据之后怎么用”的问题，不是”没有数据怎么建”的问题。
使用场景
最匹配的场景是 SaaS 产品从 PMF 到规模化之间的阶段，创始人兼产品负责人的角色最需要这套框架。
一个典型的用法是定期指标复盘。Skill 定义了三种节奏：每周 15-30 分钟的快速检查、每月 30-60 分钟的深度趋势分析、每季度 60-90 分钟的战略复盘。每周看北极星指标的周环比和异常信号，每月看 L1 指标的月趋势和队列表现，每季度做 OKR 打分和年度对比。这种分层复盘节奏的设定，是我在这个 Skill 里看到的最务实的设计之一。
另一个高价值的场景是新功能上线后的效果评估。大多数 PM 的做法是拉个留存曲线、算个使用率，然后写”功能上线后 DAU 提升 3%”。但这个 Skill 会逼你先回答：这个功能的成功衡量标准应该挂到哪个 L1 指标上？如果是留存类指标，只看 D7 够不够，要不要盯 D30？如果是激活类，新用户的激活率有没有和上线前做队列对比？功能级别的数据很容易被孤立解读，这套框架的作用就是把功能数据嵌回到产品健康的全局视角里。
不过在产品极度早期的探索阶段，这套框架用起来会很吃力。不是因为框架不好，是因为这个阶段的核心任务不是追踪指标，是找到 PMF。北极星还没找到，你想定义北极星指标本身就是伪命题。
洞察与反思
读完整个 SKILL.md，最强烈的感受是：这看起来不像一个”AI Skill”，更像一份写得还不错的产品方法论文档，被塞进了 Agent 的对话系统里。
这恰恰是 Agent Skills 生态里一个值得注意的方向。大部分 Skill 在强调”我能替你做 X”，metrics-tracking 强调的却是”我来帮你把 X 想清楚”。前者的价值依赖执行效率，后者的价值依赖认知框架的质量。执行类 Skill 的护城河很浅，竞品抄一个功能只需要几周，但认知框架的质量是靠多年的行业积累堆出来的。
Anthropic 把这类方法论 Skill 放在 knowledge-work-plugins 套件里不是偶然。它在试一个方向：AI 不只是替代执行，也可以做认知杠杆。一个 PM 跟这个 Skill 对话 20 分钟，未必能直接产出什么文件，但脑子里的指标框架如果因此重构了一次，那价值比自动生成十份周报大得多。
当然，这套框架的适用边界也很清晰。它假设组织有数据基础、团队有分析能力、决策可以靠数据驱动。对很多处于野蛮生长期的产品来说，决定生死的是增长速度，不是指标健康度。在这种场景下，北极星指标的”引领性”和”可行动性”会被”先活下来”这个压倒性的需求压缩到几乎没有讨论空间。这不是批评，是承认认知框架不可能解决所有阶段的问题。
资源地址
| 资源 | 地址 |
|---|---|
| Smithery | https://smithery.ai/skills/anthropics/metrics-tracking |
| GitHub | https://github.com/anthropics/knowledge-work-plugins |
总结
回头再看这个 Skill 的价值，它没有发明任何新的产品方法论。北极星指标的概念来自 Sean Ellis，OKR 是 Intel 时代的东西，分层指标体系是 Growth 团队的共识。但它把散落在各处的知识点压缩成了一套结构化的对话流程，让你不用翻五本书就能在 20 分钟里完成一次完整的指标审计。
这件事本身不大，但它指了一个方向：Agent Skills 的价值可以不在”替你干活”，而在”帮你理清楚该怎么想”。如果你是一个正在纠结”到底该看哪些数据”的 PM，花半小时跑一遍这个 Skill 的流程，比再加一个 BI 看板值得多。
如果你还在找 PMF，这个框架可以先收藏。如果产品已经跑起来了但数据看板全靠直觉搭的，那今晚就用。