06 - Pilot实验

用最小成本拿到 go / no-go 信号

目标

Pilot 实验不是为了直接产出论文主表，而是为了回答：

这个想法在当前问题边界内，是否已经出现足够可信的正面信号，值得继续投入？

本章的目标是：

根据 05-实验设计的 EXPERIMENT_PLAN.md 运行首轮最小实验
用统一标准把结果分成 POSITIVE、WEAK_POSITIVE、NEGATIVE、INVALID
把每次运行沉淀到 PILOT_LOG.csv，而不是只在终端里“看了一眼”
在继续、转诊断、降级为 backup、停止之间做明确决策
给 07-结果分析提供结构化输入，而不是零散截图和口头印象

本章回答的问题是：

我应该先跑什么、跑到什么程度、什么结果算有信号、什么结果意味着该停？

完成标准

完成本章，不等于“我随手跑了一个小实验”，而是至少做到：

你有一份经过人类复核的 PILOT_LOG.csv
每个 pilot run 都能回溯到 EXPERIMENT_PLAN.md 里的某个 Exp ID
你对每个 run 都给出了 signal 和 decision
你区分了研究性负结果和实现/流程错误导致的 INVALID
你知道下一步是 CONTINUE、REVISE、BACKUP 还是 STOP

输入与标准产物

输入

建议直接使用 01-05 章的标准产物：

输入	作用
`PROBLEM_NOTE.md`	防止 pilot 偏离原始问题边界
`IDEA_REPORT.md`	指定当前主线 idea 和优先级
`NOVELTY_REPORT.md`	指定最需要证明或证伪的 claim
`EXPERIMENT_PLAN.md`	给出 pilot 的目标、baseline、budget、stop rules
现有代码 / baseline repo	决定 pilot 能否快速复用
计算预算与排期	约束 pilot 规模和并行数

标准产物

产物	作用	后续会在哪用到
`PILOT_LOG.csv`	记录每次 pilot 的配置、结果、信号判断和决策	07, 08

这些 artifact 的统一命名、建议路径和状态定义见：附录 E

人类-智能体协作

阶段	智能体适合做什么	人必须负责什么	常见风险
执行清单展开	把 `EXPERIMENT_PLAN.md` 展开成 run checklist、命令模板、日志字段	决定首轮只跑哪几个最关键 run	一次展开太多 run，失去 pilot 意义
薄实现	搭建最小可运行脚本、复用 baseline、补 logging	判断哪些简化不会破坏结论	为了快而改动关键设定
运行监控	汇总 loss、主要指标、超时和报错	判断异常是研究信号还是工程事故	把 `INVALID` 误当成 `NEGATIVE`
信号归类	按预先写好的规则草拟 `signal` 和 `decision`	对 go / no-go 签字	看到一点提升就过度乐观

本章默认的工作方式是：

智能体负责把 pilot 跑得快、记得全；人类负责判断这个信号能不能支撑后续投入。

Pilot 不是什么

Pilot 的目的不是：

做完整 ablation
跑满所有 benchmark
一次性得到最终论文数字
在失败后无限追加预算“再试一次”

Pilot 的目的只有一个：

用最便宜的方式验证当前方向是否值得继续。

如果一轮 pilot 已经需要多天、多卡、多 seed，它通常已经不是 pilot，而是在偷偷做主实验。

工作流

Phase 0: 先排执行顺序，而不是同时开很多坑

从 EXPERIMENT_PLAN.md 里只选最关键的 1-3 个 run 进入首轮 pilot。优先级通常由三件事决定：

优先级维度	说明
Claim centrality	这个 run 是否直接决定主 claim 能否成立
Cost to falsify	它是否能低成本证伪错误方向
Reuse level	是否可直接复用现有 baseline 和代码

建议首轮只包含：

1 个 primary validation run
0-1 个 sanity check
0-1 个最便宜的 diagnostic run

不要一开始就把所有候选实验都铺开。

Phase 1: 冻结 Pilot Spec

真正开始跑之前，先把每个 run 写成最小执行单元：

markdown

## Pilot Run P1
- Linked experiment: E1
- Goal: validate primary claim on smallest in-scope setting
- Baseline: ...
- Dataset / split: ...
- Budget: <= 2h, 1 GPU, 1 seed
- Success: ...
- Failure: ...
- Invalid: ...
- Stop rule: ...

