从一次性脚本到可回归的扩增子工作流

扩增子分析通常包含几十到上百个步骤。只看最后有没有图，很难回答三个基本问题：这次用了哪一版代码？数据库和参数是否变化？下一批真实数据还能否完整运行？

先定义唯一的规范流程

我的做法是保留一个规范流程目录，让每个研究项目引用它，而不是复制一份脚本后各自修改。项目的数据、配置和结果仍然隔离，流程代码则只有一个需要维护的版本。

这减少了副本漂移，但也带来新的责任：规范流程的任何变化，都必须能够说明影响范围，并用真实项目验证。

记录的不只是软件版本

可复现记录至少应包括：

• 输入文件与关键配置的校验值；
• 工作流与脚本版本；
• 数据库、运行环境和主要依赖；
• 实际执行命令、开始与结束状态；
• 被跳过、降级或失败的步骤；
• 结果目录与验证回执。

这些信息不是为了让日志显得完整，而是为了在结果异常时缩小排查范围。

用两类真实数据做回归

截至 2026-08-28，规范流程分别用 Illumina paired-end 和 PacBio CCS / HiFi 的真实项目做过全流程回归：前者完成 132 / 132 步，后者完成 112 / 112 步，退出码均为 0。流程文件清单 100 项校验通过。

这个结果证明当前固定版本在这两类已知项目上可以完整运行，但不能外推为“任何数据、任何研究设计都不需要检查”。

工程通过不等于统计结论自动正确

分析流程最容易被忽略的边界，是软件成功退出与方法适用之间的差别。Alpha 多样性是否需要统一深度、Beta 多样性是否检查组内离散度、网络和差异分析的假设是否满足，都必须结合具体问题判断。

因此，项目页会同时保留两类信息：工程上验证了什么，以及方法学上还需要人工审查什么。承认边界并不会削弱流程，反而使它更可信。