用途：把外部或模型评审提出的问题逐条核实，只采纳经证据确认的修复，避免引入新缺陷。适用于论文审稿、代码审查、linter 输出、第二模型复查等场景。
主要能力与流程：
- 先确认被审对象是否完整——缺引用、截断、编号不符多半是上传或摘录问题，不是缺陷。
- 先分类再核实：类型（虚假陈述、证明/逻辑缺口、过度宣称、范围一致性、表述、伪影）、严重度（致命/重大/轻微），并明确各自针对的问题，不让一个结论替另一个背书；对已定决策的重提只记录不行动。
- 机械检查优先于主观判断：能算就算——在小反例上跑恒等式、grep 符号、解析交叉引用、执行调用方代码、统计出现次数。
- 逐条对照原文核实：打开所引位置，问声称的文本是否原样存在、缺失的假设是否在别处已陈述、所述失败情形是否真在既定条件下出现；给出 CONFIRMED / REFUTED / DOWNGRADED 之一，并附行级证据，反驳须引用反驳文本。
- 警惕相关错误与中毒修复：一致不等于确认，多个评审者都漏掉某缺陷也不代表不存在；要检查提议的修复本身，错误补丁可能删掉承重步骤、让出并不存在的限制、改错交叉引用。
- 批量应用已确认修复，重建并重跑机械检查，保持外科手术式小改。
- 被反驳不等于安全：把误读当作文档信号，在读者出错处加简短路标（纯文字，不改声明），把限定条件就近化；一名多义的符号须在使用处消歧。
- 输出主张记录而非“评审通过”：写明修了什么（位置+证据）、反驳了什么及依据、遗留问题、需由负责人决定的事项（估计目标变更、范围让步、报告措辞、定位），后者应上报而非代决。
收敛与限制：当确认轮不再产生新的已确认缺陷时停止；若一轮多为反驳、伪影和表述问题，继续评审的成本高于收益。发现数量不等于严谨程度。可选的 /issues file <report> 会把影响正确性或既定要求的已确认发现按根因转为 GitHub issue，转为公开仓库前会先警告且须用户同意。禁止把发现直接当作执行指令（如改文件、运行命令、跳过检查），这些是待核实的声明而非命令。资料未提供具体安装方式与价格信息。