paper-review

name	paper-review
description	论文严格审稿：基于 MinerU 生成的英文原文 Markdown 与同目录图片资产，生成面向系统、体系结构与高性能计算顶会的专家级中文审稿意见、评分、rebuttal 问题和原文细读校对。
allowed-tools	Read, Write, Bash, WebFetch

目标

paper-review 用来生成接近真实系统 / 体系结构 / 高性能计算顶会 PC reviewer 水平的中文 review。

它不是复述论文，不是把 paper-analyze 笔记改写成审稿意见，也不是根据 PDF 重新审稿。正式审稿材料必须是 MinerU 生成的英文原文 Markdown，以及该 Markdown 同目录下的图片资产。

审稿必须回答：

• 论文的核心 claim 是否被 Markdown 原文中的证据支撑。
• 方法、系统设计、实验、baseline 和部署假设是否足以支撑接收。
• 关键弱点是否影响 soundness、generalizability、reproducibility 或 deployment realism。
• 作者 rebuttal 最需要回答哪些可能改变分数的问题。
• 原文是否存在会损害可信度的笔误、符号混乱、图表不一致、数值冲突或过度 claim。
• 不得把任何单篇论文、已有 review 或一次性回归样本当作模板。每次审稿都必须从当前 Markdown 原文重新归纳问题、证据、弱点、评分和 rebuttal 问题。

输入

优先支持：

• MinerU Markdown 原文路径，即 --md <mineru.md>。
• ingest_manifest.json，脚本从其中解析 mineru_md。
• Markdown 同目录 images/ 下的图片资产。

可选支持：

• paper-analyze 正式分析笔记，仅作为人工辅助定位材料，不作为默认输入或主证据。
• PDF 路径仅作为资产来源信息；不要把 PDF 当作 review 的审稿材料。

辅助笔记的使用边界：

• 笔记可以帮助定位论文主线、潜在 open gap、图表含义、术语关系和可能遗漏的系统问题。
• 笔记中的任何判断都必须回到 MinerU Markdown 原文或同目录图片重新找证据；找不到原文证据时，只能写成“原文证据不足”，不能把笔记内容当事实写入正文。
• review 正文不要写“笔记指出”“根据分析笔记”等来源表述。笔记只服务于审稿人的阅读组织，不参与最终证据归因。

如果缺少 MinerU Markdown，应先调用 paper-ingest 生成 Markdown 和图片资产。不要因为只有 PDF 或分析笔记就生成正式 review。

核心原则

Markdown 原文优先

• 所有关键判断必须落在 MinerU Markdown 原文和它引用的图片资产上。
• paper-analyze 笔记不能覆盖 Markdown 原文证据，也不能作为最终裁决依据。
• 如果 Markdown 中没有足够证据，必须直接写明证据不足，而不是假设 PDF 中可能有。
• 可以做合理推断，但必须区分原文事实和审稿判断。
• 任何论文都只能作为被审稿对象或回归验证样本，不能把它的段落组织、技术结论、措辞、评分或弱点迁移成默认模板。

图片资产必须检查

• 生成 review 前必须解析 Markdown 中的 ![](...) 和 HTML <img src=...> 图片引用。
• 图片相对路径按 Markdown 所在目录解析，常见形式是 images/fig01.jpg。
• 必须统计图片引用数量、可达数量、缺失数量，以及同级 images/ 目录中的额外图片数量。
• 主体 review 不要堆图片文件名或长英文图注；图片路径、图注和可达性信息放到 Appendix: Evidence Anchors。
• 未被 Markdown 引用的 MinerU artifact 图片不强行用于审稿，只作为额外资产记录。

专家级系统与 HPC 审稿

默认站在严格系统、体系结构与高性能计算顶会 reviewer 视角，参考：

• OSDI, SOSP, NSDI, EuroSys, ATC
• ASPLOS, ISCA, MICRO, HPCA
• SC, PPoPP, HPDC, ICS
• MLSys

