24年10月准备冲ICML，一路磕磕碰碰到DDL，还是没能跑出任何拿得出手的数据。 经此一役，我意识到，科研的理想状态并不是“有一个很好的想法，就能把它实现”。于是，本着learning from errors的精神，写下这篇文章，记录一些我在科研过程中总结的经验教训。

0.心态：你的时间并不那么紧迫

即便冲会议，“冲会议”这个念头也应当放在战略层面，而非心态层面。 如果一开始就以“时间很紧啊”“要有点紧迫感啊”来鞭策自己以及组员，就很容易陷入“着急忙慌改model，每天急切地期望它涨点，可是每天都不涨”的困境。 再着急的会议也不是一天两天的事，况且很多时候大家也并非专门瞄着某个会，非它不可。所以心态上一定不能急躁，不要想着赶紧把实验跑起来然后随便一改就涨点了。 另外，摈弃”只有写运行代码才是有用功“的思维。 以前我也喜欢在一些小问题上囫囵吞枣，草草看paper，懒得写注释，命名随意······这些都在无形中增大项目的管理难度，越到后期问题越多。

1.调研&学习baseline

这是对我上次失败contribute最直接的一项。如果一开始老老实实把所有模棱两可的疑点弄明白，后期将会节省大量时间。有些事情确实应该边做边学，边做边找问题，但至少对于当前工作的核心部分，基本的原理必须吃透。 所谓吃透，就是达到面试级别的掌握程度。如果只是看了几篇博客就觉得可以开工，那么很可能遗漏各种细节和知识。而那些遗漏的细节将会在一次次实验中暴露，浪费大量时间；那些似是而非的知识，后期会学习一遍又一遍，还是似是而非。

2.时间管理

可以没有非常fine-grain的时间安排，但至少要有战略性的规划，要在项目开始前明确应该分几个阶段，要做哪些事，大概按照什么顺序开展，耗时大概多久。 写周报或日报。可以自己写也可以督促大家一起写。记录每天的收获和工作。这样可以避免陷入某个局部浑浑噩噩度过好多天才惊觉。

3.代码管理

如果有多台机器，如果有多个集群共用一个跳板机的情况，不要用分支，直接写多个model.py，否则log不好同步。 实验结果全部记录在一份组里共同可见的文档中。 log命名一定要清楚，不要以为自己记得住（也可以带上日期以便和日报对应上）。 ckpt命名最好和log一致，便于后续做分析。 注释一定要写。一般大家的commit记录都乱七八糟，所以最好在注释末尾加日期，这样你只要一对照日报就能知道这是什么时候改的。

4.实验管理

跑实验前把baseline所有的config项都看一遍（很可能出现一些似是而非的参数，是baseline用来跑ablation study的，一定不能马虎） 注意可复现性，如果在不同的机器跑，最好在每个机子上都跑一遍baseline。 一定要有分析模型和实验结果的方法，不要靠简简单单的一个metric来猜测一切。要想好怎么分析自己的改动，如何可视化，这对于写paper也很有帮助。

5.精神

人总会不开心，甚至会丧失信心，大家都是如此。 在面对挫折时，如果信奉”英雄不是不会跌倒，而是哪怕跌倒了都能恢复“，那么还是停留在鸡汤层面。咱们做机器学习的，应该相信挫折即知识。也许自己的初始位置不够好，但是通过足够多的错误和挫折，我们能学习到足够多的教训。越珍惜挫折就进步得越快。 当然，人不像机器那样孜孜不倦地“学习”，并且，人遇到错误都会难过，因此，保持良好的精神状态也许更重要。累了就休息，效率太低就暂时放空两天。一定要警惕浑浑噩噩，感觉每天都在忙碌实则虚度光阴（写日报一定程度能避免这个情况）。

6.其它

TBD