企业官网建设流程全解析

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 测试中，实验的设计质量与文档化程度往往直接决定结论能否被正确复现、积累与复用。本指南以 AAS（agentic-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（用于规划、记录与分析实验的模板）。它提供了七种文档模板，覆盖一个实验从立项到复盘再到沉淀的全过程：

1. Test Plan Template（测试计划模板）——实验前的规划蓝本，承载假设、实验设计、变体、指标与上线检查清单；
2. Results Documentation Template（结果文档模板）——实验结束后的结论记录，包含统计显著性与实际显著性的双重判断；
3. Test Repository Entry Template（测试仓库条目模板）——在统一位置追踪所有测试的索引表；
4. Quick Test Brief Template（快速测试简报模板）——适合简单测试的轻量记录；
5. Stakeholder Update Template（干系人更新模板）——实验进行中的进度同步；
6. Experiment Prioritization Scorecard（实验优先级计分卡）——决定先跑哪个实验的量化工具；
7. Hypothesis Bank Template（假设银行模板）——持续收集实验想法的待办池。

这七个模板并非孤立存在。在技能主文档 SKILL.md 中，ab-testing技能被定位为"当用户需要规划、设计或实施 A/B 测试/实验，或构建增长实验程序"时使用的专家级工具，其目标在于帮助设计"统计有效、可执行的测试"。因此，模板文档是这套方法论的可落地载体——SKILL.md 定义了"怎么想"（核心原则、假设框架、统计严谨性），模板则定义了"怎么记"（统一的文档结构）。

核心方法论前提：模板背后的设计原则

在使用任何模板之前，理解技能主文档中的四条核心原则有助于你正确填充模板内容：

1. 从假设出发（Start with a Hypothesis）：不是"看看会发生什么"，而是基于推理或数据做出具体的结局预测。模板中的 Hypothesis 字段与 SKILL.md 提供的假设框架一一对应。

2. 单次测试只改一个变量（Test One Thing）：一次测试一个变量，否则无法知道是什么起了作用。模板的 Variants 部分要求列出"具体变更 #1、#2"，正体现了这一约束。

3. 统计严谨性（Statistical Rigor）：预先确定样本量，不要"偷看"结果提前停止，坚持预定方法。模板的 Success Criteria 与样本量记录字段即为这一原则的落点。

4. 衡量真正重要的指标（Measure What Matters）：主指标（Primary）关联业务价值，次要指标（Secondary）提供上下文，护栏指标（Guardrail）防止伤害。模板将 Metrics 分为三层正是这一原则的体现。

技能的假设框架（Hypothesis Framework）原文如下：

Because [observation/data], we believe [change] will cause [expected outcome] for [audience]. We'll 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. We'll 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**: [What's being tested] - **Planned dates**: [Start] - [End]

概览字段用于建立实验的身份信息：负责人（Owner）保证责任清晰；测试 ID 与测试工具中的编号对应，便于跨系统检索；页面/功能字段明确被测对象；计划日期框定时间范围。从技能主文档的"Initial Assessment"看，在设计测试前应当先理解测试上下文（想改进什么、考虑什么变更）、当前状态（基准转化率、当前流量）、约束（技术复杂度、时间线、可用工具），这些信息都会沉淀进 Overview 与后续区块。

Hypothesis（假设）

Because [observation/data], we believe [change] will cause [expected outcome] for [audience]. We'll know this is true when [metrics].

此处直接采用 SKILL.md 定义的假设框架。撰写时注意：观察/数据部分要引用真实的证据来源（如热力图、用户反馈、分析数据），期望结局要尽量可量化（如"提升 15% 以上"），指标部分要指出具体的测量方式。

Test Design（实验设计）：以表格形式固化实验的技术参数：

结合 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 it's 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 shouldn't 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 we'll 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.md"Running 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 we're 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% 置信度即 p<0.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 we're 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 we're seeing - without making decisions yet（我们看到什么——但暂不做决策）。这正是 SKILL.md 中"Peeking Problem（偷看问题）"的制度化防护：在达到预定样本量之前，观察仅供监控技术问题与护栏指标，不用于提前判定胜负。SKILL.md 明确警告：在达到样本量之前查看结果并提前停止会导致假阳性和错误决策，应当预先承诺样本量并信任流程。评估用例 3 精确复现了这一场景：实验运行 3 天、变体 B 以 95% 置信度领先时能否提前判定？正确答案是立即指出偷看问题、解释提前停止会虚增假阳性率、建议跑完预定周期，并说明为何早期显著性具有误导性（均值回归、星期效应、受众构成漂移），仅在采用序贯测试（Sequential Testing）等专门方法时才允许提前停止。

干系人更新的时间线部分（分析完成 → 决策与建议 → 实施）则与 SKILL.md 的实验节奏建议对齐：每周（30 分钟）审查运行中实验的技术问题与护栏指标；双周结束已完成实验、分析结果、更新 playbook 并从待办中启动下一个实验；每月（1 小时）审视实验速度、胜率与累计提升，补充假设待办并用 ICE 重新排序；每季度审计 playbook。

实验优先级计分卡：用加权评分决定先跑哪个实验

当假设银行积累了大量想法而流量与工程资源有限时，需要一套量化排序机制。模板给出的计分卡如下：

Scoring: 1-5 (5 = best)

计分卡从五个维度加权评估：潜在影响（30%）、假设置信度（25%）、实施容易度（20%）、出错风险（15%）、战略对齐（10%），每项按 1-5 分打分（5 分为最优）后加权求和。这与 SKILL.md"Growth 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 测试规划）对应测试计划模板的完整产出；用例 2（4 种 CTA 颜色的 A/B/n 警示）对应测试类型与样本量判断；用例 3（3 天后 95% 置信度能否提前判定）对应偷看问题的纪律；用例 4（MVT 多变量测试）对应测试类型选择与流量评估；用例 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