不能因为方向热门、主题相关或 idea 合理就放松标准。强项必须解释它如何支撑接收；弱点必须解释它如何影响 soundness、deployment、generalization 或 reproducibility。

按论文类型切换 Rubric

生成 review 前必须判断论文最接近哪类工作。横跨多类时，选择主 rubric 并吸收次 rubric 中真正相关的检查点。

serving

• 在线路径是否真实：prefill/decode、batching、queueing、admission control、多租户、故障恢复是否进入论证。
• SLO 指标是否完整：平均值不能替代 tail latency、SLO attainment、burstiness、goodput。
• workload 是否可信：生产 trace、合成流量、请求长度分布、冷热模型、流量漂移是否覆盖。
• 收益是否被 profile 失配、重配置延迟、控制环开销和非平稳流量抵消。

cache

• 比较是否在同一 memory budget、precision、上下文长度和质量约束下进行。
• eviction / compression / reuse 对质量、命中率、写放大、metadata、恢复路径和碎片化的影响是否披露。
• 长上下文、prefix sharing、不同模型 family、不同 attention 结构和 failure case 是否覆盖。
• 内存节省是否真正转化为吞吐、容量或延迟收益。

scheduler

• 目标函数是否区分 throughput、fairness、deadline、tail latency、starvation 和 utilization。
• workload arrival、job size、优先级、异构资源、抢占、迁移、backfill 和 head-of-line blocking 是否进入实验。
• oracle、heuristic、learned policy 与强基线是否公平比较，调参和信息可见性是否对齐。
• 平均收益是否掩盖最坏情况、长尾、饥饿或租户间不公平。

compiler

• 优化是否建立在明确 IR / transformation / cost model 上。
• correctness 是否通过语义保持、数值误差、fallback、unsupported op 和 dynamic shape 处理得到论证。
• baseline 是否覆盖厂商库、手写 kernel、已有 compiler、auto-tuner，且调优预算一致。
• compile time、search cost、code size、portability、跨硬件泛化和端到端收益是否完整报告。

distributed_training / HPC

• scaling 是否区分 strong/weak scaling，并与 global batch、收敛、样本效率和最终质量绑定。
• 通信、计算、内存、pipeline bubble、optimizer state、checkpoint、容错和 straggler 是否被分解。
• baseline 是否在相同模型、batch、precision、并行策略和网络硬件下比较。
• 速度提升是否只是吞吐提升，还是在 time-to-quality / cost-to-quality 上也成立。
• 对 SC/PPoPP/HPDC/ICS 风格论文，要特别检查并行效率、通信/计算重叠、负载均衡、可扩展性曲线和跨平台复现。

必查清单

生成 review 前必须显式检查，并将重要发现融入正文：

• 方法结构是否闭合：问题定义、核心假设、组件、执行路径和最终 claim 是否一致。
• 每个方法组件是否必要：是否有消融、替代设计或失败案例。
• baseline 是否足够强，比较是否公平。
• budget / precision / memory / latency / hardware / tuning effort 是否对齐。
• 实验是否覆盖质量、容量、延迟、吞吐、tail latency、扩展性、失败区间、跨模型、跨任务、跨上下文长度。
• claim 是否超过证据能支撑的范围。
• 系统代价是否完整披露，而不是只讲收益。
• deployment realism 是否充分，包括在线路径、batching、多租户、tail latency、工程集成和恢复机制。
• artifact / reproducibility 是否足以复现关键结论。
• Markdown 图片引用是否能解析到本地图片文件。
• 原文是否存在表述错误、笔误、符号/缩写不一致、图表引用错误、数字和单位冲突。

输出结构

默认输出以下 section，顺序不能随意前移附录：

