企业官网建设流程全解析

做基因组组装这些年，我最直观的感受是：长读长测序已经从少数实验室的“黑科技”变成了入门级标配。尤其是PacBio HiFi和ONT超长读取这两样东西，几乎撑起了现在高质量参考基因组的大半个江山。以前拼一个基因组，光学图谱、遗传图谱、BAC文库都得凑齐，现在如果你手上有30x以上的HiFi数据，再配一部分ONT超长读取，基本可以靠几台服务器就拼出一个相当漂亮的参考基因组。

这篇教程我打算完全按项目实战的流程来讲：测序到底该跑多少量、数据回来怎么清理、hifiasm怎么用、ONT超长读取在哪个环节介入、最后怎么评估组装质量。全程使用我平时做项目最常用的一整套命令和参数，不整花架子，保证零基础也能照着一步步跑通。适合正在准备测序方案的研究生，也适合刚拿到数据不知道怎么下手的生信新手。

1. 为什么HiFi和ONT超长读取要搭配使用

1.1 短读长组装的痛点在哪

做基因组组装，核心问题其实就一个：怎么把一大堆随机打断的DNA片段，恢复成原来那条完整的染色体序列。二代测序（Illumina）读长只有150 bp左右，虽然碱基准确度很高，但片段太短了。基因组里充满了各种重复序列，比如转座子、rDNA簇、着丝粒区域，这些区域的序列高度相似，短片段比对过去根本分不清谁是谁，组装软件只能“猜”，一猜就容易拼错或者拼断。

打个比方，短读长拼基因组就像玩一幅五千块的拼图，但每块拼图只有指甲盖大小，而且画面里有好几块几乎一模一样的天空。你能拼出大致轮廓，但很难把重复区域完整拼出来。这也是为什么早期用纯二代数据组装的基因组，N50往往只有几十kb，很多复杂区域是碎的。

1.2 HiFi数据强在精度

PacBio HiFi（High-Fidelity）读取的原理是滚环测序加多次共识校正。一条DNA模板在测序仪里被反复读取多次，最后合成一条高精度的一致序列（consensus read）。读长通常在10到25 kb，单碱基准确度可以达到Q20以上，也就是99%以上的准确率，好一点的run甚至能到Q30。

高精度带来的好处非常直接：组装结果的单碱基错误大幅下降，基因区域的结构准确度高。这也是为什么近年来几乎所有高质量参考基因组项目，都把HiFi作为主力数据。

但HiFi也不是万能的。它的读长虽然在几十kb级别，但对于基因组里那些“超长”的串联重复区，比如长达100 kb以上的rDNA簇、着丝粒卫星序列，HiFi读长不够跨越整个重复单元，组装时还是容易断掉。

1.3 ONT超长读取的杀手锏是长度

牛津纳米孔（ONT）测序最大的特点是读长没有理论上限。实际项目中，读取几十kb很常见，做到200 kb以上也完全可能，有些极限案例甚至拿到了Mb级的reads。这种超长读取在跨越长重复区域时优势巨大：只要一条read能从重复区域一端读到另一端，组装时就有信心把两侧序列连起来。

ONT的缺点是单链测序精度不如HiFi，原始reads经过basecalling之后平均准确率一般在Q10到Q20之间，错误类型多为插入缺失。如果只用ONT做全基因组从头组装，结果往往在碱基精度上打折扣，尤其影响基因组的编码区注释。

1.4 两条腿走路的分工逻辑

所以现在主流的策略是：精度交给HiFi，长度交给ONT超长读取。HiFi保证每个碱基都拼得准，ONT超长读取负责把HiFi连不起来的复杂区域“搭桥”接上。

用ONT超长读取做辅助还有一个好处，它是纯物理连接信息，不依赖参考基因组，可以真实反映目标基因组的结构。相比遗传图谱和光学图谱，ONT超长读取在分辨复杂结构变异、串联重复时更直接，数据产出周期也短得多。

2. 开工前的测序与数据规划

2.1 先估算基因组大小

