triage-reviews

评审意见分诊

将原始评审意见转换为结构化决策文档：逐条拆分所有疑虑、分类（误解／实际缺陷／要求开展的实验／澄清／意见分歧）、按严重程度 × 工作量评分，并排序为符合投稿场所回复篇幅限制的答复计划。这是「收到评审意见」到 write-rebuttal 之间的规划步骤——直接依据原始评审意见撰写答复，会让影响评分的要点淹没在对错别字的确认中。

使用时机

• 「我的 NeurIPS／ICML／SIGSPATIAL／……评审意见已经收到——帮我回复」
• 「分诊这些评审意见」／「答复时应该先处理什么？」
• 「审稿人 2 说了 X，但论文已经涵盖了——我该怎么处理？」
• 从 OpenReview、EasyChair、CMT、HotCRP、PCS 或通知邮件中粘贴的评审意见
• 始终在使用 write-rebuttal 之前进行；对期刊修订后重投的回复也有帮助

输入

1. 文件中的原始评审意见（例如 reviews.txt）：用户从投稿系统粘贴或导出评审意见。各平台的复制说明和注意事项见：references/platform-formats.md。
2. 投稿场所配置文件（可选，但建议提供）： venues/conferences/<venue>-<year>.yml（架构见 venues/schema.yml）——提供 review.rebuttal_format、review.rebuttal_limit 和 deadlines.rebuttal_end。如果缺少该文件，先运行 parse-cfp，或采用通用平台格式继续处理。
3. 已提交的论文（.tex／PDF，可选）：用于核实误解相关的说法并补充证据定位信息。

流程

1. 暂存原始文本 — 保密处理。 请用户将评审意见保存到 git 仓库之外的本地文件中（或将其添加到 .gitignore）。 大多数会议的评审文本都属于机密：应临时处理，绝不可提交。

2. 确定性解析。 运行：

   python3 scripts/parse_reviews.py reviews.txt -o triage.json
   

   自动检测平台；使用 --format openreview|easychair|cmt|hotcrp 可强制指定平台；如有需要，使用 --min-words 3 捕获简短的单句意见。输出为 JSON 框架：评审人、评分、规范章节，以及逐条意见（R1.1、R1.2……），其中 classification／severity／effort 留空。退出代码：0 表示成功，1 表示未检测到内容，2 表示输入无效。

3. 对照原始文本核验解析结果。 确认评审人数、原始文本中的每项不足／疑问都已作为意见列出，并确认评分均已提取。如果遗漏了评审人或意见，请修正文本文本（插入一行 Review N 横幅）并重新运行，或手动将意见添加到 JSON 中 — 绝不可悄然遗漏评审人的任何观点。恢复步骤见：references/platform-formats.md 的最后一节。

4. 确定会议的 rebuttal 规则 — 然后在线重新核验。 从会议资料中读取 review.rebuttal_format、review.rebuttal_limit 和 deadlines.rebuttal_end。资料仅供参考，绝非最终依据：在用户依赖这些信息之前，应根据当前的 cfp_url（以及会议的作者指南）重新核验 rebuttal 格式、字符数／页数限制、是否允许提交新的实验结果，以及截止时间。说明核验了哪些内容以及核验时间。如果 rebuttal_format: none，请明确说明 — 分流结果仍可用于终稿修改或下一次投稿。

5. 对每项意见进行分类。 根据 references/triage-rubric.md 中的决策树和定义，为 triage.json 中的每项意见填写 classification、severity、effort、evidence_anchor 和一行 response_strategy。必须遵守以下规则：

   • 只有在论文正文中找到能反驳该说法的内容后，才能将其归类为 misunderstanding — 并在 evidence_anchor 中标注章节／行号。
   • 严重性衡量的是对录用的威胁，而非评审人的语气；有 2 位或更多评审人提出的意见，严重性上调一级。
   • 工作量衡量的是在 rebuttal 时限内作出回应的成本，而非修改论文的成本。
   • 对于任何你不确定的意见，请与用户逐项讨论；用户最了解论文。

6. 生成矩阵。 运行：

   python3 scripts/build_matrix.py triage.json --budget <limit> --budget-unit chars
   

   根据已核验的 rebuttal 限制设置预算（例如，NeurIPS 风格的 OpenReview 使用 --budget 10000 --budget-unit chars；CVPR 单页 PDF 使用 --budget 800 --budget-unit words；期刊 R&R 则省略 --budget）。该脚本会验证枚举值（在分类完成前，如果仍有未填写的意见，则以退出代码 1 并列出这些意见）、计算优先级评分以及 must／should／brief 分档，并输出评审人摘要、严重性 × 工作量网格、意见矩阵、回应计划和预算分配（使用 --format json 可生成机器可读的输出）。

7. 展示并交接。 先与用户逐项讨论 must-address 分档的意见，标出无法在 rebuttal_end 前完成的实验请求，并确认各项策略说明。然后将矩阵交给 write-rebuttal，按会议要求的格式起草回应。如果将开展新实验，请提醒用户在承诺之前核查会议对 rebuttal 中新结果的政策（步骤 4）。

输出

• triage.json — 结构化、已分类的意见数据（机器可读，可供 write-rebuttal 重复使用）。
• 分流矩阵报告（通过 build_matrix.py 生成 Markdown）：逐位评审人的评分摘要、严重性 × 工作量网格、按优先级排序的意见矩阵、must／should／brief 回应计划，以及逐项意见的预算分配。

两者都应保存在本地；都不得包含用户不希望保留在代码仓库中的文本 — 应将其视为机密工作文件。

适配你的学科

该解析器面向计算机科学投稿系统。对于以期刊为主的领域，请粘贴 ScholarOne/Editorial Manager 审稿意见，添加 Reviewer #N 横幅行，并使用 --format cmt 解析；将预算步骤替换为不设上限的回复信计划。该评分标准（误解 / 实际缺陷 / 要求进行的实验）不受学科限制。

防护措施

• 审稿文本属于机密：仅作临时处理，绝不提交到版本库，也绝不在公开材料（问题、示例、展示文件）中引用。
• 绝不捏造或弱化审稿意见——矩阵中的问题必须能追溯到原始审稿意见；每次引用最多一条句子。
• 未在论文中找到经过核实的依据时，绝不声称存在 misunderstanding；references/triage-rubric.md 中的诚信规则具有约束力。
• 规划回复时添加的任何引文，在用于 rebuttal 前都必须经过 verify-citations 核验。
• 在用户依赖 rebuttal 前，必须根据实时的 cfp_url 重新核验 rebuttal 的格式、限制和截止日期（步骤 4 不可省略）。
• 绝不代表用户向任何系统提交回复；流程必须止于计划阶段（使用 write-rebuttal 时则止于草稿）。