企业官网建设流程全解析

1. 先搞清楚一件事：开放科学到底在解决什么痛点

2021年秋天我审过一篇稿件，作者提出了一套很漂亮的数据处理方法，AUC提升显著，理论推导也完整。我花了两个周末尝试按论文里的描述复现实验，结果卡在数据预处理环节——论文只写了“我们清洗了数据”，既没有公开清洗脚本，也没有给出中间版本的转换结果。我给编辑部发了三封邮件索要代码和原始数据，两周后收到回复：作者同意提供，但需要签署一份冗长的数据使用协议。等协议流程走完，已经过去一个月。那篇论文最终被接收了，但它的可复现性评分在我这里是零分。

这就是open-science运动想根治的老问题：科研产出的核心成果以PDF形式发布，而支撑结论的数据、代码、实验日志散落在作者的个人硬盘里，读者不可见、不可验证、不可复用。整个系统的信任建立在“作者不会造假”这个假设之上，但一旦你想真正沿着别人的工作往前走一步，就会发现路基本是断的。

开放科学不是某个单一工具，也不是某一本期刊的政策，它是一整套覆盖科研流程各个环节的实践规范。大致拆开看，包含四个彼此独立的维度：开放获取，即论文全文免费可读；开放数据，即支撑结论的原始数据和中间产物公开可下载；开放源代码，即分析脚本、模拟程序、数据处理流程对所有人可见；开放同行评审，即审稿意见和作者回复随论文一起公示。

这四个维度可以单独实施，也可以组合实施。比如你只把论文发在arXiv上，这就是纯开放获取；如果你同时把数据传到Zenodo、把代码推到GitHub，并附上完整的README运行说明，那你做的就是一次相当标准的全流程开放科学实践。这篇内容我打算把每个环节怎么落地、选什么工具、有哪些隐藏的坑都过一遍，尽量做到看完就能照着操作。

适合读这篇内容的人很明确：正在做科研、有论文产出压力、同时希望自己的工作能被更多人看到和复用的研究生、博士后和青年学者。当然，如果你是实验室里负责搭建管理流程的人，这篇内容对你同样有参考价值——你需要的不是再喊一句“我们要支持开放科学”，而是一个能直接复制到团队里的实施方案。

2. 预印本是你的第一张名片：怎么发、发哪里、什么时候发

2.1 预印本服务器选型的基本逻辑

很多人第一次接触开放科学是从投稿预印本开始的。所谓预印本，就是未经同行评审、直接上传到公共服务器供所有人免费阅读的论文草稿。它最大的价值是时间——传统期刊从投稿到见刊平均耗时半年到一年，而预印本从上传到在线只需要24到48小时。

选哪个服务器，基本由你的学科决定，这一点没有太多悬念：

• 物理、数学、计算机领域，arXiv是绝对主力，覆盖面广、检索方便、引用数据完善
• 生命科学领域，bioRxiv和medRxiv更常见，前者偏基础生物，后者偏临床医学
• 化学领域，ChemRxiv逐步被认可
• 社会科学领域，SocArXiv和PsyArXiv的接受度在上升
• 地球科学领域，ESSOAr可以关注
• 跨学科或多学科工作，Zenodo附带的预印本功能也可以用，但曝光度不如上述专业平台

我自己最常用的是arXiv，因为计算机学科基本已经形成惯例：论文先上arXiv，再投期刊或会议。有些会议甚至明确要求投稿前先发预印本，以证明工作的时间戳。不过要注意，不同学科对预印本的政策差异很大，有的期刊明确规定“已在预印本服务器发布的论文仍可接收投稿”，也有的期刊存在顾虑。投稿前花五分钟查一下目标期刊的预印本政策，能省掉后面很多麻烦。查法很简单，去期刊官网找“Policy on Prior Publication”或“Preprint Policy”字样，或者直接看开放获取期刊目录里关于预印本政策的标注。

