# DrustZ的论文小课堂 \[相关工作Related Work]

这周我们说两句相关工作怎么写\~

相关工作（Related Work），很难写得出彩。但是出彩的话，会让人立刻感到文章的厚重感。很多论文真的就把这个部分写成了相关工作：只是平白地列出所有能找到的文献。听完这节小课堂，你可以比别人写得出彩一点点：）

#### 一句话总结

相关工作要注重内在逻辑，切忌东一榔头西一棒槌地列出其他文献；它的作用在于二：一为读者展开项目背景，如同讲故事铺垫；二为展示自己工作与众不同之处，突出贡献。

#### 目录

* *哪些工作是相关的*
* *构建工作之间的内在逻辑*
* *突出自己工作的不同之处*
* *用好过渡，用好过渡，用好过渡！*

<br>

#### 哪些工作是相关的

首先，请还没有看《我是怎么做文献调研》的小朋友先补习功课：

知道如何寻找和整理相关文献之后，把它们写下来又需要另一个步骤：分类。如何把这么多都相关的文献整理成三到四个小章节，并且每个章节都有一个统一的主题？

我一般会考虑几点：1.研究的问题 2. 研究的对象 3. 使用的技术。每一个点都可以引申出一到两个相关的章节，其中有些可以合并。举个例子：小明为了让视力有障碍的用户（对象）在追剧的时候能够更好地理解视频内容（问题），采用了机器学习+众包的方法，让机器来生成对视频的初步描述，并且让一同观看视频的网友们来提供细节（技术）。那么写相关文献的章节时，就可以讨论与视障用户相关的研究（对象）；与视频内容理解相关的研究（问题）；机器学习理解视频（技术）以及众包的工作（技术）。

如果研究对象比较普遍（例如设计了一种大家都可以用的语音交互），那么也在问题里细分一下，比如使用场景、交互方式等。

<br>

#### 构建工作之间的内在逻辑

当我们划分好相关工作的章节，收集好材料，准备开工的时候，千万不要无脑地把所有文献题目作者列一遍就算了；比如这种（希望论文作者没有订阅我的公号）：

<br>

<figure><img src="https://pic3.zhimg.com/80/v2-37eb4b8e53a842758725be0936c9a07e_1440w.webp" alt="" height="262" width="502"><figcaption><p>（一种很典型的行文方式：把所有工作摊煎饼地摆出来，反正我列出来了，哪个有用你自己找）</p></figcaption></figure>

“做这个工作的有ABCD, A 做了xxx，B做了xxx，C和D做了xxx” ——类似的句式，希望小朋友们不要再写啦。写相关工作的时候，作者应该是充当一种指路人，或者说书人的角色：在详细介绍核心内容之前，把故事背景在读者面前慢慢地，有条理地展开。

所以，你需要把面前的相关文献们，用一条线串起来，来向读者展现它们之间，以及和自己工作之间的关联。这些逻辑可能是递进的：例如文章ABC开创了某个领域，DEF在这个问题领域提出了集中思路，GHI则是在各个思路下的改进——那么我们就可以先说用总领的话来叙述ABC，然后用并列的方式讲DEF，最后可以一笔带过GHI（如果它们不是那么重要的话）。

这些逻辑可能是并列的：例如文章ABC用了X技术来解决某个问题，DEF用了Y技术，而GHI则用了DrustZ的技术——那么我们可以使用分条列举的方式，先写”为了解决某个问题，大家采用了不同的方法“，然后列出1）X技术\[ABC] 2）Y技术\[DEF] 3) DrustZ的技术\[GHI] 。这样把类似的文章集中起来，大家看着也顺溜。

还有些其他不怎么常见的逻辑顺序，比如分-总（例如先有零散的工作，后来有一篇文献把它们综合了起来）。但是当我们意识到文献内在的逻辑顺序，并且把它们按照逻辑列举出来的时候，就已经比许多论文的相关文献高出了不止一个档次：）

