> For the complete documentation index, see [llms.txt](https://nkcvlab.gitbook.io/tasks_for_rookies/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nkcvlab.gitbook.io/tasks_for_rookies/ability/academic-writing/writing-and-rebuttal.md).

# 论文写作与rebuttal

## LaTex相关

* [命令查询](http://www.mohu.org/info/symbols/symbols.htm)

## **论文结构**

### **题目**

一篇论文的题目是审稿人及读者首先看到的部分，他们根据题目对文章内容进行猜测、对文章贡献建立预期。题目有较多种风格，如：

* 缩写+内容，如BING: Binarized Normed Gradients for Objectness Estimation at 300fps
* 吸引眼球型，如You Only Look Once
* 中规中矩型，全面表达文章贡献，如Clinical skin lesion diagnosis using representations inspired by dermatologist criteria，题目中包含了：做了什么任务，利用了什么技术，技术的创新点

题目的选定应注意以下几点：

* **正确性**：题目中的每个词都应该是被同行轻松接受的（判断的标准：是否曾由老外在顶会顶刊中使用且具有相同表意）
* **准确性**：是否准确地概括了文章的创新点，关键词是否在文章中多次出现
* **美观性**：用词是否专业，是否吸引眼球

<mark style="background-color:red;">**任务**</mark>：打开某会议收录论文列表或某大牛论文列表，观察已接收论文的题目，从中学习。

### **摘要**

大致结构如下：

* 第1-2句：问题定义及/或重要性，现有方案概述；
* 第2-3句：现有方案缺点；
* 第3-5句：本文如何解决/本文技术贡献；
* 第5-6句：本文取得的效果及本文实验情况。

写摘要需要千雕万琢，写句子尽量**使用简单句**（单一主谓宾结构，或加入最多一个简单从句）；避免任何的语法标点等错误；逻辑缜密，有前因有后果，不可无中生有，不可自己下结论。

* **Introduction**：大致结构如下：

  * 第一段：问题定义，问题的重要性；
  * 第二段：现有主要方法综述，各自的缺点（需选择对应本文创新点的缺点进行阐述，如本文提高了算法效率，则应重点分析相关工作是如何效率低下的，至于准确率低等本文未改进的缺点可简述或忽略），此为论文的MOTIVATION。
  * 第三段：可能的解决方案（由文章思路决定，可以是分析其他领域应用成功的技术模块对本文任务的适用性，也可以是分析现有工作出现该问题的内在原因）；
  * 第四段：本文所提出的的技术概述，标志词即为In this paper, we propose to ...；
  * 第五段（可选）：本文方法得到的理论保证或实验效果；
  * 第六段：本文贡献总结。

  **注意事项**：

  * Introduction中提到的相关工作的缺陷或本文假设等，均要在方法部分及实验部分有所体现（理论分析、证明或实验验证），即**前后照应**；
  * 每一段的**功能**必须**划分**地非常清楚（一般按照以上5-6段书写），同时段之间要有逻辑连接；
  * 段内的每一句均有足够的**因果或并列**逻辑关系（少数情况下存在让步逻辑等），注意**转折词**如In addition, In specific, Therefore, Sequentially, Actually等的正确使用；
  * 不主动claim贡献，是非问题上不妄下定论，每一个观点均有足够的文献或理论分析作为支撑；
  * 论文的MOTIVATION应足够健壮（选题阶段应说服所有人）；
  * 写作质量的评价指标：从头到尾一口气可读通，不存在任何疑问，即为表意成功。

### **相关工作**

* 分节：要按照本文方法涉及到的技术或解决的任务合理分节，一般包括2-3节；
* 相关工作的概述要全面客观，重点包括**近年来本文所投稿会议或期刊上接收的（所有的）相关论文**；
* 避免句式单调，在讲前人工作的做法的同时，分析其相对于本文方法体现出来的缺点，在最后与本文方法做比较。

### **方法**

* 流程图需美观、标准、表意清晰；
* 介绍方法的实际操作前需讲清楚这样做的动机，讲清楚该操作内在的物理意义，并分析或证明为何该操作可以达到好的效果； 注意：论文内在地应该满足以下条件：**论文的动机来源正确且具说服力，对相关工作的综述（包括做法和缺陷）合理且全面，提出的方法在理论上可以取得更优的效果，后续实验验证该理论的正确性**；
* 按照文章类型（理论型或技术应用型）适度添加公式、符号。

<mark style="background-color:red;">**任务**</mark>：浏览、整理、总结经典论文的流程图，学习其表达方式。

### **实验**

* 至少包含以下几个模块：
  * 实验配置介绍：数据集、评价指标、网络结构、对比方法等；
  * 参数调优；
  * 消融实验：逐个验证本文各个模块的有效性；
  * 相关工作对比：本文方法与目前最好方法进行对比；
* 最重要的，在报告完结果后应**分析该结果说明了什么现象**（应该是验证了方法部分的某个操作的有效性或Introduction部分某个假设的合理性等，照应前文中的理论分析）

<mark style="background-color:red;">**任务**</mark>：选定某篇经典论文，分析其论文结构

## **Rebuttal及Response**

* 二者区别
  * 会议论文Rebuttal有字数或篇幅限制，该阶段不允许对论文进行修改，且所给时间较短（一般1周），需仔细斟酌，最终呈现的是最具有说服力的非常言简意赅的论据；
  * 期刊论文response无字数、篇幅等限制，且所给时间相对较长（大修一般6周），可按照意见对论文进行细致修改，最终提交的是修改好的论文及较长篇的回复。
* 注意事项
  * 揣摩审稿人语气（根据其评分、用词等），以此决定回复策略；
  * 仔细分析审稿人的concern，以此决定回复的重点。回复时，首先**直接回答**审稿人问题，然后给出**足够的理论、文献支撑**。例如，审稿人讲：虽然本文方法足够有效，但已有的X方法曾提出了类似方法。则回答时的第一句应该是讲本文方法在解决任务、理论支撑、方法定义及实验结果上均不同于（最好在某些方面优于）X方法，然后逐条具体分析；
  * 为每个审稿人的每条意见起一个精确的**小标题**，以此在促进版面易读性的同时体现我们对审稿人问题的理解程度；
  * 回复时（尤其是期刊Response时）应尽量从多个角度进行分析，注意合理地按照逻辑进行分条。

<mark style="background-color:red;">**任务**</mark>：查看实验室某两篇论文（会议期刊各一篇）的投稿历史，阅读并分析其投稿版本、获得的审稿意见、会议论文的rebuttal或期刊论文的response及修改稿、会议论文最终意见或期刊二审意见、论文最终接收版本。对照以上条目进行分析，体会与审稿人进行文字交流的过程。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://nkcvlab.gitbook.io/tasks_for_rookies/ability/academic-writing/writing-and-rebuttal.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.