exp-campaign

实验活动：观察 → 盘问 → 列举 → 剪枝 → 分阶段安排 → 交接 → 复核

实验活动原则：在证据允许的范围内尽可能精简，在论点要求的范围内尽可能完整。 切勿一开始就列出完整的全因子矩阵；也切勿悄悄删去某个维度。先列出所有内容，再用结果足以支持判断的低成本探测，为每一项删减提供依据。

适用场景

• 需要探索多个分支、消融实验或条件式分阶段安排的研究方向。一个配置已知、范围明确的分支属于 exp-batch；缺少一个数据点属于 exp-probe；仍然模糊的想法属于 exp-discuss。
• 以研究者的明确选择为准；切勿悄悄切换。根据决策树深度和因素数量判断，而不是看实验运行时长（如果不确定该用 probe 还是 batch，就用 batch）。技能说明使用英文；交付内容遵循用户的语言（默认是中文）。

1. 先观察，再提问

• 阅读项目记忆、仪表板、以往运行记录、日志和既往结论。确定已知内容、已有的基线、规范指标，以及当前证据尚未覆盖的内容。
• 用 2-3 句话重述研究者的想法：要检验的论点、令人信服的最终图表应呈现什么，以及哪些内容不在范围内。区分明确要求和待解问题。

2. 盘问研究者

分轮提出范围明确的前沿问题——仅询问已确定的决策所解锁的问题——每个问题都给出建议答案；能够自行查证的事实由你查找，不能让研究者代劳。每轮回答后重新计算问题前沿，再提出下一轮问题：轮数不限；是否停止取决于继续提问能否改变范围、论点或验收标准。

按前沿顺序询问并明确以下事项：

• 论点： 最终图表/表格具体应展示什么？哪项比较会改变研究者的看法？
• 维度： 哪些因素重要（方法、模型、数据集、精度、种子、lr，……），每个因素有哪些水平？
• 研究者可能忽略的细节： 评估划分、校准数据与评估数据之间的数据泄漏、回调指标与重新加载后的指标是否一致、种子方差、退化基线（例如所有输入都得到相同答案）、检查点的早期/晚期选择，以及平台/数值等价性。请明确提出这些问题；研究者往往会对它们说明不足。
• 预算： 设备运行小时数、墙钟时间截止期限、存储空间；哪些运行属于正式实验，哪些属于探索性实验。
• 验收： 什么情况算成功、平局，以及值得保留的负面结果。

执行关键决策和验收关键决策均已确定后即可停止。不要凭空设定提问轮数上限。

3. 列出最大实验空间

将完整的因素 × 水平矩阵写成表格。每个单元格都必须标记为以下之一：

• 必须运行——论点直接取决于该项；
• 探测后决定——低成本实验可以判断是否需要整个行/列/分支；
• 可剪枝——已有证据已回答该问题，或已证明其冗余（说明证据）。

故意从最大列表开始：剪枝过程必须清晰可见且理由充分，让评审者知道我们考虑过哪些内容。

4. 设计剪枝探测

对于每组探测后决定的项目，设计以最小实验移除最多单元格的方案：

• 示例模式：两种配置显示指标 A ≈ 指标 B（回调与重新加载、dtype 变体、缓存模式）→ 在剩余整个矩阵中采用成本较低的方案；记录等价性论点、其证据及置信度。
• 每项探测都要说明：配置、预期成本、观察结果，以及以决策形式写出的剪枝规则：if <observed condition> then skip <cells>, else run <cells>。
• 探测本身必须遵循项目的实验规范（预检、运行 ID、输出布局）。违反规范的探测无法安全地得出结论。

5. 编写分阶段计划

一份 Markdown 文档，优先使用表格而非散文：

1. 主张与范围——包括最终交付物：指标表格的架构（行 = 运行，列 = 指标 × 界面 × 划分）和图表清单（每张图：坐标轴、曲线族、参考线、每个数据集的布局）。每次计划中的运行都必须填充至少一个单元格或曲线；不会影响任何图表的运行必须说明理由。
2. 当前证据——已测量的内容及其指向。
3. 最大矩阵，每个单元格都带有 §3 中的标签。
4. **带有观察关卡的阶段：**第 0 阶段探测 → 决策点（哪些分支继续保留）→ 第 1 阶段核心运行 → 第 2 阶段确认性运行（完整轮次、独立重新加载、正式协议）。对于每个关卡：精确的命令列表、成本估算、预期观察结果、运行所采用的资源/设备约定（根据实时读取结果选择、显式传入，绝不使用默认设备），以及每种结果对应的分支表。计划中的每次运行开始前，都必须通过 exp-batch 的预检。
5. 剪枝记录——作出的假设、作为依据的探测、置信度。
6. 故障处理——对于 OOM/NaN/无法得出结论/被驱逐（其他人的任务或机器占用了显卡）的情况该如何处理：收集证据、尽可能缩小隔离范围、不得悄悄跳过。将这些情况列为预期的故障类型，而非覆盖所有可能性：突发故障应当场决定处理方式并记录为偏差，不要将其升级为新的流程。
7. **交付物：**计划文件（项目工作文档目录；默认路径为 docs/experiments/YYYY-MM-DD-<slug>.md）、每个阶段一个独立完整的启动器提示词（既要用代码围栏写入计划，也要在聊天中打印）、记录在剪枝记录中的关卡决策、必须提交的每阶段执行器报告（<slug>.stage<N>.report.md，由 exp-batch 写入），以及将结果合并到共享仪表板/表格的步骤。