2.2 发预印本的正确姿势和两个容易翻车的细节

先说姿势。预印本不是把最终投稿版直接丢上去那么简单，我建议按这个顺序操作：

1. 完成论文初稿，包括全部图表
2. 做一轮彻底的匿名核查——作者信息、项目编号、致谢、数据来源、软件版本号都要去掉或泛化
3. 按服务器要求的格式转换（arXiv用LaTeX，bioRxiv接受Word转PDF）
4. 上传主文件和补充材料
5. 填写元数据：标题、作者列表、摘要、学科分类、关键词
6. 确认发布，记录DOI

两个容易翻车的细节必须提醒。

第一个是作者顺序问题。预印本一旦发布，作者列表基本确定了这个工作的贡献归属。后期期刊修改作者顺序虽然可行，但操作起来很麻烦，需要所有作者确认并提供书面说明。我见过不止一次因为预印本时作者顺序没确认好，导致后来期刊投稿阶段作者翻脸不签同意书的案例。所以上传前务必让所有作者过一遍作者列表和署名顺序。

第二个是版本更新策略。预印本的优势之一就是可以随时更新，但更新不是盲目的。arXiv允许你撤回并替换当前版本，但所有历史版本都会永久保留，谁都能看到你之前的每一次修改。这就意味着：如果你的第一版有严重错误，不要以为悄悄换掉就没人知道。正确的做法是在新版开头加一段说明，明确指出修改了哪些部分、为什么修改。这非但不丢人，反而会给人留下严谨的印象。我自己就见过有人用v5版本替换v1时，在前面老老实实写了一句“v1中关于X定理的证明存在逻辑缺陷，本版已纠正”，结果评论区一片叫好，比硬撑着不承认强太多了。

3. 数据、代码、环境三件套：让“可复现”从口号变成可操作的动作

3.1 数据归档选Zenodo还是Figshare：算清楚这笔账

如果说预印本是脸面，那数据和代码就是里子。开放科学最核心的承诺是：别人拿到你的论文，能按图索骥把你的结果重新跑出来。要做到这一点，光放数据或光放代码都不行，必须是数据加代码加运行环境三件套齐全。

数据归档我首推Zenodo。原因有两个：一是它和GitHub做了深度集成，你可以在GitHub仓库的release页面一键归档到Zenodo，自动生成DOI；二是Zenodo由CERN运营，不设存储上限（单个文件上限50GB），且承诺长期保存，完全免费。Figshare同样免费且好用，界面更友好，但在GitHub集成方面弱一些。如果你是纯数据不想和代码绑定，两个都可以选，看习惯。OSF则适合用来管理项目全生命周期，能串联预印本、数据、代码、实验日志，但学习成本高一些，团队使用才值得。

归档数据时有一个关键问题：传什么。答案是只传生成论文图表所必需的最小数据集，加上数据字典。什么意思？你的实验可能产出了10TB的原始信号数据，但论文里只用到了这些数据经过清洗后的汇总统计。那么归档汇总统计文件和数据清洗脚本即可，原始数据只要在论文里说明获取方式就行。这样既降低上传负担，也让审查者更容易定位到核心证据。反过来，如果只传原始数据不传清洗代码，审查者拿到手也是一堆无从下手的数字，等于白传。

3.2 代码仓库的README要怎么写才算合格

代码上传GitHub是对技术的考察，而README写得好不好是对态度的考察。我审过不少开放代码，最让人抓狂的README长这样：就三行字，“This is the code for paper XXX. Please contact the author for questions.”，没有任何运行说明，依赖列表不存在，输入输出格式靠猜。

一份合格的README应该包含以下内容：

• 一句话描述项目是干什么的
• 系统要求和依赖环境（操作系统、Python版本、CUDA版本、主要依赖库及版本号）
• 安装步骤，必须是复制粘贴就能跑的那种
• 最小运行示例：用哪条命令、输入什么文件、期望拿到什么输出
• 数据和模型的获取方式（如果过大无法直接放进仓库）
• 目录结构说明：每个文件夹装的是什么
• 常见问题排查

