result-read：实验结果解读

目标：拿到实验数据后，给出"不骗自己"的解读——显著性、效应量、置信区间、业务意义四步走完才下结论。 核心纪律：p 值只回答"是不是噪音"，不回答"值不值得做"。只报 p 值的解读一律打回。

1. 何时使用

• 实验跑完了，手里有数据，要出结论 → 用本 skill 走四步解读
• 评审别人的实验报告：结论站不站得住、有没有 p-hacking 痕迹
• 写实验复盘/汇报：按本 skill 的报告模板写，局限性必须如实声明

2. 输入与输出

输入：实验数据（各组样本量、指标均值/比例、p 值）+ 当初的 plan.json。 输出：四步解读结论 + 局限声明 + 决策建议（全量 / 灰度 / 放弃 / 重做）。

3. 分步方法论：四步解读法

第一步：看显著性——"这是不是噪音？"

p<0.05 意味着：如果干预真的没效果，看到这么大差异的概率不到 5%。 它只能排除噪音，不能证明效果大、不能证明值得做。

• p<0.05：差异不太可能是噪音，进入第二步。
• p≥0.05：不显著 ≠ 没效果，只说明"当前证据不足以排除噪音"。 可能原因：样本不够（看功效）、效应真的小（看 MDE）、方向反了。 结论写"证据不足"，不写"证明无效"。

第二步：看效应量——"效果有多大？"

这是最关键的一步，也是最常被跳过的一步。

• 比例型：报告绝对提升（+1.0 个百分点）和相对提升（+20%）两个数字。 只报相对提升是耍流氓：从 0.1% 提升到 0.2% 也是"相对提升 100%"。
• 均值型：报告 Cohen's d（0.2 小、0.5 中、0.8 大是惯例参照）。
• 判断标准：效应量是否 ≥ 当初 plan 里定的 Z（最小业务价值）？ 达到了 → 值得往下看；没达到 → 即使显著也不值得做。

第三步：看置信区间——"效果的可能范围？"

95% 置信区间告诉你：真实效果最可能落在哪。

• 区间下限 > 0 且 > 最小业务价值 → 稳的，可以决策。
• 区间很宽（如 [-5%, +25%]）→ 样本还不够，结论是"方向对但精度不够"，别急着全量。
• 区间包含 0 → 和第一步的"不显著"是一回事，换个说法而已。

一句话记忆：p 值是"是不是"，效应量是"多少"，置信区间是"多准"。 三个都要，才能下结论。

第四步：谈业务意义——"换算成钱和用户"

把统计数字翻译成业务语言：

• 相对提升 20% 的点击率 × 当前日活 = 每天多多少点击
• 换算成年化增量，对比开发/运营成本
• 写清楚：这个结论的适用边界（只在新用户上显著？只在 iOS 上显著？）

统计显著但业务无意义是最常见的"正确但无用"的结论： n=10 万时，0.1% 的提升也能 p<0.05，但可能连服务器成本都覆盖不了。 这时诚实的结论是"差异真实存在，但不值得做"。

4. 六种常见误读（p-hacking 识别手册）

误读 1：边跑边看，显著了就停（peeking）

症状：实验计划跑 14 天，第 5 天 p<0.05 就停了、发了喜报。 危害：中途看 5 次，假阳性率从 5% 膨胀到 14%+；看 10 次膨胀到 20%+。 防范：停止规则写在 plan 里并严格执行；实验平台关闭"实时 p 值"显示，只显示样本量进度。

误读 2：指标篮子（多重比较不校正）

症状：看了 20 个指标，3 个显著，报告只写这 3 个。 危害：看 20 个指标，至少 1 个假阳性的概率是 64%。 防范：主要指标开跑前锁定（≤2 个）；次要指标用 Holm/Bonferroni 校正； 探索性发现标注"待验证"，不直接当结论。

误读 3：事后分组挖掘（subgroup fishing）

症状："总体不显著，但新用户分组显著！"——分组是看到数据后才分的。 危害：切 10 个人群，总有一个"显著"，这是必然不是发现。 防范：分组分析必须在设计阶段预先声明；事后发现的分组标"探索性"，必须另起实验验证。

