文件命名三大铁律：唯一性、可读性、机器可解析性

每当有新同事加入我的团队，我第一件事就是拉他们看我们的FASTQ命名规范。你想想看，一个测序项目动辄几百个文件，如果名字乱七八糟，后期分析光是找文件就能把人逼疯。

这就得从命名的基本原则聊起。我个人习惯把这三大原则叫“铁三角”——唯一性、可读性、机器可解析性。三条缺一条，你后面的分析流程就会卡壳。

唯一性：一个文件一个身份证

说白了，每个FASTQ文件在全项目中必须有独一无二的标识。我在项目中遇到过这样的情况：同一个样本跑了两次测序，结果两个文件叫一样的名字，只是放在不同目录里。后来做批量分析时脚本傻眼了——它不知道该读哪个。

唯一性的核心要素：

• 样本ID：每个样本有且只有一个ID，不能重复
• 实验批次：同一样本不同批次要靠批次号区分
• lane编号：Flow cell不同lane跑出来的数据必须标注
• read方向：R1和R2必须通过命名区分

唯一性命名示例：

# 正确的唯一性命名
PROJ001_SAMPLE_A01_L001_R1.fastq.gz
PROJ001_SAMPLE_A01_L001_R2.fastq.gz
PROJ001_SAMPLE_A01_L002_R1.fastq.gz   # 同一样本不同lane
PROJ001_SAMPLE_A01_L002_R2.fastq.gz

# 错误的命名（缺少批次/read信息）
A01.fastq.gz             # 重名风险极高
sample_A01.fastq.gz      # 多个项目重复使用该名称

可读性：文件名要像说明书

这一点很多人会忽略。你想想看，半年后你回头处理这批数据，看到一堆不明所以的缩写，你还记得每个字段是什么意思吗？我建议文件名要让一个同行在10秒内看懂主要信息。

可读性的设计原则：

1. 使用有意义的字段名：比如用SampleID而不是SID，用Project而不是PJ
2. 层级要清晰：从大到小排列——项目、样本、实验参数
3. 避免歧义：不要用容易混淆的字符
4. 控制长度：太长的名字在终端里直接被截断，反而失去可读性

字段	好例子	坏例子	说明
项目	WGS_China	WC	缩写太短，容易冲突
样本	Sample_Tumor_01	ST1	含义模糊，三个月后你肯定忘
批次	Batch_20231015	B1015	日期格式统一，容易排序
read	R1 / R2	Forward / Reverse	简短且业界通用

机器可解析性：让脚本也能看懂

这个原则是我最想强调的。很多人在命名时只考虑人看得懂，却忽略了脚本处理的需求。你猜怎么着？一次处理几万个文件，人眼肯定不行，得靠程序。

机器可解析性的要求：

• 固定的分隔符：统一用下划线_或连字符-，不要混用
• 字段位置固定：比如第1段永远是项目ID，第2段永远是样本ID
• 避免特殊字符：空格、括号、星号都会让shell脚本崩溃
• 使用纯ASCII：中文、带重音符号的字母在不同系统里可能乱码
• 大小写统一：全小写或全大写，不要混合

机器解析的正反示例：

# ✅ 机器友好（固定3个字段，用下划线分隔）
ProjectA_Sample01_R1.fastq.gz
ProjectA_Sample01_R2.fastq.gz

# ❌ 机器不友好（混用分隔符，字段位置不统一）
01-R1_Sample01_ProjectA.fastq.gz
ProjectA-Sample01-R2.fastq.gz

# ❌ 包含特殊字符（shell脚本解析会出问题）
Project A_Sample 01_(new)_R1.fastq.gz

三大原则的平衡点

你可能会问：这三个原则会不会互相冲突？比如可读性要求字段全称，但机器解析又希望字段简短？嗯，这里要注意——先在可读性上妥协，但要保留机器可解析性。

我个人常用的规则是这样的：

• 项目名称用缩写但要有对照表
• 样本ID用统一格式，比如Sample_Type_Number
• 技术参数（lane、batch）用简短数字
• read方向用业界标准R1/R2

举个例子：

# 平衡了可读性和机器可解析性
WGS_HD_001_B01_L001_R1.fastq.gz
|    |   |   |    |    |
项目 类型 编号 批次  lane read