从Baseline到消融实验：深度学习论文复现与投稿工程化指南

很多人对研究生阶段发论文的想象是这样的：想出一个绝妙 idea，写几百行代码，跑出漂亮结果，投出去就中。真正进组之后才发现，卡住自己的从来不是“没想法”，而是更具体、更琐碎的东西——导师给的 baseline 代码跑不起来，公开仓库的精度复现不出来，好不容易训出一个能看的模型，却不知道该拿它证明什么，最后写出来的稿子被审稿人一句 “incremental and lacks thorough ablation study” 打回。

这篇内容想讨论的就是这条链路：深度学习方向从跑通 Baseline 到产出创新点、再到写成一篇能投出去的文章，中间到底有哪些环节是可以被工程化的。先给一个判断：对研一研二的同学来说，发一篇中等水平的 SCI 或会议论文，真正的门槛通常不在“创新有多惊艳”，而在于你能不能把实验做得可复现、有对照、结论站得住。审稿人大多数时候不是在找“颠覆性工作”，而是在判断你有没有认真做完一件小事。

需要先把话说在前面。“水论文”这个词在组里流传很广，但它有两条完全不同的含义。一条是用工程化手段高效完成一项扎实的增量研究，另一条是数据造假、抄袭拼凑、买卖稿件——后者是学术不端，一旦被查出，代价远大于任何一篇论文带来的收益。本文讨论的只有前者，并且会反复强调证据链、消融实验和可复现性这三件事，因为这三件事恰恰是区分“高效的增量研究”和“注水”的分界线。

接下来的内容会按实际做研究的顺序展开：先讲 CNN、Transformer、Diffusion 这三类骨干网络该怎么根据任务和算力去选，再讲环境怎么搭、Baseline 怎么才算真正跑通，然后是创新点的四条可行路径和配套代码，接着是消融实验怎么设计才经得起审稿人追问，最后落到写作、选刊和投稿前的自查。如果你正卡在其中某一步，可以直接跳到对应章节。

1. 先把“发论文”这件事拆成可执行的阶段

1.1 三个阶段与各自的真实难点

把整个流程粗略切成三段，你会发现难点分布非常不均匀。

第一阶段是复现。看起来最没技术含量，实际最容易劝退人。公开仓库的 README 写着“run this script”，但你 clone 下来之后会遇到 CUDA 版本不匹配、依赖包版本漂移、数据预处理顺序和论文描述不一致、多卡训练脚本在你单卡机器上直接报错。很多人在这里耗掉一两个月，最后连一个可信的 baseline 数字都没拿到，后面的所有工作都无从谈起。

第二阶段是改进与验证。你需要在 baseline 之上做一点改动，然后证明这个改动确实有效，而不是随机种子波动带来的幻觉。这一步的难点不是写代码，而是控制变量：改了什么、只改了什么、其他条件是否完全一致、提升幅度是否超过了多次运行的方差。

第三阶段是表达。把实验记录整理成方法描述、把数字整理成表格、把动机整理成引言。这一阶段最考验的是“证据组织能力”，而不是英语水平。

真正高效的路径，是把这三段串成一条流水线：复现阶段就把配置文件、随机种子、日志格式固定下来，后面两段直接复用；改进阶段每做一个变体就产出一行消融结果，写作时表格几乎是自动生成的。

1.2 三类读者对应三种切入方式

如果你刚进组、连方向都没定，建议先花两周时间把组里已有的代码跑通，哪怕它和你的兴趣方向不完全一致。跑通过一次完整流程，你对“一篇论文需要哪些实验”的直觉会建立得非常快。

如果你已经有 baseline 但跑不出论文里的数字，优先怀疑三件事：数据增强的具体参数、学习率调度曲线、以及评测时用的是 last epoch 还是 best epoch。这三个地方是复现失败的高发区。

如果你实验做完了但不会写，那就从图表倒推：先把主结果表、消融表、可视化图排出来，看看缺哪块证据，再回头补实验。写作不是创作的终点，而是实验设计的验收环节。

1.3 一个必须先建立的认知

论文里的“创新点”在审稿人眼里通常不是“前所未有的想法”，而是“一个被清晰定义、被严格验证的改动”。你加了一个注意力模块，审稿人不会问你为什么这么聪明，而会问：参数量涨了多少？FLOPs 涨了多少？在同等参数预算下对比过吗？提升在不同数据集上都成立吗？在低数据量设置下还成立吗？

也就是说，创新点的说服力来自对照实验的完备程度，而不是想法本身的新奇度。理解这一点之后，你的实验设计会有明显变化：从“我要证明我的方法好”变成“我要排除所有其他解释”。

