企业官网建设流程全解析

跑过分子对接的朋友应该都明白，单算一个配体的时候，AutoDock Vina 用起来很轻松：准备受体、准备配体、画盒子、跑一次、看分数，一套流程半小时内能搞定。但一旦配体数量从几个变成几十个、几百个甚至上千个，原来的手工操作方式就完全撑不住了。这个时候，“AutoDock Vina 对接计算（大批量）”就不再是一个简单的软件使用问题，而是一个需要认真设计的计算流水线工程问题。就像是数据库操作里从单条 insert 改成 mysql insert select 大批量写入一样，单个操作写得很顺，不代表大规模跑的时候还能用同一种思维。

这篇文章我想从实际操作的角度，把大批量对接的完整流程、脚本设计、资源调度和结果汇总整个串一遍。文章不追求把 Vina 手册翻译一遍，而是分享我真实跑过几百个配体之后沉淀下来的一套可用方案。不管你是刚开始接触虚拟筛选的药学研究生，还是已经在用 Vina 但还在手动一个个提交任务的科研人员，这篇文章都应该能帮你把对接效率提升一个量级。

1. 大批量对接的整体思路与瓶颈分析

1.1 为什么要专门谈“大批量”

单个配体对接和批量对接，表面上看只是“多做几次”的区别，实际上是完全不同的两件事。单个对接的时候，你可以手动打开 AutoDockTools，逐个检查受体有没有特殊残基，配体的可旋转键设置合不合理，盒子是不是正好罩住活性口袋。这些检查步骤在数据处理量小的情况下不觉得麻烦，但放到几百个配体的规模上，任何一个需要人工干预的环节都会变成灾难。

批量对接的核心诉求，是把“人工逐个操作”替换成“脚本统一处理”。但这句话说起来简单，做起来却藏着很多坑。比如配体结构千差万别，有的来自数据库下载的 SDF，有的来自师兄师姐给的 mol2，有的甚至只有 SMILES 字符串。这些不同来源的配体，在批量转换的时候会出现各种格式问题、原子类型问题、加氢问题。如果不在流程层面做好统一处理，跑到一半报错是常态，更麻烦的是有些配体表面上跑完了，输出的结果却是完全没意义的。

所以我一直觉得，大批量对接的第一步不是急着写脚本跑 Vina，而是先把输入数据的质量和格式规范统一起来。这个工作做扎实了，后面所有的并行计算、结果汇总才有意义。数据的标准化程度，决定了整个批量对接项目的上限。

1.2 算力评估：先算清楚要跑多久

在开始大规模对接之前，我建议先做个简单的时间预估。拿一个常见的场景举例：一个中等大小的蛋白受体，目标区域盒子尺寸大约是 20 x 20 x 20 埃，exhaustiveness 设为 16，在普通六核十二线程的桌面 CPU 上，单个配体对接大概需要 3 到 8 分钟。取中间值五分钟，一百个配体串行跑就需要五百分钟，差不多八个小时以上。这个时间在实验室里倒是能接受，但如果配体数量上升到一千个，串行跑就需要三天半。

这就是为什么要做并行调度。现代桌面 CPU 通常都有六个以上的物理核心，如果能让每个核心独立处理一个配体，一千个配体的总耗时可以压缩到十个小时以内。如果是那种双路服务器的机器，三十二核心甚至六十四核心，整个对接过程可以控制在两三个小时左右。所以大批量对接的核心思路，是想办法把总工作量切碎，让所有计算资源同时动起来。

当然，除了 CPU 并行，还有一个更直接的办法是给 Vina 配 GPU 版本。Vina 1.2 之后社区有维护的 Vina-GPU 分支，在支持 CUDA 的 NVIDIA 显卡上，对接速度相比 CPU 版本有几个数量级的提升。这个我会在后面单独开一节详细说，因为 GPU 版本虽然快，但它的参数和 CPU 版本有区别，直接套用会出问题。

1.3 大批量对接的工作流总览

