为什么我非要跟你聊「可重复性」？

大家好，我是搞了快十年生信的老兵。今天这第一讲，咱们开门见山——可重复性。

你可能会想：“这词儿都快被说烂了，有什么好讲的？” 嗯，我理解。在我刚入行那会儿也这么想。直到有一次，我花了三个月肝出来的一个RNA-seq项目，实验结果怎么都复现不了。换台服务器、换个软件版本、甚至换个分析流程的跑法，出来的基因列表都不一样。那段时间我几乎怀疑自己的数据分析能力是不是出了bug。

实际上，这不是你的问题。这是RNA-seq分析本身的特性决定的。

什么是可重复性？不只是“能跑通”

很多朋友对可重复性的理解，就是“别人按照我的代码，能跑出跟我一样的结果”。这话对，但不够。我个人的定义更狠一点：三年后，你自己拿着当年的数据和代码，还能跑出一模一样的分析报告。

你想想看，生信分析中最怕的是什么？不是数据难处理，而是你永远说不清楚“这个结果是哪套软件、哪个参数、哪个环境跑出来的”。实验室来了新人，想复现你两年前的图，结果软件版本都找不到了——这种尴尬，我遇到过不止一次。

所以我们讲的可重复性，至少包括三层：

1. 可执行：代码和数据都在，别人能跑起来。
2. 可解释：每一步为什么这么做，有记录。
3. 可扩展：换一批新的数据，流程还能继续用。

为什么RNA-seq尤其需要狠抓可重复性？

说白了，RNA-seq分析是一个多步骤、多工具、多参数的复杂流水线。从FASTQ比对到基因定量，再到差异表达分析，每一步都有几十种软件可选，每种软件又有十几个参数可以调。

我见过一个项目，因为R版本从4.0升到4.2，同一个DESeq2跑出来的结果p-value全变了。你想想看，这要是审稿人要求你提供原始分析环境，你怎么解释？

常见的三大坑：

• 软件版本漂移：今天装的Hisat2是2.2.1，明天装的就是2.2.2，比对结果不一样
• 环境依赖问题：Python包之间相互打架，今天能跑明天报错
• 手动操作不可追溯：在命令行里敲了啥，自己都忘了

审计追踪：给每一步操作拍个照

什么叫审计追踪？就是谁、在什么时候、用了什么工具、带着什么参数、处理了哪些数据，全部记录下来。而且这份记录必须是机器可读的，不能是“我记得当时好像加了--very-sensitive”这种模糊记忆。

审计追踪的核心要素：

1. 原始数据指纹：每个FASTQ文件的MD5或SHA256校验和
2. 软件与版本列表：精确到小版本号，比如samtools 1.17
3. 参数与配置：所有命令行参数和配置文件快照
4. 中间产物校验：比对后BAM文件的文件大小、reads数等
5. 运行日志：标准输出、标准错误、资源使用情况

Nextflow：让可重复性不再靠手动

好了，光讲概念没意思。咱们得落地。这个课程的主角——Nextflow，就是解决上面所有问题的工具。

你可能用过Makefile、Snakemake或者干脆自己写for循环。但Nextflow有三个让我觉得“这工具真香”的地方：

• 数据驱动：自动识别输入文件、检查文件是否有变化、只重新计算需要更新的部分
• 容器原生：Docker、Singularity、Podman，直接绑定每个流程步骤的软件环境
• 审计追踪自动生成：每次运行都会产生一个完整的运行报告，涵盖软件、参数、资源、时间戳

举个最简单的例子，计算每个样本的基因表达量：

// traditional_script.sh - 传统方式
for sample in sample_1 sample_2; do
    hisat2 -x index -U ${sample}.fastq | samtools sort > ${sample}.bam
    featureCounts -a annotation.gtf -o ${sample}.counts ${sample}.bam
done

这个脚本有严重的问题：没有版本信息、没有校验、如果中途中断没法续跑。换一个Nextflow版本：

// main.nf - Nextflow 方式
process ALIGN {
    container 'biocontainers/hisat2:v2.2.1'
    input:
    path fastq
    output:
    path "${sample}.bam"
    script:
    """
    hisat2 -x genome_index -U $fastq | samtools sort > ${sample}.bam
    """
}

process QUANT {
    container 'biocontainers/subread:v2.0.1'
    input:
    path bam
    output:
    path "${sample}.counts"
    script:
    """
    featureCounts -a annotation.gtf -o ${sample}.counts $bam
    """
}

看到了吗？所有软件版本直接写在process的container里，输入输出通过channel自动传递，运行失败自动重试，而且每次运行都会生成完整的审计报告。

这门课到底要讲什么？

咱们不走马观花。接下来30章，我会带着大家一步一步从零搭建一个具有审计追踪能力的RNA-seq分析流程，用的就是Nextflow。

这个课程不是那种“你照着敲一遍就能跑”的教程——那样你会发现换一个数据集就跪了。我会从真正的工程角度出发，告诉你为什么要这样设计、为什么这个参数要这么写、遇到报错怎么排查。

课程模块	核心内容	你能带走什么
基础篇｜1-5章	可重复性概念、Nextflow安装与基础语法	一个能跑的最小流程
核心篇｜6-15章	RNA-seq流程关键步骤、容器化、审计追踪	带审计日志的全流程
进阶篇｜16-25章	模块化设计、参数管理、分布式执行	可复用、可扩展的生产级流程
实战篇｜26-30章	集群部署、全文追踪示例、案例复盘	完整项目模板

嗯，说到这里我想提一句：这门课我不会给你吹什么“一键出结果”。生信分析没有魔法。但如果你跟着我把这套流程走下来，你会发现——以后再也不用为“当初这个结果是怎么跑出来的”而焦虑了。

好了，第一章就聊到这儿。记住一句话：可重复性不是事后补的，而是分析一开始就设计进去的。