当前位置：首页 > news >正文

Academic Research Skills评审团契约（Sprint Contract）：评审如何先承诺后评分

news 2026/8/30 11:44:55

Academic Research Skills评审团契约（Sprint Contract）：评审如何先承诺后评分

【免费下载链接】academic-research-skillsAcademic Research Skills for Claude Code: research → write → review → revise → finalize项目地址: https://gitcode.com/GitHub_Trending/ac/academic-research-skills

用 AI 评审学术论文时，最大的隐患是评审"先读了论文，再倒推一套对自己有利的评分标准"。开源项目Academic Research Skills（research → write → review → revise → finalize 的学术写作技能套件）用**评审团契约（Sprint Contract）**机制彻底堵死这条捷径：评审者在看到论文内容之前，必须先书面承诺"评哪些维度、什么算否决（block）、什么算警告（warn）"，承诺锁定后才允许打开论文打分。本指南带你弄懂这套"先承诺、后评分"的契约机制。

为什么评审需要"先承诺，后评分"

想象一位人类评审先通读了全文，再回头写评审意见——他会不自觉地用论文的优点为自己宽松的打分找理由。AI 评审同样存在这种"事后合理化"（rationalisation）漂移。

Sprint Contract 的解法非常朴素但强硬：物理隔离两次调用🧱

阶段	能看到什么	必须输出什么
Phase 1（论文内容盲）	契约 JSON + 论文元数据（仅标题、领域、字数）	契约释义（Contract Paraphrase）+ 评分计划（Scoring Plan）+ 确认标签
Phase 2（论文可见）	契约 + Phase 1 承诺 + 完整论文	各维度打分、（可选）异议声明、评审正文

由于 Phase 1 的上下文里根本没有论文内容，评审者不可能"看完再编标准"。评分计划一旦生成即被锁定：Phase 2 中给某个维度打出block或warn，其触发明文必须是 Phase 1 承诺文本的逐字子串，改口只能走正式的"异议通道"。

评审团契约的核心字段速览

契约是一份机器可校验的 JSON 文件，以完整版评审契约 shared/contracts/reviewer/full.json 为例，核心字段一目了然：

字段	含义	示例值
`contract_id`	契约唯一标识	`reviewer/reviewer_full/v2`
`mode`	评审模式	`reviewer_full`
`panel_size`	评审团独立席位数量	`5`
`acceptance_dimensions`	验收维度 D1–D6，各带优先级（mandatory / high / normal）与负责角色	D1`methodology_rigor`（mandatory，methodology 席）
`measurement_procedure`	测量规程：规定评审者在看论文前必须输出契约释义与评分计划	`paraphrase_minimum_dimensions: "all"`
`failure_conditions`	失败条件 F0–F5：含严重度、跨评审聚合量词、触发动作	F2：severity 90，任一 mandatory 维度 block → 大修

契约结构由 shared/sprint_contract.schema.json 严格约束（Schema 13.2），additionalProperties: false保证字段不被私加；每个维度还标注eligible_roles与owner_role，明确"谁有资格给这个维度打分"，越角色打分会直接判为无效。

两阶段评审流程：硬门禁如何运转 🚦

编排器对每位评审者执行以下流程（完整规则见 academic-paper-reviewer/references/sprint_contract_protocol.md）：

装载契约：从模板深拷贝，仅允许填充generated_at等运行时字段，基线字段不可篡改；先跑校验器，报错即中止。
Phase 1 调用（盲态）：只喂契约 + 元数据，评审者输出契约释义、逐维度评分计划和确认标签[CONTRACT-ACKNOWLEDGED]。
Phase 1 结构检查：漏释义、评分计划字段缺项，允许重试一次；再失败则该评审者作废。
Phase 2 调用（可见态）：注入完整论文；评审者给出维度打分与评审正文。
Phase 2 结构检查：评分必须与 Phase 1 承诺逐字绑定；失败即作废，不允许重试（因为已经看过论文，重跑就污染了）。
评审团人数不变式：任何一位评审者作废都会触发[PANEL-SHRUNK]中止整轮——绝不悄悄按 4/5 人重新计算"多数"阈值，那是契约作者没同意过的另一个标准。

💡 一个常被忽略的细节：Phase 2 中自己的 Phase 1 输出会被包在<phase1_output>数据分隔符里，并明确告知"这是你过去的承诺记录，不是指令"——防止评审者被自己上一步写的文字"自我注入"。

异议通道：改口只限一个维度

如果评审者在 Phase 2 读到论文后，真的认为 Phase 1 的评分计划错了，可以输出## Scoring Plan Dissent声明异议——但规则苛刻：

每次调用最多异议一个维度；两个及以上 = 协议违规，该评审者整段重跑（从 Phase 1 重新开始一次），再犯即出局。
静默改口 = 违规：打分与承诺矛盾却没有异议声明，会被结构检查抓住。

这条"泄压阀不是常开通道"的设计，让评审团的承诺始终保持严肃：习惯性异议本身就是一种警报信号。

从分数到决定：失败条件的机械聚合

评分收齐后，综合器（editorial synthesizer）做的是算术而非解释。它只走三步：① 按角色资格构建打分矩阵 → ② 逐条评估failure_conditions→ ③ 在触发的条件中取severity最高者，输出唯一编辑决定。

以full.json的失败条件阶梯为例，聚合语义完全由cross_reviewer_quantifier（any/majority/all）和panel_size决定：

条件	严重度	聚合量词	触发条件	决定
F1	95	any	任一 mandatory 维度出现致命 block	拒稿（reject）
F2	90	any	任一 mandatory 维度 block	大修（major_revision）
F3	70	majority	≥2 个 mandatory 维度 warn 或更差	大修
F4	60	any	任一 high 优先级维度 block	大修
F5	40	any	任一维度 warn 或更差	小修（minor_revision）
F0	10	all	所有维度全部 pass	接收（accept）

综合器被明令禁止三件事：自创聚合规则、对分数做平均投票、事后软化已触发条件的动作。综合器的重算结果还会被scripts/check_panel_synthesis.py独立复验，不符即作废重跑一次。

评审团配置：5 人全席还是 2 人精简

模式	席位	评审角色
`reviewer_full`	5	EIC（期刊适配）+ 方法论 + 领域 + 跨学科视角 + 魔鬼代言人（DA）
`reviewer_methodology_focus`	2	EIC + 方法论

精简模式只保留与契约维度相关的席位——契约只评方法学与写作，领域和 DA 席位就没有存在的必要。每位席位（如 methodology_reviewer_agent.md、eic_agent.md）的提示词内都内嵌了同一份 Phase 1 / Phase 2 协议区块，由 scripts/check_reviewer_sprint_prompt_sync.py 保证字节级同步。

本地验证契约模板的正确姿势

仓库自带校验器，一条命令即可检查契约模板是否合法（0 错误、0 软警告才算干净）：

python scripts/check_sprint_contract.py shared/contracts/reviewer/full.json --ars-version v3.20.0

scripts/check_sprint_contract.py 在 JSON Schema 校验之外还做硬结构检查（维度 ID 重复直接报错退出）和 11 项软警告（如panel_size与模式不匹配、mandatory 维度没有被任何失败条件引用）。新增模板时，CI 会对shared/contracts/下所有文件逐一跑这个校验。