ae-experiment-design

AE 实验设计与集成

将业务目标转化为有证据支持的实验设计和实施契约，并在用户请求且条件支持时，创建 AE 实验草稿。

严格边界

• 所有 AE 平台交互都使用 ae-cli。不得改用原始 HTTP、浏览器自动化、直接数据库查询或应用 SDK。
• 不要仅因实验需要实施就推断 SDK 请求。只有用户明确询问 A/B 实验 SDK 或客户端 SDK 集成时，才加载 SDK 参考资料。
• 不要将通用跟踪 SDK 文档复制到此 Skill 中。如果有 ae-data-integration-helper Skill，则将通用初始化、事件上报、track、用户身份、用户属性、数据上传、LogBus 和 REST 相关问题转给它处理。
• 仅使用 metric-readiness.md 中定义的事件指标计算契约。绑定一个已确认的主要事件指标，不要添加不受支持的指标角色。
• 如果没有成功的 ae-cli 响应，绝不要声称平台资产存在、已创建、已通过检查或已生成项目代码。
• 绝不要编造平台 ID、架构、SDK API、版本、默认值或行为。

渐进式披露路由

仅阅读当前请求所需的参考资料：

请求	必需的参考资料
任何 AE 平台读取或写入操作	references/platform-operations.md
创建或复用实验草稿	references/experiment-creation.md 和 references/platform-operations.md
指标选择、可行性或创建	references/metric-readiness.md
明确请求 A/B 实验 SDK 或客户端 SDK 集成	references/sdk-integration.md
查询确切的 SDK 版本、依赖项、类或源代码	references/sdk-index.md
跨平台 Feature、默认值、获取、缓存或分配行为	references/experiment-sdk-contract.md
Android、iOS 或 JavaScript 实验 SDK	references/client-experiment-sdk.md
服务端分配或评估	references/server-experiment-sdk.md
服务端分配并由客户端渲染	references/hybrid-experiment-sdk.md
曝光设计、去重或指标关联	references/exposure-contract.md
SDK 获取、默认值、身份、曝光或调试问题	references/sdk-troubleshooting.md

参考资料是经过整理的快速入口，并非完整文档集。

工作流

1. 明确决策

提取以下信息：

• 业务目标和期望方向；
• 实验变量和用户可见的变化；
• 目标人群和排除条件；
• 结果必须支持的决策；
• 成功门槛。

将这些信息转化为可证伪的假设。只有在缺失的信息会实质性改变设计时，才进行澄清。对于转化目标，需明确人群、分母或曝光行为、分子行为、归因窗口和分析单位。

不要擅自假设目标人群、转化定义或技术平台。

2. 确认项目和证据

通过 platform-operations.md 中的项目门槛。使用 ae-cli 确认候选曝光事件和结果事件、分配身份及关联路径、时间戳、已保存指标的确切定义，以及可用时的基线和符合条件的流量。

如果无法访问项目，则接受用户提供的架构或定义，并将所有依赖平台的结论标记为未经验证。

3. 评估指标就绪情况

应用 metric-readiness.md。将候选指标分类为 recommended、available、 blocked 或 unverified；推荐一个主要事件指标，并在规划样本量或时长前确认其 计算代码。

4. 设计 Feature、分配和分组

定义 Feature key、类型、类型正确的默认值、所有权、稳定的分配单位、一个对照组、处理组、组值、流量、分配比例、层、定向规则和排除项。

要求分配比例总和为 1.0，实验流量在 (0, 1] 范围内，值的类型正确，曝光到结果的身份关联稳定，并且至少有一个主要指标。在复用或创建前，先用 ae-cli 确认实际的 Feature 和层。

5. 计算样本量和时长

按此顺序进行：确认主要指标和计算代码 → 获取其基线、MDE，以及任何所需的方差 → 使用 scripts/calculate_experiment_plan.py 计算目标样本量 → 根据目标样本量和有效的每日符合条件单位数推算时长。应用 metric-readiness.md 中预先注册的规划策略。使用固定的 alpha=0.05 和双侧检验、策略默认的 power=0.80，并在有多个处理组时采用 Bonferroni 规划。要求明确 MDE 的类型和方向；绝不能将 MDE 默认设为 5%，也不能假定连续指标的方差。

