指标口径与看板分析诊断

它解决什么问题

分析资产通常是这样腐烂的：

• 看板越建越多，超过一个月没人打开的也越来越多
• 同一个指标在不同看板里口径不一致，「活跃用户」在 A 报表和 B 报表里是两个数
• 定时报告管道悄悄失败，数据停更了几周无人察觉
• 注册转化这类关键环节反而没有漏斗分析
• 指标没有书面定义，换个人看就理解成另一个意思

工作原理

核心能力是盘点 + 评估 + 判决，分四步加一条输出约束：

1. Step 0 扫描工作区内所有分析产物：docker-compose.yml 中的 BI 工具（Metabase、Grafana、Superset、Redash）、看板配置文件（Grafana JSON、Metabase 导出、Looker LookML）、analytics/、reports/、sql/ 目录下的 SQL、cron / Airflow DAG / GitHub Actions 定时任务、dbt_project.yml 模型、Streamlit / Dash 脚本、Mixpanel / Amplitude / PostHog / GA4 配置、Slack webhook。
2. Step 1 逐一登记看板与报告：名称、位置、展示的指标、最后修改时间（查 git log 或文件时间戳）、创建者（git blame）、调度频率。
3. Step 2 评估使用与价值：谁在看（有访问日志就看，否则从 Slack 提及和团队结构推断）、每个数字是否有精确定义、是否驱动决策还是仅供「看着不错」、数据是否新鲜、是否随产品演进维护。
4. Step 3 标记问题：30 天以上无访问的看板、无定义的指标、虚荣指标（如累计注册总数）、关键覆盖缺口、重复且口径不一的指标、静默失败的管道。
5. Step 4 输出审计结果，遵循 docs/output-kit.md 约定：CLI 最多 40 行，box-drawing 骨架、统一严重度标记、压缩行文。超出预算就调用 /atlas-report 生成 HTML 报告，CLI 只留一行结论、top 3 发现和报告路径。

适用边界与注意点

• 「谁在看」依赖访问日志；拿不到时只能推断，结论应注明置信度。
• 设计意图就是直言该杀什么——少而精的看板胜过多而荒废的看板，团队要有下线报告的心理准备。
• 只审计现有资产，不负责新建埋点、补写指标定义或修复管道本身。
• 输出格式绑定 docs/output-kit.md，接入其他工具链时需要适配。