1、AutoDock 批次质控概述
说实话，我刚入门做分子对接那会儿，压根没听过“批次质控”这个词。当时觉得只要把配体一个个丢进 AutoDock 跑完，拿到结合自由能就算完事了。结果呢？有一次处理一百多个化合物，跑完一看，里面有十几个的能量值明显不对劲，还有几个构象完全飘在蛋白外面。后来花了整整两天排查，才发现是输入文件格式不一致、搜索参数没设对。
打那以后，我做批量对接之前，一定会先想清楚一件事：这一批结果，怎么证明它是可信的？
批次质控，说白了就是用一套标准流程，对一大批 AutoDock 输出结果做系统性的检查。它不是盯着一两个案例挑毛病，而是要覆盖所有结果，快速揪出那些“看起来正常，实际上有问题”的任务。
为什么批次质控是硬需求
AutoDock 的批量其实是靠脚本把单个作业串起来。每个任务独立运行，环境、参数、输入文件都可能出现微小差异。等你跑完几百个，手动翻日志？不现实。靠眼睛看打分？容易漏。
我见过最典型的情况：一个 50 个配体的项目，跑了 8 小时。结果统计分析时发现，有 5 个对接没有收敛，但日志里只写了一个“WARNING: number of torsions exceeds maximum”就被自动跳过了。这 5 个留下来的是默认构象，能量倒是不高，一查全是虚的。如果没有批次质控，后续的虚拟筛选排名就是废的。
批次质控的价值，我总结为三点：
- 可复现：每个结果都能溯源到输入和参数，出了问题知道查哪里。
- 可筛选：自动标记异常任务，不用人肉审计。
- 可信度：最后拿出去的结合能、打分、构象，都是有据可查的。
批次质控的核心流程
我个人习惯把批次质控分成四个阶段。下面这个表格可以看得比较清楚。
| 阶段 | 输入/输出 | 关键检查点 |
|---|---|---|
| 输入准备 | 配体 pdbqt、受体 pdbqt、grid 参数文件 | 文件完整性、原子类型兼容性、扭转键数量 |
| 分子对接 | AutoDock 运行日志、dlg 结果文件 | 任务是否正常结束、是否达到最大步数、能量是否发散 |
| 质量检查 | 结合自由能、簇统计、构象 RMSD | 能量是否在合理范围、聚类是否单一、构象是否在盒子里 |
| 结果分发 | 汇总表格、可视化构象、报告 | 数据一致性、命名规范、异常标记清空 |
你想想看，如果一张表里，一个配体的结合自由能是 -15 kcal/mol，另一个同类配体却是 +8 kcal/mol，而两者结构只差一个甲基。这种数据你敢直接用吗？批次质控就是在帮你提前发现这种异常。
常见的失败类型
做了一批项目，哪些问题是经常冒出来的？我整理了一个清单：
- 格式错误：配体 pdbqt 缺失原子、电荷未分配、或者文件被截断。
- 收敛失败：能量计算没有到达收敛标准，日志最后一行是“Cycle limit reached”而不是“Converged”。
- 能量异常：结合自由能明显偏离同类配体的分布范围（比如比平均值大 3 个标准差以上）。
- 构象不合理：对接后的构象与受体有严重空间冲突（steric clash），或者配体原子跑到 grid 盒子外面去了。
- 日志告警：AutoDock 在日志中写了一些 WARNING，比如氢原子过多、扭转键数超限、电荷不平衡等。
我曾经在一个项目里，碰见过日志里悄悄写了一句“WARNING: number of torsions > 32, using default torsions”。任务看起来跑完了，但实际用的是默认扭转，完全不是我输入的定义。如果你不做批次质控，根本不会注意到这个警告。
一个简单的自查脚本
说一千道一万，不如写点东西来干活。下面是我常用的一段 bash 片段，用来扫描 dlg 日志中的 WARNING：
#!/bin/bash
# 快速检查批次 dlg 日志中的 WARNING 和 ERROR
for dlg in *.dlg; do
echo "=== $dlg ==="
grep -E "(WARNING|ERROR|Fail|Not converged)" "$dlg"
echo ""
done跑完以后，你再对照日志文件逐个确认。如果输出太多，那就说明你这一批里坑不少。
小提示：我习惯在每次批量启动前，先手动检查前 3 个配体的日志。如果前 3 个都正常，再让脚本去批量扫。这样可以避免因为批次太大，一开始就全跑废了。
注意：不要轻易相信 AutoDock 的默认搜索参数。默认的 ga_num_evals 和 ga_run 对很多体系是不够的。我曾经因为偷懒没改，一批成品里有一半都没有找到全局最小能量，结果图表做出来曲线全是乱的。批次质控的第一个屏障，就是从参数复核开始。
这一章的知识框架
讲到现在，你可能对批次质控已经有了一个大致的印象。下面这张图直接画出了整个知识结构，方便你往后看各章时有个位置感。
这张框架图就是你后续学习的地图。每一章都会对应这里的一个节点，或是一个检查点。我们接下来会一步步拆解那些“看起来正常、实际有坑”的真实案例。
本章小结
批次质控不是什么高深的理论，它就是一套工程化的“检查清单”。你把它做在前面，后面做统计、做可视化、写报告，才能心里有底。
我个人习惯，每次批量跑完，第一件事就是跑一遍自查脚本，把 WARNING 和 ERROR 抓出来。如果超过 5% 的任务有警告，我会直接回头调参数重跑。这一章就是给你打下这个认知基础。