这一步的关键不是写得漂亮，而是防止你在结果出来后移动门槛。

Phase 2: 做薄实现，而不是做完整系统

Pilot 阶段优先：

复用已有 repo、checkpoint 和评估脚本
只保留当前判断所必需的模块
优先打通数据、训练、评估、日志四条链路
对将来可能扩展的地方先留接口，不先做完整工程

不优先：

大规模重构
完整配置系统
美化代码
为未来所有实验预先抽象

规则很简单：

只实现“让这个决策成立所必需的最小版本”。

一个推荐的 Pilot Python 项目基本模板

这个补充是合理的，而且非常适合放在 pilot 阶段：
你需要的不是“大而全实验框架”，而是一个可快速复用、能稳定留痕、后续可平滑扩展的最小 Python 项目骨架。

推荐默认组合：

环境管理：uv
配置管理：先用简单 YAML
实验入口：一个统一的 run_pilot.py
日志沉淀：结果同时进入 runs/ 和 PILOT_LOG.csv

建议目录：

text

pilot-project/
├── pyproject.toml
├── README.md
├── configs/
│   ├── base.yaml
│   └── pilot/
│       ├── p1.yaml
│       └── p2.yaml
├── src/
│   ├── data.py
│   ├── model.py
│   ├── train.py
│   ├── evaluate.py
│   └── utils.py
├── scripts/
│   └── run_pilot.py
├── runs/
│   └── pilot/
├── artifacts/
│   └── 06-pilot/
│       └── PILOT_LOG.csv
└── tests/
    └── test_config.py

一个足够轻的 pyproject.toml 例子：

toml

[project]
name = "pilot-template"
version = "0.1.0"
requires-python = ">=3.11"
dependencies = [
  "pyyaml>=6.0",
  "pandas>=2.0",
  "rich>=13.0"
]

[tool.uv]
package = false

一个足够用的配置文件例子：

yaml

exp_id: E1
claim_id: C1
seed: 7

dataset:
  name: toy-benchmark
  split: pilot

model:
  name: baseline-a

train:
  epochs: 3
  batch_size: 16

budget:
  max_hours: 2
  max_gpus: 1

logging:
  output_dir: runs/pilot/p1
  pilot_log: artifacts/06-pilot/PILOT_LOG.csv

推荐入口形式：

bash

uv run python scripts/run_pilot.py --config configs/pilot/p1.yaml

YAML 配置管理是否合理？

合理，但应控制复杂度。

对 pilot 阶段，建议规则是：

先上简单 YAML，而不是一开始就引入重量级实验框架
只把会反复改的内容放进配置：数据、预算、baseline、关键超参数、输出路径
不要把所有可能性都抽象成配置系统

什么时候 YAML 值得上：

你已经有 2 个以上 pilot 变体
你希望每个 run 都能稳定回填 PILOT_LOG.csv
你希望后续从 pilot 平滑升级到主实验

什么时候还不值得：

你只是在验证一条最小链路是否能跑通
当前只有一个一次性的 sanity check
你还没有固定好最小字段和输出路径

一句话建议：

Pilot 阶段用 “uv + 一个入口脚本 + 少量 YAML 配置” 最合适；等进入主实验，再考虑更重的配置框架。

Phase 3: 运行时先看链路，再看指标

Pilot 监控优先级通常是：

能不能稳定跑完
日志和评估是否可信
指标方向是否符合预期
提升幅度是否达到 success criteria

建议固定检查点：

检查点	你要看什么
启动后 5-10 分钟	数据、模型、日志链路是否正常
中途 30%-50%	loss / metric 是否有明显异常
结束时	是否命中 success / failure / invalid

如果连链路都不稳定，就不要急着解释研究意义。

Phase 4: 用统一标签归类信号

对每个 run，建议只给下面四类之一：

`signal`	含义	典型行动
`POSITIVE`	已出现明确正面信号，值得继续放大	`CONTINUE`
`WEAK_POSITIVE`	有趋势但证据还弱，需更聚焦验证	`REVISE` 或 `BACKUP`
`NEGATIVE`	在可信链路下未出现支持信号	`STOP` 或转入 backup
`INVALID`	结果不能解释为研究结论	修复实现或流程，再重跑同一 spec

一个实用判断：

