Preamble
bash "$(dirname "${BASH_SOURCE[0]}")"/check-update.sh 2>/dev/null || true
mkdir -p docs/03-增长迭代/A-B测试
echo "🧪 A/B测试工具已启动"
# 检查数据指标体系
if [ -f "docs/02-方案设计/数据指标体系.md" ]; then
echo "✅ 数据指标体系 - 已找到"
else
echo "⏳ 数据指标体系 - 未找到"
fi
执行流程
digraph pm_abtest {
rankdir=TB;
node [shape=box, style=filled, fillcolor="#e3f2fd"];
"定义测试假设" -> "设计实验方案";
"设计实验方案" -> "样本量计算";
"样本量计算" -> "设定测试周期";
"设定测试周期" -> "数据收集框架";
"数据收集框架" -> "输出A/B测试方案";
}
步骤 1: 定义测试假设
使用 AskUserQuestion 询问:
🎯 A/B测试假设设定
A/B测试需要明确的假设。请描述:
测试背景:为什么要进行这次测试? 示例:注册转化率低于行业平均水平(2% vs 行业5%)
测试假设:如果{改变什么},那么{预期结果},因为{原因}。 示例:如果将注册按钮从页面底部移到顶部,那么注册转化率将提升20%,因为用户更容易看到按钮。
请描述您的测试假设:
记录到变量 TEST_HYPOTHESIS
步骤 2: 设计实验方案
🔬 实验方案设计
实验变量:
- 对照组(Control):当前版本(现状)
- 实验组(Treatment):{改动描述}
关键指标:
- 核心指标(Primary):{指标名称} - 直接影响业务结果
- 辅助指标(Secondary):{指标名称} - 帮助理解变化原因
- 护栏指标(Guardrail):{指标名称} - 确保不损害用户体验
示例(注册按钮测试):
- 核心指标:注册转化率
- 辅助指标:点击率、页面停留时长
- 护栏指标:页面跳出率、用户满意度
请确认关键指标:
A) 指标合理,继续下一步 B) 需要调整核心指标 C) 需要补充辅助指标
步骤 3: 样本量计算
📊 样本量计算
需要的参数:
参数 说明 输入 基准转化率 对照组当前指标值 [X]% 最小可检测提升 期望的最小提升幅度 [X]% 显著性水平(α) 通常设为5%(0.05) 0.05 统计功效(1-β) 通常设为80%(0.8) 0.8 估算结果:
- 所需样本量(每组):约[X]个用户
- 总样本量:约[X]个用户
- 预估测试周期:约[X]天(基于当前日均流量)
样本量是否可行?
A) 可行,按此方案执行 B) 样本量过大,需要调整参数 C) 样本量太小,需要延长测试周期
步骤 4: 设定测试周期
⏱️ 测试周期设定
最小运行时间:{X}天(基于样本量计算) 建议运行时间:至少7天(覆盖工作日和周末) 最大运行时间:{X}天(避免环境变化影响)
运行规则:
- 流量分配:50%对照组 / 50%实验组
- 用户分桶:按用户ID hash 随机分配
- 互斥实验:确保同一用户不参与多个冲突实验
提前停止规则:
- 实验组指标显著优于对照组(p < 0.05)
- 实验组护栏指标显著恶化
- 出现严重技术问题
测试周期是否确认?
步骤 5: 数据收集与分析框架
📈 数据收集与分析:
数据收集:
- 埋点事件:{事件名称}
- 数据存储:{存储位置}
- 数据校验:每日检查数据完整性
分析框架:
1. 数据清洗(去除异常值、测试账号) 2. 描述性统计(均值、标准差、分布) 3. 假设检验(t检验或Z检验) 4. 效应量计算(Cohen's d) 5. 分层分析(按用户特征分组)决策规则:
- p < 0.05 → 统计显著,考虑上线
- p ≥ 0.05 → 统计不显著,维持现状或重新设计
- 护栏指标恶化 → 无论显著性如何,谨慎上线
步骤 6: 输出 A/B 测试方案
使用 Write 工具创建 docs/03-增长迭代/A-B测试/测试方案-{测试名称}.md:
# A/B测试方案 - {测试名称}
## 一、测试概览
- **测试名称**:{名称}
- **测试负责人**:{负责人}
- **创建时间**:{时间}
## 二、测试假设
**背景**:{测试背景}
**假设**:{测试假设}
## 三、实验设计
| 项目 | 说明 |
|------|------|
| 对照组 | 当前版本:{描述} |
| 实验组 | 改动版本:{描述} |
| 核心指标 | {指标名称} |
| 辅助指标 | {指标名称} |
| 护栏指标 | {指标名称} |
## 四、样本量与周期
- **所需样本量**:每组{X}个用户
- **测试周期**:{X}天({开始日期} 至 {结束日期})
- **流量分配**:50%/50%
## 五、分析计划
1. 数据清洗:{规则}
2. 描述性统计:{方法}
3. 假设检验:{方法}
4. 分层分析:{维度}
## 六、决策标准
- ✅ p < 0.05 且护栏指标无恶化 → 上线实验组
- ⚠️ p ≥ 0.05 → 维持现状或重新设计
- ❌ 护栏指标恶化 → 暂停实验
---
**文档状态**: 测试方案设计完成
**生成时间**: {时间戳}
步骤 7: 完成提示
✅ A/B测试方案完成!
📄 已生成:
docs/03-增长迭代/A-B测试/测试方案-{名称}.md🎯 建议下一步:
A) 与开发团队对齐埋点需求 B) 执行 /pm-report - 在测试结束后分析结果 C) 执行 /pm-growth - 基于测试结果制定增长方案
兜底机制
场景: 无法精确计算样本量
如果用户无法提供基准转化率等参数,使用经验法则:
- 电商/工具产品:每组至少1000个用户
- 内容/社交产品:每组至少5000个用户
- 测试周期:至少7天
V2 并行架构升级
架构概览
digraph pm_abtest_subagent {
rankdir=LR;
node [shape=box, style=filled, fillcolor="#e3f2fd"];
subgraph cluster_main {
label="主Agent";
style=filled;
fillcolor="#f5f5f5";
"主Agent交互";
}
subgraph cluster_parallel {
label="并行分析Subagent (V2)";
style=filled;
fillcolor="#f8f9fa";
"统计方案设计Subagent" [fillcolor="#c8e6c9"];
"样本量计算Subagent" [fillcolor="#bbdefb"];
"埋点方案设计Subagent" [fillcolor="#fff9c4"];
"风险分析Subagent" [fillcolor="#f8bbd0"];
}
"主Agent交互" -> "统计方案设计Subagent";
"主Agent交互" -> "样本量计算Subagent";
"主Agent交互" -> "埋点方案设计Subagent";
"主Agent交互" -> "风险分析Subagent";
"统计方案设计Subagent" -> "主Agent整合";
"样本量计算Subagent" -> "主Agent整合";
"埋点方案设计Subagent" -> "主Agent整合";
"风险分析Subagent" -> "主Agent整合";
"主Agent整合" -> "输出完整测试方案";
}
并行Subagent分析
在收集完测试参数后,并发派发4个Subagent:
Subagent 1: 统计方案设计
- 负责:选择检验方法、计算效应量、设计分层分析
Subagent 2: 样本量计算
- 负责:基于参数精确计算样本量、预估测试周期
Subagent 3: 埋点方案设计
- 负责:设计数据埋点、定义指标口径、规划数据校验规则
Subagent 4: 风险分析
- 负责:识别新奇效应、评估护栏指标、制定提前停止规则
V1 vs V2 对比
| 指标 | V1(顺序分析) | V2(并行分析) | 提升 |
|---|---|---|---|
| 分析时间 | ~6分钟 | ~2分钟 | 3x |
| 主Agent上下文 | ~15,000 tokens | ~4,000 tokens | 节省73% |
| 分析维度 | 串行3-5步 | 并行4个 | - |
| 方案完整性 | 基础 | 多维度综合 | 更全面 |
注意事项
- 一次只测试一个变量,避免混淆因素
- 测试期间不要对实验功能做额外改动
- 警惕"新奇效应"(用户对新功能的好奇导致短期数据虚高)
- 统计显著性 ≠ 业务显著性,关注效应量
输出质量对比
✅ Good 示例:
- 有数据引用:「根据 Q4 数据,留存率从 35% 降至 28%」
- 有验证来源:「数据来源:Google Analytics, 2025-12-01」
- 有明确建议:「建议将新手引导步骤从 5 步减少至 3 步」
❌ Bad 示例:
- 模糊结论:「数据表明留存率有所下降」
- 无来源:「根据经验,这个功能很重要」
- 没有行动建议:「留存是个问题」
常见误区 / Red Flags — STOP
出现以下情况立即停止并回溯:
| 误区 | 正确做法 |
|---|---|
| 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 |
| 未运行检查就声称已完成 | 先验证,再陈述 |
| 因时间紧迫跳过关键步骤 | 没有例外,时间紧更要严格 |
| "这次应该没问题"的想法 | 每次都要重新验证 |
产出质量检查 / Verification Checklist
- 前置依赖已满足(输入文档/数据已收集)
- 核心步骤已全部执行
- 输出文档已生成到
docs/目录 - 每个判断都有数据/证据支撑
- 已推荐 2-3 个后续 skill
⚠️ 任何一项未通过 → 补全后再标记完成。