review-hub：面向开放产出的人机协同审阅系统
从 AI 协作中的审阅与理解问题出发，结合自动审阅、人机交互和设计推理研究，介绍 review-hub 如何将专家判断、证据复核、文档交互与反馈学习组织为一套工作流程。
更新于
机器翻译，未经作者审校。代码、公式与图片保留原样；可随时返回原文并与 AI 讨论。
摘要
生成式 AI 降低了研究报告、产品方案与文章的生产成本，也使审阅中的理解与判断问题更加突出。完整的文本并不自动提供完整的理由：审阅者仍需识别核心主张、检验关键假设、辨别证据与推断，并决定哪些问题值得进一步调查。review-hub 面向这类没有单一标准答案的开放产出，将 AI 自审、人的理解、文档内反馈和审阅标准的持续修订组织为相互连接的过程。
系统由运行在现有 agent 环境中的审阅技能、本地会话文件和文档界面组成。其设计结合了自动批评与科学核查研究、支持主动思考的人机交互研究、设计理由的结构化表示，以及 Claude Code 团队的审阅工作流。当前实现通过分方面评审、新上下文复核、可追溯的副本修改和与正文关联的追问，支持审阅者在整体理解与局部判断之间移动。本文说明这些设计的研究依据、工作机制、功能表现及实践中的调整，并提出后续评估所需检验的问题。
1. 问题背景：产出增加之后，审阅需要承担什么
在 AI 参与的知识工作中，完成一份文本与理解这份文本之间可能存在明显距离。报告可以包含完整的方法、结果和结论，却没有充分说明某项分析选择为何合理；产品方案可以覆盖常见章节，却仍未识别最需要验证的假设；文章可以语言流畅，却在论点与证据之间留下缺口。审阅因此同时涉及事实核对、专业判断与对作品结构的理解。
传统的聊天式反馈能够列出建议，但建议与原文、证据和修改之间的关系往往需要读者自行重建。批评数量增加，也会带来新的筛选工作：哪些意见成立，哪些只是另一种写法，哪些涉及尚未解决的判断？如果每次反馈只留在对话记录中，同样的审阅标准还需要反复解释。
review-hub 的最初设计将这一问题分为四个目标：在人的审阅之前完成一轮 AI 自审；帮助人建立对作品的心智模型；使反馈能够直接关联具体内容；将有用的反馈转化为后续审阅的规则。这里的心智模型，是指对作品的问题、关键选择、证据及其依赖关系的整体理解。[1]
这一定位也与代码审查研究相呼应。Bacchelli 与 Bird 对微软团队的观察、访谈和调查发现，审查除发现缺陷外，还承担知识传递、形成共同理解和探索替代方案等作用；理解代码及其变化是其中的关键困难。[2] 对开放产出而言，这提示了一项设计要求：审阅结果应帮助读者解释作品为何成立、依赖哪些条件，以及哪些地方仍有疑问。
2. 相关研究：从自动批评到人的判断
2.1 自动审阅的能力与复核需求
CriticGPT 研究通过专门训练批评模型，辅助人评价模型生成的代码。在其评估任务中，模型批评能够发现人工审阅遗漏的问题；人机组合发现的问题数量与模型单独工作相近，同时产生较少的虚假批评。研究也指出，批评模型自身会捏造缺陷。[3] 这为“生成批评之后还需要审查批评”提供了依据：审阅系统必须处理意见的可靠性，不能仅追求意见数量。
科学文献审阅进一步揭示了任务难度。SPOT 收集了 83 篇已发表论文中的 91 个导致勘误或撤稿的重要错误。在该研究的任务与判定方式下，受测模型的召回率均未超过 21.1%，精确率均未超过 6.1%；多次运行发现的错误也缺乏稳定性。[4] 这些结果限定于该数据集、当时的模型和评估设置，其设计意义在于提醒系统显式处理遗漏、误报与运行间差异。
Google 的 Paper Assistant Tool（PAT）则探索了更有组织的审阅流程：按逻辑主题划分论文，为各部分分配审阅资源，再汇总和核查意见。在其选出的 26 篇数学与计算机科学论文、29 个公式或证明错误上，单次生成与 PAT 的检测率分别为 55.2% 和 89.7%。该研究更换了判定方式，明确说明结果不能直接与原 SPOT 分数比较。[5] 对 review-hub 的启发是按专业问题分工并保留整体上下文，而非把多次独立调用产生的意见直接堆叠给用户。
另一路线是对明确规则进行机械核查。statcheck 从论文中提取符合其识别格式的统计报告，检查检验统计量、自由度与报告的 p 值是否一致。Nuijten 等人的研究在八本心理学期刊的材料中发现了大量此类不一致。[6] 这说明部分核查可以交给确定性程序，也说明检查对象必须定义准确：报告数值的一致性、分析方法是否合理、研究结论是否成立，是不同层次的问题。
这些工作共同形成了 review-hub 的分工原则：程序维护可以机械检验的约束，模型提出需要语义与专业知识的判断，复核环节检查批评的依据，人的审阅处理剩余的事实缺口与重要选择。
2.2 解释、注意力与主动思考
向用户展示更多解释，并不必然促成更独立的判断。Buçinca、Malaya 与 Gajos 在 199 名参与者的实验中发现，认知强制设计相较于简单的可解释 AI 方案减少了过度依赖，但效果最强的设计也获得了最不利的主观评价。[7] 这揭示了审阅界面的一个基本权衡：促使人停下来思考可能有价值，也会增加交互负担。
Sarkar 在《AI Should Challenge, Not Obey》中提出将 AI 视为质疑与反思的参与者，通过反论、批评和问题拓展人的思考。[8] 这是一项交互理念，而非对特定审阅工具效果的实验结论。它对 review-hub 的影响体现在“值得追问”的设计上：某个疑问即使尚不能被判定为错误，也可以通过清楚的观察与问题推进理解。
Scim 从阅读界面入手，按内容类别高亮论文中的重要段落，并允许读者调整高亮密度，以支持快速形成对论文的概括性理解。[9] 对 review-hub 而言，其启发在于把注意力提示放回文档：问题应出现在相关段落附近，并能连接到整体概览。高亮由此成为定位与理解的辅助，而不只是装饰。
2.3 如何表示选择及其理由
一份作品通常只呈现最终采用的方案，而将备选方案与选择理由留在文本之外。QOC（Questions, Options, and Criteria）以问题、选项和评价标准表示设计空间，为记录设计理由提供了结构。[10] review-hub 借鉴这一表示，并显式记录相关证据及上下游依赖，使关键选择能够被定位和讨论。
例如，“如何处理拒答样本”可以是一项研究决策：不同处理方式对应不同的分析对象，需要依据研究问题、缺失机制和已有证据比较。相反，“两组材料除实验处理外是否相同”是一个需要核实的事实前提，不应为了填满结构而人为制造选项。
Boba 将分析选择表示为可以组合的多重分析路径，并通过可视化比较不同选择下的结果、采样不确定性与模型拟合。[11] 它提示审阅应关注哪些选择会实质影响结论。review-hub 当前根据依赖关系和专业判断组织这类选择；自动执行多重分析曾属于早期设想，后来未保留在当前审阅流程中。
2.4 审阅标准也需要被修订
EvalGen 的用户研究观察到“标准漂移”：人需要标准才能评价输出，但评价具体输出又帮助人形成和修订标准。[12] 对开放产出，这一现象尤其相关。“论证充分”“建议具体”或“修改适度”等要求，常常只有面对实例时才能得到准确表达。
因此，review-hub 将审阅标准视为可以逐步修订的工作材料。一次意见被接受、否定或撤销，既是对当前作品的反馈，也是关于审阅方式的证据。系统将这些反馈整理为具体规则修改，由用户决定是否采用，而不是将所有临时回应立即固化。
3. Claude review workflow 的启发与迁移
Claude Code 团队的《How the Claude Code team does code review》是 review-hub 的直接工程启发来源。该文以人的时间和注意力为约束：让 AI 在人介入前先审阅和修正，要求意见带有具体依据，用简短的 REVIEW.md 明确失败条件，限制低价值意见与反复审阅，并利用事故和反馈改进审核者。其评估目标同时考虑人工时间与交付后的问题。[13]
review-hub 将这些原则迁移到开放产出时，作了三项调整。
首先，将交付前自审扩展为按作品情境组织的专家评审。代码中的失败常可通过测试或执行结果确认；研究报告、方案和文章则还需要判断问题是否成立、证据是否充分、选择是否合适。因此，系统在审阅开始前明确作品类型、使用目的和审核方面，再让 AI 完成一轮自审自改，将剩余判断交给人。
其次，将错误意见扩展为问题、线索与决策三类对象。开放产出中的批评不一定具有可立即执行的修复方式。证据充分的问题可以修改；尚未解决的疑问需要追问；存在合理备选的选择需要由有权决定的人作出判断。这一区分使问题的呈现方式与其认识状态保持一致。
最后，将项目规则维护扩展为对审阅框架的持续修订。反馈可以改变某项检查的适用条件、某类作品的专家问题，也可以调整批注的表达方式。修订需要保留来源与适用范围，以便下一次审阅理解规则为何存在。
这一迁移保留了对证据、噪声和审阅成本的关注，同时根据开放文本的特点调整了控制方式。当前系统允许用户跳过问题或结束阅读；自动修改保存在副本中，最终写回须经用户同意。早期设计中的持续生成时审阅、自动敏感度分析和按问题处理状态阻止签收等设想，也不能视为当前已经完整实现的功能。[14]
4. 系统架构：判断、状态与交互
review-hub 将三个职责分开：agent 负责理解与判断，确定性脚本维护会话状态，网页负责呈现文档与记录人的操作。三者通过本地文件交换信息。
这一划分使系统能够利用现有的 agent 环境。review-start、review-run、review-apply 和 review-learn 分别组织情境确认、审阅、反馈处理与规则修订；Python 脚本负责快照、编号、结构校验、记录追加和版本检查。[15] 模型需要解释批评为何成立，程序则确保相应记录能够保存、定位和检查。
一次审阅会话保留初始版本、正在审阅的副本、关键主张与决策、问题与修改记录，以及人的反馈和讨论。文本锚点结合原文摘录与上下文定位，使意见可以关联到具体位置。写入问题时，脚本检查锚点和文件证据摘录是否存在；候选意见的语义是否正确、公允，则由复核者判断。[16]
网页展示这些记录，也将人的回应写回会话。讨论由正在运行的 agent 接续处理，浏览器本身不生成模型回答。长期规则和审阅记录存放在独立工作区，便于工具升级与记录积累分别进行。文件保存在本地；模型推理是否使用云端服务，取决于宿主 agent 的配置。
5. 工作机制：从审阅计划到人的判断
5.1 按作品情境确定标准
审阅首先需要确定作品正在解决什么问题、处于什么阶段，以及用户与作品是什么关系。研究计划重在设计是否可执行、能否回答问题；研究报告还需要检验结果与解释；产品方案需要识别关键假设及验证路径。以相同的检查表覆盖这些情境，容易产生形式完整但价值有限的意见。
类型框架提供起点，具体计划再按作品调整。例如，学术报告框架围绕研究问题与定位、文献基础、研究设计、结果、分析和解读展开；每个方面包含评价标准、专家会追问的问题与常见缺陷。用户确认计划后，系统才开始审阅。
用户角色也决定后续动作。审阅自己的草稿可以涉及修改和方案选择；评价他人的论文时，系统应提出评审意见，而不能替原作者作决定。创意写作与具有明确个人口吻的文本，则采用更有限的修改策略，以保留作者的表达与意图。
5.2 分方面判断，并复核候选意见
AI 先提取核心主张及真正存在备选方案的关键决策，再按审核方面分工。每位审核者阅读整份作品，但集中处理一到两个方面，以兼顾局部深度与全文关系。支持子 agent 的宿主可以并行执行，也可以依次完成。
候选意见随后进入新上下文复核。验证者检查引用的证据，确认作者是否已经在其他位置解释相关问题，判断批评是否成立，统一严重程度，并合并重复或同源意见。新的上下文提供一次重新判断的机会；若角色使用相同模型，仍可能共享知识缺口，因此不能将多角色一致视为独立证据。
这一流程也要求记录做得好的方面。完整评价应说明作品哪些部分已有充分依据，哪些仍有缺口，使人能够形成整体判断，而非仅看到一串负面批注。
5.3 区分已成立的问题、待追问的线索与关键决策
三类对象对应不同的依据与后续动作。
| 对象 | 判断所需材料 | 后续动作 |
|---|---|---|
| 已成立的问题 | 具体原文或事实依据，以及批评成立的理由 | 在允许范围内修改，或列出所需补充工作 |
| 值得追问的线索 | 真实观察、对主要结论的潜在影响、可推进判断的问题 | 回答、讨论或继续调查 |
| 关键决策 | 实际可行的备选方案、选择标准与相关证据 | 由有权决定的人作出选择 |
以一份模型简历评估报告为例：如果结果只来自某个模型和若干职业，结论却写成所有大模型的普遍表现，就可以提出推广范围过大的问题。如果报告剔除了拒答，却没有呈现拒答在不同组中的分布，更合适的动作是追问缺失机制及其对比较对象的影响。如果材料已经支持比较多种处理方案，才进一步形成需要选择的研究决策。
这种区分使系统能够保留尚未解决的科学问题。一个有价值的问题可以指出下一步需要什么证据，而不必过早给出确定答案。
5.4 在副本上修改，保留解释与拒绝的空间
自审自改最多进行三轮。AI 根据已复核的问题修改副本，记录每处修改的原文、新文与理由；后续审阅集中检查改动及其下游影响。需要补实验或重算才能回答的问题，则保留为明确的补充要求。当前流程可以阅读代码、设计文档及已保存结果，并抽查主结论依赖的关键数字，但不执行被审项目的代码，也不重新计算结果。
用户最终看到的是修改后的作品、全部修改记录和剩余问题，可以保留或撤销修改、否定批评、补充事实或继续讨论。反馈由 agent 处理后反映到副本；最终写回前展示与初始版本的差异，并检查原文件是否发生冲突。这样，自动修改的便利与作者对内容的控制能够同时保留。
6. 功能展示：整体理解、局部追问与修改反馈
界面采用概览与正文批注两层结构。概览说明作品的主要论证、各方面的评价及决定整体判断的关键问题；正文批注处理具体位置，并通过引用与概览连接。同一问题尽量在最合适的位置完整说明，其他位置指向该说明。
以下截图来自实际运行的 review-hub 界面，使用公开合成案例人工配置演示会话，用于展示交互，不代表模型评测结果。
图 2 的阅读顺序从全文架构进入具体问题。概览可以帮助读者先理解各部分之间的关系，再决定哪些段落需要仔细检查。对于方案类作品，概览还可以组织建议的实施路径，说明应先验证什么、哪些步骤可以暂缓。
图 3 展示了观察如何转化为追问。卡片同时呈现问题依据、对结论的影响与具体问题，使用户可以在原文语境中回答或讨论。修改、建议、追问、待核实和讨论具有不同的视觉类别，严重程度另行标示，帮助读者区分问题性质与重要性。
图 4 将修改与其发生位置连接起来。读者既可以检查局部措辞，也可以结合全文判断改动是否保留原有含义。对开放文本，这一能力尤其重要：收窄一个结论、删除一句话或补充一个限定，都可能改变文章的立场与论证。
此外，review-devil 提供对话式答辩：根据作品类型选择内行提问者，围绕五到七个关键问题逐一提问、根据回答追问，并总结哪些理由成立、哪些仍有缺口。[17] 这一模式将审阅从“文本是否写到了”推进到“作者能否解释这一选择”，适合检查研究设计、产品假设或技术方案的辩护是否充分。
7. 从反馈中修订审阅本身
review-learn 在审阅结束后汇总用户的回应，包括不成立的批评、无关紧要的建议、被撤销的修改、遗漏的问题，以及对审阅方式的直接建议。随后提出具体的文本修订，说明修改对象、依据和预期效果，经用户同意后写入规则或框架。[18]
例如，多次将作者已经说明的限制重复报告为缺陷，可能意味着检查需要增加“先核对其他章节”的条件；对研究计划只检查文档是否齐全，却未识别最危险的假设，则可能需要调整专家问题。写作偏好可以进入个人规则，而关于研究有效性的要求应留在相应类型框架中。
这种学习发生在可读、可修改的规则中，不涉及模型权重训练。规则变更保留接受或拒绝的记录，便于之后检查其来由。阅读活动也可以提供辅助线索，但需要结合具体内容解释：停留很久可能表示困惑或认真思考，没有打开批注也可能只是时间不足。
规则更新的目标是减少误报与低价值打扰，同时补足遗漏。用户同意比例上升并不足以证明审阅质量提高；如果系统为了获得同意而逐渐减少挑战，就会偏离设计目标。因此，当前学习流程要求通过收紧适用条件处理误报，而非简单取消相关检查。
8. 实践中的设计调整
8.1 将计算复现与专家审阅分开
最初方案包含读取数据和日志、重跑分析及敏感度检查。实际试用中，大体量日志复制与多个审核者同时重算造成了明显的资源负担，也暴露出任务定位问题：重复计算占用了工作量，却未必触及研究设计与解释中的关键疑问。[14:1]
当前版本因此将审阅集中在专业判断与必要的证据对照上。计算复现仍有独立价值，但需要另行组织资源、执行环境与验证任务。这样的分工使审阅可以明确提出“需要补做什么检验、它能够区分什么解释”，并让后续核验回答具体问题。
8.2 从内部一致性推进到证据是否充分
Freedman 在《Statistical Models and Shoe Leather》中通过科学调查与统计建模的案例，强调良好的研究设计、相关数据和在现实情境中检验推论的重要性。[19] 这一阅读直接推动了 review-hub 后续的设计调整：不仅检查陈述是否与结果表一致，还要追问证据是否确立了结论。
由此形成的“线索”机制关注反常结果、尚未检验的推论和未排除的竞争性解释。这些问题的价值在于引导下一步调查，不能通过文字修改直接消除。它们与事实错误分别记录，使审阅能够同时支持纠错与探究。
8.3 保留思考支持，取消强制阅读步骤
早期设计尝试在显示结果前要求用户作出预测，以促使独立判断。当前版本取消了这一闸门，改用可选择回应的高亮、问题与讨论，也允许用户在尚有未处理问题时结束审阅。
这一变化是在交互负担与主动思考之间作出的设计取舍。认知强制研究揭示的权衡仍然存在，但当前选择是否更适合长篇开放产出，需要在真实任务中比较。可选择的交互能否支持足够深入的理解，是后续评估的重要问题。
9. 讨论与评估方向
review-hub 当前提供了一套可运行的审阅组织方式：情境化标准约束评审内容，复核流程筛选意见，文档界面连接整体理解与局部判断，反馈机制持续修订规则。其主要价值主张，是让审阅围绕证据、选择和未决问题展开，并使修改与判断过程可以追溯。
目前的实现与合成试跑可以支持对这些机制的检查，但还不足以估计真实任务中的准确率、节时效果或理解改善。早期试跑还包含后来取消的重算与预测流程，不能直接代表当前版本。主要风险包括专业知识缺口、多个审核者共享错误、反馈样本的选择性，以及自动修改改变作者意图。[20]
后续评估需要同时回答三个问题：意见是否可靠，人的判断是否得到帮助，收益能否随使用积累。可在相近的真实任务上比较原有人工流程、只提供 AI 文字意见的流程，以及完整的 review-hub 流程；按体裁、长度与难度分层，并平衡任务顺序和熟悉程度。
评价指标应包括主动审阅时间、经独立判定的问题与修改质量、交付后发现的遗漏，以及对核心假设和适用边界的解释能力。长期规则更新则应在未参与规则形成的新任务上检验，避免将对旧材料的熟悉误认为泛化能力。
这些指标共同对应项目最初的目标：在质量保持的条件下，降低同类任务所需的审核时间与重复反馈。后续工作将围绕问题质量、证据连接与规则更新展开，并通过真实任务检验这套协作机制能否稳定支持人的专业判断。
项目代码、安装方式与设计记录见 review-hub GitHub 仓库。本文实现说明对应仓库版本 5abd6f9。
参考文献与项目资料
Yuxin. Review Engine：人机协同审核系统设计. 2026-10-21。最初方案。 ↩︎
Alberto Bacchelli and Christian Bird. Expectations, Outcomes, and Challenges of Modern Code Review. ICSE, 2013. ↩︎
Nat McAleese et al. LLM Critics Help Catch LLM Bugs. arXiv:2407.00215, 2024. ↩︎
Guijin Son et al. When AI Co-Scientists Fail: SPOT—a Benchmark for Automated Verification of Scientific Research. arXiv:2505.11855, 2025. ↩︎
Rajesh Jayaram et al. Towards Automating Scientific Review with Google's Paper Assistant Tool. arXiv:2606.28277, 2026，§2.1、表 2。两种流程的比较基于该文选定的子集与判定方式。 ↩︎
Michèle B. Nuijten, Chris H. J. Hartgerink, Marcel A. L. M. van Assen, Sacha Epskamp, and Jelte M. Wicherts. The Prevalence of Statistical Reporting Errors in Psychology (1985–2013). Behavior Research Methods, 48, 1205–1226, 2016；2015 年在线发表。 ↩︎
Zana Buçinca, Maja Barbara Malaya, and Krzysztof Z. Gajos. To Trust or to Think: Cognitive Forcing Functions Can Reduce Overreliance on AI in AI-Assisted Decision-Making. Proceedings of the ACM on Human-Computer Interaction, 5(CSCW1), 2021. ↩︎
Advait Sarkar. AI Should Challenge, Not Obey. arXiv:2411.02263, 2024. ↩︎
Raymond Fok et al. Scim: Intelligent Skimming Support for Scientific Papers. IUI, 2023；预印本首次发布于 2022 年。 ↩︎
Allan MacLean, Richard M. Young, Victoria M. E. Bellotti, and Thomas P. Moran. Questions, Options, and Criteria: Elements of Design Space Analysis. Human–Computer Interaction, 6(3–4), 201–250, 1991. ↩︎
Yang Liu, Alex Kale, Tim Althoff, and Jeffrey Heer. Boba: Authoring and Visualizing Multiverse Analyses. IEEE Transactions on Visualization and Computer Graphics, 2021. DOI: 10.1109/TVCG.2020.3028985. ↩︎
Shreya Shankar, J. D. Zamfrescu-Pereira, Björn Hartmann, Aditya G. Parameswaran, and Ian Arawjo. Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences. UIST, 2024. ↩︎
Addy Osmani, Morgan Westlee Lunt, and Qing Wang. How the Claude Code Team Does Code Review. claude.dev, 2026-10-15。团队工程实践记录。 ↩︎
review-hub. review-run、review-start、review-apply。 ↩︎
review-hub. review-devil。 ↩︎
review-hub. review-learn。 ↩︎
David A. Freedman. Statistical Models and Shoe Leather. Sociological Methodology, 21, 291–313, 1991. ↩︎
review-hub. 合成产出上的端到端试跑记录. 2026-10-22。 ↩︎