开源、复现包与 Artifact 评估
发布可运行的代码与数据显著提高引用与影响。本章讲发布的最低标准（README、依赖、一键复现主要结果）、许可证选择、Artifact 评估流程，以及长期维护的边界。
代码是论文的延伸
Section titled “代码是论文的延伸”发布可运行的代码与数据，对引用与影响有显著的提升：能跑起来别人论文的读者，才会真正建立在这篇论文上。代码是论文的延伸：发布前后的工作量差别不大（你都做了），影响的差别巨大。
能一键复现表 1 是最重要的。 读者 clone 下来到跑出主表的路径要尽可能短：
- README：环境、数据获取、运行命令、预期输出，按步骤写；
- 依赖锁定：requirements/lockfile 或容器镜像（见可复现性）；
- 一键复现主要结果：一个脚本/命令跑出主表（其余表的脚本可以是半自动，主表必须一键）；
- 配置与代码分离：读者改配置就能复用你的框架（见研究代码的组织）。
许可证与发布前的决定
Section titled “许可证与发布前的决定”- 许可证要在发布前决定：研究代码常用 MIT/Apache-2.0（宽松）或 CC-BY（数据）；不确定时默认宽松许可——研究的传播价值高于控制权；
- 检查代码里有没有不该发布的东西：密钥、内部路径、未公开数据的路径、他人的受限代码；
- 数据的许可与隐私单独检查（爬取的数据、含个人信息的日志，见人类被试与数据伦理）。
Artifact 评估
Section titled “Artifact 评估”系统类会议提供的 artifact 评估（Artifact Evaluation）是对论文代码与数据的独立验证：委员会按你的 README 跑一遍主要结果，通过后论文获得可复现徽章（见术语表）。提交前的自查就是"陌生人测试"：找一位没参与项目的同学，只给 README，看他能否跑出主表——跑不出就改到跑得出。
长期维护的边界
Section titled “长期维护的边界”不承诺无限期维护：研究代码的生命周期是一次性的，README 里写清维护状态（"研究代码，按原样提供，主要结果见复现脚本"）。更新与 issue 响应到论文发表后的合理期限即可——承诺维护到永远是对自己的不诚实，也是对用户的不诚实。
- 能一键复现表 1 是最重要的
- 许可证要在发布前决定
- 不承诺无限期维护