# Evaluation Narrative Reviewer

用于审查论文、报告或 slide deck 中 evaluation 的组织顺序。目标是让读者先看到端到端结论，再理解收益来源、机制、边界和成本。

## Rule

Evaluation 默认顺序：

1. `headline`：端到端结果，读者真正关心的 outcome。
2. `breakdown`：收益来自哪里。
3. `mechanism`：为什么会发生，例如 predictor accuracy、cache hit、queueing delay。
4. `ablation`：哪个设计选择有用。
5. `sensitivity`：在什么条件下成立或失效。
6. `cost`：overhead、资源消耗、tradeoff、failure case。

不要从内部 metric 开始。内部 metric 只有在读者已经知道它服务于哪个端到端 claim 后才有意义。

## Inputs

- Evaluation 章节、图表列表、slide outline 或 PDF 摘要。
- 论文主 claim。
- 可选：目标 venue、读者、页数限制。

## Output

```md
# Evaluation Narrative Review

## Diagnosis

## Recommended Order

| Position | Artifact | Role | Question Answered | Edit |
|---|---|---|---|---|

## Missing Bridges

## Concrete Edits
```

## Workflow

1. 写出主 claim。
2. 列出所有 evaluation artifact：figure、table、paragraph、slide。
3. 给每个 artifact 标注 role：`headline / breakdown / mechanism / ablation / sensitivity / cost`。
4. 检查第一个 artifact 是否是 `headline`。
5. 对每个后续 artifact，写出它回答的自然追问。
6. 检查标题和 caption 是否说发现，而不只是说 metric 名。
7. 推荐更紧的顺序和具体修改动作。

## Checklist

- 第一张图或第一个结果是端到端或 reader-visible outcome。
- 每个后续结果回答一个自然 follow-up question。
- 内部 metric 出现前，它和主 claim 的关系已经建立。
- ablation 不早于 headline。
- sensitivity 和 cost 不被隐藏在 appendix，除非主文已承认边界。
- title/caption 说 finding，例如 “X reduces p99 TTFT by 2.1x”，而不是 “TTFT CDF”。