测序深度怎么定，首先要看你的目标基因组有多大。最常用的办法是用k-mer谱图估计，工具可以用GenomeScope或者Jellyfish加GenomeScope2。简单说，就是拿一点二代测序数据（或者已有的试测数据），统计所有k-mer的出现频率分布，从峰值反推出基因组大小和杂合度。

如果没有试测数据，也可以参考同属物种的已知基因组大小。举个例子，如果目标物种是水稻，大概370 Mb；如果是番茄，约800 Mb；如果是某些两栖动物，可能动辄几个Gb。后面所有数据量的计算都依赖这个数字，所以第一步别偷懒。

2.2 HiFi测序跑多少倍深度

PacBio HiFi数据推荐深度是30到60x。最少不能低于20x，低于这个数组装连续性会肉眼可见地下降；而超过60x之后，边际收益就很小了，基本是浪费钱。

拿一个500 Mb的基因组来算：如果跑40x，需要的HiFi数据量就是500 Mb × 40 = 20 Gb。PacBio Sequel II/IIe平台单张SMRT Cell的HiFi产出大概在15到30 Gb之间，也就是说500 Mb基因组用一张cell跑40x左右是现实的。基因组更大的话，按比例增加cell数就行。

2.3 ONT超长读取怎么规划

ONT超长读取不需要像HiFi那样堆到很高深度。我自己的经验是，作为辅助数据，20到30x就足够发挥价值了。继续按500 Mb基因组算，20x就是10 Gb。ONTF那个单张PromethION Flow Cell产出可达100 Gb以上，但注意里面真正“超长”的高质量reads并没有那么多，所以重点不是总量，而是读长分布。

所谓“超长读取”，我一般期望reads的N50至少到30 kb以上，最好能到50 kb以上。如果能提取到足够多超过100 kb的reads，对跨越复杂区域的效果会立竿见影。

2.4 硬件与软件准备

软件环境我建议直接用conda管理，省的编译依赖搞到头大。先创建一个独立环境：

conda create -n genome python=3.9 -y conda activate genome conda install -c bioconda -c conda-forge hifiasm flye minimap2 racon busco quast seqkit filtlong nanoplot -y

如果电脑有NVIDIA显卡，ONT basecalling需要dorado，用conda或者从官方GitHub下载预编译包都行。硬件上，组装500 Mb左右的基因组，建议至少32核CPU、128 GB内存。如果基因组在1 Gb以上，内存和线程数都要往上加，尤其是hifiasm在构建图结构时对内存比较敏感。

3. 测序数据回来第一步：清理和质控

3.1 PacBio HiFi数据的基础处理

PacBio测序的交付物通常有两种形态：一种是原始的subreads BAM，需要自己用ccs生成HiFi reads；另一种是已经生成好的HiFi reads BAM或FASTQ。如果拿到的是subreads，跑一下：

ccs movie.subreads.bam movie.hifi.bam --min-rq 0.9 --min-length 500 --max-length 50000 -j 24

一般测序公司交付的HiFi数据已经过滤过，拿到后直接用seqkit看一眼基本统计量：

seqkit stats hifi.fastq.gz

重点关注几个指标：reads总条数、总碱基量、N50读长、平均读长。HiFi数据的N50通常应该在10 kb以上，如果N50只有5 kb以下，说明建库打断了或者测序有问题，这种数据组装出来的连续性大概率不会太好。

3.2 ONT数据的碱基识别与格式化

ONT测序下机的是原始电流信号，可能是pod5或者blow5格式。首先要做basecalling，把电信号翻译成碱基序列。如果测序公司没有帮你做这一步，用dorado：

dorado basecaller sup --device cuda:0 --emit-fastq pod5/ > ont_raw.fastq

sup参数表示用超级精度模型，速度慢一点但准确率高。basecalling之后还要做一下demultiplex（如果建库时加了条形码），这些操作做完之后，用NanoPlot看读长分布：

NanoPlot --fastq ont_raw.fastq --plots dot --legacy hex

打开NanoPlot生成的HTML页面，重点看读长直方图和N50。如果你看到N50只有几kb，说明建库时DNA片段化太严重，这种情况对“超长读取辅助组装”的帮助会非常有限。

3.3 如何从ONT数据里筛出超长reads

