别再盯着“好像变好了”：vibe 项目的 A/B 测试实战

几乎每个做过产品的独立开发者都经历过这一步：改了一个按钮的颜色，或者换了一句文案，然后盯着数据看了一周，结论是“好像变好了，也好像没有”。A/B 测试就是为了解决这种“好像”而存在的：把用户随机分成两组，一组看旧版本，一组看新版本，只比较这两组的行为差异。但 A/B 测试真正难的地方从来不是分流代码怎么写，而是实验设计本身：测什么、拿什么当指标、多少样本才够、结果怎么解读。分流写错了可以修，实验设计错了，跑出来的数字再漂亮也是错的。

本篇的示例均为虚构：南桥烘焙是一家虚构的面包房，店主方晴也是虚构人物，例子里的订单量与转化率只用来说明方法，不代表任何真实商家。本篇讲的是产品层面的 A/B 测试（页面、文案、流程），与灰度发布不同：灰度发布是为了安全上线、逐步放量，A/B 测试是为了比较决策、回答“哪个更好”。两者经常配合使用，但目标不一样，不要混着算账。

第一步：先问能不能测

不是所有改动都值得做 A/B 测试。判断标准有三条。第一，流量够不够。你的产品每天有多少用户会走到被改动的那个环节？如果一天只有 30 个人看到结算页，而你想测的提升只有 2%，那要跑几个月才能看出区别，实验还没跑完，产品已经改了三版了。第二，改动够不够大。按钮颜色从一种蓝换成另一种蓝，预期提升通常很小；把结算流程从三步改成一步，预期提升才值得测。第三，结果能不能归因。如果同一周你同时改了价格、换了首页、还做了一次推广，那么实验组和对照组的差异就说不清是谁的功劳。

南桥烘焙的例子：方晴想测“把‘加入购物车’按钮从页面底部移到商品图下方”有没有用。她先算了一笔账：店铺小程序每天约 800 人浏览商品，其中约 400 人会走到商品详情页。按这个流量，测一个 5% 以上的转化提升，大约需要两周；测 1% 的提升，需要两个月以上。她决定只测两周，能测出 5% 就够了，测不出就说明这个改动不值得继续纠结。这个“先算账再开测”的习惯，是 A/B 测试里最省时间的一步。

指标分层：一个北极星，几个护栏

每个实验只需要一个主要指标，也就是你最想改变的那个数字：下单转化率、注册完成率、付费转化率。只定一个，是为了避免事后挑数字——十个指标里总有一两个会“看起来变好了”，那不叫实验成功，那叫挑结果。

除了主要指标，还要定护栏指标：那些你绝不希望变差的数字。比如测结算流程简化，主要指标是下单转化率，护栏指标就应该是客单价、退款率、客服咨询量。如果转化率上去了，但退款率也上去了，那这个“成功”就是假的。还要定过程指标：用户有没有走到新流程、卡在哪一步，这些数据不用来判胜负，用来解释结果——实验没效果时，过程指标能告诉你是改动本身没用，还是用户根本没看到改动。

指标定义必须在实验开始前写死，包括统计口径：转化率的分母是“访问商品详情页的人”还是“访问首页的人”？退款率统计到下单后几天？这些口径一旦在实验中途改动，结果就没法看了。把指标定义写进实验记录里，和代码放在同一个地方，不要只存在某个人的脑子里。

分组：随机单位、分流一致性、不要按时间切

分组的核心要求是“随机且稳定”。随机单位通常是用户，而不是单次访问：同一个用户今天看到 A 版、明天看到 B 版，行为数据就混在一起了。实现上常用用户 ID 的哈希值取模，这样同一个用户每次都会落到同一组，换设备登录也不会乱。匿名用户可以用设备标识或者 Cookie，但要说明口径：匿名用户的分组稳定性本来就弱于登录用户。

新手最容易踩的坑是按时间切分：“这周跑旧版，下周跑新版，比较两周数据。”时间切分的问题是，这两周本身就不一样：节假日、推广、天气、热点事件都会让数据波动，你根本分不清是版本的效果还是时间的效果。除非流量实在太小、别无选择，否则不要用时间切分代替随机分组。如果真的只能用时间切分，那结论的措辞必须降级：“新版上线后数据有所变化”，而不是“新版带来了提升”。

