ae-experiment-insight

AE 实验洞察与诊断

先验证证据，再解读效果。只有当实验可信度足以支持决策时，才给出决策。

平台与参考文档路由

所有 AE 平台交互都使用 ae-cli，并遵循 references/platform-operations.md； 绝不可替换为其他平台访问方式。

进行诊断时，阅读 references/diagnostic-playbook.md。 做出发布决策前，阅读 references/decision-framework.md。

工作流

1. 还原实验背景

确定具体的项目和实验。收集：

• 假设和预期决策；
• 对照组和实验组的定义；
• 分配单元、层、定向、流量和组别分配；
• Feature 和组别值；
• 主要、次要和诊断指标；
• 计划的 MDE、alpha、power、实验时长和停止规则；
• 实际开始／结束时间，以及重要配置变更。

如果没有原始假设或成功规则，应解释观察到的效果，但不得事后编造成功标准。

2. 检查实验运行完整性

确认实验的实际状态、完整运行周期，以及实验期间重要的 Feature、流量、受众、指标或身份变更。将配置历史视为证据。有关分配、曝光、样本充足性和实验设计质量的评估，应遵循诊断手册，不要在此重复其中的规则。

3. 运行数据诊断

按因果顺序应用 diagnostic-playbook.md，并完成其中的诊断清单。使用 scripts/analyze_experiment.py 检查 SRM 和组间比较；不要凭空估算 p 值或置信区间。

4. 解读效果

针对每个预注册指标，解读诊断手册中已验证的指标契约，并报告：

• 已验证的源事件、聚合方式、分析单元、分母或总体、筛选条件和归因窗口；
• 对照组和实验组的数值；
• 绝对差异和相对差异；
• 通过确定性计算或已验证的平台报告得出的置信区间和 p 值；
• 已达到的样本量与计划样本量；
• 与 MDE 和业务阈值的关系；
• 统计显著性和实际意义。

区分以下情况：

• 统计显著且具有实际价值；
• 统计显著但影响太小、不足以产生实际意义；
• 方向上为正面，但统计效力不足；
• 在当前精度范围内未检测到效果；
• 显著负面；
• 因数据质量问题而无效或无法得出结论。

不要将 p > alpha 转述为“没有效果”。应说明当前数据未能证实效果，并描述与数据相符的区间。

5. 分析趋势和细分群体

使用完整且可比较的周期检查趋势稳定性和异常日期。 遵循 decision-framework.md 中的趋势和细分群体规则。

6. 诊断原因

对于每个疑似原因，提供：

• 观察到的证据；
• 推断及其不确定性；
• 其他可能的解释；
• 用于区分这些解释的具体平台查询或产品检查；
• 确认原因后的补救措施。

不要列出与证据无关的通用原因。 在最终报告中，将区分性检查表述为简洁、面向用户的验证操作。只有当用户明确要求提供命令、审计记录或调试详情时，才包含原始 ae-cli 命令。

7. 做出决策

应用 decision-framework.md，并基于可信度评估、主要效果、实验时长、趋势、细分群体和诊断结果，给出一个决策。

除非用户另行要求执行相应平台操作，否则绝不可启动、暂停、结束、调整流量、删除或发布实验。这些操作不属于效果解读，且必须先明确确认目标和影响。

输出要求

• 如有明确指定的语言，使用该语言；否则使用用户最近一条实质性消息所用的语言。将所有面向用户的正文、标题、标签、状态、结论、警告、限制和后续行动本地化；将本 Skill 中的章节名称视为语义指引，并消除意外的中英混杂输出。
• 保持代码、命令、原始 ID、事件／属性／指标名称、Feature 键、SDK／API 名称以及官方枚举值不变，避免翻译改变其技术含义。
• 首先说明决策状态。
• 使用自适应报告，而非固定的编号模板。默认的面向用户内容层级为：结论、核心影响、实验决策，以及产品优化或下一步行动。
• 将数据可靠性、核心指标和关注指标放在核心影响部分：
  • 数据可靠性验证：概述诊断清单，并说明总体结果为可靠、有限或不可靠。简要说明正常检查，仅详细展开警告、失败或未经验证的检查。
  • 核心指标：列出主要指标的对照组和实验组数值、绝对和相对影响、区间和 p 值、与 MDE 或业务阈值的关系，以及业务意义。只有在可信度评估支持时，才使用因果措辞。
  • 关注指标：仅在次要指标和诊断指标会影响决策、解释作用机制或揭示重大风险时才列出。不得将事后发现的指标提升为成功标准。
• 对于简短回答，将这些小节合并为核心影响下的精简段落；不要将它们提升为无关的顶层章节。
• 将 material blockers、trust blockers、诊断严重性名称以及 Gate 1 或 Gate 2 等框架标签视为内部分类。不得将其作为报告标题向用户展示，也不得在本地化标题后附上英文名称。需要表达这些概念时，使用“数据可靠性验证”或“当前为什么不能下结论”等自然的面向用户表述。
• 将指标趋势和相关细分数据放在对应的核心指标或关注指标下。只有在更广泛的背景、原因诊断、假设或限制会实质性影响解读时，才纳入这些内容。
• 只有在可信证据支持具体产品改动时，才使用产品优化章节。否则，使用下一步验证或下一步行动章节。
• 仅包含请求和证据支持的内容。不要仅因先前报告包含某个章节就添加该章节。
• 区分平台观察结果、确定性计算和推断的原因。明确说明不确定性和证据缺口。
• 不要返回没有说明的原始表格。

失败处理

• 项目或实验不明确：列出已确定的候选项并询问，不要猜测。
• 缺少报告能力：保留 ae-cli 的缺口说明，并请求平台导出所需字段。
• 权限失败：停止依赖该权限的查询，并报告缺少的权限。
• 成功但报告为空：说明没有匹配的数据；不要将其重新描述为传输失败。
• 部分成功：使用可用证据并逐项列出失败情况。
• 来源冲突：优先使用原始分配／曝光证据诊断数据质量，并解释差异。