凌晨一点半，实验室群跳出一条消息：“ICLR 2026放榜了”。我核对完四篇论文的ID，全部都是Accepted。高兴归高兴，放下手机之后我更想做的是把整个投稿过程复盘一遍。原因很简单：四篇一起被录用，这件事放在哪个实验室都算不上理所当然。

ICLR是这几年机器学习社区公认的重要会议之一，评审量大、审稿意见细，而且整个流程公开。很多人以为中稿靠的是灵感或者运气，但站在实验室的角度，一次四个方向同时中稿，背后其实是选题、实验、写作、Rebuttal这四条线同时达标的结果。这篇文章会把这四条线逐一拆开，讲清楚我们到底做了什么、踩过哪些坑，以及哪些投入是真正值得的。如果你正准备投稿，或者在等结果，下面的内容应该对你有用。

1. 一个中稿数字背后：这届录用比想象中更挑剔

1.1 评审机制决定了：录用不是“投票通过”就算数

ICLR的核心关注点是表示学习，从会议名字就能看出来，它比较看重方法能不能把问题的底层逻辑说清楚，而不是论文里堆了多少个得分点。每年投稿量都在涨，评审也越来越辛苦，很多稿子还没进入作者回复阶段，就已经因为“读不懂”被扣掉不少分。ICLR的评审过程和某些会议不一样，在正式结果出来前，作者能读到审稿人之间的讨论，也能通过回复重新影响评分。也就是说，最终录用名单是反复博弈后的结果，不是一锤定音。

这带来的直接影响是，中稿难度有很大一部分藏在“评审能不能顺利理解你的论文”上。同一项工作，如果写作混乱、实验设计关联不清，评分会差出很多。反过来，只要研究问题真实、方法逻辑清晰、实验证据链完整，就算某个审稿人给了低分，也有可能在讨论环节被拉回来。我们这次四篇里，就有两篇的评分最初并不高，是靠Rebuttal和审稿人讨论翻回来的。

1.2 四篇同批录用，不代表四个方向都在极热赛道

我把四篇论文拆成四个方向后发现，它们并不是最近热度最高的几个话题。第一篇处理少样本下的泛化问题，第二篇处理图结构里的长程依赖，第三篇做生成模型的采样加速，第四篇关注多模态对齐中的噪声数据。方向分散，意味着这批论文背后不是运气共振，而是方法论的一致——都从真实痛点出发，都做清楚了实验，也都把写作和回复当成正式工作来对待。下面这张表是我们复盘时常用来对照的四条线：

这张表看起来普通，但把四篇论文真正串起来的正是它。一个实验室如果连续两三轮投稿都能保持这个框架，中稿数量自然会稳定在一个水平上。反过来，哪一线没做到位，审稿意见里几乎一定会暴露。与其说我们在做四篇论文，不如说我们在用同一个质量标准做四件事。

2. 四篇论文的选题逻辑：我们没有追最热的方向

先说结论：这四篇论文没有一篇是冲着榜单或热点去的，至少在最开始不是。我们选方向的时候反复问自己，某个问题是不是真实存在，现有方法是不是有一块明显的短板，而我们手上的资源和能力能不能补上这块短板。三个问题的答案都符合，才会投入时间。

2.1 少样本场景下的泛化稳定性：从用户痛点倒推问题

第一篇，少样本条件下的泛化稳定性。这个问题听着不新，但每天都有没标注的数据、小样本场景出现，所以延展性很强。我们注意到很多已有方法都假设训练数据足够充分，一旦数据量掉下来，模型表现就很不稳定。于是我们希望找到一种方式，把“有限样本下的不确定性”显式建模进训练流程。选题的起点不是某篇刷榜论文，而是落地时反复出现的痛点。判断要不要做的标准很简单：我们把问题写成一句话，拿去问没有参与的同学，他能不能在一分钟内察觉这个问题有实际影响。如果不行，说明问题陈述还不够具体。

2.2 图数据的长程依赖：不是搭新结构，而是给位置一个连续表达

第二篇，图结构数据里的长程依赖。图模型在多层之后普遍存在过平滑问题，这是圈内都知道的公开难题。我们并没有像很多人那样直接堆叠更多层，而是换了个角度：给节点位置设计一种连续表达，让深层信息传递时位置编码依然清晰。选这个方向是因为它从已知缺陷出发，创新点更容易被理解，也更容易通过消融实验验证。对于首次尝试顶会投稿的人来说，最忌讳的是把一个模糊想法包装成一个大主题，最后做出来一堆指标却说不清机制。

2.3 生成模型的少步采样：把训练时的约束变成推理时的免费午餐

第三篇，生成模型的少步采样加速。生成模型要迭代很多次才能产出高质量结果，这在计算资源有限时很费劲。我们做的是训练阶段的一致性约束，让模型在少步推理时误差不逐层累积。这属于那种“读论文时一眼能看出意义”的题目，因为速度和质量的矛盾是客观的。但我们花了很长时间才想清楚：真正要解决的问题是误差累积，不是单纯减少迭代步数。这两句话的区别决定了实验设计完全不同。