ONT原始数据里什么长度都有，但真正对组装有帮助的是那部分超长reads。短reads不仅帮不上忙，还会增加计算量，甚至引入组装错误。所以我们要主动做一次“选长”操作。

我习惯用filtlong做个初步过滤，目标是提取长度在30 kb以上、总碱基量约10 Gb的reads：

filtlong --min_length 30000 --target_bases 10000000000 ont_raw.fastq.gz | gzip > ont_ul.fastq.gz

过滤后再跑一次seqkit stats，确认一下过滤后reads的N50和总碱基量。如果N50能达到50 kb以上，后续组装会非常舒服。

3.4 一个常被忽略的接头污染问题

ONT建库过程会加接头，有时候测序质量差或者建库异常，reads里会混着接头序列。如果组装完发现很多contig末端有奇怪的串联片段，大概率是接头污染没有清理干净。

可以用Porechop或Porechop_ABI做一次接头去除，但要注意的是，如果你用filtlong按长度过滤，接头污染主要集中的几百bp短reads已经被过滤掉了，所以超长reads里的接头污染通常不严重。假如你还是不放心，可以在hifiasm组装之前用cutadapt做一次简单的接头切除。

4. 组装软件选型：别在第一步就选错

4.1 HiFi组装首选hifiasm

目前社区里最主流的HiFi组装软件是hifiasm，出自哈佛李恒团队。它的优点非常突出：速度快、内存控制好、能处理高杂合基因组，还支持双亲数据辅助分型。相比老的Canu和Flye，hifiasm对HiFi数据的利用率更高，组装结果也更连续。

hifiasm默认会对杂合基因组的两个单倍型分别组装，输出primary contigs和alternate contigs。对于二倍体物种，这就意味着你可以直接拿到两套单倍型组装，对后续单倍型分型研究非常有用。

4.2 ONT超长读取用哪套工具

如果只想用ONT数据单独拼一个基因组，Flye是入门首选。Flye命令简洁，参数少，对ONT的错误模式建模也比较成熟。另一个选择是NextDenovo，在大基因组和超长reads上速度更快，但配置过程稍微复杂，需要写配置文件，适合有一定经验后进阶使用。

不过既然是HiFi和ONT超长读取联合组装，ONT很少单独上场。它的角色更多是辅助HiFi搭桥。

4.3 三种常见联合策略对比

实际操作中有三种主流方案，我列个对比表：

我自己最常用方案A，也就是直接用hifiasm的--ul参数整合ONT超长reads。原因很简单：hifiasm在建图时就把超长reads的跨越信息用上了，这一步不是简单地把ONT contig贴上去，而是从图结构层面解决重复区的连接问题，结果更自然、更准确。

4.4 为什么不推荐用纯ONT组装然后polish

很多新手会想，ONT超长读取不是能跨越很长的重复区吗，那我直接用ONT把所有区段连起来，再用HiFi polish一遍碱基不就行了？

理论上可以，实际我踩过坑。ONT组装出来的骨架结构错误通常不是单碱基级别的，而是复杂的结构错误，比如一段序列被放反了、某段重复区域被多拼了一份或少拼了一份。HiFi polish只能修正碱基错配和小的插入缺失，对结构错误无能为力。与其事后弥补，不如一开始就用图结构层面的整合方案。

5. 保姆级实操：从原始reads到最终基因组

5.1 建立项目目录与软链接

开工之前先把目录结构规划好，防止后面文件乱成一锅粥：

mkdir -p genome_assembly/{raw,clean,assembly,evaluation} cd genome_assembly ln -s /path/to/hifi.fastq.gz raw/ ln -s /path/to/ont_ul.fastq.gz raw/

这一步看似琐碎，实际上非常值得做。我见过太多人把原始数据分散在各个目录，组装完想复盘时找不到reads在哪。软链接方式能让数据集中在项目目录里，又不占用额外磁盘空间。

5.2 用hifiasm整合HiFi和ONT超长reads

这是整个流程的核心步骤。假设HiFi数据文件是hifi.fastq.gz，ONT超长reads文件是ont_ul.fastq.gz，命令如下：

hifiasm -o sample -t 48 --ul ont_ul.fastq.gz hifi.fastq.gz 2> hifiasm.log

