论文写作心得与投稿总结

最近有幸从实验中发现了一点有趣的东西，并在导师的帮助下，完成理论分析、逻辑组织和论文写作，最终投稿到某CCF A类会议，过程曲折，收获颇多，特此记录。
本文目标在于帮助刚开始写论文的博士小白写一份“过得去”的论文，仅适合于刚开始写第一篇文章的博士小白（可能只对计算机部分专业领域有效）阅读。
如果对论文写作有其他的指导或者建议，也欢迎私信我补充。

投稿流程

1. 注册PCS账户，并完成基本信息的填写；
   其他会议和期刊投稿链接

• IOTJ

2. 在投稿页面找到投稿的会议（会显示投稿的批次和日期），填写论文的title，abstract，author，页数，字数，分类等信息；
3. 提交论文与附件；如果想要覆盖之前已经提交的版本，可以在同一页面删掉之前的版本并提供新的论文；

High Level的体会

1. 读者有属于读者的知识背景，作者有作者的知识背景，需要从读者的背景出发，容易理解地逐渐过渡到作者地知识背景和论证要点；
2. 有些表达模糊的东西自己看着清楚，其他人看不懂是因为作者自己看到模糊的东西时，会自然mapping到自己思维中清晰确定的内容，而且其他人却因为没有这种知识背景所以不明白；
3. 写论文关键在于找角度，这个角度既要让读者方便理解，又要角度独特让人耳目一新，需要强调出和过往工作的区别在哪里，又要抽象层次恰当——太高的抽象容易联想到其他相似的东西从而让人觉得空谈，太低的抽象又觉得工作过于specfic，不具有借鉴和泛化意义。

论文提纲

作者不能按照自己的逻辑把内容灌给读者，而是要用读者认识新知识的方式把内容逐渐铺开。这个过程是探索过程和思维逻辑的重新组织。

1. 鉴于代码已经将原始数据处理为预期的结果，这证明了代码逻辑上的可行性。因而对于作者来说，按照代码的实现逻辑描述算法和组织文章是最容易的做法。但是这样组织出来的文章只是技术报告，而不能称之为一篇论文。这样的写法不能让读者明白论文的重点和核心在哪里，即使通过篇幅的安排加以强调，也没有办法让读者第一时间找到重点和key insight；
2. 另一个同样重要的问题是某个内容“放与不放”的问题。论文的篇幅是极为有限的，那么对于内容的取舍也是极为重要的。这里并不是说只放让文章看起来更work、比起SOTA更好的地方，故意省略文章、算法的缺陷，而是应该减少和核心无关的部分。例如，有些工程上的、基础的信号处理部分可以不放，算法部分关于一些细节上的、大家有基本观点的部分可以不放，而算法的先前假设、应用条件、performance极限是要放的。
3. 论文提纲的组织应该像数学公式推导一样：1）已知条件应该是大家的共识、先前的工作；2）论文推导演绎的部分对应数学公式中的一步步推导；3）在数学公式中，由上一步到下一步不能跳过太多步骤，这和写论文一样，由一个观点到下一个观点之间不能跳跃太多，新的概念要定义，推导一个公式要推到底，中间推到一半过会再继续都会让人产生困扰。
4. 大章节的组织应该明晰，形成高内聚、低耦合；如果对一个具体观点的描述横跨两个大章节，那么应该考虑两个章节是不是可以合并。同样的，如果某个章节内容丰度和其他章节明显不同，那么也要考虑是否要换一个方式进行组织；
5. 技术导向/应用导向。如果是技术导向，那么重点应该在于技术本身的特性、可以解决的问题，其优势在于可以更好地体现所提出技术的改进和提升，但是缺陷是如果技术本身的提升不大，或者使用限制较多，那么也容易被暴露出来。如果是应用导向，那么重点就在于应用场景会面临哪些问题，使用的方法是如何解决这些问题的。这适用于技术创新本身并不是特别大或者技术和场景match得特别好的地方。其优势在于有些技术上的问题因为场景不会面临这些问题因而可以被回避，而缺陷在于需要把场景考虑的特别全面，甚至有长期的真实场景下得应用才会被审稿人所接受。
6. 论文框架的组织不能一概而论，因为每篇文章不同步骤的、不同处理过程都是不一样的，这决定了不同论文组织的粒度是不一样的。但是基本的方法是一致的，即都从上述几个方面考虑如何组织和描述。
7. 许多时候会有一种胸中有沟壑，但是写出来就如履平地的感觉，我猜测其原因大概是因为对文章的抽象层次不够，总结归纳不够，highlight不够等等；举个例子（不一定恰当），假设我们写一篇文章讲述如何种小麦，我们当然可以简单地写如何翻土、犁地，播种，施肥，浇水。但是我们也可以这样写：小麦生长要素的研究——根系生长空间、养分和水，再落回到四个步骤，这样读者是不是更容易明白四个操作的联系和组织逻辑了呢？

