简诗 Lens 业务指标定义引擎

这个技能解决什么问题

团队里最常见的指标事故，不是算错了数，而是定义含糊。同一份报表里，"DAU"可能指登录用户，也可能指触发过事件的设备；转化率的分子分母口径不一致，会导致两个部门对着同一个数吵架。更糟的情况是，花两周做出一张仪表盘，最后没人知道这个数字该触发什么动作。

Lens 要处理的就是这类问题：把"我们想关注一个指标"变成"这里有一份可以进代码库的指标定义和 SQL"。它不写分析策略备忘录，只产出工程团队今天就能拿去实现的东西。

它如何工作

Lens 的角色设定是数据分析与 BI 工程师，执行流程分七步：

• Step 0 环境探测：扫描工作区里的数据基础设施，包括数据库配置（PostgreSQL、BigQuery、Snowflake、ClickHouse、DuckDB）、ORM 与迁移文件、已有 SQL view 和 dbt_project.yml 指标层、Mixpanel/Amplitude/PostHog/GA4 配置、已有的指标字典或埋点文档。
• Step 1 "So What?" 审计：在定义任何指标之前，先回答四个问题——它支撑什么决策？翻倍了你会做什么？腰斩了你会做什么？它是领先指标还是滞后指标？如果诚实的答案只是"挺有意思"，这个指标就会被砍掉。
• Step 2 定义北极星指标：用固定格式写出唯一那个最能代表产品是否给用户创造价值的指标。
• Step 3 定义支撑 KPI：最多 3–5 个，解释北极星为什么动，覆盖获客、活跃、留存、变现、质量五类。
• Step 4 为每个指标写 SQL：生产级质量——注释头写明业务定义、用 CTE 而不是嵌套子查询、日期范围参数化、显式处理 NULL 和除零。
• Step 5 事件埋点规范：如果工作区里有产品分析工具，为需要埋点的指标补上 tracking spec。
• Step 6 创建 SQL View：每个指标落一个 view 文件，任何 BI 工具都能直接查。
• Step 7 交付指标规范文档：遵循 docs/output-kit.md 定义的格式。

适用边界与注意点

• 输出受 40 行 CLI 预算限制，超出部分会触发 /atlas-report，完整结果在 HTML 报告里，CLI 只留一行结论和报告路径——不要指望把完整分析直接 dump 到终端。
• 它依赖工作区里已有的数据基础设施。如果数据库配置、dbt 项目或埋点工具一个都没有，产出的更接近规范草案，SQL 需要自己按方言调整。
• SQL 方言以 Step 0 探测到的引擎为准，跨库迁移时仍需人工校验。
• 指标质量的上限取决于 Step 1 审计的诚实度：如果团队对每个指标都只能说"先看看"，这个流程救不了它。