2.4 多模态对齐的噪声样本：先学会判断哪些数据该被忽略

第四篇，多模态对齐中的标签噪声。这个方向来自一次实际的数据清洗经历：网上抓下来的图像文本配对里有大量噪声，硬学会学坏。我们发现对比学习目标下，一部分噪声样本其实可以被安全忽略，关键在于先判断哪些样本不可靠。这个选题的过程最接近一个经验教训：把一个具体的数据问题抽象成方法论问题，成功率反而比直接做应用更高。

2.5 动手前的判断清单：四篇论文都过了一遍这个模板

筛选项目时，我们用下面这个清单过了一遍又一遍：

这张表看起来简单，但它等于把很多“肠子悔青”的选题失败提前消灭了。四篇论文最后能走完整个流程，和选题阶段没有埋下“说不清为什么”的病根有很大关系。

3. 真正决定命运的，往往是实验设计和写作表达

很多人以为顶会中稿的核心是数学创新，但回顾四篇论文，我们投入最多的其实是实验设计和写作。审稿人面对一份陌生稿子时，第一步判断就是“结果可信度”。实验部分如果做不到“结论和证据一一对应”，后面的理论写得再好也会被拉低评分。

3.1 实验不是跑分，而是向审稿人证明“因果关系”

我们内部有个硬性要求：每个核心结论至少要有一张主表和一条消融证据链。主表告诉读者“方法比基线好”，消融告诉读者“知道好在哪里”。一句话：实验不是跑分，而是向审稿人证明因果关系。

公平性方面也有具体操作：所有baseline尽量采用它们原论文默认设置，训练步数、batch size、优化器配置保持一致；如果为了统一条件修改了什么，必须在实验说明或附录里写清。审稿人最怕的就是baseline比原论文低一截，那会让你的主表失去解释力。我们在四篇论文中都采用同一个标准：先复现到接近原论文分数，再谈改进。这个工作很枯燥，但几乎是投这类会议的底线。

3.2 写作顺序建议：从摘要到导言，Related Work最后写

写作顺序我们也固定下来了。先写实验部分，但不是从引言开始。首先把实验表头、数据集、评价指标列清楚，让整篇论文的“证据地图”先成形。接着写摘要和引言。摘要基本按四句话结构：问题一句话，现状不足一句话，方法两到三句话，结果给出具体数字。引言则更像一条故事线：问题为什么重要、现有方法为什么不够、我们怎么做、结果如何验证。

Related Work一定要避免写成文献列表。我们要求每个相关工作和本工作的区别必须落到一句话，放在同一条上下文里比较。写完初稿后会请没参与该方向的同学读一遍，只问一个问题：这篇论文想解决什么。如果他三分钟内说不出来，说明引言还要继续改。这个办法比任何润色工具都有效。

3.3 可复现性与实验细节：最容易被低估的隐性得分点

可复现性是把“看起来还行”变成“可以相信”的关键。我们的做法是：环境依赖锁定版本，随机种子至少跑5次并报告均值与波动范围，所有训练超参写进附录，代码仓库在投稿前就整理好。做这些事不需要很高深的技术，但很容易被低估。审稿人没有义务帮你判断结果，一旦他发现某个关键设置没有写清楚，很难不怀疑其他实验。实际上，四篇论文都有一稿因为细节说明不完整被打过低分，后来我们把可复现性当成论文正文的一部分来对待，问题才消失。

4. Rebuttal不是写小作文，是对审稿人的一种“证据管理”

4.1 拿到意见后的第一反应：用表格把所有问题钉死

拿到ICLR评审意见后，第一件事不是急着回怼，而是把所有意见放进一张表。我会按类型分四类：理解偏差、方法质疑、实验补充需求、写作与表达问题。分类要具体，比如“为什么不用某方法对比”属于实验补充需求，但不能简单归为方法质疑。分类完成后，评估每类意见对最终评分的影响权重，把最重要的几条放在回复最前面。这是一次典型的项目管理，和学术水平相关，但和组织能力更相关。

4.2 逐条回应的证据链：每句话都要能指向论文里的某个具体角落

逐条回应的核心原则是：每句话都要能指向论文里的某个具体角落。不要只说“我们已经实验验证”，要给出表X、图Y、附录Z。如果审稿人问的是某个baseline，我们通常会补上一栏对比数字，即使这个数字来自已有实验。回复的结构建议是：先感谢，再复述对方问题确认理解一致，然后给出回答，最后说明这个回答在论文里的位置。ICLR的作者回复窗口很短，所以措辞尽量精简，长句容易让审稿人失去耐心。

