[TOC]
↗ Learning English the Right Way ↗ English Grammar
↗ GRE Writing ↗ TOEFL (Test of English as a Foreign Language) ↗ IELTS (International English Language Testing System)
https://youtu.be/WP-FkUaOcOM?si=ftUX98NKWnXoSzNp How to Write a Great Research Paper
https://blogs.library.columbia.edu/journalism/2014/02/writing-resources/ Writing Resources for Master’s Projects | Columbia University Libraries
We also welcome systematization of knowledge (SoK) papers. These papers will not be judged on novel research contributions, but on their value to the research community. SoK papers should provide an important new viewpoint on an established, major research area; support or challenge long-held beliefs in such an area with compelling evidence; or present a convincing, comprehensive new taxonomy of such an area. Survey papers without such insights are not appropriate for acceptance.
🏠 https://oaklandsok.github.io/
几年间我主笔或大改了20篇左右的顶会论文，一开始是在清华的实验室里苦思冥想，被拒了好几次才有点长进，基本不会因为写作被秒拒了；后来实习和工作时，在帮实习生和学弟改文章的过程中也发现了一些常见问题。我想总结一些给顶会论文写作新手的建议。如果能帮助同学们少走弯路的话，我将不胜荣幸。
这几条建议将分成上下两篇，每篇聚焦于如何避免收到一条致命的“恶评”，分别是：
- （上）This paper is hard to follow（宏观层面，谋篇布局，优化论文结构，卖出核心贡献）
- （下）The readability can be greatly improved（微观层面，精耕细作，少犯常见的小错误）
本篇先从“hard to follow”开始。缺乏经验的同学收到这样的恶评外加一个strong reject之后可能会感到迷惑和委屈，所以本文首先从审稿人的角度来分析他们为什么会对你的文章作出这样的评价，然后通过两个例子给出相应的写作建议。
审稿人视角
这个评价可能表示论文的宏观组织形式和内容分布与审稿人所期望的有较大的差距，所以他在耐心耗尽前没能搞懂你做了什么。对同一篇文章，审稿人想的跟作者想的到底差在哪呢？
一位同学可能会对自己刚完成的论文很满意，因为：
- A. 在对一个重要问题的研究过程中，我遇到了几个复杂的子问题，我一环扣一环地解决了这几个问题，最终得到了一个巧妙的解决方案。我记录了这个精彩的过程，审稿人应当为这一方案的系统性和自洽性折服。
- B. 我讨论的问题有点难以理解，但只要脑子里转过那个弯儿来，经过一系列挑战性十足的思想游戏，就可以把这个问题转化为另一个简单的问题，那么解决方案就自然呼之欲出了。我用两页纸的篇幅进行了这一思辨，逐步推出了最终的结论，审稿人肯定会受到灵魂的启迪。
- C. 我在别人的工作上加入了本质的创新，变成了全新的东西，最终的效果很好，如假包换的SOTA。审稿人只要能看懂实验结果，就应该给我accept。
那审稿人是怎么看的呢？
审稿人根本就不在乎。
审稿人点开了你的文章，边看边想：
- A. 他到底要解决什么问题？怎么一个问题又一个问题？到底哪个是他要解决的？哪个方法是common practice，哪个是他提出来的？
- B. 这两页纸在写什么东西？前面没总起，后面没总结，中间又是假设又是推论的在干什么？这个结论是怎么回事，这不是很显然的吗？磨叽了两页纸，就这？
- C. 哦，这个懂了，yet another AAA + BBB，我跳过中间四页直接看看效果吧。这张表里面的这个指标是啥意思，就比别人高了0.2，这个差别很大吗？
审稿人期望的是什么呢？
- 审稿人想要的是迅速搞明白你提出了什么新东西，而不是听你娓娓道来、抽丝剥茧，跟着你一起由浅入深地感受那四方求索、最终豁然开朗的成就感。写论文的目的在于向读者介绍工作的最终形态，而不是记录研究过程。有的同学会在文章里描述自己从最初的idea艰难跋涉直到最终结果的心路历程，这多半是没用的。
- 审稿人不会逐字逐句地看论文，他希望他直接跳到任何一页上之后都能在所有人都习惯的地方迅速找到他想要看到的内容。所以，如果你的论文组织形式不太常规，审稿人可能根本就懒得看。
- 很多人是为了学到新东西才来审稿的。如果你把一些反直觉、有趣或很实用的结论摆在显眼的地方给他看，他可能会感到有收获。但不要期望每个审稿人都愿意从你的大段文字和意义不明的图表中自己经过思考得到这些结论。
例子1：不要完整还原研究的心路历程
我为了解决一个重要的已知问题（问题甲）提出了方案A（跟其他人的方法相比变化很大），发现方案A不够好，研究一下为什么方案A不够好呢，发现这是因为方案A引入了另一个问题（问题乙）；我研究了一下如何解决问题乙，最终提出了改进版方案B（在A的基础上改动很小，加一个trick），所有问题都解决了。而且这个trick用在其他方法中也有提升。我提出了两个方案，还发现了一个别人没发现的问题，我觉得这篇文章很稳。
但审稿人是以不同的视角来看这篇文章的，他并没有亲身经历我的研究过程，不可能像我一样清楚重点在哪里。他可能会问：
- 如何证明方案A不好使的本质原因是问题乙？
- 方案A也有一定效果，如何证明这是因为解决了问题甲？
- 方案B相对于方案A只有很小的差别，怎么就这么点novelty？
- 你说B的改进用在其他方法上也有提升，那我为什么还需要A？A不也没比其他方法好到哪去吗？
我觉得很冤：这篇文章的最终结果明明是方案B，B是A的巧妙升级版，差别当然很小了，但是A也是我提出的呀！还有，为什么要纠结A和问题甲的关系，这很重要吗？
如果审稿人能听到我的抱怨，他会说：
- 你全篇都在鼓吹方案B，你没有强调A，我怎么知道它也是这篇文章主要内容的一部分？
- 就算A是你提出的，它也没有解决你强调的问题乙啊，难道它也算主要贡献？
- 既然A不算主要贡献，那你所强调的B可不就是只有很小的改动吗？
辩经是没有意义的，我们只能在写作时注意避免引发这种无意义的争论。如果我们稍微改变一下写作的方式，审稿人就更容易看懂了：
- 我提出了一个全新的方法来解决一个重要问题。
- 这个全新的方法包括一个全新的框架和一个通用的trick。
- 分别证明二者的有效性：用这一框架而不用这个trick会导致效果相对变差；这是因为另一个有趣的问题（做一些分析）；这个trick用在其他方法里，也可以有一定的提升；二者结合，效果才是最好的。
为什么审稿人喜欢这样的组织形式呢？因为他一眼就看出你提出了什么东西，以及它们各自有什么作用。他只需要判断你提出的东西技术上是否正确和效果是否显著就可以了。
例子2：不要轻言“based on”和“A+B” “提出了基于AAA和BBB的XXX”是本科毕业论文里常用的说法，适用于需要稳妥安全而不怎么需要创新性的场合。在顶会论文里这么写，可能会把本来还不错的创新性给写没了。在大多数情况下，不要轻言自己的工作“based on”，你完全可以说自己注意到了某个重要问题，琢磨明白了背后的原理，想到了一个解决方案，提出的是一种新的东西，这种东西自然地用到了AAA和BBB，而不是简单地改了改人家的成果。
设想一下，把ResNet的写作改成“based on”和“A+B”的形式，是不是就把创新性写没了？
《ResNet: Yet Another Simplified GoogLeNet》 ：我们基于GoogLeNet和VGGNet设计了一种大量用3x3卷积（借鉴VGGNet）和并行shortcut（简化自GoogleNet）的模型，超越了GoogLeNet和VGGNet。为什么效果这么好呢？因为VGGNet和GoogLeNet珠玉在前，Batch Norm也很好用。反正这个工作就是这么简单，我们没有想到理论上有什么创新性，但我们给后续的工作搭建了一个好的baseline。
这样的文章能让读者学到多少东西呢？
ResNet实际上是怎么写的呢？
- 各位想必都知道当今有个重要的问题：模型越深，居然会越掉点。
- 我们提出的解决方法惊人地简单：将模型中的映射形式从y=f(x)改成y=f(x)+x，也就是所提出的“残差学习”，就能解决这个问题。这是因为模型容易拟合f(x)=0，不容易学出f(x)=x。
- 残差学习非常容易实现，效果非常好。
提出问题——抽象出背后的原理——提出自己的解决方案和具体的实现——实验验证，这才是更符合人类认知规律的论文写法。
有的同学觉得，一篇贡献没那么大的论文硬要写成这样是在“讲故事”，但只要实事求是，只要实验证据能够支撑你的故事，这样的故事既有利于审稿人给你打出高分，也有利于读者学到新知识，更有利于你的观点的传播，属于是赢麻了。
总结和其他建议
- 上面说的第一件事其实也跟ResNet有关：真实历史上的ResNet来自于对GoogLeNet的拆解研究，并不是突然发现了“残差学习”的原理才有了ResNet，而是孙剑老师带领的团队先通过拆解GoogLeNet发现shortcut结构好用后思考出来的解释。我们上面设想的“丐版”写法虽然是反映了真实的研究过程的，却并不利于背后原理的深挖和核心思想的传播。这个实例正好能够支持本文的观点：研究怎么做和论文怎么写，是两码事。
- 论文是传播知识的工具，是方便别人省时省力地学到新东西的标准化交流方式，不是个人展示个性的舞台。审稿人（读者）习惯于看什么样的论文，我们就写什么样的论文。这本质上跟流行歌曲和通俗小说是一样的，费尽心机来迎合受众而已，不寒碜。
- 没必要在文章结构上寻求创新。大多数文章都可以写成Introduction + Related Work + Method + Experiment + Conclusion的形式。如果你提出的不是单一创新点而是一揽子小改动的组合，可以学习ShuffleNet v2是怎样写的。
- Be explicit. 你不强调的东西，不要指望别人自己悟出来。
- 要在一个地方集中地完整描述你提出的东西，不要散落得到处都是。不要假设一个读者会有耐心看完50%的篇幅才理解你做了什么。
欢迎关注下篇。
（转载请注明出处）
在《顶会论文写作建议（上）：宏观布局，避免“hard to follow”》中，我们讨论了如何在宏观层面设计论文的结构，以大多数人乐于接受的方式卖出自己的核心贡献。
在本篇中，我们将会聚焦于语言组织的层面，通过十几个我近几年从清华的学弟或实习生同学的论文中收集到的例子，讨论如何提高文章可读性，让读者能心平气和、行云流水地读完，让审稿人能更客观且无痛地评判文章的价值。
需要注意的是，我们讨论的前提是假设论文至少在语法层面是正确的，不再讨论那些可以用Grammarly或ChatGPT自动解决的基础问题。
正如上篇所说，大部分论文都可以写成提出问题——抽象出背后的原理——解决问题的格式（俗称讲故事）。本篇的宏观结构也将遵循这一套路，从而作为对上篇所述宏观写作原则的一次具体实践。
假设本文真的是一篇论文，那么在省略了一大堆关于写作如何重要、写作如何成为了一个重要的研究领域、引用了一大堆关于写作的重要prior work（作者自己也不一定看过，但是看到别人都在引所以就引了）的铺垫语句之后（这些气氛句子本来也没人会看，所以我就不写了），我们的故事现在开始。
本文提出用以下概念来度量文章的可读性：逻辑强度、防御弹性、迷惑时间、信息密度。在此之上，本文提出一些实用的建议和技巧来提高文章的可读性。
逻辑强度
在任何语言的学术写作中，逻辑的连贯都远比用词的华丽更重要。上篇已经介绍了一些宏观逻辑设计上的技巧。在微观层面需要注意的是，逻辑的连贯在于逻辑本身，而不在于衔接词（to this end, in contrast, specifically等等）。
换句话说，我们应该把衔接词当成使语言更加流畅的点缀，而不是通过衔接词来为本没有逻辑的句子强行构造逻辑。例如从总括到具体描述时，用“Specifically, …”；前后两句存在对比关系时，用“In contrast, …”。
而不是反过来！并不是我们写下“In contrast”，前后两句就真的因此而有了对比关系。衔接词与真实逻辑的不匹配会让人疑惑，显著降低文章的可读性。
我们的高中英语写作将衔接词的存在视作逻辑本身，甚至当成作文中的加分项。实际上，用一大堆衔接词不一定能提高文章的流畅程度，反而可能有负面作用。
我们写下每一个衔接词之后都要三省吾身：它前后两句的逻辑关系真实存在吗？它自身放在这个语境下正确吗？不用它行不行？
例1：衔接词必须自身正确，经得起推敲。
We argue that problem A is critical. To this end, we propose method B.
作者写下这句的时候想的可能只是挑个词来通过problem A引出method B，逻辑是显然的，但写出来的句子却是经不起推敲的："this end"中的this指的是哪个end？上文说了一个“end“（要做什么/要实现什么目的）吗？上文实际上只是提出了一个观点，并没有说要做什么，所以这个衔接词自身的存在就是错误的。
例2：衔接词不能强加逻辑关系。
The system comprises three modules. First of all, Module A is .... Second, Module B is .... Last but not least, Module C is ....
作者的本意是描述三个并列的事物，这几个衔接词却给这三个本来没有次序关系的东西强加了一定的次序。这时候就不如去掉这些词，分别介绍三个事物即可，根本不用加任何衔接，语言依然流畅：The system comprises three modules. Module A... Module B... Module C..
例3：衔接词要准确反应真实逻辑关系。
The baseline model is … On top of that, model A employs an extra attention module. In contrast, we propose a novel objective function.
这句话让人迷惑：我们的模型除了这个novel objective function以外是否也用了这个extra attention module呢？读者在寻找“In contrast”对比的对象的时候可以有两种理解。
读者可以理解成model A和我们的模型是用两种方式来解决同一问题，model A用了这一结构而没用这一目标函数，我们是用了这一目标函数而没用这一结构。读者也可以理解成我们试图拿model A和我们自己的方法对比以凸显这个目标函数的效果，所以我们的模型等于model A + 这个新提出的目标函数。
如何修改呢？如果一定要对比的话（比如你的那位不怎么懂但是confidence分数拉满的审稿人一定要让你对比），应该在结构和loss两方面分别讨论从而形成对比，消除歧义，顺便突出我们的优势：
From a structural perspective, model A introduces an extra attention module while we use the same model structure as the baseline. In terms of the objective function, method A adopts the vanilla XXX loss, which suffers from …, while we …
这也就是我们所说的，先有逻辑（“我们要从两个方面进行对比！”）后有衔接词（当然不用也行），而不是用衔接词构造逻辑（简单塞进去一个In contrast并期望对比关系就因此而产生）。
防御弹性
在写作的时候，我们每写完一句话都要考虑审稿人可能从哪个角度攻击这句话。“防御弹性”指的是我们的语言引起审稿人的质疑的频率和面对审稿人的挑剔时的抵抗能力。
正如写代码时要有“防御式编程”的概念，写作时也要有“防御式写作”的意识，随时考虑笔下的语句是不是无懈可击的。
例4：言出有据。
当我们说“Problem A是本领域的关键问题且尚未得到解决”，这时就要考虑到审稿人可能会问：“为什么说这是关键问题？它造成的后果有多严重？这种后果对最终性能影响大吗？”这就需要我们完善引用：
It is reported that problem A results in ... [1,2,3] and ... [4,5], which are critical to ... because ... [6, 7, 8].
丰富且适当的引用会让人觉得作者学识渊博，对本领域理解深刻（哪怕你只看过那些文章的摘要，只是在制造这样的幻象也行）。
例5：轻重适当。
在展示了实验结果之后，我们往往需要解释为什么我们的方法会work。不解释一般是不行的，解释的太绝对了又可能被审稿人challenge（“怎么证明？有什么理论？”），这时就要把握轻重。
- 我们有直接的证据时：The performance improves, which is attributed to that XXX can ... （后面要高调地把证据展示出来）
- 没有直接的证据，但有一些可视化等间接证据：The performance improves, which may be explained that XXX can ...
- 几乎没有证据，只是感觉应该是这样的，反正跟我们的motivation是相符的：The performance improves, suggesting that XXX can ...
例6：不要用自讨苦吃的主观词汇。
In Table 1, it is obviously exhibited that …
在学术写作这种场合使用诸如obviously之类的带有强烈主观色彩的词汇没有任何好处。如果审稿人能看出你的结果好，不需要你自己强调这个obviously；如果审稿人看不懂，你越强调他就会越迷惑：到底好在哪了，跟我仔细唠唠，我先判你一个overclaim，阁下又该如何应对呢？
迷惑时间
“迷惑时间”是读者在阅读过程中每一次“咦，这是啥”到“哦，原来是这样”之间的时间的总和。当代人类的耐心是有限的，一篇文章的总的迷惑时间越短，可读性就越高，审稿人就会越心平气和。
例7：提出一个概念后应就近解释。
在深度学习领域中，一个复杂的模型中的一个简单结构根据其功能（和讲故事的需要）可能被命名为XXX Perceiver, XXX Perceptron, XXX Recognizer, XXX Gating Function等等。
建议在给出其名字以后直接解释其实质（we propose XXX, which is implemented with a two-layer MLP）。不然如果在Introduction里只给出了它的名字而在Method部分再给出其实现的话，读者会在很长的一段时间里带着“这么玄乎的东西到底是个啥”的疑惑，最后发现“原来就这啊”，阅读体验很不好。
例8：指代对象应显然且毫无歧义。
We update structure A to solve the problem caused by model B, which is widely used in the literature.
这里“widely used”到底是A还是B？如果我们的写作水平有限，无法让长句完全不带歧义的话，就应该将其拆为短句。没有人会因为你缺少展示高超英语水平的长难句而拒你的文章！
例9：不要在需要读者集中注意力时多次引用数页后的内容。
我们在introduction里可以提几句我们的结果有多么多么好，带上几个对后面的图表的reference，但不要频繁这么干，尤其是不要在需要读者集中注意力（比如你正在激情四射地展开自己的核心故事，需要读者来判断这个故事是否合理的时候），不然读者翻过去再翻回来的这段时间里思维就断了。读者思维的连续性也是可读性的一部分，毕竟论文是线性叙事。这也是孙剑老师教我的最后一点。
信息密度
信息密度就不是什么新的概念了，指的是读者能从单位长度的文字中提取到的有效信息量。信息密度过低的文章会让人走神并怀疑作者的专业性。
例10：气氛组语句不应过于冗长。
我们都知道每篇论文中总有一些不会有人认真看的句子，这些句子一般位于各章开头，且其中“recent years”含量极高。这些句子一般还是要写几句的，但建议注意以下几点。
- 不要太长，写长了没人会看的。我曾经审过一篇做模型压缩的文章，开头从LeNet唠到ViT，直到第二页右半栏才提出“model compression”的定义。
- 不相关的不要写。如果你这篇文章是做ViT的且不涉及底层算子，就不要提卷积网络是如何滑动窗口的了。
- 不要写成历史书。审了这么多稿，我现在对从人类发现动物视皮质原理到LeNet再到AlexNet再到ResNet这段历史已经完全PTSD了。
- 写都写了，尽量跟主旨有点关系，尽快引出正题。例如，如果你提出的是一种新的hierarchical ViT，那么就可以在正文第一句里就把ViT按是否hierarchical分成两类（最近ViT们繁荣发展，包括两类……），第二句就进入主题。
例11：精炼语言。
非英语母语者写出来的英语一般不如母语者精炼，初学者更是经常因为害怕语言不够准确而越写越长。例如：
The image classification performance on ImageNet is 79.99%
改为 The ImageNet top-1 accuracy is 79.99%.As can be observed in Table 1, A outperforms B.
改为 Table 1 shows that A outperforms B.Table 1 shows that the accuracy of model A is 81.0% and the accuracy of model B is 80.0%, so we conclude that model A outperforms model B.
改为 Table 1 shows that model A outperforms model B by 1.0% in the accuracy (81.0% v.s. 80.0%).
用简练的语言准确表达意思是一门技术活，具有本质的困难性。建议多看英语母语者写的论文和其他文字内容，特别是那些有丰富教学经验的年轻选手，因为写教案是最锻炼语言组织能力的（对的，我说的就是当年斯坦福CS231N的主讲Andrej Karpathy）。
例12：图表附近应是全文中信息密度最高的地方，重要的解释和阐述距离图表越近越好。
- 如果图表中有缩写，那么标题里最好就有解释。
- 如果希望强调Table 5中的某个结果，那么分析这一结果的语句最好跟Table 5在同一页上，而且那句话前后最好就有“Table 5”这几个字。这是因为读者可能根本不会仔细看你写的文字，而是先看图表再去找跟图表中的内容关联的文字。一眼看到Table 5中某个亮眼的结果并感到好奇时，他很可能用pdf阅读器的搜索功能来搜“Table 5”。
- 不要指望读者自己从复杂的表格中自己想明白应该拿谁去跟谁对比以得出结论，我们应该把希望形成对比的内容放在一起。如果这样的表格很难设计的话，哪怕为此必须得把某个结果（一般是需要跟若干组结果全对比一遍的baseline）重复几行也在所不惜。没有人会因为表格设计不够优雅而拒你的论文，但看不明白表格进而血压升高的审稿人是真的会。
总结、挖坑与致谢
本文总结了一些从微观层面提高论文可读性的建议和技巧。如果本文能帮助到哪位读者的话，我将不胜荣幸。
我计划在不久的将来写写一篇论文从被数次拒稿到最终中稿的涅槃重生史（也可能随机写点别的）。
最后衷心感谢各位读者朋友在若干个知乎回答下对本文的催更（bushi