cjc-artifact-evaluation

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

先说清现状：《计算机学报》(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-process、cjc-author-response），

一份组织良好、可一键运行的制品能让你在修回期限内快速产出新结果、并在答复信中给出可核验的表图，

显著提升修回效率与可信度。这也是在没有正式徽章制度时，认真做制品的直接回报。

十一、自查清单

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

输出格式

[制品清单] 源代码/数据/脚本/配置/环境 —— 齐备情况
[托管] 平台___；永久标识(DOI/tag/commit)___；访问方式与日期___
[可用性声明] 正文位置___；不可公开部分是否说明替代途径？是/否
[匿名] 评审阶段仓库是否规避作者身份暴露？是/否
[自评] 干净环境复现是否对上论文表图？通过/待改
[现状说明] 本刊无独立徽章制度：已如实定位，未夸大为"通过 AE 认证"