paper-revision

# 改论文与回应审稿 两半共用一条纪律：**先判断问题在思路层还是句子层，再动手。** 在错误的骨架上抛光句子，是最贵的返工。 --- # 一、改自己的文字 ## 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 **定义**：相邻两句的思路逻辑连贯，没有跳变。对**每两个相邻句子**问： 1. 第二句是否接着第一句讲？ 2. 若没有接着讲，**是否有过渡**？ 3. 第二句是否出现**新名词**，出现得是否突兀？ ## 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** | 承认，并说明为什么不影响核心贡献 | ## 语言风格（决定成败的四条） 1. **问啥答啥。** 扯其他的会分散 reviewer 注意力。 2. **把 reviewer 问的东西放在段落最前面**，让他一读就知道在答什么。 3. **尽量按 reviewer 提问的顺序回答。** 4. **每个 Reviewer Section 下列出该 reviewer 的所有问题逐一回复。** 即使有 Common Questions，也要在各 Section 下写 "Refer to Common Questions"， 而不是让 reviewer 自己去别处找。 两条底线：**reviewer 要啥就给啥**；**不要在回答里引入新问题**（很容易因此挂掉）。 ## 重点问题 写完初稿后标记**每个 reviewer 的重点问题**（一般在 justification 里）， 把大部分精力放在确认这一两条上。 > 每个 reviewer 一般只有几个主要关心的点。有些 reviewer 写很多， > 但多了以后他们自己也记不住；**review 里那一两个关键点他们能牢牢记住**。 > 其余问题当然也要好好答，只是精力分配不同。 ## 输出模板 ```markdown ## Rebuttal 计划 ### 每个 reviewer 的分数从哪来 - R1（分数 X）：<一句话>　重点问题：<1-2 条，引自 justification> - R2 … ### Concern 分类 | Reviewer | Concern | 类别 | 回应要点 | 依据（table/fig/§ 或需补的实验） | 期限内可行 | |---|---|---|---|---|---| ### 草稿结构 每个 Reviewer Section 下按其提问顺序逐条；Common Questions 单列并在各 Section 引用。 ### 自查 - [ ] 有没有答非所问　- [ ] 有没有引入新问题 - [ ] 重点问题答清楚了　- [ ] 每条回应都指向具体证据 ```