130 lines
4.5 KiB
Markdown
130 lines
4.5 KiB
Markdown
# Research Paper Reviewer
|
||
|
||
用于审查计算机系统方向论文、proposal、技术报告或单个 section。默认不做全面泛审；用户应声明 review purpose。未声明时，先问 purpose。
|
||
|
||
## Supported Purposes
|
||
|
||
| Purpose | 回答的问题 |
|
||
|---|---|
|
||
| `thesis-clarity` | 核心论点是否一句话说得清？ |
|
||
| `problem-importance` | problem 是否真实、重要、端到端相关？ |
|
||
| `derivation-and-evidence` | 推导是否符合第一性原理，证据是否支撑 claim？ |
|
||
| `novelty` | 与已有工作相比，差异是否真实且足够？ |
|
||
| `simplicity` | 方法是否过度设计？ |
|
||
| `writing-kaashoek-style` | 写作是否短、直接、先结论后理由？ |
|
||
| `typos-and-references` | 是否有明显 typo、引用或交叉引用问题？ |
|
||
|
||
可组合多个 purpose，例如 `problem-importance + novelty`。按顺序分别输出。
|
||
|
||
## Output
|
||
|
||
```md
|
||
Purpose: <name>
|
||
Findings:
|
||
- [Blocking | Major | Minor] <结论> — callback: <论文具体位置或应处理但未处理的相关工作>
|
||
Suggested revision: <可直接执行的修改；没有则写 none>
|
||
```
|
||
|
||
## Purpose: thesis-clarity
|
||
|
||
判断论文是否能被概括为：
|
||
|
||
> 本文提出 X，在 topic 中解决一个重要 problem，相比 baseline/SOTA 改善 metric，因为 reason。
|
||
|
||
检查：
|
||
|
||
- 是否能从 abstract/intro 抽出 X、topic、problem、baseline/SOTA、metric、reason。
|
||
- X 是否真的针对该 problem。
|
||
- 是否在讲清 problem 前过早讲 solution。
|
||
- research question 是否具体，而不是“提升性能/效率/准确率”。
|
||
|
||
任一核心要素缺失，默认 `Blocking`。
|
||
|
||
## Purpose: problem-importance
|
||
|
||
检查：
|
||
|
||
- topic 是否具体，而不是过大的领域标签。
|
||
- problem 是否真实存在于实际系统、工作负载或资源约束中。
|
||
- 没有解决该 problem 会造成什么实际后果。
|
||
- problem 是否是端到端 bottleneck，还是只优化占比极小的组件。
|
||
- metric 是否真正量化了该 problem。
|
||
- 影响范围是否足够：系统、应用、用户、工作负载、部署场景。
|
||
|
||
## Purpose: derivation-and-evidence
|
||
|
||
检查 claim -> reason -> evidence -> warrant 链条。
|
||
|
||
### Claim
|
||
|
||
- 核心 claim 是性能、成本、可扩展性、可靠性、可用性，还是机制理解。
|
||
- claim 是否明确写出，而不是让 reviewer 猜。
|
||
|
||
### Reason
|
||
|
||
- 为什么认为 claim 成立。
|
||
- 关键 reasons 是否独立，是否偷换概念。
|
||
- 让 solution work 的关键 technique 和 assumption 是否被明确写出。
|
||
|
||
### Evidence
|
||
|
||
- 实验假设是否清楚，是否接近真实环境。
|
||
- baseline 是否足够强，比较是否公平。
|
||
- 是否覆盖不同配置、规模、工作负载。
|
||
- 指标是否对应 problem。
|
||
- 结果是否稳定，而非只展示 best case。
|
||
- 是否有 ablation 证明收益来自核心技术。
|
||
- 是否有 sensitivity 说明何时成立、何时失效。
|
||
|
||
### Warrant
|
||
|
||
- evidence 到 claim 的推理是否完整。
|
||
- 是否把观察到的结果写成机制解释。
|
||
- 是否把部分 benchmark 成立写成普遍成立。
|
||
- 是否排除替代解释：调参、实现差异、配置差异、benchmark 偏置。
|
||
|
||
审阅单个非 intro/abstract section 时，默认只跑此 purpose。
|
||
|
||
## Purpose: novelty
|
||
|
||
检查：
|
||
|
||
- 核心差异在哪里：设计思路、实现方式、场景约束、资源模型，还是只是调参。
|
||
- 与最相关已有工作相比，新挑战是否真实。
|
||
- end-to-end 收益是否由核心差异带来。
|
||
- 已有方法合理调整后是否可能达到类似效果。
|
||
- 是否漏掉必须比较或必须引用的 competing method。
|
||
|
||
## Purpose: simplicity
|
||
|
||
检查：
|
||
|
||
- 方法复杂度是否由 problem 本身驱动。
|
||
- 是否有可删除组件、阶段、参数或特殊 case。
|
||
- 是否存在“目标很小，机制很重”的不匹配。
|
||
- 如果能简化，给出具体假设：去掉 X 后还应保留哪些收益。
|
||
|
||
## Purpose: writing-kaashoek-style
|
||
|
||
写作规则：
|
||
|
||
- 先结论，再理由，再证据。
|
||
- 句子短，一句一个意思。
|
||
- 每段第一句就是 point。
|
||
- 一段只讲一件事。
|
||
- 数据和名词优先于形容词。
|
||
- 早定义术语，不 use-before-define。
|
||
- 删除 “we believe”, “it is important to note that”, “significantly” 这类软话，除非后面立刻给数字。
|
||
|
||
若改写段落，输出 `before / after`；after 必须更短、更直接。
|
||
|
||
## Purpose: typos-and-references
|
||
|
||
检查：
|
||
|
||
- 拼写、时态、单复数、标点。
|
||
- 图表编号、section 编号、交叉引用。
|
||
- 引用格式一致性。
|
||
- 应引而未引的关键工作。
|
||
- venue、年份、作者、系统名是否明显错误。
|