具体章节写作要点

Introduction

1. 应该包含的要点：1）研究问题的背景和重要性；2）简要描述先前工作做到了什么程度，存在哪些问题；3）简要描述本文解决了哪些问题，背后的insight是什么，这种insight可以解决问题的原因是什么；4）总结本文的要点和key idea，总结contribution；
2. Intro组织模板1：1）xxx得到了广泛应用，例如xxx；2）但是xxx在应用过程中还面临着许多问题，例如在xxx场景下，如果xxx问题不解决，就会对系统和应用产生xxx，这就要求我们解决xxx问题；3）现有工作xxx应用xxx方法解决了xxx问题，但是还面临xxx…（简要写若干个）；4）从上述分析可以看到，虽然先前工作解决了xxx，但是都没有解决xxx，而这也成为了进一步提升xxx的瓶颈；5）我们发现xxx是xxx的原因/可以解决xxx，其原因是xxx/我们利用了xxx；6）因此，本文首先利用xxx提出了xxx算法/技术/观点，…（具体是如何应用的）；另一方面，本文还利用xxx提出了xxx，…（具体是如何应用的），最终我们实现了xxx效果，和现有工作相比得到了xxx的提高。
3. 上面的模板一方面给一个基本的组织逻辑，更重要的是引出下面读者会如何质疑文章。1）这个应用或者限制是否是有价值的、需要解决的问题？2）文章找到的insight为什么就能解决这个问题？其背后的逻辑是什么？3）以读者的背景来看，xxx可能是不对的、没有价值的，为什么在这里可以应用？
4. intro作为文章最重要的部分，会吸引读者绝大多数的注意力。因为读者的背景不同、知识储备不同、认知不同，因而会对文章从各个方面产生质疑，那么如何引导读者的思维，如何让读者接受文章的核心观点，这就是intro质量高低的所在。

Related work

Related work想写得差不多，我目前认为可能要从以下几个角度进行考虑;

1. 围绕文章的contribution。这看起来又是废话，但是我认为还是有必要思考的，例如文章是以技术的角度组织相关工作还是以应用的角度组织相关工作。是从更加笼统的方面组织类似的工作就好还是要具体到具体的技术上的区别。还是以种小麦为例，可以总结种西瓜、种水稻、种各种作物的经验总结，也可以围绕种小麦这一种，围绕相关工作对地域、气候、土壤条件等，关键还是在于从哪一个角度更容易体现文章的contribution在哪里。
2. 确定了要围绕哪一个contribution写作以后，还需要确定如何展开相关内容，即通过哪一方面的相似度或者关联性组织相关的工作。例如，以使用WiFi信号做感知为例，可以将使用的信号作为主线，从CSI振幅，到相位，再到phase difference、共轭相乘和相除，通过使用信号的一步步改进得出一些结果，只不过这个结论可能更和不同信号提供了更多的信息相关。也可以通过使用场景串联起来，例如设备周围的非盲区位置的呼吸，到解决设备周围盲区位置的呼吸，再到解决覆盖家居环境的呼吸监测；
3. 相关工作的缺陷总结要精炼且无可争议。从精度或者performance等方面进行挑战有些时候往往会引起争议，但是从算法设计之初就不可避免地问题进行挑战可能效果会更好。例如，在基于WiFi感知的相关工作中，有些工作需要校准、会遇到累计误差、高度和环境相关（依赖环境中的墙壁或者FingerPrint）会更容易令人信服。
4. 不要有太多的主观判断，对工作的描写要客观。简单地说某个工作不够鲁棒，泛化性不够好是没有意义的，而应该指出在什么场景下该工作会失效/解决不了什么场景下的问题，这样往往更有说服力；
5. 为了引入本文的contribution，需要思考如何将previous work不太好的原因简单地、准确地表达出来，例如其没有考虑xxx,什么算法有xxx问题。
6. 相关工作的分类这个具体需要分情况讨论，可以紧密相关，也可以不那么紧密，但是都要从contribution出发。

Proposed approach

1. 可以一章写完，也可以分章节写完，但是分章节写后，各部分的关系和抽象层次是否对应；
2. 每章节的开头要盖好“帽子”，结尾要“总结”。“盖帽”的目的既是总领本章的内容，另外也是帮助读者明确本章节在全文中所处的地位（对应intro中的哪一部分）。简单来说就是承上启下。
3. “帽子”中还要简单明确地总结各小结内容。
4. 不要太过于细节。
5. 小结之间也要高内聚、低耦合。
6. 标题要简明扼要，且格式统一。
7. 小标题本身也应当组成完整的逻辑。
8. 各小结开头也需要盖“帽子”。
9. 可以考虑多列一些1. 2. …，少用大段的叙述；这样更容易找到重点。
10. 结论尽量前提，方便读者找到文章的核心；
11. 如果一个小结少于两段，或者大约十行，即使内容相对独立，也还是考虑合并。
12. 实验setting、结论标记清晰，释义全面，不要遗漏。

