原文：How (and How Not) to Write a Good Systems Paper

写在之前：本文最早出现在ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40. 作为USENIX 推荐的写作指南对刚动手写论文的写手应该有好的借鉴作用。

一、引言

1983 年 3月 21日，第九届操作系统原理研讨会（SOSP）收到83 篇论文，经过阅读后收录了其中的16 篇作为会议论文发表。录用比率约为1/5 ，虽然收到的论文数量较前几年少，但和往年的会议录用率相近。会议委员会许多成员都发现非常容易分开好的文章和差的文章；的确，十个委员对80% 的论文的处理很快就做出了决定。考虑到接受率，其中大部分文章都被拒绝了。

在进行完会议论文的筛选工作，一些委员表现了对提交论文整体质量的失望。许多被拒的文章表现出类似的弱点，会议委员们认为这些弱点对于作者应该是显而易见的。抱着提高之后SOSP 会议提交文稿、以及更普遍的系统论文的质量，程序委员会决定对收到的论文采用一个标准进行评估。本文将结合委员会所有成员所使用的标准，而不只是作者的。

为了避免冠冕堂皇的说教，我们使用一种启发性、偶尔幽默的方式，以第一、第二人称来陈述。但是，文章的目的却是很严肃的：指出科技论文中不断重复的常见问题，以帮助以后写手们（作者）不再范同样的问题。当你阅读这篇文章的时候，假设你将为第十届SOSP 会议或者TOCS 会议投稿。你在发表之前已经做了一些工作，所以你坐下来开始写一篇文章。当你写的时候你应该问自己哪些问题呢？而这些也是我们检查你的论文将提出的，并决定你的论文是否被发表的问题。

二、文章的类别

你的文章会很自然地分到以下三类之一：

• 它提出了一个真实的系统，或者是整个系统的综述，或者是嵌入在系统的特定主题的选择性论证。
• 它提出了一个未被实现的系统，但其中使用的想法和技术你认为应该是技术社区所认知的。
• 它提出了理论上的一个主题，比如，性能建模或者安全验证。

显然，单一的评价标准不能等同地运用到不同类别论文中；但是，许多标准对以上三类还是通用的。如同下面我们描述的，我们尽量强调每篇文章都应该有其所应该适用于的一个类型，通常通过上下文来展现。

 

三、提交论文的评价标准

读到的见解（Original Ideas）

论文中的想法新颖独到么？提交给会议或者期刊的论文是关于创新性工作的，至少包含一个创新点，否则论文没有任何意义。

那么你如何知道你的工作是创新性的？你的论文必须包含对该领域当前最新的研究，这样才知道你工作的原创性。可能第一类（真实系统）提交的论文最常见的问题就是缺少新意；描述的系统往往和在文献中一些开拓性系统是同构的。

你能够简要地阐述你的新想法么？如果你的文章是发展当前领域的知识，你的读者必须能够从你的论文中找到新的想法并理解。如果你不能，考虑下你是不是自己没有真正理解这个想法。当你有了想法的一个简要阐述，在文章的摘要部分给出。

到底解决了什么样的问题？不要期望读者只是读了你的解决方法的描述就能够猜到你遇到的问题。一定要解释为什么你的问题不能被当前发表的技术所解决。

创新性的想法足够支撑你的这篇文章么？通常情况，论文只是描述了已经成熟的技术的一、两点改进。一个新的想法能够几段就可以描述清楚，那么二十多页的论文就不必要了，会反而使实在的创新点变得难以理解。因为实在一个真实系统上的贡献常常做了许多工作，文章作者往往用全部的努力混淆了那些真正具有创新点的工作。（”My team worked on this system for two years and we’re finally done. Let’s tell the world how wonderful it is.”）如果创新性很小，那么一篇短文发表在一个合适的期刊上可能更合适与SOSP。

这个工作介绍得是不是和已经有的相关工作区分开来？对之前发表的算法，技术，或系统明显的发展并不保证一定发表。当然，“明显”这个标签必须小心使用。（记得哥伦布示范如何使得一个鸡蛋立起来（杂碎一端立起来）的故事么：“这才是我告诉你明显使用的地方”）你必须给出你的工作和最新的研究成果不同的地方。如果你不能，那么你应该问问你自己你为什么在写这篇文章，为什么其他人除了你的妈妈之外都想去读这篇文章。

是不是所有的相关工作都被引用了，你到底有没有真正读过引用的文献？否则你在遇到那些质疑你工作原创性的读者时会遇到麻烦，除非你能够很清晰地指出和之前发表文章的不同之处。这就需要引用。更进一步，你很难说服哪些阅读了你引用，而你却没读过的文献的读者。

所有和之前工作的比较是否清晰和明确？你不能简单地说：“Our approach differs somewhat from that adopted in the BagOfBits system[3].”，而应该明确指出：“Our virtual memory management approach uses magnetic media rather than punched paper tape as in the BagOfBits system[3], with the expected improvements in transfer rate and janitorial costs.”。

