IROS24被拒复盘：机器人顶会论文写作与审稿反馈指南

刷到IROS24录用邮件那天，我盯着屏幕愣了几秒才点开——标题栏那句"Accept"没有出现，取而代之的是"Reject"和三位审稿人密密麻麻的意见。说不难受是假的，毕竟这篇工作从选题到收尾折腾了大半年。但把三条意见从头到尾读了两遍之后，我反而冷静下来：这三位审稿人其实帮我指出了一直没敢正视的几个硬伤。这篇总结不打算写什么成功学鸡汤，就想把IROS24这个会从投稿到出结果的完整链路掰开讲清楚——它是什么定位、投稿卡哪些点、我当时踩了哪些坑、如果重来一次我会怎么改。不管你是第一次冲机器人领域顶会的新手，还是已经投过几轮ICRA/IROS的老手，希望这些经验能让你少走点弯路。

1. IROS24这个会到底什么定位，值不值得花半年去搏

先把最基础的问题讲明白，很多刚进课题组的朋友其实并不清楚IROS在整个机器人学术界的位置。它不是那种"投着练手"的水会，也不是拒了就说明工作不行，它处在一个很微妙也很关键的位置上——理解这个位置，你才知道该拿什么心态去准备下一篇。

1.1 和ICRA的关系，以及它真实的投稿门槛

IROS全称是IEEE/RSJ International Conference on Intelligent Robots and Systems，和ICRA并称机器人领域的两大旗舰会议。这两个会的关系有点像双胞胎：都归IEEE RAS体系，都是每年一次，都以收录完整研究论文为主。圈子里流传一个说法叫"ICRA难一点、IROS稍友好一点"，我个人实测下来觉得这个说法只对了一半。确实，同一篇工作投ICRA被拒、改投IROS中了的例子不少，但这不等于IROS好过——2024这一届收到的投稿量据我了解依然是个很夸张的数字，而会场录用的比例摆在那，绝大多数还是被刷掉了。

真正的区别在于评审口味。ICRA更看重新颖性和理论完备度，有时候一个想法够新、哪怕实验稍微单薄一点也有机会；IROS相对更看重系统完整度和实打实能跑通的东西，一个工程性很强、真机演示扎实但没有特别炫的理论框架的工作，投IROS往往比投ICRA更容易得到正面评价。我这次的稿子恰好卡在中间：方法有新意但不够颠覆，实验做得比较全但缺少一个"杀手级"的应用场景。事后复盘，这种"两头都不靠"的定位其实是最危险的。

注意：别把"ICRA被拒就改投IROS"当成默认策略。如果审稿意见指向的是实验不充分、baseline缺失这类硬伤，直接原封不动转投等于再交一次学费。改投之前一定要先补掉上一轮的核心问题，否则同一个坑会再踩一次。

1.2 2024这一届的关键时间线和投稿规则

时间管理是投稿的一半。我见过太多人因为记错了deadline，最后一晚疯狂的赶工，结果图表都没来得及对齐就提交了。下面这张表是我根据这一届的实际情况整理的，节点记清楚，倒排计划才有依据。

几个容易翻车的规则细节，我特意单独拎出来：

• 时区以PST为准。提交系统显示的都是太平洋时间，北京时间换算过去要往前推一天多，很多人最后一晚按北京时间提交，结果系统已经关了。我这次是提前48小时上传的初版，留出缓冲。
• 双盲评审。正文里绝对不能出现作者名、单位、致谢、基金编号，甚至连自引的措辞都要改成第三人称。这一条我后面还会细说。
• 页数硬卡。正文和参考文献有明确的页数上限，超出的部分要么删、要么交超页费。审稿人看到排版溢出直接扣印象分。

实操心得：把deadline定成官方截止前一周。这七天不是用来拖的，是用来做"冷却检查"的——晾几天再读自己的稿子，很多当初看不出来的语病和逻辑断层会自己冒出来。

