主题
05 - 实验设计
把新颖性判断变成可执行证据计划
目标
实验设计不是“先把论文里可能出现的所有表格都列出来”，而是把 04-新颖性验证 中的 claim、closest work 和 reviewer 风险，压缩成一份最小但足够有判断力的验证计划。
本章的目标是：
- 从
NOVELTY_REPORT.md中选出本轮最关键的 1-2 个 target claims - 明确这些 claim 需要什么证据、该与谁比较、该在哪个 setting 下验证
- 在运行前写清 success criteria、failure interpretation、invalid 条件和预算
- 输出一份可直接交给 06-Pilot实验 的
EXPERIMENT_PLAN.md
本章回答的问题是：
我要先跑什么、和谁比、在什么条件下比，以及什么结果足以让我继续或停止？
完成标准
完成这一章，不等于“我想好了几个实验”，而是至少要做到：
- 你有一份经人类复核的
EXPERIMENT_PLAN.md - 每个首轮实验都对应一个明确的 claim 或 strongest objection
- 你知道哪些 baseline 是必须比较的，不能只挑弱 baseline
- 你在运行前就写清了 success criteria、budget 和 stop rules
- 你能把本章的产物平稳交给 06-Pilot实验 和 07-结果分析
输入与标准产物
输入
建议直接使用 01-04 章产物：
| 输入 | 作用 |
|---|---|
PROBLEM_NOTE.md | 约束问题边界、non-goals 和 kill condition |
IDEA_REPORT.md | 指定 top idea、执行顺序和 strongest objection |
NOVELTY_REPORT.md | 明确 target claims、风险点和 must-cite work |
CLOSEST_WORK_TABLE.csv | 指定必须正面比较的最近工作 |
PAPER_TABLE.csv | 回查近邻工作使用的设置、指标和证据 |
| 资源预算与已有代码 | 决定实验设计是否现实可做 |
标准产物
为了避免 contract 被切得过碎，本章建议只产出 1 份标准材料：
| 产物 | 作用 | 后续会在哪用到 |
|---|---|---|
EXPERIMENT_PLAN.md | 统一记录 hypotheses、baselines、datasets、metrics、success criteria、budget、stop rules | 06, 07, 08 |
这些 artifact 的统一命名、建议路径和生命周期状态见：附录 E
人类-智能体协作
| 阶段 | 智能体适合做什么 | 人必须负责什么 | 常见风险 |
|---|---|---|---|
| 证据规划 | 把 claim 改写成实验问题、列出可能的证据路径 | 决定哪些证据真的足以支撑 claim | 把“可跑”误当成“有说服力” |
| baseline 整理 | 从 CLOSEST_WORK_TABLE 和论文表中整理比较对象 | 决定哪些 baseline 必须正面应对 | 故意避开最危险的最近工作 |
| 配置草拟 | 草拟 experiment matrix、预算和配置组合 | 决定首轮实验规模和 stop rule | 把实验矩阵扩得过大 |
| 风险预审 | 扮演审稿人问“为什么这个证据足够” | 判断 strongest objection 是否被真正覆盖 | 用复杂设计掩盖核心问题没被回答 |
本章默认的工作方式是：
可以让智能体帮你展开实验矩阵，但“什么证据足以支持主张”必须由人来定。
实验设计真正回答什么
一个好的实验设计，不是在问“还可以再跑什么”，而是在问下面 5 个问题：
- 这轮最关键的决策是什么？
- 哪条 claim 最值得先验证或先证伪？
- 必须正面比较的 baseline 是谁？
- 什么证据才算支持，什么结果又意味着该停？
- 我能否用最小成本拿到足够有判断力的第一轮信号？
如果这些问题还答不出来，不应该进入 pilot。
工作流
Phase 0: 先选本轮的决策目标
不要一上来设计“整篇论文的所有实验”。先选出本轮最关键的决策点。
通常优先级来自 3 个维度：
| 维度 | 说明 |
|---|---|
| Paper centrality | 这条 claim 是否是整篇工作的核心 |
| Novelty risk | 这条 claim 是否最容易被最近工作压掉 |
| Cost to falsify | 它是否能被低成本快速验证或证伪 |
经验上，首轮实验通常只需要：
- 1 个 primary claim
- 0-1 个 supporting claim
如果你一开始就设计 8 组实验，通常说明范围还没收敛。
Phase 1: 把 claim 变成 evidence map
对每条 target claim，至少写清 4 件事：
| 字段 | 说明 |
|---|---|
claim | 你到底想证明什么 |
objection | 审稿人最强的反驳是什么 |
needed_evidence | 什么实验结果才能真正回应这个反驳 |
experiment_type | 这更像验证、诊断、消融还是边界测试 |
常见实验类型
| 类型 | 适合回答什么 |
|---|---|
| 验证性实验 | 方法是否比 baseline 更好 |
| 诊断性实验 | 为什么有效、为什么失败、在哪失效 |
| 消融实验 | 哪个组件真的有贡献 |
| 边界/鲁棒性实验 | 结论在哪些 setting 下成立或失效 |
| scaling / 效率实验 | 收益与成本是否匹配 |
不要把所有类型都堆进首轮实验。先回答最关键的不确定性。
Phase 2: 选 baseline，不要挑软柿子
实验设计里最容易自欺的一步，就是故意不和最危险的工作比。
至少要区分 3 类 baseline：
| baseline 类型 | 为什么需要 |
|---|---|
| 社区标准 baseline | 防止结果无法被领域读者理解 |
| closest work baseline | 直接回应新颖性验证中的最近工作 |
| 便宜的 sanity baseline | 快速排除“只是实现或数据处理问题” |
规则：
CLOSEST_WORK_TABLE.csv中最危险的近邻工作，优先进入比较集合- 如果无法复现 closest work，必须在计划里写清替代方案和风险
- 不要只和明显弱于你的 baseline 比较
Phase 3: 定义数据、setting 和指标
先问：
这个 claim 最小需要在哪个数据、哪个 setting、哪个指标上被观察到？
建议至少明确：
- 一个
primary metric - 一个
secondary metric或效率指标 - 一个与 closest work 可比较的 setting
如果你引入自定义 benchmark 或新指标，也最好保留一个社区标准 setting，否则结果难以定位。
Phase 4: 压缩成最小可决策版本
实验设计的目标不是立即跑满规模，而是先设计出一个最小可决策版本。
常见压缩方式：
- 先用 1%-10% 数据或更小 setting 看趋势
- 先跑 1 个 seed，后续再补多 seed
- 先验证最核心组件，不先做全套 ablation
- 先看能否复制与 baseline 的方向性差异，再决定是否放大
这一步的关键不是“越小越好”，而是：
小到便宜，但仍然能回答问题。
Phase 5: 运行前写清 success / failure / invalid
不要等结果出来后再决定什么算成功。
对每个首轮实验，至少写清：
| 项目 | 你需要提前定义什么 |
|---|---|
success | 什么结果足以继续放大 |
failure | 什么结果说明当前方向不值得继续 |
invalid | 什么情况说明这是实现或流程错误，而不是研究结论 |
budget | 时间、GPU、数据规模和 seed 限制 |
stop_rule | 什么时候必须停，不继续加码 |
示例：
text
Success: 在相同训练预算下，primary metric 相对 strongest baseline 提升 >= 1.5%
Failure: 无明显提升，且实现与评估链路确认无误
Invalid: NaN、数据泄漏、评估脚本错误、checkpoint 损坏
Budget: <= 2h, 1 GPU, 1 seed
Stop rule: 超时或连续 2 次 pilot 无有效正信号则停止主线推进一个可选的实验设计图（LaTeX/TikZ）
如果你想在本章加入一张“从新颖性到实验计划”的图，可以直接使用下面的 LaTeX 代码：
使用时需要：
latex
\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}Phase 6: 写成 EXPERIMENT_PLAN.md
这份计划不是给自己看的散笔记，而是下一章的执行契约。
它至少要告诉你：
- 先跑哪一项
- 要和谁比
- 在哪个 setting 下比
- 什么结果算值得继续
- 什么结果意味着应该转向、诊断或停止
EXPERIMENT_PLAN.md 模板
markdown
# Experiment Plan
## Idea
- Idea title:
- Linked problem note:
- Linked novelty report:
## Decision Target
- Primary claim:
- Supporting claim(s):
- Strongest reviewer objection:
## Claim-Evidence Map
| Claim | Needed Evidence | Experiment Type | Why this is enough |
|-------|-----------------|-----------------|--------------------|
| ... | ... | ... | ... |
## Must-Run Baselines
- Closest work baseline:
- Community standard baseline:
- Sanity baseline:
## Datasets and Settings
- Primary dataset / benchmark:
- Secondary setting:
- In-scope setting:
- Out-of-scope setting:
## Metrics
- Primary metric:
- Secondary metric:
- Efficiency / cost metric:
## Experiment Matrix
| Exp ID | Claim | Type | Baseline | Dataset / Setting | Metric | Budget | Success | If Fail |
|--------|-------|------|----------|-------------------|--------|--------|---------|---------|
| E1 | ... | validation | ... | ... | ... | ... | ... | ... |
| E2 | ... | diagnostic | ... | ... | ... | ... | ... | ... |
## Stop Rules
1. ...
2. ...
## Handoff to Pilot
- First experiment to run:
- Required code / assets:
- Logging requirements:工具接入建议
这一章更适合吸收 附录 D 中的“计划与任务契约”经验：
| 工具 / 来源 | 更适合做什么 | 不要直接拿来做什么 |
|---|---|---|
| The AI Scientist | 草拟 experiment matrix、列变体、并行探索候选路线 | 替你决定什么证据足以支持 claim |
| AI-research-SKILLs | 提供任务拆分和执行清单的写法 | 直接替代具体领域判断 |
ARIS run-experiment | 强调最小验证路径、预算意识和阶段化推进 | 代替你选择最近工作和 baseline |
质量控制
1. 每个实验先回答一个问题
一个实验同时想证明“方法更好、组件有用、为什么有效、边界在哪里”，通常会失控。
2. baseline 必须回到新颖性判断
如果 baseline 的选择和 CLOSEST_WORK_TABLE.csv 对不上，这个计划大概率有问题。
3. 成功标准必须写在运行前
否则你很容易在结果出来后移动门槛。
4. 首轮实验优先追求判断力，不优先追求完整性
先拿到 go / no-go signal，再决定是否扩展。
5. 负结果也要能解释
如果实验失败后你完全不知道意味着什么，设计阶段就没做好。
常见错误
错误 1：一开始就设计整篇论文的全部实验
表现： 先列 10 个表、5 个图，再想核心问题。
解决： 先选 primary claim 和 strongest objection，只设计最关键的第一轮。
错误 2：故意避开最危险 baseline
表现： 只选容易赢的 baseline，不和 closest work 正面比。
解决： 从 CLOSEST_WORK_TABLE.csv 回填必须比较对象。
错误 3：success criteria 写得很空
表现： “如果结果看起来不错就继续。”
解决： 把 success / failure / invalid 写成具体条件。
错误 4：一个实验同时改太多变量
表现： 方法、数据、训练预算、评估脚本一起变。
解决： 首轮实验优先控制变量，一次只回答一个主要问题。
错误 5：实验规模大到无法快速止损
表现： 第一轮就上满数据、满训练、多个 seeds。
解决： 先设计最小可决策版本，再决定是否放大。
错误 6：只有正向路径，没有失败路径
表现： 计划里只写“如果成功怎么扩展”，没写失败后怎么办。
解决： 在 If Fail 和 Stop Rules 里明确下一步。
检查清单
完成本章后，你应该至少拥有：
| 问题 | 状态 |
|---|---|
| 我知道首轮要验证哪条 primary claim 吗？ | ✅ |
| 我知道必须正面比较的 baseline 是谁吗？ | ✅ |
| 我写清了 metric、budget 和 success criteria 吗？ | ✅ |
| 我区分了 success、failure 和 invalid 吗？ | ✅ |
我把 stop rule 写进 EXPERIMENT_PLAN.md 了吗？ | ✅ |
| 我准备好把计划交给 pilot 执行了吗？ | ✅ |
如果有 ❌，不要急着开跑。
小结
AI/ML 研究里的实验设计，本质上是把新颖性风险转换成证据计划：
- 从
NOVELTY_REPORT.md选出 target claims - 明确最近工作和必须比较的 baseline
- 选数据、setting 和指标
- 压缩成最小可决策版本
- 把 success / failure / invalid / stop rules 写进
EXPERIMENT_PLAN.md
下一步：06-Pilot实验 — 执行最小实验，拿第一轮信号
引用 ARIS：本章的阶段化实验推进和最小验证路径，主要来自 ARIS 的
run-experiment与idea-creator技能。扩展来源：这一版还吸收了 The AI Scientist 和 AI-research-SKILLs 中关于 experiment planning、并行探索和任务契约的可执行经验。完整来源见：附录 D