triage-reviews

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Triage Reviews

评审意见分类处理

Convert raw reviewer text into a structured decision artifact: every concern isolated, classified (misunderstanding / real flaw / requested experiment / clarification / disagreement), scored severity x effort, and ordered into a response plan that fits the venue's rebuttal budget. This is the planning step that runs between "reviews arrived" and

write-rebuttal

— rebuttals written straight from raw reviews bury the score-moving points under typo acknowledgments.

将原始评审文本转换为结构化的决策成果：拆分出每个独立关注点，将其分类为（误解 / 真实缺陷 / 要求补充实验 / 澄清 / 异议），对严重程度×工作量进行评分，并整理出符合会议/期刊回复字数限制的优先级回复计划。这是“收到评审意见”和

write-rebuttal

之间的规划步骤——直接基于原始评审意见撰写的回复会把能提升分数的要点淹没在对拼写错误的致谢中。

When to use

使用场景

"My NeurIPS/ICML/SIGSPATIAL/... reviews are in — help me respond"
"Triage these reviews" / "what do I address first in my rebuttal?"
"Reviewer 2 says X but the paper already covers it — how do I handle this?"
Reviews pasted from OpenReview, EasyChair, CMT, HotCRP, PCS, or a notification email
Always before
```
write-rebuttal
```
; also useful for journal revise-and-resubmit responses

“我的NeurIPS/ICML/SIGSPATIAL/...评审意见回来了——帮我规划回复”
“分类这些评审意见” / “我在回复中应该先处理哪些内容？”
“评审人2提到了X，但论文已经涵盖了这部分内容——我该怎么处理？”
从OpenReview、EasyChair、CMT、HotCRP、PCS或通知邮件中粘贴的评审意见
始终在
```
write-rebuttal
```
之前使用；也适用于期刊修改后重投的回复规划

Inputs

输入项

Raw review text in a file (e.g.
```
reviews.txt
```
): the user pastes or exports it from the submission system. Per-platform copy-out instructions and gotchas: references/platform-formats.md.

Venue profile (optional but recommended):

venues/conferences/<venue>-<year>.yml

(schema in

venues/schema.yml

) — supplies

review.rebuttal_format

review.rebuttal_limit

, and

deadlines.rebuttal_end

. If missing, run

parse-cfp

first or proceed platform-generic.

The submitted paper (
```
.tex
```
/PDF, optional): needed to verify misunderstanding claims and fill evidence anchors.

原始评审文本文件（例如
```
reviews.txt
```
）：用户从投稿系统中粘贴或导出的内容。各平台的导出说明及注意事项：references/platform-formats.md。
会议/期刊配置文件（可选但推荐）：
```
venues/conferences/<venue>-<year>.yml
```
（配置格式见
```
venues/schema.yml
```
）——提供
```
review.rebuttal_format
```
、
```
review.rebuttal_limit
```
和
```
deadlines.rebuttal_end
```
。如果缺少该文件，可先运行
```
parse-cfp
```
，或按通用平台流程处理。
提交的论文（
```
.tex
```
/PDF格式，可选）：用于验证误解类主张并补充证据锚点。

Process

处理流程

