企业官网建设流程全解析

大多数人和AlphaFold的第一次接触，都是从一条氨基酸序列开始的。你可能刚从某个数据库里拿了一段FASTA，想知道它的三维结构长什么样；也可能只是听说“人工智能可以预测蛋白结构”，就试着把序列扔进某个在线服务。这个工具听上去很高大上，但实际操作下来你会发现，真正的门槛不在算法，而在“第一步往哪走”。

这篇0基础教程，我会用两套路线带你把AlphaFold跑通：一条是云端轻量方案，适合第一次接触、只想快速看到结构的读者；另一条是本地完整流程，适合需要反复跑、处理私有数据或跑多聚体的场景。内容覆盖环境准备、单体建模实操、结果判读、常见报错，以及进阶的复合物预测示例。我不预设你已经懂Linux、懂Docker、懂PDB，但读完之后，你应该能独立跑出第一个.pdb文件，并且知道自己拿到的结果到底可不可信。

1. 为什么0基础也能把AlphaFold跑起来

1.1 它的核心逻辑，一句话能讲明白

AlphaFold本质上做的是一件“从序列到形状”的翻译工作。蛋白质是一条氨基酸链，它会在细胞里折叠成一个特定的三维结构，而这个结构决定了它能和什么分子结合、发挥什么功能。实验测定这个结构，过去需要结晶、冷冻电镜等一整套流程，代价很高。AlphaFold的思路则是从大量已知序列和结构中学习规律，然后用“多序列比对（MSA）+注意力机制”来找线索。比如它会在海量同源序列里看哪些位置总是一起突变，如果两个残基总是“你变我也变”，它们大概率在三维空间里靠得很近。用这个思路，它可以给出一条预测结构，而且速度远快于实验方法。

对于0基础用户，你不需要背清楚注意力机制的公式，只要理解“输入是一段序列，输出是一个坐标文件”就够了。AlphaFold替你完成了最复杂的那部分推理，你要做的只是把序列喂进去，再把结果取出来。这也是为什么我说它其实很适合新手——难点从来不在模型本身，而在运行环境。

1.2 0基础要懂的最小知识包

在动手前，这几个词值得先认识一下：

• FASTA：最常用的序列文本格式。文件里只有一行注释和一行序列，注释行以>开头。
• MSA：多序列比对，简单说就是把一堆同源序列排在一起，看哪些位置保守、哪些位置共变。AlphaFold非常依赖MSA提供的信息，序列库越全，预测往往越稳。
• Template（模板）：已知的实验结构，AlphaFold可以参考它辅助预测，但默认流程里不强制依赖它。
• PDB文件：描述蛋白质三维坐标的文件，记录每个原子的名字、残基编号和x/y/z坐标。AlphaFold输出的就是这种文件。

你不需要成为结构生物学专家，只要知道这些文件长什么样、里面哪个数字代表什么，就足够往下走了。我见过很多完全没接触过生物信息学的人，半天之内就能跑通第一个结构。

1.3 两条路线怎么选

我推荐0基础用户按下面这个表格判断自己该走哪条路：

我的建议很直接：纯0基础先走云端轻量方案，把流程完整跑通一次，再决定要不要折腾本地。很多人一上来就冲本地完整版，结果光下载数据库就断了好几次，最后连门都没进去。先看到结果，再理解过程，学习曲线会平缓很多。

2. 先跑通最简单的链路：云端轻量方案

2.1 云端方案到底替你做完了什么

云端轻量方案的核心思路是：别人已经把最难的环境部分搭好了。依赖库、模型参数、部分数据库都已经预置在环境里，你要做的只是上传一条序列，点一下运行。打个比方，就像你租了一间已经装好水电的实验室，进去只需要插上自己的样品，不用从砌墙开始。

你需要准备的只有四样东西：一个带GPU的云端工作台、一条目标蛋白序列、一个输出目录，以及一点耐心。很多平台在浏览器里就能完成全部操作，不需要本地安装任何东西。这对用Windows电脑、不想折腾双系统的人来说尤其友好。

2.2 最小实操：上传序列，运行一次预测

先用最简单的文本编辑器准备一个FASTA文件，内容长这样：

>example_protein MVLSPADKTNVKAAWGKVGAHAGEYGAEALERMFLSFPTTKTYFPHF

注意几点：>开头的那行是序列名，建议只用英文字母、数字和下划线；序列行不要混入空格、括号或数字。保存后上传到云端工作台，然后在网页终端或notebook的shell单元格里执行类似命令：

!run_alphafold.py \ --fasta_paths=./example_protein.fasta \ --max_template_date=2023-06-01 \ --output_dir=./af_result

