先写一个快速原型

最好的性能改进是从不工作状态到工作状态的转变。 ——约翰·奥斯特豪特

发现数学问题的解决方案只是战斗的一半。实际上把你发现的论证正式写下来也可能是一项艰巨的任务，特别是当论证很长且没有文献中现有模型可借鉴时。虽然论证的每个细节对作者来说可能都很清楚，但论证的整体结构可能不会立即显而易见。特别是，通常很难在论文的大部分内容已经写完之前就做出关于以下内容的重要决定：

论证的组织结构，以及
良好符号的选择

到那时，组织或符号的任何更改通常都变得难以实施。（过去很多时候，我在没有充分考虑整体结构的情况下开始写论文，花了很多时间建立一些我认为重要的引理，结果后来意识到实际上并不需要这个引理，从而浪费了大量时间。）

我发现软件工程中的快速原型技术有助于缓解这些困难。根据这种技术，人们不按线性顺序写论文，也克制住先写最简单或最直接部分的诱惑。相反，人们按照以下顺序写论文。

快速原型过程

第一阶段：骨架

首先，尽可能快地写出一个精简的"骨架"或"原型"；这个原型包含所有关键引理、命题和定理的（近似）陈述，以及所有关键定义，但所有证明都被省略，或者用非常不正式的"给自己看的笔记"来勾勒。在写作过程的主要阶段，优先考虑的是把"大局"弄对——论文的逻辑组织，以及每个重要命题或符号的一些半精确描述。这些描述的模糊性将允许人们轻松地移动论证的部分内容来改进这个大局。

第二阶段：精确陈述

在组织达到满意程度后，第二个目标是写下足够的证明，以便能够使所有引理、命题、定理和定义的陈述变得精确。

第三阶段：关键论证

一旦完成这一点，第三个目标是仔细写出论证的关键部分，例如从两个先前的关键引理推导出一个关键命题，以确保结构确实按预期工作。

第四阶段：常规填充

最后，填充论文的所有"常规"方面，例如标准引理的证明，或主要定理的快速应用。通常，到这个阶段，论文中剩余的空白是如此不连贯，以至于基本上可以按任何顺序填充。这也是**写引言** 和类似 论文动机 的好时机。

实际实施技巧

任何不影响大局的决定都应该推迟到这个过程的后期。例如，如果你有一个小量，可能等于x或者可能是y，但还不知道确切是哪一个，你可以暂时写"令???"，并在证明中使用???作为这个量的占位符，直到你到达证明中确切弄清楚???应该是什么的点，那时你可以编辑单行来完成证明。（与此相对的是在证明中的两打地方写x，然后在写作过程的后期发现必须回去把这两打地方中的x改为y（以及x^2改为y^2等）。即使有现代的搜索替换工具，这也可能是一项令人恼火的耗时任务。）

协作好处

这种方法的一个好处是它可以与合著者分工。例如，一位作者可以写出证明的非正式草图，省略许多细节，然后另一位合著者可以调整组织和符号，然后填充细节，然后第一位作者可以审阅论文并添加一些评论和写引言。许多其他排列也是可能的；这在很大程度上取决于协作的性质。使用版本控制软件（例如 Subversion）可以极大地促进这个过程，我建议投入一些时间学习如何使用这类软件（例如从这个链接开始）。

写作过程中的想法管理

当你在写论文的某一部分时，经常会得到关于如何处理论文另一部分的好想法；例如，在写下引理时，可能会有一个例子或评论的想法来阐明该引理。当这种情况发生时，我不建议忽略那个想法，也不建议放下当前正在做的事情来完全充实那个想法；相反，花一分钟时间在论文的相关位置为那个想法写一个"存根"（只需足够在回到那个位置时唤起记忆），然后回到之前正在做的事情，以免打断你的注意力或动力。然后可以暂时安全地忘记那个想法，在写作过程更合适的阶段，在闲暇时重新审视它。

注意事项和替代方案

快速原型策略通常很难完美遵守，我必须承认有时（特别是对于较短的论文）我采取非常不同的方法，先写论文"容易"和"有趣"的部分（例如引言，或一些简单的引理），并试图利用产生的动力来快速写出论文的其余部分。如果你非常确信论文的大规模结构将如何安排，这种方法往往效果很好，但当我在写作过程中发现完全不同的组织方式会好得多时，我后悔使用了这种更仓促的方法。