simulate-reviewers

模拟评审

在投稿前，将论文提交给模拟的、针对会议校准的评审小组。NeurIPS 主会评审和 SIGSPATIAL 演示轨评审会以不同标准、基于不同理由拒稿——本技能会复现这种差异：由评审人设驱动的弱点评查、按会议自身评分标准打分，以及确定性的录用风险解读，告诉作者趁还有时间该改进什么。

适用场景

• “评审会怎么评价这篇论文？”／“模拟一次评审”
• “像严苛的 NeurIPS 评审那样评审这篇论文”／“第二位评审会讨厌什么？”
• “这篇论文够不够投 KDD，还是应该投短文轨？”
• “在评审发现问题之前找出弱点”／“对我的投稿进行红队评审”
• preflight-check 通过后（格式无误）、投稿前——本技能评判内容，preflight 评判合规性。

输入

1. 论文：.tex 源码目录、PDF，或任何可读格式的草稿。 临时处理，绝不要将论文文本复制到仓库中。
2. 会议档案：venues/conferences/<venue>-<year>.yml（架构见 venues/schema.yml）。如果没有档案，先用 parse-cfp 创建一个，或者 使用最接近的会议类别默认值运行，并说明这一点。
3. 目标轨道（页数限制和评审预期各不相同——请询问）。

流程

1. 构建校准后的评审材料包。 运行：

   python3 scripts/review_form.py venues/conferences/<venue>-<year>.yml \
       --track "<track>"
   

   这是确定性的离线操作。它会合并会议类别档案，并输出评审小组（评审人设 + 严苛程度）、会议评分标准及其临界门槛、评分细则、每位评审人的表单框架，以及 scores.json 模板。添加 --json 可输出机器可读格式。退出代码：0 表示成功， 2 表示档案缺失／无法解析或轨道未知。

2. 根据最新 CFP 重新核实——必做。 档案和脚本中的评分标准锚点只是历史惯例，并非 绝对依据。获取档案中的 cfp_url（以及链接中的评审指南页面），核实： 评分标准和表单、匿名评审级别、答辩格式、轨道要求。 如有任何差异，更新档案 YAML，在报告中注明差异，并以最新信息为准。陈述每项会议事实时， 都要附上置信度标签和可点击的来源： verified-live／corroborated／inferred-from-family／ needs-verification。向用户引用评分数字却不提供来源，是错误，不是图省事。

3. 通读整篇论文并整理主张清单。 列出每项新颖性主张（“首次”“达到最先进水平”“优于”）、 每项实证主张，以及相应支持证据所在的位置。这份清单是评审人设攻击的目标。方法见 references/weakness-hunting.md。

4. 以各自的角色独立撰写每份评审意见。 按顺序针对材料包中的每位评审者各写一份，不要在撰写时参考其他评审意见（真实评审是彼此独立的；独立发现的相同问题才是最有力的信号）。角色行为、严厉程度校准和赛道修饰项见 references/reviewer-personas.md。依据规则——不可妥协：

   • 每份评审都要先写真诚的优点，然后再写缺点——就像真实的评审表。列出 2–4 项具体优点（论文做得好的地方：新颖性、出色的实验、清晰度、有用的工件），并像指出缺点那样，说明这些优点依据的章节或图。只有缺点的评审不是真实评审，也会误导作者，使其不知道修订时应保留什么。不要为了凑数编造优点——如果论文较弱，就如实说明，但要找出真正做得好的地方。
   • 每项缺点都要引用章节、图、行号，或引用不超过 1 句话的原文。
   • 绝不编造先前研究。如果某个角色怀疑缺少相关工作，应使用 find-papers 查找真实候选文献，并用 verify-citations 验证；或者有条件地表述这一顾虑（“如果存在关于 X 的先前研究，R4 会找到”），不要伪造引用。
   • 只有略读者角色可以出现误读，而且必须是实际文本确实可能导致的误读。

5. 先按评分标准打分，再映射到会议等级。 每位评审者都要根据 references/rubrics.md 中的评分锚点，对四个核心维度（新颖性、可靠性、可复现性、清晰度）分别按 1–5 分打分，然后映射到材料包中的会议总体等级和信心等级。严厉程度校准：严厉程度为 5 时，未解决的可靠性问题会将总体评价上限限定为边缘拒稿；严厉程度为 2 时（演示赛道），这类问题应作为疑问提出，而非设为上限。

6. 确定性地汇总。 填写第 1 步中的 scores.json 模板，然后运行：

   python3 scripts/aggregate_scores.py scores.json
   

   它会计算置信度加权平均分、分歧／支持者／反对者标记、拖累维度和决策风险区间 （很可能拒稿／边缘拒稿／边缘接收／很可能接收），并应用“没有支持者时，边缘评价向下判定”的规则。 --example 会输出有效输入示例；--json 用于机器可读输出；输入无效时退出码为 2。

