改论文与回应审稿
两半共用一条纪律:先判断问题在思路层还是句子层,再动手。 在错误的骨架上抛光句子,是最贵的返工。
一、改自己的文字
1. 思路层(先做这个)
对 abstract、introduction、method 或任意段落,四步:
编码:raw text → high-level 写作思路(一句一条)
分析:a. 该思路是否体现了想表达的内容? b. 思路逻辑是否流畅?
改进:针对不合理处修改思路
解码:改好的思路 → raw text
为什么要编码再解码:raw text 的表面流畅会掩盖逻辑漏洞; 压成一句一条后,逻辑断裂变得显眼。
完整示例
raw text
Inspired by \tocite{Hier gs, LoG, OctreeGS}, we model scene representation as $\mathcal{G}(v,t,\mu,R,S,o,SH)$ based gaussians primitives. Our method organizes gaussian primitives into a tree-based hierarchy with $L$ levels, higher level leading to coarser visual quality but better efficiency, vice versa. Gaussian primitives in higher level nodes are merged from lower level nodes in a designed way. To be specific, we interpolate all the attributes of level $l$ gaussian primitives … to get attributes of level $l+1$ gaussian primitives. We adaptively select nodes to render according to camera view and manually set nodes' velocity by tracking information.
编码
1. 用 gaussian primitives 作为 scene representation。
2. 组织为 tree-based hierarchy,higher level 质量更粗但效率更高。
3. Higher level 由 lower level merge 而来。
4. 具体而言,插值 l 层得到 l+1 层。
5. 根据 camera view 渐进式选择 nodes。
分析 a(是否体现了想表达的内容):想表达的是 ①hierarchy tree 的具体设计 ②设计它的 motivation。诊断——①太粗略,没讲清怎么设计;②完全没讲。
分析 b(逻辑是否流畅):第 4→5 条从"怎么建层级"跳到"怎么选节点渲染",无过渡。
改进 → 解码:补上 motivation、细化设计后重写英文。
2. Sentence flow
定义:相邻两句的思路逻辑连贯,没有跳变。对每两个相邻句子问:
- 第二句是否接着第一句讲?
- 若没有接着讲,是否有过渡?
- 第二句是否出现新名词,出现得是否突兀?
3. 段落是否清楚
从读者角度检查四点: ① 这段是否有一个明确主题? ② 第一句是否讲清了这段要说什么? ③ 每个名词/概念读者能否读懂?是否 self-contained? ④ 相邻句子的逻辑是否连续?
然后 reverse-outlining:从已写出的段落反推它的写作思路,看是否通顺。 (这就是第 1 节的"编码"——同一个动作。)
4. Method 特有
- 每句话的动机是否清楚——读者要时刻知道为什么要执行这句话里的内容
- 句子之间是否 flow
- 名词是否前后一致,不要变来变去
5. 用模型辅助的边界
擅长:指出 sentence flow 断点和逻辑跳变(最有价值);把中英混合的意思写成地道英文;判断某个搭配是否地道。 不能替代:决定这段要表达什么(思路层);判断某个 motivation 是否成立。
一个段落的思路迭代 4–5 版是正常的。在写具体句子的过程中反过来改思路, 是段落思路清晰的关键,也是最常被跳过的一步。
二、回应审稿意见(Rebuttal)
流程
1. 整理 review,回答"为什么 reviewer 给这个分"
2. 分类每条 concern,决定怎么答
3. 起草;标记每个 reviewer 的重点问题,反复确认是否真的答到了
第 1 步的产出不是罗列,而是一句话解释每个 reviewer 的分数从哪来—— 答不出这个,就不知道要靠什么提分。
分类每条 concern
| 类别 | 处理 |
|---|---|
| 可用已有内容回答 | 引用具体 table/figure/section,不要复述 |
| 需要补新实验 | 先评估 rebuttal 期限内做不做得完;做不完就降级为受限回应 |
| 是误解 | 澄清,同时检查是不是我们的写作导致的误解 |
| 确实是 limitation | 承认,并说明为什么不影响核心贡献 |
语言风格(决定成败的四条)
- 问啥答啥。 扯其他的会分散 reviewer 注意力。
- 把 reviewer 问的东西放在段落最前面,让他一读就知道在答什么。
- 尽量按 reviewer 提问的顺序回答。
- 每个 Reviewer Section 下列出该 reviewer 的所有问题逐一回复。 即使有 Common Questions,也要在各 Section 下写 "Refer to Common Questions", 而不是让 reviewer 自己去别处找。
两条底线:reviewer 要啥就给啥;不要在回答里引入新问题(很容易因此挂掉)。
重点问题
写完初稿后标记每个 reviewer 的重点问题(一般在 justification 里), 把大部分精力放在确认这一两条上。
每个 reviewer 一般只有几个主要关心的点。有些 reviewer 写很多, 但多了以后他们自己也记不住;review 里那一两个关键点他们能牢牢记住。 其余问题当然也要好好答,只是精力分配不同。
输出模板
## Rebuttal 计划
### 每个 reviewer 的分数从哪来
- R1(分数 X):<一句话> 重点问题:<1-2 条,引自 justification>
- R2 …
### Concern 分类
| Reviewer | Concern | 类别 | 回应要点 | 依据(table/fig/§ 或需补的实验) | 期限内可行 |
|---|---|---|---|---|---|
### 草稿结构
每个 Reviewer Section 下按其提问顺序逐条;Common Questions 单列并在各 Section 引用。
### 自查
- [ ] 有没有答非所问 - [ ] 有没有引入新问题
- [ ] 重点问题答清楚了 - [ ] 每条回应都指向具体证据