埋点与分析现状盘点

团队数据工具的腐烂很少是戏剧性的：今天加一个 Mixpanel 事件，下周补一个 Grafana 面板，再过两个月，没人说得清活跃用户到底按什么口径计算。到想接入新指标或做归因分析时，埋点散落在前端代码和多个 SaaS 工具里，看板由不同时期的三个人搭建，口径定义只写在某个人的脑子里。

它解决什么问题

在开始任何新分析之前，先搞清楚已经有哪些数据资产可用。Lens 扫描整个工作区，把 analytics-related 的东西——SDK 初始化、SQL 目录、BI 配置、定时任务——整理成一份可读的现状盘点。产出的目的不是漂亮的报告，而是让你在做分析前知道：数据在哪、口径是什么、能不能直接用。

核心能力与工作流程

工作分四步，每一步都只做事实记录，不做产品宣传。

第一步是环境探测。扫描 docker-compose.yml 中的 Metabase / Grafana / Superset / ClickHouse 等组件，识别 Looker 的 *.lkml、dbt 的 dbt_project.yml、Evidence 的配置文件，同时检查 Mixpanel、Amplitude、PostHog、GA4 等客户端埋点的初始化和 track() 调用。

第二步是埋点盘点。逐项记录：哪些事件被采集、事件附带什么属性、有没有服务端追踪、接入了哪些第三方数据源、基础设施指标（CPU、延迟、错误率）走的是什么链路。

第三步是看板盘点。盘清所有 Dashboard 所在的工具、最后更新时间、负责人、定时报表发送给了谁、告警的触发条件和阈值。

第四步是质量评估。针对每件分析产物，检查五个问题：指标有没有明确定义、数据是否还在流动、看板最后修改时间是什么时候、刷新和告警是自动还是手工、分析权限是自助还是集中在某个人手里。

交付方式与适用边界

发现以 40 行 CLI 为上限呈现：box-drawing 骨架、统一的严重程度标记、压缩过的发现摘要。超出这个预算的完整分析会生成 HTML 报告，CLI 只保留结论摘要和报告路径。

适合的场景是接手一个分析基础设施不透明的工作区，或者在做新数据接入前做一次 baseline 盘点。需要清楚的是：它只负责把现状摊开——哪些在监控、哪些没人管、哪个指标没有定义——不会自动修管道、不会替你重建看板，也不预设什么指标必须存在。