你想测一个新功能，Slack 里三个人正在吵怎么测。停一下。代码 ship 之前你得有一页纸——讲清楚到底测什么、什么时候停、什么样的结果你认。AI 写这种一页纸初稿很顺手，前提是输入到位。
这个任务
输出一页 A/B 实验方案：假设、主指标、护栏指标、MDE、样本量校验、灰度计划、停止条件。
什么时候适合让 AI 做
- 功能改动和大致受众已经定了。
- 主指标有现成基线（当前转化率、D7 等）。
- 能用大白话说出 2-3 条护栏。
- 想先做一次”这个实验值不值得跑”的硬筛。
- 不是让 AI 当统计软件——它出方案，统计引擎跑数。
要给 AI 喂什么
- 一句话说清功能改动（“onboarding 第 3 步新增 goal-picker”）
- 主指标和当前基线（“D7 留存，目前 22%”）
- 2-3 条护栏（“崩溃率、人均周内付费、首日卸载率”）
- 日流量（“iOS 端每日新增 1.2 万”）
- 你的最小可检测效应；没想好就让它给个 sanity 区间
- 决策窗口与产品日历（“21 天内必须出结论，第 25 天市场要 launch”）
可直接复制的 Prompt
You are a senior product analyst writing a one-page A/B test plan.
Feature change: a new onboarding step 3 that asks users to pick a goal (sleep, focus, anxiety) before reaching the home screen. Current onboarding has no goal-picker.
Primary metric: D7 retention. Baseline: 22% on iOS.
Guardrails:
- Crash-free session rate (must not drop more than 0.2 pp)
- IAP revenue per new install in week 1 (must not drop more than 5%)
- Day-1 uninstall rate (must not rise more than 1 pp)
Audience: new iOS installs only. 12,000 new installs per day.
Decision window: 21 days max. Marketing launch on day 25, so we cannot extend.
Write the plan in this exact structure:
1. Hypothesis (one sentence, falsifiable). Form: "If we add X, then primary metric Y will move by Z, because mechanism W."
2. Primary metric definition. Include: what counts as a D7-retained user (returning session on calendar day 7 in user-local time, not server UTC). Mention the most likely measurement bug.
3. MDE check. Given baseline 22% and 21-day window with 12k installs/day, what is the smallest effect we can reliably detect at 80% power? Show the math (or estimate).
4. Guardrail thresholds and what we would do if each one trips. Each guardrail gets one sentence: trigger and action.
5. Ramp plan: day 1-3 at 10/10/80 (control/treat/holdout), day 4+ at 50/50 if no guardrail trips. Name the specific check to run before each ramp step.
6. Stop conditions: when do we kill, when do we extend, when do we ship.
7. The one thing this experiment will NOT answer (so we do not over-claim later).
Rules:
- No "consider" language. Each section makes a call.
- No invented numbers. If you need a number I did not give you, mark it [need from analytics].
- If the MDE is bigger than 1.5 pp, say "this experiment is likely underpowered" out loud.
- Max one page.示例输出
假设。 在 onboarding 第 3 步加入 goal-picker 后，D7 留存将从 22% 升至至少 24.5%——因为用户在第一次会话里自主锚定了一个返回理由。
主指标。 D7 留存 = 用户本地时区下第 7 天的回访会话。最易出 bug 的地方：服务端 UTC 切日会让亚太用户低估约 3 pp。上线前确认埋点用的是 install-local day。
MDE 校验。 基线 22%、21 天窗口、日新增 1.2 万，总样本约 25.2 万，按 50/50 分组每边 12.6 万。80% power、alpha 0.05 下 MDE ≈ 0.8 pp。目标提升 2.5 pp 远高于 MDE，本实验功效足够。[need from analytics: 真实 day-7 子样本量，holdout + 慢留存会削减可用 n]。
护栏。 崩溃率低于 99.6% → 暂停排查。周内付费/新增下降 5% 以上（day 3 即触发）→ 暂停，怀疑 goal-picker 在抢付费路径。首日卸载率 +1 pp 以上 → 直接 kill。
灰度。 Day 1-3 跑 10/10/80（control/treat/holdout）确认埋点和护栏。Day 4 在崩溃率与卸载率全绿后切到 50/50。Day 14 做一次中期 check。
停止。 Day 14 时 D7 提升 1.5 pp 以上且 p 小于 0.05 → ship。任意护栏触发 → kill。延期不可选（市场 day 25 锁定）。
不回答。 本实验不告诉你 goal-picker 是否能改善 W4 留存或 LTV。需要在第 4 周单独跑一次 cohort readout。
怎么继续打磨
- 假设太虚（“提升参与度”）—— 硬规则：“一句话写出机制”。
- 跳过 MDE —— 强制”给出 MDE 数学或估算，underpowered 时明说”。
- 护栏只是摆设 —— 每条都要有数值触发器和一个动词。
- 灰度计划没有 check —— 必须写”每一步切量前要看什么”。
- AI 编流量数字 —— 反复重申”未提供的数字标 [need from analytics]“。
容易踩的坑
- 功能 ship 完了才设计实验——这时你已经没法说 no。
- 21 天的实验挑了个季度级才会动的指标（LTV）。
- 五条护栏——假阳性概率叠加。三条够了。
- 没有停止条件。“等我心里有底再停”的实验永远停不下来。
FAQ
Q：实验跑了一半发现样本量估错了，要不要停？ A：不要停。停掉等于先看结果再决定，自己破坏了显著性。先记录”样本量重算”这件事，按原计划跑完；下一次同类实验把这次的 baseline 修正再算。
Q：主指标没显著但护栏也没动，算成功还是失败？ A：算”未证伪”，不算成功。把功能下线或留小流量长跑，不要全量。直接全量等于把”无害”当”有效”，会污染下一次实验基线。
Q：实验期间产品做了别的改动怎么办？ A：实验作废。同一时间窗只能有一个变量。下次让 AI 在方案里加一条”冻结期清单”——哪些模块这 21 天禁止改。
Q：AI 写的样本量校验靠谱吗？ A：作为 sanity check 可以，作为决策依据不行。让 AI 给区间，再用公司内部的样本量计算器或 statsig/optimizely 复核一次。
相关
- AI A/B 实验总结
- AI 实验解读
- AI 留存 Cohort 解读
- AI 功能优先级
- AI 漏斗分析解读
- AI App Store ASO 关键词调研：不靠拍脑袋
- AI Crash 上报三角分类：从堆栈到负责人一次到位
标签: #AI 写作 #app-experiment #ab-testing #app-product-ops #独立开发