测序告诉你谁在，MetaTraits 告诉你它们能干什么

微生物组研究里最日常的一句话是「这个样本里 30% 是 Faecalibacterium」。这句话只说明了一个相对丰度，它回答的是「有谁、有多少」，没有回答「它是怎样一种菌」。测序给出的是基因序列，而序列本身不携带「最适生长温度 37 摄氏度」「不耐氧」「发酵丁酸盐」这些信息；这些信息过去只散落在几千篇论文的方法段、培养条件表格和菌种描述里，检索起来靠读论文，规模化起来几乎无法实现。

MetaTraits 做的就是这件事的中间层：它把自己定位成「把散落在多个数据库、且对未培养类群基本缺失的表型信息统一到一处」的资源，一手接四个培养数据库的实验记录，一手接四个模型对基因组序列的推断，再按分类单元把两者合成可以 join 到丰度表上的性状向量。它的官网挂在 EMBL 域名下，论文发表在《核酸研究》，作者来自 EMBL 海德堡的 Bork 组与德国 DSMZ，这是一个典型的「欧洲公共生物信息基础设施 + 国家菌种保藏中心」的组合。

对使用者来说，它的价值不在数据量本身，而在三件事：性状名被统一过、每条结论能回溯到原始证据、以及它明确告诉你哪些分支的结论不可靠。代价同样明确——补进来的预测值不是实验、覆盖面对难培养类群近乎空白、种级聚合会把菌株之间的真实差异抹平。一屏速览见下表。

维度	内容
全称	metaTraits: a large-scale integration of microbial phenotypic trait information
中文名	微生物表型性状整合资源
建设机构	EMBL 海德堡 Bork 组（Daniel Podlesny、Chan Yeong Kim 等）
合作机构	德国 Leibniz 研究所 DSMZ（Lorenz C. Reimer、Julia Koblitz、Isabel Schober）
论文	Nucleic Acids Research，DOI 10.1093/nar/gkaf1241，官网标 2025-11-26
官网	https://metatraits.embl.de
规模（官方口径）	超过 220 万个基因组、140 项以上归一化性状
培养来源	BacDive、BV-BRC、JGI IMG、JGI/GOLD
预测来源	BacDive-AI、GenomeSPOT、MICROPHERRET、Traitar 四个模型
分类体系	NCBI Taxonomy（2025-07-28 快照）与 GTDB（r220）双轨
性状类别	细胞形态、生理、代谢与酶活、环境偏好、生活方式五类
交付形式	网页检索、JSON API、六张分级汇总 TSV、两张分类映射表
接口门槛	无需鉴权，无注册，无申请
许可	官网未单列数据许可标识，声明遵循 EMBL 隐私政策
服务状态	首页挂维护提示，API 端点核验当日返回 404

§1 它要解决的具体麻烦

1.1 丰度表里有名字，没有性状，中间那一层是空的

宏基因组流水线跑到最后，你能拿到的是一张「样本 × 分类单元」的相对丰度矩阵，以及若干功能注释的结果。问题是功能注释给出的是基因层面的能力——「这个样本的群落里存在纤维素降解相关的 CAZyme」——而不是「这些基因在哪些分类单元里、这个分类单元自己是不是真的在用」。生态学解释需要的恰恰是后者：当你说「炎症组里 Faecalibacterium 下降」，你想接着说的是「而这个属是产丁酸、严格厌氧、对 pH 敏感的」，这句话在任何一个测序结果文件里都找不到。

它不在测序结果里，是因为它本来就不是测出来的。革兰氏染色、能否在 4 摄氏度生长、耐盐上限是多少、能不能利用甘露醇——这些是实验室里对着菌落做出来的观察，记录在论文表格与菌种描述里。把它们收集起来、对接到分类单元上，是一件典型的「数据工程活儿而不是科学发现活儿」：单个观察没有多高的新颖性，但凑齐了一件事就成立——你可以在丰度表旁边直接加一列「是否产芽孢」。MetaTraits 就是这条缝里的填充物，它的公开表述也正是这一句：微生物在结构与生理上差异很大，但这些表型信息分散在多个数据库里，且对仍未培养的类群基本缺失。

1.1a 为什么要补这一层：一个具体的分析卡点

设想一篇肠道微生物组关联研究：测序、注释、差异丰度都做完了，结果是一串物种名与 p 值。写讨论时笔会停住——为什么这个属在病人里少？没有性状层，能写的只有两类话：引用别人对该属的描述（「已知为产丁酸菌」），或推测性的套话（「可能与肠道屏障有关」）。两类都不是这篇研究自己的结果。

有性状层之后，至少多出三种可以落地的分析：性状富集看差异是否集中在某类生理特征上；性状-环境关联把临床变量与群落加权性状向量做相关；机制假设的定向生成把后续实验聚焦到具体通路。三者共同的前提都是性状能被当成一列数来用。

分析类型	没有性状层时能做什么	有性状层后能做什么	前提条件
差异丰度	列出差异物种名	同上，并可做性状层面的富集	性状向量可 join
机制解释	引用他文对该属的描述	用本人样本的加权性状做定向论证	性状值有稳健多数
环境关联	只能到分类单元层级	到性状层级做关联	性状数值化后可比
假设生成	泛泛的「与屏障有关」	指向具体生理特征与可测表型	性状与实验设计可对应
跨队列比较	比较物种名，受注释体系干扰	比较性状向量，受体系干扰更小	两个队列用同一套口径

1.2 三条常见的错误期待

第一条是把规模当覆盖度。两百余万统计的是「被纳入索引的基因组数」，不是「在被问的性状上有数据的基因组数」。入索引的门槛是组装质量或所属集合，与有没有做过革兰氏染色无关。

第二条是当成可以直接引用的实验测定。表里既有培养数据库转抄的实验记录，也有模型对序列的推断，两者共用同一列；网页用 AI badge 区分，下载的 TSV 只有 databases 列能看出模型名。当成「已被实验确认」写进论文，是最容易发生的引用事故。

第三条是期待它给出「这个物种的性状」。它给的是各取值的比例，以及一致率不足 85% 时的「无稳健多数」标签。分布与投票结果语义不同：想要确定的物种画像，往往得到的是一张比例表，而这张表恰好说明物种层面不存在单一画像。

另有两种更隐性的错位：把「有这条性状」当成「只有这条性状」——分支汇总只列出现过的取值，没被提及的不以「未知」形式出现，于是「没查到」与「查到但结果为空」在表上看起来一样；把「资源可用」当成「服务可用」，2026 年 10 月核验时这一点具象成了三个接口同时 404。

期待	实际	第一次使用时会发生什么
基因组多即覆盖全	覆盖面由上游描述决定	查稀有门落空
每条性状都是实验值	预测与观察同表	引用时误标
物种有单一性状画像	给的是构成比例	画不出「典型菌株」
没列出即不存在	表只列出现过的取值	把空缺读成阴性
网站在即接口在	两层独立部署	脚本在维护期失败

1.3 它能给到的与给不到的

你的需求	它给的	够不够
某个属或种是否革兰氏阴性	该分类单元下各取值的观察与预测构成比例	够做方向性判断，不足以写「确认为阴性」
某物种的最适生长温度	温度相关性状的数值分布，含最小、最大与离散取值	够用，但注意是分布不是单值
未培养 MAG 的表型推断	四个模型给出的布尔或数值预测	够做假设生成，不能当作测量值
菌株级别的性状差异	只能下钻到单条记录查看该基因组的注释	够看个案，没有成规模的菌株级差异表
性状的文献出处	databases 列与网页上的证据链接	够溯源，但链接指向来源库而非原论文段落
某一性状的实验证据强度	观察条数、贡献库数、共识占比	可间接判断，但没有按证据等级分层的字段
与丰度表对接	分类单元名与 taxon_lineage	够对接，但需自行选 NCBI 或 GTDB 口径
完整性状矩阵（基因组 × 性状）	网站不直接提供，需按分类单元或按记录取	不够，做全量矩阵要自己拼
人类疾病相关的表型解读	无此字段，只有微生物自身的性状	给不到，须另接病原或毒力库

1.4 你的处境与它能帮到的事