2. CNN、Transformer、Diffusion 怎么选

2.1 三者的核心差异在归纳偏置

选骨干网络，本质上是在选归纳偏置（inductive bias），也就是模型在没见过数据之前就“预设”了什么样的规律。

CNN 预设的是局部性和平移等变性：相邻像素相关，同一个卷积核在图像不同位置都能用。这个预设非常贴合自然图像的统计特性，带来两个直接后果——参数效率高，以及在小数据集上不容易过拟合。一个小型 ResNet 在几万张图上就能训出可用结果，这是 CNN 至今仍然是很多视觉任务的默认选择的原因。

Transformer 预设的是全局关系：任意两个位置之间都可以直接建立依赖，权重由注意力动态计算。它的表达能力强，但代价是它没有把“局部性”写进结构里，需要从数据中学出来。所以 ViT 系列在 ImageNet-1K 这种规模上从头训练往往不如同量级 CNN，必须依赖大规模预训练或者强数据增强（如 DeiT 的蒸馏策略）才能追上。注意力的计算复杂度随 token 数呈平方增长，这也是高分辨率任务里必须先切 patch 或者用窗口注意力的原因。

Diffusion 则是完全不同的范式：它不是判别模型，而是生成模型。训练目标是学会从加噪图像中预测噪声，推理时从一个纯高斯噪声出发，迭代去噪生成样本。它的优势是生成质量高、训练稳定（相比 GAN 不容易模式崩塌），代价是采样慢——需要几十到上千步迭代。如果你做的是分类、检测、分割这类判别任务，用 Diffusion 做骨干通常是不划算的；但如果你做的是图像生成、超分、图像修复、医学影像合成、数据增强，那它就是当前的主流选择。

2.2 一张对照表看清选择边界

这张表不是让你死记，而是提醒：选型要同时考虑“任务匹配度”和“你手上的算力”。一个常见的误区是，看到某篇顶会论文用 Transformer 拿到了 SOTA，就照搬到自己只有一张 12G 显卡的课题上，最后卡在显存和训练时间上，连 baseline 都没跑完。

2.3 实际选题的决策顺序

建议按这个顺序问自己四个问题。

第一，我的任务是判别还是生成？判别优先 CNN 或 Transformer，生成优先 Diffusion 或 GAN。

第二，我的数据规模有多大？万级以下优先 CNN；十万级以上可以考虑 Transformer；百万级以上 Transformer 的优势才会明显体现。

第三，我的算力预算是什么？如果只有单卡且时间有限，把精力放在结构轻量化、数据增强策略、损失函数设计这类“低算力高性价比”的方向，比硬上大模型更容易出成果。

第四，我要投的期刊或会议，近期收录的文章以哪类方法为主？这不是让你跟风，而是让你判断审稿人的预期。如果一本期刊近两年几乎全是 CNN 改进类工作，你投一篇纯 Transformer 的稿子，需要额外花笔墨解释为什么必须用 Transformer。

2.4 混合架构是更稳妥的中间路线

如果觉得纯 Transformer 太吃数据、纯 CNN 又太“卷”，混合架构是一个务实的选择。ConvNeXt 的思路是把 CNN 现代化，借鉴 Transformer 的训练技巧（LayerNorm、GELU、更少的激活、更大的卷积核）来提升纯卷积网络的性能；而另一条路线是在 CNN 中插入注意力模块，让模型在保留局部归纳偏置的同时获得全局建模能力。

混合路线的最大好处是实验成本可控：你可以在一个已经跑通的 CNN baseline 上做最小改动，加入一个模块，然后做完整的对照实验。这类工作的审稿风险也相对低，因为对比方法容易找、参数量容易对齐、消融容易做干净。

3. 环境准备：搭一套能复现的实验底座

3.1 硬件与软件的基本盘

硬件方面，一张 8G 到 24G 显存的卡足以支撑绝大多数学术实验的起步阶段。显存不够时，优先考虑混合精度训练（AMP）和梯度累积，而不是立刻换卡。混合精度通常能省 30% 到 50% 的显存，代价是需要处理梯度缩放；梯度累积则是用时间换显存，把 batch size 拆成多次前向再统一更新。

软件方面，Python 3.9 或 3.10 是目前兼容性最好的选择，PyTorch 2.x 系列在编译和性能上都有明显改进。具体版本以你所在实验室的服务器环境和组内代码为准，本文重点是演示通用思路，不建议盲目追最新版本——很多复现失败是版本漂移引起的，而不是代码逻辑有问题。

