你想测一个新功能，Slack 里三个人正吵着该怎么测。在你把 flag ship 出去之前，先要有一页纸——讲清楚到底测什么、什么时候停、什么样的结果你认。AI 几分钟就能写出一份不错的初稿，前提是你把基线、流量和决策窗口都喂给它。统计这部分它不会替你算，也不该替你算。
一句话总结
把功能改动、主指标基线、日流量和决策截止日给模型，让它按固定的 7 段结构产出方案：假设、指标定义、MDE 校验、护栏、灰度、停止条件、以及这次实验不回答什么。推理用 Claude Opus 4.7 或 GPT-5.5，真正的显著性检验交给 Statsig、GrowthBook 或公司内部的统计引擎跑。AI 出草稿，平台下结论。
产出什么
一页 A/B 实验规格：可证伪的假设、精确的主指标定义、最小可检测效应（MDE）的硬筛、2-3 条护栏指标、灰度计划、以及明确的停止条件。
什么时候适合让 AI 做
- 功能改动和大致受众已经定了。
- 主指标有现成基线（当前转化率、当前 D7 等）。
- 能用大白话说出 2-3 条护栏。
- 在烧掉三周流量之前，想先做一次”这实验值不值得跑”的快速硬筛。
- 不是让 AI 跑统计。它出方案，你的实验平台算显著性。
要给模型喂什么
| 输入 | 例子 |
|---|---|
| 功能改动（一句话） | “onboarding 第 3 步新增 goal-picker” |
| 主指标 + 基线 | ”D7 留存，iOS 端目前 22%“ |
| 护栏（2-3 条） | “崩溃率、人均付费、首日卸载率” |
| 日流量 | ”iOS 端每日新增 1.2 万” |
| MDE（或让它给区间） | “值得 ship 的最小提升：2 pp” |
| 决策窗口 + 日历 | ”21 天内必须出结论，第 25 天市场要 launch” |
用哪个模型
三家前沿模型（截至 2026 年 6 月）做这件事都够用，因为它本质是对你给的数字做结构化推理，不是重计算，差距很小：
| 模型 | API 价格（每百万 token 输入/输出） | 在这件事上为什么选它 |
|---|---|---|
| Claude Opus 4.7 | $5 / $25 | 7 段结构守得最严；被要求别编数字时最听话 |
| GPT-5.5 | $5 / $30 | 输出最省 token；MDE 算术算得稳 |
| Gemini 3.1 Pro | $2 / $12 | 最便宜，1M token 上下文，方便你直接贴长指标导出 |
一页方案的成本差只有几分钱，所以你已经在付哪个就用哪个：Claude Pro（每月 $20）、ChatGPT Plus（每月 $20）或 Google AI Pro（每月 $19.99）。
可直接复制的 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 a 21-day window with 12k installs/day,
what is the smallest effect we can reliably detect at 80% power, alpha 0.05?
Show the arithmetic (or a clear estimate).
4. Guardrail thresholds and the action if each trips. One sentence each:
numeric trigger plus an action verb.
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 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 切日会让亚太用户低估几个百分点。上线前确认埋点用的是 install-local day。
MDE 校验。 基线 22%、21 天约 25.2 万新增（50/50 分组每边约 12.6 万），80% power、alpha 0.05 下 MDE 约 0.7-0.8 pp。目标提升 2.5 pp 远高于 MDE，功效足够。[need from analytics：真实 day-7 子样本量，holdout 和慢留存会削减可用 n]。
护栏。 崩溃率低于 99.6% → 暂停排查。人均付费在 day 3 前下降 5% 以上 → 暂停，怀疑 goal-picker 在抢付费路径的注意力。首日卸载率 +1 pp 以上 → 直接 kill，新增步骤在赶走用户。
灰度。 Day 1-3 跑 10/10/80，先验证埋点和护栏。Day 4 在崩溃率与卸载率全绿后才切到 50/50。Day 14 做一次中期 check，看是否够格提前下结论。
停止。 Day 14 时 D7 提升超过 1.5 pp 且 p < 0.05 → ship。任意护栏触发 → kill。延期不可选，市场 day 25 锁定。
不回答。 本实验不告诉你 goal-picker 是否能改善第 4 周留存或 LTV。需要在第 4 周单独跑一次 cohort readout。
MDE 算法，用大白话讲
所需样本量与你想抓的效应大小的平方成反比——MDE 砍一半，样本量大约要翻四倍。教科书的双比例公式是：
n per arm ≈ (Z_alpha/2 + Z_beta)^2 × [ p1(1-p1) + p2(1-p2) ] / (p2 - p1)^2在行业标准的 80% power、95% 置信下，Z_alpha/2 = 1.96、Z_beta = 0.84。基线越低，所需样本涨得越凶：在 1% 基线上抓一个小提升，需要的用户量大约是 5% 基线的 25 倍。你不用手算，让模型估一个，再用样本量计算器在投流量之前核一遍。Statsig 和 CXL 都有免费的。
真正的统计要在正经平台上跑
AI 出方案，正经引擎算显著性。截至 2026 年 6 月：
| 平台 | 免费档 | 付费起步 | 适合谁 |
|---|---|---|---|
| Statsig | 免费事件额度大方，免信用卡 | Pro 约 $150/月起 | 想把序贯统计和 feature flag 放一起的技术团队 |
| GrowthBook | 开源自托管免费，或云端免费（1 席） | $20/席/月 | 自己掌控数仓、想用 SQL 定义指标的团队 |
| Optimizely | 无 | 企业版年费 $50k+ | 多产品个性化的大型组织 |
独立开发者或小团队，GrowthBook（自托管，免费）或 Statsig 免费档跑一个 goal-picker 实验，不用签合同就够了。
怎么继续打磨
- 假设太虚（“提升参与度”）→ 硬规则：“一个从句写出机制”。
- 跳过 MDE → 强制”给出 MDE 算术或清晰估算，underpowered 时明说”。
- 护栏只是摆设 → 每条都要有数值触发器和一个动词。
- 灰度计划没有 check → 必须写”每一步切量前要看什么”。
- AI 编流量数字 → 反复重申”未提供的数字标 [need from analytics]“。
容易踩的坑
- 功能 flag ship 完了才设计实验——这时你已经没法老实说 no。
- 21 天的实验挑了个季度级才会动的指标（LTV）。
- 五条护栏——每多一条假阳性概率就叠加一次，三条够了。
- 没有停止条件。“等我心里有底再停”的实验永远停不下来。
FAQ
AI 能替我算显著性吗？ 不能。AI 出方案、把 MDE 当 sanity check 估一下。真正的显著性检验要在 Statsig、GrowthBook、Optimizely 或公司内部引擎里跑。AI 给的数字当个心里有数，别当判决。
流量不够跑我想要的 MDE，怎么办？ 把主指标换成动得更快的前置指标（首日留存或激活），把滞后指标（D7、LTV）排到之后的 cohort readout 里。如果功效本来就不够，把窗口拉长也救不了你。
需要 holdout 组吗？ 需要，任何不好回滚的功能都要留。5-10% 的 holdout，在你几周后需要一个干净基线对照时，第一次就值回票价。
跑到一半发现样本量估错了，要停吗？ 不要停。你一偷看结果就停，正是亲手破坏自己显著性的方式。把”样本量重算”记一笔，按原计划跑完，下一次同类实验把基线修正再算。
单边检验还是双边？ 默认双边，除非你有写下来的理由。单边算术更简单、结论更弱；审稿的人有理由不信它。
相关
- AI A/B 实验总结
- AI 实验解读
- AI 留存 Cohort 解读
- AI 功能优先级
- AI 漏斗分析解读
- AI App Store ASO 关键词调研：不靠拍脑袋
- AI Crash 上报三角分类：从堆栈到负责人一次到位
标签: #AI 写作 #app-experiment #ab-testing #app-product-ops #独立开发