什么才是可复现的科研计算交付

1. 先把“重复、复现、复核”说清楚

术语在不同学科中常被反向使用，交付前应附操作性定义。本文把可重复（repeatability）定义为原团队用同一批研究对象和受控条件再次运行；把计算可复现（computational reproducibility）定义为另一位操作者使用原输入、代码、步骤和分析条件获得一致结果；把使用独立采集的新数据或新研究回答同一科学问题称为独立重复验证（replicability）。[1] 可复核不是统一国际术语，本文仅指审阅者能够检查输入、来源、关键决策、日志和图表血缘，即使因隐私、许可证、商业软件或算力限制而无法完整执行。可重复成功不能自动证明可复现；可复现同一计算也不能证明模型正确或科学结论能被新数据重复验证。

2. 交付单位应是证据图，而不是结果文件夹

一个 PDF 只能陈述结论，不能说明某张图由哪个输入、提交和参数产生。W3C PROV 用实体、活动和责任主体描述“什么被什么过程、由谁生成”；RO-Crate 用 JSON-LD 将数据、方法、软件、人员和结果组织为可交换研究对象。[5,6] 最低血缘应能回答输入来源、消费步骤、生成物、执行/审核者，以及失败或人工干预。文件结构与 README 服务于人读；manifest、校验和与结构化 provenance 服务于机器检查。

3. 数据必须可识别，转换必须可追溯

“data/ 目录已附”仍不够。输入清单应记录对象标识、来源和日期、版本/数据库发布号、格式、大小、SHA-256 等校验值、许可与访问级别，并将原始输入设为只读。清洗、筛选、单位换算和手工修订应由脚本或变更表生成，不能覆盖原文件。FAIR 不等于无条件公开；受控数据可以保留可发现元数据、申请路径和授权规则。[2,3] 无法移交的数据至少应提供可验证清单、责任方、保留期和去标识化或合成测试样本。

4. “代码可见”不等于“使用版本可定位”

代码应锁定提交哈希或签名发布版，而不是只给会变化的仓库首页；脚本、补丁、子模块、模型权重和参考数据库要分别标识。README 说明入口、参数和失败处理，LICENSE 说明复用边界，CITATION.cff 或等价元数据说明如何引用。版本化 DOI 适合发现与引用，内容寻址的 SWHID 可指向确切源码对象，两者互补。[8,9] 软件论文和软件名称都不能代替所用版本及其身份。

5. 环境锁定要覆盖“解析结果”，不只是一串版本号

Python 3.x + package list 不能说明传递依赖、系统库、编译器和构建选项。至少应保留锁文件或环境导出、操作系统/架构、CPU/GPU、驱动、加速库、线程数、随机种子和精度。容器可提高隔离和迁移性，但浮动标签、未锁定软件源、缺少 recipe 或镜像摘要仍会漂移。[10,11] 更强方案同时保存构建配方、基础镜像 digest、包锁、镜像/二进制归档与测试命令；Guix/Nix 可记录更完整的构建图，仍受硬件、上游存档和维护能力限制。[12]

7. 归档、引用和独立复跑共同构成“完成”

Git 仓库是协作空间，不天然等于长期归档。冻结时应创建不可变发布包，记录版本、作者、许可、关联论文/数据和持久标识，并链接代码、数据、工作流、环境、日志和结果。大文件可分层保存，但须保留资产清单、位置、校验值和删除策略。随后由未参与开发的人在干净环境复跑并提交差异报告；此前只能称“为复现做了准备”。复跑记录仍须注明日期、平台、输入、容差和覆盖范围。

L0：最低可复核包——任何正式项目都应具备

• README 写明研究问题、范围、目录、入口、负责人、已知限制与支持窗口。
• 输入 manifest 含来源、版本/日期、许可/权限、大小、格式和校验值；原始输入不被覆盖。
• 代码固定到提交或发布版；参数、配置、种子、人工步骤和图表生成代码可定位。
• 保存实际命令、时间、资源、软件/硬件身份、stdout/stderr、退出状态和异常处置。
• 原始/关键中间输出、最终表格与图、解释和“不支持哪些结论”一并交付。

L1：可再运行包——由原团队在干净环境重复

• 提供单一入口或工作流 DAG、相对路径、依赖锁文件、环境配方和容器 digest。
• 附最小测试数据、预期输出、schema/完整性检查及数值或统计验收容差。
• CI 或隔离环境完成一次 smoke test；失败时能定位到输入、步骤、环境或资源层。

L2：可移交包——面向另一操作者或机构

• 版本化归档具有 DOI、SWHID 或机构持久标识；版本、作者、许可和软件引用元数据完整。
• 数据、代码、环境、工作流与每次运行通过 RO-Crate/PROV 或等价 manifest 互相链接。
• 受限资产有申请流程、责任方、替代测试数据和“开放至何种粒度”的说明。

L3：经独立复现的包——高风险决策或正式发布

• 未参与开发的复核者在声明的平台和日期执行，保留复跑日志与环境身份。
• 按预先定义的逐位、数值或统计容差比较关键结果，并公开差异与未覆盖步骤。
• 指定维护者、依赖/安全更新策略、保留期限与再验证触发条件；不承诺永久可运行。

常见误区

• 误区: “代码上传 GitHub 就可复现” · 更可靠的判断: 仓库地址没有锁定输入、提交、环境、运行记录和归档版本。
• 误区: “有 Docker 镜像就不会变化” · 更可靠的判断: 还需 digest、构建配方、锁定源、宿主/硬件说明和镜像归档。
• 误区: “固定随机种子就一定逐位一致” · 更可靠的判断: 并行调度、GPU 内核、编译器和浮点次序仍可能改变结果；应定义科学容差。
• 误区: “FAIR 就必须公开所有数据” · 更可靠的判断: FAIR 允许认证和授权；受限数据仍需元数据、申请路径和责任边界。
• 误区: “日志只保留成功命令即可” · 更可靠的判断: 失败、重试、警告和人工干预往往决定最终结果，也属于 provenance。
• 误区: “相同图形证明独立重复验证” · 更可靠的判断: 同数据同代码的复跑只支持计算可复现，不等于新数据/独立实现支持科学结论。

结论

真正可复现的科研计算交付，把“结果”升级为一条可检查、可执行、可归档的证据链。最低包让人知道发生了什么；可再运行包让原团队脱离个人电脑；可移交包让另一机构找到并理解全部研究对象；只有经过独立复跑和差异记录，才应标记为“已复现”。最专业的承诺不是“永久一键复现”，而是清楚说明谁在何时、用什么输入与环境、按什么容差验证了哪些结果，以及哪些步骤仍受数据、模型、算力或制度边界限制。