Experiment Failure Analysis

---
name: experiment-failure-analysis
description: Systematically analyze experiment failures and optimization setbacks to identify root causes and define validation plans before abandonment decisions.
---

# Experiment Failure Analysis

## Description
系统化分析实验和优化方案失败的根本原因，避免轻易放弃方案。当测试结果不理想时，通过多层次的诊断框架深入分析问题，提出假设并设计验证实验，确保在充分论证后才做出放弃决策。

## Activation
当出现以下情况时**必须**调用此skill：
- 实验方案出现严重性能缺陷
- 优化方案的效果比原基础方案还差
- 优化方案的提升不明显或微乎其微
- 预期的改进没有实现
- 测试结果与理论预期严重不符

触发关键词：
- "性能下降"、"效果不佳"、"没有提升"
- "比原来还差"、"优化失败"
- "结果不理想"、"没有改善"
- "方案失效"、"实验失败"

## Instructions

### 核心原则
**禁止立即放弃方案**。必须经过完整的分析、假设提出、实验验证流程，并获得用户同意后才能放弃方案。

### 分析框架

执行以下四层诊断分析：

#### 1. 代码实现层面分析
首先排除实现错误：

- **代码正确性检查**
  - 逻辑是否正确实现了设计意图
  - 是否存在边界条件处理错误
  - 数据结构使用是否合理
  - 算法实现是否有bug

- **性能实现检查**
  - 是否存在不必要的计算重复
  - 数据访问模式是否高效
  - 内存使用是否合理
  - 是否存在隐藏的性能瓶颈

**输出**：明确指出代码层面的问题（如果有），或确认代码实现正确。

#### 2. 方案设计层面分析
检查设计本身的合理性：

- **设计逻辑审查**
  - 方案的理论基础是否正确
  - 设计思路是否存在逻辑漏洞
  - 优化目标是否明确且可达
  - 是否考虑了所有关键因素

- **适用性分析**
  - 方案是否适合当前问题的特征
  - 问题规模是否在方案的适用范围内
  - 数据特征是否符合方案的前提条件
  - 是否存在方案与问题的不匹配

**输出**：评估设计的合理性，指出潜在的设计缺陷。

#### 3. 假设验证层面分析
深入检查方案的基础假设：

- **识别核心假设**
  - 方案基于哪些关键假设
  - 这些假设是显式的还是隐式的
  - 假设的合理性如何

- **假设验证**
  - 设计小型实验验证每个假设
  - 收集数据检验假设是否成立
  - 量化假设与实际的偏差
  - 分析假设失效的影响范围

**输出**：列出所有假设及其验证结果，明确哪些假设不成立。

#### 4. 环境和测试层面分析
排除外部因素干扰：

- **测试环境检查**
  - 测试条件是否公平一致
  - 是否存在测试偏差
  - 数据集是否代表性
  - 评估指标是否合理

- **对比基准检查**
  - 基准方案是否正确实现
  - 对比是否在相同条件下进行
  - 是否存在测量误差

**输出**：确认测试的有效性，排除测试问题。

### 综合分析报告

完成四层分析后，生成结构化报告：

#### 失败原因分析
```
1. 主要原因：[最可能的失败原因]
   - 证据：[支持这一结论的证据]
   - 影响程度：[量化影响]

2. 次要原因：[其他可能的原因]
   - 证据：[...]
   - 影响程度：[...]

3. 不确定因素：[需要进一步验证的因素]
```

#### 可能性假设
```
假设1：[具体假设描述]
- 理论依据：[...]
- 验证方法：[如何验证这个假设]
- 预期结果：[如果假设成立，应该观察到什么]

假设2：[...]
[...]
```

#### 验证实验方案
为每个假设设计具体的验证实验：

```
实验1：验证[假设1]
- 目的：[...]
- 步骤：
  1. [...]
  2. [...]
- 预期结果：[...]
- 判断标准：[如何根据结果判断假设是否成立]

实验2：验证[假设2]
[...]
```

#### 改进方向建议
基于分析提出可能的改进方向：

```
方向1：[改进方向]
- 理由：[为什么这个方向可能有效]
- 实施难度：[低/中/高]
- 预期效果：[...]

方向2：[...]
[...]
```

### 决策建议

基于完整分析，提供明确的建议：

- **如果问题可修复**：提供具体的修复方案和实施步骤
- **如果需要调整**：说明需要调整的部分和调整方向
- **如果建议放弃**：必须提供充分的论证，包括：
  - 已经尝试的所有验证实验及结果
  - 方案根本性缺陷的证据
  - 为什么无法通过修改来改进
  - 替代方案的建议

### 用户交互

在提供完整分析报告后：

1. **征求用户意见**
   - 用户是否同意分析结论
   - 用户是否有额外的观察或信息
   - 用户对验证实验的优先级建议

2. **执行验证实验**
   - 根据用户反馈调整实验方案
   - 逐个执行验证实验
   - 实时报告实验结果

3. **最终决策**
   - 只有在完成验证实验后才讨论是否放弃
   - 必须获得用户明确同意才能放弃方案
   - 如果放弃，提供替代方案建议

## Output Format

使用以下结构化格式输出分析结果：

```markdown
# 实验失败分析报告

## 问题概述
[简要描述实验方案和失败现象]

## 四层诊断分析

### 1. 代码实现分析
[分析结果]

### 2. 方案设计分析
[分析结果]

### 3. 假设验证分析
[分析结果]

### 4. 环境测试分析
[分析结果]

## 失败原因总结
[主要原因、次要原因、不确定因素]

## 可能性假设
[列出所有假设]

## 验证实验方案
[详细的实验设计]

## 改进方向建议
[具体的改进建议]

## 下一步行动
[建议的具体行动步骤]

---

**请确认**：
1. 您是否同意以上分析？
2. 是否需要补充其他信息？
3. 您希望优先执行哪些验证实验？
```

## Examples

### Example 1: 性能优化方案效果不佳

**场景**：实现了一个缓存优化方案，但测试发现性能反而下降了20%。

**分析过程**：
1. 代码检查：发现缓存查找使用了线性搜索而非哈希表
2. 设计审查：缓存策略本身合理，但缓存大小设置过小
3. 假设验证：假设"缓存命中率高"，实测只有15%
4. 测试检查：测试数据集的访问模式与生产环境不同

**结论**：方案设计合理，但实现有误且测试不充分。修复后性能提升40%。

### Example 2: 算法优化提升不明显

**场景**：将O(n²)算法优化为O(n log n)，但实际运行时间只减少了5%。

**分析过程**：
1. 代码检查：算法实现正确
2. 设计审查：理论复杂度分析正确
3. 假设验证：假设"n足够大"，实测n平均只有50，在此规模下常数因子占主导
4. 测试检查：发现真正的瓶颈在I/O而非计算

**结论**：优化方向错误，应该优化I/O而非算法复杂度。

## Notes

- 保持客观和系统化，避免主观臆断
- 用数据和实验结果说话
- 鼓励深入思考而非表面分析
- 即使方案最终需要放弃，分析过程本身也是宝贵的学习经验
- 记录所有分析过程和实验结果，为未来类似问题提供参考

## Version
1.0.0