我第一次看到这段命令时也愣了一下，不知道每个参数是什么意思。拆开看其实很简单：--fasta_paths指定输入文件；--max_template_date是预测时可参考的模板截止日期；--output_dir是结果保存目录。 运行结束后，结果目录里会出现ranked_*.pdb、timings.json、ranking_debug.json等文件。你首先要下载的通常是ranked_0.pdb，这是综合分数最高的预测结构。

2.3 不要乱改的三个默认项

关于云端方案，我要泼一盆冷水：对于0基础，运行前忍住冲动，别去改下面几个地方。

max_template_date可以改，但不要设成未来日期，否则模板检索阶段会直接崩。模型参数文件不要动，云端环境已经选好了默认权重，删了会导致启动失败。数据库路径更不要手动改成不存在的目录，很多新手以为“填一个看起来更像数据库的路径”能提速，结果反而找不到MSA文件。

这些改动都会影响核心逻辑，而报错信息对新用户又不友好。跑通一次之后再研究它们，比一上来就乱试要高效得多。

2.4 云端跑通后，我建议你马上做的事

拿到ranked_0.pdb之后，别急着关页面。用可视化工具打开它，转一圈看整体形状，然后打开ranking_debug.json，找到几个模型对应的pLDDT分数，记下平均值。这么做比你连续跑十个蛋白都有用，因为后面切换到本地时，你能对得上这些数字的含义。顺便检查一下输出目录里有没有msas/文件夹，如果里面有内容，说明MSA构建成功，这个信号比“命令跑完”更可靠。

3. 本地完整版：从环境搭建到跑通单体建模

3.1 硬件和系统：别被“最低配置”忽悠

本地完整版最大的优点是数据在自己手里，不依赖外部平台，但准备工作也更多。先说硬件门槛，我的经验值是下面这套：

没有独立显卡也能跑，CPU模式只是慢，短序列尚可接受，序列一长就非常煎熬。内存方面，MSA构建阶段占用会突然升高，32GB是我见过比较稳妥的下限。 操作系统优先选Linux不是因为它高贵，而是Docker、GPU驱动这类基础设施在Linux下兼容性最好，Windows也能跑，但路径、权限和共享内存的坑会多一些。新手如果经常需要跑结构，我会劝你直接装一个Linux环境，省掉后面百分之八十的麻烦。

3.2 环境搭建：Docker是帮你隔离麻烦的

为什么要用Docker？AlphaFold依赖很多科学计算库，版本极其敏感，一套环境里某库升级就可能导致需要重新编译一遍。Docker把整套依赖封装成镜像，你只需要把输入数据挂载进去，代码在容器里跑，宿主系统干干净净。

最简操作步骤：

# 1. 克隆代码仓库，把地址替换成你实际使用的官方或镜像地址 git clone <仓库地址> cd alphafold # 2. 拉取运行镜像 docker pull <镜像地址>:latest # 3. 下载参数文件和精简数据库 python3 docker/download_all_data.py --data_dir=$HOME/af_data

关于第三步多说一句：下载脚本通常提供全量和精简两种选项，新人强烈建议先用精简数据库（reduced_dbs）跑通流程。全量数据库动辄上TB，下载中断一次就非常痛苦。下载完成后，确认$HOME/af_data下出现了params/和msa/等目录再继续，别急着运行。

3.3 跑单体：每行参数都值得看懂

环境就绪后，进入项目目录执行：

python3 docker/run_docker.py \ --fasta_paths=./example_protein.fasta \ --max_template_date=2023-06-01 \ --data_dir=$HOME/af_data \ --output_dir=$HOME/af_output \ --docker_image_name=<你的镜像>:latest \ --gpu_devices=0

每个参数都有自己该管的事：

关于运行时间，我给个大概感觉：一个约120个残基的蛋白，用一张中端GPU，从MSA构建到出结果大约20分钟到1小时。序列越长，MSA搜索越久，模型推理也越慢。MSA阶段日志看起来像是卡住了，其实没卡，底层数值库第一次运行还要做编译，耐心等就好。

3.4 本地跑通的三个判断信号

判断本地是否真的跑通，不要只看命令退没退出。我习惯看三个信号：

• 终端出现Running model_1、model_2等字样，说明模型开始推理，不是还在搜序列库。
• 结果目录出现result_model_1.pkl和ranked_0.pdb，说明预测真正完成。
• 运行结束后打开timings.json，能看到每个阶段的耗时。这个文件我之前一直忽略，后来发现排查性能瓶颈特别有用，比如MSA阶段占比过高，通常意味着数据库路径配错或序列头写得不规范。

4. 输出文件到底怎么看

