改版上线两周，数据组发来截图："新版把注册转化率从 5.0% 提到了 5.4%，p 值 0.04，显著，可以全量。"三个月后回看，转化率又跌回 5.1%，新版本实际上什么都没改变——那个"显著"结果从头到尾是一场统计噪声。这不是编的故事，而是 A/B 测试行业里每天都在重复的事故。谷歌、必应、微软、领英这些把实验做成日常的公司，公开数据早就给过答案：绝大多数测试结论是不可靠的，问题集中出在两个最容易被忽视的环节——样本量不够，和显著性被滥用。
对企业数字化项目来说，这笔账格外真实：一次用户体验改版少则几周多则几月的开发投入，最终却由一个统计上根本撑不住的数字来拍板。本文把 A/B 测试里最常见的五个坑逐一拆开，全部依据英文世界的原始研究与公开数据（Kohavi 等人的实验研究、Evan Miller 的模拟分析、GoodUI 的元分析等），并给出改版项目动手前可以直接抄用的检查清单。
一、先认清大盘：多数实验本来就不该"赢"
《可信在线对照实验》（Trustworthy Online Controlled Experiments）一书的三位作者分别执掌谷歌、必应、领英的实验平台，他们基于每年每家两万次以上的实验经验给出过一个著名的分布：在微软，大约只有三分之一的实验产生正向结果，三分之一是中性的，剩下三分之一会让本来想提升的指标变差；在谷歌和必应的搜索场景，能产生显著正向结果的实验比例甚至只有 10%—20%。换句话说，"好主意"在实验里的存活率本来就低得可怜。
这个大盘数字的实践含义是：如果你的团队号称"每次 A/B 测试都赢"，更可能的解释不是点子质量远超微软谷歌，而是测试流程在系统性地制造幻觉。而独立研究者对公开案例的盘点也印证了效果量的天花板：GoodUI 元分析了 115 个公开的网页 A/B 测试结果，观察到的相对提升中位数只有 4% 出头，且大约七成的测试统计功效（power）低得不切实际——也就是说，这些测试从设计之初就没多少机会检出真实存在的小幅改进。
二、第一个坑：样本量不是"跑够天数"，是解一道数学题
样本量由四个参数共同决定：显著性水平 α（惯例 0.05，即容忍 5% 假阳性）、统计功效 1−β（惯例 80%，即真效果存在时有八成把握检出它）、基线转化率、以及最小可检测效应 MDE（你希望检出的最小提升幅度）。两比例检验的近似公式是：每组样本量 n ≈ (1.96+0.84)² × [p₁(1−p₁)+p₂(1−p₂)] ÷ (p₂−p₁)²。把常用业务数字代进去，结果足以让多数中小企业清醒：
基线转化率 5%，想检出"相对提升 10%"（5.0%→5.5%），每组约需 31,200 人，两组合计 6 万多访客；基线 2%，想把 2.0%→2.1% 这种"看起来提升了 5%"的改动检出，每组约需 315,000 人；即便是最"划算"的场景——基线 5%、绝对提升 1 个百分点（5%→6%），每组也要约 8,100 人。而改版检出的通常是前一种量级的小效应：一个 3 万访客的官网，同时对 20 个组件做测试，每个分到 1,500 人——这个样本量下，多数真实存在的小改进根本测不出来，测出来的"大幅改进"又多半是噪声。
坑的隐蔽之处在于：样本不足不会让结果"变差"，而是让结果双向失真。功效只有 30% 的实验，意味着 70% 的真改进会被判为"无显著差异"；而如果实验提前"碰巧显著"了，被高估的幅度又会被当成真实效果写进汇报。正确顺序是动手前先算：明确业务上值得上线的最小提升是多少，反推 MDE，再得出所需样本量与预计周期——算出来需要跑八周，就不要指望两周出结论。
三、第二个坑：每天看一眼仪表盘，显著性就打五折
"提前查看"（peeking）是 A/B 测试最高频、代价也最高的错误。频率派显著性检验的设计前提是：在预定样本量上只做一次分析。每多看一次数据、再做一次检验，就多给随机噪声一次越过 5% 门槛的机会。统计学者 Evan Miller 用模拟量化过这件事：一个真实效果为零的实验，如果每当新数据到达就查看、见到 p<0.05 立刻停止，实际的假阳性率不是 5%，而是约 26%——差不多每四个"赢家"里就有一个纯属虚构。后续多个团队的独立模拟（30 天每日检验场景）得到的数字落在 25%—30% 区间，方向完全一致。
多数实验工具不会拦住你，甚至鼓励你这么做——"置信条变绿就提示可以停止"的界面，本质上是一台把假阳性率调到二十几倍的机器。解决办法有两类：纪律派的做法是预先注册决策时点（样本达标的那一天，或固定跑满整周取先到者），中途看板只用于监控告警、不用于下结论；技术派的做法是采用为持续监测设计的序贯检验（如 O'Brien-Fleming 型 α 消耗函数、always-valid 检验），把 5% 的总预算"分配"到每次中期分析，让多次查看加起来的假阳性率仍然守在 5%。用了带自动停止功能的平台，务必确认它背后是正规序贯方法，而不是"p<0.05 就停"的隐式多重比较。
四、第三个坑：看五个指标，就是把赌局开了五档
改版测试很少只看一个数字：转化率、客单价、跳出率、停留时长、按钮点击率……每个指标按 α=0.05 判断一次，在真实效果全为零的前提下，"至少一个指标显著"的概率是 1−0.95⁵≈22.6%；看 10 个指标逼近 40%；看 20 个指标达到 64.2%。这就是多重比较问题——评审会上那句"虽然主指标不显著，但次指标有显著提升"，多数时候只是在庆祝噪声。
同样危险的是分组切片。整体不显著的实验，切成安卓/iOS、新老用户、五个渠道之后，总会有一两个分片"显著"——每个分片都在独立掷骰子，而分片样本量更小、噪声更大。Kohavi 三人组把样本比例失配（SRM，进组人数偏离预设分流比例）、辛普森悖论（总体与分层方向相反）列为实验可信度的头号威胁，他们的建议很直接：实验开始前指定唯一的核心决策指标（OEC），其余全部降级为观察性指标；确需多指标并行判断时，用 Bonferroni、Holm 或 FDR 之类的方法校正显著性门槛；分片结论只能用来生成新假设，不能当作上线依据，除非分片本身就是实验设计时的检验对象。
五、第四个坑：赢家会褪色——新奇效应与"赢者的诅咒"
即便实验做得完全规范，第一个月的大幅提升也常常在后续衰减。原因之一是新奇效应（novelty effect）：老用户对界面改动短期敏感，点击和转化被"新鲜感"抬高，几周后回落；Kohavi 团队在书中专门用 primacy/novelty 章节提醒此类偏差。原因之二更根本，是所谓"赢者的诅咒"：在一堆含噪声的估计值里挑最大的那个，其观测值天然高估真实效应——你从 10 个变体里选中"提升 8%"的那个，它的真实提升大概率明显小于 8%；实验功效越低，这种高估越严重（统计上称为 Type M 误差：低功效设计下，显著结果的条件期望效应可以是真实效应的数倍）。
这解释了为什么"上次改版 A/B 测试提升 6%，全量上线后只兑现了 1%"是很多团队的共同经历：不是数据造假，而是小样本 + 择优汇报的数学必然。对策一是把 MDE 设成业务上真正值得上线的幅度，而不是"能测出来就行"；对策二是对高价值的"赢家"做复跑验证——用同样的设计重新跑一次，褪色幅度是评估结果可信度的最诚实标尺。
六、第五个坑：小流量业务的现实——测不动就别硬测
前述所有计算都建立在"流量足够"的前提上。一个年访客 20 万的工业品官网，首页改版想检出 5% 的相对提升，按公式要两组各 6 万以上的转化基数，实际要跑一年以上；流量越小的业务，A/B 测试的置信区间越宽——宽到横跨正负好几个百分点的结果，无论 p 值多少，都只是说明手里的尺子刻度太粗。投资人 Andrew Chen 在《你为什么不应该做 A/B 测试》一文中复盘过创业公司的普遍困境：成长期产品的真实流量下，多数测试要达到统计显著需要以年为单位计时——这些测试从立项那天起就注定没有结论。
小流量企业并非无计可施，但要先改姿势：第一，测大改动不测小改动——按钮颜色的微调不值得测，信息架构和核心流程的重构才有足够效应量；第二，聚焦核心用户分群，把无关访客从分析里剔除以降低方差；第三，把 A/B 测试降级为"护栏工具"而非"发现工具"——上线前用它确认新版不会更差，正向判断交给别的方法：五人左右的可用性测试能暴露 80% 以上的交互硬伤（Nielsen 的经典结论），远比重型实验便宜；上线前后对比加上明确的行为指标基线，也是小样本下的务实选择；第四，埋点和数据管道先于实验——分组不均、埋点口径错位造成的"伪显著"，修复统计方法救不了。
七、改版项目动手前的八项检查清单
把五个坑倒过来，就是一张可以直接放进改版合同附件或需求文档的检查表。一、明确唯一核心指标（OEC），其余指标登记为观察项，禁止事后升格。二、用标准公式或计算器预先算出样本量与最短周期，写明"未达样本量不下结论"。三、固定决策时点：跑满至少一个完整周（覆盖工作日与周末行为差异），中途看板仅报警。四、多指标并行时选定校正方法（Bonferroni/Holm/FDR）并在报告中标注。五、上线前核对 SRM：实际分流与预设比例偏差超过统计容忍度，实验作废重跑。六、老用户与新用户分层报告，防新奇效应混入总均值。七、高价值赢家用原设计复跑一次，或上线后 30/60 天回看衰减曲线。八、A/A 测试验证系统：两组都跑旧版，若仍有约 5% 概率"显著"，说明埋点或分流有偏——这一步很多平台从来没做过。
八、结语：A/B 测试是取证工具，不是许愿池
微软、谷歌那种年跑两万次以上实验的文化给出的第一课，恰恰是谦逊：三分之二的想法会被证明无效或有害。A/B 测试的价值在于用统一标准淘汰坏主意、确证好主意，前提是样本量、检验方式、决策纪律三者都配得上这个标准。对企业改版项目而言，与其说"我们做了 A/B 测试"，不如先回答三个问题：需要多少样本才算数？什么时候允许看结果？谁有权把次指标宣布为胜利？这三个问题答不上来，测试平台再漂亮，也只是把拍脑袋的过程自动化了一遍——界面更好看的随机数生成器，终究还是随机数生成器。
