改论文与回应审稿
两半共用一条纪律：先判断问题在思路层还是句子层，再动手。 在错误的骨架上抛光句子，是最贵的返工。
一、改自己的文字
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 里那一两个关键点他们能牢牢记住。 其余问题当然也要好好答，只是精力分配不同。
输出模板
markdown## Rebuttal 计划 ### 每个 reviewer 的分数从哪来 - R1（分数 X）：<一句话> 重点问题：<1-2 条，引自 justification> - R2 … ### Concern 分类 | Reviewer | Concern | 类别 | 回应要点 | 依据（table/fig/§ 或需补的实验） | 期限内可行 | |---|---|---|---|---|---| ### 草稿结构 每个 Reviewer Section 下按其提问顺序逐条；Common Questions 单列并在各 Section 引用。 ### 自查 - [ ] 有没有答非所问 - [ ] 有没有引入新问题 - [ ] 重点问题答清楚了 - [ ] 每条回应都指向具体证据