把整个大批量对接流程拆开来看，大致可以分成六个环节。第一是受体准备，包括去水、加氢、补全缺失残基，最后转成 PDBQT 格式。第二是配体准备，把不同来源的小分子统一转换成 Vina 能识别的 PDBQT 文件。第三是搜索空间定义，也就是确定对接盒子的中心坐标和尺寸。第四是批量任务执行，靠脚本循环调用 Vina 完成所有配体的对接。第五是结果汇总，把几百个输出文件里的结合自由能分数提取出来，排序筛选。第六是异常处理，把报错的任务找出来，修复后重新提交。

这六个环节里，最耗时的是第二步配体准备，最容易出问题的是第六步异常处理，而大多数人最关注的往往是第四步批量执行。实际上我认为批量执行反而是最轻松的一步，因为 Vina 本身的命令行设计非常干净，非常适合脚本化调用。真正决定项目成败的，是前面几步的标准化做得怎么样，以及后面异常处理机制是否完善。

2. 准备阶段：受体、配体与搜索空间的标准化

2.1 受体文件处理：加氢、去水、转 PDBQT 的细节

受体制备是整个对接流程中最严谨的一步。虽然看起来只是把 PDB 文件转换成 PDBQT，但这个转换过程中丢失了什么、补全了什么，直接影响后续所有配体的对接结果。

第一步是去水分子。晶体结构里的水分子有些是功能性水，参与了氢键网络，但在批量对接场景下，我们通常不保留水分子，否则会占据结合口袋空间，干扰配体的构象搜索。这里有一个例外情形，如果某个水分子稳定地介导了配体和蛋白的相互作用，那就需要单独处理。但在批量对接的项目里，为了流程统一，我一般建议先把水全部去掉，后续针对命中化合物再做精细对接时，再把关键水分子加回来考虑。

第二步是加氢。PDB 文件里的氢原子通常是不全的，必须根据 pH 环境和残基的质子化状态手动加上。这个过程在 AutoDockTools 里对应的是 Edit > Hydrogens > Add。加完氢之后，还要把残基名称里的 H 元素合并成非极性氢。如果不做合并，PDBQT 文件里的原子类型会混乱，对接时某些原子会被忽略，导致结果异常。

第三步是转换成 PDBQT 格式。AutoDockTools 的 Grid > Macromolecule > Choose 可以完成这个转换。转完之后建议用文本编辑器打开看一眼，确认文件开头有REMARK记录，原子行里包含 AutoDock 的原子类型字段。比如碳原子通常是A类型，氧是OA，氮是NA。如果看到原子类型是空白的或者显示成 AMBER 的命名方式，说明转换没做对，需要重新检查处理过程。

2.2 配体批量转换：从二维结构到 3D 构象的管道

配体准备这个环节，是大批量对接里最容易消耗时间的地方。原因很简单，配体的来源太杂了。从 ZINC、ChEMBL 这类数据库下载的文件通常是 SDF 或者 SMILES，它们的三维坐标质量参差不齐，有些甚至没有三维坐标。直接从晶体结构的共晶配体出发的话，坐标倒是准确的，但需要把配体从蛋白结构中单独提取出来，同时补全共晶配体缺失的原子。

我目前用下来最顺手的一条配体准备管道，是以 Open Babel 作为主力，RDKit 为辅助。Open Babel 的命令行非常简洁，一条命令就能生成 3D 构象并加氢。他还有一个很关键的功能，就是能把配体文件里的原子类型标记成 AutoDock 风格，可以直接对接 Vina 使用。

如果配体的原始文件是 SDF，可以用这样的命令批量加氢并转换成 PDBQT：

obabel ligand.sdf -O ligand.pdbqt -p 7.4 --gen3d -m

这里的-p 7.4是指定 pH 为 7.4 的质子化状态，--gen3d表示如果没有三维坐标则生成一个合理的三维构象。-m参数是当 SDF 里包含多个分子时，把它们拆分成独立的 PDBQT 文件。

如果配体是从 SMILES 字符串开始的，Open Babel 同样可以直接处理：

obabel "CC(=O)Oc1ccccc1C(=O)O" -O aspirin.pdbqt -p 7.4 --gen3d