解释一下参数：

• -o sample：设置输出文件前缀，每个输出文件都会带sample这个前缀。
• -t 48：使用48个线程。
• --ul ont_ul.fastq.gz：指定ONT超长reads文件，hifiasm会把它们用于辅助搭桥。支持多个文件，冒号分隔。
• 最后的hifi.fastq.gz：HiFi reads是主输入，可以放多个文件。

跑的时候注意观察日志输出，如果程序卡在某个步骤很久没反应，可以用tail查看日志：

tail -f hifiasm.log

hifiasm运行时间取决于基因组大小和reads数量。500 Mb基因组配48线程，一般10到20小时能跑完。等程序结束后，输出目录里会有一堆.gfa文件，其中最核心的是：

• sample.bp.p_ctg.gfa：primary contigs，也就是主组装结果。
• sample.bp.hap1.p_ctg.gfa和sample.bp.hap2.p_ctg.gfa：两个单倍型对应的contigs。
• sample.bp.p_utg.gfa：未分型的unitig图文件，一般不用管。

5.3 从GFA文件转换出FASTA

hifiasm输出的是GFA格式，需要转换成常规的FASTA才能用于后续评估和注释。用gfatools最省事：

gfatools gfa2fa sample.bp.p_ctg.gfa > sample.p_ctg.fa

没有gfatools的话，用awk也能快速转换：

awk '/^S/{print ">"$2; print $3}' sample.bp.p_ctg.gfa > sample.p_ctg.fa

转换完成之后，顺手统计一下初级组装结果：

seqkit stats sample.p_ctg.fa

看N50和总长度。如果项目数据质量正常，500 Mb基因组用HiFi+ONT整合，contig N50至少应该到几个Mb甚至更高。如果N50只有几百kb，先别急着怀疑软件，回头检查ONT超长reads的N50是不是太低了。

5.4 备选方案：先用Flye组装ONT再做整合

如果手头的ONT超长reads质量特别高，你想多看一套纯ONT组装结果做参考，可以额外跑一遍Flye：

flye --pacbio-raw ont_ul.fastq.gz --genome-size 500m --threads 32 --out-dir flye_out --iterations 2

这里--pacbio-raw表示输入是未经纠错的原始reads，--genome-size需要根据实际基因组大小修改，--iterations控制纠错迭代轮数，2到3轮效果够用。

Flye跑完后会生成assembly.fasta，你可以拿它和hifiasm的组装结果对比一下。如果Flye组装的连续性明显更好，说明ONT超长reads中含金量很高，可以考虑用SALSA2把Flye contig作为scaffold来辅助hifiasm结果。

SALSA2的用法很简单，把HiFi contig与ONT reads做一次比对：

minimap2 -t 32 -x map-ont sample.p_ctg.fa ont_ul.fastq.gz > reads.paf SALSA2 -i sample.p_ctg.fa -p reads.paf -o salsa2_out -t 32

不过大多数情况下，hifiasm --ul这一步已经把ONT信息充分用上了，SALSA2属于加餐，不是必需品。

5.5 组装质量评估不能只看N50

组装完成之后，最重要的事情是评估质量。我每次都会跑两个工具：QUAST和BUSCO。

BUQAST用于统计装配基本指标：

quast.py sample.p_ctg.fa --gene-finding -t 16 -o quast_out

如果项目有参考基因组，可以加-r reference.fasta做比较，会额外输出基因组覆盖度、错配数、倒位数等指标。没有参考基因组也完全没问题，QUAST会输出contig数量、N50、L50、总长度这些核心统计量。

BUSCO用于评估组装完整性：

busco -i sample.p_ctg.fa -l embryophyta_odb10 -m genome -c 16 -o busco_out

注意这里-l参数要根据物种选择对应的数据库，植物选embryophyta_odb10，动物选metazoa_odb10，脊椎动物选vertebrata_odb10，真菌选fungi_odb10，反正按你的目标物种选最接近的那个。

BUSCO结果重点看Complete和Single-copy的比例。一个完整的真核生物基因组组装，Complete BUSCO通常应该在95%以上。如果只有80%甚至更低，说明组装遗漏了很多基因区域，需要检查数据量或者考虑调整组装参数。

