| name | research-experiment |
| description | 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。 |
实验设计与诊断
改进方法 = 对 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 步 · 本质原因：对表面原因问"为什么"，列出尽量多的候选。两类：
- 代码有 bug
- "xx 算法"在"xx 数据"上确实有问题：超参没设对 / 缺了几个 tricks / 算法本身不行
区分第 2 类的手段：看相关论文为什么能 work、用了什么 tricks
（literature-review 检索 → pdf-explore 读实现细节），
给相关论文的算法做 ablation 看哪部分是关键。
有些 idea 单独拿出来不 work，加上 tricks 才 work（NeRF + positional encoding）。
第 3 步 · 验证：设计实验逐个证伪。跳过验证直接改算法 = 猜的梯度。
输出模板
用户说"实验不 work"时，不要直接给改进建议。先产出这张表；
缺哪一格就去补，补不出来就明说"这一格需要你提供 X"。
## 诊断：<一句话现象>
**表面原因**：<哪个变量一改就变差>
**对照**：work = <配置> 不 work = <配置> **差异**：<具体列出，不写"设置不同">
| # | 候选本质原因 | 支持证据 | 反对证据 | 怎么用一个实验证伪 |
|---|---|---|---|---|
| 1 | 代码 bug：<具体哪里> | | | |
| 2 | 超参：<哪个> | | | |
| 3 | 缺 tricks：<论文 X 用了 Y> | | | |
| 4 | 算法本身不行：<为什么> | | | |
**下一个实验**（只验证一条，exploration points = 1）
- 验证第 <N> 条 - 二元标准：<若…则该原因成立> - 最小设计：<一天能做完的版本>
**还需要你提供**：<看不到的信息，如训练日志、baseline 配置>
自检："下一个实验"是从表里推出来的，还是先想好再倒填的？
后者说明在合理化直觉，不是在求梯度。
填满的实例：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。