对于大规模数据，我一般建议先在本地把配体文件整理好，统一命名为lig_0001.pdbqt、lig_0002.pdbqt这样的格式。文件名里不要包含中文、空格和特殊字符，否则后面 Shell 脚本处理的时候会出现一堆莫名其妙的错误。这个细节我吃了不少亏，现在只要是批量任务，一律用纯数字或字母命名，后缀统一。

2.3 盒子中心与尺寸如何统一确定

盒子是一个很容易忽略但影响巨大的参数。Vina 结合自由能的计算结果，很大程度上取决于搜索空间的定义。盒子中心偏了，配体根本找不到正确的结合位点；盒子尺寸大了，搜索空间膨胀，不但耗时长，结果也容易出现假阳性。

对于单配体对接，你可以在 AutoDockTools 里通过 Grid 选项一个一个地可视化确定盒子位置。但批量对接要求所有配体共用同一个搜索空间，所以盒子的确定必须在项目启动前一次性完成。

我推荐的做法是，用 PyMOL 或者 VMD 打开受体蛋白，找到已知的活性位点，通常在共晶配体周围。如果没有共晶配体，可以通过文献里的关键残基位置来大致确定。选定中心位置的坐标后，用 Vina 的--center_x、--center_y、--center_z参数固定下来。

盒子尺寸方面，一般以覆盖活性位点周围的所有关键残基为原则。对于大多数酶类靶点，20 x 20 x 20 埃的立方体是够用的。如果口袋比较深或者配体分子比较大，可以适当加大到 25 或 30 埃。但我不建议无脑扩大，因为盒子每增大一维，构象搜索空间是按体积增长的，对接耗时也会显著增加。

盒子的中心坐标和尺寸确定后，建议写在一个共享的配置变量里。后面批量脚本里所有的任务都从这个变量读取盒子参数，这样即使要调整，也只需要改一个地方，不用每个任务单独修改。

3. 核心实操：Vina 配置与批量脚本设计

3.1 单个 config 文件的最佳实践

Vina 支持两种提交任务的方式。一种是直接在命令行里带全部参数，比如：

vina --receptor receptor.pdbqt --ligand lig_0001.pdbqt --center_x 12.34 --center_y -5.67 --center_z 8.90 --size_x 20 --size_y 20 --size_z 20 --exhaustiveness 16 --num_modes 9 --out out_0001.pdbqt

另一种方式是写一个配置文件，把参数放到文本文件里。对于单次操作，命令行方式没有问题。但对于批量任务，我强烈建议使用配置文件。原因很简单：批量任务出错的时候，如果你用的是命令行参数，回溯起来要翻看历史命令记录；而用配置文件的话，每个配体的全部参数都在一个固定位置，检查和调整都非常方便。

一个规范的 config 文件大概是这样的：

receptor = receptor.pdbqt ligand = lig_0001.pdbqt center_x = 12.34 center_y = -5.67 center_z = 8.90 size_x = 20 size_y = 20 size_z = 20 exhaustiveness = 16 num_modes = 9 out = out_0001.pdbqt

需要注意，Vina 的配置文件格式要求非常严格，=左右两边到底有没有空格，取决于你用的版本。老版本 Vina 1.1.2 通常要求=两边没有空格，也就是center_x = 12.34这种写法在某些版本里可能读不出来。我建议先手动运行一次，确认版本能正确解析配置文件之后，再和下次写进脚本里。

3.2 让 Shell 帮你循环：批量跑对接的正确姿势

批量执行的第一种方式，是用 Shell 脚本循环。这个方案依赖最少，只需要你装了 Vina 和一个标准 Linux 环境，适合绝大多数科研服务器。

最简单的循环大概是这样的：

#!/bin/bash for lig in ligands/*.pdbqt; do name=$(basename "$lig" .pdbqt) sed "s/^ligand = .*/ligand = $lig/" config_template.txt > "config_$name.txt" sed -i "s/^out = .*/out = results/$name.pdbqt/" "config_$name.txt" vina --config "config_$name.txt" done

这个脚本的思路是，准备一个模板配置文件，然后遍历ligands目录下的每个 PDBQT 文件，用sed命令把模板里的 ligand 和 out 字段替换成当前任务对应的值，生成独立配置文件后调用 Vina。

