Files
agentic-ctx/skills/evaluation-narrative-reviewer.md
2026-05-13 21:36:34 +08:00

1.9 KiB
Raw Permalink Blame History

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. costoverhead、资源消耗、tradeoff、failure case。

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

Inputs

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

Output

# Evaluation Narrative Review

## Diagnosis

## Recommended Order

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

## Missing Bridges

## Concrete Edits

Workflow

  1. 写出主 claim。
  2. 列出所有 evaluation artifactfigure、table、paragraph、slide。
  3. 给每个 artifact 标注 roleheadline / 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”。