你的处境	它能帮你什么	下一步该做什么
手上有一张属级丰度表，想加一列「是否产芽孢」	用属级汇总表按 taxon_name 直接 join	先确认丰度表的分类体系，再选 NCBI 或 GTDB 一侧下载
测到了一批 MAG，想知道它们像什么样的菌	用 species 或 genus 级汇总做上下文比对，或用 porTraits 直接提交基因组	把预测结论标记为推断，与实验来源的行分开写进结果
想论证某个功能类群在肠道里更常见	用环境偏好与生活方式类性状做分组统计	先看该分支是否被判为无稳健多数，再决定要不要报
审稿人问「你说它厌氧，证据是什么」	记录视图里的溯源链接指向 BacDive 或 BV-BRC 条目	顺着链接点回原库，进一步找原始文献
做微生物组与临床指标的关联，需要在讨论里解释机制	把关联物种升级成性状向量，用于富集或通路推理	明确性状是文献与预测混合，不要在方法段写「测定」
想找一套标准本体做自己的注释体系	140 项性状已挂 OMP、GO、CHEBI 等本体	直接用它的 onto id 对齐，比自建词表省事
需要一份干净的 GTDB 与 NCBI 对照	官方映射表，平均一致率分别 99.47% 与 99.87%	高一致率的表在物种边界上仍会有冲突，边界附近要抽查
只想快速看看 Faecalibacterium 是什么	网页搜索框输名字就有分支汇总	注意首页维护提示，接口可能暂时不可用

1.5 一句话判断

它解决的不是「测一个菌」，而是「查一个菌已经被别人描述过什么」；这个定位决定了它天然有偏、天然有预测，也天然适合做假设生成而不是做证据。

1.6 不适合谁：四条边界

第一条边界：需要实验级证据的场景。若结论要落在「该菌株确为革兰氏阳性」这样的判决上，它只能作检索入口，最终证据须回到 BacDive 条目或论文。定位是聚合与检索，不是测定。

第二条边界：需要菌株级性状矩阵的场景。没有「所有菌株 × 所有性状」的宽表，做表型-基因型关联要自己拼，拼出来空值率很高。

第三条边界：以未培养类群为主体的问题。官方写明这类信息对未培养类群基本缺失，只靠预测填补。研究对象若是从未培养的候选门，拿到的几乎全是推断。

第四条边界：需要人口学或疾病相关表型的场景。这里没有与宿主、疾病状态、临床结局相关的字段，只承担微生物那一侧的性状解释。

§2 数据构成与规格

2.1 物理规格：六张分级表、两张映射表、一套网页与一个接口

官方给下游的稳定交付物是压缩 TSV 汇总表，按「分类粒度 × 是否含预测」交叉出六个文件：NCBI 与 GTDB 两套体系，各分科、属、种三级，每级又分全数据与仅培养两版，文件名规律为 <体系>_<粒度>_summary_<all|no_predictions>.tsv.gz；另有两张分类映射表。汇总表适合批量 join，记录视图适合个案溯源，网页与接口适合交互查询。六个文件的列结构统一。

交付物	文件名规律	粒度	内含预测	适用场景
NCBI 全数据汇总	ncbi_<级别>_summary_all.tsv.gz	科 / 属 / 种	是	需要最大覆盖的关联分析
GTDB 全数据汇总	gtdb_<级别>_summary_all.tsv.gz	科 / 属 / 种	是	与 GTDB 口径的宏基因组流程对接
NCBI 仅培养汇总	ncbi_<级别>_summary_no_predictions.tsv.gz	科 / 属 / 种	否	只要实验记录、拒绝模型推断
GTDB 仅培养汇总	gtdb_<级别>_summary_no_predictions.tsv.gz	科 / 属 / 种	否	同上，按 GTDB 分箱
GTDB→NCBI 映射	GTDB2NCBI.tsv.gz	分类单元对	否	把 GTDB 结果转成 NCBI 名
NCBI→GTDB 映射	NCBI2GTDB.tsv.gz	分类单元对	否	把 NCBI 结果转成 GTDB 名

2.2 字段与记录的完整字典

汇总表的二十列构成了一张记录的全部信息。它有三组：标识组（这一行是谁）、构成组（各取值的比例如何）、溯源组（数据从哪来、挂在哪本体上）。