但说实话，这个脚本在实际使用中有两个问题。第一是没有借重并行能力，是串行跑的，配体一多就特别慢。第二是缺少日志和错误处理，如果中间某个配体因为乱七八糟的原因失败了，脚本不会停下来，但你也不会立刻知道，最后只能在结果目录里一个个排查缺失的输出文件。

3.3 一个更稳妥的 Python 包装器示例

为了应对串行脚本的各种弱点，后来我把批量对接的代码迁移到了 Python。Python 的好处是逻辑清晰，调试方便，还能方便地处理异常情况和时间统计。

这里给一个我现在在用的精简版本：

import subprocess import os import glob import sys from concurrent.futures import ProcessPoolExecutor RECEPTOR = "receptor.pdbqt" CENTER = {"x": 12.34, "y": -5.67, "z": 8.90} SIZE = {"x": 20, "y": 20, "z": 20} EXHAUSTIVENESS = 16 NUM_MODES = 9 LIGAND_DIR = "ligands" OUTPUT_DIR = "results" WORKERS = 8 def build_config(ligand_path, output_path): return f"""receptor = {RECEPTOR} ligand = {ligand_path} center_x = {CENTER['x']} center_y = {CENTER['y']} center_z = {CENTER['z']} size_x = {SIZE['x']} size_y = {SIZE['y']} size_z = {SIZE['z']} exhaustiveness = {EXHAUSTIVENESS} num_modes = {NUM_MODES} out = {output_path} """ def run_one(ligand_path): name = os.path.splitext(os.path.basename(ligand_path))[0] output_path = os.path.join(OUTPUT_DIR, f"{name}_out.pdbqt") log_path = os.path.join(OUTPUT_DIR, f"{name}.log") if os.path.exists(output_path): return name, "skipped" config_path = os.path.join(OUTPUT_DIR, f"{name}_config.txt") with open(config_path, "w") as f: f.write(build_config(ligand_path, output_path)) with open(log_path, "w") as f: result = subprocess.run( ["vina", "--config", config_path], stdout=f, stderr=subprocess.STDOUT, ) if result.returncode == 0 and os.path.exists(output_path): return name, "done" return name, "failed" def main(): os.makedirs(OUTPUT_DIR, exist_ok=True) ligands = sorted(glob.glob(os.path.join(LIGAND_DIR, "*.pdbqt"))) if not ligands: print("No ligands found.") sys.exit(1) done = 0 failed = [] with ProcessPoolExecutor(max_workers=WORKERS) as executor: for name, status in executor.map(run_one, ligands): if status == "done": done += 1 elif status == "failed": failed.append(name) print(f"Done: {done}, Failed: {len(failed)}") if failed: print("Failed ligands:", failed) if __name__ == "__main__": main()

这个脚本有几个关键设计。第一，它使用了ProcessPoolExecutor实现多进程并行，每个进程独立执行一个 Vina 任务，互不干扰。第二，它在任务开始前检查输出文件是否存在，如果存在就跳过。这样如果跑到一半机器断电或者手动中断，重新启动脚本时会自动跳过已经完成的配体，这在实际操作中真的非常有用。第三，它会把每个配体的日志单独存成一个文件，方便排查报错原因。

不过要注意，WORKERS这个参数不要盲目设成 CPU 核心数，除非你确认 Vina 每次只用一个线程。默认情况下，Vina 1.2 会使用当前机器上所有的 CPU 线程，这会导致外层并行和内层并行冲突，机器负载飙升，总耗时反而增加。我通常的做法是，给每个 Vina 任务限制单线程，然后把进程数设为 CPU 物理核心数。这样就是真正的一个核心跑一个任务，资源利用最均衡。

3.4 并行调度：别让 CPU 闲着

关于并行调度的细节，我再补充两点经验。第一点是，如果你的服务器 CPU 支持超线程，物理核心数和逻辑线程数不一样。Vina 这类计算密集型任务，超线程带来的性能提升有限，反而可能因为线程切换增加额外开销。所以进程数我一般设置在物理核心数左右，不超过逻辑线程数。例如一台六核十二线程的机器，开六个并行任务是最均衡的选择。

