中文 · English
Get Started · View Report · How It Works
ClaimCheck 审查科研论文与公开代码之间的一致性。它固定论文版本与 repository commit，把论文中的实现声明拆成可核查的 claims，再沿真实代码路径寻找定义、构造、调用和最终科学输出，形成可以逐条回查的证据链。
一次 audit 主要回答这些问题：
| 检查范围 | 具体问题 |
|---|---|
| 核心方法 | 论文描述的模块、公式、损失函数和训练逻辑是否进入活动代码路径 |
| 科学细节 | 符号、固定常数、归一化、reduction、operation order 是否一致 |
| 数据与实验 | dataset、split、dimensions、随机性、训练阶段和 evaluation setting 是否一致 |
| 代码可达性 | 某个定义是否被真正构造、调用，并最终影响 loss、prediction 或 metric |
| 开源完整性 | 数据、checkpoint、训练入口、评估入口和环境信息是否公开且可追溯 |
| 风险信号 | placeholder、dummy、fallback、常量输出、未应用 checkpoint、循环内 RNG reset 等模式 |
ClaimCheck 的代码追踪路径是：
配置 → 定义 → 构造 → 调用 → 下游使用 → loss / prediction / metric
每个重要结论都会绑定论文原文、论文位置、代码路径、精确行号和对应代码片段。
通用 coding / research Agent 可以阅读论文、浏览仓库并给出即时判断。ClaimCheck 为 paper–code audit 固定了输入版本、审查路径、覆盖要求和证据格式，使同一类任务能够按照稳定的协议执行，并保留完整的复核依据。
| 直接让通用 Agent 审核 | ClaimCheck | |
|---|---|---|
| 任务目标 | 根据当前 prompt 理解代码、解释实现或寻找问题 | 专门核对论文中的科学声明与公开实现 |
| 输入版本 | 由当前会话和 Agent 自行确定 | 固定论文版本与 repository commit |
| 论文声明 | Agent 在阅读过程中自行概括 | 先冻结可证伪 claims，并保存逐字 quote |
| 代码审查 | 按当前问题自由浏览仓库 | 同时执行 Claim-guided 正向审查与 Code-first 反向审查 |
| 科学覆盖 | 取决于 prompt 和当次审查路径 | 强制覆盖 Equation、Parameter、Dataflow、Experiment |
| 缺失判断 | 由 Agent 根据搜索结果形成判断 | 记录检索范围、未闭合路径和 falsification boundary |
| 证据格式 | 以对话中的解释为主 | 保存 paper quote、code path、精确行号和代码片段 |
| 结果复核 | 依赖当次上下文 | 证据绑定固定输入，并经过机械 validation |
| 代码执行 | 取决于 Agent 和运行环境 | 默认静态审查；runtime verification 需要明确授权 |
ClaimCheck 的重点是把一次 paper–code review 变成结构化、可重复、可回查的审查流程。通用 Agent 仍负责语义理解和代码推理，Skill 负责约束审查边界、证据要求和最终交付格式。
一次完整审查会生成研究者可读的 HTML memo。报告先给出总体判断和复现边界，再展示关键 finding 的论文证据与代码证据。
展示内容为完全虚构的 synthetic demo，不针对任何真实论文、作者或研究团队。
关键 finding 会直接并排展示论文原文与活动代码：
每条 finding 包含论文原文与位置、代码文件与精确行号、对应代码片段，以及差异对方法或实验结论的影响说明。
查看更多报告界面
资源表单独记录数据、checkpoint、环境和公开入口，便于区分实现一致性与复现条件。
需要 Python 3.10+、Git，以及一个能够读取并遵循 SKILL.md 的 coding / research agent。
安装基础 PDF 解析依赖：
python -m pip install pypdf然后把论文和仓库交给 Agent：
请按照 SKILL.md 审查这篇论文与其官方代码仓库的一致性。
论文：<PDF / arXiv / 标题>
仓库：<GitHub URL 或本地路径>
通过 ClaimCheck 的 deterministic renderer 生成 audit-report.html 和 audit-summary.md；不要手写或重做报告 HTML/CSS。
只提供论文或仓库其中一项时，工作流会先执行 source discovery；正式审查在论文版本与 repository commit 都固定后开始。
我们使用同一篇论文（Towards Universal Mesh Movement Networks, arXiv:2407.00382v4）对不同模型进行了端到端 ClaimCheck 测试。基于最终报告的科学问题召回、误报控制、coverage 完整性和整体可用性，目前观察到的排序如下：
| 排名 | 模型 | 当前观察 |
|---|---|---|
| 1 | GPT-5.6 Sol High | 综合表现最好；能够抓住关键公式/实现差异，同时对边缘问题较克制，适合作为默认高质量审查模型。 |
| 2 | Claude Opus 5 | 代码追踪和问题召回最强，能继续挖出更多潜在差异，但更容易产生偏激进或边缘性的 finding，且成本更高。 |
| 3 | GPT-5.6 Terra High | 判断相对谨慎，但本次运行的 claim / scientific coverage 明显较少；该次测试还锁定了不同的 repository commit，因此该名次仅作参考。 |
| 4 | DeepSeek V4 Pro | 能完成完整流程，但在本次样例中漏掉了已知关键差异，同时产生了更多弱相关 finding，整体稳定性较低。 |
这是一组单论文、单次运行的初步结果，用于说明不同模型在长程 Agent 审查中的行为差异，不应视为通用模型排行榜，仅供参考。
ClaimCheck 本身不绑定特定模型，但它属于长程、多阶段、强约束的 paper–code audit 工作流。一次完整审查需要模型持续遵循 SKILL.md 中的阶段顺序，在论文 claim、代码调用链、scientific coverage、verifier 与最终报告之间保持一致的状态，并正确使用多组本地工具。因此，不同模型在长上下文理解、跨阶段指令保持、工具调用规划和科学推理上的稳定性差异，会直接影响最终 finding 的完整性与准确性。
为获得更稳定的结果，建议优先使用具备较强长程指令遵循、代码追踪和推理能力的模型。其他兼容 Agent 仍然可以运行 ClaimCheck，但在复杂论文、较大仓库或较长审计流程中，可能需要更多 validation / retry 才能达到同样的协议一致性。ClaimCheck 会尽可能通过结构化模板、stage validator 和 deterministic renderer 降低模型差异带来的影响，但语义判断本身仍由所选模型完成。
在当前 UM2N 样例与测试环境下，一次完整审查通常约需 25–35 分钟。本次 GPT-5.6 Sol High 完整运行约消耗 7% 的 Codex 周额度。这两个数字均为经验值，实际耗时与额度消耗会随论文长度、仓库规模、模型配置、缓存命中率和 validator retry 次数变化。
flowchart LR
A[论文 + 固定 repository commit] --> B[冻结可证伪 claims]
B --> C1[Claim-guided 正向审查]
B --> C2[Code-first 反向审查]
C1 --> D[Scientific coverage]
C2 --> D
D --> E[机械证据校验]
E --> F[Verifier]
F --> G[Deterministic renderer]
G --> H[Report provenance validation]
H --> I[HTML 审查报告]
整个 workflow 分成六个阶段。
1. 固定论文与代码版本。 记录唯一论文版本、PDF hash 或 URL，以及 repository commit SHA，保证所有证据对应同一份输入。
2. 冻结论文 claims。 在代码审查开始前提取最小、独立、可证伪的实现声明，并保存逐字 quote。Equation 标签只用于明确公式/数学表达；freeze_claims.py 会同时检查 quote 和 claim schema。
3. 生成 claim-aware 模板并执行正向审查。 create_semantic_templates.py 会按 frozen claim/tag 预生成 coverage item、claim ID 与论文 quote/locator，Agent 只需要补代码证据和科学判断，再从每条 claim 追踪配置、定义、构造、调用和最终 sink。
4. 执行反向审查。 独立检查 data_pipeline、model_construction、objective、optimization、inference、evaluation、checkpoint 和 output_use，发现代码侧的重要行为与论文披露情况；只有能够追到活动科学 sink 或论文预期的路径才进入 candidate。
5. 建立并逐阶段校验 scientific coverage。 Equation、Parameter、Dataflow 和 Experiment 四类信息统一进入 coverage ledger；validate_semantic_stage.py 会在 forward / reverse 完成后立即检查 schema、claim linkage、frozen paper evidence 和代码行证据，避免错误拖到 merge 阶段才暴露。
6. 汇总并生成报告。 verifier 只保留有材料性的 finding；静态模式没有重跑精确指标、公开数据没有实际下载、无关 dead code 等情况不会自动降级总判断。最终 HTML 只能由 scripts/build_report.py 使用 assets/audit-report.template.html 生成，并由 scripts/validate_report.py 校验 renderer provenance、template fingerprint、关键 DOM 和 canonical rendering。
完整执行协议见 SKILL.md，角色边界与 verifier 约束见 references/pass-contracts.md。
一次完整 audit 强制覆盖四类科学信息，并单独记录复现资源：
| 范围 | 重点 |
|---|---|
| Equation | 正负号、固定常数、归一化、reduction、operation order |
| Parameter | 初始化、sharing、trainability、optimizer membership、输出依赖 |
| Dataflow | 输入来源、中间表示、branch / fusion、调用链、最终 sink |
| Experiment | dataset、split、dimensions、hyperparameters、training stages、metrics |
| Resources | source code、data、checkpoint、environment、训练与评估入口 |
最终用户报告使用固定的研究者可读结论，例如“基本对应”“部分对应”“细节有出入”或“证据不足”。Agent 内部的 candidate、accept、reject、merge 等流程状态保留在内部 artifacts 中。
不同 Agent 可以产生不同的 findings、reasoning 和 evidence discovery。ClaimCheck 固定审计协议、结构化 artifact schema、机械 validation、verifier 交接、report renderer、页面结构与 CSS。换用 Claude、DeepSeek、GPT、Gemini 或其他 Agent 时，科学判断可以变化，最终报告 UI 仍由同一套 renderer 控制。
ClaimCheck 默认使用静态审查：读取论文、仓库、配置与元数据，建立实现路径和证据链。Runtime verification 在用户明确授权并具备合适隔离环境时执行。
- 固定版本：所有结论绑定唯一论文版本与 repository commit。
- 静态优先：默认流程聚焦源码、配置、数据流和资源可获得性。
- 缺失结论需要检索边界：absence finding 必须记录足够完整的搜索范围和可证伪边界。
- dummy / bypass 需要执行证据：静态 scanner 生成 suspected lead；confirmed 状态需要真实 execution evidence。
- 资源单独建模：checkpoint、dataset 和 environment availability 作为复现条件独立记录。
主要交付物是：
run/
├── audit-report.html # 面向研究者的完整报告
├── audit-summary.md # 简洁结论
└── ... # claims / evidence / coverage / verifier artifacts
audit-report.html 用于阅读结论和证据。它由 scripts/build_report.py 从结构化 artifacts 确定性生成，并携带 renderer/template provenance；scripts/validate_report.py 会拒绝手写、改版或 template/version 不匹配的 HTML。JSON artifacts 保存论文 quote、代码行号、覆盖范围和 verifier 决策，支持机械回查与后续复核。
- Python / PyTorch 的专项静态规则最完整，JAX、TensorFlow、C++、MATLAB、R 的框架专项支持仍在扩展。
- factory / registry / dynamic import 的 reachability 可能需要人工扩展搜索。
- Hydra / OmegaConf 等复杂配置继承还需要更深入解析。
- optimizer parameter-set 与 frozen parameter tracing 仍有自动化空间。
- 一次 audit 聚焦论文—代码一致性与复现边界，完整复现实验属于更高成本的独立任务。
开发、测试与项目结构
python -m pip install pytest
python -m pytest -q回归测试覆盖 quote 回查、evidence 行号、frozen-claim drift、reverse inspection completeness、dummy execution evidence、benchmark label isolation、notebook semantic view、dataset constructor mismatch 与 iterative RNG reset 等关键约束。
python scripts/build_readme_demo_report.py
python scripts/capture_readme_media.py第一条命令用 production HTML template 构造 synthetic demo；第二条命令用 headless Chromium 生成静态截图、GIF 和 animated WebP。详细方案见 docs/readme-media-plan.md。
.
├── SKILL.md # Agent 审查协议
├── scripts/ # deterministic tooling、validators、report builders
├── assets/ # schemas、HTML template、branding、README media
├── references/ # workflow / safety / coverage / evaluation contracts
├── examples/ # synthetic public demo
├── tests/ # regression tests and fixtures
└── benchmarks/ # development benchmark tooling/material
研究背景与致谢
ClaimCheck 是独立开发的项目，开发思路受到两个方向的启发：
- Feynman paper audit workflow 展示了 paper-to-code audit 作为研究 Agent 核心能力的工作方式。
- SciCoQA: Quality Assurance for Scientific Paper–Code Alignment 系统化研究了 scientific paper–code discrepancy，并提供真实案例支持这一问题的研究。
ClaimCheck 在开发与回归阶段使用过 SciCoQA 公开案例。查看标签后的案例仅用于 label-informed regression，不用于未见样本 benchmark 成绩。
ClaimCheck 与 Feynman、SciCoQA 及其作者或所属机构均无官方关联。
在花一天复现论文之前，先花几分钟确认作者究竟公开了什么。