1. GFFcompare到底在解决什么比对难题
1.1 从一批注释文件堆到桌面说起
如果你做过转录组组装，多半经历过这个场景：StringTie 跑完几个样本，手里攒下五六个 GTF，每个里面转录本 ID 五花八门，同一个基因在不同样本里被切成好几段，外显子边界还差那么几个碱基。这时候导师或者同事丢过来一句"拿 GFFcompare 比一下"，你照着敲了命令，屏幕上刷过几行日志，目录里多出.stats、.tracking、.tmap、.refmap、.loci和一个.combined.gtf，然后……就卡住了。那几个字母=、c、j、u到底代表什么？敏感度和精确度两条数字怎么解读？u类占了一大半是好事还是坏事？
GFFcompare 就是干这件事的工具：把一份或多份转录本注释（GTF/GFF）互相比较，并且和参考注释比对，给出结构层面的分类、统计和评估指标。它最初脱胎于 Cufflinks 工具链里的 Cuffcompare，后来独立出来由 CCB（Center for Computational Biology, Johns Hopkins）维护，现在是 StringTie 生态里做组装评估的事实标准。搞懂它，你才能回答"我的组装到底好不好"这个问题，而不是只盯着 log 里一句 "done" 自我安慰。
我这篇不打算复述官方文档的参数列表——那种内容你随手gffcompare -h就能看到。我更想聊的是：那套编码体系背后的判定逻辑是什么、每个输出文件真正该怎么用、参数在什么场景下会改变结论、以及我实际踩过的那些坑。文章面向已经会跑命令行、但被 GFFcompare 结果绕晕的转录组分析人员，也适合刚接手组装项目、想把评估做扎实的同学。版本差异我会专门提醒，因为它确实坑过我不止一次。
1.2 为什么不能直接 diff 两个 GTF 文件
很多人第一反应是diff a.gtf b.gtf，或者写个脚本比transcript_id。这条路走不通，原因有三层，理解了这三层，你才明白 GFFcompare 存在的必要性。
第一层是坐标容差。两个组装器对同一个外显子边界的判断可能差 1 到 50 个碱基，尤其在外显子-内含子交界处，测序读段跨 junction 的证据强弱不同，边界就会抖。如果做严格字符串比对，这些"几乎一样"的转录本会被判成完全不同，结果里全是假阴性。GFFcompare 用了一套容差机制（比如-d、-e控制距离），把边界接近的转录本归到一起。
第二层是结构等价而非文本等价。一条转录本的本质是它的内含子链（intron chain），也就是外显子边界的序列组合。两条转录本外显子数目一样、每个 junction 坐标一致，就是结构等价，哪怕transcript_id完全无关、起点终点差几个碱基。GFFcompare 的核心比对对象就是内含子链，而不是字符串。
第三层是同一位点存在多转录本。一个基因位点可以产出多个剪接异构体，它们共享部分外显子、又各自有独特外显子。这种"部分重叠"的关系没法用布尔值回答，必须用一套分级编码来描述"重叠到什么程度"。这就是=、c、j、m这一串字母的来历。
所以，GFFcompare 解决的不是"两个文件一不一样"，而是"两份注释之间，每一条转录本在结构上如何对应"。这个定位转变过来，后面所有细节都会顺很多。
1.3 GFFcompare 内部干了三件事
很多人把 GFFcompare 当成一个黑盒，其实它一次运行做了三件相对独立的事，拆开看会清晰非常多。
第一件是合并（merge/collapse）。当你给它多个输入 GTF 时，它先把所有输入里的转录本放在一起，做去冗余，产出一个非冗余的"并集"集合，也就是.combined.gtf里的TCONS_xxxx转录本。注意：这一步是先于比对发生的。也就是说，如果你传了 3 个样本，.stats里"Query mRNAs"的数字对应的是并集转录本数量，不是三个样本数量之和。这个细节我第一次用时没意识到，白白困惑了半天。
第二件是比对（compare）。把并集（或者你给的单个文件）和-r指定的参考注释逐条比对，按容差规则判定结构关系，给每条转录本打上分类编码。
第三件是统计（stats）。基于上面的比对结果，在碱基、外显子、内含子、内含子链、转录本、位点六个层级上分别算出敏感度（Sensitivity）和精确度（Precision），并统计漏掉/新增的外显子、内含子、位点数量。
提示：如果没有指定
-r，第三件统计里就不会有敏感度和精确度，只剩两两之间的分类关系。想评估组装质量，-r基本是必给的。
理解了这三件事的边界，你就知道：.combined.gtf是合并的产物，.tracking、.tmap、.refmap、.loci是比对的产物，.stats是统计的产物。不同文件对应不同阶段，互不混淆。
2. 那套字母编码才是 GFFcompare 的通用语言
2.1 编码的优先级：先认亲，再谈别的
GFFcompare 给每条输入转录本打出的是一个单字符分类编码，外加可能的前缀（比如=就是最高等级）。关键点在于：编码不是叠加的，而是按优先级选一个。两条转录本可能同时满足多个关系的条件，GFFcompare 会按固定顺序挑优先级最高的那个作为最终编码。
这个优先级顺序大致是：
=>c>k>m>n>j>e>o>p>s>x>i>y>u
为什么要有优先级？因为一条转录本可能既和参考某条转录本共享一个 junction（满足j的条件），又整体被参考包含（满足c的条件）。这时候显然应该报"被包含"这个更强的结论。优先级本质上是从强到弱描述结构相似性的一个刻度表。
理解了这个排序，你读.tracking时就不会疑惑"为什么它明明是 novel，却被标成了c"。因为c的优先级更高，说明它确实被某条参考转录本完整包含，只是内部结构可能还有差异，但分类上按包含处理。
2.2 匹配类编码：=、c、k
这三个是最高优先级的编码，代表"和参考有明确的容纳或匹配关系"。
=表示内含子链完全匹配。多外显子转录本要求每一段内含子的起止坐标都一致，链方向一致；单外显子转录本要求外显子边界落在容差之内（或完全一致，取决于版本）。这是最强的一致性，通常用来统计"完全被参考支持的转录本"数量。做组装评估时，=数量除以参考转录本总数，就是转录本层级的敏感度来源之一。
c表示输入转录本被参考转录本包含（contained）。也就是说，输入的内含子链是参考内含子链的一个子集——输入可能少了一两个外显子，但保留的那部分 junction 都跟参考对得上。这种转录本往往是参考里已经存在、但被组装成了更短版本的情况，或者参考本身有更长的异构体。
k表示参考转录本被输入包含（reverse containment）。方向反过来：输入更长，参考是它的子集。这种情况常见于你把两个注释版本对比时，新版本把两个旧异构体连成了一条更长转录本。
这三个的区别用一句话记：=是相等，c是输入被参考包住，k是参考被输入包住。方向感很重要，很多人在读.tmap时会记反。
2.3 结构变体类编码：m、n、j、e、o
这一组是"有关系但不等同"的地带，也是组装结果里数量最多的一批。
m是内含子保留（retained intron）。输入的转录本里至少有一段内含子，在参考里是作为外显子存在的。这在真核生物里很常见，尤其在某些组织或胁迫条件下会发生可变剪接导致的内含子保留。GFFcompare 把这类标成m，提醒你这里可能存在生物学上的剪接事件，也可能只是组装噪声。
n是新异构体（none，也有说 novel isoform）。两条转录本的内含子链互不包含，但至少共享一个剪接位点。翻译成人话就是：这条输入的转录本和参考某条转录本用的是同一套剪接位点的一部分，但组合出了参考没有的新结构。这通常是真实的新剪接异构体的信号，值得细看。
j是多外显子、至少一个 junction 匹配。比n更弱一点，表示它和参考共享了至少一个剪接位点，但整体结构差异较大。很多组装出来的 novel 转录本落在这个类。
e是单外显子转录本，部分覆盖参考的内含子。这类比较尴尬——单外显子转录本本身就难以判断，它可能是真实的单外显子基因，也可能是基因组 DNA 污染、或者未剪接的前体 RNA。GFFcompare 把这种"跨在内含子上"的单外显子单列出来，方便你后续过滤。
o是其他同链重叠。凡是落在同链、有重叠、但前面几个类都不满足的，都归到这里。这是一个兜底类，信息量不大，主要用来判断"有没有关系"。
我一般会重点盯=、n、m三类的绝对数量和占比。n和m太高，说明组装器在参考之外发现了大量结构，要么是真发现，要么是噪声；=太低，则说明组装和参考对不齐。
2.4 反向与内嵌类编码：s、x、i、y
这一组是最容易被误读的，因为它们大多暗示"方向"或"嵌套"出了问题。
s表示反链上的内含子匹配。也就是说，转录本和参考共享一个 junction，但链方向相反。这几乎总是坏消息——要么是链特异性建库处理时方向搞反了，要么是注释本身链信息有误。如果你的链特异性数据里s类异常多，第一个要怀疑的就是链方向参数。
x是反链上的外显子重叠。同样提示链方向问题。
i是完全落在参考内含子内部（intronic）。这类转录本在参考里找不到对应的外显子结构，整条都嵌在某个参考基因的内含子里。有可能是新的独立基因、可能是内含子里的非编码转录本、也可能是注释不完整导致的假象。GFFcompare 提供-C参数可以把这类直接丢掉。
y是转录本的内含子包含了参考（contains reference within intron）。方向和i反过来，是输入的内含子把参考整条包进去了。
s、x两类一旦出现明显数量，优先排查链方向；i、y两类则要结合基因组注释的完整度来判断。
2.5 无中生有与特殊类：u、r、p
u是unknown / intergenic，表示这条转录本和参考没有任何重叠，落在基因间区。这是最能引起误解的一个类。
r是重复序列重叠。只有在提供了基因组序列（-s参数）时才可能被识别。它表示这条转录本和基因组里的重复元件有重叠，很可能来自转座子或低复杂度区域，可信度存疑。
p是可能的聚合酶通读（polymerase run-on）。转录本和参考没有实际重叠，但距离很近（在-d指定的范围内）。这类转录本很可能是上游基因转录没有正常终止、一路读下去产生的，生物学意义有限，但也要看具体距离。
u类需要特别说清楚：它不等于垃圾。u只表示"在给定参考注释里找不到对应关系"。如果你的参考注释本身不完整（比如只包含蛋白编码基因，没有 lncRNA 注释），那么一批真实的 lncRNA 组装结果会全部落进u类。我看到过有人一看u类占比高就直接判定"组装失败"，这是典型误判。正确做法是把u类转录本单独提取出来，做序列比对或结构域搜索，判断它们是不是新的非编码转录本。
| 编码 | 含义 | 通常怎么解读 |
|---|---|---|
= | 内含子链完全匹配 | 被参考完全支持 |
c | 被参考包含 | 组装短了或参考更长 |
k | 包含参考 | 组装长了或参考更短 |
m | 内含子保留 | 可能有真实剪接事件 |
n | 新异构体 | 潜在新剪接，重点看 |
j | 至少一个 junction 匹配 | 结构差异较大 |
e | 单外显子覆盖内含子 | 需过滤或核实 |
o | 其他同链重叠 | 兜底类 |
p | 可能通读 | 距离近但无重叠 |
s | 反链内含子匹配 | 链方向疑似错误 |
x | 反链外显子重叠 | 链方向疑似错误 |
i | 落在参考内含子内 | 内含子区转录本 |
y | 内含子包含参考 | 嵌套关系 |
u | 与参考无重叠 | 基因间区，未必是垃圾 |
r | 与重复序列重叠 | 需-s才能识别 |
3. 六个输出文件到底哪个该看
3.1.stats：六层刻度的敏感度与精确度
.stats是我打开的第一个文件，也是信息密度最高的一个。它由几块组成：先是几个总览数字（Query mRNAs、Reference mRNAs、超级位点数量），然后是六个层级的敏感度和精确度，最后是错配的明细统计。
六个层级从细到粗分别是：Base level（碱基层级）、Exon level（外显子层级）、Intron level（内含子层级）、Intron chain level（内含子链层级）、Transcript level（转录本层级）、Locus level（位点层级）。
敏感度和精确度的定义必须先说清楚，否则数字读反是常事：
- 敏感度 Sn = TP / (TP + FN)，衡量参考里有多少被你的组装找到了。
- 精确度 Pr = TP / (TP + FP)，衡量你组装出来的有多少是靠谱的。
以转录本层级为例：TP 是和参考完全匹配（=）的转录本数，FN 是参考里没被匹配上的转录本数，FP 是你组装出来但参考里没有的转录本数。所以敏感度低意味着"漏了"，精确度低意味着"多了"。
层级越粗，数字通常越高，这是正常的。碱基层级只要碱基重叠就算对，容易虚高；转录本层级要求整条结构一致，数字必然低一截。看结果时一定要认准层级，我见过有人拿碱基层级的 99% 去汇报，结果被问转录本层级哑口无言。
.stats后半段的 Missed exons / Novel exons / Missed introns / Novel introns / Missed loci / Novel loci，则是把错配拆到具体类别，方便定位到底是边界问题还是结构问题。如果 Missed introns 特别多，说明组装没找到应有的剪接；如果 Novel introns 特别多，说明组装在参考之外造出了很多剪接结构。
3.2.tracking：每条转录本的户口本
.tracking是我认为最被低估的文件。它以并集转录本（TCONS_xxxx）为单位，一行记录一条转录本在不同输入样本和参考里的对应关系。列的结构大致是：第一列并集转录本 ID，第二列所属位点 ID（XLOC_xxxx），接着每个输入样本一列，记录该样本里对应的原始转录本 ID，最后一列是参考里对应的转录本及其分类编码。
这个文件的价值在于跨样本追踪。想知道某个新发现的异构体在哪几个样本里都组装出来了？查这一行，几个样本列都有值，说明它是可重复的；只有一个样本列有值，那就要怀疑是不是噪声。想做差异剪接分析、或者手动筛 novel 转录本，从.tracking入手比从.tmap高效得多。
我常用的一个操作是：筛出所有编码为n（新异构体）、并且在至少两个样本中都出现的转录本，这些是可信度最高的候选新剪接事件。用简单的awk过滤就能做，不需要写复杂脚本。
3.3.tmap与.refmap：方向相反的两张映射表
这两个文件容易搞混，因为它们字段结构几乎一样，方向却完全相反。
.tmap是从输入转录本出发，列出每条输入（query）转录本最匹配的参考转录本，字段包括参考基因 ID、参考转录本 ID、分类编码、查询基因 ID、查询转录本 ID、外显子数、FPKM/TPM、覆盖度、长度等。想回答"我这条组装转录本对应参考的哪条"，查.tmap。
.refmap是从参考转录本出发，列出每条参考转录本对应的所有输入转录本。想回答"参考里的这条基因，我组装出了几个版本"，查.refmap。评估"参考基因的召回情况"时，.refmap更顺手。
两个文件里都有class_code列，这就是第 2 节那套编码的来源。FPKM、TPM、cov这几列只有在你输入的是 StringTie 输出（带这些属性）时才有意义，输入的是纯 GTF 时可能为空。
3.4.loci与.combined.gtf：位点视角与合并结果
.loci文件以位点为单位，给出每个超级位点（super-locus）包含哪些转录本、和参考的关系。做位点层级的统计或者想快速定位"哪些区域是全新的"，这个文件很方便。
.combined.gtf则是去冗余之后的并集注释，里面是TCONS_xxxx。很多人把这个文件当成"最终组装结果"直接拿去做下游。这没问题，但要清楚一件事：它是按容差规则合并过的，转录本边界可能被你原来的单样本结果略有调整。如果你对边界精度有严格要求，得回头核对合并前后的差异。
另外提一句，.combined.gtf的转录本 ID 前缀可以通过-p参数自定义。默认是TCONS，和 StringTie 的--merge保持一致。如果你做的是多项目对比，建议改一下前缀，否则不同项目的 ID 撞车，下游脚本解析时会很痛苦。
4. 参数怎么配才不白跑
4.1 基础命令骨架
最朴素的用法就是单文件对参考：
gffcompare -r reference.gtf -o mycmp assembled.gtf-r指定参考，-o指定输出前缀（默认gffcmp），最后跟输入。跑完得到mycmp.stats、mycmp.tracking等一套文件。
多文件的情况：
gffcompare -r reference.gtf -o mycmp sample1.gtf sample2.gtf sample3.gtf这时它会先合并再去比对，.stats里的 Query 数量对应合并后的并集。文件多了命令行会长，可以用-i传一个列表文件，每行一个 GTF 路径，清爽很多。
这里有个很实际的取舍：你要评估的是单个样本的质量，还是整体的质量？如果是前者，应该一个样本单独跑一次，得到各自的敏感度/精确度；如果是后者（比如做 StringTie--merge之后的共识注释评估），才把所有样本一起传。混在一起跑，单样本的问题会被平均掉，看不出差异。我刚开始做的时候就把两种混了，导致某个样本的组装问题一直没暴露出来。
4.2 距离参数-e与-d
-d控制TSS（转录起始位点）聚类的最大距离，默认 100 bp。它影响的是把哪些转录本算作共享同一起始位点——在判断p类（聚合酶通读）和位点合并时起作用。-e控制外显子合并/邻近外显子的最大距离，也默认 100 bp，主要影响单外显子转录本的归并。
这两个参数调大，会把更多"差不多"的转录本归到一起，编码往更强的方向走（更多=、c），敏感度数字会好看，但可能把真实的结构差异掩盖掉。调小则相反，能区分更细的结构，但会把边界噪声放大成假差异。
我的经验是：除非你有明确的生物学依据，否则别动默认值。100 bp 是经过大量数据验证的折中。真有特殊需求（比如基因组特别紧凑的物种），调完后一定要对比一下参数变化前后的.stats，看编码分布怎么变。如果=数量突然暴涨，多半是容差太松了。
4.3 过滤类参数：-C、-M、-R这些开关
GFFcompare 提供了一批"过滤"参数，作用是把某些明显不重要或存疑的转录本从统计里剔除。用不用、怎么用，取决于你的分析目标。
-C会丢弃完全落在参考内含子里的输入转录本，也就是第 2 节讲的i类。如果你的参考注释已经很完整，只想看基因区的组装质量，加-C能让.stats更干净。但如果你怀疑参考漏注释了内含子区的转录本，就不能加。
-M忽略单外显子转录本。单外显子转录本在 NGS 数据里噪声很大，很多组装器会输出大量短的单外显子框。如果你只关心多外显子基因的结构，-M能显著提升精确度数字。代价是可能漏掉真实的单外显子基因。
-R则在有-r时，把参考限制到与输入有重叠的那部分再做统计。这个开关在"我只想评估我对已知基因的复现程度"时很有用，因为它排除了"参考里那些根本不该被表达检测到的基因"对敏感度的稀释。
需要提醒的是，不同版本的 GFFcompare 在部分过滤参数的语义上有细微差异。我遇到过升级版本后同一批数据.stats数字变化的情况。稳妥做法：升级后先用旧版本跑一遍已知数据做基准，确认数字解释没变再上生产。
注意：过滤参数会改变分母（统计基准），所以带过滤和不带过滤的结果不能直接横向比较。要么全程带，要么全程不带，别一会儿加
-C一会儿不加。
4.4 链与序列参数-s
-s用来指定参考基因组序列文件（FASTA）。它主要影响两件事：一是帮助判断链方向，二是启用重复序列重叠检测（r类）。如果你的数据是链特异性建库，或者你想知道哪些组装转录本落在重复区，这个参数就值得加。
代价是运行时间会明显变长，因为要读基因组、做序列比对。我在处理哺乳动物基因组时，加-s后运行时间从几分钟涨到将近半小时。所以平时做快速评估可以不加，只有在需要精细判断链方向或排查重复污染时才加。
链方向问题的典型表现就是第 2 节说的s、x类偏多。如果你的链特异性数据里这两类占比超过几个百分点，先别急着下结论，用-s重跑一次，看是不是链判断被数据本身误导了。
| 参数 | 作用 | 建议 |
|---|---|---|
-r | 指定参考注释 | 做评估时几乎必给 |
-o | 输出前缀 | 建议改，避免多项目撞名 |
-p | 并集转录本前缀 | 多项目场景建议自定义 |
-T | 不生成 tmap/refmap | 只要 stats 时可加，省时间 |
-i | 传入文件列表 | 多文件时用，命令行更清爽 |
-s | 参考基因组序列 | 判链/查重复时加，耗时会涨 |
-e | 邻近外显子最大距离 | 默认 100，非必要不动 |
-d | TSS 聚类最大距离 | 默认 100，非必要不动 |
-C | 丢弃落在参考内含子的转录本 | 参考完整时才用 |
-M | 忽略单外显子转录本 | 只看多外显子结构时用 |
-R | 参考限制到有重叠部分 | 评估已知基因复现时用 |
5. 踩坑实录与结果解读的坑
5.1 参考注释版本不对，全部白跑
这是最隐蔽也最致命的坑。你以为参考是GRCh38的注释，实际用的是GRCh37版本，坐标整条错位，结果.stats里敏感度低得离谱，编码一片u和o，你还在怀疑是不是组装器出问题了。
排查方法很直接：先用head看一下 GTF 的坐标范围和染色体命名。染色体命名不一致是重灾区——有的注释用chr1，有的用1，比对时字符串对不上，结果自然是全u。这种行为 GFFcompare 一般不会报错，它会默默把所有转录本当基因间区处理，特别坑。
我的做法是在跑之前固定做一次一致性检查：参考、组装、基因组三者的染色体命名必须统一，用cut -f1 reference.gtf | sort -u和组装文件对比一下，几秒钟的事，能省掉几小时的返工。
5.2 链特异性方向搞反
链特异性建库的dUTP协议方向，不同工具的处理约定不一样。如果建库方向在 StringTie 阶段就搞反了，组装出来的转录本链信息和参考相反，GFFcompare 就会报大量s、x类。
判断依据是：如果s加x占了显著比例，而你的建库是链特异性的，基本可以确定方向反了。修复方式是回到上游，调整 StringTie 的链特异性参数（--rf或--fr），重新组装再比。不要指望 GFFcompare 帮你修，它只负责报告。
这个坑我跟它纠缠过整整一个下午，最后发现是--rf和--fr用反了。提醒一句：这两个参数的语义要对着你建库试剂盒的说明书确认，别凭印象。
5.3 把u类当垃圾丢掉
前面提过一次，这里再强调一遍，因为它真的太常见。u类占比高，第一反应往往是"组装质量差"，然后直接把u类删掉。
但如果你的参考注释只覆盖了蛋白编码基因，那全长非编码 RNA、反义转录本、增强子 RNA 全都会落进u类。把这批直接丢掉，你等于扔掉了这次组装最有价值的新发现。
正确的处理方式是：把u类转录本单独提取出来，统计它们的长度分布、外显子结构、是否有多外显子剪接、是否在多个样本里可重复。如果它们结构完整、跨样本可重复、长度合理，那大概率是真实的新转录本，值得单独做下游验证。我手上就有一个项目，最后发出来的核心结论正是从u类里挖出来的。
5.4 单外显子转录本拉低精确度
单外显子转录本是精确度的"重灾区"。NGS 数据里，基因间区的单外显子组装框大量存在，它们落进u或o类，成了精确度公式里的 FP（假阳性），把精确度拉得很低。
这时候要区分：是精确度真的低，还是被单外显子框拖累了？最直接的办法是加-M重跑一次，对比加与不加的.stats。如果精确度从 60% 跳到 85%，说明问题主要出在单外显子上；如果变化不大，那才是多外显子结构本身有问题。这个对比实验我强烈建议每个项目做一次，能帮你快速定位问题方向，比盯着单一数字瞎猜强得多。
5.5 GTF 属性格式不合法导致静默出错
GFFcompare 对 GTF/GFF 的属性格式有一定要求，尤其是transcript_id和gene_id这两个字段。如果属性里少了transcript_id，或者引号、分号格式不规范，GFFcompare 可能不会明确报错，而是给出奇怪的结果——比如所有转录本都被当成独立的，或者统计数量对不上。
遇到"结果看起来不太对但没报错"的情况，我第一件事就是把输入 GTF 喂给gffread或者做个格式检查，确认属性完整。规范的做法是从源头保证——StringTie 输出的 GTF 一般是合规的，问题多出在手动拼接或者是第三方工具导出的注释上。
提示：养成习惯，跑 GFFcompare 前先
grep -c 'transcript_id' input.gtf，对比一下总行数，两者接近才说明每个转录本都有 ID。
5.6 敏感度和精确度看错了方向
最后一个坑是解读层面的。敏感度和精确度一高一低的时候，很多人第一反应是"整体质量不错"，但如果敏感度 90%、精确度 50%，实际含义是：参考里九成被你找到了，但你多报了一倍的东西。这在组装场景里可能是过度组装；反过来，敏感度低精确度高，则是漏报严重。
更细致的做法是看层级之间的落差。如果碱基、外显子层级都很高，但转录本、位点层级断崖式下跌，说明你的组装在局部是对的，但整体拼接结构不对——典型表现是转录本被拆成了好几段，或者多个基因被拼成一条。这种情况去查.tracking和.loci，往往能定位到具体的"断点"区域，那里可能存在重复序列或复杂的可变剪接。
6. 把它接进组装评估流水线
6.1 从 StringTie 到 GFFcompare 的完整链路
一个典型的组装评估流程大致是这样几段：先分样本用 StringTie 组装，得到一个样本一个 GTF；如果用--merge做共识，就先合并再评估；然后用 GFFcompare 对参考做比对，拿到统计；最后根据统计和编码分布做判断。
需要提醒的是，--merge后的共识注释再拿去做 GFFcompare 时，它的性质已经不是原始组装了——它已经做过一轮去冗余。所以这时候的敏感度/精确度更像是"共识注释对参考的覆盖度"，而不是"原始组装器的能力"。两者不能混为一谈。我做评估时通常会跑两轮：一轮是各样本单独比参考（看单样本质量），一轮是共识注释比参考（看整体覆盖），两组数字放在一起看才有全貌。
6.2 手算敏感度与精确度做交叉验证
虽然.stats直接给了数字，但作为分析人员，你最好能手算一遍验证，尤其是当你怀疑某个数字异常时。方法是从.tmap和.refmap里数编码：
- 参考转录本总数记为 R。
- 编码为
=的输入转录本数量记为 T。 - 转录本层级敏感度 Sn ≈ T / R（这里简化了，严格来说敏感度是按参考侧算匹配上的比例）。
- 转录本层级精确度 Pr ≈ T / (输入转录本总数)。
你自己算出来的数字如果和.stats差很多，多半是某些过滤参数或者容差设置改变了分母，值得回头核对。这招在我排查"为什么更新版本后数字变了"时特别有用。
另外，.stats里还会输出Matching transcripts和Matching loci的绝对值，这两个数字比百分比更实在，跨项目对比时我更倾向看绝对值。
6.3 和其他评估工具怎么搭配
GFFcompare 强在结构层面的比对，它不关心转录本表达量、不关心编码潜能。所以完整的组装评估通常还要搭配别的工具：
- 表达量一致性可以用 StringTie 的
-B输出配合其他量化工具核对。 - 编码潜能可以用 ORF 预测工具（如 TransDecoder 之类）来判断
u类转录本是不是有编码能力。 - 转录本完整性可以用 BUSCO 之类的标记基因方法来评估。
GFFcompare 的角色是给出"结构对不对"这个维度，其余维度交给别的工具。别指望一个工具把所有问题都回答了。我见过有人拿 GFFcompare 的精确度低就去否定整个组装，忽略了那批被否定的转录本可能正是最有价值的新发现。
我的习惯是：GFFcompare 报告里，先看六个层级的敏感度/精确度拿到整体印象，再重点看
n和u两类的绝对数量，最后结合.tracking判断候选转录本的跨样本可重复性。三步下来，一份组装的质量画像基本就清晰了。
最后分享一个我常用的小技巧：把.stats里的敏感度、精确度按层级做成一张表，重复跑不同参数组合，把结果竖着排在一起。参数（容差、过滤开关）对结果的影响一目了然，比一次跑一个来回对比高效得多。这套对比表我在每个组装项目里都会留一份，事后复盘时特别管用，也能帮你快速回答"这个数字为什么比上次高"这类问题。