7. 撰写元评审和修复清单。 以 AC/1AC/AE 的角色综合各份评审，指出最主要的共同顾虑，并说明是否存在支持者。然后将每项缺点转化为按优先级排列的修复清单，每项都要标注：

   • fix-now — 投稿前可以解决（补充消融实验、弱化论断、添加可复现性说明）；
   • rebuttal-defensible — 在该会议的 rebuttal 格式中可以应对（查看 review.rebuttal_format／个人资料中的限制）；
   • structural — 本轮无法解决；考虑改投其他会议／赛道（移交给 select-venue）。 需明确核查的边缘拒稿预测因素列于 references/weakness-hunting.md。

输出

一套以聊天形式呈现的模拟评审材料（仅在用户要求时写入文件）：

• N 份独立评审，采用会议要求的格式撰写，每份均以 优点 部分开头，接着是 缺点、问题和分项评分。
• 元评审，指出应保留的最大优点和需要解决的最大共同风险，并说明是否存在支持者。
• 评分表及 aggregate_scores.py 的决策风险输出。
• 按优先级排列的修复清单，每项均标注 fix-now／rebuttal-defensible／structural。

所有输出都必须包含免责声明：这只是旨在改进论文的模拟评审，并非对真实结果的预测。

迷你示例

一篇投稿至 NeurIPS 主会的 9 页论文。运行 python3 scripts/review_form.py venues/conferences/neurips-2026.yml --track Main 并检查实时征稿启事（已确认评审尺度和 rebuttal 格式，并标记为 verified-live）后，分别独立撰写四个角色的评审意见。逐渐出现共识：R2（实证怀疑者）和 R4（相邻领域专家）彼此没有看到对方的意见，却都发现了同一个缺口。

R2，弱点。“表 2 报告的是单次运行结果（§5.1）。若用 5 个随机种子的 ±std，领先基线的 +1.3% 差距还能保持吗？文中没有说明基线的调参预算是否一致。”——严谨性 2，信心 5。

R4，弱点。“§1 中‘首次将 X 与 Y 结合’的说法，需要考虑 2023 年关于 X-under-Y 的工作。如果存在这项工作，新颖性主张就应缩小到工程层面的差异。”（有条件——转交给 find-papers；未编造引用。）——新颖性 2，信心 4。

填写并汇总 scores.json（R1 5/4、R2 4/5、R3 6/2、R4 5/4）后得到：

conf-weighted mean: 4.8   delta vs threshold: -0.133 (normalized)
DECISION RISK:      BORDERLINE-REJECT
drag dimensions:    soundness 2.5, reproducibility 2.75
flags:              strong detractor present (R2) — objection must be rebuttal-proof

修改清单以多位评审共同发现的问题为首：fix-now — 为表 2 补充 5 个随机种子的 ±std，并说明调参预算一致性（以最低成本解决严谨性底线问题）；fix-now — 核实 X-under-Y 的相关先前工作，并据此弱化“首次”的说法。元评审指出，唯一高于门槛的分数来自信心较低的快速浏览者（没有真正的支持者），因此结果处于边缘时，倾向于向下判定，除非在投稿前解决严谨性方面的异议。

适配你的学科

评审组和评分尺度由会场的 family: 字段决定。对于其他领域，可在 scripts/review_form.py 中为你的社区创建分支并添加校准条目（角色 + 评分尺度），再添加一个 venue YAML 文件——例如，为 APA 期刊设置由负责编辑和 2 位评审组成的评审组，采用接收/小修/大修/拒稿的决定选项。

防护措施

• 切勿将模拟结果说成预测（“你的论文在 NeurIPS 会得 5 分”）。应说：“模拟评审组给它打了 X 分；真实评审组的结果差异很大。”
• 切勿编造引用、评审者身份或引文——角色仅为原型，绝不能使用真实研究者的姓名；对相关工作遗漏的指称必须通过 find-papers + verify-citations 核实，否则应保留条件性表述。
• 根据实时的 cfp_url 重新核实评审流程信息（步骤 2 不可省略）；在报告中标记任何已过时的档案信息。
• 仅临时处理论文；每项发现最多引用一句话；绝不在此仓库中存储论文文本。
• 绝不代表用户向任何评审系统提交内容或发布内容。
• 过程中发现的格式/合规问题不在处理范围内——应转交给 preflight-check。

记忆

此技能采用用户论文目录中共享的 .paper-memory/ 约定，详见 paper-memory-convention.md。

• **开始时：**读取 .paper-memory/profile.yml（领域、风险偏好、venue 级别），以校准评审组及各角色质疑新颖性主张的力度；同时读取 lessons.md，了解之前提出过哪些弱点，以及作者反复出现的 recurring 弱点（例如“消融实验薄弱”或“贡献夸大”），以便元评审重点指出这些问题。
• **结束时：**按照共享格式追加持久性弱点 - [YYYY-MM-DD] (simulate-reviewers | <scope>) weakness -> recommendation（通过 reflect-and-improve 的 reflect_log.py append 操作，该操作会去重并添加日期）。如果某种结构性习惯在多个草稿中反复出现，则标记为 recurring；如果是某一稿件特有的缺口，则标记为 this-paper。不要记录各评审者分数中的噪声。
• 如 .paper-memory/ 不存在，则按需创建，并主动询问是否将其添加到项目的 .gitignore。该目录仅保存在本地；绝不上传，也不复制到此仓库。