exp-design：实验设计选择框架

目标：不堆公式，给出"最小可用"的实验设计决策树——小白照着走，能选出不犯大错的设计。 核心纪律：设计错了，后面算得再精确都是错的。先选对设计，再谈样本量。

1. 何时使用

• 有"改了 X，能不能提升 Y"的问题，但不知道该用什么实验方法 → 用本 skill 选设计
• 实验方案评审：判断别人的设计有没有结构性硬伤
• 随机分流做不了时：找准实验替代方案，而不是硬上 A/B

2. 输入与输出

输入：一句话研究问题 + 三个澄清答案（干预是什么 / 指标是什么 / 最小有意义的变化是多少）。 输出：设计选择（五选一）+ 选择理由 + plan.json 初稿（含对照、随机化、指标、分流、时长字段）。

3. 分步方法论

3.1 第一步：把问题写成可证伪假设

格式：「干预 X 使指标 Y 变化 ≥Z%」

• X 必须是一个具体动作（"把按钮变绿"，不是"优化首页"）
• Y 必须可测量（点击率，不是"用户体验"）
• Z 必须有数字（"相对提升 20%"，不是"显著提升"）

Z 定不下来时用最小业务价值法：开发成本 ÷ 单用户价值 = 盈亏平衡的提升幅度。 低于这个幅度的提升，实验做出来也没意义——先算账，再开实验。

3.2 第二步：走决策树（最小可用版）

能随机分流吗？
├─ 能 → 有几个因素要同时测？
│ ├─ 1 个 → ：对照组 + 实验组，随机分流
│ └─ ≥2 个，想看交互 → ：2×2 起，注意样本量×4 起跳
└─ 不能 → 有干预前后的数据吗？
├─ 有，且有"没干预"的对照组 →
├─ 有，且干预按某个阈值触发 →
├─ 有，但干预组和对照组本来就不一样 →
└─ 没有 → 先埋点攒数据，别做实验

用户差异特别大（如 B 端客户）？
└─ 在随机基础上加：先按关键特征分层，层内再随机

3.3 第三步：五种设计的一句话适用条件

3.4 第四步：设计的四个必备件（写进 plan.json）

1. 对照：没有对照组的"实验"叫观察。特殊情况（全量上线无法对照）必须用准实验方法补救，不能直接对比上线前后。
2. 随机化方式：写明分流键（用户 id 哈希 / 设备 id）与分流层级（用户/请求/页面）。按时间切、按地域切都不是随机，要声明并说明混杂控制。
3. 主要指标（1~2 个）：开跑前锁定。指标多=假阳性多，次要指标可以看，但决策只看主要的。
4. 停止规则：事先写好"跑满 X 天或达到 N 样本"，中途不许改。改停止规则=作弊。

3.5 第五步：准实验的诚实声明

准实验（DID/断点/匹配）本质上是在"补救"不能随机的缺陷，报告里必须写清：

• 用了什么方法、控制了哪些混杂
• 关键假设是否成立（如 DID 的"平行趋势"：画两条线给用户看）
• 结论强度降一档：不说"证明"，说"证据支持"

4. 随机化实操（线上实验最容易翻车的地方）

1. 分流键选择：登录态产品用用户 id；未登录用设备 id / cookie。分流层级一旦选定（如用户），整个实验期间不许变。
2. 哈希分流：hash(分流键 + 实验盐) % 100。实验盐每个实验独立——同一个用户在不同实验中应被独立分流，避免实验间串扰。
3. 粘性分桶：用户一旦分到某组，整个实验期间不变。按请求分流（如每次刷新重新随机）会让同一用户体验两种版本，数据全废。
4. SRM 检查：开跑 24 小时内，对照组:实验组的人数比做卡方检验。比例显著偏离预期（如 1:1 跑成 6:4）→ 分流代码有 bug，停实验修 bug，不要"将错就错"。
5. 互斥与正交：同时跑多个实验时，流量层要互斥（同一层内实验互斥）或正交（不同层独立分流）。两个实验抢同一批用户还互相不知情，结果没法归因。
6. 新奇效应与学习期：新功能上线前 2~3 天，用户因好奇点击偏高。判定用"稳定期"数据，或把前 3 天单独标注。