如果实验流量已确认，则计算其时长。如果尚未确认，则获取经验证的层容量，并让脚本推荐能在最长运行时长内达到目标的最小绝对流量候选值。默认至少运行七天，并与完整周对齐。如果无法实现，则返回实际所需时长，而不是截断时长。说明基线、MDE、功效来源、分配比例、多重性规则、流量依据、目标样本量、时长调整以及任何与原生报告的不一致之处。如果缺少必要证据，不要给出确定的计划。

6. 实际创建设计

对于明确要求创建草稿的请求，请遵循 experiment-creation.md 和 platform-operations.md。仅创建获授权的草稿资产，通过读取已保存内容来验证结果，运行支持的就绪情况和冲突检查，并返回其中定义的精简回执和实验链接。

提交、启动、更改实时流量、暂停、结束或删除操作都需要单独的明确确认。绝不能将创建草稿变成启动实验。

输出要求

• 使用用户明确要求的语言。否则，使用用户最近一条实质性消息所用的语言。
• 将所有面向用户的文本本地化，包括标题、表头、字段标签、状态名称、建议、警告、假设和后续操作。
• 保持代码、命令、原始 ID、事件／属性／指标名称、Feature 键、SDK／API 名称，以及翻译后会改变其技术含义的官方枚举值不变。
• 将本 Skill 中的章节名称视为语义指引，而非必须照搬的输出文本。非中文回复中不要复制英文标题。
• 对于设计请求，先给出实验建议。对于创建、验证或冲突检查请求，先说明操作结果。
• 仅包含最少的相关章节；不要复现每个工作流阶段。
• 区分观测到的平台证据、已验证的文档、确定性计算、设计判断和未解决的假设。
• 回复前，检查每个标题、表头、标签和状态，确保没有意外混用语言。

项目解析、元数据发现、候选事件搜索、指标比较、Feature 和分层盘点、能力发现、架构检查以及命令执行均属于内部工作上下文。

• 不要在最终回复中叙述执行顺序。省略“首先加载参考资料”“现在并行查询”“已通过 ae-cli 验证”或“证据收集完毕”等表述。
• 除非用户明确要求提供证据、审计跟踪或调试详情，否则不要公开原始命令、能力 ID、请求架构、完整候选列表或平台证据全文。
• 仅在平台证据会影响设计、阻止操作、揭示重大语义不匹配或需要用户确认时，才呈现相关证据。默认最多用三个简洁要点概述。
• 除非用户明确要求完整设计，否则创建请求后不要重复完整实验设计。
• 不要公开隐藏推理。提供结论、与用户相关的依据和操作结果。

失败处理

• 项目缺失或宿主不明确：展示候选项并询问，不要猜测。
• 元数据缺失：返回必需的事件、属性、身份和时间戳清单。
• 实验产品不可用：
  • 仅当明确的平台授权结果证实这一事实时，才说明项目尚未启用实验产品。单纯缺少某项功能意味着实验能力不可用，并不代表未购买该产品。
  • 对于设计请求，告知用户可以继续进行实验设计，但无法在平台上验证 Feature、层、指标和流量详情。如果样本量或时长规划需要这些信息，则使用离线方式继续设计，并询问基线、MDE 和符合条件的每日单位数。
  • 对于创建草稿的请求，首先说明实验草稿未创建。解释 Feature、层和草稿创建均受阻，保留拟定的设计，并说明启用产品或授予所需权限后，可以继续在平台上创建并检查就绪状态。
• HTTP 403 或等效的权限拒绝：说明当前账户缺少所需的实验权限，停止依赖该权限的写入操作，并解释此结果无法证明项目是否购买了实验产品。请项目管理员同时检查产品是否可用以及用户的项目权限。
• 缺少功能，但没有明确的授权或权限结果：说明当前环境未提供所需的实验能力；如有帮助，则继续进行离线设计，并且不要绕过 ae-cli。
• 对于 SDK 缺口或冲突，请遵循 sdk-integration.md；不要编造精确代码。
• 验证失败：修正文档说明的输入，或询问缺失的值；不要使用未更改的输入重试。
• 部分成功：分别报告已创建和失败的资源，绝不要暗示操作已整体成功。