“跑通”这两个字，在深度学习或者说 AI 项目复现里，意味着你终于把别人公开的代码在本地环境里跑出了预期的结果。但跑通从来不是终点，它只是起点。大多数人跑通之后会陷入一段短暂的真空期：接下来干什么？是调参？是换数据集？是动模型结构？还是直接去改损失函数？这篇文章不谈虚的，直接围绕“项目代码跑通后如何做创新、改进、修改损失”这个主题，把后续的路线、实验方法和工程化落地方案拆开讲清楚。
先说一个容易被忽略的事实：跑通的代码是“别人的理解和假设”。你只是验证了这套假设在你的环境里成立。真正的改进，是从你开始改动第一个变量、记录第一次对比实验开始的。下面从三个层面展开：先讲改损失函数这个高频需求怎么做才不出错，再讲模型创新和改进的通用路径，最后讲工程化整理与代码规范的落地，也就是把“能跑的代码”变成“能迭代的代码”。
1. 核心问题：跑通之后，为什么第一件事不是改代码而是建基线
很多人在项目跑通后，第一反应是“这里能不能改一下”“那里能不能换一个”。这种冲动可以理解，但缺少基线意识的修改，最后往往无法判断改动到底是好是坏。
基线（Baseline）是指你当前已经跑通的那套配置，包括损失函数、学习率、batch size、数据增强方式、模型结构、优化器选择等。跑通之后的第一步，是把这套配置固定下来，并且完整记录下来。推荐至少记录以下几项：
| 记录项 | 说明 |
|---|---|
| 环境版本 | Python、PyTorch/TensorFlow、CUDA、GPU 驱动版本 |
| 数据集 | 训练集/验证集/测试集划分、数据量、预处理方式 |
| 模型结构 | 主干网络、头部结构、是否加载预训练权重 |
| 损失函数 | 损失名称、各项权重、是否辅助损失 |
| 优化器与调度器 | 优化器类型、学习率、动量、权重衰减、学习率策略 |
| 训练配置 | batch size、epoch、梯度累积、混合精度 |
| 初始指标 | 跑通后的 loss 规模、验证集准确率或其它核心指标 |
有了基线，后续的每一次修改才可量化。否则你改了十处代码，最后指标涨了，你都不知道是哪一处带来的收益。
这里建议用版本控制工具管理代码，同时用实验记录工具管理指标。最简单的做法是先把项目目录初始化成 Git 仓库，然后把“跑通版本”打上 tag。之后每次改动都基于新分支进行，不要在主分支上直接乱改。
# 先把跑通版本固化为基线 git init git add . git commit -m "baseline: reproduce original project, training converged" git tag baseline_v1.02. 修改损失：最容易被高估也最容易被搞砸的环节
改损失函数是项目改进中最常见、也最容易翻车的操作。很多人看到论文里某个损失效果不错，直接拿来替换原项目的损失，结果模型不收敛，或者指标反而下降，然后就开始怀疑代码有问题。其实多数情况下不是代码有问题，而是你对损失的适配条件理解不够。
2.1 先理解原损失为什么成立
在动手改之前，先弄清楚原始损失函数解决的是什么问题。以图像分类为例，交叉熵损失关心的是预测分布和真实分布的差异；以目标检测为例，损失通常由分类损失和回归损失组成，两部分权重会直接影响训练平衡；以生成模型为例，损失可能包含对抗损失、感知损失、特征匹配损失等多个项。
你需要搞清楚三个问题：
- 原损失函数的每个项分别约束模型哪部分行为？
- 各项之间的权重系数是怎么来的？是否有论文依据？
- 当前损失在你的数据分布下是否存在明显短板？
只有回答完这三个问题，你才知道该不该改、从哪里改。
2.2 修改损失的正确步骤
修改损失不是“找到 loss.py 改几行”这么简单。下面给出一条经过验证的通用流程：
第一步，记录当前基线的 loss 曲线和指标曲线。这一步不能省，至少保留训练集和验证集的 loss 曲线、核心指标随 epoch 变化的曲线。
第二步，只改一个变量。比如你计划把原来的交叉熵换成 focal loss，那就只改损失部分，其它所有配置保持不变。不要同时换优化器、调学习率、改数据增强。
第三步，用较小规模数据快速验证。不要一开始就全量数据跑几十个 epoch。可以取训练集的 10% 或 20%，跑少量 epoch，观察 loss 是否能下降、梯度是否稳定。这一步能快速暴露是否出现 NaN、是否不收敛、是否梯度爆炸等问题。
第四步，小规模验证通过后，再跑完整训练。同时记录不收敛时的处理方式，比如是否需要调整损失权重、是否需要降低学习率、是否需要 warmup。
第五步，对比基线。把新损失的最终指标和基线记录放在同一张表里，看是否有提升。如果没有提升，不要急着放弃，先检查实现是否有 bug，再考虑是否这个损失根本不适合当前任务。
# 修改损失时的代码示例：以 PyTorch 为例 class CombinedLoss(nn.Module): def __init__(self, alpha=1.0, beta=0.5): super().__init__() self.alpha = alpha # 原始损失权重 self.beta = beta # 新增损失权重 def forward(self, pred, target, feat=None): # 原始损失 loss_base = F.cross_entropy(pred, target) # 假设新增一个辅助正则损失，这里仅为示例 loss_aux = 0.0 if feat is not None: loss_aux = torch.norm(feat, p=2) ** 2 / feat.size(0) return self.alpha * loss_base + self.beta * loss_aux2.3 常见的损失修改方向
根据任务类型不同，可选的损失改进方向也不一样。这里整理几个常见方向，具体适用性要以你的项目和基线表现为准：
| 改进方向 | 适合场景 | 注意事项 |
|---|---|---|
| 换用更稳健的损失 | 类别不平衡、难样本较多 | focal loss、dice loss 等，注意调整 gamma 或 alpha |
| 在原始损失上增加正则项 | 过拟合、特征分布异常 | L2 正则、特征正交正则、对比正则 |
| 引入辅助损失 | 深层网络训练不稳定 | 在中间层加辅助分类损失，注意辅助损失权重 |
| 损失函数加权 | 多任务学习、多损失项 | 各项权重的比例需要调参，考虑不确定性加权 |
| 自监督辅助任务 | 标注数据少、特征表示弱 | 需要额外构造预文本，训练成本会增加 |
每一条都值得单独验证，不要一次性全部叠加。
3. 改进与创新：从复现到“做出不同”的四条可执行路径
代码跑通之后想做改进，不一定非要自己从零设计一个新模型。对绝大多数场景来说，创新是组合出来的，不是凭空造出来的。下面四条路径是按投入产出比排序的。
3.1 路径一：数据侧改进
数据是影响模型效果最直接的因素。原始项目使用的数据分布不一定适合你的真实场景。你可以：
- 收集与任务更匹配的真实数据，替换或扩充原有数据集。
- 调整数据预处理流程，比如归一化参数、图像尺寸、灰度化方式。
- 增加数据增强策略，例如随机裁剪、旋转、颜色抖动、MixUp、CutMix。
- 检查数据标注质量，清洗错误标签，建立更合理的验证集。
数据改进不属于“改模型”，但它经常比改模型带来更明显的效果提升。而且数据改进的风险最低，不太需要担心模型不收敛。
3.2 路径二：训练策略改进
训练策略包括学习率调度、优化器选择、批大小、梯度累积、混合精度、EMA、对抗训练等。这类改进不需要改动模型结构，只需要修改配置或少量训练代码。
一个比较实用的做法是复现原项目之后，先做一组学习率和 batch size 的敏感性分析。很多时候你只需要把学习率调低一点、把训练步数拉长一点，指标就会有稳定提升。
# 示例：在原有训练脚本中启用 EMA 更新 model_ema = copy.deepcopy(model) decay = 0.999 def update_ema(model, model_ema): with torch.no_grad(): for p_ema, p in zip(model_ema.parameters(), model.parameters()): p_ema.data.mul_(decay).add_(p.data, alpha=1 - decay)EMA 在很多视觉任务里都能带来稳定提升，代码量不大，风险可控。
3.3 路径三：模型结构改进
模型结构改进是大多数人理解的“创新”，但它也是风险最高的改进方式。这里不推荐直接凭空发明新结构，更稳妥的方式是替换或插入成熟模块。
具体做法是：先分析出原始模型中的薄弱模块，比如下采样方式、注意力机制、特征融合方式、激活函数、归一化层，然后用成熟的新模块替换它，进行消融实验。
举例来说：
- 原始模型用的普通卷积，可以考虑替换成深度可分离卷积或空洞卷积，降低参数量或扩大感受野。
- 原始模型没有注意力机制，可以在主干输出后增加一个轻量级注意力模块。
- 原始模型的特征融合方式只是简单相加，可以改成 concat 后接 1x1 卷积，或者使用加权融合。
改结构一定要遵循“单变量替换 + 消融实验”的原则。一次只替换一个模块，逐个验证。
3.4 路径四：损失函数改进
这条路径在上一节已经展开。损失改进本质上是“引导模型向更合理的方向学习”。如果你的任务存在类别不平衡、难样本太多、多任务权重失衡等问题，损失改进的收益会比较明显。
4. 实验管理：没有记录的改进等于白做
很多项目改进失败，不是因为方法不行，而是因为实验记录混乱。你改了三版代码，跑了一堆结果，最后根本分不清哪次用了哪个配置。
建议从跑通之后就开始建立实验记录体系。如果不想引入重量级的实验管理工具，至少要做到以下几点：
- 每次实验建立独立配置文件，包含所有超参数项。
- 训练日志统一保存到单独目录，按日期和实验名称命名。
- 每轮实验结束后，把关键指标整理到一张汇总表中。
- 每个实验对应一个 Git 分支或 commit。
# 推荐的项目目录结构 project/ ├── checkpoints/ # 模型权重 │ ├── baseline/ │ └── experiment_focal/ ├── configs/ # 实验配置文件 │ ├── baseline.yaml │ └── exp_focal.yaml ├── data/ # 数据目录 ├── logs/ # 训练日志 │ ├── baseline.log │ └── exp_focal.log ├── scripts/ # 训练和评估脚本 ├── src/ # 源代码 ├── results/ # 结果汇总 └── README.md如果你有精力，可以接入 WandB 或 TensorBoard。把 loss 曲线、学习率曲线、梯度范数、验证集指标都可视化出来，比只看终端日志直观得多。
# 使用 TensorBoard 记录训练指标，简单易用 from torch.utils.tensorboard import SummaryWriter writer = SummaryWriter(log_dir="logs/baseline") for epoch in range(epochs): train_loss = train_one_epoch(...) val_acc = validate(...) writer.add_scalar("loss/train", train_loss, epoch) writer.add_scalar("metrics/val_acc", val_acc, epoch) writer.add_scalar("lr", current_lr, epoch)5. 消融实验：证明你的改进有效而不是“感觉有效”
消融实验（Ablation Study）是证明改进有效性的核心手段。它的基本逻辑是：从完整方案中逐步去掉某个模块或改动，观察性能变化。如果你的改进确实有效，去掉它之后性能应该下降。
实际执行时建议按这个顺序：
第一组：基线模型，不加任何改动。 第二组：基线 + 只加第一个改动。 第三组：基线 + 只加第二个改动。 第四组：基线 + 两个改动都加。
通过这四组实验，你能看出每个改动单独的贡献，以及两个改动之间是否有交互作用。有时候单独看每个改动都是负收益，但两个改动加起来是正收益，这是因为它们之间存在互补性。这种情况在消融实验里也很常见，需要特别注意。
如果一组改动太多，两两组合的消融实验数量会非常大，所以先做单一改动实验，再挑有潜力的组合验证即可。
6. 工程化整理：把可跑的代码变成可迭代的代码
代码跑通之后，如果不做工程化整理，直接在上面继续改，很快会陷入“改一处坏一处”的局面。尤其多人协作时，代码结构混乱会严重影响效率。
6.1 项目结构整理
以 PyTorch 项目为例，一个相对清晰的结构可以按功能分层：
project/ ├── configs/ # 所有实验配置，yaml 或 json ├── data/ # 数据加载与预处理 │ ├── dataset.py │ └── transforms.py ├── models/ # 模型定义 │ ├── backbone.py │ ├── head.py │ └── criterion.py # 损失函数都放这里 ├── engine/ # 训练与验证逻辑 │ ├── trainer.py │ └── evaluator.py ├── utils/ # 工具函数 │ ├── logger.py │ └── metrics.py ├── scripts/ # 入口脚本 │ ├── train.py │ └── eval.py └── tests/ # 单元测试把损失函数单独放在criterion.py里，是一个非常重要的习惯。这样当你尝试不同损失时，不需要去翻训练主流程，只需要替换 criterion 的实例化代码。
# criterion.py 中统一管理损失函数 class CriterionFactory: @staticmethod def create(cfg): loss_type = cfg.loss.type if loss_type == "cross_entropy": return CrossEntropyLoss(**cfg.loss.params) elif loss_type == "focal_loss": return FocalLoss(**cfg.loss.params) elif loss_type == "combined_loss": return CombinedLoss(**cfg.loss.params) else: raise ValueError(f"Unknown loss type: {loss_type}")6.2 代码自动校验与格式化
跑的代码随着迭代会越来越乱。建议配置 Ruff 或 Black 做代码格式化，配置 pre-commit 做提交前检查。这个过程能显著降低代码 review 的沟通成本。
# .pre-commit-config.yaml 示例 repos: - repo: https://github.com/astral-sh/ruff-pre-commit rev: v0.1.0 hooks: - id: ruff - repo: https://github.com/psf/black rev: 23.10.0 hooks: - id: black# 安装 pre-commit 并启用 pip install pre-commit pre-commit install6.3 Git 使用规范
跑通版本提交一个 baseline commit 后，后续所有改进实验都应该开独立分支，不要直接在 master 上改。
# 创建实验分支 git checkout -b exp/focal_loss # 实验结束，记录结果后合并回主分支 git add . git commit -m "exp: replace CE loss with focal loss, +1.2% val_acc" git checkout master git merge exp/focal_losscommit message 建议写清楚“改了什么 + 带来了什么效果”。这种习惯能让你在几周后回看代码历史时，还能快速定位到具体改动。
7. 如何判断一个改进是否真的值得保留
跑通之后你可能会尝试很多改进思路，但并不是所有让指标提升的改动都值得保留。需要从多个维度评估：
| 评估维度 | 判断标准 |
|---|---|
| 指标提升幅度 | 是否在多个随机种子下都稳定提升，而非单次运气 |
| 推理速度影响 | 参数增加多少，推理时间增加多少 |
| 显存占用变化 | 显存是否大幅上涨，训练 batch size 是否需要缩小 |
| 训练稳定性 | 是否更容易发散，是否对学习率更敏感 |
| 代码复杂度 | 是否引入了大量难以维护的代码 |
| 可复现性 | 在不固定随机种子时，效果是否仍稳定 |
一个只在单一随机种子下涨点、换个种子就失效的改进，大概率是噪声，不构成真正的贡献。最稳妥的做法是用 3 个不同随机种子跑 3 次实验，取均值和方差来判断。
8. 常见问题与排查方法
下面整理项目跑通后做改进时最常见的几个问题，以及对应的排查思路。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 修改损失后 loss 为 NaN | 损失中存在除零、log(0)、梯度爆炸 | 检查损失输入是否有负值或极小值；打印梯度范数 | 加 epsilon，使用 clamp，降低学习率 |
| 修改损失后 loss 不下降 | 损失权重过大，或新损失与任务不匹配 | 单独测试新损失在随机初始化下的表现 | 先小权重起步，逐渐增大；用一个小 toy dataset 验证 |
| 指标没有变化 | 改动可能没有影响核心行为 | 检查是否有 bug 导致新代码没有被真正调用 | 在损失函数里加 print 并确认调用次数 |
| GPU 显存不足 | 新增模块或损失导致中间变量增多 | 观察显存占用变化 | 减小 batch size，使用梯度累积，开启混合精度 |
| 训练速度明显变慢 | 新模块计算复杂度过高 | profiler 定位耗时模块 | 替换为轻量级实现，或在低分辨率验证 speed |
| 多机或多人协作时改乱代码 | 缺少分支管理和格式化 | 检查 git log 和分支状态 | 建立分支规范，启用 pre-commit |
9. 最佳实践与建议
最后整理几条跑通之后最实用的工程建议。
第一，先跑通，再微调。不要在项目第一次运行成功后就急着大改。先保留基线，理解每个文件是干什么的，再开始动代码。
第二，一次只改一个变量。不管改损失、改结构、改训练策略，都遵循这个原则。同时改太多，出了问题根本定位不了。
第三，优先做数据侧改进。数据质量提升带来的收益往往比改模型大得多，而且代码改动量小。
第四，记录每一个实验。哪怕结果不好，也要记录“什么方法不行、为什么不行”。这种“负结果”在你后续挑选方向时非常有价值。
第五，代码规范化放在改进之前。先把项目结构整理好、格式化工具配好、Git 分支规范定下来，之后再改模型和损失会舒服很多。
第六，涉及人脸、声音、版权数据等任务时，务必确认数据和模型使用的合法授权。技术实验要做，但要在合规边界内进行。
10. 总结与下一步
跑通项目代码之后，最应该做的第一件事是固化基线并完整记录实验环境，第二件事才是考虑创新和改进。修改损失函数时，要遵循“理解原始设计 → 单变量改动 → 小规模验证 → 完整训练 → 对比基线”的流程，不要上来就大改大换。模型结构改进则要优先替换成熟模块而不是凭空发明结构。与此同时，工程化整理、实验记录、消融实验和 Git 分支管理，决定你后续迭代能走多远。
如果你现在正好卡在“代码跑通但不知道下一步做什么”，建议先花一两天时间把项目结构整理清楚，用 git tag 固定基线，然后挑选一个你最关心的方向做第一组对比实验。先从数据或训练策略入手，风险最低；等对代码熟悉了，再考虑动损失或模型结构。
这套思路不仅适用于单个项目，也适用于你以后接触的大多数深度学习项目。建议收藏备用，下次跑通新项目时按这个流程走一遍。
