A/B 测试文档模板体系实战指南：从实验计划、结果复盘到增长实验程序的全套可复用模板

A/B 测试文档模板体系实战指南从实验计划、结果复盘到增长实验程序的全套可复用模板【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills导读在 A/B 测试中实验的设计质量与文档化程度往往直接决定结论能否被正确复现、积累与复用。本指南以 AASagentic-awesome-skills仓库中ab-testing技能的模板参考文档为核心系统讲解一套覆盖实验全生命周期的文档模板体系测试计划Test Plan、结果文档Results Documentation、测试仓库条目Test Repository Entry、快速测试简报Quick Test Brief、干系人更新Stakeholder Update、实验优先级计分卡Experiment Prioritization Scorecard与假设银行Hypothesis Bank。读完本文你将掌握如何用统一结构规划每一个实验、如何用统计严谨的方式记录与解读结果、如何建立可持续增长实验程序Growth Experimentation Program并了解这套模板与技能中假设框架、样本量计算、指标分层等核心方法论如何衔接。本文以 test-templates.md 为主体内容并结合 SKILL.md技能主文档、sample-size-guide.md样本量参考与 evals.json评估用例进行纵深解读。模板体系总览为什么实验需要标准化文档模板参考文档开篇即点明其定位Templates for planning, documenting, and analyzing experiments用于规划、记录与分析实验的模板。它提供了七种文档模板覆盖一个实验从立项到复盘再到沉淀的全过程Test Plan Template测试计划模板——实验前的规划蓝本承载假设、实验设计、变体、指标与上线检查清单Results Documentation Template结果文档模板——实验结束后的结论记录包含统计显著性与实际显著性的双重判断Test Repository Entry Template测试仓库条目模板——在统一位置追踪所有测试的索引表Quick Test Brief Template快速测试简报模板——适合简单测试的轻量记录Stakeholder Update Template干系人更新模板——实验进行中的进度同步Experiment Prioritization Scorecard实验优先级计分卡——决定先跑哪个实验的量化工具Hypothesis Bank Template假设银行模板——持续收集实验想法的待办池。这七个模板并非孤立存在。在技能主文档 SKILL.md 中ab-testing技能被定位为当用户需要规划、设计或实施 A/B 测试/实验或构建增长实验程序时使用的专家级工具其目标在于帮助设计统计有效、可执行的测试。因此模板文档是这套方法论的可落地载体——SKILL.md 定义了怎么想核心原则、假设框架、统计严谨性模板则定义了怎么记统一的文档结构。核心方法论前提模板背后的设计原则在使用任何模板之前理解技能主文档中的四条核心原则有助于你正确填充模板内容从假设出发Start with a Hypothesis不是看看会发生什么而是基于推理或数据做出具体的结局预测。模板中的 Hypothesis 字段与 SKILL.md 提供的假设框架一一对应。单次测试只改一个变量Test One Thing一次测试一个变量否则无法知道是什么起了作用。模板的 Variants 部分要求列出具体变更 #1、#2正体现了这一约束。统计严谨性Statistical Rigor预先确定样本量不要偷看结果提前停止坚持预定方法。模板的 Success Criteria 与样本量记录字段即为这一原则的落点。衡量真正重要的指标Measure What Matters主指标Primary关联业务价值次要指标Secondary提供上下文护栏指标Guardrail防止伤害。模板将 Metrics 分为三层正是这一原则的体现。技能的假设框架Hypothesis Framework原文如下Because [observation/data], we believe [change] will cause [expected outcome] for [audience]. Well know this is true when [metrics].SKILL.md 同时给出了强弱假设的对比示例弱假设是Changing the button color might increase clicks.改变按钮颜色可能会增加点击强假设是Because users report difficulty finding the CTA (per heatmaps and feedback), we believe making the button larger and using contrasting color will increase CTA clicks by 15% for new visitors. Well measure click-through rate from page view to signup start.因为用户反馈难以找到 CTA——依据热力图与用户反馈我们相信将按钮加大并使用对比色将使新访客的 CTA 点击率提升 15% 以上我们将测量从页面浏览到注册开始的点击率。对比可见强假设具备观测依据、具体变化、量化预期与明确测量指标——这正是模板中假设段落要求填写的标准。测试计划模板把实验设计固化为可评审文档模板结构逐字段解读测试计划模板Test Plan Template是七个模板中最核心的一份包含以下区块Overview概览# A/B Test: [Name] ## Overview - **Owner**: [Name] - **Test ID**: [ID in testing tool] - **Page/Feature**: [Whats being tested] - **Planned dates**: [Start] - [End]概览字段用于建立实验的身份信息负责人Owner保证责任清晰测试 ID 与测试工具中的编号对应便于跨系统检索页面/功能字段明确被测对象计划日期框定时间范围。从技能主文档的Initial Assessment看在设计测试前应当先理解测试上下文想改进什么、考虑什么变更、当前状态基准转化率、当前流量、约束技术复杂度、时间线、可用工具这些信息都会沉淀进 Overview 与后续区块。Hypothesis假设Because [observation/data], we believe [change] will cause [expected outcome] for [audience]. Well know this is true when [metrics].此处直接采用 SKILL.md 定义的假设框架。撰写时注意观察/数据部分要引用真实的证据来源如热力图、用户反馈、分析数据期望结局要尽量可量化如提升 15% 以上指标部分要指出具体的测量方式。Test Design实验设计以表格形式固化实验的技术参数ElementDetailsTest typeA/B / A/B/n / MVTDurationX weeksSample sizeX per variantTraffic allocation50/50Tool[Tool name]ImplementationClient-side / Server-side结合 SKILL.md 的说明这些字段背后的方法论包括测试类型A/B两个版本、单一变更、流量需求中等、A/B/n多个变体、流量需求更高、MVT多变更组合、流量需求非常高、Split URL不同 URL 承载变体。评估用例 evals.json 中第二个用例正是一个典型场景用户想同时测试 4 种不同的 CTA 按钮颜色这应被识别为 A/B/n 测试并需要警示4 个变体比简单 A/B 测试需要显著更多的流量。样本量依据 sample-size-guide.md 的快速参考表需要四个输入基准转化率Baseline conversion rate、最小可检测效应MDE、统计显著性水平通常 95%α0.05、统计功效通常 80%β0.20。例如基准转化率 3% 时检测 20% 提升需要约 31,000/变体检测 50% 提升需要约 5,200/变体。流量分配标准 A/B 默认 50/50保守方案用 90/10、80/20 以限制劣质变体风险技术风险较高时可采用从小到大的渐进分配Ramping。实现方式客户端Client-side用 JavaScript 在页面加载后修改 DOM实施快但有闪烁flicker风险常用工具有 PostHog、Optimizely、VWO服务端Server-side在渲染前确定变体无闪烁但需要开发工作常用工具有 PostHog、LaunchDarkly、Split。Variants变体### Control (A) [Screenshot] - Current experience - [Key details about current state] ### Variant (B) [Screenshot or mockup] - [Specific change #1] - [Specific change #2] - Rationale: [Why we think this will win]控制组描述当前体验与现状细节变体组列出具体变更并附上理由Rationale。SKILL.md 中Designing Variants章节给出了可变更的类别清单标题/文案信息角度、价值主张、具体性、语气、视觉设计布局、颜色、图片、层级、CTA按钮文案、大小、位置、数量、内容信息量、顺序、社交证明。同时强调最佳实践变更要单一、有意义足够大胆以产生差异且忠于假设。Metrics指标三层指标结构是本模板的精华### Primary - **Metric**: [metric name] - **Definition**: [how its calculated] - **Current baseline**: [X%] - **Minimum detectable effect**: [X%] ### Secondary - [Metric 1]: [what it tells us] - [Metric 2]: [what it tells us] - [Metric 3]: [what it tells us] ### Guardrails - [Metric that shouldnt get worse] - [Another safety metric]SKILL.md 的说明主指标是与假设直接关联、用来判定测试结果的那个指标次要指标支撑主指标的解读解释变化为何/如何生效护栏指标是不应该变差的指标若显著变差应停止测试。SKILL.md 给出的定价页示例主指标 套餐选择率次要指标 页面停留时长、套餐分布护栏指标 支持工单数、退款率。评估用例 5 展示了一个完整应用测试长表单新增公司规模和职位字段vs 短表单时主指标为表单完成率次要指标为线索质量SQL 转化率、注册后激活率护栏指标为总体注册量——并应指出转化数量与线索质量之间的权衡以及下游指标需要更长的观测窗口。Segment Analysis Plan分群分析计划- Mobile vs. desktop - New vs. returning visitors - Traffic source - [Other relevant segments]预先规划分群分析移动端 vs 桌面端、新访客 vs 回访访客、流量来源等。值得注意的是sample-size-guide.md 特别指出常见样本量错误 #4忽略分群——若计划做分群分析应按最小分群计算样本量而不是按全量流量计算后再做分群分析。Success Criteria成功判据- Winner: [Primary metric improves by X% with 95% confidence] - Loser: [Primary metric decreases significantly] - Inconclusive: [What well do if no significant result]在实验开始前就写清楚三种可能结局的判定标准与处置预案这能有效避免事后解释hindsight bias与偷看问题。SKILL.md 的Interpreting Results表提供了结论框架显著胜出 → 实施变体显著失败 → 保留对照组并分析原因无显著差异 → 需要更多流量或更大胆的测试信号混杂 → 深入挖掘或分群分析。Pre-Launch Checklist上线前检查清单- [ ] Hypothesis documented and reviewed - [ ] Primary metric defined and trackable - [ ] Sample size calculated - [ ] Test duration estimated - [ ] Variants implemented correctly - [ ] Tracking verified in all variants - [ ] QA completed on all variants - [ ] Stakeholders informed - [ ] Calendar hold for analysis date这份清单与 SKILL.mdRunning the Test章节的 Pre-Launch Checklist 高度一致假设已记录、主指标已定义、样本量已计算、变体实现正确、追踪已验证、所有变体完成 QA可视为上线前的硬性关卡。结果文档模板以统计严谨性复盘实验Summary摘要# A/B Test Results: [Name] ## Summary | Element | Value | |---------|-------| | Test ID | [ID] | | Dates | [Start] - [End] | | Duration | X days | | Result | Winner / Loser / Inconclusive | | Decision | [What were doing] |结果文档以摘要开场直接给出结论性信息方便后续检索与引用。Results结果样本量达成情况### Sample Size | Variant | Target | Actual | % of target | |---------|--------|--------|-------------| | Control | X | Y | Z% | | Variant | X | Y | Z% |这是分析的第一步——SKILL.md 的Analysis Checklist明确要求先确认是否达到样本量若未达到则结果只是初步的。评估用例 7 的场景定价页测试 4 周对照组 2.1% 转化、变体 2.4% 转化、每变体 12,000 访客正是检验这一步的典型从 2.1% 基准检测 0.3 个百分点提升约 14% 相对提升需要先核对 12,000/变体的样本量是否足够。主指标结果### Primary Metric: [Metric Name] | Variant | Value | 95% CI | vs. Control | |---------|-------|--------|-------------| | Control | X% | [X%, Y%] | — | | Variant | X% | [X%, Y%] | X% | **Statistical significance**: p X.XX (95% sig / not sig) **Practical significance**: [Is this lift meaningful for the business?]模板在此处引入两个关键概念——统计显著性p 值95% 置信度即 p0.05意味着结果随机发生的概率小于 5%与实际显著性这个提升对业务是否真的有价值。SKILL.md 的 Analysis Checklist 第 3 步要求将效应量effect size与 MDE最小可检测效应和项目影响做对比。评估用例 7 进一步要求区分统计显著与实际显著并在结果处于临界状态时建议做分群分析或后续测试。次要指标与护栏指标### Secondary Metrics | Metric | Control | Variant | Change | Significant? | |--------|---------|---------|--------|--------------| | [Metric 1] | X | Y | Z% | Yes/No | ### Guardrail Metrics | Metric | Control | Variant | Change | Concern? | |--------|---------|---------|--------|----------| | [Metric 1] | X | Y | Z% | Yes/No |Analysis Checklist 的第 4、5 步对应这两个表格次要指标是否与主指标一致护栏指标是否有任何一项变差在 SKILL.md 中护栏指标显著变差是即使主指标胜出也应停止测试的信号之一。分群分析### Segment Analysis **Mobile vs. Desktop** | Segment | Control | Variant | Lift | |---------|---------|---------|------| | Mobile | X% | Y% | Z% | | Desktop | X% | Y% | Z% | **New vs. Returning** | Segment | Control | Variant | Lift | |---------|---------|---------|------| | New | X% | Y% | Z% | | Returning | X% | Y% | Z% |模板预设了移动端 vs 桌面端、新访客 vs 回访访客两个最常见的分群维度。注意 SKILL.md 的Common Mistakes清单警告了挑选分群Cherry-picking segments的错误——分群分析应在实验计划阶段预先声明而不是事后挑选有利的分群来证明结论。Interpretation解读与 Decision决策## Interpretation ### What happened? [Explanation of results in plain language] ### Why do we think this happened? [Analysis and reasoning] ### Caveats [Any limitations, external factors, or concerns] ## Decision **Winner**: [Control / Variant] **Action**: [Implement variant / Keep control / Re-test] **Timeline**: [When changes will be implemented]解读部分用通俗语言解释发生了什么、为什么我们认为这发生了并诚实记录限制条件外部因素、环境变化、样本偏差等。决策部分明确胜者、行动方案与实施时间线。SKILL.md 的Analysis Checklist第 2 步提醒统计显著不等于保证它只是一个阈值——95% 置信度意味着结果随机发生的概率低于 5%。Learnings学习沉淀### What we learned - [Key insight 1] - [Key insight 2] ### What to test next - [Follow-up test idea 1] - [Follow-up test idea 2] ### Impact - **Projected lift**: [X% improvement in Y metric] - **Business impact**: [Revenue, conversions, etc.]学习沉淀环节将单次实验的结论转化为组织的知识资产包括学到了什么、下一步测试什么、预计提升与业务影响。这与 SKILL.md 中Growth Experimentation Program章节的实验循环Experiment Loop第 5、6 步衔接——将胜者推广到 playbook、从学习中发现新假设。测试仓库条目模板统一索引所有实验对于需要在统一位置追踪所有测试的团队模板提供了一张极简索引表| Test ID | Name | Page | Dates | Primary Metric | Result | Lift | Link | |---------|------|------|-------|----------------|--------|------|------| | 001 | Hero headline test | Homepage | 1/1-1/15 | CTR | Winner | 12% | [Link] | | 002 | Pricing table layout | Pricing | 1/10-1/31 | Plan selection | Loser | -5% | [Link] | | 003 | Signup form fields | Signup | 2/1-2/14 | Completion | Inconclusive | 2% | [Link] |每条记录包含测试 ID、名称、页面、日期、主指标、结果Winner/Loser/Inconclusive、提升幅度与链接。这个索引表是测试仓库Test Repository的核心入口与每个测试的完整结果文档通过 Link 列互相关联。从增长实验程序视角看这张表也是衡量实验速度Experiment Velocity的基础数据源——SKILL.md 建议追踪每月启动实验数大多数团队 4-8 个、胜率成熟程序通常 20-30%持续更高可能意味着假设过于保守、平均测试时长2-4 周、待办深度20 个假设排队与累计提升所有胜者的复合收益。快速测试简报模板轻量实验的低成本记录对于不需要完整文档化的简单测试模板提供了一句话级别的简报结构## [Test Name] **What**: [One sentence description] **Why**: [One sentence hypothesis] **Metric**: [Primary metric] **Duration**: [X weeks] **Result**: [TBD / Winner / Loser / Inconclusive] **Learnings**: [Key takeaway]六个字段分别对应做什么一句话描述、为什么一句话假设、指标主指标、时长、结果状态与关键收获。它保留了完整模板的要素骨架假设、指标、结果、学习但将每项压缩到一句话适合假设明确、变更单一、风险较低的快速验证。注意即使使用简报假设框架的完整性仍不可省略——SKILL.md 的常见错误清单将没有清晰假设列为测试设计的三大错误之一。干系人更新模板实验进行中的透明沟通实验运行期间的定期沟通同样需要标准化## A/B Test Update: [Name] **Status**: Running / Complete **Days remaining**: X (or complete) **Current sample**: X% of target ### Preliminary observations [What were seeing - without making decisions yet] ### Next steps [What happens next] ### Timeline - [Date]: Analysis complete - [Date]: Decision and recommendation - [Date]: Implementation (if winner)模板的关键设计是Preliminary observations初步观察栏的定位说明——What were seeing - without making decisions yet我们看到什么——但暂不做决策。这正是 SKILL.md 中Peeking Problem偷看问题的制度化防护在达到预定样本量之前观察仅供监控技术问题与护栏指标不用于提前判定胜负。SKILL.md 明确警告在达到样本量之前查看结果并提前停止会导致假阳性和错误决策应当预先承诺样本量并信任流程。评估用例 3 精确复现了这一场景实验运行 3 天、变体 B 以 95% 置信度领先时能否提前判定正确答案是立即指出偷看问题、解释提前停止会虚增假阳性率、建议跑完预定周期并说明为何早期显著性具有误导性均值回归、星期效应、受众构成漂移仅在采用序贯测试Sequential Testing等专门方法时才允许提前停止。干系人更新的时间线部分分析完成 → 决策与建议 → 实施则与 SKILL.md 的实验节奏建议对齐每周30 分钟审查运行中实验的技术问题与护栏指标双周结束已完成实验、分析结果、更新 playbook 并从待办中启动下一个实验每月1 小时审视实验速度、胜率与累计提升补充假设待办并用 ICE 重新排序每季度审计 playbook。实验优先级计分卡用加权评分决定先跑哪个实验当假设银行积累了大量想法而流量与工程资源有限时需要一套量化排序机制。模板给出的计分卡如下FactorWeightTest ATest BTest CPotential impact30%Confidence in hypothesis25%Ease of implementation20%Risk if wrong15%Strategic alignment10%TotalScoring: 1-5 (5 best)计分卡从五个维度加权评估潜在影响30%、假设置信度25%、实施容易度20%、出错风险15%、战略对齐10%每项按 1-5 分打分5 分为最优后加权求和。这与 SKILL.mdGrowth Experimentation Program章节介绍的ICE 评分Impact Confidence Ease各 1-10 分后取平均互为补充ICE 更轻量、适合快速初筛而本模板的加权计分卡允许团队按自身业务优先级调整权重例如高风险行业可将出错风险权重上调。SKILL.md 建议每月在上下文变化时重新评分。假设银行模板持续积累实验想法假设银行Hypothesis Bank是增长实验程序待办池backlog的载体| ID | Page/Area | Observation | Hypothesis | Potential Impact | Status | |----|-----------|-------------|------------|------------------|--------| | H1 | Homepage | Low scroll depth | Shorter hero will increase scroll | High | Testing | | H2 | Pricing | Users compare plans | Comparison table will help | Medium | Backlog | | H3 | Signup | Drop-off at email | Social login will increase completion | Medium | Backlog |每条假设记录包含 ID、页面/区域、观察Observation、假设Hypothesis、潜在影响与状态Testing/Backlog 等。SKILL.md 的Hypothesis Generation章节为填充这张表提供了六类想法来源分析数据流失点、低转化页面、表现不佳的分群、客户研究痛点、困惑、未满足的预期、竞品分析他们使用而你没有的功能、信息或 UX 模式、支持工单关于转化流程的反复出现的问题或投诉、热力图/录屏用户犹豫、rage-click 或放弃的位置、过往实验显著失败的测试往往揭示值得尝试的新角度。结合模板中的示例一条高质量假设银行记录应当观察部分具体低滚动深度假设部分可检验缩短 hero 区域将提升滚动影响评级明确高/中/低状态清晰可追踪。模板的实践衔接从单次测试到持续增长引擎将七个模板串联起来便形成了一套完整的工作流与 SKILL.md 定义的实验循环Experiment Loop无缝对接1. Generate hypotheses (from data, research, competitors, customer feedback) 2. Prioritize with ICE scoring 3. Design and run the test 4. Analyze results with statistical rigor 5. Promote winners to a playbook 6. Generate new hypotheses from learnings → Repeat对应到模板体系假设生成阶段使用假设银行模板收集想法优先级排序阶段使用实验优先级计分卡或 ICE 评分筛选出最先运行的实验设计与运行阶段使用测试计划模板固化设计用快速测试简报模板处理轻量实验用干系人更新模板保持运行中的沟通分析与复盘阶段使用结果文档模板记录统计显著性与实际显著性判断沉淀与索引阶段使用测试仓库条目模板建立统一索引胜出的实验进一步沉淀为 playbook 条目SKILL.md 提供了专门的 Experiment Playbook 格式包含日期、假设、样本量、结果、护栏指标、分群差异、原因分析、可复用模式、适用页面与状态字段。评估用例 evals.json 中的 7 个场景恰好覆盖了这一工作流的典型节点用例 1首页标题 A/B 测试规划对应测试计划模板的完整产出用例 24 种 CTA 颜色的 A/B/n 警示对应测试类型与样本量判断用例 33 天后 95% 置信度能否提前判定对应偷看问题的纪律用例 4MVT 多变量测试对应测试类型选择与流量评估用例 5长表单测试的指标分层对应三层指标框架用例 6文案任务与测试任务的边界对应技能间的协作分工用例 7结果显著性评估与是否上线对应结果文档模板的决策环节。常见错误警示模板之外的红线模板记录了应该怎么写而 SKILL.md 的Common Mistakes章节则划定了红线两者配合使用才能保证模板产出的质量测试设计阶段变更过小无法检测、同时测试太多东西无法隔离、没有清晰假设。执行阶段提前停止、测试中途修改变体、不检查实现是否正确。SKILL.md 特别强调Do not peek and stop early不要偷看并提前停止——在达到样本量之前查看结果并提前停止会导致假阳性与错误决策同时也应避免在实验中途修改变体、从新来源引入流量。分析阶段忽视置信区间、挑选分群、过度解读无显著差异的结果。此外sample-size-guide.md 针对样本量补充了五类常见错误功效不足无法检测现实效应对策是现实地设定 MDE、获取更多流量或干脆不测、功效过剩已显著但仍等样本量——这其实没问题因为已承诺样本量就应遵守、基准率错误应用特定指标与页面的转化率而非全站平均值、忽视分群若计划分群分析按最小分群计算样本、测试太多东西流量被过度切分应坚决排序、减少并发测试。当样本量要求过高、流量不足以支撑测试时指南给出的备选方案同样值得记入模板的评估环节增大 MDE只接受检测 20% 的提升、降低置信度到 90%有风险需记录、减少变体只测最有希望的变体、合并流量跨多个相似页面测试、前移到漏斗上游测试、用定性数据决策不测试、或接受更长的测试周期。结语A/B 测试模板参考文档提供的不是七张孤立的表格而是一套可组合、可扩展的实验文档体系计划阶段用测试计划模板锁定设计运行阶段用干系人更新模板保持透明收尾阶段用结果文档模板记录统计结论沉淀阶段用测试仓库、简报、计分卡与假设银行支撑增长实验程序的持续运转。这套体系的价值在于它把实验方法论中的纪律先假设、单变量、预计算样本量、不偷看、三层指标翻译成了具体的字段和表格让每个团队成员都能以统一标准产出可评审、可检索、可复用的实验文档。若需进一步掌握与模板配套的统计基础可继续阅读仓库中的 sample-size-guide.md样本量快速参考表、时长计算公式、多变体调整、序贯测试与快速决策框架若需了解整个技能的方法论全貌核心原则、测试类型、指标选择、流量分配、实施方式、增长实验程序与常见错误可阅读技能主文档 SKILL.md若想看到模板在实际场景中的预期应用方式可参考技能的 evals.json 评估用例。【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,600 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/GitHub_Trending/an/agentic-awesome-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考