所做工作包含一个有意义的扩展，验证，或这之前的但未被验证想法的否定么？关于应用经验支持了之前发表的论文，或者与之前已发表的论文相矛盾的设计，是非常有价值和有意义发表的。设计很简单，但应用（尤其是基于那些没有听过的设计）是很有意义的。

引用的最旧的论文是哪篇？最新的又是哪篇？你有没有引用过其他研究所的相似工作？你有没有引用科技报告，未发表的备忘录，个人通信？这些问题的答案帮助提醒你知识或理解中的盲点。经常地，那些只有权威论文的引用的论文往往重复了最近发表的工作，而论文作者却不知道。只包含了最近论文的引用常常“再发现”（虽然不知道）旧的想法。那些只引用了未发表或者没有被引用的文章往往视野狭窄。要记住引用不仅是对其他的感谢，还是一个微小的机制，通过其读者可以了解到该领域的基本原理以及发展情况。如果读者想了解更多，他只需要将引用变为他能够读到的文献即可。个人通信和内部的备忘录都不能做到这点。技术报告通常在数量上印刷受限，很难获取，因此尽量避免引用这类文献。

 

系统实现（Reality）

文章描述的是真实的已经被应用的东西么？有不少提交到SOSP 的论文长达十五页，开始都是紧张的论述，到最后总结（如果有的话）才回答这个问题，那么在这之前的描述的都是假设的系统，该系统应用刚开始或者还没有被完成。这点是不能接受的。你的读者有权利在一开始就知道讨论的系统是否是真实的。

如果系统已经实施应用，它是如何应用的，它在展示出论文想法重要性中起着什么作用？再次声明，一个多少人年的实施努力本身并不能佐证一篇论文的发表。如果应用的系统包含新的想法，如何解释其在实际中发挥作用也是重要的。一个看似不错的想法没有成功至少和其成功了是一样有意思的。特定性和精确都是重要的。“Our weather prediction system is up and running and no one has complained about its occasional inaccurate forecasts”远没有“everytime we fail to forecast rain, the users hang their wet shirts over the tape drives to dry”具有说服力。在后者，起码我们知道人们使用并依赖这个系统。

如果系统还没有实现，那么这个想法现在足够用来发表么？这个问题作者可能很难冷静地回答，但每个审稿人都会给出自己的决定。写篇描述一个新的系统的设计论文，然后在接下来一、两年中实现，并产生一篇“经验”论文是非常诱人的。这类流派的成功论文几乎在设计论文结束都包含了初始的一些经验。接下来的论文是关于长期使用该系统的经验教训，常常以意想不到的方式。审稿人通常对纯设计类的论文非常怀疑，除非其新想法具有非常高的质量。

 

经验教训（Lessons）

你从所做工作中获得了哪些经验教训？如果你没有学到任何东西，那么可以打赌你的读者也没有，那么你就只是浪费了他们的时间和浪费了出版你文章花费的树木。

读者应该从论文中学到什么？清晰地讲出这些经验教训。许多人重复着历史的错误就是因为他们不明白书中经验教训。

这些经验教训具有多普遍的应用能力？一定记得清楚说明所做结论依赖哪些假设。要小心基于缺乏知识和经验的概括。在“真实系统”中一个由其普遍的问题就是从单个例子的概括。比如，假设所有文件系统目录都保存在一个文件中并线性检索。当给出你的结论时，结论帮助再次阐述了之前的假设。但读者可能十五页都没有看到并忘记了这样的假设，你自己可能也忘记了。

 

选择（choices）

在不同情况下它的替代品是什么？为什么要选择这样的方式？一篇好的文章不仅描述，而且解释。告诉了读者一些你所做工作所没法告诉他们的，你在选择时是如何小心考虑的。你希望能够节省未来的研究者们碰壁的代价。你也记录下那些可能有意思的途径还没有试探过。确信你说清楚了什么是什么。

选择结果是正确的么，如果是，这是促使它们摆在首要位置的原因么？如果不是，你从经验中学到了什么？你多少次发现自己说“这有用，但理由错了”？这样的声明代表着智慧（至少少量的）并使得你的读者受益。许多文章从开始的假设中给出了一个合理的参数并由此推导出了结论，而实际上是尝试了很多种参数，获取不同的结果，最后从最优的结果中反向得到合理的参数。这种“历史修正主义”处于不诚信的边缘，并使得读者不明白研究工作是如何真正做的。

 

上下文环境（context）

研究工作是基于哪些假设的？只有假设都得到声明，抱有怀疑精神的读者才能够接受你的论点。确保你给出了所有的假设，因为一些隐性的假设很容易忽略。

它们都是实际的么？对于“未实现系统”的论文，这相当于问设计的假设是否能够有望支持成功的应用。许多论文设计在抽象地处理真实的系统组件特点时都是幼稚的。对于理论研究假设如何映射出现实必须清楚，比如，可靠性建模中的错误模型，安全验证中安全威胁类别，排队论中到达分布。

研究工作对于这些假设的扰动有多敏感？如果你的假设都是建立在一堆脆弱的假设条件之上，那么对于读者来说，这比建立在一个更为广泛和坚实的基础上的成果要没用的多。

