生信分析的可重复性：从脚本到容器化的实践思考

问题的提出

几年前我在做转录组分析时遇到一个尴尬的情况：半年后用同一套原始数据跑流程，得到的结果和之前不完全一样。虽然差异不大，但这让我开始思考——我们的分析流程真的可重复吗？

可重复性的三个层次

1. 脚本级别

最基本的可重复性要求：

# 坏习惯
analysis_v2_final.R
analysis_v2_final_modified.R
analysis_v2_final_real_final.R

# 好习惯
01_qc.R
02_alignment.R
03_quantification.R
04_differential_expression.R

关键原则：

• 使用版本控制（Git）
• 保持脚本编号和命名规范
• 所有参数通过配置文件传递

2. 环境级别

"It works on my machine." — 这是可重复性最大的敌人。

• R 包管理：使用 renv 锁定包版本
• Python 环境：使用 conda 或 venv + requirements.txt
• 系统级：Docker 容器化

renv 使用示例

# 初始化 renv
library(renv)
renv::init()

# 保存环境快照
renv::snapshot()

# 在其他机器上恢复
renv::restore()

3. 数据级别

原始数据不可修改，分析过程中的中间数据需要记录生成方式：

我的分析流程模板

经过多次迭代，我现在使用的分析流程遵循以下原则：

统计思维的重要性

除了代码可重复性，统计方法的选择也影响了结论的可重复性：

• 多重检验校正：Bonferroni, FDR 等方法的选择
• 效应量：不仅是 P 值，还要关注效应大小和置信区间
• 交叉验证：避免过拟合的必要手段

统计显著不等于实际显著。大样本量下微小差异也能得到显著的 P 值，但可能毫无生物学意义。

结语

可重复性不是一个一次性达到的目标，而是一种需要持续培养的科研习惯。从今天开始，为自己的每个分析项目建立一个规范的目录结构、使用版本控制、记录环境信息——几年后的你会感谢现在的自己。

实践出真知，这些经验来自我日常分析中的踩坑和反思。欢迎留言讨论你的可重复性实践。