# 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、年份、作者、系统名是否明显错误。