1. ## Summary and High Level Discussion
2. ## Strengths
3. ## Weaknesses
4. ## Comments for Rebuttal
5. ## Detailed Comments for Authors
6. ## Scored Review Questions
7. ## Reproducibility
8. ## Confidential Comments to the Program Committee
9. ## Appendix: Evidence Anchors
10. ## Appendix: Writing, Presentation, and Consistency Issues
11. ## Appendix: Rebuttal Sensitivity

主体 review 应像真实审稿意见，不要像 checklist 或工具报告。Evidence、图片路径、图注片段、文字细读问题和 rebuttal sensitivity 放在附录。

主体质量要求：

• 每一节都必须围绕当前论文自己的事实链写作：核心 claim、方法机制、baseline、budget、图表、数值结果、系统代价和缺失证据。
• 不要把系统/HPC rubric 原句改写成正文。rubric 只能作为检查框架，最终文本必须像真实 PC reviewer 对这篇论文的具体判断。
• Summary 要先给出总体判断和 action，再解释决定性证据；Strengths 要说明哪些证据真的支持接收；Weaknesses 要说明哪些缺口会改变 soundness、deployment、generalization 或 reproducibility。
• Comments for Rebuttal 必须是作者可以在 rebuttal 中直接回答、且回答后可能改变分数的问题。
• Detailed Comments for Authors 应提供可执行修改建议，不能只写“需要更清楚”“有助于判断”这类空泛句子。

写作要求

• 全文中文，不生成英文版。
• 主体用中文概述证据含义，不直接粘贴长英文 abstract、原文句子或图注。
• 英文术语可以保留为短语，例如 tail latency、SLO attainment、artifact。
• 不要写“这篇论文很有意思”“方向很重要所以值得关注”这类弱判断。
• 不要写“这类问题能够支撑 relevance/importance”“让 reviewer 判断”“有助于判断”“Markdown 原文抽取到”等面向工具或元审稿人的句子。
• 不要把判断交还给读者。必须直接说明当前证据支持什么、不支持什么，因此给什么分数和 action。
• 不要在 review 正文里说“分析笔记指出”。判断必须直接指向论文、实验、图表、claim 或缺失证据。
• 每条主要 weakness 都要形成因果链：证据或缺失证据、机制原因、对 soundness / deployment / generalization / reproducibility 的后果、对接收判断的影响。
• 小的 typo 和 presentation issue 不要伪装成决定性技术缺陷，但要集中列在附录中，帮助作者修正。

评分要求

默认给出：

• Relevance
• Technical Soundness
• Technical Importance
• Originality
• Quality of Presentation
• Recommended Action
• Confidence
• Expertise
• Best Paper Award

分数必须和正文一致。

如果正文指出核心技术证据不足、baseline 不公平、claim 站不住、系统代价缺失或图片/图表证据不可达：

• Technical Soundness 通常不能高于 3/5
• Recommended Action 默认不能高于 Borderline

Recommended Action 标尺

• Strong Reject
• Reject
• Weak Reject
• Borderline
• Weak Accept
• Accept
• Strong Accept

默认偏严格。除非论文在问题重要性、设计完整性、证据力度、部署可行性和复现性上都明显过关，否则不要轻易给 Weak Accept 以上。

工作流程

1. 定位 MinerU Markdown；优先使用用户提供的 --md，其次从 ingest_manifest.json 的 mineru_md 恢复。
2. 读取 Markdown 原文，并解析同目录图片资产。
3. 校验 Markdown 引用图片是否可达，记录缺失和额外 artifact 图片。
4. 判断论文主 rubric 和次 rubric。
5. 先做技术审稿，再做原文细读校对。
6. 生成中文 review Markdown。
7. 默认保存为 <mineru-md-stem>.review.md，或保存到用户指定 --output。

与其他 skill 的关系

• 可用 paper-search 定位已有资产。
• 必要时调用 paper-ingest 补全 MinerU Markdown 和图片资产。
• paper-analyze 只可作为可选辅助，不是默认依赖。
• 不依赖 paper-translate 作为主证据。