4.1 不要只下载ranked_0.pdb就完事

很多新手拿到ranked_0.pdb就像拆完盲盒一样关掉页面，这样其实浪费了AlphaFold输出的其他信息。典型输出目录长这样：

af_output/ ├── features.pkl ├── msas/ ├── ranked_0.pdb ├── ranked_1.pdb ├── ... ├── ranking_debug.json ├── result_model_1.pkl ├── timings.json └── unrelaxed_model_1_pred_0.pdb

每个模型都会生成一个PDB文件，ranked_0是模型按总分排序后选出的最佳结果，但ranking_debug.json里的原始分数更有参考价值。打开它看一眼，你能了解模型之间的分数差距：如果ranked_0和ranked_1分数几乎一样，说明结果稳定；如果差距很大，建议多留个心眼，不要只取第一名。

4.2 pLDDT藏着置信度，不在文件名的“rank”里

AlphaFold把每个残基的置信度写进了PDB文件的B因子列。B因子原本是实验结构里的温度因子，这里被复用为0到100的pLDDT值。数值越大，该残基坐标越可信。

可视化软件里通常可以按B因子上色，蓝色代表高置信，红色代表低置信。我见过不少人盯着整体折叠看得很兴奋，结果功能区域一片红，那就要小心了。看结构时先看B因子着色，比先看整体形状更重要。

4.3 PAE：判断结构域之间的相对位置靠不靠谱

如果说pLDDT是“每个残基自己有多自信”，PAE（预测对齐误差）回答的是“两个残基之间相对位置有多可靠”。这个值藏在输出JSON里，可以用简单脚本提取成矩阵，也可以直接查看可视化结果。

读取PAE矩阵有几个经验：

• 对角线一定是深蓝色，表示残基和自己误差为0。
• 某个结构域内部区块整体是蓝色，说明这个区域内部折叠可信。
• 如果两个结构域之间出现大片黄色、红色，说明它们的相对位置不确定，哪怕每个结构域内部的pLDDT都很高。

举个真实场景：一个蛋白由两个结构域组成，各自内部pLDDT在90以上，但PAE矩阵中两个结构域交界处一片红色。那你只能确信两个结构域各自的折叠方式，它们之间的摆放关系不靠谱，这时候不能直接拿来做复合物分析。

4.4 结果验证的经验法则

没有实验结构的情况下，怎么判断模型能不能用？我的顺序是这样的：

1. 看整体平均pLDDT是否达到85以上。
2. 看PAE矩阵是否大部分区域为蓝色。
3. 把预测结构和已知同源结构做重叠比较，看关键残基是否落在大致相同的位置。
4. 结合功能实验证据，比如突变数据、交联数据，看关键残基是否集中在高置信区域。

这些验证都不需要复杂编程，大部分结构可视化工具都能完成。做过两三次之后，你对“什么结果能信、什么结果不能信”会形成直觉。

5. 跑通之后的坑：六类报错与排查链路

真正拦住新手的往往不是模型本身，而是这些看起来很小的问题。我把常见报错整理成优先排查顺序，每一条都附上原因和解决路径。

5.1 MSA数据库不完整

报错典型表现是FileNotFoundError: .../msa/xxx，或者提示找不到某个数据库子目录。根因大多是下载数据库时中断过，或者下载脚本只选了参数文件而漏了MSA库。

排查时先看--data_dir指向的目录下有没有msa/文件夹，再检查其中文件数量是否和文档一致。我早期下载时开着下载工具，半夜断了，第二天运行到MSA阶段直接崩。后来养成了习惯：跑之前先列目录，确认文件都在再动手，宁可多花一分钟检查，也不要白跑半小时。

5.2 Docker权限与共享内存报错

两种表现最容易混淆。一种是permission denied while trying to connect to the Docker daemon socket，这通常是当前用户不在docker用户组，用sudo运行或者把用户加入docker用户组后重新登录即可。另一种是容器内报“can't allocate shared memory”，看起来像磁盘不够，实际是默认共享内存太小，在启动命令里加上--shm-size=64g就能解决。

这两个问题我遇到过不止一次，尤其是共享内存，配置不够时MSA阶段偶尔会莫名崩溃，让人完全摸不着头脑。

5.3 GPU相关：驱动、CUDA、显存不足

报错常见形式包括CUDA_ERROR_OUT_OF_MEMORY和底层数值库提示“can't set visible devices”。排查思路按顺序来：

• 先确认宿主机能列出自带的显卡设备，如果能列出来，硬件层面基本没问题。
• 确认运行镜像里的GPU相关版本和宿主机兼容，版本差距过大时直接换新镜像。
• 显存不足时，先减少同时运行的模型数量，比如只保留一个模型；还不够，把序列裁剪成短片段测试，确认代码链是否正常。