一个必须养成的习惯是：把环境固定下来。用 conda 导出环境文件，或者用 pip 的 requirements.txt 锁版本，把 CUDA 版本、PyTorch 版本、torchvision 版本三者的对应关系记在 README 里。这三者不匹配是最常见的启动失败原因。

bash复制# 创建并激活环境（版本以实际服务器 CUDA 为准）
conda create -n dl-research python=3.10 -y
conda activate dl-research

# 安装 PyTorch，注意 cu121 要和 nvidia-smi 显示的驱动兼容
pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121

# 常用辅助库
pip install numpy pandas matplotlib pyyaml tqdm tensorboard

# 导出环境，方便换机器复现
pip freeze > requirements-lock.txt

3.2 一套能撑住三个月实验的目录结构

实验代码最怕越写越乱。建议从第一天就按下面的结构组织，后面加模块、加配置、加脚本都不需要大改。

text复制dl-research/
├── configs/                 # 所有实验配置，一个实验一个 yaml
│   ├── cifar10_cnn.yaml
│   └── cifar10_cnn_se.yaml
├── data/                    # 数据集，加入 .gitignore
├── src/
│   ├── models/
│   │   ├── small_cnn.py
│   │   └── se.py
│   ├── datasets/
│   ├── utils/
│   │   ├── seed.py
│   │   └── logger.py
│   └── train.py
├── scripts/
│   └── run_seeds.sh
├── runs/                    # 每次实验的输出，加入 .gitignore
├── requirements-lock.txt
└── README.md

关键点是配置与代码分离。所有超参数写进 yaml，代码只读配置。这样做的好处是：做消融实验时，你只需要复制一份 yaml 改一个字段，实验记录天然就是可追溯的；写作阶段整理表格时，直接遍历 runs 目录读取每个实验的 result.json 就行。

yaml复制# 文件路径：configs/cifar10_cnn.yaml
experiment:
  name: cifar10_cnn_baseline
  seed: 42
  output_dir: runs/cifar10_cnn_baseline

data:
  name: cifar10
  root: ./data
  num_classes: 10
  batch_size: 128
  num_workers: 4

model:
  name: small_cnn
  dropout: 0.1

train:
  epochs: 50
  optimizer: sgd
  lr: 0.1
  momentum: 0.9
  weight_decay: 0.0005
  scheduler: cosine

3.3 随机种子必须固定到每一个环节

这是最容易被忽略、又最影响结论可信度的一步。深度学习实验的可变性来源有三处：Python 的 hash 随机化、NumPy 的随机数、以及 CUDA 的卷积算法选择。三者都要管。

python复制# 文件路径：src/utils/seed.py
import os
import random
import numpy as np
import torch

def set_seed(seed: int = 42) -> None:
    """固定所有随机源，保证同一配置多次运行结果一致。"""
    random.seed(seed)
    np.random.seed(seed)
    torch.manual_seed(seed)
    torch.cuda.manual_seed_all(seed)

    # Python 进程内 hash 随机化，影响 dict/set 的遍历顺序
    os.environ["PYTHONHASHSEED"] = str(seed)

    # 强制 cuDNN 使用确定性算法，会略慢但结果可复现
    torch.backends.cudnn.deterministic = True
    torch.backends.cudnn.benchmark = False

这里有一个权衡要说清楚：cudnn.deterministic = True 会让训练变慢，因为它放弃了自动搜索最快卷积算法的能力。在最终跑论文主结果时建议开启，在前期调参探索阶段可以关掉以节省时间。另外，即使固定了种子，不同显卡型号、不同驱动版本之间的结果仍可能有微小差异，这是硬件层面的浮点累加顺序导致的，写论文时不必追求比特级完全一致，只要同一台机器上可复现就够了。

4. 跑通 Baseline 的标准动作

4.1 怎么选一个“对的” baseline

选 baseline 有三个原则，缺一不可。

官方有开源代码。优先选作者提供了完整训练脚本的仓库，哪怕是第三方复现也行，但要看它的 issue 区是否有人成功复现出论文数字。没有代码的论文，对新手来说复现成本极高。

被引量足够且近期有对比工作。这决定了你后面找对比方法时会不会困难。一个只有几十次引用、近三年无人使用的方法，审稿人很可能会质疑你为什么不和更新的方法比。

算力可承受。一个需要 64 张卡训三周的方法，即使再经典也不适合作为你的起点。判断标准很简单：你手上的卡能不能在一天内跑完一个 epoch。

4.2 一个最小可运行的完整示例