还有一个坑是“分流污染”：实验组的用户把链接分享给对照组的用户，或者客服手动把某个用户切到另一组。分享链接带实验参数时尤其容易出问题。解决办法是：分组以服务端记录的用户归属为准，而不是以 URL 参数为准；分享出去的链接不应该改变接收者的分组。

结果解读：四个最常见的误读

误读一：提前偷看。实验跑到第三天，数据“看起来显著”，就提前宣布胜利。提前偷看的问题是，你看了很多次，每次都有一定概率撞上随机波动，多次偷看等于多次抽奖。解决办法是：开始前定好最小运行时间（比如两周）或者最小样本量，时间不到、样本不够就不判胜负；如果实在要中途看，只看过程指标（有没有跑通、有没有 bug），不看胜负指标。

误读二：p 值崇拜。一个 p 值小于 0.05 的结果不代表“提升是真实的”，它只代表“如果新旧版本真的没区别，看到这么大差异的概率比较小”。小样本下的“显著”往往伴随着被高估的提升幅度——这叫“赢家诅咒”。报告结果时要同时写三样东西：差异幅度、置信区间、样本量。只写“显著提升 30%”而不写样本量和置信区间的实验报告，基本等于没写。

误读三：多指标挑结果。同时看十个指标，总有一两个会“显著”，这就是多重比较的问题。如果确实需要看多个指标，要提前说明哪些是指标、哪些只是观察，或者对显著性标准做相应收紧。更务实的做法是：主要指标判胜负，其他指标只用来发现问题，不用来追加胜利。

误读四：平均数掩盖分组差异。整体提升 5%，可能来自新用户提升 20%、老用户下降 10%。这种现象叫辛普森悖论，分组看和整体看会得出相反结论。实验报告里至少要按新老用户、设备类型这两个维度各切一次，看看提升是不是均匀的。如果提升只来自某一类用户，那上线决策就要重新考虑：是只给这类用户上，还是继续优化。

小流量产品的替代办法

如果你的产品流量实在太小，跑不起严格的 A/B 测试，也不要硬跑。有三种替代办法，各有代价。第一种是前后对比：上线前记录两周基线数据，上线后记录两周数据，比较变化。代价是无法排除时间因素，结论措辞必须保守。第二种是定性验证：找 5 到 10 个真实用户，让他们在新旧两个版本上各完成一次任务，观察卡点、记录原话。样本虽小，但能发现 A/B 测试发现不了的问题，比如“用户根本没注意到这个按钮”。第三种是顺序测试：把改动先给一小部分用户，确认没有 bug 和明显负面反馈，再逐步放量。这本质上是灰度发布，不是 A/B 测试，不要把它包装成实验结论。

南桥烘焙最后就是这么做的：两周实验跑完，按钮位置调整带来的转化提升是 3%，置信区间跨过了 0，严格说“没有统计学上的结论”。但过程指标显示，新位置的按钮点击率确实高了，而下单转化率没动——说明用户看到了按钮，但下单意愿没变。方晴据此决定保留新位置（因为点击体验更好），但不再为这个改动投入更多时间。这个决策本身就是 A/B 测试的价值：不是每一次实验都要分出胜负，分不出胜负也是一种答案，它告诉你“别再在这里花时间了”。

上线前的一页纸实验记录

每个实验开始前，写一页纸记录，包含以下内容：实验名称与假设（“我们认为把按钮移到商品图下方，会让用户更快找到购买入口，从而提升下单转化率”）；主要指标、护栏指标、过程指标及其统计口径；分组方式与随机单位；最小运行时间与最小样本量；提前结束的条件（比如出现严重 bug、护栏指标跌破阈值）；结果解读人（谁来判胜负，避免“谁提的实验谁宣布胜利”）。实验结束后，把实际结果、分组切分、决策写回同一页纸。三个月后回看这些记录，你会发现它们比任何数据看板都更能说明产品是怎么一步步变成今天这样的。

最后提醒一句伦理边界：A/B 测试测的是产品行为，不是测用户底线。价格歧视（不同用户看到不同价格）、针对弱势群体的诱导设计、未经说明收集敏感行为数据，都不应该以“实验”的名义进行。实验开始前问自己一句话：如果用户知道自己被分到了这一组，他会不会觉得被冒犯？如果答案是会，那就不要做。长期来看，用户信任比任何一次实验的提升都贵得多。

实验分流的代码骨架与检查点