6. 移交与审查

• 执行在独立的 Agent 会话中进行，每个阶段或分支各一个会话。 与 plan-brief 类似，campaign 会为每个阶段提供独立完整的启动提示词；新的会话读取计划，采用 exp-batch，并实现和运行该阶段。切勿在规划会话中执行 campaign。
• 每条启动提示词都包含：此阶段必须填写的单元格、确切的配置/命令、指标约定、停止条件，以及需要报告的关卡观察结果。执行者遵循计划，而不是重新审议已敲定的决策；如果证据推翻计划，则停止并询问。
• 在每条启动提示词中说明等待安排。 要么研究人员已委派执行——明确说明（“你可以启动运行，并使用 later 工具在无人值守时等待”）；要么执行 Agent 必须在阶段开始时请求授权。获得授权且宿主提供 later 工具时，执行者会在后台运行长任务，按约多留约 10% 的缓冲时间安排自行唤醒（提示词须写成完整的下一步指令），然后结束当前轮次；持续唤醒，直到收集到该阶段的关卡观察结果。如果运行超时，则根据观察到的进度重新估算，而不是依赖原计划。这样，多小时的阶段可以无人值守地进行；否则，执行者会在每次长时间运行时停止并等待人工处理。
• 由谁启动正式运行，由研究人员决定，而不是计划决定：执行 Agent 负责实现代码并进行预检；研究人员可以自行运行正式命令，也可以明确授予执行权限。计划必须说明哪些命令属于正式命令。
• 阶段报告返回后，由本会话负责下一步——研究人员是传递报告的人，因此不要等待自动通知。读取 <slug>.stage<N>.report.md（而不是聊天记忆），逐一比较每个关卡的预测结果与观察结果，在剪枝记录中写下决策（gate N: observed X → keep / skip cells …），重新开放失败探测所依据假设涉及的单元格，并明确说明原因；然后发出第 N+1 阶段的启动提示词，替换其所取代的预先编写的分支变体。
• 结束条件： 共享表中每个仍保留的单元格都有一行，且图表列表中的每幅图都能据此绘制时，campaign 即告结束。随后在计划顶部记录 Status: done (stages: N)，说明剪除了哪些内容以及所依据的证据，将负面结果交给研究人员，并停止开启分支。如果某个关卡在确认阶段结束后仍无法解决主张是否成立的问题，就将未决问题交还，而不是增加阶段。
• 最终审查：指标表/图表集是否回答了原始主张？负面结果和配置偏差是否清晰可见？在共享仪表板上发布，并涵盖现有的回调和重新加载界面。

7. 代码组织（在此规划，由 exp-batch 实现）

计划决定代码放在哪里，以便后续每个分支都能保持一致：

• **模块放置是一项决策，要明确说明：**每个部分属于哪个现有模块，哪些内容留在实验自己的目录中。单一使用方不需要新的共享抽象；但如果两个分支原本会以不同方式编辑同一个文件，就要将各项职责拆分到不同模块中。
• **隔离实验目录：**每个实验都有自己的目录，且布局可预测，这样仅凭名称就能找到一次运行（脚本、配置和输出相互对应）。实验不得访问其他实验的目录。
• **优先松耦合，而非图方便：**实验通过现有接口使用稳定的共享库；实验不得为了满足自身需求而修改共享库的内部实现，共享库也不得增加实验专属分支。如果共享接口确实缺少某项功能，这应作为计划层面的决策，而不是顺手改动。
• **精简的研究代码：**只保留能正确运行实验所需的最少代码。不要进行防御式编程——不做猜测性的输入验证，不添加“以防万一”的分支，也不吞掉错误。出错时，带着真实错误退出。事后分析时再决定应修复代码还是环境（设备争用、磁盘已满、缓存过期）；很多时候代码本来就是正确的。

严格边界

• 绝不要把被裁剪掉的空间说成“已运行但失败”；被裁剪意味着“未运行，因为探测 P 显示了 X”。
• 绝不要在没有实测对比的情况下，声称不同配置等效。
• 活动计划并不代表可以启动正式运行；请遵守项目关于由谁运行哪些内容的规定。