如果你看到不熟悉的占位符或需要检查已连接的工具，请参阅 CONNECTORS.md。
在与利益相关者分享前审查分析的准确性、方法论和潜在偏差。生成置信度评估和改进建议。
/validate-data <待审查的分析>分析可以是：
检查：
执行下面的清单——数据质量、计算、合理性和呈现检查。
对照下面的详细陷阱目录进行系统审查（连接爆炸、幸存者偏差、不完整期间比较、分母变化、平均值的平均、时区不匹配、选择偏差）。
尽可能进行抽查：
应用下面的结果合理性检查技术（量级检查、交叉验证、红旗检测）。
如果分析包含图表：
审查是否：
提供具体、可操作的建议：
使用三级评分标准评估分析：
准备好分享——分析方法合理，计算已验证，注意事项已注明。有小的改进建议但不构成障碍。
可分享但需注明注意事项——分析基本正确，但有特定的限制或假设必须传达给利益相关者。列出所需的注意事项。
需要修订——发现具体的错误、方法论问题或缺失的分析，应在分享前解决。按优先级顺序列出所需的更改。
## 验证报告
### 总体评估：[准备好分享 | 可分享但需注明注意事项 | 需要修订]
### 方法论审查
[关于方法、数据选择、定义的发现]
### 发现的问题
1. [严重程度：高/中/低] [问题描述和影响]
2. ...
### 计算抽查
- [指标]：[已验证 / 发现差异]
- ...
### 可视化审查
[图表或视觉呈现方面的任何问题]
### 建议改进
1. [改进建议及其重要性]
2. ...
### 需要告知利益相关者的注意事项
- [必须传达的注意事项]
- ...在与利益相关者分享任何分析之前，执行此检查清单。
问题：多对多连接悄无声息地使行数倍增，膨胀了计数和总和。
如何检测：
-- 检查连接前后的行数
SELECT COUNT(*) FROM table_a; -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id; -- 3,500（糟糕）如何预防：
COUNT(DISTINCT a.id) 而非
COUNT(*)问题：只分析今天存在的实体，忽略了那些已被删除、流失或失败的实体。
示例：
如何预防：在得出结论前问"谁不在这个数据集中？"
问题：将不完整的期间与完整的期间进行比较。
示例：
如何预防：始终筛选到完整的期间，或比较同月同日/相同天数。
问题：分母在不同期间之间发生变化，使比率无法比较。
示例：
如何预防：在所有比较期间使用一致的定义。标注任何定义的变化。
问题：对预先计算的平均值再取平均，当组大小不同时结果错误。
示例：
如何预防：始终从原始数据聚合。永远不要对预聚合的平均值再取平均。
问题：不同的数据源使用不同的时区，导致不对齐。
示例：
如何预防：在分析前将所有时间戳标准化为单一时间区（推荐 UTC）。记录使用的时区。
问题：细分由你正在衡量的结果定义，造成循环逻辑。
示例：
如何预防：基于处理前的特征而非结果定义细分。
对于分析中的任何关键数字，验证其通过"嗅觉测试"：
| 指标类型 | 合理性检查 |
|---|---|
| 用户数量 | 是否与已知的 MAU/DAU 数据匹配？ |
| 收入 | 数量级是否与已知的 ARR 相符？ |
| 转化率 | 是否在 0% 到 100% 之间？是否与仪表盘数据匹配？ |
| 增长率 | 50%+ 的月环比增长是否现实，还是数据有问题？ |
| 平均值 | 鉴于你对分布的了解，平均值是否合理？ |
| 百分比 | 各细分百分比合计是否约为 100%？ |
每个非平凡的分析都应包含：
## 分析：[标题]
### 问题
[正在回答的具体问题]
### 数据来源
- 表：[schema.table_name]（截至 [日期]）
- 表：[schema.other_table]（截至 [日期]）
- 文件：[文件名]（来源：[来自哪里]）
### 定义
- [指标 A]：[精确计算方式]
- [细分 X]：[成员资格的精确判定方式]
- [时间段]：[起始日期] 至 [结束日期]，[时区]
### 方法论
1. [分析方法的步骤 1]
2. [步骤 2]
3. [步骤 3]
### 假设和限制
- [假设 1 及其合理的原因]
- [限制 1 及其对结论的潜在影响]
### 关键发现
1. [发现 1 及其支持证据]
2. [发现 2 及其支持证据]
### SQL 查询
[所有使用的查询，带注释]
### 注意事项
- [读者在据此采取行动前应了解的事项]对于可能被复用的任何代码（SQL、Python）：
"""
分析：月度群组留存
作者：[姓名]
日期：[日期]
数据来源：events 表、users 表
最后验证：[日期]——结果与仪表盘匹配度在 2% 以内
目的：
基于首次活动日期计算月度用户留存群组。
假设：
- "活跃"意味着该月至少有一次事件
- 排除测试/内部账户（user_type != 'internal'）
- 全程使用 UTC 日期
输出：
群组留存矩阵，行为 cohort_month，列为 months_since_signup。
值为留存率（0-100%）。
"""/validate-data 在我发送给高管团队之前审查这份季度收入分析：[分析内容]/validate-data 检查我的流失分析——我在比较 Q4 和 Q3 的流失率，但 Q4 的测量窗口更短/validate-data 这是我们转化漏斗的 SQL 查询及其结果。逻辑看起来正确吗？[查询 + 结果]