pm-experimentation-ab

A/B 测试与实验技能

此技能的工作方式（请先阅读）

这是一项生成式技能（用于设计或修订实验计划，也可审核现有的测试设置）。实验领域中，AI 助手的默认做法常常悄然出错，并因此得出自信却错误的结论。Claude 会乐于“设置 A/B 测试”，然后仅凭少数用户就宣布胜出者、一看到 p < 0.05 就偷看数据并停止、只优化一项指标，却不设护栏来控制对其他方面造成的损害，测试只运行三个工作日，最后得出“B 胜出”的结论，却没有细分群体分析、长期评估，也没有任何记录。糟糕的实验比不做实验更糟——它会把猜测包装成“数据”。

因此，此技能设有门槛，而门槛就是严谨的统计方法：

1. 明确背景——受控实验是否真是合适的工具，它要支持哪一个决策，以及风险级别（这些因素会决定置信度、流量分配和持续时间）。
2. 落实始终适用的核心原则——预先登记假设和成功标准，运行前计算测试所需样本量，完成完整周期，使用一个主要指标和护栏指标，解读“胜出”背后的实际含义，并完成学习闭环。
3. 提出取决于背景的决策（置信度阈值、流量分配、A/B 测试与多变量测试、指标类型、领先指标与长期指标、测试优先级），并说明利弊；由用户选择。

随后，交由 pm-okr-metric-validity-audit（所选指标是否有效，而非虚荣指标？）以及 pm-assumption-rigor-audit（假设是否针对最高风险、可证伪，并已预先承诺？）继续处理。

范围与配合：此技能负责受控实验方法及其统计学原理。它与 pm-assumption-testing 配合，后者负责选择测试内容和成本最低的测试方式——如果问题处于早期阶段、流量较低，或更适合通过定性方式回答，应转交给 assumption-testing，而不是强行进行 A/B 测试。广义的下一步构建内容排序交由 pm-prioritization，指标定义/OKR交由 pm-okrs-kpis，高风险的发布放行决策交由 pm-decision-quality-audit。

---

步骤 0 — 设计测试前明确背景

如果信息未知，请先提问；如果在没有答案的情况下继续，请说明所作的假设：

• 受控实验是否是合适的工具？ A/B 测试需要足够的流量，才能在合理的时间内达到有效样本量；变更必须能体现在行为上，而且问题应是“哪个效果更好”，而不是“有没有人需要这个”。如果流量有限、想法尚未验证，或问题是“为什么”，请转交给 pm-assumption-testing（先做成本更低的定性测试或低保真测试）。不要指望通过 A/B 测试找到产品与市场的契合点。
• 这项实验要支持哪一个具体决策，风险有多高？ 每项实验只对应一个决策。判断失误的风险/影响决定置信度阈值和流量分配（结账流程或定价变更，与按钮颜色变更不可同日而语）。
• 基准值和最低可检测效应（MDE）是多少？ 你需要当前指标值，以及值得关注的最小提升幅度——两者都会影响样本量计算。基准值越低、MDE 越小，所需样本量越大。
• 业务周期是什么？是否存在混杂因素？ 工作日与周末的规律、季节性、发布、促销、竞争对手动态。这些因素决定最短持续时间，并可排除会导致结果偏差的时间窗口。

---

始终适用的核心原则（适用于任何受控实验）

运行前预先登记

• 写出可证伪的假设并说明理由：“如果我们[做出这项改动]，那么[这项指标]会因为[用户洞察]而[增加/减少][幅度]。”模糊的假设（“看看更大的按钮有没有用”）只会带来模糊的结果。
• **以证伪而非证实为目标进行设计。**预先设定成功和失败标准；事先承诺什么结果会改变你的看法。如果每次测试都“成功”，那你衡量的指标就不对，或者是在事后编造说法——你有时必须判断错误。
• **提前设定决策阈值。**在上线前决定什么结果意味着迭代、转向或坚持（例如，“提升 <20% → 转向，20–40% → 迭代，>40% → 坚持”）。预先承诺才能避免事后合理化。

正确确定规模并运行测试

• **先计算样本量，再推算测试时长。**根据基线、MDE 和置信度，计算每个变体所需的用户数；每日流量会告诉你测试需要运行多久。跳过这一步，就会导致测试过早停止或无限期拖延。
• **达到真正的显著性——不要偷看结果。**设定置信水平（默认 95%/p<0.05），让测试运行至计划的样本量，并覆盖完整的业务周期（≥1–2 周）。一看到显著的 p 值就停止，会抬高假阳性率。“100 个用户后就显著”说明配置有问题，不是测试成功。
• **随机且持续地分配；对两组都做 QA。**默认按 50/50 分配，确保同一用户在不同访问中始终处于同一组，并在各类设备和浏览器上验证追踪是否正常触发。测试期间绝不要更改分组比例——这会扭曲结果。

诚实地衡量

• 一个主要指标 + 护栏指标。主要指标与假设相关，并用于判定成败；添加护栏/健康指标（例如收入、流失率、订单价值、支持请求量、延迟），以便发现那些表面“成功”、却悄悄损害其他方面的情况。舍弃那些让人感觉良好、却无法推动决策的虚荣指标。
• 不要止步于“它赢了”。分析细分群体（移动端/桌面端、新用户/回访用户、地理位置、来源——整体提升 10% 可能掩盖了移动端下降 5%），检查次要影响，并权衡短期与长期效果（留出组可以揭示短期提升是否能持续）。

完成闭环

• **记录并做出决策。**记录预先写好的假设、设置、结果（包括失败），并依据预设阈值做出迭代、转向或坚持的决定。将结果纳入相关 OKR。建立可搜索的经验库，避免组织重复运行相同的测试——失败的实验往往包含最有价值的警示，而出人意料的用户行为（Twitter 的“@username”、Airbnb 的商务旅客）正是突破的隐藏之处。

