做 RNA-seq 转录本组装的人几乎都会撞上同一个尴尬场面StringTie 或者 Cufflinks 跑完手里多了一个几百兆的 GTF 文件打开一看全是 TCONS_00000001、STRG.1234 这种流水号既没基因名也没功能注释。你盯着这堆编号真正想知道的只有一件事——它到底组装得对不对跟已知注释能对得上多少那些对不上的又是些什么东西GFFcompare 就是冲着这个问题来的。它是约翰霍普金斯大学计算生物学中心那套工具链里的一员和 StringTie、gffread 出自同一个团队定位非常明确拿一份参考注释做标尺去衡量一份或者多份查询组装结果的准确度和完整度顺便把每个转录本在参考里的下落逐条记录清楚。做转录本组装的评估、做多样本合并去冗余、做新转录本发掘基本都绕不开它。不过这个工具会用和用明白之间隔着一道挺深的沟。命令行就那么几个参数跑起来也就几秒到几分钟但输出文件里那一堆分类码class code和六级敏感度/精确度指标才是真正决定你结论站不站得住脚的地方。我见过太多人直接把 .stats 里的数字抄进汇报里却完全不知道那个 Base level 的精确度为什么会高得离谱。这篇就把 GFFcompare 从场景定位、分类码语义、实操命令、输出解读到踩坑排查整个串一遍适合刚接触转录本组装评估的读者也适合已经跑过但读不懂输出的人回头补课。1. GFFcompare 在 RNA-seq 流程里到底站什么位置1.1 转录本组装评估的真实痛点参考基因组比对工具比如 HISAT2、STAR输出的 BAM本质上是读段落在哪儿的堆叠证据它不告诉你这里是一个有完整外显子结构的转录本。把 BAM 转成转录本结构这一步靠的是 StringTie、Cufflinks、Scallop、StringTie2 这类组装器。但组装器的输出有一个先天缺陷它没有身份。一个 TCONS 编号只能告诉你这是我拼出来的一条转录本没法告诉你它是不是等于注释里的 AT1G01010.1。更要命的是组装器的输出会随参数、随样本、随测序深度飘。同一样本换个-f的丰度阈值多外显子转录本的数量能差出十几个百分点。这个时候如果没有一个统一的、可量化的评判标准你根本没法判断我这次调参到底是变好了还是变差了。GFFcompare 提供的正是这套标准。它把查询组装结果和参考注释做结构层面的比对输出一套行业里约定俗成的指标——敏感度SensitivitySn和精确度PrecisionPPV并且在六个层级上分别给出数值碱基层、外显子层、内含子层、内含子链层、转录本层和基因座层。这六级设计本身就很有讲究后面会专门拆。1.2 三种最典型的使用场景第一种单样本组装质量评估。你跑完 StringTie得到 sample1.gtf想看看组装得怎么样。这时候拿同一物种、同一版本的参考注释跑一次 GFFcompare看 .stats 里的六级指标再扫一眼分类码分布基本就能判断这次组装是及格还是需要回头查比对参数。第二种多样本合并去冗余。这是 GFFcompare 用得最多也最容易用错的地方。多个样本各自组装出来的 GTF彼此之间有大量重叠但又不完全一致的转录本。如果你直接把这些 GTF 拼起来同一个基因会被拆成几十条碎转录本。GFFcompare 的合并模式通过-i参数指定一个文件列表会把所有查询转录本按结构相似性归并输出一份统一的、去冗余的注释。这一步在很多流程里是可变剪接分析、转录本定量分析的前置条件。第三种转录本溯源。当你手里有一份新组装的 GTF想知道里面哪些是老转录本、哪些是没见过的GFFcompare 的 .tracking 文件就是干这个的。它逐条记录每个查询转录本在参考里的对应关系class code 直接告诉你它是精确匹配、部分匹配还是完全新的。1.3 和 gffread、StringTie --merge 的分工别搞混新手最容易混的就是这块。gffread主要做格式转换、提取 CDS/蛋白序列它不做结构比对评估StringTie --merge能做多样本合并但它只合并不评估你不知道合并完之后跟参考注释的吻合度如何GFFcompare 既能合并-i又能评估-r 六级指标还能溯源.tracking。三者里只有 GFFcompare 是带标尺的。我一般的项目流程是每个样本 StringTie 组装 →gffread做格式清洗 → GFFcompare 统一评估 → 用评估结果决定要不要回炉调参 → 最后用 GFFcompare 的合并输出去做下游定量。这个顺序能把组装质量差和下游分析差两件事有效隔离开出问题的时候定位成本低很多。2. 分类码全解每个字母背后都是生物学含义分类码是 GFFcompare 的灵魂也是被误解最多的地方。很多人看到输出里一堆j、一堆u就慌了其实每个字母对应的都是明确的几何关系理解了就不慌。2.1 匹配类、c、k是最理想的情况表示查询转录本和参考转录本的内含子链完全一致。注意这里强调的是内含子链而不是外显子边界——因为外显子边界是由内含子位置间接定义的只要所有内含子的起止点完全对上就判定为精确匹配。这一类转录本是我组装对了的直接证据。c表示查询转录本被包含在参考转录本之内而且内含子链是兼容的。典型的例子是参考里有一条长的多外显子转录本你组装出了它 3 端或 5 端截短的一小段。它不一定是错的可能是测序深度不够、或者这段本身就存在一个短的异构体。k是c的反向表示查询转录本包含了参考转录本。参考里有一条短的你组装出的这条把参考完整包住了还在两端各多出一段外显子。这类往往对应参考注释不全或者存在更长的异构体。这三个码合起来是判断召回率的核心依据。的数量直接决定转录本层的敏感度。2.2 同链重叠但不完全匹配m、n、j、e、om表示保留内含子retained intron。查询转录本跟参考有重叠但至少有一个参考内含子被你当成了外显子。生物学上这可能是真实的可变剪接事件也可能是组装器把未剪切的 pre-mRNA 或者基因组污染当成了成熟 mRNA。大量出现m是一个值得警惕的信号。n是部分重叠且完全没有内含子链匹配通常出现在外显子边界差异很大的场景。j是多外显子转录本里至少有一个剪接位点junction对上了参考但整条链对不齐。这个码在实际项目里出现频率非常高说明你的外显子边界对了一部分错了一部分。如果j占比特别高八成是组装器的边界校正参数没调好。e是单外显子转录本跟参考外显子有重叠同时还咬进了参考内含子至少一段区域。文档里明确说过这类很可能是 pre-mRNA 片段。o是同链上其他形式的外显子重叠属于沾边但不典型的一类。2.3 反向链、内含子区与基因间区x、s、y、i、ux表示与参考转录本在反向链上有外显子重叠。s表示反向链上内含子区域有重叠。这两个码如果大量出现通常意味着链特异性建库出了问题或者组装时链信息丢失了——这是一个非常强烈的流程报警信号比任何指标都灵敏。y表示查询转录本把某条参考转录本完整地包含在自己的内含子区域里。i表示查询转录本完全落在参考转录本的内含子内部。这两个码常出现在基因组注释比较稀疏的物种里因为那些内含子区域其实藏着还没被注释的小基因或非编码转录本。u是 intergenic完全落在基因间区跟任何参考转录本都不沾边。u不一定是错的——新转录本发掘的目标就藏在这里——但它也是假阳性的重灾区必须配合表达量、编码潜力和实验验证来判断。把上面这些整理成一张速查表贴在显示器边上会很有用分类码几何关系常见生物学解释需要警惕的程度内含子链完全一致已注释转录本被正确重建无c被参考包含截短的异构体或组装不完整低k包含参考更长的异构体或注释缺失低m有内含子被保留真实保留事件或 pre-mRNA 污染中高n部分重叠无内含子链匹配边界差异大中j至少一个剪接位点匹配外显子边界精度不足中e单外显子咬进内含子疑似 pre-mRNA 片段中o同链其他外显子重叠结构异常或注释不全中p无重叠但距离很近疑似聚合酶通读中r近距离但非通读模式重复序列或假阳性中x反向链外显子重叠链信息错误高s反向链内含子重叠比对错误或链信息错误高y参考落在查询内含子里注释缺失或嵌套基因低i落在参考内含子里未注释小基因低u基因间区全新转录本或假阳性需逐条验证2.4 从分类码分布反推组装问题这一步是真正的经验活。我一般不看单个转录本的码而是看分布。经验值上一个质量过关的人类或拟南芥组装加上c、k、j这几类应该占到总查询转录本的多数u的占比在单样本组装里通常不会太夸张。如果u一下子飙到三成以上第一反应应该是参考注释版本对不对、染色体命名是否一致而不是兴奋地以为自己发现了大量新基因。反过来如果i和y明显偏多那要看看参考注释是不是太旧了。老版本注释里很多基因间区后来被证明是有转录活性的这种情况下i/y多反而是参考注释需要更新的信号而不是我的组装有问题。3. 实操从安装到跑通第一个比对3.1 环境准备与安装最省事的方式还是走 conda依赖链它会自己处理conda create -n gffcmp -c bioconda -c conda-forge gffcompare conda activate gffcmp gffcompare --version如果想用最新版本或者要改源码可以从项目仓库拉下来自己编译git clone 项目仓库地址 cd gffcompare make release ./gffcompare --version编译出来的二进制是静态链接的直接拷到别的机器上也能跑这点在集群环境下很实用——不用每台节点都装一遍 conda 环境。我自己的习惯是把编译好的gffcompare单独拷一份到共享目录然后在 PBS/Slurm 脚本里用绝对路径调用避免环境变量污染带来的诡异问题。注意GFFcompare 的版本号会影响分类码的统计口径。跨项目比较指标时务必确认两个结果的版本号一致否则那些小数点后一位的差异可能纯粹来自版本差异。3.2 输入文件准备与格式陷阱GFFcompare 吃两种输入查询文件一到多个 GTF/GFF和参考文件-r指定。参考文件必须是带注释的GTF 或 GFF3。如果给的是 GFF3加-G参数告诉工具这是通用 GFF 格式。这里有个坑不同来源的 GFF3 对外显子属性的写法不一样有的用Parent有的用transcript_id格式不统一会直接导致解析失败或者转录本被拆散。我的做法是先用gffread统一转成 GTF 再用gffread annotation.gff3 -T -o annotation.gtf查询文件这边必须保证每条转录本有唯一的transcript_id且对应的gene_id存在。StringTie 的输出默认满足这个条件但如果你手工改过 GTF很容易把这两个属性漏掉或者写错层级结果是 GFFcompare 报出一堆transcript without gene的警告指标全废。另一个高频坑是染色体命名不一致。参考注释里写的是chr1你的组装结果里写的是1结果就是所有转录本全部落到u里指标惨不忍睹。跑之前先做一次命名核对cut -f1 query.gtf | sort -u | head cut -f1 annotation.gtf | sort -u | head两边的输出对不上就先做重命名别急着往下跑。3.3 命令拆解与关键参数最基础的比对命令长这样gffcompare \ -r annotation.gtf \ -o cmp_result \ query.gtf-o指定输出前缀所有输出文件都会带上这个前缀。跑完之后你会拿到cmp_result.stats、cmp_result.tracking、cmp_result.tmap、cmp_result.refmap、cmp_result.annotated.gtf这几个文件。几个我常用的参数组合值得展开说gffcompare \ -r annotation.gtf \ -R \ -e \ -s \ -d 100 \ -p 0.5 \ -o cmp_result \ query.gtf-R让工具只考虑那些和查询有重叠的参考转录本。这个参数在参考注释特别臃肿比如包含大量未验证转录本的时候很有用能把敏感度算得更干净——相当于把评估范围收窄到你本来有可能组装出来的那部分。-e开启外显子层级的精确评估。默认情况下 GFFcompare 主要看内含子链加上-e之后会对每个外显子的边界单独计数指标会变得更严格也更接近真实的结构准确度。-s是忽略链信息。除非你的建库确实是非链特异性的否则不要加这个参数。如果发现加了-s之后指标突然变好那说明你的链信息有问题这本身就是一个需要排查的信号而不是靠-s掩盖过去。-p控制最小重叠比例-d控制p/r这类近邻分类的距离阈值单位 bp。这两个参数在小基因组或者基因密集的物种里要适当调不然相邻基因之间会互相干扰。3.4 合并模式-i的正确打开方式多样本合并不是把多个 GTF 写在命令行上而是准备一个列表文件ls sample*.gtf gtf_list.txt gffcompare \ -r annotation.gtf \ -i gtf_list.txt \ -o merged \ --no-merge等一下这里有个容易搞反的地方-i提供的列表在合并模式下会被当成一组需要归并的输入。如果你只是想对每个样本单独评估、不想合并就别加-i改成循环逐个样本跑for gtf in sample*.gtf; do prefix$(basename $gtf .gtf) gffcompare -r annotation.gtf -o cmp_${prefix} $gtf done合并模式下GFFcompare 会把结构相同或高度相似的转录本归入同一个基因座locus并在 .tracking 里记录来自哪个样本的哪条转录本被归到了哪里。这一步的输出是后续做差异转录本表达分析的基础。提示合并模式跑大样本集比如超过 20 个样本时内存占用会明显上升建议在集群上给足内存或者分批合并后再做一次总合并。4. 输出文件逐个拆开看4.1 .stats六级指标怎么读.stats是所有人第一眼看的地方但它也是最容易被误读的地方。它的结构大致是这样# Summary for dataset: query.gtf # # Query mRNAs : 45231 in 28900 loci (32100 multi-exon transcripts) # (4210 multi-transcript loci, ~1.6 transcripts per locus) # Reference mRNAs : 61200 in 34500 loci (55800 multi-exon) # Super-loci w/ reference transcripts: 25100 #-----------------| Sensitivity | Precision | Base level: 92.1 | 88.4 | Exon level: 74.3 | 71.9 | Intron level: 86.5 | 84.2 | Intron chain level: 55.8 | 52.1 | Transcript level: 48.9 | 46.3 | Locus level: 61.2 | 59.7 | # Matching intron chains: 34100 Matching transcripts: 29900 Matching loci: 20600先看最上面几行的数量信息。Query mRNAs是查询里的转录本总数括号里是其中多外显子的数量再下面一行是每个基因座平均几条转录本。这几个数字能帮你快速判断组装结果是不是太碎——如果一个基因座平均有五条以上转录本多半是组装器过度拆分或者样本里确实有很强的可变剪接。Reference mRNAs是参考注释的规模Super-loci w/ reference transcripts表示有多少个超级基因座里出现了参考转录本这个数字和后面的 Locus level 指标是配套看的。中间那六级指标是最核心的下一节专门拆。底部三行是绝对计数匹配上的内含子链数、匹配上的转录本数、匹配上的基因座数。这三个数字配合上面的比例看能防止你被小样本的百分比误导——比如一个只有几百条转录本的小注释敏感度 90% 和敏感度 50% 的绝对差距可能只有几百条。4.2 .tracking转录本溯源的核心.tracking是我个人用得最多的输出文件。每一行代表一个查询转录本在合并模式下可能是一组被归并的查询转录本记录内容包括它的查询转录本编号、所属查询基因编号、在参考里落到的参考基因编号和参考转录本编号以及分类码。最后一列还会带上这一行聚合了哪些原始转录本的信息。有了这个文件你可以非常方便地做几件事用awk筛出所有u分类的行快速导出候选新转录本列表筛出所有来自某个样本的行看看这个样本贡献了多少独特转录本或者把分类码当成分组变量统计每个样本的码分布做样本间的一致性比较。我常用的一个统计命令awk {print $5} merged.tracking | sort | uniq -c | sort -rn输出就是分类码的频次分布一眼就能看出整体结构。4.3 .tmap 和 .refmap.tmap记录的是参考转录本和查询转录本的对应关系.refmap是反向的记录。两个文件配合使用好处是可以双向追溯想知道某条参考转录本被哪些查询转录本匹配上了查 .refmap想知道某条查询转录本匹配到了哪些参考转录本查 .tmap。这两个文件在调试的时候特别有用。比如你发现 Locus level 的敏感度很低可以从 .refmap 里筛出那些完全没有查询匹配的参考转录本然后去看它们有什么共同特征——是不是都特别长是不是都是低表达基因是不是都集中在某些染色体区域这种模式化的排查比盯着一个汇总数字瞎猜高效得多。如果只关心转录本比对不在乎这些映射关系可以加-T参数跳过这两个文件的生成能省一点磁盘和时间。4.4 .annotated.gtf 与 .loci.annotated.gtf是把你的查询转录本加上分类码和参考对应关系之后重新输出的 GTF。这个文件的好处是可以在 IGV 里直接加载边看比对边看注释尤其适合验证那些分类码比较奇怪的转录本。.loci文件需要加-L参数才会生成汇总了基因座层面的信息包括每个基因座的坐标、包含哪些转录本、参考上对应什么。做基因座层级的差异分析时这个文件比转录本层级的更方便。5. 指标怎么算Sn 与 PPV 的数学和陷阱5.1 六级指标的逐级含义理解这六级的关键在于区分比较的对象和比较的严格程度。Base level碱基层是最宽松的。它只看查询转录本覆盖的碱基里有多少落在参考外显子上反过来说参考外显子有多少碱基被覆盖。这个指标几乎不会低因为只要位置大差不差碱基就是重叠的。它的最大问题是会把内含子保留的错误完全掩盖——你把一个内含子当成外显子碱基照样落在参考的某段区域上层级不限的话照样算覆盖。Exon level外显子层要求外显子边界相对准确是全等匹配的计数。它比碱基层严格得多。Intron level内含子层看的是单个内含子的起止点是否完全一致。这个层级对组装器的剪接位点识别能力非常敏感。Intron chain level内含子链层要求整条转录本的所有内含子都匹配但不要求转录本的首尾外显子边界完全一致。这是区分组装得差不多和组装得精准的分水岭。Transcript level转录本层最严格要求转录本的完整结构包括首尾外显子边界都和参考一致基本等同于分类码所代表的情况。Locus level基因座层在基因座这个更粗的粒度上算匹配比转录本层宽松。把六级的敏感度从碱基层往转录本层排下来通常会看到一条明显的下降曲线比如 92% → 74% → 86% → 56% → 49%。这条曲线的形状本身就携带信息如果内含子层的敏感度显著高于外显子层说明你的剪接位点识别得不错但首尾外显子边界偏了如果内含子链层比内含子层掉得特别狠说明你有大量转录本对了一部分内含子这在分类码上就体现为大量j。5.2 为什么 Base level 的精确度会虚高这是被引用最多也最容易误导人的一个数字。碱基层精确度高可能只是因为你的组装结果里绝大多数碱基都落在基因区——而基因区在整个基因组里占比不高所以粘上去就算对。我见过有人拿着 Base level 的 95% 对外宣称组装质量极高结果 Transcript level 只有 40%。这两个数字不矛盾它们衡量的是完全不同的东西。汇报的时候一定要同时给出至少三个层级我自己习惯是给 Exon、Intron chain、Transcript 这三个分别代表局部准不准整体结构对不对转录本找全没找全。5.3 跨样本、跨工具比较时的注意事项想拿 GFFcompare 的结果去比较不同工具比如 StringTie vs Scallop或者不同参数的好坏有三个前提必须满足。第一参考注释必须完全一致。不同版本的注释规模差很多敏感度的分母都不一样直接比毫无意义。第二参数必须一致。有没有加-e、-R、-s会显著影响指标数值。第三要结合绝对数看。一个工具可能敏感度高但精确度低说明它召回多但假阳性也多另一个反过来。单看某一个指标很容易得出片面结论。我一般的做法是画一张散点图横轴精确度、纵轴敏感度每个工具/参数组合一个点看得一目了然。注意评估结果的好坏是相对参考注释而言的。如果参考注释本身就不全比如某些物种注释质量很差那么组装结果里大量出现的u和i可能反映的是注释的缺口而不是组装的问题。这一点在非模式生物项目里尤其重要。6. 常见问题排查实录6.1 匹配率异常低的五个常见原因按我踩坑的频率从高到低排参考注释版本或来源不匹配。最常见没有之一。同一物种不同数据库的注释染色体命名、转录本编号体系都不一样。解决办法就是前面说的跑之前先用cut -f1核对染色体名。链信息丢失或被忽略。如果你的建库是链特异性的但组装时没有正确传递链信息会直接产生大量x、s。检查一下组装步骤有没有对应参数StringTie 的--rf或--fr。GTF 属性格式错误。transcript_id和gene_id缺失或者写在了错误的层级会导致转录本被拆散或者合并错误指标全线崩塌。组装器输出的是 GFF 而非 GTF。忘了加-G或者反过来多余地加了-G都会导致解析异常。参考注释包含大量未验证转录本。有些注释文件把预测、未验证的转录本也放进去了导致分母虚大敏感度自然被拉低。这种情况可以配合-R参数缓解。6.2 内存与运行时间问题GFFcompare 单次比对的耗时主要跟转录本数量成正比内存则跟基因座的数量和复杂度相关。单样本比对一般几秒到几十秒就完了真正吃资源的是几十个样本的合并。我实测过 30 个人类样本合并峰值内存大概要用到十几 GB 级别如果集群单节点内存限制比较紧建议分批合并。另外一个容易忽略的耗时来源是参考注释特别大的时候。如果注释文件有上百万条记录光是解析就要花不少时间。这种场景下可以先把参考里明显不会匹配上的转录本比如非目标染色体上的过滤掉能省下可观的运行时间。6.3 分类码分布异常的速查表现象可能原因排查动作u占比超过 30%参考版本不符、染色体命名不一致核对两侧染色体名和注释版本大量x/s链信息错误、建库类型配置错检查组装参数里的链特异性设置大量mpre-mRNA 污染、内含子保留事件检查文库是否有基因组污染看抽样比对大量j外显子边界精度差调组装器的边界校正参数增大测序深度大量i/y参考注释偏旧内含子区有未注释基因考虑更新注释版本再做评估数量极少但 Base level 很高结构对不齐但位置重叠重点看 Intron chain 和 Transcript 两级6.4 一个我踩过的具体坑有一次评估一个植物样本u分类占比高达 40%但碱基层敏感度有 90%。第一反应是参考注释有问题核对了版本和染色体命名都没错。后来发现是查询 GTF 里有一部分转录本的起始位置用了负坐标或者超出染色体长度这些记录被解析后落到了无效区域。原因是上游组装时用的 BAM 里混进了一段拼接错误的比对记录。把这类异常记录过滤掉之后u的比例直接掉到了 15%。这个坑教给我的经验是拿到组装 GTF 之后先做一次基本的坐标合法性检查比跑完评估再去反查要省事得多。简单的检查可以这样awk $4 0 || $5 $4 {print} query.gtf | head awk $4 1000000000 {print} query.gtf | head不同物种的染色体长度上限不一样上面第二个命令的阈值要按实际情况改。这一步花不了几秒钟但能省掉后面几小时的排查。7. 把 GFFcompare 嵌进自动化流程7.1 多样本批量评估脚本单个样本手动跑没问题样本一多就必须脚本化。我自己的评估脚本大致长这样#!/bin/bash set -euo pipefail REFannotation.gtf OUTDIRgffcmp_reports mkdir -p $OUTDIR for gtf in assemblies/*.gtf; do sample$(basename $gtf .gtf) echo Processing $sample gffcompare \ -r $REF \ -e \ -o $OUTDIR/$sample \ $gtf done # 汇总所有样本的六级指标 for stats in $OUTDIR/*.stats; do sample$(basename $stats .stats) echo $sample grep -E Transcript level|Intron chain level|Exon level $stats doneset -euo pipefail这一行别省。GFFcompare 在某些输入异常的情况下会静默失败或者输出残缺的 .stats用严格模式能第一时间暴露问题。7.2 从 tracking 文件挖可变剪接信息合并模式产出的 .tracking 文件是可变剪接分析的一座金矿。它天然携带了哪些转录本属于同一个基因座、分别来自哪些样本的信息。你可以这样提取每个基因座的转录本数量分布awk {print $2} merged.tracking | sort | uniq -c | sort -rn | head -20输出就是转录本数量最多的前 20 个基因座。这些基因座往往是可变剪接最活跃的地方值得优先深入分析。再进一步把 .tracking 和表达量数据比如 StringTie 输出的 FPKM/TPMjoin 起来就能做转录本层级的差异分析。这里有个细节要注意GFFcompare 输出的转录本编号是它自己重新分配的跟原始样本 GTF 里的编号不一样join 的时候要拿 .tracking 里的原始转录本编号去关联别直接用合并后的编号。7.3 与下游分析的衔接评估完的下一步通常是三选一如果指标合格直接进入定量和差异分析如果指标偏低但还能接受挑出分类码为、c、k的转录本做保守分析如果指标很差回头调组装参数重来。我个人倾向于在项目前期就把这个分支逻辑写进流程里用一个阈值比如 Transcript level 敏感度低于某个值就报警自动卡住质量不合格的样本避免有问题的组装结果一路流向最终结论。这种质量门禁的思路在批量项目里能省掉非常多的返工。还有一点值得提醒GFFcompare 的评估是基于参考注释的所以它天生会低估那些真正的新转录本的价值。如果项目目标本身就是发掘新转录本那u和i这些分类不能当成错误而应该单独拉出来配合编码潜力预测、表达量、保守性分析做二次筛选。这时候 GFFcompare 更多是承担一个分流器的角色而不是评分器。我个人在实际项目里最大的体会是GFFcompare 的价值从来不在那个能写进 PPT 的百分比数字上而在于它把哪里对不上、为什么对不上这件事拆解到了可以逐条排查的粒度。一个跑得漂亮的项目评估报告里往往不是所有指标都高而是所有偏低的指标都能给出解释——要么是注释的缺口要么是物种特性要么已经定位到了上游的具体环节。能对每一条分类码说出理由比拿一个漂亮的平均分要有底气得多。