5. 反模式（这些设计一律打回）

1. 无对照前后对比："上线后转化率涨了"——可能是大盘涨了、季节到了、运营做了活动。没有对照，一切免谈。
2. 边跑边看显著了就停：中途看 5 次 p 值，假阳性率从 5% 膨胀到 14% 以上。这是最常见的 p-hacking。
3. 指标篮子：一次看 20 个指标，挑显著的报。不校正的多重比较等于保证出假阳性。
4. 分层变量拍脑袋：分层随机按"感觉"分层，分层变量与指标无关时纯属添乱，还损失自由度。
5. 样本量按流量倒推："我们每天就 500 流量，跑 3 天吧"——先算需要多少，再看流量够不够，不够就换指标或放弃。
6. 准实验不做平行趋势检查：DID 不看干预前两组趋势是否一致，等于闭眼开车。
7. 多实验抢流量不声明：两个实验同时跑、流量层既不互斥也不正交，最后谁的效果都说不清——实验排期表是必需品。

5. 样本量直觉表（开实验前的数量级感觉）

功效 80%、α=0.05 双侧、两组比例比较，每组大约需要：

读法：基准越低、想检出的提升越小，样本量越大。拿到这个表先问自己： 流量够吗？不够 → 三条路：① 换更高频的指标（如用点击率代替转化率）； ② 接受更大的 MDE（只测大变化）；③ 放弃实验，别做"注定检不出"的实验。 精确数字一律用 power_calc.py 算，表只给直觉。

6. 常见场景速查

• 落地页/按钮文案测试：随机对照 + 主要指标 1 个（点击率/转化率）+ 7 天。注意新奇效应，前 2 天数据只看不判。
• 定价测试：B 端慎用随机（客户会互相打听价格）；C 端可用，但要声明价格歧视的合规风险。不能随机时用 DID：先对部分地区调价。
• 邮件/推送标题测试：随机对照的经典场景，分流键=用户 id，注意打开率指标的延迟（至少等 48 小时再看）。
• 推荐算法策略测试：分流层级选"用户"而非"请求"（同一用户看到两种策略会串扰）；警惕网络效应（社交产品中对照组会被实验组影响）。
• B 端功能灰度：客户数少（n<100）时随机对照功效极低，改用"配对设计"（相似客户配对、一对中随机）或直接做可用性测试，别硬套 A/B。
• 运营活动效果复盘：活动已上线无法随机 → 准实验：找没参加活动的相似用户做对照（倾向得分匹配），或对比活动前后趋势（DID），结论降一档表述。

7. 自检与反馈

质检门（设计评审前逐项打勾）：

• [] 假设写成了"干预 X 使指标 Y 变化 ≥Z%"格式
• [] 设计类型在决策树上有明确落点，排除了其他选项的理由写了一句话
• [] 对照组存在且可比（或准实验的补救方法已声明）
• [] 随机化方式/分流键已写明
• [] 主要指标 ≤2 个，开跑前锁定
• [] 停止规则已事先写好（时长/样本量）
• [] plan.json 已生成，字段齐全

标准冒烟用例：输入"按钮变绿能不能提升点击率"，期望输出：设计=随机对照（A/B），主要指标=点击率，plan.json 含 control=true、randomization、分流比、duration_days≥7。

分层变量选择三问（用分层随机前先回答）：① 这个变量和指标强相关吗（历史数据验证过）？② 分层后每层样本还够吗（层数×2 组，每组都要满足功效）？③ 分层变量在分流时就能拿到吗（实验后再知道的变量不能用来分层）？三问任一答"否"就别分层。

一键提 issue：设计决策树走不通的场景，以 [design] <一句话场景> 为标题提交到 https://github.com/lhg-plugs/lhg-experiment/issues，正文写"场景 → 决策树卡在哪 → 期望的指引"。

出品：刘洪光

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

• GitHub 主页：https://github.com/lhg-skills —— 全部 skill 开源在此，欢迎 star
• 抖音：搜「刘老师讲AI实战」
• 微信：lhgsmsw
• 反馈：skill 用法问题提 issue 时请附上你的 plan.json（脱敏后）