2. 投稿前的选题和准备：工作量评估决定了成败

很多人以为投稿是从写论文那一刻开始的，其实真正的胜负手在你决定做这个课题的时候就埋下了。选题太大做不完，太小不够格，这个度特别难拿捏。这一节我想聊聊怎么判断一个工作"够不够IROS的线"，以及时间该怎么倒排。

2.1 什么样的工作能过这条线

我总结了一个粗糙但好用的自检清单，投稿前拿它过一遍，心里基本就有数了：

1. 有没有一个明确的、能被一句话说清的问题。如果你的摘要第一句自己是绕的，审稿人一定也是绕的。
2. 和已有工作比，增量在哪。是方法新、场景新，还是性能显著更好？三者至少要占一个，占两个更稳。
3. 实验有没有说服力。至少要有仿真验证，能上真机更好。IROS审稿人对"只有仿真"是相对宽容的，但仿真场景必须足够贴近真实。
4. 能不能复现。参数、网络结构、训练细节写清楚，审稿人很在意这一点。

第三点我特别有感触。我这次的实验是一部分仿真加一部分真机，真机部分当时做得比较仓促，只跑了两组场景。审稿人2直接指出"真机实验的场景覆盖不足，无法支撑所声称的泛化能力"。这句话戳中的正是我选题时就偷的懒——我当时想的是"有真机就行"，没深想真机到底要验什么。

2.2 时间倒排：从截止日往回推半年

假设你打算冲明年这一轮，我建议的时间分配大致是这样，以6个月周期为例：

• 第1到2个月：打磨想法，做最小可行性验证。这一阶段的目标是确认"这事能成"，哪怕性能很差。
• 第3到4个月：跑主实验，补baseline，边跑边写初稿。千万别等实验全跑完再动笔，你会写到怀疑人生。
• 第5个月：完成全部实验，论文迭代到能看的状态，找师兄师姐内审。
• 第6个月：打磨语言、统一图表风格、排版、双盲自查，然后提交。

我这次最大的失误是把真机实验压到了第5个月的后半段，结果实验出来的结果和仿真有一些不一致的地方，我花了很多时间去解释这个gap，压缩了写作和打磨的时间。如果重来，我会把真机实验提前到和第3、4个月的主实验并行推进。

提示：写作不是最后一步，而是贯穿全程的。我习惯每做完一组实验就立刻更新对应的论文小节，这样到收尾时，论文其实已经成型了七成，剩下的只是润色。

3. 论文写作：审稿人真正会盯的那些细节

写学术论文和写技术博客是两回事。博文可以铺垫、可以抖机灵，论文必须每一段都服务于"让审稿人相信我的贡献"。这一节我想拆开讲讲结构和图表这两个最容易被低估的环节。

3.1 结构要讲一个完整的故事

IROS用的是标准的IEEE会议模板，常规结构就是Abstract、Introduction、Related Work、Method、Experiment、Conclusion。模板是固定的，但怎么填内容差别巨大。我的经验是，整篇论文要有清晰的"故事线"，从头到尾回答三个问题：这个问题为什么重要、别人怎么做的、我凭什么做得更好。

Introduction尤其关键，很多审稿人时间有限，会先看摘要和引言，如果这两部分没让他提起兴趣，后面的方法写得再好也可能被草草略过。我这次引言的前两段写得还行，但第三段"贡献列表"写得太平，三条贡献都是"我们提出了……我们设计了……我们验证了……"这种句式，读起来没有冲击力。审稿人3的意见里提到了"贡献表述较为笼统"，现在回头看，确实是这个问题。

方法部分我踩的坑是符号定义混乱。同一个变量在公式和正文里出现了两种写法，自己校对时没发现，审稿人一眼就抓出来了。后来我总结出一个笨办法但很管用：所有符号列一张表，逐个核对出现位置，确保定义唯一、前后一致。

3.2 图表决定了稿子的第一观感

