experiment-brainstorm

实验构思

根据团队过去停止的实验提出新的实验想法。先阅读历史记录；根据哪些实验确实推动了指标、哪些护栏失效，以及哪些标签或项目探索不足来提出想法。

所有 API 调用都通过随附的辅助脚本进行：${CLAUDE_PLUGIN_ROOT}/scripts/gb-call。它需要 GB_API_KEY——可在 shell 中设置，或由 /growthbook:gb-setup 写入 ~/.config/growthbook/.env。如果未设置或无效，gb-call 的错误消息会指向 /growthbook:gb-setup。

工作流

1. 拉取实验列表，按创建时间从近到远排列。

   gb-call GET '/api/v1/experiments?limit=50&status=stopped&sortBy=dateCreated&sortOrder=desc'
   

   每页最多返回 50 个实验（limit 上限为 100）。保留 sortBy=dateCreated&sortOrder=desc——API 默认按从早到晚排序；对于历史记录超过一页的组织，不排序拉取会让每个提案都基于很久以前的实验。

   如果用户限定了构思范围（“结账相关的想法”“增长团队接下来该测试什么”），请用筛选条件缩小拉取范围，而不是事后丢弃结果：&tag=checkout、&projectId=prj_abc123、&owner=<email>、&result=won,lost、&metricId=met_abc123 或 &implementationType=feature。tag、owner、result、metricId 和 implementationType 可接受逗号分隔的值（同一参数内按 OR 处理）；projectId 接受单个项目 ID。不同参数之间按 AND 组合。

   如果用户想了解产品测试模式，可考虑添加 &bandits=false：bandit 结果提供的是各实验组的概率，而非胜负结论，因此会扭曲第 4 步的胜率统计。

2. 获取每个已停止实验的结果。 遍历已停止实验的 ID：

   gb-call GET /api/v1/experiments/<id>/results
   

   控制调用频率——API 的速率限制为每分钟 60 次请求。除非用户明确需要更多结果，否则最多拉取约 20 个实验；这足以发现模式，也远低于调用限额。

3. 分析模式。 在提出任何想法之前，先从结果数据中找出三点：

   • 哪些方法有效——测试变体胜过对照组的实验有哪些共同主题（涉及哪些项目、哪些界面、哪类改动）。
   • 哪些方法停滞不前——失败或结果不明确的测试有哪些共同主题。
   • 哪些领域探索不足——与其他领域相比，实验数量较少的项目、标签或界面。

4. 粗略汇总背景信息。 心中估算即可——无需展示完整仪表板：

   • 大致胜率（获胜 / 已有结论的总数）。
   • 按主要指标的绝对提升幅度列出前 3 个获胜实验。
   • 按绝对提升幅度列出前 3 个失败实验。
   • 是否有实验被标记为 SRM（样本比例不匹配）。
   • 项目 / 标签分布。

5. 提出 5–7 个想法。 每个提案包含：

   • 假设，用一句话说明：“如果我们改变 X，那么 Y 会改善，因为 Z。”
   • 依据——用一句话关联到具体的历史实验（扩展获胜实验、换种方式重试失败实验，或填补探索空白）。注明实验名称或 ID。
   • 主要指标——选一个。说明指标类型（比例、均值、比率、分位数）及原因。
   • 预期效果量级——只描述大致量级（例如“与结账流程测试提升 +3.2% 相当”），不要给出精确数字。
   • 需要关注的风险——一项护栏指标或潜在回归风险。

6. 按结构呈现。 先概述观察到的模式（每项 1–2 行），再列出提案。最后询问用户想进一步完善哪项——不要在此技能中开始设计或创建实验。将用户选中的想法交接给 experiment-design。

护栏

• 仅限已停止的实验。 从综合结果中排除草稿和正在运行的实验。如果用户询问当前运行中的实验流程，那是另一个问题——请引导他们使用 flag-discovery 或 experiment-design。
• 仅凭 result 不能判断实验已停止。 实验停止时会记录结果；即使之后重新启动，该结果仍会保留，因此 result=won 可能会返回正在运行的实验。查询中始终保留 status=stopped，不要依赖 result 来限定历史记录。
• 筛选 bandit 要用 bandits，而不是 type。 列表端点没有 type 参数——implementationType 用于筛选关联变更的类型（feature / visualChange / redirect），这与响应中的 type 字段（standard / multi-armed-bandit）是不同维度。发送 type= 会返回 400 错误。
• 每项提议都要有依据。 引用你所借鉴的具体过往实验。不要基于泛泛的最佳实践提出方案。
• 不要重复失败方案而不说明原因。 如果某项提议与近期失败的方案相似，请明确指出并解释这次有哪些不同。
• 胜率定义： won / (won + lost + inconclusive)。不要编造其他公式。
• 留意历史记录中的 SRM 和护栏问题。 如果许多实验都出现 SRM 失败，请指出这一点，并至少提出一个旨在改善实验规范的想法，而不是再做一个产品测试。
• 只提出方案，不要创建实验。 绝不要向 /api/v1/experiments 发送 POST 请求。用户接下来的步骤是使用 experiment-design 推进他们想要采用的方案。
• 避免为指标而提案。 每个想法只设一个目标指标（偶尔可以设两个）。不要提出包含五个指标、指望其中一个有所变化的测试——这是“目标指标过多”的常见陷阱。GrowthBook 的决策框架最多支持两个目标指标；更多指标会削弱统计效能，也会让上线或终止的决策变得混乱。
• 注意速率限制。 50 个实验 + 20 次结果查询 ≈ 21 次调用，远低于每分钟 60 次的上限。如果用户想要更深入的分析，请先征求同意，再将调用次数扩展到 40 次以上。

使用的端点

• GET /api/v1/experiments?limit=50&status=stopped&sortBy=dateCreated&sortOrder=desc — 列出已停止的实验，按时间从新到旧排序（limit 上限为 100）。可选的范围筛选条件：tag、owner、result、metricId、implementationType（同一参数中以逗号分隔的多个值按 OR 处理）、projectId（单个项目 ID）、bandits（true / false）、archived。可排序字段：dateCreated、dateUpdated、name。
• GET /api/v1/experiments/{id}/results — 获取单个范围内实验的完整结果。每个已停止的实验调用一次。

输出模板

## Patterns from your last N stopped experiments

- Working: <theme>
- Stalling: <theme>
- Under-explored: <theme>

## Proposed experiments

### 1. <short title>
- Hypothesis: …
- Grounded in: <past experiment + verdict>
- Primary metric: <name> (<type>)
- Expected effect: <order of magnitude>
- Risk: <guardrail>

…

Pick one or two and I'll hand off to `experiment-design` to scope it.