paper-self-review

name

paper-self-review

description

Adversarially review a paper before submission and predict exactly what reviewers will attack, using the five-category rejection checklist (contribution, writing clarity, result strength, experimental coverage, method soundness) plus a claim-to-evidence audit. Produces a findings report with a verdict per item, not vague impressions. Use whenever the user asks if a paper is ready, what reviewers will say, whether the contribution is enough, whether they will get rejected, or asks you to review someone else's submission — and run it proactively before any submission deadline, because the checklist routinely surfaces a missing ablation or an unsupported abstract claim while there is still time to fix it. Boundary: this predicts what gets attacked and produces the findings list; actually rewriting what it finds is paper-revision. 中文触发：自评审、review论文、审稿、会不会被拒、contribution够不够、投稿前检查、adversarial writing、帮我看看这篇论文。

论文自评审

目的：确定审稿人可能指出的潜在问题，在投稿前就把它们解决掉。

方法叫 Adversarial writing：自己 review 自己的论文， 考虑 reviewer 可能会问的所有问题，并一一解决。

---

一、论文被接收需要做到三点

1. Contribution 足够——需要包含以下几点中的若干： Novel task / Novel pipeline / Novel pipeline module / Novel design choices / New experimental findings / New insights
2. 实验效果比之前的方法好。
3. Ablation studies 和 comparison experiments 充分。

---

二、五方面拒稿检查清单

逐条过一遍，就知道这篇论文是否该被拒。每一条都要给出"是/否 + 证据"，不要泛泛而过。

1. 技术贡献是否足够（论文有没有给读者带来新知识）

• 1.1 想解决的 failure cases 是不是很常见？
• 1.2 提出的技术是不是已经被 well-explored 了，该技术带来的 performance improvement 是可预见的 / well-known 的？
• 1.3 技术是不是比较 straightforward？

如果 1.1 或 1.2 命中，问题出在选题而不是写作——回到 research-ideation 检查是否落入了"四种情况"的前两种。这时候改写作救不回来。

2. 论文写作是否清楚

• 2.1 Introduction 是否清楚描述论文贡献？
• 2.2 Pipeline figure 是否清楚描述 pipeline 与技术贡献？
• 2.3 是否缺少技术细节、不可复现？
• 2.4 每个方法模块是否都写了 motivation？

修复方法见 paper-revision。

3. 实验效果是否足够好

• 3.1 是否只比之前的方法好了一点点？
• 3.2 虽然比之前的方法好，但效果本身是否仍然不够好 / 不够 impressive？

4. 实验测试是否充分

• 4.1 是否缺少 ablation studies？
• 4.2 是否缺少重要的 baselines？是否缺少重要的 evaluation metric？
• 4.3 数据是否太简单，无法证明方法是否真的 work？

5. 方法设计是否合理

• 5.1 实验的 setting 是否不实际？
• 5.2 方法是否存在技术缺陷、看起来不合理？
• 5.3 方法的鲁棒性：是否需要在每个场景上调超参？
• 5.4 新的方法设计在带来 benefit 的同时，是否引入了更强的 limitation， 导致新方法的净收益为负？

5.4 的判据：一篇论文要提升一个 metric，并且不明显损害其他 metrics。

---

三、必查的两条硬要求

1. 所有 claim 必须成立且有实验 support。

论文中所有的 claim（特别是 abstract 和 introduction 里的 claim）， 需要不犯错，也得有实验 support。不然一些 reviewer 会直接以此拒掉论文。

做法：把 abstract 和 introduction 里的每一句断言列出来， 逐条标注它由哪个 table / figure / section 支撑。找不到支撑的，要么补实验，要么改写。

2. Related work 里必须讨论和自己方法最相关的论文。

漏掉最相关的工作，一些 reviewer 会直接以此拒稿。

---

四、输出模板

评审产出用这个格式。每一条都要带位置和证据—— "introduction 写得不够清楚"对作者没有任何用，"§1 第三段引出 technical challenge 时 直接跳到了我们的方法，没有说明 recent method 2 为什么会存在"才有用。

## 自评审：<论文标题>　<日期>

**总判**：<接收 / 边缘 / 会被拒>　主要风险：<一句话>

### 命中项（按严重度排序）
| # | 类别 | 位置 | 问题 | 证据 | 修复动作 | 需要多久 |
|---|---|---|---|---|---|---|
| 1 | 4.1 缺 ablation | §5.2 | core contribution B 没有单独的 ablation | 表 3 只有 A+B 和 baseline | 补 A-only 一行 | 2 天实验 |
| 2 | 2.4 缺 motivation | §3.3 第一段 | 模块 C 直接给了设计，没说为什么需要它 | | 补一句 problem-driven 开头 | 30 分钟 |

### 五方面逐条判定
1. 技术贡献是否足够：<是/否 + 依据>　1.1 ☐　1.2 ☐　1.3 ☐
2. 写作是否清楚：2.1 ☐　2.2 ☐　2.3 ☐　2.4 ☐
3. 实验效果是否够好：3.1 ☐　3.2 ☐
4. 实验测试是否充分：4.1 ☐　4.2 ☐　4.3 ☐
5. 方法设计是否合理：5.1 ☐　5.2 ☐　5.3 ☐　5.4 ☐
（☐ = 未命中即通过；☒ = 命中，需在上表出现）

### Claim 审计
| Abstract/Intro 里的 claim | 支撑它的 table/figure/section | 成立？ |
|---|---|---|
|  |  |  |

### 时间可行性
距截稿 <N> 天。上表中来得及修的：<#…>；来不及的：<#…，建议怎么处理>

最后一节很重要：在截稿前三天报出一条需要两周实验的问题，等于没报。 来不及修的项要给出降级方案（改写 claim、加进 limitation、把强断言改成受限断言）， 而不是让作者干着急。

五、Review 别人论文时

用完全相同的五方面清单和同一张表，逐条过一遍就能得出结论。 区别只是不需要"时间可行性"一节。

---

六、把自评审做成论文的一部分

在论文的最后加一个自我评审的 question lists，按上面五方面分别提问题， 然后根据这些问题改论文。改完再过一遍，直到清单上没有命中项。

追求完美主义是保证论文质量的非常重要的方式。

---

七、超出"不被拒"之后

清单只保证不被拒。要让论文收获好 review，还有一层：

把论文做得漂亮、美观，让人第一印象觉得这篇论文很高级。 三个抓手：好看的 teaser figure / pipeline figure；好看的表格和结果图；整齐的排版。

要让工作有影响力（而不只是被接收）：把算法推到更难的数据上、面向下游研究群体做 demo，见 research-experiment； 选题层面的影响力判据见 research-ideation。