下面用 CIFAR-10 加一个小型 CNN 演示完整流程。这个例子足够小，单卡几分钟就能跑完一个 epoch，适合用来验证整条流水线是否通畅。换成你自己的数据集时，只需要改 dataloader 和类别数。

python复制# 文件路径：src/models/small_cnn.py
import torch.nn as nn

class SmallCNN(nn.Module):
    """三层卷积块的小型骨干，用于验证训练流程。"""

    def __init__(self, num_classes: int = 10, dropout: float = 0.1):
        super().__init__()

        def block(cin: int, cout: int) -> nn.Sequential:
            return nn.Sequential(
                nn.Conv2d(cin, cout, 3, padding=1, bias=False),
                nn.BatchNorm2d(cout),
                nn.ReLU(inplace=True),
                nn.Conv2d(cout, cout, 3, padding=1, bias=False),
                nn.BatchNorm2d(cout),
                nn.ReLU(inplace=True),
                nn.MaxPool2d(2),
            )

        self.features = nn.Sequential(block(3, 64), block(64, 128), block(128, 256))
        self.pool = nn.AdaptiveAvgPool2d(1)
        self.classifier = nn.Sequential(
            nn.Flatten(),
            nn.Dropout(dropout),
            nn.Linear(256, num_classes),
        )

    def forward(self, x):
        return self.classifier(self.pool(self.features(x)))

训练脚本要包含四件事：数据加载、模型构建、训练循环、评测与落盘。其中“落盘”这一步很多人会省掉，结果是跑完十次实验后只能靠记忆回忆哪个配置对应哪个数字。

python复制# 文件路径：src/train.py
import argparse
import json
import os

import torch
import torch.nn as nn
from torch.utils.data import DataLoader
from torchvision import datasets, transforms

from models.small_cnn import SmallCNN
from utils.seed import set_seed


def build_loaders(root: str, batch_size: int, num_workers: int):
    """CIFAR-10 的均值方差来自训练集统计，直接用即可。"""
    mean = (0.4914, 0.4822, 0.4465)
    std = (0.2470, 0.2435, 0.2616)

    train_tf = transforms.Compose([
        transforms.RandomCrop(32, padding=4),
        transforms.RandomHorizontalFlip(),
        transforms.ToTensor(),
        transforms.Normalize(mean, std),
    ])
    test_tf = transforms.Compose([
        transforms.ToTensor(),
        transforms.Normalize(mean, std),
    ])

    train_set = datasets.CIFAR10(root, train=True, download=True, transform=train_tf)
    test_set = datasets.CIFAR10(root, train=False, download=True, transform=test_tf)

    train_loader = DataLoader(
        train_set, batch_size=batch_size, shuffle=True,
        num_workers=num_workers, pin_memory=True, drop_last=True,
    )
    test_loader = DataLoader(
        test_set, batch_size=batch_size, shuffle=False,
        num_workers=num_workers, pin_memory=True,
    )
    return train_loader, test_loader


@torch.no_grad()
def evaluate(model, loader, device):
    model.eval()
    correct, total = 0, 0
    for images, labels in loader:
        images = images.to(device, non_blocking=True)
        labels = labels.to(device, non_blocking=True)
        pred = model(images).argmax(dim=1)
        correct += (pred == labels).sum().item()
        total += labels.size(0)
    return correct / total


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--root", default="./data")
    parser.add_argument("--epochs", type=int, default=50)
    parser.add_argument("--batch-size", type=int, default=128)
    parser.add_argument("--lr", type=float, default=0.1)
    parser.add_argument("--seed", type=int, default=42)
    parser.add_argument("--out", default="runs/baseline")
    args = parser.parse_args()

    set_seed(args.seed)
    os.makedirs(args.out, exist_ok=True)
    device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

    train_loader, test_loader = build_loaders(args.root, args.batch_size, 4)
    model = SmallCNN(num_classes=10).to(device)
    criterion = nn.CrossEntropyLoss()
    optimizer = torch.optim.SGD(
        model.parameters(), lr=args.lr, momentum=0.9, weight_decay=5e-4,
    )
    scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=args.epochs)

    best_acc = 0.0
    for epoch in range(1, args.epochs + 1):
        model.train()
        running_loss, seen = 0.0, 0
        for images, labels in train_loader:
            images = images.to(device, non_blocking=True)
            labels = labels.to(device, non_blocking=True)

            optimizer.zero_grad(set_to_none=True)
            loss = criterion(model(images), labels)
            loss.backward()
            optimizer.step()

            running_loss += loss.item() * labels.size(0)
            seen += labels.size(0)

        scheduler.step()
        acc = evaluate(model, test_loader, device)
        best_acc = max(best_acc, acc)
        print(f"epoch={epoch:03d} loss={running_loss / seen:.4f} "
              f"test_acc={acc:.4f} best={best_acc:.4f}")

    with open(os.path.join(args.out, "result.json"), "w", encoding="utf-8") as f:
        json.dump({"best_test_acc": best_acc, "seed": args.seed}, f,
                  ensure_ascii=False, indent=2)


