baseline-selection-audit

基线选择审计

将一项主张、方法、实验计划草案或文献脉络图，转化为经得起审稿人检验的基线集合和公平性台账。

在以下情况下使用此技能：

• 正在规划实验，但不清楚应该选择哪些基线
• 文献综述找到了竞争方法，但尚未将其转化为对比实验
• 论文可能缺少 SOTA、直接竞争方法、经典方法、消融基线或对照基线
• 审稿人可能会质疑调参、规模、数据、算力、协议或指标方面的不公平
• rebuttal 或修订需要确定值得补做哪项基线实验
• 用户需要说明为何某个基线因不可比而被排除

请勿将此技能用于检查引用元数据。检查 BibTeX 和 LaTeX 正确性请使用 citation-audit。主要问题是缺少参考文献而非缺少对比时，请使用 citation-coverage-audit。

将此技能与以下技能配合使用：

• 竞争论文脉络图不完整时，在使用此技能前先使用 literature-review-sprint
• 最接近的基线会改变方法设计时，使用 algorithm-design-planner
• 使用此技能后，使用 experiment-design-planner 将选定的基线转化为具体的实验矩阵
• 仅在基线范围、公平性规则和停止条件明确后，才使用 run-experiment
• 基线结果出人意料、不稳定或优于所提方法时，使用 result-diagnosis
• 基线风险需要关联到论文主张、图表和章节时，使用 paper-evidence-board
• 基线决策、风险和行动需要跨会话保留时，使用 research-project-memory

技能目录结构

<installed-skill-dir>/
├── SKILL.md
└── references/
    ├── baseline-taxonomy.md
    ├── fairness-ledger.md
    ├── memory-writeback.md
    ├── report-template.md
    └── reviewer-risk.md

渐进式加载

• 始终阅读 references/baseline-taxonomy.md、references/fairness-ledger.md 和 references/reviewer-risk.md。
• 撰写最终审计前，先阅读 references/report-template.md。
• 如果项目包含 memory/、组件级 .agent/ 文件夹，或用户要求持久化项目记忆，请阅读 references/memory-writeback.md。
• 如果基线集合取决于当前 SOTA、近期同期工作或会议预期，请通过网络搜索、OpenReview、proceedings、arXiv、PMLR、ACL Anthology、CVF、DBLP、Semantic Scholar 或用户提供的论文，使用当前来源进行核实。
• 如果无法进行当前核实，请将基线状态标记为暂定，并指出最终实验规划前还需进行哪些检索。

核心原则

• 基线的作用是支撑主张，而不是装饰表格。
• 区分概念上最接近的竞争方法、实证结果最强的基线、标准基准基线、消融基线和对照基线。
• 缺少某个基线，可能是为了补充引用、进行比较，或两者皆是。请明确指出是哪一种。
• 公平性必须涵盖数据、模型规模、算力、调参、指标、协议、代码可用性和结果报告。
• 不要要求用户运行所有可能的基线。应按审稿影响和决策价值排序。
• 排除某个基线需要有站得住脚的理由，且通常需要附上引用或局限性说明。
• 强基线胜过所提方法是项目信息，而不只是实验失败。
• 输出必须能够直接交接给 experiment-design-planner。

步骤 1 - 梳理主张与比较范围

收集：

• 论文主张或实验主张
• 所提方法和最接近的基线（如已知）
• 目标任务、数据集、基准、指标和协议
• 目标会议或学术社区的预期
• 现有结果、表格草案或计划中的实验
• 文献综述的输出（如有）
• 代码可用性和算力预算
• 项目记忆 ID，例如 CLM-###、EVD-###、RSK-### 或 ACT-###

将主张改写为：

We need to show that [method] improves [property] over [comparison set] under [task/protocol], without the result being explained by [confound].

如果无法写出，请转交给 research-idea-validator、algorithm-design-planner 或 paper-evidence-board。

步骤 2 - 构建候选基线池

使用：

• 文献综述的输出
• 引用的相关工作
• 基准测试排行榜或官方基线
• 目标会议近期接收的论文
• 代码仓库或模型发布
• 如果处于 rebuttal 模式，则查看审稿人意见

使用 references/baseline-taxonomy.md 对每个候选项进行分类。

基线池应包括：

• 直接竞争方法
• 当前最强方法
• 标准基准基线
• 经典基线
• 用户方法的上一版本或最接近的消融
• 无方法或简单对照基线
• 适用时的 oracle、上界或诊断基线
• 资源匹配的基线
• 目标会议预期的领域特定基线

步骤 3 - 指定基线要求级别

为每个候选项指定且仅指定一个级别：

