技能介绍

要解决的问题

A/B 实验看起来门槛不高，真正踩坑的地方都在方案落地前：流量不足时硬上实验，结论全是噪声；把"要不要做这个功能"这类战略问题塞进实验框架，几周后拿到的数据什么都回答不了；显著性peeking加上提前停止，让一个 MDE 只有 5% 的实验在"第 3 天看起来赢了"。团队耗费工程资源跑完实验，最后拍脑袋做决策——实验只负责制造图表，不负责产生判断。

它如何工作

Lumen 的输入是一个待测试的改动，输出是一份可直接执行的实验规格，或者一份明确的"不要测"结论。

先做判定，再写规格。 按 Step 0 依次回答三个问题：

流量是否够？ 主指标每周至少 500 次转化，且能在 6 周内达到所需样本量。不够就直接转向定性方法，而不是设计实验。
是战术问题还是战略问题？ 按钮文案、布局、流程步骤属于战术，可以实验；定位、核心价值主张、大功能方向属于战略，应该走用户研究。
效应量能否被检测？ 如果预期只能让主指标移动 5% 以内，需要十万级样本，按当前流量根本跑不完。

判定通过后，技能按 Step 2–6 输出完整规格：主指标、护栏指标及其容差、按 80% power / 95% 置信度查表得到的每组样本量、预计运行时长（超过 42 天即判定不可行）、以及上线前必须写下的决策规则。

决策规则是硬约束。 测试期间偷看结果并提前停止，是团队自我欺骗最常见的方式。规则必须在 Day 1 之前写下来并同步给所有利益相关方，之后不再修改。

适用边界

不是实验启动器。 战略方向、需求真伪、问题定义，都不该由实验回答。
流量是硬门槛。 样本量查表基于 80% power 和 95% 置信度，查表值是近似值，实际仍需按自己框架的参数校准。
输出受 40 行 CLI 预算约束。 规格超长时，完整内容转入 HTML 报告（/atlas-report），CLI 只保留一行结论、Top 3 发现和报告路径。

工具的默认答案是"别测"，只有在判定通过时才输出那份规格。