说到落地，很多 vibe 项目的分流代码其实可以很简单，关键是把几个检查点做对。一个最小可用的骨架是：用户登录后，服务端根据用户 ID 的哈希值决定分组，把分组结果写进用户画像或者实验记录表；前端渲染时只向服务端请求“当前用户属于哪一组”，不要让前端自己算分组——前端算分组容易被篡改、也容易在不同页面算出不同结果。实验配置（分组比例、起止时间、涉及页面）要放在服务端配置里，而不是写死在前端代码里，这样紧急关停实验时只需要改配置，不需要重新发版。

上线分流代码之前，跑一遍这四个检查点。第一，分组比例检查：跑 1000 个测试用户，分组比例是不是接近设定值（比如 50/50）？如果偏差超过几个百分点，分流函数可能有问题。第二，稳定性检查：同一个用户刷新页面、换设备登录，分组变不变？第三，隔离检查：实验组和对照组的用户有没有可能互相看到对方版本？比如共用缓存、共用服务端渲染结果，都可能造成串组。第四，日志检查：每一次分组决策有没有记录？没有记录的实验，事后无法复核，等于白做。这四个检查点花不了半天，但能拦住大多数分流事故。

一份失败实验的复盘模板

失败的实验比成功的实验更有价值，前提是复盘写得到位。复盘模板可以只有五栏：假设（当初为什么认为这个改动有效）、实际结果（主要指标、护栏指标、置信区间、样本量）、过程发现（用户到底有没有看到改动、卡在哪一步）、原因猜测（区分“已证实”和“猜测”，不要把猜测写成结论）、下一步（放弃、继续优化、换方向）。南桥烘焙的按钮实验如果用这个模板写，结论会很清晰：假设是“按钮位置影响下单”，实际结果是“点击提升、转化不动”，过程发现是“用户看到了按钮但下单意愿没变”，下一步是“保留新位置、停止投入”。

复盘还有一个作用：防止重复踩坑。三个月后，另一个人提出“要不要把按钮移到商品图下方”，你翻出这篇复盘就知道这件事已经测过、结果是什么、为什么停手，不需要再花两周重测一遍。实验记录的积累，本质上就是团队的产品直觉在变成书面资产。直觉会随着人员流动而流失，记录不会。所以每次实验结束，无论成败，都把这一页纸写完再关掉任务。这是对未来的自己最划算的一次投资。

写在最后：实验文化的起点是一页纸

很多团队做不好 A/B 测试，不是因为缺工具，而是因为缺习惯：实验开始前不写假设，实验结束后不写复盘，下一次换个人又从零开始猜。改变这一点不需要采购任何平台，只需要坚持一页纸实验记录：假设、指标、分组、样本量、结果、决策。写满十页，你的团队就有了第一份属于自己的实验知识库；写满五十页，新人入职时就不需要再问“我们以前测过这个吗”，翻记录就知道。A/B 测试的终极产出不是某一次的胜负数字，而是团队“用证据做决定”的习惯。这个习惯一旦养成，产品决策的质量会在未来几年里持续受益——远比某一次按钮颜色的 3% 提升值钱得多。所以，别再盯着“好像变好了”。写下假设，分好组，跑够样本，再看数字说话。

什么时候应该停掉实验

实验开始前定好的“提前结束条件”，往往比实验本身更重要。出现以下任何一种情况，都应该立即停掉实验，而不是等到预定时间。第一，出现严重 bug：比如实验组用户无法下单、页面白屏、数据丢失——这时候继续跑实验就是在拿真实用户做代价。第二，护栏指标跌破阈值：比如退款率在三天内上升超过预设的红线，哪怕主要指标看起来在涨，也要先停下来查原因。第三，分组被污染：发现大量用户串组、或者某个渠道的流量全部涌入了同一组，数据已经不可信，继续跑只是浪费时间。第四，外部环境突变：比如竞品突然降价、平台政策变化、热点事件导致流量结构完全改变，这时候的实验结果已经无法推广到正常时期。

停掉实验不等于实验失败。把停掉的原因、当时的数据、决策过程写进实验记录，这次“未完成”的实验同样会成为团队的知识。最糟糕的做法不是停掉实验，而是明明已经发现数据不可信，却为了“跑满两周”硬撑下去——跑出来的数字越完整，误导性就越强。实验的纪律性，恰恰体现在敢于提前叫停的时刻。