更加高级的写作方式，则是与其列举文献，更像是让文献为作者自己的陈述服务。你在阅读的过程中，很难感觉到作者在刻意塞进一些文献来充数；相反，作者是在整理自己的思路，顺便引用了关键的文献来加以佐证。一些好的例子可以参照\[1,2,3]。

<br>

#### 突出自己工作的不同之处

写“相关文献”另一个主要目的，是让大家了解你的工作与这些文献有什么不同。而这一点，许多作者似乎都没有意识到：很多段落都只是列出以往的工作，然后戛然而止。让人读完会摸摸头，OK，我知道了，这些工作很重要，但跟你做的又有什么关系呢？

<figure><img src="https://pic1.zhimg.com/80/v2-ded4b1b913d719c7aa5e9326ffcf2710_1440w.webp" alt="" height="304" width="440"><figcaption></figcaption></figure>

所以在介绍完别人的工作之后，还要在后面（例如章节的最后一段，或者每个段落的最后一句）接一些为什么和这些工作比较，以及与它们有何不同。这样一来，既说了别人工作的重要，也突出了自己工作的价值，其实是一举两得的事请。

<br>

#### 用好过渡，用好过渡，用好过渡！

最后来说一下写相关工作的笔法。其实就一个：用好过渡！开头不要直接列别人的文章，先概括地说一下这个段落的主题；写完一个小部分，不要立即跳到下一段开始写另一个部分，而是在末尾写一个过渡句：“以上就是人们在X领域的研究，但是随着Y技术的进步，更多的人把目光转移到了Z上”，“对于Y技术在X领域的研究已经介绍许多，但在另一个Z方面，相同的技术也有许多应用”。拿出小学作文满分的本领来！

我老板写Related Work有一个习惯，从来不会在大标题下什么都不写就直接跳到第一个小标题（例如上边那个反例）。在大标题的下面，用一些总领的语言来概括+引出接下来的小章节，其实也是一个很好的过渡方式。一切为了读者服务！

<figure><img src="https://pic3.zhimg.com/80/v2-cafd63855ff2e5659ed60614d4280d62_1440w.webp" alt="" height="162" width="528"><figcaption><p>(这是他最著名一篇论文的相关工作开头部分 [4]。哪怕没啥写的，用一句话来引出接下来的小章节，也能起到过渡的作用)</p></figcaption></figure>

在你写完相关文献之后，可以试着只阅读每个段落的第一句以及最后一句，看看能不能大致地掌握整个章节想表达的东西。如果可以，那么你的过渡已经运用地炉火纯青了！

***

以上就是我写论文相关工作部分的一些小经验，希望帮助到在论文写作边缘苦苦挣扎的小朋友。论文写得糟糕不用怕，熟能生巧\~ 本小课堂就是让这个过程变得快一些，让你的论文写作遍地开花！我们下期见！（狗头

> 文章引用：\
> \[1] Fred Hohman, Andrew Head, Rich Caruana, Robert DeLine, Steven M Drucker: Gamut: A Design Probe to Understand How Data Scientists Understand Machine Learning Models, 2019\
> \[2] Jacob O. Wobbrock, Edward Cutrell, Susumu Harada, I. Scott MacKenzie: An Error Model for Pointing Based on Fitts’ Law, 2008\
> \[3] Jas Brooks, Steven Nagels, Pedro Lopes: Trigeminal-based Temperature Illusions, 2020\
> \[4] Jacob O. Wobbrock, Meredith Ringel Morris, Andrew D. Wilson: User-Defined Gestures for Surface Computing, 2009


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://zhang-ming-rui.gitbook.io/when-rocket-launches/wei-xin-gong-hao-gui-dang-dai-bu-chong/ke-yan-xiang-guan/drustz-de-lun-wen-xiao-ke-tang-xiang-guan-gong-zuo-related-work.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
