/pm-abtest

name: pm-abtest
description: |
  Use when: 需要验证产品优化效果、进行数据驱动的A/B实验决策、评估功能改动的因果影响
  Do NOT use when: 改动无法量化测量、样本量不足、不需要严格统计验证
allowed-tools:
  - Read
  - Write
  - AskUserQuestion
  - Agent
  - Bash

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

---

跨 Agent 交互规则

当流程要求与用户交互时：

1. 如果当前环境支持 AskUserQuestion，使用 AskUserQuestion（最佳体验）。 2. 如果当前环境不支持 AskUserQuestion，必须用普通聊天消息提出同样问题。 3. 一次只问一个问题。 4. 提问后必须停止当前回合，等待用户回答（STOP and WAIT）。 5. 不得在用户回答前生成文档、写入 docs。 6. 已有 docs 文件不能替代本轮用户回答。

---

执行流程

步骤 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 并行架构升级

架构概览

并行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个 | - | | **方案完整性** | 基础 | 多维度综合 | 更全面 |

---

注意事项

1. 一次只测试一个变量，避免混淆因素 2. 测试期间不要对实验功能做额外改动 3. 警惕"新奇效应"（用户对新功能的好奇导致短期数据虚高） 4. 统计显著性 ≠ 业务显著性，关注效应量

---

输出质量对比

**✅ Good 示例**：

- 有数据引用：「根据 Q4 数据，留存率从 35% 降至 28%」
- 有验证来源：「数据来源：Google Analytics, 2025-12-01」
- 有明确建议：「建议将新手引导步骤从 5 步减少至 3 步」

**❌ Bad 示例**：

- 模糊结论：「数据表明留存率有所下降」
- 无来源：「根据经验，这个功能很重要」
- 没有行动建议：「留存是个问题」

---

常见误区 / Red Flags — STOP

出现以下情况立即停止并回溯：

| 误区 | 正确做法 | |------|---------| | 使用"应该"、"大概"、"看起来"做结论 | 必须基于实际数据和验证 | | 未运行检查就声称已完成 | 先验证，再陈述 | | 因时间紧迫跳过关键步骤 | 没有例外，时间紧更要严格 | | "这次应该没问题"的想法 | 每次都要重新验证 |

---

产出质量检查 / Verification Checklist

• [ ] 前置依赖已满足（输入文档/数据已收集）
• [ ] 核心步骤已全部执行
• [ ] 输出文档已生成到 `docs/` 目录
• [ ] 每个判断都有数据/证据支撑
• [ ] 已推荐 2-3 个后续 skill

> ⚠️ 任何一项未通过 → 补全后再标记完成。

---