如何高效推进实验？（慢即是快）

前期投入时间做基建，后期往往走得更快

• 保持清晰整洁的开发习惯：
  • 规范的目录结构。
  • 严谨一致的变量、函数、类命名规范。
  • 遵守规范的 git commit messages。
• 分门别类地组织好项目文件：数据（Data）、相关工作（Related Work）、实验代码（Code）、运行日志（Log 日志）、模型权重（Checkpoints）必须各归其位。
  • 协作便利：清晰的架构便于人与人之间合作，也极大地方便了与“AI 同事”（Coding Agent）进行交接。
  • Rebuttal 的保障：在投稿后 3、4 个月甚至更久，当审稿人意见返回需要紧急补充实验时，清晰的基建能让你依然能一眼看懂自己当初的代码，避免重写代码的悲剧。
• 对 AI 辅助编程（Coding Agent）的正确态度：
  • 不要求完全看懂 AI 生成的每一行代码，但需要了然于胸：
    • 核心的研究逻辑（你的主要学术贡献点）在哪里？
    • 整体的代码框架是如何组织和调度的？
  • 严格做好数据与评估的双重把关：
    • 确保数据清洗与处理（Data Curation）是百分之百正确无误的。
    • 确保模型的评估机制（Evaluation）是完全客观、公平（Fair）的。

project/
├── data/          Data
├── related_work/  Related Work
├── src/           Code
├── logs/          Log
├── checkpoints/   Checkpoints
└── results/       实验结果与分析

何恺明（Kaiming He）的科研信念： 面对 5000 张 TPU 的庞大计算规模，当别人都觉得难以驾驭和使用时，何恺明选择从头开始一点点自己搭建一整套底层的 Infrastructure（基建工程），这为他后续产出 MoCo、CoCo、MAE、DiT 等一系列极具统治力的开创性工作奠定了坚实的基础。

设计实验的主旨：永远为 Claims（论文主张）服务

常见的研究陷阱

“我设计了一个极为花哨、复杂的方法，不停地调参、调参 终于运气好刷点刷到 SOTA（榜一）了！立刻开写文章！”

目标绝不仅仅是刷到一个 SOTA 数字就结束了。你必须能够回答：

1. 为什么它能 Work？性能的提升到底来源于哪个模块？ —— 这绝对不是写完论文后才去补的“事后诸葛亮”分析，而应该在设计之初，就在实验中时时进行消融实验（Ablation Study）和对比实验。
2. 它到底解决了什么 Gap？ —— 如果是为了写论文而去生硬地“后编”故事，会导致你对竞争对手（Baselines）的理解不够深入。

1. 01Claim
2. 02实验设计
3. 03主实验 / 消融 / 对比
4. 04结果与回答 Claim

优秀科研习惯的几条黄金法则

Kaiming He 的品味

在解决实际问题之前，先把 Baseline（基线）做到尽可能高、甚至无可提高的极致状态。在此之后展开的研究，才是真正有价值的开始。做出更 Work、更有开创性（Ground-breaking）的工作；如果在很弱的 Baseline 上做性能提升，往往只是虚假的繁荣，没有实质性的学术意义。

Spreadsheet 实验管理与分析框架

进入研究的第一课，是要学会在做实验前先搭好 Research 表格，精确设计好表格的每一行和每一列：要包含哪些评估指标、如何安排对比实验、如何通过数据指标的推演得出逻辑链条。必须让实验的全局全景图（Landscape）和每一组实验的梯度变化始终清晰可见。

Claim / 问题	Baseline	改动	评估指标	预测结果	实际结果	得出的判断
待验证的研究主张	最强基线	Module / Setting	Metrics	跑实验前先预测	运行后填写	支持还是反驳？

负向结果（Negative Results）的正面意义

反向的结果同样包含极高的信息量（Info Gain）。如果发现某条路径完全行不通、或者指标没有任何变化，在确保实验设计正确的前提下，这也是一个重要发现，可以帮助你及时更新对某个问题的学术认知，调整研究路径。

基于表格去预测实验结果

在实验跑出结果前，基于现有的理论和推断去“预测”表格里的数字，再通过实际运行结果与预期之间的偏差，去审视自己的物理 / 数学直觉，进而更新认知。

实验过程管理：层级清晰、可复现

实验入口必须清晰明了

争取做到一键（单条命令）批量运行所有核心实验。这既有利于自己高效推进项目，也极大地方便了开源后同行的复现与引用。

大规模实验的避坑指南

在租用大量昂贵算力进行大规模运行前，必须先确保在最小的数据子集上，整个代码流水线的闭环是可以跑通的。

例如：先调用便宜的轻量级模型，跑 5 个样本，确认输入、推理、评估、日志输出等所有环节均没有 Bug 后，再启动大规模集群实验。

1. 015 个样本 + 便宜模型
2. 02输入 → 推理 / 训练
3. 03评估 → 日志输出，全部跑通
4. 04大规模集群实验

日志系统必须健全完整

• 规范化打印详尽的实验运行日志（Log），便于在任务中断或报错时迅速定位问题。
• 在长周期代码中，必须合理设置错误自动重试机制（Retry）与断点续训 / 保存机制（Checkpoint）。

本专题继续阅读

• 基础与工具全景
• 代码与项目工具链
• 进度管理与科研心态