我自己的习惯是，README写完后隔三天再照着它从零跑一遍，把过程中发现的所有省略步骤都补进去。这一步极其重要，因为写代码时你觉得理所当然的操作（“先装好依赖”“把数据放到data目录下”），别人看的时候真不一定知道。

还有一个小建议：在GitHub仓库里放一个带固定版本号的environment.yml或requirements.txt。不要用那种不带版本号的依赖声明，那等于没说。原因很简单——你的代码可能只依赖numpy的某个特定版本行为，如果用户装了不兼容的新版本，跑出的结果对不上，第一反应肯定是你的代码有问题。版本锁死能帮你挡掉大量这种无谓的质疑。

3.3 运行环境固化：Docker和Binder选哪个

即使版本号锁死了，不同操作系统之间的差异仍可能让“按说明操作”变成“按说明报错”。要彻底解决这个问题，可以用Docker容器把整个运行环境固化下来。构建一个Docker镜像，把代码、依赖、系统配置都打包进去，别人pull一个镜像就能在完全一致的软件环境里运行，不用关心底层是什么系统。

Docker的门槛在于有些人没接触过容器技术，第一次写Dockerfile会有点蒙。但标准流程其实很固定：

1. 选择基础镜像，比如python:3.9-slim或pytorch/pytorch
2. 复制代码到容器内
3. 安装依赖
4. 设置工作目录和入口命令

写好后推到Docker Hub，并在README里附上image标签，别人就能一键复现。

如果不想维护Dockerfile，Binder是替代方案。它能直接从你的GitHub仓库构建一个临时在线环境，读者点一下链接就在浏览器里打开一个装有你代码和依赖的Jupyter交互式会话。缺点是首次启动需要构建时间，另外免费版有内存限制，适合轻量级项目。

选择建议：代码重、环境复杂、需要GPU的项目用Docker；轻量级分析和教学用例用Binder就够了。两个都配当然更好，但至少要有一个，否则你的“可复现”承诺仍然是打折的。

4. 数据可用性声明和许可协议：最容易暴露水平的两块细节

4.1 一份写得规范的数据可用性声明长什么样

投稿期刊时，越来越多的期刊要求作者提供数据可用性声明（Data Availability Statement），用来告诉读者数据和代码在哪里。别看这只是短短几句话，写不好很影响观感。最差的是那种空泛的写法：“Data available on reasonable request.”——这句话的潜台词是“你来找我要吧，但我不一定给”。开放科学语境下，这基本等同于数据不可用。

一份合格的声明应该明确指出：

• 数据存放的位置（仓库名、DOI或URL）
• 数据的授权许可类型
• 代码存放的位置（GitHub仓库地址）
• 任何访问限制（比如包含敏感信息的例外情况）