if __name__ == "__main__":
    main()

运行方式和验证方式如下。注意脚本里用的是 from models.xxx import，所以要在 src 目录下执行，或者把 src 加进 PYTHONPATH。

bash复制cd src
python train.py --epochs 50 --batch-size 128 --lr 0.1 --seed 42 --out ../runs/baseline_seed42

4.3 怎么判断 baseline 真的跑通了

判断标准不能只看“没有报错”。

先看损失曲线。正常情况下训练损失应该在前几个 epoch 快速下降，然后趋于平缓。如果损失几乎不动，先检查学习率是否太小、数据归一化是否漏了、标签是否错位。

再看精度量级。小型 CNN 在 CIFAR-10 上的常见水平在七成上下，用 ResNet-18 这类结构通常能到九成以上。如果你的结果和这个量级差得远（比如只有三成），说明流程里有问题，而不是“模型不够强”。具体数值请以你自己复现的结果为准，不要拿本文的数字当基准，因为数据增强、训练轮数、调度策略都会影响最终精度。

最后看稳定性。换三个不同的随机种子再跑一遍，如果三次结果的波动超过一两个百分点，那说明你的结论后续很难站住，因为改进带来的提升可能完全被方差淹没。

5. 从 Baseline 到创新点的四条可行路径

5.1 路径一：结构改进，最小改动最容易验证

结构改进是最直观的一条路，但也是最“卷”的一条。想做出差异，关键是控制参数预算。如果你加了模块，参数量从 11M 涨到 13M，那审稿人一定会问：涨的这部分参数如果直接加深网络，效果是不是一样？

一个务实的做法是选一个轻量模块，把它插入现有 backbone，然后做三组对照：原模型、原模型加模块、原模型加等量参数的普通卷积。第三组是关键，它能回答“收益到底来自模块设计还是来自更多参数”。

下面是 SE 模块的一个标准实现。它的思路是通道注意力：先全局平均池化把每个通道压成一个标量，经两层全连接学到通道权重，再乘回原特征图。

python复制# 文件路径：src/models/se.py
import torch
import torch.nn as nn