我还踩过一个隐蔽的坑：连续跑多个蛋白，第一个成功了，第二个报显存不足，实际是上一个进程没释放显存。查一下进程列表，把残留进程清理掉就好。这个问题在本地多任务时特别容易遇到。

5.4 max_template_date导致的问题

这个参数看着无害，却是我见过新手最容易设错的。典型表现是模板检索阶段突然报错，提示模板日期相关异常。如果你把日期设成了未来日期，AlphaFold的模板过滤逻辑会直接出问题。

最稳的做法是第一次跑就把它固定设置为“今天的日期”，或者你序列公开发布的日期，之后不要随意改。这个参数不是越新越好，它本质上是防止预测时用“未来信息”的一种设计，保持保守反而更安全。

5.5 fasta格式里的隐形错误

有时候命令顺利跑完，结果却很诡异：PDB里全是低置信度，或者MSA文件几乎是空的。这时候问题多半出在FASTA内容上。

检查四件事：序列头那行是不是严格以>开头，且没有空格、括号；序列行有没有混入数字或异常字母；多聚体有没有用冒号正确连接各链；文件最后一行有没有正常换行。

我见过一个典型例子：注释行写成>protein (human)，括号被解析进去后，后续搜索范围完全跑偏，最后出来的模型每个结构域置信度都不高。这种错误不动声色，却会让结果彻底失效。

5.6 输出目录的容量与保存问题

运行很久之后突然保存失败，先查--output_dir所在磁盘够不够。AlphaFold的中间文件很大，features.pkl动辄几百MB到几GB，跑几次就能撑爆几十GB分区。

我的习惯是：

• 把output_dir放到确认过空间的分区。
• 跑完立刻把ranked_*.pdb和ranking_debug.json下载到本地。
• 及时清理不需要的pkl和中间MSA文件。

这些文件跑完一次后几乎不会再看，留着只占空间。

5.7 排查三原则

最后分享三条通用排查经验：

• 日志里往上翻，找第一个错误，那才是根因。很多人只看最后一行，结果被衍生报错带偏。
• 改配置时一次只改一个变量，方便确认是哪个改动产生了效果。
• 跑之前确认三件事：输入文件存在、数据库目录存在、GPU设备可见。

6. 从单体到复合物：多聚体与自定义模板

6.1 多聚体其实不难：一条fasta含多条链

AlphaFold原生模型也支持多聚体预测，把多条链写进同一个FASTA记录，链之间用冒号连接即可：

>complex_A_B MAAKGST...:MVLSPA...

运行命令和单体基本一致，不需要额外切换模型。输出里会多出复合物层面的置信度指标。我的判断经验是：复合物界面得分大于0.8，界面可信；0.6到0.8属于“能看但别直接下结论”；低于0.6，界面处很可能需要实验数据修正。

需要提醒的是，多聚体预测比单体更吃显存，总残基数一旦超过1500，普通显卡跑起来就很吃力，建议分链处理或者用更大显存的机器。

6.2 自定义模板：什么时候需要，以及最简操作

0基础阶段我不建议主动碰自定义模板。AlphaFold默认流程也会自动搜索模板，不需要你额外做什么。需要自定义模板的场景一般是同源建模：你有一个和已知结构高度相似的蛋白，想让AlphaFold参考这个已知结构。

操作思路是这样：

1. 从结构数据库里找出和你的序列最相似的已知链。
2. 把对应结构文件转换成模板所需的格式。
3. 在运行命令里加上--template_mmt_dir参数，指向模板目录。

注意，模板目录的文件名要与序列ID对应，格式要求很严格，必须先跑通默认流程再研究它。我见过有人为了省几分钟搜索时间强行加模板，结果文件名配不上，反而报错重跑。

6.3 我一直保留的最小工作流

分享一个我目前最常用的流程：拿到一条新序列，先在云端轻量方案跑一次，看整体pLDDT分布。如果平均在85以上，直接采信；如果偏低，再切到本地完整版，调小模型数量、加模板重新预测。每次跑之前，我会用文字记录三行：输入文件、日期参数、输出目录。这个做法看着原始，但复盘问题时非常有用，尤其是连续跑多个蛋白的时候。

最后再分享一个小技巧：运行脚本前，先用最基本的文本编辑器打开FASTA文件看一遍，确认最后一行以换行符结束、没有隐藏字符。这能少踩很多MSA阶段的坑。我实测下来，大多数“莫名其妙”的失败，其实都藏在那些不起眼的准备步骤里。