误读 4：p 值拜物教

症状：报告只有 p=0.043 和"显著"两个字，没有效应量、没有置信区间。 危害：p=0.043 是最不可靠的区间——换个随机种子就可能翻转。 防范：本插件审计规则 EXP-RSLT-001 直接拦截：有 p 值无效应量 = blocker。

误读 5：把"不显著"说成"没效果"

症状："p=0.3，证明新方案没用，维持现状。" 危害：可能是样本不够（功效 40% 的实验，p=0.3 太正常了）。 防范：不显著时看两件事：① 当初的功效够不够；② 置信区间——如果区间是 [-1%, +15%]， 真实效果可能是 +15%，只是没检出来。结论写"证据不足"，并给出"要检出需要多少样本"。

误读 6：辛普森悖论（汇总与分组结论打架）

症状：总体看实验组赢，分新老用户看两组都输（或反过来）。 危害：按汇总结论全量，可能对所有人都是错的。 防范：实验组和对照组的用户构成必须一致（SRM 检查 partly 覆盖）； 重要分层（新老用户、平台）常规性地看一下分组结果，方向不一致时先别全量。

5. 报告模板

# <实验名>结果报告（日期）

## 数据表
| 组 | 样本量 | 主要指标 | 次要指标... |
|---|---|---|---|
| 对照组 | n= | x% | ... |
| 实验组 | n= | y% | ... |

## 四步解读
1. 显著性：p=0.0xx，差异（是/否）可能是噪音
2. 效应量：绝对提升 +x 个百分点，相对提升 +y%（Cohen's d=z）
3. 置信区间：差值的 95% CI 为 [a%, b%]
4. 业务意义：换算成年化增量约 N，（是否）覆盖成本

## 方法学声明
- 停止规则：按计划跑满（是/否，中途查看次数）
- 多重比较：主要指标 x 个，校正方法（Holm/无）
- 分组分析：预先声明（是/否），事后发现标探索性

## 局限
- （如：只在新用户显著；iOS 样本不足；实验期间有大促干扰）

## 决策建议
全量 / 灰度扩大 / 放弃 / 重做（理由一句话）

底线：局限性不写 = 报告不合格。没有局限的实验报告，比有局限的更可疑。

6. 反模式

1. 喜报式解读：先定结论（"我们成功了"），再找数据支撑。解读必须从数据出发，plan 里的成功标准是事先定的。
2. 小数点后三位精确的错误："提升 0.043%"——样本噪声都比这大，报两位有效数字就够了，多的都是噪音。
3. 因果词滥用：准实验/观察性数据用"证明""导致"。证据强度配不上动词强度时，降级表述。
4. 选择性时间窗："看最近 7 天显著"——为什么是 7 天不是 14 天？时间窗必须在 plan 里事先定。
5. 忽略业务常识：数据说显著，但和业务常识严重冲突时（如按钮变绿转化率翻倍），先怀疑数据（埋点、分流 bug），再庆祝。

7. 自检与反馈

质检门（出解读结论前逐项打勾）：

• p 值、效应量（绝对+相对）、置信区间三个数字都报了
• 效应量 ≥ 当初 plan 定的最小业务价值（否则结论是"不值得做"）
• 多重比较已处理（主要指标锁定 / 校正方法声明）
• 分组结论标注了"确证性/探索性"
• 局限性写了至少一条
• 决策建议是四选一（全量/灰度/放弃/重做），不是"显著所以全量"

标准冒烟用例：用 fixtures/report-bad/result.md 跑审计，期望命中 EXP-RSLT-001~006； 用 fixtures/report-good/result.md 跑，期望零 blocker。

一键提 issue：遇到本手册没覆盖的误读模式，以 [read] <一句话描述> 为标题提交到 https://github.com/lhg-plugs/lhg-experiment/issues。

出品：刘洪光

本 skill 由真人出镜 IP「刘洪光」（安徽合肥）出品，归属 lhg-skills。

• GitHub 主页：https://github.com/lhg-skills —— 全部 skill 开源在此，欢迎 star
• 抖音：搜「刘老师讲AI实战」
• 微信：lhgsmsw