5.6 可选进阶：用HiFi reads做一次polish

hifiasm组装的碱基精度已经很高，理论上不需要额外polish。但如果你用纯ONT组装方案（比如Flye），或者想进一步降低极低频错误，可以用racon做两轮polish：

minimap2 -t 32 sample.p_ctg.fa hifi.fastq.gz > hifi.paf racon -t 32 hifi.fastq.gz hifi.paf sample.p_ctg.fa > polished.fa

跑完第一轮后再用polished.fa作为模板跑第二轮。两轮polish之后，碱基精度基本上到Q40级别了。不过记住，polish不能修正结构错误，只能在已有骨架基础上优化细节。

6. 常见问题与排查技巧实录

6.1 hifiasm跑着跑着内存爆了

这是最常遇到的问题。如果基因组较大（超过1 Gb）且线程数开得很高，hifiasm的内存峰值可能轻松超过256 GB。解决办法有几个：第一，检查是否真的需要整合ONT超长reads，如果你只有一两倍深度的ONT，可以先不用--ul参数，跑一个纯HiFi版本，通常连续性也不会差太多；第二，增加服务器内存；第三，注意观察日志里内存占用趋势，在内存接近上限前及时调整参数。

另外有一个小技巧：hifiasm会把中间文件写在你指定的输出目录，如果磁盘空间不够也会报错。建议预留至少三倍于原始reads总大小的磁盘空间。

6.2 BUSCO完整性特别低

如果组装完成后BUSCO Complete低于90%，先别甩锅给组装软件。检查顺序是：

• 测序深度是不是不够？HiFi低于20x的话，完整性低很正常。
• 有没有严重污染？用BlobTools根据GC含量和覆盖度做一次污染物筛查，如果发现有细菌、质粒序列混入，需要用序列清理工具去除。
• BUSCO数据库是不是选错了？选了embryophyta却组的是动物基因组，结果当然不对。
• 杂合基因组有没有处理到位？如果目标物种是高度杂合的，建议用hifiasm的二倍体模式并考虑用hap1+hap2合并结果做后续分析。

6.3 contig N50比预期低很多

N50提不上去，最常见的原因是ONT超长reads不够长、不够多。hifiasm的--ul参数虽然能把ONT信息整合进组装图，但前提是这些reads确实足够长并且能跨越重复区。如果过滤后的ONT reads N50只有10 kb左右，对重复区的辅助作用非常有限。

另一个原因是目标基因组里重复区域实在太多，比如某些两栖动物或者植物基因组，这种情况建议加大ONT超长reads测序量，同时在建库时尽量少打断DNA，把模板DNA长度尽量提高。

6.4 组装结果里混入大量短contig

组完的FASTA里如果有很多几百bp到几kb的小contig，大概率是两类来源：一类是高度重复的序列单元，软件无法判断它们该放在哪里；另一类是线粒体、叶绿体基因组碎片。

应对方法有两种。第一，用seqkit按长度过滤一次，把小于1 kb的短contig暂时移除，先保留主组装做分析；第二，用Mitochondrial或者叶绿体数据库做比对，把细胞器基因组单独抽出来，不污染核基因组组装。

6.5 常见问题速查表

7. 一些经验和心得

我实际做过的项目里，最容易被忽视的其实不是组装命令，而是ONT超长reads在建库和筛选阶段的质量控制。很多团队花大价钱跑了PacBio，却在ONT文库制备时因为DNA片段长度不够，导致最终真正超长的reads寥寥无几。如果在filtlong这一步发现连5 Gb超过50 kb的reads都凑不出来，就该考虑重新补一次ONT建库，而不是硬着头皮继续组装。

最后分享一个小技巧：如果你不确定目标物种要不要加ONT超长读取，可以先做一次HiFi试组装，看看contig N50是不是卡在某个瓶颈。如果N50一直在1 Mb上下上不去，且你确认测序深度足够，那基本可以判断基因组里有大量长重复区，这时候别犹豫，直接补一个ONT超长reads文库。这个方案我在好几个项目里都验证过，投入产出比非常可观。