依赖自编代码的论文，投稿前如何准备运行说明

论文结论依赖自编代码时，上传几个脚本不等于已经提供可运行材料。编辑或评估者需要知道从什么输入出发、用什么环境、按什么顺序运行，以及输出怎样对应论文结果。准备运行说明，是把研究分析过程变成可理解材料的关键一步。

先确定需要交付的分析范围

列出支持核心结论的脚本、配置文件和必要资源，区分正式分析与探索记录。不要把整个工作目录未经整理就打包，也不要只保留画图脚本而省略生成图中数字的关键步骤。

Nature的初次投稿说明对支撑结论的自编代码提出可用性说明要求，具体提交安排应以目标期刊政策为准。是否可以公开、何时开放及存在何种限制，需要真实核实，不应把无法提供的材料写成“全部可获得”。

写清运行环境

记录操作系统、主要语言、依赖库和版本，以及确实影响运行的硬件条件。用读者能执行的方式说明环境准备，避免只有“安装相关软件”。如果依赖外部工具或许可资源，注明其作用及获得条件。

同时检查配置中是否残留个人路径、口令或内部服务器地址。示例配置可以使用说明性占位值，但必须明确哪些位置需要填写。不能让材料只能在作者自己的电脑上运行，而说明又声称无需调整。

交代输入和数据限制

为输入文件列出名称、格式、字段含义和必要预处理。若原始数据受限，说明限制及允许的访问方式；可使用合适的演示数据解释操作，但要标明它不能复现真实研究数字。

数据说明与代码说明应相互对应。例如，脚本要求缺失值采用特定编码，就在字段说明中写清。否则同一程序处理不同编码，可能产生不同样本量，评估者却难以发现原因。

用最短路线连接论文结果

写出推荐运行顺序，每一步说明输入和输出，并把关键输出映射到正文的图、表或分析。随机过程应记录有关设置及其作用，结果存在允许的数值差异时解释原因，不能承诺任何环境都得到完全相同文件。

可以增加一个小规模检查任务，让使用者先判断环境是否安装正确。随后说明完整运行的大致资源需求，但时间估算要标注测试条件。运行失败信息应提供排查线索，而不是让读者反复猜测缺少哪个文件。

请未参与编写的人试运行

让合作者从干净目录按说明操作，记录卡住的位置。重点看能否找到输入、理解参数、按顺序执行并定位输出。发现问题后修改说明或代码包，再保存对应稿件的版本。

提交时核对代码可用性声明、上传包和正文方法是否一致。运行说明应忠实解释已经完成的分析，不能为了更漂亮的结果悄悄改变程序。好的代码材料使证据路径更清楚，而不是把透明度等同于自动通过评估。

参考资料：Nature，初次投稿指南及代码公开指引。