Stage the raw text — confidentially. Have the user save the reviews to a local file outside any git repository (or add it to
```
.gitignore
```
). Review text is confidential at most venues: process it transiently and never commit it.
Parse deterministically. Run:
```
python3 scripts/parse_reviews.py reviews.txt -o triage.json
```
Auto-detects the platform; force with
```
--format openreview|easychair|cmt|hotcrp
```
and catch terse one-liners with
```
--min-words 3
```
if needed. Output is a JSON skeleton: reviewers, scores, canonical sections, and per-concern entries (
```
R1.1
```
,
```
R1.2
```
, ...) with
```
classification
```
/
```
severity
```
/
```
effort
```
left null. Exit codes: 0 ok, 1 nothing detected, 2 bad input.
Verify the parse against the raw text. Confirm the reviewer count, that every weakness/question in the raw text appears as a concern, and that scores were captured. If a reviewer or concern was missed, fix the text (insert a
```
Review N
```
banner line) and re-run, or add the concern to the JSON by hand — never silently drop a reviewer point. Recovery steps: references/platform-formats.md, last section.
Resolve the venue's rebuttal mechanics — then re-verify them live. Read
```
review.rebuttal_format
```
,
```
review.rebuttal_limit
```
, and
```
deadlines.rebuttal_end
```
from the venue profile. Profiles are a starting point, never ground truth: re-verify the rebuttal format, the character/page limit, whether new experimental results are allowed, and the deadline against the live
```
cfp_url
```
(and the venue's author guidelines) before the user relies on them. State what was verified and when. If
```
rebuttal_format: none
```
, say so — triage still guides the camera-ready revision or the next submission.
Classify every concern. Fill
```
classification
```
,
```
severity
```
,
```
effort
```
,
```
evidence_anchor
```
, and a one-line
```
response_strategy
```
for each concern in
```
triage.json
```
, applying the decision tree and definitions in references/triage-rubric.md. Rules that bind:
- Claim
```
misunderstanding
```
  only after locating the refuting text in the actual paper — cite section/line in
```
evidence_anchor
```
  .
- Severity measures threat to acceptance, not reviewer tone; concerns raised by 2+ reviewers escalate one level.
- Effort measures cost to respond within the rebuttal window, not cost to fix the paper.
- Walk the user through any concern where you are uncertain; the user knows the paper.
Render the matrix. Run:
```
python3 scripts/build_matrix.py triage.json --budget <limit> --budget-unit chars
```
with the budget from the verified rebuttal limit (e.g.
```
--budget 10000 --budget-unit chars
```
for NeurIPS-style OpenReview;
```
--budget 800 --budget-unit words
```
for a CVPR one-page PDF; omit
```
--budget
```
for journal R&R). The script validates the enums (exit 1 with a list of unfilled concerns until classification is complete), computes priority scores and must/should/brief bands, and emits the reviewer summary, severity x effort grid, concern matrix, response plan, and budget allocation (
```
--format json
```
for machine-readable output).
Present and hand off. Walk the user through the must-address band first, flag any requested experiment that cannot finish before
```
rebuttal_end
```
, and confirm the strategy lines. Then hand the matrix to
```
write-rebuttal
```
for drafting in the venue's format. If new experiments will be run, remind the user to check the venue's policy on new results in rebuttals (step 4) before promising them.

保密存储原始文本。让用户将评审意见保存到本地文件，且该文件不在任何git仓库内（或添加到
```
.gitignore
```
中）。在大多数会议/期刊中，评审文本属于机密信息：仅临时处理，绝不提交到版本库。
确定性解析。运行以下命令：
```
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
```
字段初始为null。退出码说明：0表示处理成功，1表示未检测到有效内容，2表示输入格式错误。
对照原始文本验证解析结果。确认评审人数量正确、原始文本中的每个问题/疑问都已作为关注点列出，且评分已被捕获。如果遗漏了某个评审人或关注点，可修改文本（插入
```
Review N
```
标题行）后重新运行，或手动向JSON中添加关注点——绝不能静默丢弃评审人的意见。恢复步骤见：references/platform-formats.md的最后一节。
确认会议/期刊的回复规则——并实时验证。从配置文件中读取
```
review.rebuttal_format
```
、
```
review.rebuttal_limit
```
和
```
deadlines.rebuttal_end
```
。配置文件仅作为参考，绝非绝对标准：在用户依赖这些信息之前，必须对照实时的
```
cfp_url
```
（以及会议/期刊的作者指南）重新验证回复格式、字符/页数限制、是否允许补充新实验结果，以及截止日期。告知用户验证的内容和时间。如果
```
rebuttal_format: none
```
，需说明这一点——分类结果仍可用于指导最终版本的修改或下一次投稿。
对每个关注点进行分类。在
```
triage.json
```
中为每个关注点填写
```
classification
```
、
```
severity
```
、
```
effort
```
、
```
evidence_anchor
```
和一行
```
response_strategy
```
，需遵循references/triage-rubric.md中的决策树和定义。需遵守以下规则：
- 只有在论文中找到反驳文本后，才能标记为
```
misunderstanding
```
  ——在
```
evidence_anchor
```
  中引用章节/行号。
- 严重程度衡量的是对录用结果的威胁，而非评审人的语气；被2位及以上评审人提出的关注点需提升一个等级。
- 工作量衡量的是在回复窗口期内完成回复的成本，而非修改论文的成本。
- 对任何不确定的关注点，需与用户沟通；用户最了解自己的论文。
生成分类矩阵。运行以下命令：
```
python3 scripts/build_matrix.py triage.json --budget <limit> --budget-unit chars
```
其中预算值来自已验证的回复限制（例如，NeurIPS风格的OpenReview使用
```
--budget 10000 --budget-unit chars
```
；CVPR单页PDF使用
```
--budget 800 --budget-unit words
```
；期刊修改后重投可省略
```
--budget
```
）。脚本会验证枚举值（若存在未填写的关注点，会退出并返回错误码1，列出未完成分类的条目），计算优先级分数并划分“必须处理/应该处理/简要处理”区间，输出评审人摘要、严重程度×工作量网格、关注点矩阵、回复计划和每个关注点的字数分配（使用
```
--format json
```
可生成机器可读的输出）。
展示结果并移交。首先向用户介绍“必须处理”的区间，标记任何无法在
```
rebuttal_end
```
截止日期前完成的要求补充实验，并确认回复策略。然后将分类矩阵移交至
```
write-rebuttal
```
，以按照会议/期刊格式撰写回复。如果计划补充新实验，需提醒用户在承诺之前再次检查会议/期刊关于回复中补充新结果的政策（步骤4）。

Output

输出结果

```
triage.json
```
— structured, classified concern data (machine-readable, reusable by
```
write-rebuttal
```
).
A triage matrix report (markdown, via
```
build_matrix.py
```
): per-reviewer summary with scores, severity x effort grid, priority-ordered concern matrix, must/should/brief response plan, and per-concern budget allocations.

Both stay local; neither should ever contain text the user needs to keep out of a repo — treat them as confidential working files.

```
triage.json
```
——结构化的分类关注点数据（机器可读，可被
```
write-rebuttal
```
复用）。
分类矩阵报告（Markdown格式，通过
```
build_matrix.py
```
生成）：包含带评分的评审人摘要、严重程度×工作量网格、按优先级排序的关注点矩阵、“必须/应该/简要”回复计划，以及每个关注点的字数分配。

两者均保存在本地；绝不能包含用户需要保密的文本——将它们视为机密工作文件。

Adapt to your discipline

适配不同学科

The parser targets CS submission systems. For journal-centric fields, paste ScholarOne/Editorial Manager reviewer comments, add

Reviewer #N

banner lines, and parse with

--format cmt

; swap the budget step for an unbounded response-letter plan. The rubric (misunderstanding / real flaw / requested experiment) is discipline-agnostic.

解析器针对计算机科学的投稿系统设计。对于以期刊为主的领域，可粘贴ScholarOne/Editorial Manager的评审意见，添加

Reviewer #N

标题行，然后使用

--format cmt

进行解析；将预算步骤替换为无字数限制的回复信计划。分类标准（误解/真实缺陷/要求补充实验）适用于所有学科。

Guardrails

约束规则

Review text is confidential: process transiently, never commit it, never quote it in public artifacts (issues, examples, showcase files).
Never fabricate or soften reviewer text — concerns in the matrix must be traceable to the raw reviews; quote at most a sentence at a time.
Never claim
```
misunderstanding
```
without a verified anchor in the paper; honesty rules in references/triage-rubric.md are binding.
Any citation added while planning responses goes through
```
verify-citations
```
before it reaches a rebuttal.
Re-verify rebuttal format, limits, and deadline against the live
```
cfp_url
```
before the user relies on them (step 4 is not optional).
Never submit a response to any system on the user's behalf; stop at the plan (and at the draft, in
```
write-rebuttal
```
).

评审文本属于机密信息：仅临时处理，绝不提交到版本库，绝不公开引用（如在issue、示例、展示文件中）。
绝不能伪造或弱化评审文本——矩阵中的关注点必须可追溯到原始评审意见；最多每次引用一句话。
只有在论文中找到已验证的锚点后，才能标记为
```
misunderstanding
```
；references/triage-rubric.md中的诚实规则具有约束力。
在规划回复时添加的任何引用，必须经过
```
verify-citations
```
验证后才能纳入回复。
在用户依赖这些信息之前，必须对照实时的
```
cfp_url
```
重新验证回复格式、限制和截止日期（步骤4为必填项）。
绝不代表用户向任何系统提交回复；仅完成规划步骤（以及
```
write-rebuttal
```
中的草稿撰写）。