POSITIVE：方向对，值得加预算
WEAK_POSITIVE：方向不确定，只值得小幅加码
NEGATIVE：方向大概率不对，除非有明确修复理由
INVALID：这次结果不算数，先修链路

Phase 5: 只在有明确理由时重跑

Pilot 最常见的浪费，是把“我不甘心”当成重跑理由。

允许重跑的典型理由：

修复了明确 bug
纠正了数据泄漏、评估错误或配置错位
补上了 EXPERIMENT_PLAN.md 里本来就要求的 logging / metric
把超时、崩溃、NaN 这类 INVALID 修正为可解释运行

不够充分的理由：

“这次 seed 不太好”
“感觉再训久一点会起来”
“也许再调两个超参数就好了”

如果要重跑，必须在 PILOT_LOG.csv 里写明 rerun_reason。

一个补充的 Pilot 调度图（LaTeX/TikZ）

如果你想在本章再补一张“多候选方案如何共享 pilot 预算”的调度图，可以直接使用下面的 LaTeX 代码：

Pilot scheduling emphasizes short cycles, small budgets, and parallel idea screening rather than full-scale experimentation.

使用时需要：

latex

\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}

一个可选的 Pilot 决策图（LaTeX/TikZ）

如果你想在本章放一张“pilot 执行与 go / no-go 判断图”，可以直接使用下面的 LaTeX 代码：

Pilot execution in this handbook is a decision-oriented loop: freeze a minimal spec, run the cheapest meaningful experiment, classify the signal, and write the decision into \textttPILOT_LOG.csv

使用时需要：

latex

\usepackage{tikz}
\usetikzlibrary{positioning,arrows.meta}

Phase 6: 写成 `PILOT_LOG.csv`

Pilot 不应只留下“印象”。至少要留下统一日志。

`PILOT_LOG.csv` 最低字段

字段	说明
`pilot_id`	当前 pilot run 的唯一标识
`exp_id`	对应 `EXPERIMENT_PLAN.md` 的实验编号
`claim_id`	对应哪条 claim
`baseline`	使用的 baseline
`setting`	数据、split、预算、seed 等最小设定
`runtime`	实际耗时
`primary_metric`	关键指标
`delta_vs_baseline`	相对 baseline 的变化
`signal`	`POSITIVE / WEAK_POSITIVE / NEGATIVE / INVALID`
`decision`	`CONTINUE / REVISE / BACKUP / STOP`

最低要求与附录 E 一致：idea_id, setup, runtime, metric, signal, decision

建议扩展字段

字段	说明
`status`	`completed / crashed / timeout / invalidated`
`rerun_reason`	若重跑，为什么重跑
`notes`	异常、观察和下一步动作
`artifact_path`	关键日志、曲线或 checkpoint 位置

示例：

markdown

| pilot_id | exp_id | claim_id | baseline | setting | runtime | primary_metric | delta_vs_baseline | signal | decision | status | rerun_reason | notes |
|----------|--------|----------|----------|---------|---------|----------------|-------------------|--------|----------|--------|--------------|-------|
| P1 | E1 | C1 | Base-A | 10% data, 1 seed | 48 min | 86.4 | +1.8 | POSITIVE | CONTINUE | completed |  | first clear gain |
| P2 | E2 | C1 | Base-A | 10% data, 1 seed | 35 min | 84.9 | +0.3 | WEAK_POSITIVE | REVISE | completed |  | trend exists but weak |
| P3 | E1 | C1 | Base-A | 10% data, 1 seed | 12 min | NaN | N/A | INVALID | REVISE | crashed | fix eval script | metric parser bug |

工具接入建议

这一章更适合吸收附录 D 里“并行探索、任务合约、最小实验执行”的经验：

工具 / 来源	更适合做什么	不要直接拿来做什么
ARIS `idea-creator` / `run-experiment`	强调尽早淘汰、阶段化推进、实验日志化	代替你做 go / no-go 判断
The AI Scientist	帮你组织并行候选 run、记录结果分支	自动把 weak signal 说成 strong result
AI-research-SKILLs	提供 run checklist、失败后处理和执行契约写法	代替领域判断和实验可信度判断

这部分强调的是从已有自动化科研系统里提炼出的可执行模式，而不是传统“先做小实验试试”的泛泛建议。

质量控制

1. Pilot 必须服务于某个明确决策

如果一个 run 跑完后，你仍然不知道自己该继续还是停，这个 pilot 大概率设计失败。