说个扎心的现实：审稿人打开你的PDF，第一眼扫的往往不是文字，是图。图的清晰度、配色、信息密度，直接决定了他是"认真读"还是"大概翻翻"。我这次的架构图自我感觉画得挺漂亮，但审稿人1的意见是"总体框架图信息量太大，看图比看正文还累"。这句话让我反思了很久——图的目的是降低理解成本，不是炫技。

我的教训整理成几条：

• 一张图只讲一件事。架构图讲流程，对比图讲性能，别在一张图里塞三个信息层次。
• 配色控制在三到四种。彩虹色系看起来很热闹，实际打印出来或者审稿人屏幕偏色时会一塌糊涂。
• 坐标轴、图例、单位缺一不可。我见过太多图因为没标单位被审稿人质疑严谨性。
• 表格优先于曲线的地方要用表格。如果是离散的几个方法对比，表格比折线图更清楚。

实操心得：把论文的图单独截出来，发给同组不熟悉这个工作的人看，让他说出这张图在讲什么。如果他说不出来或者说的和你想的不一样，图就得改。这个"外行测试"我用了很多次，屡试不爽。

4. 格式规范与投稿系统实操：这些坑不该踩

内容之外，格式和系统操作是最容易让人翻车的地方，因为它们无聊、琐碎，但一旦出错就是致命的。我这次在双盲自查上就差点出问题。

4.1 模板、页数和双盲自查

IROS用IEEE的会议模板，具体命令是固定的：

\documentclass[conference]{IEEEtran} \IEEEoverridecommandlockouts

页数控制是个技术活。正文有上限，参考文献另算。我的建议是写完初稿后先编译看看页数，如果超了，优先删冗余的介绍和重复的实验描述，实在删不下再考虑把部分细节挪到补充材料里。压缩版面时有个顺序技巧：先砍形容词和过渡句，再砍次要实验，最后才动核心公式和主图。

双盲自查我列了一个清单，每次投稿前都会逐条过：

• 正文、图注、表注里有没有出现作者姓名和单位。
• 致谢和基金编号是否全部删除。
• 自引是否改成了第三人称表述（不要写"our previous work"，写"某某等人提出的方法"）。
• 上传的补充材料、代码链接里有没有暴露身份的信息（比如GitHub主页上的真实姓名）。
• PDF的元数据里有没有残留作者信息。

最后一条特别容易漏。很多人以为删了正文里的名字就完了，其实PDF文件的属性里可能还带着作者信息。我这次是用了个小脚本把元数据清掉才上传的。

4.2 投稿时的材料清单

提交系统里要传的东西比想象中多，临时凑容易出错。我习惯提前一天把所有材料准备好放一个文件夹：

主题分类这一项千万不能随便选。选对了，分到的审稿人是懂你方向的，评价会更中肯；选错了，分到一个不对口的审稿人，可能整篇稿子都被误读。我这次选的是偏感知的方向，但我的工作其实更偏控制，结果审稿人2明显对控制部分的理解不够深入，给了一条略显外行的意见。

5. Author Feedback阶段：怎么把劣势扳回来

初审意见出来后，会有大约一两周的作者反馈期。这是唯一一次和审稿人"对话"的机会，写好了能救命，写砸了也能把本来有希望的稿子送走。我这次虽然最终没中，但反馈阶段确实让一个原本要打低分的审稿人态度有所缓和，这个过程值得详细说说。

5.1 先把审稿意见分类，别急着反驳

拿到意见的第一反应通常是委屈，尤其是看到一些明显没读懂你论文的评论时。但先冷静，把所有意见分类：

• 误解类：审稿人理解错了你的意思。这类要礼貌澄清，指出原文具体位置。
• 硬伤类：确实是你的问题，比如实验不足、baseline缺失。这类要坦承，并说明补充了什么。
• 口味类：审稿人觉得你的方法不够优雅这类主观评价。这类最难办，能回应就回应，回应不了就礼貌接受。