• must-have：缺少该基线会让论文难以自圆其说
• should-have：显著提升审稿人信心，但省略仍有辩护空间
• optional：有助于提供背景，对录用影响较小
• not-comparable：虽有关联，但作为直接比较不公平或无效
• citation-only：应在讨论中提及或引用，但无需进行实验

每个 must-have 基线都需要明确负责人、实验形式、公平性约束，以及无法完成时的备选方案。

每个 not-comparable 基线都需要说明原因：

• 任务或数据不同
• 指标不兼容
• 代码不可用，复现成本过高
• 资源配置不同
• 使用了额外监督或数据
• 没有足够的公开细节来忠实复现
• 评估的是不同的主张

步骤 4 - 审核公平性

阅读 references/fairness-ledger.md。

针对每个 must-have 和 should-have 基线，检查：

• 数据划分和预处理是否相同
• 训练数据和额外数据策略是否相同
• 模型规模是否可比，或是否进行了明确的规模控制
• 计算量是否可比，或是否采用了明确的计算量归一化指标
• 调参预算是否可比
• 评估指标和解码／采样协议是否可比
• 是否使用了正确的官方代码或忠实的重新实现
• 是否使用了足够数量的随机种子、置信区间或方差报告
• 统计单位是否一致：token、样例、图像、FLOPs、运行时间、NFE、参数或内存

如果无法确保公平性，请决定是否：

• 调整主张
• 添加匹配子集比较
• 进行规模较小的诊断性比较
• 明确说明局限，并将该基线标记为仅引用
• 留待 rebuttal 阶段处理相关风险

步骤 5 - 预测审稿人可能提出的质疑

阅读 references/reviewer-risk.md。

针对每个缺失、薄弱或不公平的基线，写出审稿人可能提出的质疑：

Reviewer could say: [attack].
Severity: fatal / major / medium / minor
Mitigation: run / cite / justify / narrow claim / move to appendix / accept risk

按对录用的影响排序：

• 致命的新颖性或比较威胁
• 缺少必需的基准测试／SOTA 比较
• 调参或计算量不公平
• 消融基线薄弱
• 协议不明确
• 缺少对照

步骤 6 - 交接实验设计

向 experiment-design-planner 输出：

• 选定的基线及其要求级别
• 比较表的确切行
• 需要记录的公平性台账字段
• 指标和协议约束
• 消融／对照基线
• 停止条件
• 每个基线旨在回答的预期审稿人问题
• 基线无法完成时的备选方案

如果计算资源有限，请提出分阶段计划：

1. 满足审稿要求的最小集合
2. 影响较大的可选补充
3. 附录中呈现或延期处理的基线

步骤 7 - 编写基线审核报告

阅读 references/report-template.md。

如果要保存到项目中，且未指定路径，请使用：

docs/experiments/baseline_selection_audit_YYYY-MM-DD_<short-name>.md

如果在由 init-python-project / new-workspace 创建的代码仓库或代码工作区中操作，请优先使用：

docs/reports/baseline_selection_audit_YYYY-MM-DD_<short-name>.md

报告必须包括：

• 待审核的主张
• 候选基线池
• 要求级别表格
• 公平性台账
• 审稿人质疑预测
• 选定实验矩阵的交接内容
• 排除的基线及原因
• 记忆更新部分

步骤 8 - 写回项目记忆

如果存在记忆文件，请阅读 references/memory-writeback.md。

更新最小必要的一组条目：

• memory/risk-board.md：缺失、不公平、不可用或不可比较的基线风险
• memory/evidence-board.md：计划中的基线比较和消融实验
• memory/action-board.md：实现、运行、引用或论证相关操作
• memory/claim-board.md：因基线可行性而收窄的论断
• memory/decision-log.md：纳入、排除或分阶段引入基线的长期决策
• 工作树 .agent/worktree-status.md：基线实现的目的和退出条件
• paper/.agent/：对表格/章节的影响（如果已有草稿）

使用确定性标签：

• verified 表示已根据一手来源或官方代码核实的基线
• user-stated 表示用户提供的限制条件
• inferred 表示审稿人风险和公平性判断
• unverified 表示尚未核实的候选项

最终检查

定稿前：

• 每项论文论断都至少有一项直接比较或对照实验
• 不要混淆概念上最接近的竞争方法与实证效果最强的基线
• 明确列出 must-have 基线
• 为排除的基线提供站得住脚的理由
• 公平性约束具体到足以执行
• 使用审稿人的措辞写出审稿人可能提出的质疑
• 输出可直接提供给 experiment-design-planner 使用
• 如果存在项目记忆，请予以更新