第二点是，如果任务量特别大，建议在脚本里加一个简单的进度日志功能。比如每完成一个任务，就往progress.log里追加一行时间戳和配体名。这样你可以随时用tail -f progress.log查看当前任务进行到哪了，不用反复检查目录里的输出文件个数。

我之前跑一个五百配体的虚拟筛选项目时，就是因为脚本里加了跳过完成任务的机制，中间因为网络问题断了一次，重连后直接重新运行脚本，已经完成的四百多个任务全部自动跳过，只补跑了没完成的部分，节省了大量时间。

4. 参数调优与结果聚合：从对接能量到候选排序

4.1 对接分数怎么读、怎么筛

Vina 跑完一个配体后，输出的 PDBQT 文件里会包含一个或者多个构象，每个构象对应一个结合自由能分数。默认情况下 Vina 返回 9 个构象，分数从低到高排列，分数越低代表预测的结合能力越强。

读取单个结果的分数，可以直接看输出文件开头的REMARK VINA RESULT行。这一行包含三个数值：第一个数值是结合自由能，单位是 kcal/mol；后面两个是 RMSD 的上下界，用于描述不同构象之间的相似程度。

在批量筛选的时候，通常只需要取每个配体的最低能量构象作为代表。比如设置一个 -8.0 kcal/mol 作为阈值，把分数低于这个值的配体看作潜在阳性，进入下一轮更精细的验证。这个阈值怎么定没有绝对标准，取决于你的靶点体系和阳性参考配体的分数。如果你手头有已知活性的化合物，可以用它作为基准，分数和它相当的都值得关注。

4.2 批量结果汇总与排序的最快方法

几百个配体跑完之后，最实用的结果是汇总成一个 CSV 文件，直接用 Excel 打开排序。我用一个小 Python 脚本完成这个工作：

import glob import os import csv import re rows = [] for outfile in glob.glob("results/*_out.pdbqt"): name = os.path.basename(outfile) affinity = None with open(outfile) as f: for line in f: if line.startswith("REMARK VINA RESULT"): parts = line.split() affinity = float(parts[3]) break if affinity is not None: rows.append([name, affinity]) rows.sort(key=lambda x: x[1]) with open("summary.csv", "w", newline="") as f: writer = csv.writer(f) writer.writerow(["ligand", "affinity_kcal_mol"]) writer.writerows(rows) print(f"Total ligands with results: {len(rows)}")

把脚本保存成collect_results.py，在当前目录下运行python collect_results.py，就会生成一个summary.csv文件。打开后按照 affinity 从低到高排列，最低的几个就是最值得优先关注的候选化合物。

如果你不想用 Python，也可以在 Linux 命令行下用 grep 和 sort 快速完成同样的工作：