我这次收到三条意见，审稿人1主要吐槽框架图和表达，属于口味加部分硬伤；审稿人2质疑真机实验的覆盖面，是实打实的硬伤；审稿人3觉得贡献表述笼统，属于表达问题。分类清楚之后，我就能有针对性地写反馈，而不是一股脑地辩解。

5.2 反馈写作的几个原则

反馈不是自由发挥的战场，是有格式和字数限制的。写的时候我遵循了几条原则：

1. 逐条回应，编号对应。审稿人提了五点，你就回五点，一一对应，别混在一起。
2. 先感谢，再回应，最后给证据。哪怕意见很尖锐，开头也要礼貌。
3. 能用数据就用数据。审稿人质疑泛化能力，我就补了一组新场景的实验数据贴进去。
4. 承认问题要具体。别写"我们承认实验有不足"，要写"我们承认在X场景下缺少验证，为此补充了Y实验，结果见表Z"。
5. 控制篇幅。反馈有字数限制，啰嗦等于浪费机会，把最有力的证据放前面。

我这次给审稿人2的反馈里，补了两组真机新场景的数据，并明确标注了这是反馈期内补充的实验。虽然最终还是没能改变审稿人的整体判断，但那位审稿人在后续的讨论里语气明显缓和了，从"无法支撑"改成了"补充实验有所助益"。这让我相信反馈是有意义的。

注意：反馈期非常短，通常只有一周左右。所以收到意见的第一天就要开始写，别拖。补充实验如果要现跑，更要提前预留时间，很多时候根本来不及，那就得用已有的数据换角度说明。

6. 高频拒稿原因和我踩过的那些坑

被拒之后我做了个复盘，把审稿意见、自己反思的、还有和同组投过IROS的人交流得到的经验汇总了一下。这一节全是负面清单，可能不好看，但我觉得比任何成功经验都值钱。

6.1 常见拒稿理由速查

我这次命中了两条：真机实验覆盖面不够、贡献表述笼统。这两条其实都属于"准备时偷懒、收尾时还债"的类型，完全可以在投稿前避免。

6.2 被拒之后，我是怎么调整的

刚收到结果那几天确实有点低落，但我强迫自己做了三件事，事后证明很有用。

第一件，把审稿意见翻译成可执行的修改清单。不要停留在"审稿人说实验不足"这种模糊层面，要具体到"补哪一组实验、用什么数据、多久能跑完"。我列了七条，其中五条是必须在下一轮投稿前完成的。

第二件，冷静评估这篇工作值不值得改。有些工作被拒是因为方向不对，硬改不如换题。我这次的判断是：方法本身没问题，问题出在实验和表达，属于可救的范围，所以决定改。

第三件，找不同的人读。我把稿子发给了组里不做这个方向的师兄，让他只看引言和方法，然后告诉我"这篇在做什么"。他卡壳的地方，就是我表达有问题的地方。

实操心得：被拒之后别急着立刻改投下一个会。同样的稿子换个会投，大概率还是同样的结局，因为问题没解决。我给自己定了规矩：至少要完成上一轮意见里超过八成的问题整改，才允许投出去。

改投的时间规划也要重新做。如果决定投下一届ICRA，那时间大概是半年后，节奏和IROS是错开的，正好可以利用这个间隔把工作做扎实。我现在的状态就是一边补实验一边等下一次窗口，心里反而比第一次投稿时踏实多了。

我个人在实际操作中的体会是，投稿这件事，运气的成分有，但远没有想象中那么大。IROS24这一轮走下来，我最大的收获不是那封邮件，而是终于弄明白了自己的工作在哪个环节上还不够硬。审稿人的每一句吐槽背后，其实都对应着一个可以在下一次避免的具体动作。把这些动作清单化、执行掉，下一篇投出去的时候，你心里是有底的，而不是靠祈祷。