kscz0000 A/B 测试搭建
适用场景
当用户想规划、设计或实施 A/B 测试或实验，或搭建一套持续运转的增长实验体系时，调用本技能。也适用于用户提到"A/B 测试"、"分流测试"、"实验"、"测一下这个改动"、"变体文案"、"多变量测试"、"假设"、"我该不该测这个"等场景。
你是实验设计与 A/B 测试领域的专家，目标是帮助用户设计出统计有效、可指导决策的测试。
初步评估
优先检查产品营销上下文：
若存在 .agents/product-marketing.md（也可能是 .claude/product-marketing.md 或旧版文件名 product-marketing-context.md），先读取它，再向用户提问。仅询问尚未覆盖或与本任务直接相关的信息。
设计测试前，先弄清楚：
- 测试背景 —— 想优化什么？在考虑什么改动？
- 现状基线 —— 当前的转化率？日均流量？
- 约束条件 —— 技术复杂度？时间窗口？可用工具？
核心原则
1. 先有假设
- 不是"试试看会怎样"
- 对结果的具体预测
- 基于推理或数据
2. 一次只测一个变量
- 每个测试只动一个变量
- 否则你不知道是哪个起了作用
3. 统计严谨
- 预先确定样本量
- 不要偷看数据后提前收尾
- 严格遵守方法论
4. 测量真正重要的指标
- 主指标直接挂钩业务价值
- 次指标用于辅助解读
- 护栏指标防止伤害业务
假设框架
结构
因为 [观察/数据]，
我们认为 [改动]
将带来 [预期结果]
对 [受众] 而言。
我们通过 [指标] 来验证假设是否成立。
示例
弱假设："改个按钮颜色也许能提升点击。"
强假设："根据热图和用户反馈，新用户普遍找不到 CTA。我们把按钮放大并换成对比色，预计新访客的 CTA 点击率提升 15% 以上。衡量指标为从页面浏览到开始注册的点击率。"
测试类型
| 类型 | 说明 | 所需流量 |
|---|---|---|
| A/B | 两个版本，单一改动 | 中等 |
| A/B/n | 多个变体 | 较高 |
| MVT | 多改动组合 | 非常高 |
| Split URL | 各变体使用不同 URL | 中等 |
样本量
速查表
| 基线 | 10% 提升 | 20% 提升 | 50% 提升 |
|---|---|---|---|
| 1% | 15万/变体 | 3.9万/变体 | 6000/变体 |
| 3% | 4.7万/变体 | 1.2万/变体 | 2000/变体 |
| 5% | 2.7万/变体 | 7000/变体 | 1200/变体 |
| 10% | 1.2万/变体 | 3000/变体 | 550/变体 |
计算器：
更详细的样本量表与测试周期计算：见 references/sample-size-guide.md
指标选择
主指标
- 唯一最重要的指标
- 直接挂钩假设
- 用来判定测试胜负
次指标
- 帮助解读主指标
- 解释改动为什么/怎么起效
护栏指标
- 不应该变差的指标
- 若显著变差，应立即停掉测试
示例：定价页测试
- 主指标：套餐选择率
- 次指标：页面停留时长、套餐分布
- 护栏：客服工单量、退款率
变体设计
可变内容
| 类别 | 示例 |
|---|---|
| 标题/文案 | 切入角度、价值主张、具体程度、语气 |
| 视觉设计 | 布局、颜色、图片、层级 |
| CTA | 按钮文案、大小、位置、数量 |
| 内容 | 包含的信息、顺序、篇幅、社会证明 |
最佳实践
- 单一且有意义的改动
- 改动幅度足以产生差异
- 与假设一致
流量分配
| 方式 | 切分 | 适用场景 |
|---|---|---|
| 标准 | 50/50 | A/B 默认设置 |
| 保守 | 90/10、80/20 | 限制劣质变体风险 |
| 渐进 | 从小到大放量 | 规避技术风险 |
注意事项：
- 一致性：回头访问同一用户看到同一变体
- 时段/星期的均衡曝光
实施方式
客户端
- 用 JavaScript 在页面加载后修改
- 实施快，可能引发闪烁
- 工具：PostHog、Optimizely、VWO
服务端
- 渲染前就决定变体
- 无闪烁，需要开发投入
- 工具：PostHog、LaunchDarkly、Split
运行测试
上线前清单
- 假设已记录
- 主指标已定义
- 样本量已计算
- 变体实现正确
- 埋点已验证
- 所有变体已完成 QA
测试进行中
要做：
- 监控技术问题
- 检查分群质量
- 记录外部因素
不要做：
- 偷看结果并提前终止
- 改动变体
- 引入新的流量来源
偷看陷阱
没达到样本量就看结果并提前终止，会导致假阳性和错误决策。先承诺样本量，过程上管住手。
结果分析
统计显著性
- 95% 置信度 = p 值 < 0.05
- 表示结果由随机因素导致的概率 <5%
- 不是绝对保证，只是一个门槛
分析清单
- 达到样本量了吗？ 若未达标，结果仅作参考
- 统计显著吗？ 看置信区间
- 效应量有意义吗？ 与 MDE 对比，估算业务影响
- 次指标是否一致？ 是否支撑主指标？
- 护栏指标有异常？ 是否有变差的？
- 分群差异？ 移动端 vs 桌面？新用户 vs 回访？
结果解读
| 结果 | 结论 |
|---|---|
| 显著胜出 | 上线变体 |
| 显著落后 | 保留对照组，分析原因 |
| 无显著差异 | 加大流量或加大幅度 |
| 信号混合 | 深入挖掘，可能要看分群 |
文档记录
每次测试都要记录：
- 假设
- 变体（附截图）
- 结果（样本、指标、显著性）
- 决策与经验
模板见：references/test-templates.md
增长实验体系
单次测试有价值，但持续运转的实验体系才是复利资产。本节介绍如何把实验当作长期增长引擎来运转，而不只是单次测试。
实验闭环
1. 生成假设（来自数据、研究、竞品、客户反馈）
2. 用 ICE 评分排序
3. 设计并运行测试
4. 用统计严谨性分析结果
5. 把胜出方案沉淀到 playbook
6. 从经验中提炼新假设
→ 循环往复
假设生成
从多个来源给实验 backlog 注入素材：
| 来源 | 看什么 |
|---|---|
| 数据分析 | 流失节点、低转化页面、表现差的分群 |
| 用户研究 | 痛点、困惑、未被满足的期待 |
| 竞品分析 | 对方用而你没用过的功能、文案或 UX 模式 |
| 客服工单 | 转化流程中的反复咨询或投诉 |
| 热图/录屏 | 用户迟疑、暴怒点击、放弃的位置 |
| 过往实验 | "显著落后"的测试常常揭示新方向 |
ICE 排序
每个假设在三个维度上打 1-10 分：
| 维度 | 评估问题 |
|---|---|
| Impact 影响 | 如果成立，主指标能拉多少？ |
| Confidence 信心 | 有多大把握？（看数据，不是拍脑袋） |
| Ease 难度 | 上线和衡量要花多少时间和成本？ |
ICE 得分 = (影响 + 信心 + 难度) / 3
先跑分数最高的实验。随着上下文变化每月重新打分。
实验节奏指标
把实验节奏作为增长的领先指标来追踪：
| 指标 | 目标 |
|---|---|
| 每月新启动实验数 | 大多数团队 4-8 个 |
| 胜出率 | 成熟项目常见 20%-30%（持续高于此可能意味着假设过于保守） |
| 平均测试周期 | 2-4 周 |
| Backlog 深度 | 排队中的假设 20+ |
| 累计提升 | 所有胜出方案的复利收益 |
实验 playbook
测试胜出后，不仅要上线，还要把模式沉淀下来：
## [实验名称]
**日期**：[日期]
**假设**：[假设内容]
**样本量**：[每个变体的 n]
**结果**：[胜出/失败/无结论]——[主指标] 变化 [X%]（95% 置信区间：[区间]，p=[值]）
**护栏指标**：[护栏指标及结果]
**分群差异**：[按设备、分群或队列的显著差异]
**成败原因**：[分析]
**模式**：[可复用的洞见——例如"定价 CTA 旁加社会证明可提升方案选择率"]
**可迁移到**：[此模式可能适用的其他页面/流程]
**状态**：[已上线 / 暂搁 / 需后续测试]
随着时间推移，playbook 沉淀出专属于你产品和受众的可复用增长模式库。
实验节奏
每周（30 分钟）：复盘进行中的实验，关注技术问题和护栏指标。不要提前判定胜出，但若护栏显著恶化要立即止损。
每两周：结束已完成的实验。分析结果、更新 playbook、从 backlog 启动下一个实验。
每月（1 小时）：复盘实验节奏、胜出率、累计提升。补充假设 backlog，重新用 ICE 排序。
每季度：审计 playbook。哪些模式已广泛应用？哪些胜出模式还未规模化？哪些漏斗区域测试不足？
常见错误
测试设计
- 改动太小（测不出来）
- 改动太多（无法归因）
- 没有清晰假设
执行
- 提前终止
- 测试中途改东西
- 未校验实现
分析
- 忽视置信区间
- 挑分群（cherry-pick）
- 对无结论结果过度解读
针对本任务的提问
- 当前的转化率是多少？
- 该页面每天有多少流量？
- 在考虑什么改动？原因是什么？
- 想检测的最小提升幅度是多少？
- 有哪些可用的测试工具？
- 这个领域之前测试过吗？
相关技能
- cro：基于转化率优化原则生成测试想法
- analytics：搭建测试衡量体系
- copywriting：撰写变体文案
使用限制
- 仅在任务与上游来源及本地项目上下文明确匹配时使用本技能。
- 验证命令、生成的代码、依赖、凭证及外部服务行为后再应用更改。
- 不要把示例当作环境特定测试、安全审查或用户对破坏性/高风险操作的批准替代品。