| 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, ATCASPLOS, ISCA, MICRO, HPCASC, PPoPP, HPDC, ICSMLSys
不能因为方向热门、主题相关或 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，顺序不能随意前移附录：
## Summary and High Level Discussion## Strengths## Weaknesses## Comments for Rebuttal## Detailed Comments for Authors## Scored Review Questions## Reproducibility## Confidential Comments to the Program Committee## Appendix: Evidence Anchors## Appendix: Writing, Presentation, and Consistency Issues## 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 不要伪装成决定性技术缺陷，但要集中列在附录中，帮助作者修正。
评分要求
默认给出：
RelevanceTechnical SoundnessTechnical ImportanceOriginalityQuality of PresentationRecommended ActionConfidenceExpertiseBest Paper Award
分数必须和正文一致。
如果正文指出核心技术证据不足、baseline 不公平、claim 站不住、系统代价缺失或图片/图表证据不可达：
Technical Soundness 通常不能高于 3/5Recommended Action 默认不能高于 Borderline
Recommended Action 标尺
Strong RejectRejectWeak RejectBorderlineWeak AcceptAcceptStrong Accept
默认偏严格。除非论文在问题重要性、设计完整性、证据力度、部署可行性和复现性上都明显过关，否则不要轻易给 Weak Accept 以上。
工作流程
- 定位 MinerU Markdown；优先使用用户提供的
--md，其次从 ingest_manifest.json 的 mineru_md 恢复。
- 读取 Markdown 原文，并解析同目录图片资产。
- 校验 Markdown 引用图片是否可达，记录缺失和额外 artifact 图片。
- 判断论文主 rubric 和次 rubric。
- 先做技术审稿，再做原文细读校对。
- 生成中文 review Markdown。
- 默认保存为
<mineru-md-stem>.review.md，或保存到用户指定 --output。
与其他 skill 的关系
- 可用
paper-search 定位已有资产。
- 必要时调用
paper-ingest 补全 MinerU Markdown 和图片资产。
paper-analyze 只可作为可选辅助，不是默认依赖。- 不依赖
paper-translate 作为主证据。
