论文代码被要求开源？可复现仓库准备与声明写法指南

投SCI时被编辑要求补一份Code Availability Statement，很多人这才慌了神：代码散落在各个文件夹里，注释东一块西一块，别人拿到根本跑不起来。近年来Nature、Science及旗下子刊、IEEE大量期刊都已把代码与数据公开写进投稿政策，可复现性（Reproducibility）正在从加分项变成硬门槛。

一、先搞清楚：你的期刊要求到什么程度

不同期刊对代码的尺度差别很大，投稿前务必读一遍Guide for Authors里的相关条款：

• 强制公开型：如Nature系列，接受发表时必须提供代码与数据，并声明存放在公共仓库；
• 按需提供型：只要求写声明，说明代码「因合理请求可提供」，但审稿人可能仍会索要；
• 鼓励不强制型：多数应用类期刊目前处于这一档，公开代码会成为审稿人眼中的加分项。

一个稳妥的判断方法：去目标期刊官网翻最近半年发表的同类文章，看它们的Code Availability Statement怎么写的、代码放在哪，照着同档标准准备就不会错。

二、什么样的代码仓库才算「可复现」

审稿人或读者打开你的代码仓库，理想状态是按README走一遍就能跑出论文里的结果。准备时对照这几条：

• README是门面：写清环境依赖（Python/R/MATLAB版本、关键库及版本号）、运行顺序、每一步对应论文里的哪张图表；
• 依赖要固定：用requirements.txt、environment.yml或renv.lock把版本号锁死，「pip install装最新版就能跑」往往意味着三个月后就跑不了；
• 数据路径解耦：把示例数据放进仓库或给出公开下载入口，避免出现只有你电脑上才存在的绝对路径；
• 清理敏感与冗余：删掉API密钥、内部数据、注释掉的废代码和临时脚本，仓库干净程度直接影响审稿印象。

三、GitHub加Zenodo：让代码有个不会失效的「身份证」

期刊普遍不建议只挂一个裸的GitHub链接，因为仓库随时可能改名、删除。标准做法是GitHub加Zenodo的组合：

• 第一步：把整理好的代码推送到GitHub公开仓库；
• 第二步：在Zenodo上关联该仓库，一键生成分配DOI的版本快照；
• 第三步：论文定稿前，在GitHub打一个release（如v1.0），Zenodo会为该版本生成永久DOI；
• 第四步：把DOI写进Code Availability Statement，并在正文中以「代码可在……获取（DOI: xxx）」的格式引用。

这样一来，即使日后仓库还在继续更新，论文引用的版本快照也不会变，审稿人和读者都能精确对应到发表时的代码状态。

四、Code Availability Statement怎么写

声明本身不需要长篇大论，但要素要全：代码和数据的存放位置（附DOI或链接）、所用软件与版本、获取受限数据或部分代码的联系方式。如果确有不能公开的部分（如涉及隐私的临床数据、受协议限制的第三方代码），要明确说明原因并写明申请获取的渠道，切忌留空或含糊其辞。

五、投稿前自查清单

• 读目标期刊的代码与数据政策，确认公开层级；
• 仓库README能让人不问你任何问题就跑通主流程；
• 依赖版本已固定，示例数据可获取；
• Zenodo DOI已生成，链接在无痕浏览器里能打开；
• 声明中未出现内部路径、真实姓名邮箱以外的敏感信息。

把代码整理成可复现的仓库，前期看似多花了半天功夫，换来的是审稿人「代码清晰规范」的好印象，也省去了返修阶段手忙脚乱补材料的狼狈。选刊阶段如果还想顺带核对期刊的分区、影响因子与发表周期等数据，可以通过RDLink研发家（www.yanfajia.com）的期刊大数据工具按影响因子、中科院分区、JCR分区快速筛选比对，投稿前的功课一次做齐。了解更多论文写作与投稿服务，可访问研发家官网。