列名	含义	类型	实际取值形态
taxon_id	分类单元编号，随体系不同	整数	NCBI 用 taxid，GTDB 用 GTDB 内部编号
taxon_name	分类单元拉丁名	文本	属名或种加词，属级不带种加词
trait_name	归一化后的性状名	文本	小写连字符串，如 presence-of-motility
unit	数值性状的单位或类型	文本	boolean、%、µm、Celsius、gene
database_count	贡献该行数据的库数量	整数	1 到数个，取决于该性状被哪些库收录
total_observations	观察与预测总条数	整数	从 1 起的计数，种级大分支可达数千
consensus_value	多数取值	文本或数值	布尔值为 true/false，数值型为具体数
consensus_count	支持多数取值的条数	整数	小于等于总条数
consensus_percentage	多数取值占比	浮点	0 到 100，低于 85 时判为无稳健多数
minimum	数值性状的最小值	浮点	布尔性状为 NA
median	数值性状的中位数	浮点	布尔性状为 NA
mean	数值性状的均值	浮点	布尔性状为 NA
maximum	数值性状的最大值	浮点	布尔性状为 NA
discrete_values	各离散取值及计数	文本	形如 false=1 或 rod=12;coccus=3
databases	数据源及其版本	文本	分号分隔，形如 BacDive-AI:proGenomes3=a1bef3e
group_1	性状的一级大类	文本	如 Metabolism、Environmental preferences
group_2	性状的二级分类	文本	如 Aerobic growth、pH
ontology_ids	本体编号	文本	分号分隔，可挂多个本体
taxon_lineage	从域到该单元的分类路径	文本	竖线分隔，如 `Bacteria\

2.3 一条记录的完整解剖

下面这一行是从 NCBI 种级全数据汇总表里取的第一条记录（文件开头首个数据行），它恰好是整个表里最朴素的一类：只有一个库、一条记录、一个取值。

taxon_id    1960156
taxon_name  Abditibacterium utsteinense
trait_name  acidophilic
unit        boolean
database_count     1
total_observations 1
consensus_value    false
consensus_count    1
consensus_percentage  100.0
minimum NA  median NA  mean NA  maximum NA
discrete_values    false=1
databases          BacDive-AI:proGenomes3=a1bef3e
group_1    Environmental preferences
group_2    pH
ontology_ids       OMP:0005009
taxon_lineage      Bacteria|Abditibacteriota|Abditibacteriia|Abditibacteriales|Abditibacteriaceae|Abditibacterium|Abditibacterium utsteinense

逐段读这一行：database_count 与 total_observations 均为 1，说明这条「是否嗜酸」的判断背后只有一条记录；consensus_percentage 100.0 在此不表示高度一致，只表示一条记录全落在同一侧。databases 冒号前是 BacDive-AI，即这是模型预测而非实验观察，冒号后的 proGenomes3=a1bef3e 说明依据的基因组集合与模型版本。ontology_ids 挂 OMP:0005009，即「最适生长发生在 pH 0 到 5.5 之间」的群体生长表型。

换一个性状结构完全一样，只是数值型四列会从 NA 变成实数。第二条记录 aerobic growth: anoxygenic phototrophy 来源 MICROPHERRET:proGenomes3=fd21931，同时挂 GO:0040007;PATO:0001455;ECOCORE:00000131 三个本体，说明一项性状可多锚，检索时任一万能入口都可抵达。

2.4 性状目录的构成表

Traits 目录页逐条列出性状，每条给名称、类型、本体编号、定义，预测类另附训练基因组数与正例比例。下表只呈现结构与规模。

维度	构成	说明
性状总条目	官方论文称 140 项以上归一化性状	目录页逐条列出，含布尔、因子、数值三类
布尔型	主体，多数为「是/否」判断	如能否利用某碳源、是否产芽孢、是否运动
因子型	少量，取值来自有限集合	如细胞形状（杆状、球状、螺旋）、鞭毛排列
数值型	少量，带物理单位	细胞长宽（µm）、温度（Celsius）、盐度（% w/v）、pH
基因组衍生型	少量，非表型而是序列特征	基因组大小、GC 含量、编码密度、基因数，标注为基因组统计
生态衍生型	少量，由栖息地分布推算	generalism score、habitat count、泛基因组开放度
本体覆盖	OMP、GO、CHEBI、ENVO、MICRO、NCIT、SNOMED、mesh 等十余个	一项性状可挂多个本体
预测类性状	目录页标注训练基因组数的部分	由 BacDive-AI、GenomeSPOT、MICROPHERRET、Traitar 提供
碳源利用类	以 utilizes: 为前缀的一大批	大多只有布尔判断，条目间结构高度相似
五大类分组	细胞形态、生理、代谢与酶活、环境偏好、生活方式	对应 group_1 列的取值

2.5 与同类资源的字段差异

把它和三个近邻放在一起看，差异主要在「粒度」与「是否含预测」两个轴上。BacDive 是菌株级的培养与生理数据，几乎不含预测，覆盖的是被培养过的菌；BV-BRC 与 JGI IMG 各有自己的性状字段与分类口径；GTDB 提供的是分类学本身，不含性状。MetaTraits 的独特性在于同一张表里既有实验也有推断，且统一了名字。

资源	记录单位	含预测	分类口径	与 MetaTraits 的关系
MetaTraits	分类单元 × 性状	是	NCBI 与 GTDB 双轨	本体
BacDive	菌株	否	自有菌株号	被整体引入的四个来源之一
BV-BRC	基因组与菌株	部分	自有	被引入的来源之一
JGI IMG	基因组	部分	自有	被引入的来源之一
GOLD	测序项目与样本	否	自有	被引入的来源之一
GTDB	基因组与分类	否	自有	被引入的分类骨架
proGenomes	基因组集合	否	自有	预测所依据的基因组集合
SPIRE	MAG 集合	否	自有	预测所依据的 MAG 集合

2.6 六个汇总文件之间的关系

六张表是同一份底层结果在三种粒度、两种证据口径上的投影，不是六个独立的库。种级查不到不代表属级没有，只代表该种的记录没有形成可汇总的行。分类越细记录越少，触发 85% 阈值的概率越高，所以很多分析宁可停在属级：共识更稳，代价是信息更粗。

文件	粒度	含预测	何时优先用	主要风险
ncbi_family_summary_all	科	是	跨门比较、粗粒度性状统计	过粗，掩盖属间差异
ncbi_genus_summary_all	属	是	与常见属级丰度表对接	属内异质性被压平
ncbi_species_summary_all	种	是	种级差异分析	空行与无稳健多数偏多
ncbi_family_summary_no_predictions	科	否	只要实验证据的综述	覆盖断崖明显
ncbi_genus_summary_no_predictions	属	否	用实验证据做机理讨论	难培养类群几乎全空
ncbi_species_summary_no_predictions	种	否	严格的实验口径分析	可用行数大幅减少
gtdb_* 对应六项	科 / 属 / 种	同左	与 GTDB 流程对齐	名称与 NCBI 不一致

2.7 数值性状的单位与可比性

数值类性状的单位不一致：细胞长度以微米计，温度以摄氏度计，盐度以质量体积百分比计。同一分支通常给出上下限两条记录而非一个「最适值」。范围宽可能是菌株差异，也可能是文献口径不同——有人录「能长的范围」，有人录「实验用的培养温度」。

单位	对应性状	典型记录形态	解读注意
boolean	形态、酶活、碳源利用	true 或 false 加计数	占比是构成，不是置信
Celsius	温度最小值、最大值	两条记录各给一端	不是最适温度
% NaCl (w/v)	盐度最小值、最大值	以质量体积百分比计	培养基差异会影响可比性
pH	pH 最小值、最大值	各给一端	缓冲体系影响结果
µm	细胞长度、宽度	各给最小与最大	与染色与制片有关
%	基因组 GC、编码密度	单一数值	序列特征非表型
gene 或 bp	基因数、基因组大小	单一数值	与组装质量相关

2.8 记录标识的唯一性与 join 键

taxon_id 与 trait_name 的组合是自然主键，但跨表时不能直接用：两套体系的 taxon_id 位于不同编号空间，taxon_name 也会因重分类而被重用。稳妥做法是先用映射表换编号再对接；只能按名字 join 时，至少用 taxon_lineage 做一次前缀校验。

join 键	同表内可用	跨表可用	跨体系可用	建议
taxon_id	是	同体系内是	否	同体系首选
taxon_name	是	多数可用	部分可用	配合 lineage 校验
taxon_lineage	是	是	否	做一致性校验
映射表对	不适用	不适用	是	跨体系首选
ontology_ids	是	是	是	性状概念级对齐

§3 标识层：一个性状到底挂在谁身上

3.1 三条溯源链的交汇点

每条数据能沿三条链往回走：分类链从 taxon_id 到 taxon_lineage 一路回到域；数据源链由 databases 列的每个名字对应一个库或一个模型；本体链由 ontology_ids 指向受控词表条目。三条链交汇于那一行汇总记录，于是「这条结论来自哪个库」「用的哪套分类」「对应哪个本体编号」都可用字段回答。多数同类资源只给最后一层结论。

3.2 菌株、基因组与分类单元：三个层次不在同一张表里

理解这个资源的第一道坎，是分清三个层次。最细的是菌株，带 DSM 号或 ATCC 号；往上是基因组组装，带 GCA 或 GCF 登录号；再往上是分类单元，带 taxid 或 GTDB 编号。培养数据库以菌株为记录单位，预测模型以基因组为单位，汇总表以分类单元为单位。

三种单位之间不是一一对应：基因组可能来自已描述菌株、未描述分离物或 MAG，后者根本没有对应菌株；同一菌株可能有多个组装，也有菌株从未被测序。所以「有 50 个基因组」与「有 50 个菌株被描述过」是两件事。

层次	标识形态	谁在里面	用于什么
菌株	DSM 号、ATCC 号、自有编号	培养数据库	培养与生理实验记录
基因组	GCA_ 或 GCF_ 登录号	proGenomes、SPIRE、来源库	预测的输入单位
分类单元	taxid 或 GTDB 编号	汇总表	join 丰度表

3.3 搜索框能吃的四类标识

官方文档给出了四类可以直接粘进搜索框的例子，每一类落在不同的记录视图上。这个设计对做批量处理的人有用：你可以先用手上的已有标识验证系统能否识别，再决定要不要走接口。

标识类型	示例形态	落到哪	用途
物种名	Bifidobacterium bifidum	分类单元汇总	看分支级性状分布
基因组登录号	GCA_001606525.1	单基因组记录视图	看这一株的全部注释
SPIRE 标识	spire_mag_00047739	MAG 记录视图	看一个未培养基因组的推断
JGI 标识	Go0007368	IMG 记录视图	看 JGI 侧的观察
BV-BRC 标识	205913.6	BV-BRC 记录视图	看 BV-BRC 侧的观察

3.4 双轨分类：NCBI 与 GTDB 不是同一套东西

同时挂两套分类不是冗余：微生物组分析几乎都在 GTDB 上做物种注释，而菌株登记与保藏记录几乎都在 NCBI 上。两边的结果不能直接混——同一个属在 GTDB 里可能被拆成几个属，同一个种名可能指向不同的基因组集合。官方为此提供双向映射表，规则是「对应单元须有 85% 以上的基因组在两边共享同一编号」，平均一致率为 GTDB→NCBI 的 99.47% 与 NCBI→GTDB 的 99.87%。这两个数是「被对应上的单元」的一致率，不是覆盖率；在物种边界、新拆分的属、基因组稀少的支系上，映射会失效或落到上级单元。

3.5 记录视图里能看到什么

按登录号查询进入记录视图，列出的是支撑汇总结果的每一条底层记录，带来源与预测上下文。对做质控的人这一层最有价值：能看到某个基因组的革兰氏染色是来自培养数据库的实验，还是某个模型的推断。但它是给人看的，官方没有「按基因组批量导出全部注释」的公开端点，成规模获取要走汇总表或接口。

3.6 本体映射的三种颗粒度

本体映射的颗粒度直接决定检索能力。粗颗粒度是「这项性状属于代谢」，靠 group_1 就能实现；中颗粒度是「这项性状属于好氧生长」，靠 group_2；细颗粒度是「这项性状在本体里的定义是群体生长表型中关于 pH 的那一支」，要靠 ontology_ids。

实际做跨库对齐时，细颗粒度最有用，因为本体编号是全局唯一的，不会因为来源库的中文或英文叫法不同而错位。粗颗粒度的名字在来源库之间同名不同义的情况很多——「motility」在一家指游动能力，在另一家可能包含群集运动。挂到本体上之后，这些歧义才有机会被消解。

颗粒度	字段	跨库稳定性	用途
粗	group_1	中	大类统计、分组
中	group_2	中低	细分主题筛选
细	ontology_ids	高	与其他数据源对齐
原始	trait_name	高（本库内部）	本库内查询与 join

§4 证据层：实验、预测与它们混在一起之后

4.1 四个库给观察，四个模型给推断

来源分成两组。观察组是 BacDive、BV-BRC、JGI IMG、GOLD，性状来自培养、生理生化试验或文献整理；推断组是 BacDive-AI、GenomeSPOT、MICROPHERRET、Traitar，以已有标签的基因组训练后对无标签基因组给出推断。两组在同一张表里合流，好处是未培养类群不至于整片空白，代价是两种性质不同的信息共用一套字段。

组别	名称	信息来源	覆盖偏向	可引用性
观察	BacDive	DSMZ 维护的培养与生理数据	被培养、被深入研究的菌株	高，可回到实验
观察	BV-BRC	细菌与病毒资源整合库	病原与基因组项目	高
观察	JGI IMG	基因组与微生物组注释平台	环境基因组项目	中高
观察	GOLD	测序项目与样本元数据	项目侧的背景信息	中，粒度较粗
推断	BacDive-AI	以 BacDive 标签训练的模型	有近邻同源基因组的类群	低，属推断
推断	GenomeSPOT	基因组统计特征推断	有完整组装的基因组	低
推断	MICROPHERRET	代谢与生理性状预测	覆盖代谢类性状较广	低
推断	Traitar	基于系统发育与基因家族	覆盖形态与部分生理性状	低

4.2 85% 这条线是做什么用的

官方设定了一条阈值：分支内一致率低于 85% 时给「no robust majority」标签而非共识值。多数数据库会强行给一个众数把分歧藏起来，这条设计反其道而行。逻辑是：超过六分之一的记录持不同意见，就不该说「这个分支的性状是 X」。后果是越往下钻越容易撞上它，而细粒度结论恰恰最常被拿去做解释。

4.3 案例：Faecalibacterium prausnitzii 的种级画像为什么拼不出单一结论

Faecalibacterium prausnitzii 是肠道研究里最常被提到的种，常被描述为产丁酸、严格厌氧、革兰氏阳性、对氧极敏感。查它得到的不是一句话而是一组比例：氧耐受方面多数落在不耐氧一侧但并非全部，革兰氏阳性比例很高，温度、pH、碳源利用这几个维度上记录数与来源库都不均，且出现明显分歧。

这不是数据质量问题，而是生物学事实的投影。F. prausnitzii 后来被比较基因组研究拆成一组系统发育上不同的谱系，各谱系在底物利用与氧敏感性上有差异，部分谱系被重划为其他属。种级记录里「革兰氏阳性占比不是 100%」正是菌株差异被聚合后的样子。这个案例落在第七节的偏差枚举里，它是「覆盖不均匀」与「种级聚合有损」两个偏差共同作用的产物：聚合方法正确，结论却可能指向并不存在的典型菌株。

4.4 预测值的三条使用规则

第一条，标签要诚实。用了含预测的版本，方法段应写「性状来自 MetaTraits 全数据汇总（含模型推断）」，而不是「来自 BacDive」，这两句在评审眼里是两种证据等级。第二条，关键结论要复核，看该分支的实验来源是否也支持同一方向，对照全数据与仅培养两份文件成本很低。第三条，不要拿预测值训练下一轮预测，预测已基于 BacDive 标签训练，再当新标签只会放大原有偏差。

4.5 只看实验来源时，覆盖会掉多少

六个汇总文件里一半是仅培养版，与全数据版并排就能看出每个分支有多少靠预测撑起来：研究充分的分支差别很小，研究稀少的门则整片为空。这个落差本身就是信号——它说明该分支的性状认识有多少来自实验、多少来自推断。跨门比较时不区分这一点，结论会系统偏向被研究透的门。

4.6 证据链接回到哪里

每条性状条目都链接回它在 BacDive、BV-BRC、JGI GOLD/IMG 或对应模型里的原始证据，这是它区别于二手汇编的地方。但链接终点是来源库的条目页而非原论文段落，想引用原始陈述还得再往下走一层。

4.7 当两个库打架时，系统怎么处理

培养数据库之间经常出现分歧。同一株菌，BacDive 里的记录可能来自 1970 年代的一篇描述，BV-BRC 里的记录来自另一个团队的生化鉴定；两边的结论在「能否利用某种碳源」上不一致，是完全正常的。系统处理这类分歧的方式不是裁决，而是计数：把两条都算进 total_observations，让 discrete_values 同时列出两侧的条数，再由 85% 阈值决定要不要给出共识。

情形	系统行为	使用者应当做的
两库结论一致	共识明确，占比高	正常使用
两库结论相反，各一条	占比 50%，判无稳健多数	回到两个来源核实记录年份与方法
一库多条、另一库一条	多数侧占优，可能过 85%	看是不是记录数差异而非真分歧
观察与预测相反	按条数计，可能被预测改写	用仅培养表对照一次
只有预测来源	有共识，但全是推断	方法段必须标注

代价是记录数多的来源更有话语权，而记录数多往往只说明研究得更早，不一定更对。读高占比共识时先看 database_count：只有一家来源时，「共识」的实质是「这一家的看法」。

4.8 菌株差异为什么不该被当成噪声

种是一个便利箱。同一个种的不同菌株在温度耐受、氧耐受、碳源谱上差异可以很大，足以影响生态位预测，这些差异是真实的生物学而非实验误差。聚合到种级时它们不会消失，而会变成占比，所以「耐盐上限定在一个比例分布上」是常态。正确读法是把结论当成范围，而不是把中位数当作上限。

读法	做法	结论形态	是否稳妥
取中位数	把 median 当作物种性状	单值	不稳妥，掩盖范围
取范围	用 minimum 与 maximum 描述	区间	稳妥
取比例	用 consensus_percentage 描述一致性	比例	稳妥，但要区分来源
取众数	只看 consensus_value	单值	不稳妥，低占比时尤其
下钻菌株	进记录视图逐条看	条目级	稳妥但费时

4.9 两个工作流在证据链里的位置

porTraits 注释用户自己的基因组，sumTraits 注释用户自己的分类谱。前者把未知基因组放进已知图景，后者把群落构成翻译成性状构成。两者都只是入口：porTraits 的输出本质是预测，sumTraits 的输出是受输入谱质量与分类体系左右的加权结果。

§5 接口层：三种取数方式与它们的实际状态

5.1 三条路径怎么选

想临时看一个物种，用网页搜索框，最快。想把性状接进分析流程，用汇总 TSV，最稳。想按需批量取某几个分类单元，用接口，最省事——前提是接口在线。三条路径给出的数值应该一致，因为它们最终都来自同一套汇总结果，差异只在粒度和呈现。

路径	输入	输出	适合	风险
网页搜索	名字或标识	分支汇总与记录视图	探索、核实	维护期不可用
汇总 TSV	无（整表下载）	分类单元 × 性状全表	批量分析	体积大，需自行筛选
JSON 接口	taxid 列表	该批 taxid 的性状观察	按需取数	接口若下线则需回退

5.2 下载并读出种级汇总表

官方文档给出的六个汇总文件都在同一个静态目录下。下面的脚本下载 NCBI 种级全数据表，读表头，并按性状统计一次行数与分类单元数——这两个数决定了这张表能不能直接当矩阵用。

#-- 下载并解析 MetaTraits 的种级汇总表
import csv, gzip, io, urllib.request
from collections import defaultdict

BASE = "https://www.bork.embl.de/~robbani/metatraits/ncbi_species_summary_all.tsv.gz"
url = BASE
with urllib.request.urlopen(url, timeout=120) as resp:
    raw = resp.read()
text = io.TextIOWrapper(gzip.GzipFile(fileobj=io.BytesIO(raw)), encoding="utf-8")
reader = csv.DictReader(text, delimiter="\t")
rows = list(reader)

print("列名：", reader.fieldnames)
print("总行数：", len(rows))
print("不同分类单元：", len({r["taxon_id"] for r in rows}))
print("不同性状：", len({r["trait_name"] for r in rows}))

per_trait = defaultdict(set)
for r in rows:
    per_trait[r["trait_name"]].add(r["taxon_id"])
top = sorted(per_trait.items(), key=lambda kv: -len(kv[1]))[:10]
for name, taxa in top:
    print(name, len(taxa))

运行后你会看到，行数是「分类单元 × 性状」的组合数，而不是分类单元数。这张表不是宽表，要做「物种 × 性状」的矩阵，必须自己 pivot，而且 pivot 之后必然有大量空缺——不是每个物种都做过每项观察。

5.3 逐个分类单元取数

官方的单分类单元端点是 /traits/taxon/<taxonomy_id>，参数 databases 可重复，省略时用全部库。下面是按官方文档写的调用形式。

#-- 按 taxid 取单个分类单元的性状观察（NCBI 口径）
curl -s "https://metatraits.embl.de/api/v1/traits/taxon/511145" \
  -H "Accept: application/json" | head -c 2000

核验当日，这个端点与 /api/v1 根路径都返回 404（详见 §5.6）。这不说明端点设计有误，只说明服务当前不在正常状态——官网首页同时挂着「正在计划维护，部分服务暂时不可用」的提示。遇到这种情况，回退路径就是 §5.2 的汇总表。

5.4 批量取数

批量端点用 POST，请求体是 taxonomy_ids 与可选的 databases。官方文档说单次可提交的 id 数量上限是 MAX_IDS，但页面没有把这个常量替换成具体数字，实际值需以运行时返回的错误信息为准。

#-- 批量取数：按官方文档构造请求体
import json, urllib.request

payload = {"taxonomy_ids": [511145, 83333, 562], "databases": ["BacDive"]}
req = urllib.request.Request(
    "https://metatraits.embl.de/api/v1/traits/taxon",
    data=json.dumps(payload).encode("utf-8"),
    headers={"Content-Type": "application/json", "Accept": "application/json"},
    method="POST",
)
try:
    with urllib.request.urlopen(req, timeout=60) as resp:
        data = json.loads(resp.read().decode("utf-8"))
    print(len(data))
except urllib.error.HTTPError as e:
    print("HTTP", e.code, e.read()[:300])

写进生产代码时，建议把这一层封装成一个「先试接口、失败回退汇总表」的函数，因为接口的可用性不受使用者控制。

5.5 用汇总表把性状接到丰度表上

真正做分析的那一步是 join。下面的代码把丰度表按属名对上属级汇总表，构造一个「样本 × 性状」的矩阵。关键在两点：分类体系要选对，性状要先选好。

#-- 把属级丰度表与 MetaTraits 属级汇总表对接
import csv, gzip, io, urllib.request
from collections import defaultdict

url = "https://www.bork.embl.de/~robbani/metatraits/ncbi_genus_summary_all.tsv.gz"
with urllib.request.urlopen(url, timeout=180) as resp:
    gz = gzip.GzipFile(fileobj=io.BytesIO(resp.read()))
rows = list(csv.DictReader(io.TextIOWrapper(gz, encoding="utf-8"), delimiter="\t"))

WANT = {"presence-of-motility", "sporulation", "gram-negative"}
trait_map = defaultdict(dict)
for r in rows:
    if r["trait_name"] in WANT:
        trait_map[r["taxon_name"]][r["trait_name"]] = (
            r["consensus_value"], float(r["consensus_percentage"]))

#-- abundance.tsv 为两列：genus<TAB>abundance
with open("abundance.tsv", encoding="utf-8") as f:
    for line in f:
        genus, ab = line.rstrip("\n").split("\t")
        t = trait_map.get(genus)
        if t is None:
            continue
        for name, (val, pct) in t.items():
            print(genus, ab, name, val, pct)

这段代码故意保留了 pct：不是所有 join 都该成功。当 pct 低于 85 时，官方对应的位置是「无稳健多数」，这份数据在这一列上不提供共识，直接拿来当 0 或 1 用等于凭空造了一个值。

5.6 接口状态与校验：核验当日的一手观察

核验当日对接口的访问结果如下，一并记在这里，因为下次复现时会遇到同样的问题。

#-- 端点存活探测（核验当日执行）
for u in "/api/v1" "/api/v1/traits/taxon/511145" "/api/v1/traits/taxon/562"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://metatraits.embl.de${u}")
  echo "$u -> $code"
done

三条都返回 404。同时首页的维护提示仍在。汇总表的静态文件则是可用的，HTTP 200，last-modified 为 2026-06-10。这说明接口层与静态文件层是两套独立部署，接口停服时静态文件未必停。写流程时按这个事实设计回退，比假设接口一定在线要稳。

拿到文件之后的第一件事是校验表头。二十列齐全、且 concept 类的关键列（consensus_value、databases）存在，就说明文件没有被截断或换过版本。

5.7 超时与重试：静态文件也不总是快

静态表放在 EMBL 的一个家目录路径下，带宽与稳定性不如专门的数据门户。种级表在几十 MB 量级，urlopen 默认无超时，网络抖动时会长时间挂住。给下载加超时与重试是必要的一步。

#-- 带超时与重试的下载函数
import gzip, io, time, urllib.request

def fetch_gz(url, tries=3, timeout=120):
    last = None
    for i in range(tries):
        try:
            with urllib.request.urlopen(url, timeout=timeout) as resp:
                raw = resp.read()
            return gzip.GzipFile(fileobj=io.BytesIO(raw))
        except Exception as exc:
            last = exc
            time.sleep(2 ** i)
    raise RuntimeError("下载失败") from last

url = "https://www.bork.embl.de/~robbani/metatraits/ncbi_species_summary_all.tsv.gz"
gz = fetch_gz(url)
print(gz.read(200).decode("utf-8", "replace"))

重试间隔用指数退避，因为这类失败多为瞬时拥塞，固定间隔容易撞在同一时间窗口。

5.8 缓存：多久重拉一次

静态表的 last-modified 是识别更新时点的唯一信号，因为文件名里没有版本号。核验当日其修改时间为 2026-06-10，而上游分类快照是 2025 年 7 月，说明静态表不随分类快照同步刷新。做法是把首次下载的 last-modified 与文件大小记进清单，按项目周期用 HEAD 比对，变了再整份重下。

检查项	手段	判定	动作
是否更新	HEAD 请求看 last-modified	与记录不同	整份重下
文件是否完整	比对 content-length	与记录不同	重下并校验表头
列结构是否变	读表头比对字段清单	缺列或多列	停下改代码
服务是否在线	GET 首页看返回码	非 200	等维护结束
接口是否可用	GET 端点看返回码	404 或 5xx	走静态表回退

5.9 把结果落成分析能用的宽表

最后一步是把长表转成宽表。下面这段代码只保留布尔型、且有稳健多数的行，输出 species × trait 的稀疏结构，可直接转成 DataFrame。

#-- 长表转宽表：只保留布尔型且有稳健多数的记录
import csv, gzip
from collections import defaultdict

matrix = defaultdict(dict)
with gzip.open("ncbi_species_summary_all.tsv.gz", "rt", encoding="utf-8") as f:
    for r in csv.DictReader(f, delimiter="\t"):
        if r["unit"] != "boolean":
            continue
        if float(r["consensus_percentage"] or 0) < 85.0:
            continue
        matrix[r["taxon_name"]][r["trait_name"]] = 1 if r["consensus_value"] == "true" else 0

cols = sorted({t for d in matrix.values() for t in d})
print("物种数", len(matrix), "性状列数", len(cols))
print(next(iter(matrix.items())))

转成宽表后会立刻看到一个事实：绝大多数格子是空的。这不是代码错，而是数据结构——每项性状只在部分分类单元上有记录。稀疏性是下游分析的第一个约束。

§6 与库内条目的关系

6.1 关系图谱

它站在「上游汇总」的位置：往下接四个培养数据库与四类模型，往上给微生物组分析、性状-基因型关联与生态位推断提供输入。

邻居类型	代表资源	与 MetaTraits 的方向	关系性质
培养数据库	BacDive	上游	被整体引入，是主要观察来源
病原与基因组库	BV-BRC	上游	被引入，补病原侧
环境基因组平台	JGI IMG、GOLD	上游	被引入，补环境项目侧
分类骨架	GTDB、NCBI Taxonomy	上游	提供分类层级与命名
基因组集合	proGenomes、SPIRE	上游	预测的输入单位
性状本体	OMP、GO、CHEBI、ENVO	上游	提供受控词表
宏基因组流程	GTDB-Tk、MetaPhlAn 类工具	平行	输出分类谱，可对接本库
功能注释	KEGG、COG、CAZy 类	平行	一个给能力，一个给表型
菌株保藏	DSMZ 菌种目录	平行	菌株实物，本库不含
数据仓库	通用科研数据仓库	下游	派生矩阵可寄存

6.3 与 BacDive 的分工：一个到菌株，一个到分支

BacDive 的记录单位是菌株，强项是「查这一株做过哪些试验」，弱项是「拿一株代表一个物种」。本库把它整体引入后做了一次升维：把菌株级记录投影到分类单元，再与另外三个库的记录、四个模型的推断合成一份。于是强项变成「一个分支上各项性状的构成」，弱项变成「这一株究竟做过什么」——后者要走记录视图而非汇总表。

分工的实际含义：做菌株水平的判决回 BacDive，做分支水平的描述或 join 用 MetaTraits。两者数字不必一致，一个是原始记录，一个是聚合结果。

对比项	BacDive	MetaTraits
记录单位	菌株	分类单元 × 性状
性状来源	培养与文献记录	四库记录加四模型推断
有无预测	无	有，可筛除
典型查询	这一株做过哪些试验	这个属各项性状的构成
适合人群	微生物分类与生理研究者	微生物组分析与数据工程
与对方的关系	上游供料方之一	引入方

6.4 与性状预测工具的分工：一个出数，一个合流

做基因组性状预测的模型单独拿出来都能用，但 MetaTraits 把四个模型的输出与四个库的记录放在同一套性状名、同一套本体、同一套分类上，因此不需要为四个模型各处理一遍输出格式。

场景	更适合直接跑模型	更适合用 MetaTraits
只有几个基因组，要快速出预测	是	也可
要与已发表的观察对照	否	是
要跨库统一性状名	否	是
要指定模型版本与训练集	是	否，版本信息在 databases 列里但不全
要给非程序员看结果	否	是

6.5 与功能注释资源的分工：能力与表型的两个轴

功能注释给的是「这个群落里有哪些基因」，按序列相似性指派，不需要知道基因属于哪个分类单元；表型注释给的是「这些分类单元被观察到有什么特征」，必须先有分类单元再查记录。两者正交，做机制解释时要分别拿、再对齐。

维度	功能注释	表型注释（本库）
输入单位	序列	分类单元
回答	有什么基因	这个单元被观察到什么
分类依赖	弱	强，必须先定分类
误差来源	注释数据库的覆盖与相似性阈值	文献覆盖、菌株差异、模型推断
典型用途	通路与功能潜力	生态位解释、性状富集

6.2 检索路径

找类似资源有四条路：从数据源出发，查 BacDive 官网的接口与本体映射；从文献出发，在 Europe PMC 搜 microbial traits database；从本体出发，在 EBI 的 OLS 打开 OMP 或 CHEBI 条目看谁引用了它；从工具出发，GTDB 注释社区的讨论常提到本库。

§7 质量评估与局限性

7.0 阅读本节前的一个前置校正

读这一节前要先放下一个印象：数据库的「质量」不等于「准确率」。这里一个重要偏差不是错误，而是覆盖不均匀——它忠实反映了研究的注意力分布，模式菌株被反复描述，难培养类群近乎空白。当成「数据错了」会误判它的性质，当成「数据全面」同样误判。本节所有判断都建立在「它是一个覆盖率高度偏斜的聚合层」这个前提上。

7.1 五维评分

下面这套评分按 DAIMS 的常见维度改写，用于给出一个可比较的画像，不用于横向排名。

维度	评分	依据
可发现性	4/5	官网、论文、DOI 齐全，搜索友好
可访问性	3/5	静态表无门槛，但接口核验当日不可用
可互操作性	4/5	本体映射到位，双分类体系带映射表
可复用性	3/5	许可未单列标识，再分发需确认
上下文完整性	4/5	溯源列齐全，证据可回到来源库
文档质量	4/5	概念解释清楚，参数常量未展开
版本可追踪	3/5	有快照日期与模型 commit，无版本号

7.2 三个做得好的地方

第一，把「不确定」做成了字段。85% 阈值与 no robust majority 标签，是把分歧显式化，而不是藏在均值背后。这在同类资源里是少见的克制。

第二，溯源做到了列级。databases 列带着库名、模型名、基因组集合与 commit，一条记录的历史是可查的。

第三，交付形态覆盖了三种人。网页给不做代码的人，TSV 给做批量分析的人，接口给做在线服务的人。三者共用一套结果，避免了不同口径打架。

7.3 已知的、可枚举的偏差

偏差	表现	何以致之	后果
研究注意力偏差	模式菌株与病原菌数据密集	文献本身集中在这两类	跨门比较会偏向被研究透的门
未培养类群空缺	候选门几乎全为预测	无法培养即无法做表型试验	该分支的性状是推断不是事实
种级聚合损失	同种异菌株差异被压成比例	分类单元聚合是设计选择	可能指向一个不存在的典型菌株
观察与预测同表	两类证据共用一套字段	为了让覆盖不出现断崖	误引为实验测定
85% 阈值带来的空结论	细分分支常判无稳健多数	分歧被显式化而非隐藏	细粒度查询常得不到答案
转录继承偏差	来源库的文字描述被归一	抽取过程无法复核原文	模糊描述被压成布尔值
本体覆盖不均	部分性状挂多个本体，部分挂一个	各领域本体成熟度不同	跨本体检索的召回不均
分类快照滞后	依赖特定日期的 taxonomy	分类学持续修订	新旧命名之间需自行换算

7.4 外部验证矩阵

下面几条是可以在不下载数据的前提下，从官方页面独立核对的点。

待核项	官方陈述	外部可核对的部位	核验结论
基因组规模	超过 220 万	论文摘要与首页 About 段	两处一致
性状数量	140 项以上	论文摘要与 Traits 目录页	一致，目录页逐条可数
四个培养来源	BacDive、BV-BRC、JGI IMG、GOLD	首页 About 与导航 Databases 菜单	一致
四个预测来源	BacDive-AI、GenomeSPOT、MICROPHERRET、Traitar	Traits 目录页每条的来源表	一致
双分类体系	NCBI 2025-07-28、GTDB r220	导航栏 Taxonomy 下拉	一致
映射一致率	99.47% 与 99.87%	文档页 Downloads 段	一致
接口无需鉴权	文档明示	文档页 API Access 段	陈述一致，当日端点不可用
85% 阈值	低于即标 no robust majority	文档页 Trait Summaries 段	一致

7.5 它为何能持续：把别人做过的实验反复卖出去

它的边际成本结构决定了它能活下来。原料不是新实验，而是别人做完、发表、进了公共库的记录；增量工作只有归一化、映射与推断。每一轮分类学更新、每一个新模型、每一批新 MAG，都能让同一套原料产生新衍生品，而成本不随使用人数上升。资助来自德国科学基金会、韩国研究基金会与 EMBL 自身。

§8 生态位与历史

8.1 历史沿革

BacDive 与 BV-BRC 在 2010 年代逐步成型，proGenomes 与 GTDB 同期确立了基因组集合与分类学的新标杆，SPIRE 把 MAG 纳入可比集合。到 2020 年代中期，基因组覆盖已经足够密，性状层面却仍停在各库自说自话的状态，这正是本库出现的时机。

时间	事件	对本库的意义
2010 年代前期	BacDive 上线并持续扩充	提供最大的一块实验观察
2010 年代中期	BV-BRC、JGI IMG、GOLD 成型	补齐病原与环境项目侧
2010 年代后期	GTDB 发布并快速迭代	提供可对齐的分类骨架
2020 年代初	proGenomes、SPIRE 集合发布	提供预测所需的基因组池
2025 年	论文发表于 Nucleic Acids Research	资源正式定型
2026 年中	汇总表静态文件更新	服务仍在维护
核验当日	首页挂维护提示，接口 404	服务间断可用

8.2 生态位：不做实验的那一层

在「谁来提供微生物性状」这件事上已有三类玩家：保藏中心做实物保存与培养实验，基因组平台做测序与注释，本体维护者做概念体系。本库是第四类，不做实物、不做新测序、不造概念，专做「把前三类合成一张可查、可 join、可溯源的表」。好处是不与任何一方竞争，坏处是价值上限由上游决定。

玩家	产出	与本库的关系	本库不能替代的部分
菌种保藏中心	菌株实物与培养试验	供料方	实物保藏与新增实验
基因组平台	组装与基因注释	供料方	新的测序与组装
本体维护者	受控词表与定义	供料方	概念体系的制定
本库	跨库合流的性状表	合流层	无，本库只做这一层

8.3 上下游怎么用它

向下游看，最直接的两类用途是性状富集与讨论段的解释辅助；往上游看，它是四个来源库的统一入口，做综述的人可先在此找线索再回原库核实。

8.4 它的替代与互补

没有单一资源能替代它，因为它的核心是「合流」。但每一个环节都有替代：只想要实验数据就直连 BacDive；只想要分类就用 GTDB；只想要预测就用单个模型。它的不可替代性只在于「一张表里同时有这些，且名字对得上」。

8.5 标注形态：日期与提交号的混搭

导航栏里四个培养数据源标的是日期（均为 2025-07-29），四个模型标的是提交号或版本号（BacDive-AI a1bef3e、GenomeSPOT 1.0.1、MICROPHERRET fd21931、Traitar 8bd7d86）。

混搭反映两类上游的差异：数据库的版本语义是快照日期，软件是提交号。好处是能确切知道结果对应哪个时点、哪个版本。

来源	标注形态	语义	可复现性
BacDive	2025-07-29	快照日期	高，只要上游保留历史
BV-BRC	2025-07-29	快照日期	高
JGI/GOLD	2025-07-29	快照日期	高
JGI/IMG	2025-07-29	快照日期	高
BacDive-AI	a1bef3e	代码提交	中，需仓库仍可达
GenomeSPOT	1.0.1	语义化版本	高
MICROPHERRET	fd21931	代码提交	中
Traitar	8bd7d86	代码提交	中
NCBI Taxonomy	2025-07-28	快照日期	高
GTDB	r220	发布批次	高

8.6 一个开放性问题的位置

它不解决也不试图解决的问题是可观测性：实验室标准培养基上不生长，不等于自然界不生长；37 摄氏度下不表现某个酶活，不等于别的温度下也不表现。这些「测了但没测出来」在表里以一个 false 出现，与「确实为阴性」无法区分。这是整个培养微生物学的共同困境，使用时留出余地：性状结论与生态观察不符时，先想是不是没培养出来。

§9 使用指引

9.1 三种角色的路径

角色	起手	关键决定	交付
微生物组分析者	下载属级或种级全数据表	选 NCBI 还是 GTDB 口径	样本 × 性状矩阵
微生物生理研究者	网页搜物种，看分支分布	实验口径还是含预测	文献检索的线索清单
数据工程师	读字段字典，写 join 与回退	接口与静态表的主备关系	可复现的取数脚本

对分析者，最容易出错的是分类口径。MetaPhlAn 或 GTDB-Tk 产的丰度表名在 GTDB 侧，直接拿 NCBI 表 join 会大面积失配。先做一次名称对数，再决定下哪张表。

对微生物生理研究者，网页的图像化结果比表格直观，但要把「这个分支有没有稳健多数」当成一个前置筛选条件，而不是事后解释。判为无稳健多数的维度，直接跳过，节省时间。

对数据工程师，最关键是别把接口写死。先试接口，超时或非 200 立即回退静态表，日志记下走了哪条路。

9.2 一条最短的可用流程

下面这条流程从零到拿到一张可用的性状矩阵，只依赖 Python 标准库，不依赖接口。

#-- 第一步：把种级与属级汇总表拉到本地
mkdir -p metatraits && cd metatraits
for f in ncbi_genus_summary_all ncbi_species_summary_all; do
  curl -sSL -o "$f.tsv.gz" "https://www.bork.embl.de/~robbani/metatraits/$f.tsv.gz"
done
ls -lh

#-- 第二步：校验表头，并统计每个分类单元覆盖了多少项性状
import csv, gzip
from collections import defaultdict

EXPECT = ["taxon_id", "taxon_name", "trait_name", "unit", "database_count",
          "total_observations", "consensus_value", "consensus_count",
          "consensus_percentage", "minimum", "median", "mean", "maximum",
          "discrete_values", "databases", "group_1", "group_2",
          "ontology_ids", "taxon_lineage"]

with gzip.open("ncbi_species_summary_all.tsv.gz", "rt", encoding="utf-8") as f:
    reader = csv.DictReader(f, delimiter="\t")
    missing = [c for c in EXPECT if c not in (reader.fieldnames or [])]
    print("缺列：", missing if missing else "无")
    cover = defaultdict(int)
    for r in reader:
        cover[r["taxon_name"]] += 1

heaviest = sorted(cover.items(), key=lambda kv: -kv[1])[:10]
for name, n in heaviest:
    print(name, n)

#-- 第三步：只保留有稳健多数的行，做成稀疏矩阵
import csv, gzip
from collections import defaultdict

matrix = defaultdict(dict)
with gzip.open("ncbi_species_summary_all.tsv.gz", "rt", encoding="utf-8") as f:
    for r in csv.DictReader(f, delimiter="\t"):
        if r["unit"] != "boolean":
            continue
        pct = float(r["consensus_percentage"] or 0)
        if pct < 85.0:
            continue                      # 官方口径：无稳健多数
        matrix[r["taxon_name"]][r["trait_name"]] = r["consensus_value"]

print("可用物种数：", len(matrix))
first = next(iter(matrix.items()))
print(first[0], len(first[1]))

这条流程省略的两件事，在正式分析里都得补上：一是按 databases 列过滤掉四个模型来源（若要求实验口径），二是把 ontology_ids 落到一张字典里，方便按概念而不是按名字检索。

9.3 引用方式

引用资源本身用论文：Podlesny D、Kim CY、Robbani SM 等，metaTraits: a large-scale integration of microbial phenotypic trait information，Nucleic Acids Research，DOI 10.1093/nar/gkaf1241。引用具体数据时，建议同时写明取数日期与所用的汇总表文件（例如「NCBI 种级全数据汇总，2026 年 10 月访问」），因为静态表会随上游更新而变。

如果研究里用了预测值，方法段应说明「性状含模型推断」，并列出贡献的模型名。这不是免责，而是让同行能判断结论的证据等级。

9.4 三种常见误用的纠正流程

三种高发误用与纠正：把无稳健多数的行当空值丢掉（应先统计丢失比例，比例过高说明粒度选错，降到属级）；把全数据的结论写进「实验验证」（应准备全数据与仅培养两版，不一致时以仅培养为准）；用 GTDB 丰度表直接对接 NCBI 汇总表（应先跑名称交集，比例低就改走映射表）。

误用	早期信号	纠正动作	需要重跑的部分
丢掉无稳健多数	可用行数骤减	降一级粒度	全部 join
预测当实验	方法段写「测定」	双版本对照	结论段与图表
跨体系直接对接	名称交集比例低	用映射表换编号	全部 join
只取中位数	结论与范围不符	改用区间描述	描述性统计
不看 database_count	单来源高占比	回到来源核实	关键结论

9.5 一份上线前的自检清单

按顺序过这份清单，能挡掉大多数会在评审阶段被问到的点。

序号	自检项	通过标准	不通过时
1	分类体系是否统一	丰度表与性状表同侧	换表或做映射
2	是否含预测	方法段已注明	补写说明
3	无稳健多数如何处理	有明确规则并写进方法	补规则
4	关键结论的证据来源	能指到具体库与条数	回记录视图核
5	引用的取数日期	文中已写	补写
6	许可确认	再分发前已询问	暂停分发
7	接口依赖	有回退路径	补回退
8	稀疏性处理	分析设计已考虑	改设计

§10 AI 使用声明

项目	声明
数据性质	微生物分类单元与基因组的表型性状聚合，非人类受试者数据
可否直接用于训练	可，但布尔类性状的类不平衡明显，需按分类单元重采样
建议用途	性状富集、生态位推断、假设生成、文献检索起点
不建议用途	把预测值当作实验标签、做临床诊断依据、菌株级判决
偏差风险	覆盖偏向模式菌株与病原菌，未培养类群几乎全为推断
标注要求	保留 databases 列，训练集里区分观察与推断
引用要求	引论文 DOI，并注明取数日期与所用汇总文件
版本标注	无版本号，须注明 NCBI 与 GTDB 快照日期

常见误读（避坑清单）

常见说法	实际情况	证据
「它有两百多万个基因组，所以覆盖很全」	基因组数不等于有性状的单元数，两者是不同的计数	首页 About 段与 Traits 目录页
「consensus_percentage 100% 说明结论很可靠」	一条记录也能给出 100%，它是构成比例不是置信度	文档页 Trait Summaries 段明示
「这些性状都是实验测出来的」	四个模型提供的推断与实验同表，靠 badge 与 databases 区分	首页 Databases 菜单分两组列出
「种级结果就是这种菌的性状」	种内菌株差异会被压缩成比例，可能指向不存在的典型菌株	§4.3 的案例
「查不到某物种说明数据有错」	更可能是该种没有被培养描述过，或被判为无稳健多数	85% 阈值设计
「NCBI 和 GTDB 的结果可以直接叠在一起」	两套体系边界不同，须用映射表并接受边界失配	文档页 Downloads 段
「接口随时可用，直接写进流水线」	核验当日三个端点均 404，首页挂维护提示	§5.6 的探测结果
「它和 BacDive 是同类产品」	BacDive 是上游来源之一，本库做的是跨库合流与预测	首页 About 段
「性状名一样就一定是同一件事」	来源库同名不同义，须靠本体编号对齐	§3.6 的颗粒度对照
「拿了数据就能直接发表，许可没问题」	官方未单列数据许可标识，再分发前应询问	官网页脚与 About 页

FAQ

Q1：MetaTraits 和 BacDive 是什么关系？
BacDive 是本库四个培养数据源之一。本库不重复它做过的实验，做的是把四家的观察统一到同一套性状名与本体上，再补上模型推断。记录单位也不同：BacDive 到菌株，本库到分类单元。

Q2：consensus_percentage 能当置信度用吗？
不能。官方文档明确说它表示有多大比例的观察或预测落在该取值上。一条记录也能得到 100%，与「高度确定」无关。判断可靠性要同时看观察条数与贡献库数。

Q3：预测值和实验值混在一起，怎么区分？
网页上有 AI badge。下载表里看 databases 列，冒号前是来源名：BacDive-AI、GenomeSPOT、MICROPHERRET、Traitar 是模型，其余是培养数据库。要严格实验口径，就只保留非模型来源的行，或直接用仅培养版本。

Q4：能不能直接接到宏基因组丰度表上？
可以，接入点是分类单元名，但须先对齐分类体系：GTDB 注释的丰度表对 GTDB 侧，NCBI 体系对 NCBI 侧。pivot 之后矩阵非常稀疏，设计分析时要预判。

Q5：为什么同一个物种在不同分支下结论不一样？
因为性状在种内不保守，同种不同菌株的温度耐受、盐度上限、碳源谱常常不同，种级汇总把这些差异压成比例。分支越小越容易触发 85% 阈值，此时系统给的是「没有共识」，而不是一个错误的共识。

Q6：查一个物种什么都没查到，是数据错了吗？
多数情况下不是。更常见的原因是该物种几乎没有被培养描述过，或所属分类单元在所选库里没有记录。换到属级或科级再查一次，或用仅培养表对照，看是否因排除预测而变空。

Q7：接口为什么返回 404？
核验当日三个端点都返回 404，首页同时挂着维护提示。文档给出的路径 /api/v1/traits/taxon/<taxonomy_id> 本身没有问题，问题在服务状态。建议以静态汇总表为主路径，接口作加速件。

Q8：数据许可是什么？能直接再分发吗？
官网声明使用遵循 EMBL 隐私政策，但未给数据文件单列许可标识，下载页也没有明确的 CC 标注。再分发或商用前，按官网联系方式询问较稳妥。

Q9：它和 KEGG、CAZy 这类功能库有什么区别？
功能库回答「群落具备什么基因能力」，本库回答「这个分类单元被观察到有什么性状」。前者基于序列推断，后者基于文献与实验记录。两者互补。

Q10：用了它的数据，论文里该怎么写？
引论文 DOI，写明取数日期与所用汇总文件，并说明性状是否含模型推断。关键结论若只由推断支撑，值得在方法或讨论里点明，目的是让同行判断证据等级。

术语表

术语	含义
表型性状	可观察的生理、形态或代谢特征，如能否运动、是否产芽孢
MAG	宏基因组组装基因组，从混合样本拼接出的单个基因组
分离株	从样本中培养并纯化得到的单一菌株
模式菌株	与新种描述同时指定、作为该种参照的菌株
归一化	把不同来源的不同叫法收敛到同一个名称
本体	受控词表，词条之间有层级与关系，如 OMP、GO
OMP	微生物表型本体，本库多数形态与生理性状锚在这里
GO	基因本体，覆盖生物学过程与分子功能
CHEBI	化学实体本体，碳源利用类性状挂在这里
ENVO	环境本体，栖息地与生态位相关性状挂在这里
GTDB	基因组分类数据库，按平均核苷酸一致性重新划定物种边界
NCBI Taxonomy	美国国家生物技术信息中心的分类体系，菌株登记常用
共识值	分支内出现最多的取值
无稳健多数	分支内一致率低于 85% 时的标记
观察	来自培养数据库的实验或文献记录
预测	模型基于序列给出的推断值
溯源	一条数据回到来源库或模型的路径信息
基因组集合	一组经过统一质控的基因组，如 proGenomes、SPIRE
基因组分箱	从宏基因组中把基因组片段归类到单个基因组的过程
性状富集	检验某组分类单元的性状分布是否偏离背景
线性关系	分类单元之间的上下级从属关系
分类快照	某一日期冻结的分类体系版本
平均一致率	映射表中被对应上的单元在两边编号一致的比例
表头校验	检查下载文件的列名与顺序是否符合预期

附录 A：核心数字核对表

项	值	来源	来源层级
基因组覆盖	超过 2.2 million	论文摘要与首页 About	官方页面 + 论文摘要
性状数量	140 项以上	论文摘要与 Traits 目录页	官方页面 + 论文摘要
培养数据源数	4 个	首页 About 段	官方页面
预测模型数	4 个	首页 Databases 菜单与 Traits 页	官方页面
NCBI 分类快照	2025-07-28	导航栏 Taxonomy 下拉	官方页面
GTDB 版本	r220	导航栏 Taxonomy 下拉	官方页面
多数判定阈值	85%	文档页 Trait Summaries 段	官方页面
GTDB→NCBI 平均一致率	99.47%	文档页 Downloads 段	官方页面
NCBI→GTDB 平均一致率	99.87%	文档页 Downloads 段	官方页面
汇总表文件数	6 个	文档页 Downloads 段	官方页面
映射表文件数	2 个	文档页 Downloads 段	官方页面
论文 DOI	10.1093/nar/gkaf1241	About 页 Cite 段	官方页面
论文期刊	Nucleic Acids Research	About 页 Cite 段	官方页面
论文标称日期	2025-11-26	About 页 Cite 段	官方页面
接口鉴权	无需鉴权	文档页 API Access 段	官方页面
接口状态	核验当日 404	§5.6 探测结果	本文核验
静态表可用性	HTTP 200	核验当日 HEAD 请求	本文核验
静态表结构版本	last-modified 2026-06-10	核验当日 HEAD 请求	本文核验

附录 B：数字的来源分层

第一层，官方页面：2.2 million、140 项以上、4 个来源库、4 个模型、NCBI 2025-07-28、GTDB r220、85%、99.47%、99.87%、6 张汇总表、2 张映射表、接口无需鉴权。全部来自 metatraits.embl.de 的首页、文档页与关于页。

第二层，论文摘要：2.2 million、140 项以上、四个培养来源名、四个预测来源名、NCBI 与 GTDB 双链、五个性状大类、两个工作流名。来自 Europe PMC 返回的 NAR 论文摘要。

第三层，本文核验：三个端点的 404、静态表的 HTTP 200 与 last-modified、汇总表十九列的列名与顺序、首个数据行的取值。这些是核验当日的一次性观察，会随服务状态变化。

未纳入的部分：任何需要全量下载后统计的分布数字、任何字段空值率、任何按分支的覆盖率排名。这类数字属于拿到数据之后自己该做的第一步，写在这里既不稳定也无助于决策。

附录 C：完整参考文献

1. Podlesny D, Kim CY, Robbani SM, Schudoma C, Fullam A, Reimer LC, Koblitz J, Schober I, Iyappan A, Van Rossum T, Schiller J, Grekova A, Kuhn M, Bork P. metaTraits: a large-scale integration of microbial phenotypic trait information. Nucleic Acids Research. 2025. doi:10.1093/nar/gkaf1241.
2. metaTraits 官方网站，https://metatraits.embl.de，访问日期 2026-10-27。
3. metaTraits 文档页，https://metatraits.embl.de/documentation，访问日期 2026-10-27。
4. metaTraits 关于页，https://metatraits.embl.de/about，访问日期 2026-10-27。
5. metaTraits 性状目录页，https://metatraits.embl.de/traits，访问日期 2026-10-27。
6. NCBI 种级全数据汇总表，https://www.bork.embl.de/~robbani/metatraits/ncbi_species_summary_all.tsv.gz，访问日期 2026-10-27。

附录 D：核验任务代码

#-- 复现本文的核验过程：页面、接口、静态表三层
set -u
SITE="https://metatraits.embl.de"

echo "== 页面 ==="
for p in "" "documentation" "about" "traits"; do
  printf "%-16s %s\n" "/$p" "$(curl -s -o /dev/null -w '%{http_code}' "$SITE/$p")"
done

echo "== 接口 =="
for p in "api/v1" "api/v1/traits/taxon/511145"; do
  printf "%-32s %s\n" "/$p" "$(curl -s -o /dev/null -w '%{http_code}' "$SITE/$p")"
done

echo "== 静态表 =="
curl -sI "https://www.bork.embl.de/~robbani/metatraits/ncbi_species_summary_all.tsv.gz" \
  | grep -Ei "HTTP/|content-length|last-modified"

echo "== 表头 =="
curl -s "https://www.bork.embl.de/~robbani/metatraits/ncbi_species_summary_all.tsv.gz" \
  -r 0-3000 | gzip -dc 2>/dev/null | head -1 | tr '\t' '\n' | nl

附录 E：如果只记五件事

第一，它解决的是「查一个菌被描述过什么」，不是「测一个菌是什么」。定位在检索与聚合，不在测定。

第二，表里的性状有两个来源：培养数据库的实验记录，和四个模型的推断。混在一起是设计选择，不是缺陷，但引用时要分开。

第三，覆盖极不均匀。模式菌株与病原菌数据密集，难培养类群近乎空白。跨门比较前先看仅培养表的覆盖。

第四，种级汇总是比例不是结论。低于 85% 一致率时官方直接判无稳健多数，这个标签是有用信息，不是系统失败。

第五，静态汇总表比接口可靠。写流程时把接口当加速件，主路径放静态表。

编辑说明

核验时间 2026-10-27，方式为直接请求官方页面 HTML、Europe PMC 接口与静态文件头，未使用搜索引擎摘要。覆盖的页面为首页、documentation、about、traits 四个，接口探测了三个路径，静态表只取了表头与首个数据行所在的前若干字节，未下载全量文件。

文中所有规模与结构数字均有来源层级归属，见附录 A 与附录 B。凡属一次性观察（接口 404、静态表 200 与修改时间），已在正文标注为核验当日状态。

未覆盖的内容：未逐一验证 140 项性状在本体中的映射是否全部有效；未核对六个汇总表之间的数值是否自洽；未测试 porTraits 与 sumTraits 两个工作流的实际输入输出。这四项留作后续补充。

官方内部存在两处口径未说明之处：一是论文页标称日期 2025-11-26 与期刊早期在线日期之间的差异，二是接口文档里 MAX_IDS 未被替换成具体数值。两处均按原文陈述写出，未作推断。

---

相关数据集导航

以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：

• ipd-imght-hla — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• mgi — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• wikipathways — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• card-db — 共享标签：基因组学与多组学 / 微生物组 / 变异与注释 / 知识图谱
• sequence-ontology — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• bv-brc — 共享标签：基因组学与多组学 / 微生物组 / 变异与注释
• alliance-genome — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• dbcan-hgm — 共享标签：基因组学与多组学 / 微生物组 / 变异与注释
• cspec — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱
• cellosaurus — 共享标签：基因组学与多组学 / 变异与注释 / 知识图谱

导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。