# Research Experiment

> Design experiments that decide something, and diagnose failing ones by driving from surface symptom to root technical cause before changing anything. Treats improving a method as SGD on the idea, where the root-cause analysis IS the gradient — so it outputs a ranked candidate-cause table with a falsifying experiment for each, never a list of things to try, and ships a fully worked example diagnosis to show the granularity. Also covers minimum-viable exploratory design (binary feasibility criterion, one-day version), what comparison/ablation/demo experiments a paper needs, and which harder data to push to. Use whenever the user reports bad results, a method that doesn't work, metrics dropping after a change, asks what to run next, or asks which ablations a paper needs — and use it BEFORE proposing hyperparameter tweaks, because an unverified guess about the cause is a random gradient that burns a whole cycle. 中文触发：实验不work、效果不好、掉点了、做什么实验、实验设计、消融、ablation、baseline、调不出来、为什么不收敛、要不要试试调参、做什么demo。

- Skill: `hughyau/research-experiment` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add hughyau/research-experiment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hughyau/research-experiment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: HughYau (https://skillmd.com/u/hughyau)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hughyau/research-experiment

---


# 实验设计与诊断

**改进方法 = 对 idea 做 SGD。** 目标函数 `|| Experiment(idea) − Target result ||`，
**"分析实验为什么不 work" 就是求梯度**。

由此得到唯一的效率判据：**每次循环是否产出了一条经过验证的本质技术原因。**
没有 → 这次循环的梯度是随机的，下一次改动等于掷骰子。
失败的实验不是浪费——它排除了一条路径，前提是那条路径被**写下来**了
（落进 `experiments/LOG.md`，见 `research-project`）。

## 一、设计实验

### 核心原则：减少 exploration points

一次实验里的未知量越多，结果越不可归因。两种分解，通常同时用：

| 分解 pipeline | 分解实验设置 |
|---|---|
| 把 idea 拆成组件，从**可控的**部分开始，逐步加入探索性模块 | 从**简单 setting** 开始，逐渐增加难度，最后进入真正的 setting |

### 简单实验：只存在 core technical challenge

```
明确解法要解决的 core technical challenge
   → 找出当前数据里还有哪些额外的 technical challenge
   → 寻找或构建不含这些额外 challenge 的数据
   → 在这样的数据上验证解法
```

好处是成本低、且**没有其他 challenge 的干扰**，能干净地判定解法本身是否 work。
顺序：简单数据验证正确性 → 简单数据上改进 → 真实数据上调 work。

### 探索性实验的最小可行性三步

**第一步：定义二元的可行性标准。**
这个实验要验证什么？成功标准是什么？**必须是二元、明确、可测量的**（是/否）。
写不出二元标准 = 还没想清楚要验证什么，此时做实验是浪费。

**第二步：设计最小的实验。** 用这句话倒逼：
> **"如果只有一天时间，我能做的最简单的验证是什么？"**

**第三步：对照标准判定，只导向三个方向之一。**

| 结果 | 下一步 |
|---|---|
| **成功** | 设计更严谨、更大规模的实验巩固；开始增加复杂度 |
| **失败** | 用最小成本排除了一条路径。分析是想法错还是实现错，据此 pivot 或终止 |
| **模糊** | **实验设计得不够好，标准没定清楚。**回第一步重定义 |

第三行最常被处理错：拿到模糊结果时**不要"再多跑几个 setting"**，
模糊结果重复几次仍然是模糊的。

## 二、诊断实验为什么不 work

```
表面原因  →  本质技术原因  →  用实验验证这个原因
```

三步都要走完。**只有确认真的是"技术原因"，改算法才有意义。**

**第 1 步 · 表面原因**：哪个变量一改就变差（换了数据 / 加了 module / 改了参数）。
方法是**对比 work 与不 work 的两组**，列出它们的具体差异。

**第 2 步 · 本质原因**：对表面原因问"为什么"，**列出尽量多的候选**。两类：

1. **代码有 bug**
2. **"xx 算法"在"xx 数据"上确实有问题**：超参没设对 / 缺了几个 tricks / 算法本身不行

区分第 2 类的手段：**看相关论文为什么能 work、用了什么 tricks**
（`literature-review` 检索 → `pdf-explore` 读实现细节），
**给相关论文的算法做 ablation** 看哪部分是关键。
有些 idea 单独拿出来不 work，加上 tricks 才 work（NeRF + positional encoding）。

**第 3 步 · 验证**：设计实验逐个证伪。**跳过验证直接改算法 = 猜的梯度。**

### 输出模板

用户说"实验不 work"时，**不要直接给改进建议**。先产出这张表；
缺哪一格就去补，补不出来就明说"这一格需要你提供 X"。

```markdown
## 诊断：<一句话现象>

**表面原因**：<哪个变量一改就变差>
**对照**：work = <配置>　　不 work = <配置>　　**差异**：<具体列出，不写"设置不同">

| # | 候选本质原因 | 支持证据 | 反对证据 | 怎么用一个实验证伪 |
|---|---|---|---|---|
| 1 | 代码 bug：<具体哪里> | | | |
| 2 | 超参：<哪个> | | | |
| 3 | 缺 tricks：<论文 X 用了 Y> | | | |
| 4 | 算法本身不行：<为什么> | | | |

**下一个实验**（只验证一条，exploration points = 1）
- 验证第 <N> 条　- 二元标准：<若…则该原因成立>　- 最小设计：<一天能做完的版本>

**还需要你提供**：<看不到的信息，如训练日志、baseline 配置>
```

自检：**"下一个实验"是从表里推出来的，还是先想好再倒填的？**
后者说明在合理化直觉，不是在求梯度。

填满的实例：[references/diagnosis-example.md](references/diagnosis-example.md)
（depth prior 监督后掉点的完整诊断）。它示范三件事：
"差异"一格要写到具体配置、候选原因里必须有"代码 bug"这一类、
以及候选的**执行顺序按排查成本排而不是按可能性排**——十分钟能排除的先做。

## 三、论文需要哪些实验

实验规划倒推自论文要回答的三个问题：

| 问题 | 实验 |
|---|---|
| 怎么证明方法比已有方法强？ | **comparison**：和相关的、**较新的** baseline 比。任务太新没有 baseline 时，构造自己方法的 variants |
| 怎么证明各 module 有效？ | **ablation**：①一个大表+可视化，列 core contributions 与重要 components 的影响；②若干小表，每个覆盖一个 module 的 design choices（对超参敏感性、对输入质量敏感性、去掉某 choice 的影响） |
| 怎么展示方法的上限？ | **在更有挑战性的数据上做 demo** |

第三项决定影响力，判据是：

> **面向下游研究群体做 demo——做给会引用这篇论文的人看，不是做给自己或大众看。**

算法在目标数据上 work 之后，**尽量在更新、更难的数据上跑，把算法推到极限**。
"大家都想看一个算法能做到什么程度"本身就是很大的贡献。
反事实：Neural Body 若没做街舞数据，拿不到 best paper candidate。

缺 ablation / 缺重要 baseline / 缺重要 metric / 数据太简单——这四条都是常见拒稿理由，
见 `paper-self-review`。

## 衔接

诊断结论与下一个实验回写 `experiments/LOG.md` 和 `PROJECT.md` §4（`research-project`）。
方案本身有问题（而非实现问题）时回到 `research-ideation`。