核心用法
AB Testing Skill 采用四阶段结构化工作流，引导用户系统性地完成产品实验。当用户提及 AB 测试或相关需求时，Skill 会主动确认是否进入流程模式，并依次推进以下阶段：
Stage 1（明确目标与背景）：锚定假设和核心指标，明确成功标准、约束条件及不可破坏的底线，尽早识别未知因素。
Stage 2（设计实验方案）：将目标转化为具体的随机化策略和分组方案，显式对比不同替代方案的权衡，避免隐含的假设陷阱。
Stage 3（实施、验证与加固）：以伦理和防护机制为核心执行验证循环，优先采用小步快跑、可测量的检查点，并在高风险处设置回滚机制。
Stage 4（运营、沟通与迭代）：通过分析规则和决策标准闭环，涵盖监控、文档、利益相关者同步及经验沉淀。
用户可随时选择跳过阶段或切换至自由模式，Skill 会尊重用户偏好而不强制说教。
显著优点
1. 流程严谨性：将 AB 测试这一复杂工作拆解为可管理的阶段，每个阶段都有清晰的退出标准和检查清单，避免常见的设计漏洞。
2. 伦理内建：在第三阶段明确强调伦理审查和防护机制，这在同类工具中较为罕见，特别适合处理敏感用户数据或高风险功能变更的场景。
3. 灵活适配：既支持完整工作流，也允许用户按需取用；若用户选择自由模式，Skill 会无缝切换而不强加流程。
4. 风险显性化：强制要求陈述风险和权衡，而非含糊带过，帮助团队建立健康的决策文化。
潜在缺点与局限性
1. 无自动化执行：作为纯文档型 Skill，不提供统计计算、样本量自动计算或与实验平台的 API 集成，用户仍需借助专业工具（如 Optimizely、Statsig 或自建平台）执行实际实验。
2. 领域深度有限：侧重于流程框架，对于特定行业（如医疗、金融）的合规要求或高级统计方法（如序贯测试、因果推断）需用户自行补充。
3. 依赖用户主动性：工作流的效果高度依赖用户是否愿意投入时间完成各阶段，缺乏强制性的进度追踪机制。
适合的目标群体
- 产品经理：需要系统化地规划和评审实验，向技术团队和利益相关者清晰传达实验设计。
- 数据分析师/科学家：作为实验设计阶段的协作工具，确保统计假设和业务目标对齐。
- 增长团队：在快速迭代中保持实验质量，避免"为了实验而实验"的陷阱。
- 初创公司技术负责人：建立实验文化初期，需要标准化流程但无力购买全套实验基础设施。
使用风险
- 性能风险：无，纯 Markdown 文档，零代码执行。
- 依赖项风险：无外部依赖，无需维护版本兼容性。
- 数据安全风险：不访问用户数据、不发起网络请求，符合 GDPR/CCPA。
- 决策误导风险：Skill 仅提供框架指导，实际统计显著性判断和因果推断仍需专业判断，用户不应将流程完成等同于实验设计正确。
- 组织采用风险：若团队缺乏统计基础，可能机械套用流程而忽视统计功效、多重比较校正等关键问题，建议搭配统计培训或专家咨询使用。