如果论文提出了一个模型，那么它提供了什么样的见解和信息？仅仅是定义了想象的模型本身并不是那么有用。一个深刻的定理比一千个定义都要有意义。

 

聚焦（Focus）

介绍性的材料是否包含了对于你的研究工作多余的材料？“真实系统”的论文尤其对无关的描述很在意。如果你的主题是分布式文件系统，计算机之间的连接和通信网络的物理特性就可能不那么在意。避免以同样的深度介绍系统的所有主要特性的想法。集中在具有新颖性和不寻常的地方，而这些将是文章原创性技术内容的焦点。

你涵括了之前发表的工作中足够的材料使得你的读者能顺着你的论述么？不要假设读者在上周已经对阅读了所有引用的文章，也不要假设他们在阅读时能从指间瞬间参考。如果你想让你的读者参考之前的文章，避免这种类型引导式的语句“We adopt the definition of transactions from Brown [4], layering it onto files as described by Green [7, 18], with the notions of record and database introduced by Black [10] and White [12] and later modified by Gray [6]”。另一方面，不要从冗长的摘要和引用工作的意译使你的读者加重不必要的负担。

 

介绍（Presentation）

所有的想法都清晰、合理地组织和阐述了么？

所有的术语在使用之前都有定义么？

向前引用是否保持在最低限度了呢？读者如果碰到像下面的陈述会非常烦躁“每个文件包含了一系列项目，将在后面的章节中介绍”。读者必须记住技术术语“项目”，但这个术语还没有任何语义。要求读者这样做一次、两次还是可以接受的，但只有在绝对必要的时候。即使你当时还不能跑题介绍“项目”的含义，提供给读者关于这个术语的一些有意义的信息：“每个文件包含了一系列项目，这些可变大小、自定义序列的详细解释将在后面‘多媒体文件’下进行讨论。”你的读者可能还是不完全明白你的文件的概念，但至少他隐约看见你想带他向哪个方向。

有备用的文章组织么？理论文章，特别是包含数据形式的，一般都比描述系统的文章好组织。期望的定义，引理，定理，例子，推论顺序对于推导性论文非常有用，但对描述性论文施展不了拳脚。在“真实系统”的论文中，更多的依赖于动机：广泛的调研和选择性的对待。通常情况下，在组织上的困难往往是因为作者不愿意遵从任一方法。决定论文是对你的系统的综述还是集中在一个特定的点上，然后相应地构建文章结构。

要先写一个摘要么？摘要传达了文章的重要想法没？在文章的摘要中介绍系统更容易被滥用。摘要常常是内容的散文表而不是文章技术内容的大纲。一个摘要的示例：“A system based on Keysworth’s conceptualization of user interaction [4] has been designed and implemented. Some preliminary results are presented and directions for future work considered.”没有读者在浏览到这里会继续阅读。为了避免被动时态（虽然很传统）并包含一个简单的声明和结果。“We designed and implemented a user interface following the ideas of Keysworth and discovered that converting the space bar to a toe pedal increases typing speed by 15%. However, accuracy decreased dramatically when we piped rock music instead of Muzak ™ into the office.”将讨论和争论放在文章后面。这样有助于在完成整篇文章前写好摘要，甚至大纲，因为它将重心集中在你想调研的主要想法上。

文章写完了么？审稿人往往能够帮你改进你的文章，但他们不能够代替你来写。此外，你也不能期望他们在你的章节中进行修补并标注上“在最终稿上加上”。在一篇数学论文中，审稿人对没有证明的定理保持着怀疑态度，并且，如果该定理是推导最终目标的基础，那更是不可忍受的。同样的，在描述一个系统的文章中，审稿人也不能容忍对系统重要的解释或理由的忽略。

 

写作风格（Writing Style）

写作是否清晰、简洁？

字词是否拼写并使用正确？

句子是否完整，语法是否正确？

模棱两可的、俚语、俏皮话是否避免了？

如果你在提交论文之前没有足够重视你的文章中的语法错误，拼写和用法，你为什么要期望审稿人认真对待你的论文呢？一些审稿人感觉这种疏忽不只是局限在文章本身，并将在第一个技术上不合乎逻辑的地方拒绝文章。请记住你是请求审稿人帮个忙：“请让我说服你我做了一些有趣的，足以发表的工作。”审稿人如果收到的是一份整洁，清晰，小心翼翼地修正了的手稿，而不是像一个小学辍学写的，经过复印机10 次复印后的奇数大小纸张的论文，他会更愿意帮助你。即使你不特别关注精确的论述，那在你的组织中也一定有某人关注着。将你的手稿交给这些认真的灵魂并认真听取建议。

 

四、总结

这些三十多个问题可以帮助你写出一片更好的技术论文。当你组织你的演讲，写第一份草稿，和将你的草稿提炼为最终形式事可以参考之。其中一些问题指出了“系统”论文特有的问题；另外的一些适用于一般性的技术论文。写出漂亮的论文是份困难的工作，但你也获得了回报：你的想法在杂志的社区以及会议读者中得到广泛的传播和更深入理解。