技能 数据科学 学术研究可复现性与数据可用性指南

学术研究可复现性与数据可用性指南

v20260724
cjc-artifact-evaluation
本指南为学术论文作者提供全面的指导,说明如何在投稿中主动提供可复现的代码、数据集和实验脚本。即使目标期刊缺乏正式的制品评审徽章,通过规范化地提交这些可验证的“制品”,可以极大地增强研究结论的透明度和可信度。
获取技能
130 次下载
概览

《计算机学报》代码与数据可用性

先说清现状:《计算机学报》(Chinese Journal of Computers, CJC) 目前没有像国际计算机会议 (例如 ACM/USENIX 系列的 Artifact Evaluation、Available/Functional/Reusable/Reproduced 徽章) 那样独立、强制的制品评审(artifact evaluation)流程与徽章体系(截至 2026-07-09 的核验,本刊未 公开此类专门轨道,属 待核实 是否会新增)。这并不意味着可用性不重要——恰恰相反,作为 CCF A 类 综合性中文月刊,CJC 以原创长文为主,外审专家会实质性审查方法与实验的可信度。因此本技能的定位是: 在没有正式徽章制度的前提下,主动、规范地提供可复现的代码与数据,把可用性做成稿件的加分项与 外审信任的来源。

一、为什么在没有徽章时仍要认真做

  • 外审专家对"只报数字、无法核验"的实证结论天然存疑;提供可运行制品能显著降低被质疑的风险。
  • 计算机学科的系统、算法、数据挖掘、机器学习类工作,其贡献往往内嵌在可运行的代码里;开放制品 让贡献可被复用、被引用、被后续工作站在其上。
  • 修回阶段若被要求补实验或核对数据,一份组织良好的制品能让你快速响应(见 cjc-author-response)。

二、可随稿提供的制品清单

制品 内容 说明
源代码 方法/系统实现、基线实现 附 README、依赖清单、构建与运行说明
数据集 训练/测试数据或其获取脚本 自采数据说明采集方式;第三方数据给出出处与许可
实验脚本 复现表格与图的一键脚本 脚本与论文中的表号图号一一对应
配置与随机种子 超参数、环境、随机种子 保证结果可稳定重现
环境说明 依赖版本、硬件、OS 建议给出容器化(Docker)或环境文件

三、稳定托管与访问方式

  • 优先托管到能长期访问、可获得永久标识的平台:如可分配 DOI 的归档仓库(Zenodo/figshare)、 或稳定的代码托管(GitHub/Gitee) + 打 release tag 固定版本。
  • 固定版本:论文对应的是某一次提交/发布,记录 commit SHA 或 release 版本号,避免"主分支已变、 复现对不上"。
  • 记录访问方式与访问日期,在正文可用性声明中给出(见下)。
  • 若数据涉及隐私、商业机密或伦理限制无法公开,如实说明原因与替代核验途径(如可申请获取、提供 脱敏子集),不要留空。

四、正文中的可用性声明写法

在论文合适位置(脚注、致谢或专门小节)给出简明声明,例如:

本文的实现代码、实验脚本与(可公开的)数据集已托管于 <稳定链接/DOI>,对应版本 <tag/commit>,
以便复现本文表 X—表 Y 与图 Z 的结果;因 <隐私/许可> 原因,<某数据> 不便公开,可依 <途径> 获取。

注意:投稿评审阶段若本刊沿用作者信息删除的双盲式外审,链接与仓库应避免直接暴露作者身份(见 cjc-submission 的匿名注意与 cjc-reproducibility)。

五、自评清单(模拟外审视角)

  • 干净环境中按 README 能否从零构建并运行?
  • 一键脚本产出的数字能否对上论文表图?误差在合理范围?
  • 依赖是否固定版本、随机性是否受控?
  • 数据来源、许可与预处理是否交代清楚、可追溯?
  • 敏感数据的不可公开部分是否已说明并给出替代核验?
  • 制品是否固定到与论文对应的版本号?

六、与国际会议徽章制度的差异(供作者定位)

维度 国际会议 artifact evaluation 《计算机学报》现状
是否独立评审轨道 有,专门 AE 委员会 无独立徽章轨道(待核实 是否新增)
徽章 Available/Functional/Reusable/Reproduced 无正式徽章
作者动作 按 AE 规范提交、被独立评审 自愿提供,服务于外审信任与复用
侧重 制品可运行/可复现的独立认证 支撑长文实证结论的可信度

七、需向编辑部确认的易变项

  • 本刊是否新增了代码/数据可用性的强制要求或专门材料通道(待核实)。
  • 补充材料/多媒体附件的接收方式与容量限制(见 cjc-supplementary)。

八、推荐的制品目录结构

一个便于外审快速上手、便于复用的仓库骨架示例:

artifact/
├── README.md            # 概览、环境、构建、复现表图的入口说明
├── LICENSE              # 开源许可(见下)
├── requirements.txt     # 或 environment.yml / Dockerfile
├── src/                 # 方法与基线实现
├── data/                # 小数据或下载脚本(大数据走稳定托管)
├── scripts/
│   ├── run_all.sh       # 一键复现总入口
│   ├── table6.sh        # 对应论文"表6"
│   └── fig3.sh          # 对应论文"图3"
├── configs/             # 超参数与随机种子
└── results/             # 复现产物落地位置

README 至少写清:一句话简介、依赖与环境、如何构建、如何一键复现主结果、各脚本对应的表图、 预计运行时间与硬件要求、数据来源与许可、以及不可公开部分的说明。

九、开源许可选择

  • 代码常用 MIT/Apache-2.0/BSD(宽松)或 GPL(传染性);据复用意图与所依赖库的许可兼容性选择。
  • 数据集注明许可与来源;第三方数据遵守其原始许可,不得擅自二次分发受限数据。
  • 在 README 与正文可用性声明中标明许可,避免"能下载但不知道能否使用"的灰色地带。

十、随修回快速响应的价值

如果外审在退修中要求补实验或核对某个数字(见 cjc-review-processcjc-author-response), 一份组织良好、可一键运行的制品能让你在修回期限内快速产出新结果、并在答复信中给出可核验的表图, 显著提升修回效率与可信度。这也是在没有正式徽章制度时,认真做制品的直接回报。

十一、自查清单

  • 目录结构清晰、README 覆盖构建与复现?
  • 每个主表主图有对应脚本?
  • 环境/依赖/种子固定?
  • 许可明确、第三方数据合规?
  • 制品固定到与论文对应的版本(tag/commit)?
  • 评审阶段仓库已去作者身份?

输出格式

[制品清单] 源代码/数据/脚本/配置/环境 —— 齐备情况
[托管] 平台___;永久标识(DOI/tag/commit)___;访问方式与日期___
[可用性声明] 正文位置___;不可公开部分是否说明替代途径?是/否
[匿名] 评审阶段仓库是否规避作者身份暴露?是/否
[自评] 干净环境复现是否对上论文表图?通过/待改
[现状说明] 本刊无独立徽章制度:已如实定位,未夸大为"通过 AE 认证"
信息
Category 数据科学
Name cjc-artifact-evaluation
版本 v20260724
大小 7.63KB
更新时间 2026-07-28
语言