class SEBlock(nn.Module):
    """Squeeze-and-Excitation 通道注意力模块。"""

    def __init__(self, channels: int, reduction: int = 16):
        super().__init__()
        hidden = max(channels // reduction, 4)
        self.pool = nn.AdaptiveAvgPool2d(1)
        self.fc = nn.Sequential(
            nn.Linear(channels, hidden, bias=False),
            nn.ReLU(inplace=True),
            nn.Linear(hidden, channels, bias=False),
            nn.Sigmoid(),
        )

    def forward(self, x):
        b, c, _, _ = x.shape
        weight = self.fc(self.pool(x).view(b, c))
        return x * weight.view(b, c, 1, 1)

把它接进卷积块的方式很简单，在激活之后、残差相加之前插入即可。注意 reduction 这个超参要写进论文的消融表，取 8、16、32 的结果差异往往比模块本身更值得讨论。

5.2 路径二：损失函数与训练策略，改动小但容易出结论

相比结构改动，损失函数和训练策略的改动成本更低，而且容易讲清楚动机。

标签平滑（label smoothing）是把 one-hot 标签从 1 和 0 换成 1 - eps 和 eps / (K - 1)，本质上是给模型一个“别太自信”的约束，能缓解过拟合、改善校准性。它的实现只有几行，非常适合作为消融实验的第一组。

python复制# 文件路径：src/utils/losses.py
import torch
import torch.nn as nn
import torch.nn.functional as F


class LabelSmoothingCrossEntropy(nn.Module):
    def __init__(self, smoothing: float = 0.1):
        super().__init__()
        assert 0.0 <= smoothing < 1.0
        self.smoothing = smoothing

    def forward(self, logits: torch.Tensor, targets: torch.Tensor) -> torch.Tensor:
        num_classes = logits.size(-1)
        log_prob = F.log_softmax(logits, dim=-1)

        # 真实类别处的目标值
        with torch.no_grad():
            true_dist = torch.full_like(log_prob, self.smoothing / (num_classes - 1))
            true_dist.scatter_(1, targets.unsqueeze(1), 1.0 - self.smoothing)

        return (-true_dist * log_prob).sum(dim=-1).mean()

其他可考虑的方向包括：把交叉熵换成带类别权重的版本处理长尾分布，加入对比学习辅助损失，用 EMA（指数移动平均）维护一份教师权重做自蒸馏，或者引入课程学习按难度排序样本。这些改动都需要在论文里明确说明“为什么这个任务需要它”，否则容易被打成“堆 trick”。

5.3 路径三：数据层面，小算力下的高性价比方向

数据层面的改进常被低估。同一套模型，换一种数据增强策略，精度差异可能比换一个 backbone 还大。可做的方向包括：设计针对特定任务的增强（医学影像的弹性形变、遥感影像的旋转与色彩扰动）、用半监督方式利用无标注数据、用伪标签做自训练、用生成模型合成稀有类别样本。

如果走扩散模型合成数据这条路，需要注意一个审稿人常问的问题：合成数据和真实数据的分布差异怎么衡量？建议至少加一组对照，用真实数据训练、合成数据训练、混合训练三者对比，并给出 FID 之类的分布距离指标。

5.4 路径四：跨域迁移与组合创新

把一个成熟方法迁移到新场景，是最容易落地的一条路，前提是你要能说清楚“为什么直接迁移不行”。比如把自然图像的注意力机制迁移到医学影像，你需要指出两者的差异：医学影像的感兴趣区域更小、对比度更低、通道语义不同，因此原始的池化方式或感受野设置需要调整。

组合创新要警惕一个问题：把 A 和 B 拼在一起，必须有实验证明两者互补，而不是简单叠加。做法是分别做 A only、B only、A+B 三组，如果 A+B 的提升小于 A only 加上 B only 的各自提升之和，说明存在冗余，这时候要能解释原因。

6. 实验设计与消融：让审稿人信服的最小证据链

6.1 主结果表要回答什么

主结果表的作用不是展示你的方法最高，而是证明你的方法在同等条件下比其他方法好。所以表里必须包含三类信息：对比方法的来源（引用）、对比方法的参数量或计算量、以及你自己的方法在相同设置下的结果。

如果空间允许，建议把参数量（Params）和计算量（FLOPs）单独列一列。如果空间紧张，至少在正文里给出，否则审稿人很可能追问。

表里的“复现值”和“原文报告值”要分开标注。这是一个很多人忽略的细节：你无法保证在完全相同的设置下复现别人，所以诚实的做法是同时给出原文数字和你复现的数字，并说明差异来源（数据划分、增强策略、训练轮数）。

6.2 消融实验的最小完备集

消融不是“多跑几个实验”，而是“排除其他解释”。一个能过关的消融，通常包含四组。

第一组验证每个组件是否都必要：完整模型、去掉组件 A、去掉组件 B、两个都去掉。如果去掉某个组件后效果不掉，说明它没用，要么删掉要么重新设计。

第二组验证超参敏感性：关键超参取三到五个值，画一条曲线。审稿人最怕的是“你的方法只在某个特定超参下有效”。

第三组验证数据规模敏感性：在 25%、50%、100% 训练数据下分别比较。如果你的方法在低数据量下优势更明显，这是一个很好的卖点。

第四组验证计算开销：参数量、FLOPs、推理时间。收益和代价要同时呈现，只报收益不报代价会被认为是选择性汇报。

6.3 多次运行取均值，这一步不能省

单次运行的结果不足以支撑任何结论。建议每个配置至少跑三个种子，报告均值和标准差。下面这个脚本用于批量跑种子并汇总结果。

bash复制# 文件路径：scripts/run_seeds.sh
#!/usr/bin/env bash
set -e

cd "$(dirname "$0")/../src"

for seed in 42 43 44 45 46; do
  echo ">>> running seed ${seed}"
  python train.py \
    --seed "${seed}" \
    --epochs 50 \
    --batch-size 128 \
    --lr 0.1 \
    --out "../runs/baseline_seed${seed}"
done

汇总脚本读取每个 run 目录下的 result.json，计算均值和标准差，直接产出可粘进论文表格的数字。

python复制# 文件路径：scripts/summarize.py
import json
import os
import statistics

RUNS = [f"runs/baseline_seed{s}" for s in (42, 43, 44, 45, 46)]

accs = []
for run in RUNS:
    path = os.path.join(run, "result.json")
    with open(path, "r", encoding="utf-8") as f:
        accs.append(json.load(f)["best_test_acc"])

mean = statistics.mean(accs)
std = statistics.stdev(accs) if len(accs) > 1 else 0.0
print(f"n={len(accs)} mean={mean:.4f} std={std:.4f}")
print("raw:", [f"{a:.4f}" for a in accs])

如果两个配置的均值差小于一个标准差，基本可以认为差异不显著。这时候要么增大样本量（多跑几个种子），要么承认差异不显著并调整论文表述——后者远比硬说“提升了 0.3%”更安全。

6.4 审稿人最常提的四类质疑

第一类是“baseline 太弱”。应对方式是在对比表里加入近两年的方法，哪怕它们的结果是从原文引用的。

第二类是“消融不完整”。应对方式是按上面四组补齐，尤其是计算开销那一组。

第三类是“提升幅度太小”。应对方式是补充在更困难设置下的结果（低数据量、跨数据集、噪声数据），或者把论述重心从“精度更高”转到“在同等精度下开销更低”。

第四类是“超参不公平”。应对方式是明确写出你为对比方法做了哪些调参、搜索空间是什么。如果时间不允许为每个对比方法做完整搜索，就在论文里诚实说明并给出统一的调参预算。

7. 从实验记录到稿件：写作与投稿

7.1 推荐的写作顺序

不要从引言开始写。引言的每一句话都在为你的方法做铺垫，如果方法还没定稿，引言一定会反复重写。

推荐的顺序是：先做图表（主结果表、消融表、可视化图），再写方法（Method），再写实验（Experiments），然后写相关工作（Related Work），最后写引言和摘要。这样写的好处是，每一部分都有已经固化的证据支撑，不会出现“想说的结论没有实验支持”的情况。

方法部分要写到“别人能照着复现”的程度。公式要给出符号定义，模块图要标清张量维度变化，关键超参要写进正文而不是只放在附录。

7.2 表格与图的规范

表格建议用三线表，不要用竖线。LaTeX 里用 booktabs 宏包，视觉效果和期刊要求都更匹配。

latex复制% 文件路径：paper/tables/main_result.tex
\begin{table}[t]
  \centering
  \caption{Main results on two datasets. Best in bold.}
  \label{tab:main}
  \begin{tabular}{lccc}
    \toprule
    Method & Params (M) & Dataset-A (\%) & Dataset-B (\%) \\
    \midrule
    Baseline        & 1.2 & 00.00 & 00.00 \\
    Method-A        & 1.4 & 00.00 & 00.00 \\
    Ours            & 1.4 & \textbf{00.00} & \textbf{00.00} \\
    \bottomrule
  \end{tabular}
\end{table}

图的规范有两条硬要求：一是坐标轴必须有标签和单位，二是图例要能脱离正文独立看懂。很多稿子被打回是因为图里的曲线没有标注是训练集还是验证集。

7.3 选刊的几个务实判断

选刊不要只看影响因子。建议同时看四个指标。

审稿周期。很多期刊的官网会给出“submission to first decision”的中位数，这个数字对研二同学尤其重要，因为它直接决定你赶不赶得上毕业时间节点。

版面费。开源期刊通常收取文章处理费，金额差异很大，投稿前一定要确认，并且和导师沟通清楚。

主题匹配度。翻一下近两年的目录，看看有没有和你方法类型相近的文章。如果一本期刊从来不收某类方法，投过去大概率是编辑直接拒。

期刊状态。投稿前务必通过正规渠道确认期刊当前的收录状态，避免投到已经被移出核心数据库的刊物。这一步不能省，也不能只依赖中介或第三方列表。

7.4 投稿前的自查清单

最后一行值得单独强调。一稿多投、数据挑选、图表重复使用，这些在任何期刊都是明确的红线，一旦被记录，影响的是整个学术生涯，代价和一篇论文完全不成比例。

8. 常见问题与排查思路

表格里最值得展开的是“复现不出论文数字”这一条。实际经验是，大部分复现失败不是代码有 bug，而是默认值不一致。论文附录里写的 weight decay 5e-4，代码里可能是 1e-4；论文说训练 200 epoch，代码默认是 100；论文说用 cosine 调度，代码里其实是 step 调度。所以复现的第一步不是改代码，而是把所有超参列成一张表，逐项核对论文、附录、代码默认值三处是否一致。

另一个高频坑是评测协议。同样是 CIFAR-10，用中心裁剪还是全图、用 last epoch 还是 best epoch、是否做水平翻转增强测试（TTA），结果能差出一两个百分点。这些细节必须在论文里写清楚，否则别人复现你的工作也会遇到同样的问题。

9. 最佳实践与一份可执行的时间表

9.1 用 Git 管理实验，而不是管理代码

很多人用 Git 只管代码，其实更重要的是管配置。建议每个实验变体对应一个 yaml 文件，提交时把 yaml 和对应的 result.json 一起提交（或者至少记录 commit hash 到 result.json 里）。这样三个月后你回头看，能准确知道每个数字对应哪份配置。

一个实用技巧是在 result.json 里额外记录三个字段：git commit、运行时间、机器名。排查“为什么同样的配置结果不一样”时，这三个字段往往能立刻定位问题。

9.2 日志用 TensorBoard，不要靠 print

print 在调试阶段够用，但一旦并行跑多个实验，就需要可视化和统一目录。TensorBoard 的接入成本很低，几行代码就能记录 loss、accuracy、学习率曲线。

python复制# 文件路径：src/utils/logger.py
import os
from torch.utils.tensorboard import SummaryWriter


def create_writer(log_dir: str) -> SummaryWriter:
    os.makedirs(log_dir, exist_ok=True)
    return SummaryWriter(log_dir=log_dir)


# 在训练循环中按需调用：
# writer.add_scalar("train/loss", loss.item(), global_step)
# writer.add_scalar("val/acc", acc, epoch)
# writer.close()

关键指标建议固定命名，比如 train/loss、val/acc、train/lr。命名统一之后，多个实验的曲线可以直接在同一张图里对比，写作阶段画学习率敏感性图会非常快。

9.3 一份十二周的时间安排

第 1 到 2 周：读综述，确定任务和数据集，把组内已有代码跑通。

第 3 到 4 周：复现一个公开 baseline，把配置文件、日志、评测协议全部固化下来，拿到一组可信的基准数字。

第 5 到 6 周：确定改进方向，做最小可行改动，先验证“有没有效果”，不追求最优。

第 7 到 9 周：补齐消融实验、超参敏感性、多数据集验证，每个配置跑三个种子。

第 10 周：整理图表，写方法和实验部分。

第 11 周：写引言、相关工作、摘要，通读修改语言。

第 12 周：格式检查、引用核对、投稿前自查，投出去。

这个节奏的前提是算力不太紧张。如果单卡且数据集较大，建议把第 7 到 9 周拉长到五周，并且优先保证主结果和核心消融，把敏感性实验放到附录或者留作后续工作。宁可少做两个锦上添花的实验，也要保证主结果和核心消融是干净的，因为审稿人首先看的是这两块。

9.4 几条容易被忽略的工程建议

把数据集的划分文件（train/val/test 的索引）单独保存成 json 或 txt，不要依赖代码里的随机划分。这样换机器、换版本时划分完全一致，对比实验才有意义。

所有实验统一用一份评测脚本，不要每个实验写一份。评测口径不一致是“结果对不上”的头号原因。

在论文里报告推理时间时，写清楚硬件型号、batch size、是否使用混合精度、是否包含预处理。只写“快 20%”而不给条件的表述，会被要求补充。

涉及医学、人脸、用户行为等敏感数据时，务必确认数据使用授权和伦理审批，脱敏处理做到位。这部分在投稿时通常需要声明，缺失会直接影响送审。

10. 回到最开始的那个问题

CNN、Transformer、Diffusion 怎么选，答案并不在某个排行榜上，而在你的任务类型、数据规模和算力预算三者的交集里。判别任务优先考虑 CNN 或 Transformer，生成任务优先考虑 Diffusion；数据少就选归纳偏置更强的结构，算力紧就选轻量化或混合架构。选定之后，真正的功夫在于把这个 baseline 跑到可信、把改动做到可控、把证据链补齐。

从跑通 Baseline 到写出稿件，中间没有哪个环节是“靠灵感”的。环境固定、种子固定、配置与代码分离、每个变体都留一份可追溯的记录、关键结果跑三个种子取均值——这些做法听起来琐碎，但它们决定了一篇稿子是“看起来像论文”还是“经得起追问”。审稿人真正在意的，从来不是你提出了多惊人的想法，而是你说的每一句话背后有没有对应的实验。

如果你现在正准备开始，建议就从最小的一步做起：把本文那个 CIFAR-10 的示例跑通，然后把数据集换成你自己的，把配置抽成 yaml，把结果落成 json。这条流水线一旦建立起来，后面换模型、换任务、换方向，你都只需要替换中间那一小块。这套底座，比任何一篇具体的论文都更值得先花两周时间打磨好。