2. 先确认链路可信，再解释指标

指标再漂亮，如果评估脚本、数据切分或日志链路有问题，也不能拿来做研究判断。

3. `INVALID` 不能当成负结果

实现崩溃、超时、数据泄漏、评估错误都应先归到 INVALID，修链路后再判断方向对不对。

4. 弱信号不等于主线成立

WEAK_POSITIVE 最多说明“值得更聚焦地继续看”，不说明 claim 已经站住。

5. 负结果也要可复盘

真正有价值的 pilot，不仅能发现该继续的方向，也能明确记录为什么某条路不值得再走。

常见错误

错误 1：pilot 做成主实验

表现：第一轮就上全数据、多 seed、完整 ablation。

解决：回到 EXPERIMENT_PLAN.md，只保留当前最关键的判定实验。

错误 2：失败后无限重跑

表现：每次结果不理想就说“再试一个版本”。

解决：只有明确修复理由时才允许重跑，并写入 rerun_reason。

错误 3：不区分 `NEGATIVE` 和 `INVALID`

表现：代码报错、NaN、超时也被算成方法失败。

解决：先判断链路是否可信，再做研究结论。

错误 4：只记住好结果

表现：终端看过就算，没有留下统一日志。

解决：所有 pilot run 都进入 PILOT_LOG.csv，包括失败和无效运行。

错误 5：把微弱提升自动解释成突破

表现：+0.2 或 +0.3 的浮动也被直接当作主线证据。

解决：回到预先定义的 success criteria，弱信号只能算 WEAK_POSITIVE。

检查清单

完成本章后，你应至少能回答：

问题	状态
我是否只选了最关键的 1-3 个 pilot run？	`[]`
我是否在运行前写清了 success / failure / invalid？	`[]`
我是否把实现错误和研究负结果分开了？	`[]`
我是否记录了每个 run 的 `signal` 和 `decision`？	`[]`
我是否能明确说出下一步是 continue、revise、backup 还是 stop？	`[]`

小结

Pilot 实验的本质不是“先跑一点看看”，而是：

用 EXPERIMENT_PLAN.md 冻结最小可执行规格
以最便宜的实现和预算跑出首轮信号
用统一标准把结果分成 POSITIVE / WEAK_POSITIVE / NEGATIVE / INVALID
把结果和决策写进 PILOT_LOG.csv
为 07-结果分析提供可复盘输入

下一步：07-结果分析 - 把 pilot 和主实验结果转成可辩护发现

引用 ARIS：本章的阶段化 pilot 执行、尽早淘汰和日志化思路，主要来自 ARIS 的 idea-creator 与 run-experiment 技能。
扩展来源：这一版还吸收了 The AI Scientist 和 AI-research-SKILLs 中关于并行探索、实验状态记录和失败处理的可执行经验。完整来源见：附录 D

06 - Pilot实验 ​

目标 ​

完成标准 ​

输入与标准产物 ​

输入 ​

标准产物 ​

人类-智能体协作 ​

Pilot 不是什么 ​

工作流 ​

Phase 0: 先排执行顺序，而不是同时开很多坑 ​

Phase 1: 冻结 Pilot Spec ​

Phase 2: 做薄实现，而不是做完整系统 ​

一个推荐的 Pilot Python 项目基本模板 ​

YAML 配置管理是否合理？ ​

Phase 3: 运行时先看链路，再看指标 ​

Phase 4: 用统一标签归类信号 ​

Phase 5: 只在有明确理由时重跑 ​

一个补充的 Pilot 调度图（LaTeX/TikZ） ​

一个可选的 Pilot 决策图（LaTeX/TikZ） ​

Phase 6: 写成 PILOT_LOG.csv ​

PILOT_LOG.csv 最低字段 ​

建议扩展字段 ​

工具接入建议 ​

质量控制 ​

1. Pilot 必须服务于某个明确决策 ​

2. 先确认链路可信，再解释指标 ​

3. INVALID 不能当成负结果 ​

4. 弱信号不等于主线成立 ​

5. 负结果也要可复盘 ​

常见错误 ​

错误 1：pilot 做成主实验 ​

错误 2：失败后无限重跑 ​

错误 3：不区分 NEGATIVE 和 INVALID ​

错误 4：只记住好结果 ​

错误 5：把微弱提升自动解释成突破 ​

检查清单 ​

小结 ​