grep -H "REMARK VINA RESULT" results/*.pdbqt | awk '{print $1, $4}' | sort -k2 -n

这个命令会把每个输出文件的最低能量构象分数提取出来，按分数从低到高排列。-H选项保证输出带文件名，方便知道哪个配体对应哪个分数。

4.3 常见陷阱：刚性受体、可旋转键、exhaustiveness 的关系

参数调优方面，有三个点我吃过亏，值得拿出来单独说。

第一个是刚性受体问题。Vina 默认将受体视为刚性结构，也就是说蛋白骨架和侧链在对接过程中完全不移动。这对于大多数粗筛场景是足够合理的，因为诱导契合效应的完全模拟需要用到柔性侧链对接或有约束的分子动力学模拟，计算成本会大幅增加。但如果你的靶点侧链柔性很强，口袋体积变化明显，刚性受体对接的结果就需要谨慎解读。

第二个是可旋转键数量。Vina 在配体预处理时会根据配体的可旋转键信息决定哪些二面角可以自由旋转。如果一个配体有超过十个可旋转键，构象搜索空间会急剧膨胀，exhaustiveness 不够的话，结果容易陷入局部最优。碰到这种情况，我通常会把 exhaustiveness 调高到 32 甚至 64，同时适当延长对接时间。

第三个是 exhaustiveness 的收益递减规律。这个参数控制全局搜索的彻底程度，数值越大，理论上搜索越充分，但耗时也线性增加。实测下来，从默认的 8 提升到 16，结果会有明显改善；从 16 提升到 32，改进幅度变小；再往上就基本是收益递减了。大批量筛选时，我一般先用 exhaustiveness=8 或 16 跑一轮粗筛，把排名靠前的化合物挑出来之后，再用更高的 exhaustiveness 做一轮精筛。这个“粗筛加精筛”的组合拳，比对所有配体都无脑开高参数要高效得多。

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

5.1 问题速查表

批量对接跑了几个项目之后，遇到的报错类型其实非常集中。下面这个表是我实际踩坑经验的总结，基本覆盖了大部分常规问题：

5.2 日志能告诉你的信息

Vina 每跑完一个任务，会往标准输出里打印一段统计信息，包括搜索空间设置、配体原子数、可旋转键数量、exhaustiveness 等信息。这些信息看起来像是普通的日志，但仔细看能发现很多问题。

比如日志里如果显示grid size和你设置的不一致，检查一下配置文件里 size_x、size_y、size_z 是否写对了。如果可旋转键数量显示为 0，说明配体的 rotatable bond 信息有问题，对接结果会非常不准确。遇到这种情况，需要重新生成配体 PDBQT 文件，确保 torsions 信息被正确保留。

另一条很有用的日志信息是耗时统计。Vina 结束时会打印出本次对接消耗的时间。如果某个配体的耗时明显高于平均水平，很可能是因为它结构复杂，或者可旋转键数量多，导致构象搜索空间变大。在批量项目里，这些异常的慢任务时间上占比不小，值得关注，因为它们往往是预测结果的潜在风险点。

5.3 GPU 版本 Vina 的体验与取舍

最后聊一下 Vina-GPU 这类加速方案。这个分支利用 CUDA 实现在 GPU 上进行对接，速度相比 CPU 版本提升非常明显。我实际测试过一个包含 30 个配体的测试集，CPU 版本需要将近一个小时，GPU 版本几分钟就跑完了，提速在十倍以上。

不过 GPU 版本有几个使用注意点。第一，它需要 NVIDIA 显卡和 CUDA 环境，这对部分实验室的服务器来说是个门槛。第二，不同版本的 Vina-GPU 支持的参数范围和 CPU 版本不完全一致，比如一些高级参数在 GPU 版本里可能被简化或忽略。第三，GPU 版本的搜索结果在个别情况下会和 CPU 版本有细微差异，这主要是因为浮点数精度和搜索随机性的影响，整体趋势是一致的，但如果你做的是非常精细的定量分析，建议最终以 CPU 版本的结果为准。

所以我在实际项目中采取的分类使用策略是：大规模初始筛选用 GPU 版本快速过滤，把候选化合物数量从千级别压缩到几十个；后续对这几个精筛化合物用 CPU 版本配合高 exhaustiveness 进行完整细致的对接计算，确保最终结果严谨可靠。这个组合方案兼顾了效率和精度。

6. 最后再分享几点批量跑对接的心得

批量对接跑了几年，我最大的体会是：这个工作百分之八十的时间其实不是在按计算，而是在处理数据。配体的归一整理、盒子参数的一次确认、脚本的健壮性设计，这些前期功夫做得越扎实，后面批量计算阶段就越顺利。反过来，前期随便搞搞，想着先把几十个配体塞进去跑，后面光排查报错就能耗掉你大半天的时间。

还有一点是文档记录。每次批量对接项目，我都会在项目目录下放一个 README 文件，把受体来源、配体文件版本、盒子坐标和尺寸、exhaustiveness 设置、Vina 版本号全部记录下来。这样即使过了半年再回头看这批结果，也知道这些数据是怎么算出来的，哪些参数下得到的，方便复现和追溯。做科研这行，可复现性比什么都重要。

如果你刚开始接触批量对接，建议先不要急着去跑一千个配体。拿二十个配体，把整套流程从头到尾跑通，对照这篇文章里的脚本和排查表，先建立起自己熟悉的工作流。等你觉得顺手了，再逐步扩大规模。自动化批量处理这件事，最重要的不是跑得快，而是跑得稳、可追溯、出了错能快速定位。把这几条做到位，你就已经比大多数手动逐个跑 Vina 的人领先一大截了。