投稿中的方案版本和仓储版本号，正文怎样对应？

一个仓库主页可能不断变化

研究方案可能在预注册时冻结一版，数据仓库和代码仓库又在分析过程中继续更新。论文若只给仓库主页，读者后来打开时可能看到新文件，以为它就是投稿时使用的方案。方法段应写明方案的注册或存档标识、版本日期、正文所执行的版本，以及仓库中对应的文件或提交版本。OSF把注册视为带时间戳的只读版本，DataCite也提供版本关系的记录方式；两者说明“可定位的某版”比泛指项目更有用。

计划与实际执行分开描述

方案中预定的主要结局、纳排标准和分析方法，应与稿件实际执行逐项对照。若研究中途改变了时间窗或新增敏感性分析，不必把变化藏起来；可以说明何时、为何改变，改变发生在看到关键结果之前还是之后。预注册并非保证方案永远不变，而是让读者能识别预定与探索内容，以及变动发生的时间。正文方法写实际做法，补充表或方案对照记录则呈现偏离，避免把旧方案复制进正文造成矛盾。

数据与代码也有各自版本

原始数据快照、清洗后的分析集、运行代码、软件环境可能分别保存于不同仓库。给每个关键资源留下版本号、提交哈希、发布时间或持久标识，并在方法或数据可得性声明中说明关系。若数据仓库更新了一份纠错版，却未重跑论文分析，应明确文章使用旧版还是新版；若已重跑，受影响的图表也要同步更新。记录更新原因，有助判断只是文件名变化还是数值本身改变。不要让代码指向新数据、表格却来自旧数据。

把方案、数据和图表对应起来

可在内部表中列正文图表、方案条款、数据文件与代码运行标识，投稿时把最关键的对应关系写入方法或补充资料。一个实例是主要结局在方案第二版定义，表二用分析集第三版和脚本某次提交生成；读者由此能看出版本变化是否影响结果。若期刊要求双匿名审稿，可按其规则处理可识别作者的仓库页面，但不能牺牲版本追溯。

投稿前按版本重走一遍

选一项核心结果，用稿件所写的版本去找方案、输入数据和运行脚本。如果需要靠作者口头补充才能知道哪版有效，说明文中仍缺标识。引用动态仓库时保留访问日期或归档快照，正式发表前再核对链接仍可打开。版本号不是装饰性信息，它使预设计划、实际操作和可复查结果能够在同一时间点相遇。

参考信息：OSF注册说明、OSF API与DataCite版本管理原始资料。