比如审稿人问：“为什么不和某方法比较？”我们当时的处理方式是先承认对方说得有道理，接着说明我们看过该方法的设定与我们的问题不同，最后贴上一张在相同设置下跑出的对比表。虽然结果不一定是我们赢，但完整性会让审稿人觉得你认真对待了意见。

4.3 回复中的三类绝对不可做的事

三类话绝对不要出现在Rebuttal里。第一类是攻击性表达，比如“你显然没有认真读”“这很常识”，它们不会带来任何帮助。第二类是空洞承诺：“我们会在终稿补充大量实验”——如果回复窗口内补不完，终稿也没有机会，这句话只会伤害可信度。第三类是只贴代码不解释，审稿人没有时间翻代码仓库，你必须把关键结果直接放在回复里。实话讲，这些错误我们几乎每届都会看到，它们会让原本可以翻盘的稿子失去机会。

5. 踩坑实录：三个差点让我们前功尽弃的小问题

5.1 坑一：某个baseline的分数一直偏低，根因竟是环境配置

先说一个最典型的坑：某个baseline在我们环境里跑出来的分数一直比原论文低3个百分点。最开始我们没当回事，主表里直接拿这个偏低的数字做对比。后来在投稿前补写Implementation Details时，一个同学发现是数据预处理顺序不一样，另外一个项目的环境里用到的依赖库版本也偏旧。两处修正后，分数回到原论文水平。虽然我们没有刻意造假，但这个“偏低”会让主表呈现一种并不公平的比较，一旦被审稿人抓住，整篇论文的可信度都会受损。从那以后，我们给所有外部baseline定了规矩：先按原论文默认配置复现，再动任何一行代码，环境依赖全部锁进依赖清单里。这一步枯燥，但值得。

5.2 坑二：可视化只挑了漂亮样本，结果是给审稿人送分题

第二个坑和可视化有关。论文里有一组例子展示方法生成的效果，我们当时挑了效果最好的几个样本，图片确实漂亮，审稿人却一针见血地指出：这组样本在各类别里的分布并不均匀，看起来不像随机抽样。这个意见其实等于把“你有选择偏差”写在了桌面上。我们只能重新补了一组全量统计，用各类别比例和指标中位数说明整体效果，并把选择标准写进附录。这个坑的教训是：可视化的目的是验证，不是装饰。凡是展示，就要敢于用随机样本，或者严格说明选择规则。

5.3 坑三：训练超参数散落在代码里，正文却只写了主干

第三次出现在训练超参数的说明上。论文主表里的模型用了warmup、梯度裁剪和一个调度策略，但正文的Implementation Details只写了学习率和batch size。审稿人怀疑这些额外设置是专门为我们的方法调的，甚至追问baseline是否也用了同样的训练细节。我们把完整超参数表上传到代码仓库，并在附录中标注每一组设置来自哪一轮实验。最终审稿人接受了。这件事说明：训练配置本身就是实验结果的一部分，不写等于告诉别人“这里可能藏着后门”。以后再投，我们会在初稿阶段就把训练配置表当正文一样对待。

5.4 这些坑的共同本质：可验证性比结果好看更重要

这三个坑放到一起看，本质都是同一个问题：论文的每个结论都必须经得起验证。审稿人不会追着每行代码去读，但一旦发现某一处细节不可解释，整篇论文都会被打上问号。我们复盘时经常说，中稿不是赢在算法创新多惊艳，而是赢在让审稿人挑不出低级毛病。可验证性比短期结果好看重要得多，这个排序应当刻在每一个投稿人的脑子里。

6. 录用之后的五日清单：让下一次投稿少走弯路

6.1 论文公开后，第一周就要做完的四件事

录用通知不是终点，只是责任升级的开始。我们的经验是拿到通知后五天内完成四件事：第一，对照Rebuttal里给审稿人的承诺，逐条检查最终版论文有没有真正做到；第二，把训练配置、复现命令和环境安装说明归一版，别让开源仓库处于“能看不能跑”的状态；第三，把Rebuttal中补充的有价值的实验整理进附录，而不是让它只存在对话里；第四，组织一次内部报告，把这个项目的立题、被质疑过程、实验取舍完整讲一遍。这么做看起来慢，实际上是把一次投稿的经验变成团队通用的资产。

6.2 一份可以直接抄的投稿Checklist

接下来是一份我们内部用了两届的投稿Checklist，你可以直接抄走：

6.3 团队经验沉淀：我自己的数据记录方式

最后说一个我个人很喜欢的小习惯：为每篇论文建一行记录，放在同一个页签里。内容包括论文ID、目标会议、初版选题、最关键的三条评审意见、最终怎么回应的、以及投稿后遗留的问题。下一次选方向时，翻一下这些记录，比重新开一次讨论会高效得多。对方向分散的实验室来说，这几乎是靠录像带传承经验。

四篇论文被ICLR 2026录用当然值得高兴，但我最想留下的，不是那张录用名单，而是这套已经跑通两轮的方法。它才是下一批论文能被录用的真正原因。