cjc-artifact-evaluation
GitHub指导CJC作者规范提供代码数据以提升复现性与外审信任。涵盖制品清单、稳定托管、可用性声明写法、目录结构及开源许可选择，助作者在无独立徽章制度下增强实证可信度并快速响应修回需求。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill cjc-artifact-evaluation -g -y
SKILL.md
Frontmatter
{
"name": "cjc-artifact-evaluation",
"description": "在为投向《计算机学报》(Chinese Journal of Computers, CJC) 的稿件准备代码与数据可用性材料时调用。本刊目前没有像国际计算机会议(如 ACM\/USENIX 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 认证"
Version History
- 9f86f09 Current 2026-07-19 14:45