举个例子，我论文里的声明是这么写的：“The raw imaging data used in this study are available in Zenodo (https://doi.org/10.5281/zenodo.XXXXXXX) under CC-BY 4.0 license. All analysis code is available at https://github.com/example/project under MIT license. Processed data files are included in the repository as supplementary tables. No additional restrictions apply.”

这样写的好处是，读者不需要任何中间环节就能拿到所有材料，而且清楚知道能拿这些材料做什么——CC-BY 4.0意味着只要署名就能自由复用，MIT则意味着代码可以被整合进任何项目，包括商业项目。

4.2 许可协议怎么选：不是所有开源协议都适合科研代码

这个问题看起来小，实际上坑很多。科研代码的许可协议选择，直接决定了别人能不能放心使用你的成果。

代码的常用协议大致分三类：

• 宽松型：MIT、BSD、Apache 2.0。别人可以自由使用、修改、再分发，甚至可用于闭源商业项目。适合你想让代码被尽可能多的人使用的场景。
• 强保护型：GPL。别人如果用了你的代码，他们的衍生作品也必须开源。适合你不希望自己的劳动成果被闭源商用的情况。
• 中间型：LGPL、MPL等。适用于特殊需求，一般科研场景用不到。

数据类资源不太适合用软件协议，更常见的选择是知识共享协议。CC-BY（允许任何用途，需署名）最宽松也最推荐；CC-BY-SA要求衍生作品同样共享；CC-BY-NC禁止商业使用；CC-BY-ND禁止修改。从科研数据的角度说，CC-BY通常是最佳选择，因为后续研究者不会被非商业条款束缚住手脚。比如有人想基于你的公开数据做企业合作项目，CC-BY-NC就会直接挡路。

一个真实的教训：我2019年参与过一个开源数据库项目，团队里有人选了CC-BY-NC协议，当时觉得“防止别人拿我们的数据赚钱没毛病”。结果第二年有个药企想和我们合作开发一个临床决策工具，需要用这个数据库做模型训练。法务一查，授权协议禁止商用，合作只能被迫调整方案，绕了一大圈才解决。从那之后我在所有项目里默认CC-BY，除非有极其特殊的理由。

4.3 版本管理和归档时间点：什么时候该给代码打tag

GitHub仓库本身不是长期存档的可靠场所——公司被收购、仓库被删除、账号被停用的情况每年都在发生。真正可靠的做法是：论文被接收时，给当时的代码状态打一个tag，并同步归档到Zenodo生成一个不可变的DOI。

具体的做法是：

1. 论文接收后，创建一个新的release版本，写上版本号（如v1.0.0）
2. 在GitHub仓库的Settings里启用Zenodo集成（免费，只需按提示授权）
3. 发布release，Zenodo会自动抓取仓库代码并生成DOI
4. 把这个DOI写进论文的数据可用性声明，提交给出版社

这样你既保持了GitHub上的活跃开发，又给了论文读者一个绝对稳定的引用入口。需要注意，归档后后续再改代码不影响已发布的DOI——那个DOI指向的是当时归档的快照，永远都不会变。这也是科研引用需要DOI而不是直接引GitHub URL的原因：URL可能失效，DOI几乎不可能失效。

5. 开放同行评审：从“被迫接受”到“主动选择”的转变

5.1 开放评审模式的几种形态

传统同行评审里，审稿人身份和审稿意见都不公开，作者也不知道是谁在背后给自己提意见。开放同行评审则试图为这个环节增加透明度。目前有几种不同程度的开放模式：

• 完全开放：审稿人姓名、审稿意见、作者回复全部随论文公开
• 部分开放：审稿意见公开但审稿人匿名（或相反）
• 可选的开放式评审：作者可以选择是否发表审稿记录
• 发布后评审：论文正式发表后，任何读者都可以在PubPeer或期刊官网发表评论

计算机领域的大型会议现在基本都采取“审稿意见可见但审稿人匿名”的模式。神经信息处理系统大会、国际机器学习大会这两个会议，作者在 rebuttal 阶段能看到全部审稿意见，但不知道审稿人是谁。发表后，审稿意见和作者Response会随论文一起出现在会议网站。这种做法明显提升了评审质量——审稿人知道自己写的意见会被同行阅读，措辞会更谨慎、建议会更具体。

期刊层面，eLife、Nature Communications、Royal Society Open Science这些刊都在推行不同程度的开放评审。如果你介意审稿人身份暴露，选刊时看准“双盲评审”或“单盲评审”标签即可。如果你完全不介意，甚至希望审稿意见公开（好的审稿意见能帮读者理解论文的局限），可以主动选择开放评审模式的期刊。

5.2 要不要参与期刊之外的开放评审平台

期刊体系之外还存在两类开放评审平台，值得了解。

一类是发布后评审平台，比如PubPeer。任何人在上面都可以匿名评论任何一篇已发表论文。这个平台名声有点两极分化——既有真正指出学术不端的高质量评论，也有恶意攻击甚至骚扰。你不需要主动参与，但应该知道它的存在，并且定期搜索自己论文的关键词，看看有没有人对你的工作发表评论。真要被人提出了合理质疑，选择在PubPeer上实名回应通常比私下联系更好——公开质疑配公开回应，这本身就是开放科学精神的一部分。

另一类是预印本审稿平台，比如PREreview。这个平台邀请科研人员（包括研究生！）对bioRxiv和arXiv上的预印本进行公开评审，评审内容会反馈给作者。这其实是低风险练习评审能力的好机会——学生时代的评审经验对将来独立审稿非常有价值。我现在带的学生，我都会建议他们选几篇和自己研究方向相关的预印本去PREreview练手，顺便积累学术履历。

5.3 收到评审意见后的心态调整和回复技巧

开放评审和传统评审在心态上有一个显著区别：传统评审意见只有你和编辑能看到，回复写得再烂也只有编辑知道；开放评审环境下，你回复审稿人时的措辞、态度、论证的充分程度，会被所有读者看到。这就对回复质量提出了更高要求。

我总结出三个原则：

第一，绝对不要在回复里表现出攻击性。哪怕审稿人的意见完全外行，回复也要保持专业、克制的语气。可以写“We appreciate the reviewer’s suggestion, but we believe it may be based on a misunderstanding of our experimental setup. Please see our response below for clarification.”这种句式。公开的回复记录会长期伴随你的论文，没必要为了一时痛快留下不专业的印象。

第二，逐条回复，不要跳问题。哪怕十几个问题里面有五个你都觉得没道理，也必须一条一条回应。跳跃式回复在开放评审里极易被读者抓住把柄，让人觉得你在回避问题。

第三，如果审稿人提到的内容确实是你论文的盲区，大方承认并补充分析。我见过最好的回复是这样写的：“We agree with the reviewer that our original discussion was insufficient. We have now provided additional analysis in Section 4.2 to address this issue.” 这类诚恳的回应往往能赢得审稿人和读者的双重尊重。

6. 在开放与竞争之间找平衡：一些实在的建议

6.1 开放科学会牺牲学术竞争力吗

这是每个决定走开放路线的人都会问的问题。担心不是没有道理——你公开了数据和方法，等于把底牌亮给竞争对手看。他们可以基于你的数据抢先发表后续工作，先入为主占住研究方向。

但实践中，开放科学带来的引用提升往往能抵消这种担忧。多个大规模元分析研究的数据表明，开放论文的引用量比不开放论文平均高18%到30%，挂在bioRxiv上的预印本比未预印本的最终版论文更早被引用。原因不复杂：论文可见性越高，被阅读和引用的机会就越大。对于青年学者来说，早日建立学术可见度的价值，通常高于短期“防被抢跑”的保护价值。

数据的话，从Nature Communications 2019年刊出的一项分析可以看到，带开放数据的论文相比不带数据的论文，引用优势在发表后第二年就拉开差距，而且随时间的推移优势会进一步拉大。2020年PLOS ONE上有一篇针对生物学领域的研究也得出了类似结论，开放数据论文的引用率提升约25%。

6.2 处理被抢发焦虑的三个实操对策

对“被抢发”的焦虑，光靠上面这些统计数据很难彻底化解。我自己也经历过这个阶段，最后是靠三个具体做法把焦虑降下来的：

一、用预印本时间戳锁定优先权。这是最直接的保护方式。你在arXiv发预印本，你的发布时间就是全网可查的学术记录。对方再发类似工作，无法声称这是首创。学术圈默认的规则是：优先权看公开时间，不看期刊发表时间。

二、发布数据时选择稍晚于论文接收的节点。不需要论文一完成就开放所有数据。你完全可以在论文被接收之后再归档数据、发布代码。期刊只要求最终版本上线时数据和代码可用，没人规定一审之前就得开放一切。给自己留出一个合理的时间窗口完成后续研究工作，是完全符合学术规范的。

三、控制开放粒度。前期只开放论文里明确用到的数据集和分析脚本，不需要把整个实验室的所有实验记录都搬上网。开放科学的原则是“最小必要公开”，而不是过度公开。那些还没整理完、还打算继续往下做的项目，完全可以等成熟后再公开。

6.3 怎么说服导师和课题组一起走开放路线

对研究生来说，最常见的障碍不是技术，而是导师的顾虑。导师的担心通常集中在两点：学生数据被人抢先利用，以及团队的独特数据被外人拿走。说服策略上，我不建议用“这是大势所趋”这类空话，更有效的做法是把开放科学的利益具象化。

你可以向导师展示小组内已经发表的论文在GitHub上开放代码后的数据变化：星标数、issue反馈、外部协作请求、后续论文引用，这些数字比任何理论论证都有说服力。如果你所在的团队还没做过开放科学的实践，可以先选一篇影响力较大的论文做试点，完整走一遍“代码归档到GitHub+数据归档到Zenodo+README撰写”的流程，跑通之后再向导师展示结果。一个能正常运行的开放项目，比十次口头宣讲都管用。

另外一点经验是：提前向导师承诺数据使用权优先。比如明确说明“数据公开后，团队内部任何时候都可以优先使用，不需要额外的许可流程”。这个承诺能有效打消导师对“数据公开后自己用起来反而麻烦”的担忧。实际操作中，我建议在公开数据时采用分级授权策略——核心数据用Embargo（延迟公开）模式，设定6到12个月的封禁期，期满自动公开。这既保住了团队的时间窗口，也做到了最终开放。

7. 踩坑实录：我在开放科学实践中交过的五笔学费

7.1 文件命名混乱导致的数据被误读

2020年我帮一个合作团队整理公开数据集时，发现他们的文件命名完全乱套：v2和final出现在同一个目录里，final_v3其实是比v2更早的版本，data_processed既有清洗后的数据也有半成品。这种混沌状态在个人项目里可能无伤大雅，但一旦公开，任何一个下载者都会困惑，甚至可能拿错的版本分析出错误结论，最后反过来质疑你的数据质量。

现在我的归档前检查清单上有一条固定事项：所有文件名遵循统一规则，比如raw_日期_实验编号.csv、processed_日期_变量.csv，并且每个目录下放一个README说明文件命名规则和每类文件的具体含义。整理归档数据时多花一小时，后面能省下无数封解释邮件。

7.2 许可证选错被合作方卡住

这条前面提过，值得再展开一次。我们当时数据库项目选了CC-BY-NC，初衷是防止商业机构免费拿走研究团队多年的积累。结果药企合作要谈时，法务部门一看协议就摇头，说商用授权存在障碍。我们的选择只剩两个：改协议（但之前所有已下载数据的用户都会受到许可变更的影响，操作上很不干净）或者绕开这个数据库另建一套。无论哪个选择，时间成本都很高。

教训就是：如果没有非常明确的理由，科研数据默认CC-BY，代码默认MIT或BSD，可以兼容绝大多数后续使用场景。特定目的的防御性许可是应该通过其他方式来管理的，而不是在公开协议层面设限。

7.3 数据匿名化不彻底造成隐私隐患

教育数据、医疗数据、问卷数据，这些涉及人类受试者的数据，公开前必须做充分的匿名化处理。我第一次公开一个包含访谈内容的语料库时，以为把姓名替换成匿名编号就够了。事后被合作方提醒，才发现访谈原文里被试提到过自己的工作单位、城市、具体年龄等组合信息，这些信息合并起来足以反推出访谈对象身份。

正确的操作是：对直接标识符（姓名、邮箱、身份证号）当然要删除；对准标识符（出生日期、工作单位、职位、地域等）也要做泛化处理，比如把具体年龄换成年龄段，把城市换成区域。发布前找团队里不参与该项目的人做一次“猜人测试”会比一个人自查靠谱得多——因为你对数据太熟了，很容易自己想当然。

涉及临床数据和未成年人数据，情况更复杂，强烈建议提前和所在机构的伦理委员会沟通，获得数据共享的伦理审批意见后再进行。

7.4 GitHub仓库直接被人用来爬数据导致宕机

这是技术上的坑。有个项目我放了几个大体积的中间结果文件在GitHub仓库里，直接被人用脚本并发下载，导致仓库访问变慢，GitHub发了限流警告。后来我把大文件迁移到Zenodo，并在README里更新了下载链接，仓库本身只保留代码和示例数据。GitHub的1GB文件限制虽然存在，但最好把超过100MB的文件都放外部存储。

Zenodo对单个文件的大小上限是50GB，且不限总存储量。如果你有超大文件，可以考虑分卷压缩后在Zenodo上生成新版本。

7.5 版本更新太频繁造成下游用户困扰

开放代码发布后，自然会有用户提issue、提需求，你也想快速响应。但频繁的提交和在主分支上的直接修改，可能让下游用户无所适从——他们fork的版本、你论文对应的版本、你README推荐安装的最新版本，三者可能是不同的状态。

我现在的做法是：保留一个与论文DOI对应的不可变release版本，日常开发在main分支上进行，发布新功能时打tag形成新release。论文版本永远是那个被Zenodo快照固定的v1.0.0，之后的更新都以v1.1.0、v2.0.0这样递进，并在release notes里写清楚每个版本的变化。用户按论文DOI拿到的代码永远稳定，而想用新功能的人可以自由切换版本。

8. 如果只让我留下一套最小可行方案

如果前面内容信息量太大，你只需要记住一套最小可行方案就够入门了。这套方案不需要花一分钱，不需要团队配合，也不要求导师支持，你自己就能完成。

操作就四步：

1. 论文写完终稿后，上传到对应学科的预印本服务器，锁定时间戳
2. 把支撑论文结论的数据集整理好，上传Zenodo，生成DOI
3. 把分析代码整理好，推到GitHub，写好README和环境依赖文件
4. 论文投稿时，在数据可用性声明里写清楚数据集DOI和代码仓库地址

完成这四步，你的这篇论文就已经达到开放科学的基础标准了。别人拿到论文，可以在半小时内找到你的数据、你的代码、你的分析环境，并复现你论文里的核心图表。

这个方法一定要在你投稿前就做完，不要等论文接收后再补。原因很简单：评审专家可能恰好就是看到你数据和代码的人。如果审稿人同时对数据和代码做了核查，你的信任度会直接拉高一个档次。而如果你的数据可用性声明里只写着“available on reasonable request”，审稿人又会怎么想呢？

我自己的经历可以给一些参考。2022年我按照这套流程做了两篇论文，一篇用Docker环境+GitHub代码，一篇只给数据没给代码。前者第二年就被另外两个团队引用并复用了部分代码做了后续研究；后者至今只在学术社交平台上被人问过一次数据。差距不是一般地明显。

最后分享一个我在实践中养成的习惯：每次论文接收后，我会花两小时做一次“站在读者视角”的完整测试。关掉自己的电脑，借一台干净的虚拟机或者找同事的电脑，只凭论文里写的内容，从零开始获取数据、拉取代码、按README操作，直到复现出论文中的核心结果。整个过程只要有一次无法走通，我就继续补文档、补脚本、补说明。这套流程虽然费时间，但每次走完，我对自己的论文发布状态就有了百分之百的确定性。开放科学最本质的价值也就在这里：它强迫你用别人能理解、能验证的方式，重新审视自己的工作，而这个过程中你学到的东西，往往比论文本身更有意义。