Implement

1. 重点在于实现的细节，但是这种细节并不是简单技术/代码的罗列，也是应该有逻辑，且和上面的内容对得上的；
2. 实现要全面，对于应用导向或者claim应用在某一个场景的系统，应该能够cover住常见的情况，不要出现被reviewer质疑是否有没有情况不能处理；
3. 如果真的有某些情况不能处理，也应该给出合理的措施，例如该情况在该场景下出现概率很低或者系统可以记录该情况方便复查回滚；总之，即使出现了异常情况，系统应该也是可控的；
4. 在描述技术的时候，应该明确每一部分的输入和输出，当前操作是如何利用上一步的输出并给下一步提供输入的，明确该操作的作用；
5. 在描述当前操作时，应该详述该操作的作用，例如对于阈值的划分，其依据和取值逻辑，有时候甚至可以描述高一点的阈值会带来什么样的结果，较低的阈值会带来什么样的结果；
6. 因为在代码实现或者工程设计的时候会涉及很多变量，如果对这些变量的解释不够简单、准确，会很容易给人造成困惑；

Evaluation

1. evaluation要严格对应contribution，evaluation并不是只要把各个场景都试过一遍就可以完成的，因为场景是无穷无尽的。文章需要在有限的场景下，通过逻辑证明这些场景可以代表其他没有尝试过的场景。
2. 最好的组织方式是围绕contribution组织实验，这样的话会让contribution的证明得到加强，也方便读者理解实验的验证过程；
3. 实验细节描述到位，示意图、场景平面图标识风格统一且清晰，按照顺序标注；
4. 使用恰当的标题进行区分和分割；
5. 注意和baseline进行比较，以及如何组织结果使得本文的outperforms更加清晰；
6. 注意使用的metrics是不是合理、易懂；

Limitation

1. 为了让limitation更加清晰，每一处限制可以考虑分为两部分写：第一段写本文技术面临的问题，第二段写可能的解决方案，如果暂时没有适合的解决方案，也可以留待future work；
2. limitation可能的寻找角度是根据上文具体实现的步骤，从假设、简化、近似中寻找。例如文章为了某种目的做了一些假设，但是现实中可能有一些情况并不满足该假设，那么这些情况就是文章的limitation，这样的讨论可以让文章更加完整，让技术的应用领域和条件更加清晰；

Conclusion

1. 和摘要要统一，包括文章的motivation、主要insight和algorithm、performance，该部分应该是一个精简版的摘要和intro。

论文表达

章节

1. 大的章节和小的章节在组织时要有逻辑，可以通过只读标题，不读内容的方式判断是否逻辑连贯；
2. 大的章节和小的章节在开头都要有合适的“帽子”，这个帽子要包含：本章的目标/背景/motivation，和前后章节的联系（承上启下），本章节具体逻辑和内容的简要概述；

段

“一段表达一个内容就够了，如果每一段都把motivation，方法，结论提一遍，那么全文只需要一段就够了”

1. 每一段围绕一个“要点”进行叙述，讲清楚一个“要点”就足够了，不能讲太多；
2. 每一段第一句应该能够总结本段的内容，甚至可以不读段落内的具体描述也不影响读者理顺全文逻辑；

句

1. 主句和从句之间的主语最好统一，频繁改变主语对让人对描述的对象产生疑惑；
2. 句子描述不重复、不拖沓；
3. 避免表达主观的距离，想要表达观点时，要有客观的句子在旁佐证，例如performance，具体数字

词

尚在“悟”，没有较好的总结和guideline

1. 用词恰当，不过分夸大，不词不达意；

其他材料

图片

1. 只放必要的、重要的图，能够和文章核心对应起来的图，每个图最好都能对应文章的“要点”，减少无谓的，表达含义不够丰富的，重复的图
2. 善用caption，caption可以写得稍长一些，甚至在一定程度上可以通过读文章的图和caption就明白文章的主要内容是什么；
3. caption的格式和语言结构要统一；
4. 图片中的字的大小要适当，最好和caption文字大小相近；
5. 可用的画图编辑 MetaPost

公式

1. 同样的，只放必要的，重要的，能够和文章叙述能够对应起来的公式，公式的目的应该是帮助理解，让读者明白文章处理的目标和技术；
2. 部分重要的公式或者公式中的重要部分可以用大括号等进行标记；例如

\newcommand*{\circled}[1]{\lower.7ex\hbox{\tikz\draw (0pt, 0pt)%
    circle (.5em) node {\makebox[1em][c]{\small #1}};}}
\underbrace{}_{\circled{1}}
\overbrace{}_{\circled{1}}

表格

1. 同样的，只放必要的，重要的，能够和文章叙述能够对应起来的表格，之所以强调这么多遍，是因为有时候在作者看来重要的“点”对于读者来说并不一定重要，需要用读者的思维重新审视这篇文章；

随时想到随时更新，这一总结过程将持续一段时间…