---

取决于具体情境的决策（呈现选项，不自动应用）

逐项列出决策及其权衡，并给出与 Step 0 相关的建议；由用户选择。同时应用所有方法和指标类型会导致失败。

决策	适用情况	应避免／调整的情况	默认建议
置信度阈值	对关键／不可逆的流程（结账、定价）采用 99%；对低风险、快速迭代的功能采用 90%	把 95% 奉为不可动摇的标准，用于琐碎改动；或在影响范围大的改动中采用 90%	按风险分级；默认采用 95%，关键场景提高阈值，仅对成本低且可逆的调用降低阈值
流量分配	对快速、低风险的读取采用 50/50	当变体存在实际负面影响（新定价、重大改版）时，采用 90/10（或更小的曝光比例）	除非负面影响风险足以构成限制曝光的理由，否则采用 50/50；测试期间绝不更改
A/B 测试与多变量测试	用 A/B 测试清晰地隔离单一改动；用多变量测试找出不同元素之间的交互效应	流量不足时进行多变量测试——N 个元素 × 多个变体会成倍增加所需样本量（4 种组合 = 4 倍流量）	默认采用 A/B 测试；仅在流量大的界面采用多变量测试
标准化指标与自定义指标	用标准化指标（注册率、WAU）比较不同实验；用自定义指标（“完成首项任务所需时间”）检验具体假设	只用标准化指标（无法体现功能的实际效果），或只用自定义指标（失去一致性）	跟踪少量标准化指标，并且跟踪与假设相关的自定义指标
领先指标与滞后／长期指标	当目标罕见／见效缓慢时，用领先指标（加入购物车）快速获取信号；用留出组评估持续影响	仅凭短期指标就断定取得了长期成效	用领先指标解读早期表现；留出一部分用户以确认效果能否持久
测试优先级排序	用 PIE（潜力 × 重要性 × 易行性）或类似方法为测试想法的待办列表排序	不做排序就同时运行多个测试，或优先测试低流量页面	按 PIE 为想法打分；更广泛的路线图排序交由 pm-prioritization 处理

有几种情境会同时改变多项默认建议：**流量低／尚未达到产品市场契合度（PMF）**的产品通常不应进行 A/B 测试（改用假设测试）；高风险、不可逆的改动则应采用 99% 置信度、保守的流量分配、优先考虑防护指标，并在发布前进行 decision-quality 检查。

---

验证结果（编排）

交接时使用每个审查视角对应的可安装技能 name。只有在该技能已安装时才调用；如果未安装，该技能的核心内容已经包含这些规则，可直接继续，而不要因此阻塞。

完成初稿或修订后，应将其交给审计视角审查，而不是直接宣布完成。这些是候选审查视角——按照 docs/orchestration-policy.md 中的方针选择，或将整个产物交由 pm-product-review 审查。此处，assumption-rigor 是始终相关的审查视角（自动运行）；其他视角则是可选项，取决于产物的实际内容。如果用户调用此技能是为了处理某一特定事项，请尊重该范围。

• pm-assumption-rigor-audit（自动运行）——该假设是否是最值得进行受控测试的高风险假设？它是否以可证伪的方式表述，是否在测试前设定了成功标准，并在测试后得到诚实解读（而非带有确认偏误）？
• pm-okr-metric-validity-audit（可选——如果提到了主要指标或护栏指标）——主要指标和护栏指标是否能有效衡量结果（而非页面浏览量等虚荣指标），并且是否与实际目标相关？优化错误指标的实验会把错误方向扩大。
• pm-decision-quality-audit（可选——如果该方案会推动高风险或不可逆的发布）——迭代、转向或坚持的决策是否基于可靠的流程（预设阈值、事前复盘、区分流程与结果），而非侥幸得到的数字？

**组合方式（依据 docs/orchestration-policy.md 第 9 节）：**此技能与 pm-assumption-testing 配合使用——后者是负责决定测试什么以及采用成本最低的方法的协作技能（交由它处理）；当 A/B 测试是合适的方法时，此技能负责运行受控实验。如果审计发现冲突，应以目标为准：实验的目的是产出可信的决策——如果无法获得有效样本、缺少护栏，或结果不会改变行动，就不要将其作为 A/B 测试来运行。

---

常见的正确与错误做法

❌ 不要	✅ 应该
根据极小样本宣布胜出方案	先计算样本量；达到目标样本量后再结束
看到第一个 p < 0.05 就提前停止	预先设定置信度，并覆盖完整业务周期；不要提前停止
只运行三个工作日	覆盖 ≥1–2 周或完整业务周期；避免使用有偏的时间窗口
不顾副作用，盲目优化单一指标	设置一个主要指标，以及护栏／健康指标
追逐虚荣指标（页面浏览量）	让指标与假设和决策相关
写下含糊的“我们来测试 X”	提出可证伪的“如果／那么／因为”假设，并设定成功和失败标准
只看总体数字	按设备／新用户与回访用户／地区细分，并查看次要指标和长期结果
在测试期间更改流量分配比例	预先固定比例；保持分配随机且持久
在流量不足时进行多变量测试	默认采用 A/B 测试；仅在流量充足的页面上进行多变量测试
对未经验证、流量低的想法进行 A/B 测试	将早期、低流量或定性问题交由 assumption-testing 处理
说一句“B 赢了”就结束	记录结果，根据预设阈值决定迭代、转向或坚持，并积累经验
未经审查就发布测试计划	交由 okr-metric-validity + assumption-rigor 审查（重大发布还需 decision-quality）

---

来源课程（Uxcel）

• A/B 测试与实验
• A/B 测试
• 实验指标
• 从发布中学习