GMrepo v3 — 人类肠道宏基因组整理库：302 种疾病、11.9 万 run 与 MCI 一致性指数

INFOBOX — GMrepo v3 一屏速览

维度	内容
本质	人类肠道宏基因组整理库（curated database），不是原始数据仓，也不是竞赛基准
维护方	华中科技大学（HUST）陈卫华课题组，与济宁医学院合作
论文	Nucleic Acids Res 2026;54(D1):D734–D742（doi:10.1093/nar/gkaf1190；2025-11-24 在线首发）
三代	v1 2019（58,903 runs/253 项目/92 表型）→ v2 2022（71,642/353/133）→ v3 2026（118,965/890/302）
规模（论文口径）	890 项目、118,965 runs（16S 87,048 + 宏基因组 31,917）、302 种疾病
规模（官网实时）	196,099 runs、1,172 项目、351 表型（2026-10-17 抓取，论文定稿后仍在增长）
核心增量	MCI（Marker Consistency Index）：把"这个菌在多少研究里同向变化"压成一个 0–100% 的数
marker 层	1,299 marker taxa（726 种 + 573 属），167 个表型对，来自 275 个 curated 项目
获取	免费、免注册，/Downloads/SQLDumps/ 下 11 个 .txt.gz + 全库 gmrepo.sql.gz
license	官方未声明——这是本条目最重要的风险提示
一句话定位	想研究"某个菌到底是不是真的和某种病有关"，GMrepo v3 是目前把"跨研究一致性"做得最显式的公开整理库之一

---

§0 导读：这个数据集解决什么问题

0.1 一个具体的研究困境

假设你在做一个结直肠癌（colorectal cancer, CRC）与肠道菌群的课题。你检索到公开数据里有几十个 CRC 相关的肠道宏基因组项目，来自中国、美国、欧洲、日本。你想回答一个看起来很朴素的问题：有没有哪些菌，在多个独立队列里都稳定地在患者中升高？

按传统做法，你需要：

1. 逐个去 ENA / SRA 找项目，读原文补充材料确认哪些样本是 CRC、哪些是健康对照；
2. 下载原始 fastq，自己跑质控、去宿主、物种注释；
3. 把几十个项目的丰度表对齐到同一套分类体系；
4. 手动做 meta 分析，逐个菌统计方向一致性。

这四步里，第一步（元数据整理）通常最耗人，也最容易出错——论文里的分组信息常常藏在补充表、甚至只在图注里。第三步（统一重注释）则要求所有项目用同一版本的工具和参考库，否则"差异"里混着方法学差异。

GMrepo 的存在意义就是把这四步的前三步做完并公开：它人工整理了宿主元数据、用统一流程重新注释了所有样本、按表型分组，并且（从 v2 开始）在项目级别识别了疾病 marker、（v3 起）用 MCI 量化这些 marker 的跨研究一致性。

0.2 它不是什么

明确边界比罗列功能更重要：

• 它不是原始数据仓。GMrepo 明确说明"因硬件存储限制，不直接提供原始测序数据"，只在网页上给 run accession 并跳转 NCBI SRA。它给的是派生的种/属相对丰度表与人工整理的元数据。
• 它不是机器学习基准。没有官方 train/test 划分、没有排行榜、没有 baseline 模型分数。它的"评估"含义是生物学复现性评估（marker 是否在多个研究中同向），不是模型性能评估。
• 它不是某一次研究的数据集。890 个项目是汇集而来，每个项目有自己的采样协议、测序平台、人群构成。GMrepo 统一的是处理流程与元数据格式，不可能统一各项目的研究设计。
• 它不是 v3 才有的东西。v1（2019）和 v2（2022）都已发表且被广泛引用；v3 是同一数据库的第三代快照。检索时看到的"GMrepo"数字可能来自任一版本，必须看口径。

0.3 为什么它值得一个 AI-Ready 条目

对 AI/ML 研究者而言，GMrepo v3 的价值不在"拿来训一个分类器"（虽然可以），而在于三个更稀缺的属性：

1. 表型标签已经是人工整理过的。疾病/健康分组不是靠关键词猜的，是逐个项目读过原文定的。这在微生物组领域是稀缺资源。
2. 特征是统一的。所有样本都用 QIIME2（16S，ASV 层面）或 MetaPhlAn4（宏基因组）重新注释，丰度可比。这意味着你可以把不同项目的样本放进同一个特征空间。
3. 带"证据强度"标注。MCI 直接告诉你某个 marker 在多少比例的研究里方向一致——这相当于给每个候选生物标志物附了一个可靠性分数，是构建"可信特征筛选"任务的天然素材。

代价也要说清楚：license 未声明、原始数据需自行回溯、元数据缺失率高、规模存在三个口径。这四点会在后文反复出现。

0.4 本条的读法建议

你的角色	建议先读	关键结论
想做疾病-菌群关联的研究者	§1 → §2 → §4	先确认你的疾病表型在 302 种里、且样本量够
想构建 ML 数据集的人	§2 → §3 → §5 → §6	注意 QC 通过率与元数据缺失，别把 QC 失败样本当负例
关心可复现性的方法学者	§4 → §8	MCI 的设计思路可直接迁移到其他组学
只想知道怎么下载	§6 + 附录 D	11 个 txt.gz + 一个 sql dump，无 API
要做合规审查	§6.4 + §10 坑 1	license 未声明是硬伤，需向作者确认

---

§1 数据集速览：十问十答

Q1：GMrepo v3 到底是什么？
一个由华中科技大学陈卫华课题组维护的、对人类肠道宏基因组进行人工整理元数据 + 统一重注释的公开数据库，第三代版本发表于 Nucleic Acids Research 2026 年数据库专刊。

Q2：v3 和 v2、v1 是什么关系？
同一数据库的三个连续版本快照，不是三个独立数据库。v1（2019）：58,903 runs / 253 项目 / 92 表型；v2（2022）：71,642 runs / 353 项目 / 133 表型，首次引入 marker 识别与跨数据集比较；v3（2026）：118,965 runs / 890 项目 / 302 表型，新增 MCI 指数与 marker 中心界面。

Q3：数据从哪来？
从 ENA（European Nucleotide Archive）与 NCBI SRA 等公共测序库收集，再读原始文献人工补齐宿主元数据。原始数据本身仍留在 SRA，GMrepo 只存派生结果。

Q4：里面有什么表？
项目表、run 主表（含人工整理元数据）、种级相对丰度、属级相对丰度、丰度汇总、种/属共现、按表型统计、MeSH 映射、NCBI 分类表，外加一个全库 MySQL dump。

Q5：v3 最大的方法学新增是什么？
MCI（Marker Consistency Index，标记物一致性指数）。它把"某个菌在健康 vs 疾病的比较中被识别为差异 marker"这件事，跨多个项目汇总成"出现频率 × 方向一致性"的单一百分比。

Q6：MCI 怎么读？
论文给出的经验阈值：MCI > 75% 视为在健康对照中稳健富集；MCI < 25% 视为在疾病中稳健富集；中间区间为方向不一致或证据不足。

Q7：1299 个 marker taxa 是什么意思？
726 个种 + 573 个属，共 1299 个分类单元，它们在某些表型对之间有显著的丰度差异，并且被跨项目比较过。分布在 167 个表型对中，来自 275 个"精心整理（curated）"的项目——注意这 275 只是全库 890 项目的一部分。

Q8：能下载吗？要钱吗？要注册吗？
能，不要钱，不要注册。官网 /Downloads/SQLDumps/ 目录下提供 11 个 .txt.gz 静态文件与一个 gmrepo.sql.gz 全库转储，直接 HTTP 下载。

Q9：有 API 吗？
没有 REST API。官方文档明确只提供静态文件与网页版图形查询构建器（Graphical Query Builder），查询结果页可导出 TSV。要程序化批量检索，得下载全库 dump 自建索引。

Q10：license 是什么？
官方没有声明。 官网与文档站都只有 “Copyright © 2021 HUST Chen lab” 字样，没有 CC BY、CC0、ODbL 之类的授权文本。数据可以免费下载，学术使用按惯例引用最新论文；但二次分发与商业使用处于法律不确定状态，使用前应直接联系作者确认。

1.1 速览补充表：三代关键指标对照

指标	v1（2019）	v2（2022）	v3（2026）
项目数	253	353	890
runs/samples	58,903	71,642	118,965
其中 16S 扩增子	41,285	45,111	87,048
其中宏基因组	17,618	26,531	31,917
表型（phenotype）数	92	133	302
marker taxa	—（未引入）	592（350 种 + 242 属）	1,299（726 种 + 573 属）
表型对	—	47	167
marker 来源项目	—	83	275
一致性指标	—	无（仅趋势对比）	MCI
DOI	10.1093/nar/gkz764	10.1093/nar/gkab1019	10.1093/nar/gkaf1190

一眼可见的增长不止是"量"：16S 占比从 v2 的 63% 升到 v3 的 73%，说明 v3 的扩张主要靠扩增子项目；而宏基因组项目增幅相对温和（26,531 → 31,917，+20%）。这会影响下游分析——16S 只到属级（多数情况），宏基因组可到种/株级，混合使用时特征空间不对齐。

1.2 一句话结论

GMrepo v3 是"把文献里的分组信息抠出来、把所有样本用同一把尺子重新量一遍、再告诉你哪些菌在不同研究里说法一致"的基础设施型数据资源。它的门槛在理解口径，不在获取。

---

§2 数据构成与规格

2.1 三层漏斗：从 118,965 到 68,723

GMrepo 的规模不能只报一个总数。文档站 “Database overview” 页给出了一条清晰的处理漏斗，这是理解整个数据集最有用的一个视角：

层级	runs/samples	项目数	含义
① 已收录元数据	118,965	890	只要元数据整理完成即计入，其中不少样本根本没有下载或处理
② 已完成原始数据处理	108,176	884	下载了 fastq 并跑完了 QC 与注释流程
③ 可获得丰度数据	68,723	664	通过 QC，丰度表里真的有数
④ QC 失败	39,453	472	被剔除，但 run 记录保留

三个数字之间的关系值得细看：

• ①→② 掉了 10,789 个 run（约 9%），对应"元数据整理了但原始数据取不到或没处理"的情况——公共数据库里 run 被撤、被合并、或下载失败都属常态。
• ②→③ 掉了 39,453 个 run，QC 通过率约 63.5%。这是最需要注意的数字：如果你天真地以为 118,965 个样本都能用，实际可用的不到六成。
• ③+④ = 68,723 + 39,453 = 108,176，恰好等于 ②。这是唯一一个严格配平的等式。
• 但项目数上 664 + 472 = 1,136 > 884，不配平。原因是按项目计数时同一个项目可以同时出现在"有可用样本"和"有失败样本"两侧——一个项目里有些 run 过了 QC、有些没过，两边都被记一次。文档没有明说这个重叠，但从算术上可以反推出来。

这就是典型的"同一份数据、两个维度计数"陷阱。看到 664 和 472 相加超过 884，不要以为是文档写错，是计数口径不同。

2.2 QC 规则：两道闸门

文档 “Data processing & QC” 页披露的两轮 QC 规则很简洁：

第一轮（测序深度闸门）：16S 样本的 clean reads 少于 20,000 条，判为 QC failed（QC status = 0），剔除。

第二轮（多样性闸门）：注释完成后，如果某个样本里单一分类单元占总丰度超过 99.99%，说明扩增或测序出了严重问题（比如引物偏好导致近乎纯培养的假象），同样判为 failed。

注意 v1 论文 Figure 2 的图注里，这条规则写成了"less than 20k reads or 99.99% of the total abundance"——一个句子把两道闸门并在一起说。两种表述不矛盾，但读论文时容易误以为是一个阈值；实际执行是两轮、两个条件。

这套 QC 的严厉程度决定了用途边界：

• 20,000 条 reads 对 16S 而言是相当宽松的下限（多数可用样本在数万到十万级），所以 63.5% 的通过率主要不是被深度卡掉的；
• 更可能的原因是大量老项目测序深度本身偏低、或 SRA 上的 fastq 质量参差。但这只是推断，论文未给出 QC 失败原因的分布统计（见 §10 遗留疑点）。

2.3 分类单元：1,683 种、1,515 属

在 68,723 个可用样本中，GMrepo 共识别出 1,683 个物种，归属于 1,515 个属。纳入阈值是两条同时满足：

1. 至少在 2 个样本中出现；
2. 中位相对丰度 ≥ 0.01%。

这两个阈值都很宽松，意在"尽量不漏"，而不是"只留高置信"。后果是丰度表里包含大量低丰度、低流行率的物种——做稀疏化或特征筛选时要注意，1,683 不是"可靠物种数"，是"出现过的物种数"。

与 marker 层对照：marker 物种只有 726 个。这 726 是 1,683 的子集（还需满足"在表型对间有显著差异且进入 curated 项目"），但两者不可相减——1,683 − 726 = 957 不代表"957 个无关联物种"，因为绝大多数物种从未被纳入任何 marker 分析。

2.4 表型体系：302 种疾病与健康对照

v3 把注释的疾病表型从 v2 的 133 扩到 302。表型组织方式（自 v1 起未变）是以表型为中心（phenotype-centric）：

• 每个 run 归属于一个表型；
• 表型取"健康"或具体疾病名（对齐 MeSH 医学术语体系，库内提供 mesh_data.txt.gz 映射表）；
• 同一个项目通常同时包含患者与健康对照，因此在"按表型检索"时，一个项目会被多个表型重复命中——官网首页对此专门有提示：“若用户未限定表型，检索到的项目数可能大于实际数量”。这句话是检索时最容易踩的坑之一。

健康对照不是第 303 个表型，而是作为对照基线单独汇总，在丰度统计里与各疾病并列展示。

2.5 宿主元数据字段

人工整理并随 run 一起发布的宿主侧字段（依据文档 “All runs” 表说明与 v1/v2 论文方法节）：

字段	说明	典型缺失情况
phenotype	健康 / 疾病名	少量样本表型不明（v1 论文单独统计过 “unknown phenotype”）
country / population	采样国家或人群	多数有，但粒度不一（国家 vs 地区）
age	年龄	缺失较多，部分研究只给年龄段
gender / sex	性别	缺失中等
BMI	体质指数	缺失最严重，很多研究不报
antibiotics usage	近期抗生素使用	极稀疏，仅少数研究记录

v1 论文 Figure 3 专门画了元数据完整性的分布图，并按"年龄、性别、BMI 三项齐全"来评估完整性。这张图传达的信号很明确：不要假设 GMrepo 的元数据是齐全的，它是"尽力整理"的结果，不是"完整登记"。

对建模者的直接影响：

• 若要做年龄/性别分层分析，样本量会骤降；
• BMI 与抗生素使用几乎不能作为协变量在全库层面使用，只能在少数项目内部使用；
• 跨项目比较时必须先跑一遍缺失率审计，而不是直接 groupby。

2.6 项目来源与国别分布

v3 论文摘要未列国别统计；中文二次报道（热心肠日报，2025-11-25 转载）称样本"广泛分布于全球 45 个国家"。这一数字未在英文摘要中直接出现，属于二手中文来源口径，正文采用时应标注来源（见 §10 存照 A）。

对使用者更实际的问题不是"覆盖多少国"，而是分布是否均衡。微生物组研究的国别分布长期高度集中于中美欧，GMrepo 作为汇集库无法改变这一点。做跨人群泛化研究时，这是一条硬约束，而非可以靠样本量弥补的问题。

2.7 文件清单与格式规格

官方下载目录 https://gmrepo.humangut.info/Downloads/SQLDumps/ 的完整清单（全部为 .txt.gz，制表符分隔纯文本；最后一项为 MySQL 转储）：

文件名	内容	典型用途
projects.txt.gz	项目列表与描述	建立项目索引、核对入组标准
stats_by_phenotype_and_project.txt.gz	项目汇总（总 run / 已处理 / 有效 / 失败）	筛选"样本量够且 QC 通过率高"的项目
sample_to_run_info.txt.gz	全部 run + 人工整理元数据	主表，表型分组的唯一权威来源
samples_loaded.txt.gz	已处理 run + 所用工具 + QC 状态	复现处理链、区分已处理/未处理
species_abundance.txt.gz	种级相对丰度（仅 QC 通过）	主要特征矩阵
species_abundance_summary.txt.gz	种级丰度统计摘要	快速看分布，避免解压全表
species_cooccurence.txt.gz	种/属共现	网络分析、生态位研究
stats_by_phenotype.txt.gz	按表型统计 run 数、有效/失败数、关联物种属数	评估某疾病的可用样本规模
mesh_data.txt.gz	MeSH 术语表	疾病名的标准化与跨库映射
superkingdom2descendents.txt.gz	NCBI 分类表（taxon_id → 学名与层级）	分类层级聚合、名称对齐
gmrepo.sql.gz	全库 MySQL dump	需要联表查询、自建 API 时的唯一选择

两个容易忽略的细节：

1. taxon_id 与 ncbi_taxon_id 不是一回事。文档专门提醒：taxon_id 是 GMrepo 内部唯一 ID，ncbi_taxon_id 才是实体在 NCBI 分类体系中的 ID。联表时用错会导致大量空连接。
2. 丰度表是按样本归一化到 100% 的。文档写明"相对丰度随后按样本计算，总和归一化为 100%"。这意味着丰度不能直接跨样本相加当作绝对量，"总菌量"信息在归一化时已经丢失。

2.8 规格小结表

项目	规格
主键	run accession（SRR/ERR/DRR 等 SRA 编号）
记录粒度	run/sample 级（非个体级；同一人多次采样会记多条）
特征空间	种 1,683 / 属 1,515（全库可用样本）；marker 层 726 种 + 573 属
标签空间	302 种疾病 + 健康对照
数值类型	相对丰度（百分比，样本内归一化至 100%）
缺失值	元数据字段大量缺失；丰度表中不出现即视为 0 或未检出
压缩	gzip，解压后为 TSV 文本
程序化访问	无 API；静态文件 + 网页查询构建器（结果可导 TSV）
版本标识	以论文 DOI 为锚；官网首页未标版本号，工作台域名含 2025

最后一行值得强调：去官网首页看不到"v3"字样，但文档站数字与 v3 论文一致，工作台入口域名是 gmrepo2025.humangut.info:8443。判断你看到的是哪一版，靠数字而不是靠页面标签。

---

§3 处理与注释流水线

3.1 为什么"统一重注释"比"直接收集丰度表"值钱

微生物组领域有一个默认事实：不同研究用不同工具、不同参考库、不同参数做出的丰度表不可直接合并。同一份 fastq，用 QIIME2 的某个参考库注释和用 MetaPhlAn 注释，得到的物种组成可以在属级就有明显差异；换参考库版本又会有差异。

如果直接把 890 个项目的原始丰度表拼起来做 meta 分析，你得到的"病例 vs 对照差异"里会混进"工具差异"和"参考库差异"。这正是 GMrepo 花费大量算力重新处理全部数据的理由。

代价是：GMrepo 的丰度值只代表"用 GMrepo 流程处理后的值"，不是各原始研究的官方结论。若你的研究需要复现某篇原文的数字，必须用原文的方法，不能用 GMrepo 的表。

3.2 16S 分支：QIIME2 + ASV

步骤	工具	说明
质量评估	FastQC 0.11.8	唯一在文档中标注了版本号的工具
去接头/低质量碱基	Trimmomatic	版本未披露
FASTQ → FASTA	Seqtk	版本未披露
分类注释	QIIME2	版本与参考库均未披露
输出单位	ASV（Amplicon Sequence Variant）	非 OTU

为什么用 ASV 而不是 OTU：文档给出的理由是 ASV 能更精确地衡量序列变异，且便于不同研究之间的比较（可追踪、可重复）。OTU 依赖 97% 相似度聚类，聚类结果随数据集组成而变——同一批序列放进不同数据集里聚类，边界会移动；ASV 是逐条序列的去噪判定，同一序列在不同数据集中得到同一 ID。对"跨项目比较"这个核心目标，ASV 是正确选择。

但要清楚 ASV 的代价：ASV 是一串序列指纹，跨项目合并时通常还要再做一步分类学注释才能对齐到"物种"。而 16S 的物种级分辨率本身就有限（多数 16S 只能到属），这是为什么 v3 里 16S 占比升到 73% 却仍只有 726 个 marker 物种的部分原因。

3.3 宏基因组分支：MetaPhlAn4

宏基因组（shotgun metagenomics）走 MetaPhlAn4 默认参数。MetaPhlAn4 是基于标记基因（marker gene）的物种定量工具，不需要组装，速度快、跨样本可比性好，代价是对低丰度物种灵敏度有限、且只能给出其参考库中收录的物种。

文档未披露 MetaPhlAn4 使用的数据库版本。这是一个实质性缺口：MetaPhlAn 的数据库版本更新频繁，不同版本之间物种集合会变。若你要与自己的 MetaPhlAn 结果对比，必须先确认版本一致（见 §10 遗留疑点 B）。

3.4 相对丰度的归一化与解读

文档明确：相对丰度按样本计算并归一化为 100%。由此推出三条使用规则：

1. 不能比较绝对菌量。一个人肠道细菌总量是另一个人的十倍，在相对丰度里看不出来。
2. 组分数据（compositional data）的经典陷阱：某物种比例上升，其他物种比例必然下降，即使它们的绝对量没变。做差异分析时直接用 t 检验/ Wilcoxon 会引入假阳性，正规做法是对数比变换（CLR、ILR）后再分析。GMrepo 不提供变换后的矩阵，需自行处理。
3. 零值含义模糊。"0"可能是真的没有，也可能是没测到（尤其 16S 的低丰度物种）。全库层面大量零值是正常的，做机器学习时朴素填充会引入偏差。

3.5 疾病 marker 识别流程

marker 识别是 v2 引入、v3 大幅扩展的模块。流程骨架（依据论文摘要、文档与中文二次报道综合）：

对每个 curated 项目：
  1. 取该项目内的两个表型（通常 = 疾病组 vs 健康对照组）
  2. 在种级与属级分别做差异丰度分析（中文报道口径：LEfSe，线性判别分析效应大小）
  3. 输出该项目内的差异分类单元及其方向（疾病组升 or 降）

跨项目汇总：
  4. 按"表型对"（如 Health vs Colorectal Neoplasms）把多个项目的 marker 并起来
  5. 统计每个 taxon 出现在多少个项目中、方向是否一致
  6. v3 新增：计算 MCI，量化"出现频率 × 方向一致性"
  7. 提供 marker-centric 界面：查同一 taxon 在不同疾病中的趋势

LEfSe 的具体参数（LDA 阈值、α 值、是否做多组比较）文档未披露，中文报道只提到"基于 LEfSe 算法"。这意味着严格的复现需要读论文方法节或联系作者（见 §10 遗留疑点 C）。

3.6 共现分析：三条件同时满足

共现（co-occurrence）模块的方法在文档中写得比较明确，是"三条件同时满足"：

检验	判定"存在"的标准	显著性
Fisher 精确检验	相对丰度 > 0.01% 视为该 taxon 存在	p < 0.05
Pearson 相关	基于相对丰度	p < 0.05
Spearman 相关	基于相对丰度	p < 0.05

三者同时通过才记为共现对，且健康状态与每种疾病分别独立计算。

这套设计的用意是双保险：Fisher 精确检验只看"有没有"，抓的是共存/互斥的生态关系；Pearson/Spearman 看"有多少"，抓的是丰度协同。只用一种检验会漏掉另一类关系。

局限也很清楚：共现不等于因果，也不等于共生。两个菌共现可能因为它们偏好同一宿主环境（比如都喜欢高纤维饮食），而非彼此依赖。而且在相对丰度数据上做相关分析，本身就受组分约束影响（伪相关），结果只宜作为假设生成，不宜作为生态机制结论。

3.7 流水线可迁移性评估

环节	可复现性	缺口
原始数据获取	高	run accession 齐全，可回 SRA
QC 阈值	高	20,000 reads / 99.99% 单单元，明确
16S 注释	中	QIIME2 版本与参考库未披露
宏基因组注释	中	MetaPhlAn4 参数明确（默认），DB 版本未披露
丰度归一化	高	样本内归一 100%
marker 识别	低	LEfSe 参数未披露
MCI 计算	中	定义清楚（频率 × 方向一致性），公式细节需查论文
共现分析	高	三条件与阈值明确

结论："拿到与 GMrepo 完全一致的丰度表"这件事无法 100% 复现，但"理解它的丰度表是怎么来的、在什么条件下可比"完全可以做到。对多数下游使用者而言，后者才是关键。

---

§4 核心方法学增量：MCI 与跨数据集可复现性

4.1 问题从哪来：微生物组 marker 的"论文依赖"

微生物组领域有一个广为人知的尴尬：同一疾病，不同研究报出的 marker 菌常常对不上。结直肠癌研究里 Fusobacterium nucleatum 是难得的共识，但绝大多数其他候选菌在换个队列后就失去显著性。

原因至少有四层：

1. 样本量与把握度：小样本研究容易出假阳性，也容易漏掉真信号；
2. 研究对象差异：人群、饮食、用药、地理，都会改变菌群；
3. 方法差异：测序平台、注释工具、参考库、统计方法全部不同；
4. 发表偏倚：阳性结果更容易发表，阴性复现躺在抽屉里。

传统解决办法是 meta 分析——但那需要原始数据且工作量巨大，且每次只能针对一个菌、一个病。

GMrepo v3 的 MCI 提供的是批量、自动化的"一致性打分"：不是回答"这个菌是不是真的有关"，而是回答"在现有研究中，这个菌的说法有多一致"。这是一个更谦逊、但更可操作的问题。

4.2 MCI 的定义与读法

MCI = Marker Consistency Index（标记物一致性指数）。论文摘要给出的定义是：它综合了 marker 在多个研究中的流行程度（prevalence）与方向一致性（directional consistency）。

用直白的话说：

• 如果一个菌在 20 个项目里被识别为 marker，其中 18 个项目都是"疾病组升高"，那它的一致性很高；
• 如果同样的 20 个项目里，9 个说升、11 个说降，那它的"平均效应"可能为零，但出现频率很高——这不是稳健信号，是噪声；
• 如果一个菌只在 2 个项目里出现，即便两次方向一致，也不该给高分。

MCI 就是把这两个维度压成一个 0–100% 的数。论文给出的经验判读：

MCI 区间	含义	使用建议
> 75%	在健康对照中稳健富集	可作为健康关联菌的强候选
25%–75%	方向不一致或证据混杂	灰区，不宜直接当生物标志物
< 25%	在疾病中稳健富集	可作为疾病关联菌的强候选

注意 0–25% 不代表"弱"，而是"强地指向疾病"。MCI 是方向性刻度，不是"质量分"。

4.3 关键统计：400 个 marker 的两端

论文给出的核心数字非常具体：

• 在改变出现在 ≥10 个项目的 marker 中，共 400 个；
• 其中 143 个在健康对照中一致富集（MCI > 75%）；
• 其中 85 个在疾病中富集（MCI < 25%）。

这组数字的价值在于它量化了"可复现"的比例：

• 两端合计 143 + 85 = 228，占 400 的 57%；
• 剩余 172 个（43%）落在灰区。

换句话说，即便是"在 10 个以上项目里都被识别为 marker"的这一批相对可靠的候选，也有超过四成方向不一致。这个数字本身就是对微生物组 marker 文献的一记提醒："在某项研究中显著"与"跨研究一致"之间的距离比想象中大。

需要提醒的是，400 只是"≥10 个项目"这个门槛下的子集，不是 1,299 个 marker taxa 的全部。项目数少于 10 的 marker 没有进入这个统计，它们的一致性无从判断——这也解释了为什么论文把"≥10 个项目"作为分析门槛：低于这个门槛，一致性统计没有意义。

4.4 四个示例 marker：读法演练

论文与中文二次报道给出的四个代表性结论，正好覆盖 MCI 光谱的四种位置：

① Fusobacterium nucleatum（具核梭杆菌）——疾病端经典
在结直肠癌中持续富集。这是微生物组领域少有的"教科书级"共识，几乎每个 CRC 菌群研究都会报。它的存在相当于一个阳性对照：如果 MCI 方法在这个菌上给不出高一致性，说明方法本身有问题。它出现在疾病端，也反过来印证了 MCI 的标定方向正确。

② Enterocloster bolteae——跨病种关联
在多病种中显著关联。这个信号的性质与前一个不同：它不是一个病的专属 marker，而是跨疾病的共性信号。这类菌在临床上更有意思（可能反映普遍性炎症或代谢紊乱），但也更容易被混杂因素污染（比如住院、用药）。

③ Faecalibacterium prausnitzii（普氏粪杆菌）——健康端旗舰
高度一致的健康富集菌。这是众所周知的"抗炎、产丁酸"菌，在 IBD、CRC、糖尿病等多种疾病中都常见下降。它在 MCI > 75% 一侧，同样起到方法学校验作用。

④ Hungatella hathewayi——疾病端、特定病种
被报道为多发性硬化（multiple sclerosis, MS）等疾病的风险菌。这是一个较新的、病种相对特定的信号。这类 marker 的价值在于指向具体机制假说，但也最需要独立队列验证。

四例并置可以看出 MCI 的实用方式：它不是筛掉所有灰区菌，而是把"经典共识"“跨病共性”“健康保护”"病种特异"分门别类。

4.5 MCI 的方法学价值与边界

价值：

1. 可迁移。这套"频率 × 方向一致性"的思路可以直接搬到任何"多研究独立发现同一类特征"的场景——影像组学、单细胞 marker 基因、GWAS 位点复现。GMrepo 提供了一个可抄的模板。
2. 把"元分析"做成了数据库功能。用户不需要自己下载几十个项目、自己跑差异分析、自己汇总，MCI 已经算好并挂在界面上。
3. 显式面对不确定性。相比"只报显著结果"，把灰区占比（43%）摆出来是诚实的做法。

边界：

1. MCI 不校正研究质量。20 个项目里 18 个一致，如果这 20 个都来自同一实验室、同一人群，一致性高不代表普适。
2. MCI 不校正发表偏倚。库里收录的是已发表项目，阴性结果本就稀少。
3. MCI 依赖上游 marker 识别的质量。若 LEfSe 参数在不同项目上不一致，方向一致性会被方法学噪声污染。
4. MCI 高 ≠ 因果。稳健的关联仍可能由共同混杂（饮食、用药、BMI）驱动。
5. MCI 的绝对数值依赖阈值设定。75%/25% 是经验阈值，论文未给出基于置换检验或 FDR 的标定依据（见 §10）。

4.6 从"趋势对比"到"一致性指数"：v2 与 v3 的方法学差别

v2 已经有跨数据集比较，做法是"把各项目的 marker 并排展示，让用户自己看趋势是否一致"。这依赖人工判读。

v3 的 MCI 把这个判读自动化、指标化。表面上是加了一个数，实质上是把"一致性"从定性描述变成可排序、可筛选、可阈值化的量。这一转变对下游至关重要：只有变成数值，才能做"给 marker 排序""取 top-N 稳健 marker 建分类器"这类操作。

这也是为什么 MCI 是 v3 论文标题里 “enhanced cross-dataset biomarker analysis” 的实质内容，而不仅仅是又多收了几百个项目。

4.7 把 MCI 当特征权重用：一个可操作的想法

对做 ML 的人，一个自然的用法是：把 MCI 当作特征可靠性的先验权重。

思路 A：硬筛选
  只保留 MCI > 75% 或 < 25% 的 marker 作为特征
  → 特征数从 1299 降到数百，噪声低，但可能丢掉病种特异信号

思路 B：软加权
  以 |MCI - 50%| 作为权重，对特征做加权或作为正则项
  → 保留全部信息，让模型自己决定用多少

思路 C：分组验证
  在 A 组项目上训练、B 组项目上测试，比较 MCI 高/低两组 marker 的泛化差距
  → 这实际上是在验证"MCI 是否真的预测了可迁移性"，是一个有价值的研究问题

思路 C 尤其值得做：论文证明了 MCI 与方向一致性相关（定义使然），但没有证明 MCI 能预测"在新队列上的表现"。这是一个明确的开放问题。

---

§5 三方口径对账：论文、文档站、官网首页

5.1 三个数字，三套说法

这是使用 GMrepo 时最容易出错的地方，也是本条必须单独成节的理由。同一时刻（2026-10-17），你能看到三套规模数字：

指标	论文快照（v3，2025-11）	文档站 overview	官网首页实时（2026-10-17）
runs/samples	118,965	118,965（收录层）	196,099
项目数	890	890	1,172
疾病表型	302	302	351
marker taxa	1,299	未列	1,864
marker 来源项目	275	未列	335
表型对	167	未列	186
物种 / 属	未列（摘要）	1,683 / 1,515	未列

5.2 差额从哪来

论文与官网的差额（+77,134 runs、+282 项目、+49 表型）不可能是统计口径差异——数量级太大。唯一合理解释是：论文是 2025-11 定稿时的快照，官网在那之后继续收录了近一年的项目。

这带来两个直接后果：

1. 引用时必须写清口径。写"GMrepo v3 有 118,965 个样本"是对的（论文口径），写"GMrepo 现在有 19.6 万个样本"也是对的（官网口径），但混着写就是错的。
2. "v3"是一个时间点，不是一个功能集。官网没有版本号标签，工作台域名带 2025，但数字已远超 v3 论文。严格说，2026-10 你下载到的全库 dump 不是 v3 论文描述的那份数据，而是它的超集。

5.3 三个口径各自适合什么场合

场合	用哪个口径	理由
写论文的方法学引用	论文快照（118,965 / 890 / 302 / 1,299 / 167 / 275）	可被审稿人核对到具体文献
报告"我能下载到多少数据"	官网实时	与实际下载内容一致
说明 QC 通过率、可用样本	文档站 overview（108,176 / 68,723 / 39,453）	唯一给出分层数字的公开来源
描述物种特征空间	文档站（1,683 种 / 1,515 属）	唯一给出该数字的公开来源

最实用的一条经验：下载完全库后，用自己的脚本数一遍 sample_to_run_info.txt.gz 的行数，以实测为准，并在方法学里写"截至下载日期 YYYY-MM-DD，全库 N 个 run"。这是唯一不会被质疑的写法。

5.4 文档站的另外两处滞后

除了规模数字，文档站还有两处明显的滞后，都属于"读文档时要多留个心眼"的类型：

① 引用文案停在 v2。 文档首页写"请引用我们最新的论文"，但给出的仍是 Dai et al. 2022（GMrepo v2, NAR 50(D1):D777–D784）。v3 论文（2026, 54(D1):D734–D742）没有被更新进去。这不是笔误，是文档维护滞后。引用时不要照抄文档站，要用 v3 的 DOI。

② 版权年份停在 2021。 站点页脚写 “Copyright © 2021 HUST Chen lab”，即便 v3 已于 2025 年发布。这也解释了为什么 license 信息看起来像"很久没维护"——事实上确实如此。

5.5 存照：容易混淆的四组数字

容易混的两组	区别
1,683 种（全库可用样本） vs 726 种（marker 物种）	前者是"出现过的物种"，后者是"在表型对显著且进入 curated 项目的物种"；后者是前者子集
302 种疾病（论文） vs 351 表型（官网）	后者含健康对照与新增疾病；"表型"与"疾病"在官网口径中并列出现
664 个项目（有可用样本） vs 472 个项目（含 QC 失败）	两者不互斥，同一项目可两侧同时计数，相加超 884
118,965 run（收录） vs 108,176（已处理） vs 68,723（可用）	三级漏斗，逐级递减，详见 §2.1

把这四组数字贴在方法学草稿旁边，能避免绝大多数"数字对不上"的返工。

---

§6 获取与许可：门是开的，牌子没挂

6.1 获取方式：静态文件，不需要任何申请

GMrepo 的获取是本文档里少见的"零摩擦"类型：

• 不需要注册、不需要登录、不需要填表、不需要申请、不需要机构邮箱；
• 所有数据以静态文件形式挂在 https://gmrepo.humangut.info/Downloads/SQLDumps/ 下；
• 直接 wget / curl / 浏览器点击即可。

最小可行的下载命令（示例，把目标目录换成你自己的路径）：

# 只取主表与种级丰度（多数分析够用）
BASE=https://gmrepo.humangut.info/Downloads/SQLDumps
for f in sample_to_run_info.txt.gz species_abundance.txt.gz \
         stats_by_phenotype.txt.gz superkingdom2descendents.txt.gz; do
  curl -O "$BASE/$f"
done

# 需要联表时再下全库 dump（文件较大，建议先看 HEAD 的 Content-Length）
curl -O "$BASE/gmrepo.sql.gz"

6.2 决策树：我到底该下哪个文件

你的任务是什么？
├─ 只想统计"某疾病有多少可用样本"
│   └─ stats_by_phenotype.txt.gz（最轻，先下这个）
├─ 想做机器学习分类（样本 × 物种）
│   ├─ 元数据与标签 → sample_to_run_info.txt.gz
│   └─ 特征矩阵     → species_abundance.txt.gz
├─ 想知道某项目为什么样本少
│   └─ stats_by_phenotype_and_project.txt.gz
├─ 想做共现/网络分析
│   └─ species_cooccurence.txt.gz
├─ 想按分类层级聚合（门/纲/目/科）
│   └─ superkingdom2descendents.txt.gz + 丰度表
├─ 想把疾病名映射到标准术语
│   └─ mesh_data.txt.gz
└─ 想自建 API / 做复杂联表 / 需要全部注释字段
    └─ gmrepo.sql.gz（全库 dump，一次性解决）

最重要的建议：先下 stats_by_phenotype.txt.gz。 它只有几百行，能立刻告诉你你关心的疾病在库里有多少 run、多少通过 QC。如果某个病只有 50 个样本，后面的建模计划可以直接调整，不必浪费带宽下载几个 GB 的丰度表。

6.3 原始数据怎么办：回 SRA

GMrepo 不提供原始 fastq。文档给出的路径有两条：

1. 网页：在 GMrepo 里点每个 run 旁的 “linkout” 图标，直接跳到该 run 在 SRA 的页面；或把 run accession 粘贴进 SRA 搜索框。
2. 命令行：SRA Toolkit 的 prefetch <run_accession> 下载，或 fastq-dump [options] <run_accession> 直接转 fastq。

实际成本提醒：单个人类肠道宏基因组样本的 fastq 常在 1–5 GB 量级，890 个项目全量下载是 TB 级工程。绝大多数研究不需要全量——如果你只用 GMrepo 的丰度表，就完全不必碰原始数据。

6.4 许可：本条最重要的风险提示

官方未声明任何 license。

这是经过三处核验的结论：

• 官网首页：无 license 段落，仅有页脚版权声明；
• 文档站（2909682517.github.io/gmrepodocumentation）全站检索：无 license / terms / 使用条款章节，页脚同为 “Copyright © 2021 HUST Chen lab”；
• 下载页：只说明文件清单与格式，无授权说明。

这意味着什么，需要讲清楚：

使用场景	法律状态	建议动作
学术研究、论文中引用	灰色但惯例可行	引用 v3 论文，在方法中注明数据来源与下载日期
论文中再分发衍生表	不确定	引用原文 + 说明"派生自 GMrepo，原库未声明许可"
商业产品中使用	高风险	必须先向通讯作者（Wei-Hua Chen）书面确认
打包进自己的公开数据集	高风险	同上；或只提供下载脚本，不打包数据本体
训练商业模型	高风险	同上

需要区分的是：论文的著作权与数据的许可是两回事。v3 论文发表在 Nucleic Acids Research（OUP 开放获取），论文文本适用 OUP 的开放获取条款；但数据本身的许可并不因论文开放获取而自动开放。这是很多使用者会混淆的地方。

对比参照：同领域的 CuratedMetagenomicData（Bioconductor）等资源通常会明确声明许可（多为 CC BY 或类似），GMrepo 在这方面是明显的短板。

6.5 API 状况与替代方案

无 REST API。 文档明确只提供静态文件与网页图形查询构建器。

对程序化使用者的三条替代路径：

1. 全库 dump + 本地 SQL：gmrepo.sql.gz 导入本地 MySQL（或转成 SQLite/Postgres），最灵活，一次性成本高但后续零成本。
2. 静态文件 + pandas：species_abundance.txt.gz 是 TSV，pandas.read_csv(..., sep='\t') 即可，适合中等规模分析。注意大文件内存占用。
3. 查询构建器 + 结果导 TSV：适合一次性、探索性查询，不适合批量。注意首页提示的"项目重复计数"问题。

6.6 获取环节的五个坑（提前警告）

1. taxon_id ≠ ncbi_taxon_id。联表出错的头号原因，详见 §2.7。
2. 丰度表是样本内归一化到 100% 的。不能当绝对量用。
3. 样本主键是 run 不是个体。同一人多次采样算多个 run，做个体级分析前必须去重（若元数据里有个体标识）。
4. 官网数字与下载内容不一致。官网首页是实时统计，你下载的是某一时刻的快照，以实测行数为准。
5. gmrepo.sql.gz 解压后体积可能远超预期。先看 HEAD 的 Content-Length，确保磁盘够。

---

§7 生态位：GMrepo 在微生物组数据资源版图中的位置

7.1 四类资源的对照

微生物组领域的公开资源大致分四层，GMrepo 处在"整理了的下游派生数据"这一层：

层级	代表资源	提供什么	与 GMrepo 的关系
原始序列仓	ENA、NCBI SRA、DDBJ	fastq / sra 文件	上游：GMrepo 的原始数据都在这
统一整理的元数据+丰度	GMrepo、CuratedMetagenomicData	人工整理的样本元数据 + 统一注释的丰度	GMrepo 的同层竞品是 curatedMetagenomicData
单一大项目	American Gut Project、HMP	单个大型队列的内部数据	上游：AGP 是 GMrepo 的重要数据来源之一
分析平台/工具	QIIME2、MetaPhlAn、LEfSe	方法与软件	上游工具：GMrepo 用它们做处理

7.2 与 CuratedMetagenomicData 的定位差异

同为"整理过的宏基因组资源"，两者路线不同（对比基于公开定位，非本次核验的具体数字）：

维度	GMrepo	CuratedMetagenomicData
发放形式	静态 TSV + MySQL dump	R/Bioconductor 包（curatedMetagenomicData()）
更新机制	官网持续追加，版本靠论文标识	包版本化，随 Bioconductor 发布周期
强项	表型中心组织 + 项目级 marker + MCI	与 R 生态无缝，元数据标准统一
一致性分析	内置 MCI 与 marker 界面	无内置跨研究一致性指标

一句话区分：GMrepo 更像"带分析结论的数据库"，curatedMetagenomicData 更像"干净的数据管道"。前者省去你自己算一致性，后者省去你自己对格式。

7.3 AGP 在其中的特殊地位

American Gut Project（AGP）是 GMrepo 的重要上游之一。v1 论文特别说明了一个细节：来自 AGP 的数据，只采信"由医疗专业人员（医生、医师助理）给出的诊断"作为表型依据——因为 AGP 是公民科学项目，参与者自报的疾病信息质量参差。

这个细节很有代表性：GMrepo 的表型标签不是"原文写了什么就记什么"，而是有准入判断的。这也是它相对"直接爬元数据"的价值所在。

同时也带来一个偏倚：AGP 中大量自报表型样本会被归入 “unknown phenotype”（v1 论文 Figure 3 专门统计了这块），导致某些疾病的有效样本比 AGP 的原始样本量少得多。做样本量规划时要预见到这一点。

7.4 数据库的"代谢"：为什么 v3 之后还在长

从论文快照（118,965 runs）到官网实时（196,099 runs）的 10 个月内增长了 65%，说明这是一个仍在活跃维护的资源，不是发表后即冻结的静态数据集。

这对使用者的正面意义：资源不会烂尾。负面意义：任何写死的数字都会过期，包括本条目里的所有数字。这正是本条反复强调"以实测为准"的原因。

判断资源是否活跃的一个简单办法：看官网首页数字与最近一次论文的差距。差距大且方向为增长，说明在维护。

7.5 下游应用生态

GMrepo 被用在几类典型下游场景（基于其数据形态推断的常见用法，非特定论文引用统计）：

1. 疾病分类器训练：以种/属丰度为特征、以表型为标签，训练 RF/XGBoost/深度学习模型。难点在跨项目批次效应。
2. 生物标志物筛选：用 MCI 做初筛，再在独立队列验证。
3. 菌群-疾病关联的假设生成：marker-centric 界面可快速看一个菌在多个病中的趋势。
4. 教学与综述：数据可下载、结构清晰，适合作为微生物组数据处理的示例。
5. meta 分析的方法学对照：把自己的差异分析结果与 GMrepo 的 marker 表对照，看是否落在"已知一致"的区域。

7.6 与库内其他条目的关系

详见 §9。这里先给结论：GMrepo 属于**“多组学-微生物组”**这一类，与影像/病理/电子病历类条目没有直接交叉，互链价值主要在同一"整理型数据库"方法论层面，而非同一数据源层面。

---

§8 方法学启示：三条可迁移的经验

8.1 经验一：把"整理"本身当作可发表的产品

v1、v2、v3 三次都发在 Nucleic Acids Research 的数据库专刊。这类工作的贡献不是新算法，而是把杂乱数据整理成可用状态，并持续投入人力维护。

这个模式对 AI 数据集建设的启示很直接：数据整理（curation）的工程价值长期被低估。一个标注质量高、元数据齐全、版本可追溯的整理数据集，其科研价值往往超过一个新训练的模型。GMrepo 连续三代发表、被广泛引用，说明学术共同体会为"可信赖的整理"付费（以引用形式）。

8.2 经验二：一致性指标可以做成一种"数据产品质量标签"

MCI 的思路是把"这个结论有多稳"变成数据的一部分。这对任何多来源数据集都适用：

• 影像组学：某纹理特征在多少个中心的研究中被报为有效？
• 单细胞：某 marker 基因在多少个数据集中被报为该细胞类型特异？
• GWAS：某位点在多少个队列中重复？

传统做法是把这些放在"讨论"或"局限"里，读者自己判断。MCI 的做法是把它做成一个可筛选的字段。这是一个简单但威力很大的设计选择：一旦变成字段，就可以排序、取阈值、作为特征权重。

8.3 经验三：诚实报告灰区比只报显著更有说服力

论文明确写出"400 个 marker 中 143 个健康富集、85 个疾病富集"，等于承认了 172 个（43%）方向不一致。这是一个不讨好但正确的选择。

对比之下，很多数据集论文只报"我们发现了 N 个 marker"，而不说其中有多少能复现。GMrepo v3 的做法提供了一个模板：在发布数据集时，同时发布"这个数据集里有多少结论是稳的"。

8.4 反面清单：GMrepo 没做好的三件事

诚实地列出短板，比单纯表扬更有用：

1. license 未声明。这是最严重的问题，直接限制了商业使用与二次分发，与本领域其他资源相比是明显退步。
2. API 缺失。2026 年的生物数据库没有 REST API 已经很少见。静态文件 + dump 的做法虽然可用，但把索引成本转嫁给了用户。
3. 处理流程版本披露不全。FastQC 标了 0.11.8，QIIME2/MetaPhlAn4 数据库版本/Trimmomatic/Seqtk 全无版本号，导致严格复现困难。

这三条都不是不可修补的技术难题，更多是工程规范意识的问题。对读者而言，这也是一个提醒：看数据集论文时，除了看规模数字，也要看它有没有把版本、许可、API 这些"不性感"的东西写清楚。

8.5 一条实践建议：先用小样本验证流程

拿到任何整理型数据库，推荐的验证顺序是：

第 1 步：下 stats_by_phenotype.txt.gz，确认目标疾病样本量
第 2 步：下 sample_to_run_info.txt.gz，看目标疾病的元数据缺失率
第 3 步：下 species_abundance.txt.gz，取目标疾病 + 健康对照的子集
第 4 步：在这个小子集上跑通全流程（预处理 → 特征筛选 → 建模 → 评估）
第 5 步：确认无误后再扩大范围 / 下载全库 dump

这个顺序能避免"下了 20 GB 才发现关键字段全空"的情况。

---

§9 与库内条目的关系

9.1 关系判定

条目	关系类型	说明
本库现有 GMrepo 任何版本条目	无	经 DB 全表检索 url_name ILIKE '%gmrepo%' 与 title ILIKE '%GMrepo%'，返回 0 行，本条目为该资源在本库的首个条目
American Gut Project	上游数据源	AGP 是 GMrepo 收录的重要项目之一；解释 GMrepo 的表型准入规则时需提及
其他微生物组/宏基因组条目	同域	若库内存在 CuratedMetagenomicData 类条目，属同层竞品，互链价值最高
其他"整理型数据库"条目	方法论同构	凡以"人工整理 + 统一重注释"为核心贡献的数据库，都与本条目在方法论上可对照

9.2 与库内条目的检索建议

若需在库内检索"微生物组"类条目，推荐按以下关键词逐个试（大小写不敏感）：

SELECT record_id, url_name, left(title, 60)
FROM ai_ready_dataset
WHERE status = 1 AND del_sign = 0
  AND (url_name ILIKE '%microbio%'
    OR url_name ILIKE '%metagenom%'
    OR url_name ILIKE '%gut%'
    OR url_name ILIKE '%16s%'
    OR url_name ILIKE '%genom%')
ORDER BY record_id;

注意：本库的在架统计必须带 del_sign = 0，否则会把历史软删占位算进来。

9.3 互链点的写作建议

本条不写具体 rid。原因是互链目标的具体 record_id 由入库顺序决定，写作阶段无法确认，写错会导致发布后"导航目标不在架"的检查失败。正确的做法是由主会话在入库后统一回填。

正文中建议表述为：“GMrepo v3 与库内 American Gut Project 等肠道菌群条目同域，前者是整理层、后者是原始队列层，二者构成上下游关系。”

9.4 为什么本条目在库里是必要的

AI-Ready 数据集谱系长期偏向影像与文本，微生物组是明显缺位的一块。而微生物组数据恰恰是最典型的"AI-Ready 难题"：

• 原始数据在 SRA，格式不统一；
• 元数据散落在论文补充材料里；
• 不同研究的方法差异巨大，合并需要统一重注释；
• 表型标签的可靠性依赖人工整理。

GMrepo 把这些问题解决了一大半，是这一领域最有代表性的"整理型"资源。收录它，能填补本库在"多组学-微生物组"上的空白，也能为其他整理型数据库提供一个可对照的样板。

---

§10 避坑清单：十个已核实或高度可疑的坑

坑 1：license 未声明却被当作开放数据

现象：很多二手介绍（包括部分中文科普）把 GMrepo 描述为"免费开放数据"，读者据此直接用于商业项目或打包分发。

实情：官网与文档站均无 license 文本，只有版权声明。“免费可下载"不等于"授权可再分发”。

应对：学术使用引用论文即可；商业或再分发前，必须写信向通讯作者确认。引用时写"数据来源：GMrepo v3（https://gmrepo.humangut.info），原库未声明许可"，比含糊写"公开数据"更安全。

坑 2：把官网首页的实时数字当成论文数字

现象：写论文时引用"GMrepo 有 196,099 个样本"，审稿人核对 v3 论文发现是 118,965，被质疑数据来源不实。

实情：官网是实时统计，会随收录增长；论文是定稿快照。

应对：学术引用用论文口径；若必须用最新数字，写明"官网首页，访问日期 YYYY-MM-DD"。最稳妥的做法是下载后自数行数。

坑 3：以为 118,965 个样本都能用

现象：按 118,965 规划样本量，实际可用只有 68,723（约 58%）。

实情：三级漏斗——收录 118,965 → 已处理 108,176 → 可用 68,723。QC 通过率 63.5%（相对已处理样本）。

应对：规划前先下 stats_by_phenotype.txt.gz，看你关心的疾病实际可用多少样本。别用总数。

坑 4：把 664 与 472 相加当作项目总数

现象：“664 个项目有可用数据 + 472 个项目 QC 失败 = 1,136 个项目，可文档说只有 884 个项目，是不是数据错了？”

实情：两个数字不互斥。同一项目里部分 run 通过、部分失败，会在两侧各计一次。

应对：项目计数以"已处理 884"为准；run 计数才有严格配平（68,723 + 39,453 = 108,176）。

坑 5：把 1,683 个物种当成"可靠物种数"

现象：直接用 1,683 个物种做特征，模型被大量低丰度噪声物种拖垮。

实情：1,683 的纳入阈值极宽松（≥2 个样本出现、中位丰度 ≥0.01%），只保证"出现过"，不保证"稳定"。

应对：自行加阈值——例如要求流行率 > 10% 或平均丰度 > 0.1%，再做特征筛选。GMrepo 不做这一步是有意为之（保持最大信息量），需要你按任务补。

坑 6：把相对丰度当绝对量做统计

现象：对物种丰度直接做 t 检验，得到大量"显著"差异，其中相当一部分是组分效应（compositional effect）的假象。

实情：丰度已按样本归一化到 100%。一个物种上升，必然挤压其他物种。

应对：做 CLR 或 ILR 变换后再做差异检验；或用专门的组分数据方法（ANCOM-BC、ALDEx2 等）。GMrepo 不提供变换后矩阵。

坑 7：用 taxon_id 去连 NCBI 表

现象：联表后大量空值，或分类学名称完全对不上。

实情：GMrepo 内部用 taxon_id（内部唯一 ID），NCBI 实体 ID 是 ncbi_taxon_id，两者不同。

应对：连 superkingdom2descendents.txt.gz 时用 ncbi_taxon_id；内部关联用 taxon_id。文档对此有明确提醒。

坑 8：把 1299 个 marker 当成"全部显著菌"

现象：以为库里所有有差异的菌都在这 1299 个里。

实情：1,299 个 marker 只来自 275 个 curated 项目（全库 890 项目的一部分），且只覆盖 167 个表型对。大量项目从未做过 marker 识别。

应对：如果你的疾病不在 167 个表型对里，marker 表里可能一无所有，需要自己从丰度表做差异分析。

坑 9：以为同一项目只属于一个表型

现象：检索某疾病，返回的项目数远多于实际该疾病的项目数。

实情：官网首页明确提示：几乎每个项目都同时包含患者与健康对照，未限定表型时项目会被重复命中。

应对：检索时限定具体表型；或用项目表去重后再统计。

坑 10：把 MCI 当成"这个菌是真的"的证明

现象：挑 MCI 最高的几个菌，直接写进"已证实的生物标志物"。

实情：MCI 衡量的是跨研究一致性，不是因果性，也不是诊断效能。它在 400 个 ≥10 项目的 marker 上只有 57% 落在两端（143 + 85），其余 43% 在灰区。

应对：MCI 高只说明"多个研究同向报告"，仍需独立队列验证诊断性能（AUC、灵敏度、特异度），并考虑混杂因素。

10.1 遗留疑点（本轮未能核实的项）

1. QC 失败原因分布：文档只给阈值，未给"因深度不足失败"与"因单分类单元失败"的数量分拆。
2. 参考库版本：QIIME2 的参考库、MetaPhlAn4 的数据库版本均未披露，严格复现受限。
3. LEfSe 参数：LDA 阈值、α 值、是否多组比较未披露；“Disease marker identification” 专页未抓取（超出本轮网络预算）。
4. 45 国覆盖：仅中文二次报道口径，英文摘要未见，属待核。
5. 个体级样本数：118,965 是 run 数，对应多少个独立个体未披露。
6. MCI 阈值标定依据：75%/25% 为经验阈值，论文摘要未说明是否经置换检验或 FDR 标定。
7. 官网实时数字与论文的映射关系：196,099 runs 是否已全部经过 v3 流程处理，未披露。
8. 库内是否已有 CuratedMetagenomicData 类条目：本轮未做全库同域扫描（超出写手职责范围，建议主会话按 §9.2 的 SQL 复核）。

---

§11 总结

11.1 三句话总结

1. GMrepo v3 是人类肠道宏基因组领域最系统的"整理型"公开数据库之一：890 个项目、118,965 个 run、302 种疾病，用 QIIME2/MetaPhlAn4 统一重注释，元数据人工整理。
2. 它的方法学增量是 MCI：把"某个菌在多少研究里同向变化"压成 0–100% 的分数，让跨研究一致性第一次变成可排序、可筛选的字段；在 400 个高频 marker 中，57% 落在稳定两端，43% 在灰区。
3. 它的最大短板是治理而非技术：license 未声明、无 API、处理流程版本披露不全——这三点直接限制了商业使用与严格复现。

11.2 适合谁

角色	适合理由
疾病-菌群关联研究者	省去最耗时的元数据整理与统一重注释，直接拿可比丰度表
想做生物标志物筛选的团队	MCI 提供了现成的"一致性"先验，可做初筛
微生物组方法学者	MCI 的设计思路可直接迁移到其他组学的一致性评估
ML 工程师构建医疗组学数据集	标签可靠、特征统一、规模大，是少见的"可直接用"的组学表格数据
教学与综述作者	数据可得、结构清晰、三代演进脉络完整，适合作为案例

11.3 不适合谁

角色	不适合理由
需要原始 fastq 的研究者	GMrepo 不发原始数据，须回 SRA 自取
需要绝对菌量（qPCR、定量内标）的研究者	相对丰度已归一化，绝对量信息丢失
需要株级（strain-level）分辨率的研究者	16S 到属、宏基因组默认到种，株级不足
商业产品团队（未经授权）	license 未声明，法务风险高，须先取得书面许可
需要某个特定小病种且样本少量的研究者	302 种疾病中分布极不均，冷门病种样本可能个位数
需要 API 做实时检索的工程团队	无 API，只能下全库 dump 自建

11.4 30 秒决策卡

你是否要研究"肠道菌群与人类疾病"？           否 → 不需要本数据集
        ↓ 是
你的疾病在 GMrepo 的 302 种表型里吗？          否 → 只能从丰度表自做差异分析
        ↓ 是
下 stats_by_phenotype.txt.gz，可用样本 > 100？  否 → 考虑合并更多项目或换资源
        ↓ 是
你需要原始序列吗？                            是 → GMrepo 只给丰度，原始数据去 SRA
        ↓ 否
用丰度表还是全库 dump？                       单病种/单分析 → 丰度表；多表联查/自建 API → dump
        ↓
你是否要做商业使用/再分发？                    是 → 先向作者确认 license（官方未声明）
        ↓ 否
可以开始。引用 v3 论文 DOI: 10.1093/nar/gkaf1190

11.5 版本与引用规范

写论文时推荐的引用方式（示例）：

数据来源：GMrepo v3（Liu C, Wang X, Zhang Z, et al. GMrepo v3: a curated human gut microbiome database with expanded disease coverage and enhanced cross-dataset biomarker analysis. Nucleic Acids Research, 2026, 54(D1): D734–D742. doi:10.1093/nar/gkaf1190），全库数据于 YYYY-MM-DD 从 https://gmrepo.humangut.info/Downloads/SQLDumps/ 下载，共 N 个 run 通过 QC。

这四要素——版本 DOI、下载日期、下载地址、实测数量——能覆盖审稿人对数据来源的绝大多数质询。

---

FAQ（高频问答 20 问）

A. 基础认知

1. GMrepo 和 GMrepo v3 是一回事吗？
GMrepo 是数据库名，v3 是第三代版本。当前官网运行的是 v3 之后的持续更新版本，数字已超过 v3 论文快照。

2. 它和 QIIME2 是什么关系？
QIIME2 是 GMrepo 处理 16S 数据用的工具，不是同一层级的东西。GMrepo 用 QIIME2 跑注释，输出 ASV 与丰度表。

3. 它和 MetaPhlAn 是什么关系？
MetaPhlAn4 是 GMrepo 处理宏基因组数据用的物种定量工具（默认参数）。MetaPhlAn 是工具，GMrepo 是数据库。

4. 它是中国团队做的吗？
是。华中科技大学生命科学与技术学院陈卫华课题组主导，v3 与济宁医学院合作。

5. 为什么样本数从 v1 的 5.9 万涨到 v3 的 11.9 万？
主要是持续收录新发表的公开项目 + 对已有项目的补充。v3 的 16S 占比（73%）高于 v2（63%），说明增量主要来自扩增子项目。

B. 数据与获取

6. 下载需要申请吗？
不需要。免注册、免申请，直接 HTTP 下载静态文件。

7. 全库有多大？
官方未给出总大小。单个丰度表解压后可能达 GB 级；gmrepo.sql.gz 是全库转储，下载前建议先看 Content-Length。本条不提供未核实的具体体积数字。

8. 有 API 吗？
没有 REST API。只有静态文件与网页查询构建器。

9. 原始数据在哪？
在 NCBI SRA / ENA。GMrepo 只给 run accession，点击 linkout 跳转，或用 SRA Toolkit 的 prefetch / fastq-dump 自取。

10. 数据多久更新一次？
官方未公布更新周期。从论文（2025-11）到官网（2026-10）增长 65% 来看，处于持续追加状态，但无固定节奏。

C. 数据使用

11. 丰度是绝对量还是相对量？
相对量，且已按样本归一化到 100%。不能比较绝对菌量。

12. 为什么我的分析里很多物种丰度是 0？
物种纳入阈值很宽松（≥2 样本、中位丰度 ≥0.01%），大量低丰度物种在多数样本中就是 0。零值既可能是真没有，也可能是没测到。

13. 可以直接做 t 检验吗？
不建议。相对丰度是组分数据，直接检验会引入假阳性。应先做 CLR/ILR 变换，或用 ANCOM-BC、ALDEx2 等专用方法。

14. taxon_id 和 ncbi_taxon_id 有什么区别？
前者是 GMrepo 内部唯一 ID，后者是 NCBI 分类体系中的实体 ID。联表时必须用对。

15. 一个 run 是一个病人吗？
不一定。run 是一次测序，同一人多次采样会有多个 run。个体级分析需先按元数据去重。

D. Marker 与 MCI

16. 1299 个 marker 覆盖所有项目吗？
不。只来自 275 个 curated 项目、覆盖 167 个表型对。全库 890 项目中其余项目未做 marker 识别。

17. MCI 高就说明这个菌是真信号吗？
不。MCI 衡量跨研究一致性，不衡量因果或诊断效能。仍需独立队列验证。

18. 为什么 MCI 的灰区占比这么高（43%）？
因为微生物组研究的异质性本来就大：人群、饮食、用药、方法学差异都会让 marker 方向翻转。灰区高是诚实的反映，不是方法失败。

19. 我能不能自己算 MCI？
可以。定义是"出现频率 × 方向一致性"的合成，但具体公式细节需查论文方法节（本轮未核到完整公式）。建议直接调用库里现成的 MCI 值。

20. marker 分析用的是什么差异检验？
中文二次报道口径为 LEfSe；具体参数（LDA 阈值、α 值）文档未披露，属遗留疑点。

---

事实清单（硬事实 26 条）

#	事实	来源
1	v3 论文：Nucleic Acids Res 2026;54(D1):D734–D742	OUP/Scilit 元数据
2	DOI：10.1093/nar/gkaf1190	OUP / CNGBdb
3	PMID：41277537	PubMed / CNGBdb
4	v3 在线首发：2025-11-24	OUP
5	v3 规模：890 项目 / 118,965 runs	论文摘要
6	v3 构成：16S 87,048 + 宏基因组 31,917	论文摘要
7	v3 疾病表型：302（v2 为 133）	论文摘要
8	marker taxa：1,299（726 种 + 573 属）	论文摘要
9	表型对：167；来源项目：275	论文摘要
10	≥10 项目的 marker：400 个	论文摘要
11	MCI > 75% 的健康富集 marker：143 个	论文摘要
12	MCI < 25% 的疾病富集 marker：85 个	论文摘要
13	维护机构：华中科技大学（HUST）陈卫华课题组	论文作者单位 / 站点版权
14	官方站点：https://gmrepo.humangut.info	论文摘要
15	已处理 run：108,176（884 项目）	文档站 overview
16	可用丰度 run：68,723（664 项目）	文档站 overview
17	QC 失败 run：39,453（472 项目）	文档站 overview
18	可用样本中物种 1,683 / 属 1,515	文档站 overview
19	物种纳入阈值：≥2 样本且中位丰度 ≥0.01%	文档站 overview
20	QC 阈值 1：16S clean reads < 20,000 判失败	文档站
21	QC 阈值 2：单分类单元 > 99.99% 判失败	文档站
22	16S 流程：QIIME2 + ASV；宏基因组：MetaPhlAn4 默认参数	文档站
23	上游工具：FastQC 0.11.8 / Trimmomatic / Seqtk	文档站
24	共现三条件：Fisher(p<0.05) + Pearson(p<0.05) + Spearman(p<0.05)，存在阈值 0.01%	文档站
25	下载目录：/Downloads/SQLDumps/，11 个 txt.gz + 1 个 sql.gz	文档站
26	官网首页实时：196,099 runs / 1,172 项目 / 351 表型 / 1,864 markers	官网首页 2026-10-17

---

术语表（28 条）

术语	英文	释义
宏基因组	metagenome	环境样本中全部微生物遗传物质的总和
宏基因组测序	shotgun metagenomics	对样本全部 DNA 直接测序，可到种/株级
16S rRNA 扩增子	16S rRNA amplicon	只测 16S 基因特定区段，成本低，多数到属级
ASV	Amplicon Sequence Variant	扩增子序列变体，逐条序列去噪后的精确序列单元
OTU	Operational Taxonomic Unit	按相似度阈值聚类的操作分类单元，ASV 的前身
相对丰度	relative abundance	某分类单元在样本中的占比，通常归一化至 100%
流行率	prevalence	某分类单元在样本集合中出现的比例
共现	co-occurrence	两个分类单元在样本中非随机地同时出现
表型	phenotype	样本供体的健康状态或疾病类别
表型对	phenotype pair	用于比较的两组表型，如健康 vs 结直肠癌
marker taxon	marker taxon	在表型对之间丰度显著差异的分类单元
MCI	Marker Consistency Index	标记物一致性指数，综合出现频率与方向一致性
元数据整理	metadata curation	从文献与公共库中人工提取并核实样本宿主信息
重注释	re-annotation	用统一工具与参考库重新处理原始数据
组分数据	compositional data	各部分之和恒定的数据（如归一化丰度）
CLR	Centered Log-Ratio	中心对数比变换，处理组分数据的常用方法
ILR	Isogonal Log-Ratio	等距对数比变换，组分数据另一种变换
LEfSe	Linear Discriminant Analysis Effect Size	差异丰度分析工具，输出 LDA 效应量
MetaPhlAn	MetaPhlAn	基于标记基因的宏基因组物种定量工具
QIIME2	QIIME 2	微生物组扩增子分析流程框架
批次效应	batch effect	因处理批次不同引入的非生物学差异
组成性偏倚	compositional bias	组分数据中某部分变化引起的其他部分表观变化
假阳性	false positive	实际无差异却被判为有差异
FDR	False Discovery Rate	错误发现率，多重检验校正指标
本库软删	soft delete	记录保留但 del_sign=1，统计时须排除
在架	on-shelf	本库中 status=1 AND del_sign=0 的条目
AI-Ready	AI-Ready	结构规范、许可清晰、可直接用于模型训练的数据就绪状态
数据治理	data governance	围绕许可、版本、质量与可追溯性的管理规范

---

---

---

§12 案例解剖：三个典型使用场景的完整推演

本节用三个虚构但符合真实数据约束的场景，把前文的规则串成可执行的动作序列。所有场景中的样本量、阈值均为示例，实际以你下载的数据为准。

12.1 场景一：结直肠癌菌群特征筛选（小样本起步）

背景：一位临床研究者想验证"某几个菌能否区分 CRC 患者与健康对照"，手头没有算力跑原始数据，希望直接用 GMrepo 的丰度表。

第一周：先看规模，别急着下载

动作 1：下载 stats_by_phenotype.txt.gz（几百 KB）
动作 2：筛选 phenotype 含 "Colorectal" 的行
动作 3：读三列——run 总数、有效 run 数、失败 run 数
判断：
  - 若有效 run < 100 → 样本不足，考虑合并相邻表型或换资源
  - 若失败比例 > 50% → 该项目群整体测序质量差，慎用

这一步的价值在于用几百 KB 的成本否决掉后续几个 GB 的下载。很多人跳过这一步，直接下丰度表，最后发现目标疾病只有几十个样本。

第二周：确认元数据可用性

动作 4：下载 sample_to_run_info.txt.gz
动作 5：取目标表型 + 健康对照的子集
动作 6：逐列统计缺失率（age / gender / BMI / country / antibiotics）
判断：
  - country 缺失 < 10% → 可做国别分层或作为协变量
  - age 缺失 > 50% → 放弃年龄校正，改在局限中声明
  - BMI 缺失 > 70% → 基本不可用（这在微生物组数据里很常见）
  - antibiotics 缺失 > 90% → 只能当"未记录"处理，不能当"未使用"

最后一条最容易出错："未记录"与"未使用"是完全不同的语义。若把缺失当"未使用"，会把大量未知样本归入干净组，系统性稀释抗生素效应。

第三周：构建特征矩阵并处理组分性

动作 7：下载 species_abundance.txt.gz，取子集样本 × 物种
动作 8：过滤——保留流行率 > 10% 的物种（自行加严阈值）
动作 9：零值处理——加伪计数（如 1e-6）后做 CLR 变换
动作 10：可选——用 MCI 对物种排序，作为特征重要性的先验

第 9 步是分水岭。不做变换直接跑 t 检验，你会得到上百个"显著"物种，其中大量是组分效应的产物——某个高丰度物种变化，会机械地推高所有其他物种的相对比例。做完 CLR 后显著物种数通常会大幅收缩，这才是可信的信号。

第四周：划分与评估

动作 11：按 project_accession 划分 train/test（严禁按样本随机）
动作 12：训练基线模型（逻辑回归 / 随机森林）
动作 13：同时报告两个指标：
         - 同项目内交叉验证 AUC（乐观，仅作参考）
         - 跨项目 holdout AUC（真实，作为主结论）
动作 14：与 GMrepo 的 marker 表对照，看模型选出的特征有多少落在 1299 个 marker 里

第 13 步的两个数字通常会差很多。同项目交叉验证 AUC 0.9、跨项目 AUC 0.6 是微生物组领域的常态。只报前者是自欺，只报后者会被质疑方法不行——两个都报，并解释差距来源（批次效应 + 人群差异），才是诚实写法。

这个场景的三个关键判断点

判断点	错误做法	正确做法
样本量	用 118,965 规划	用 stats_by_phenotype 的实际可用数
缺失值	把 NaN 当"无"	区分"未记录"与"未使用"，缺失率高就放弃该协变量
评估	只报同项目 CV	同项目 CV + 跨项目 holdout 双报

12.2 场景二：MCI 作为方法学模板的迁移

背景：一位影像组学研究者读到 GMrepo v3 的 MCI，想把这个思路用到自己的"某影像特征在多少中心的研究中被报为有效"的问题上。

第一步：拆解 MCI 的两个输入

MCI 的输入不是原始数据，而是每条"发现"的方向与所属研究。迁移到影像组学时，对应关系是：

GMrepo 中的概念	影像组学中的对应物
marker taxon	某个影像组学特征（如某纹理参数）
project	某个独立研究 / 中心 / 队列
phenotype pair	某疾病 vs 对照
方向（富集/减少）	特征值在病例组升高/降低
出现频率	多少个研究报告该特征显著
方向一致性	其中多少个方向相同
MCI	合成的一致性分数

第二步：明确 MCI 不解决什么

迁移时必须放弃三个幻想：

1. 它不校正研究质量。20 个研究一致，若都来自同一团队同一设备，一致性没有普适意义。GMrepo 也没解决这个问题。
2. 它不校正发表偏倚。阴性结果不进库，MCI 天然偏高。
3. 它不告诉你因果。一致性是关联的属性，不是机制的证明。

第三步：设计自己的版本

一个可落地的迁移方案：

输入：N 个独立研究，每个研究报告一组显著特征及方向
计算：
  for 每个特征 f:
      k = 报告 f 显著的研究数
      n = 总研究数
      p_same = 方向相同的研究数 / k
      consistency = p_same                     # 方向一致性
      prevalence  = k / n                      # 出现频率
      score = consistency × f(prevalence)      # 合成（f 可取 sqrt、log 等）
输出：按 score 排序的特征表 + 灰区标注

关键设计选择在于 f(prevalence) 的形式：GMrepo 的具体合成公式本轮未核到（见遗留疑点），但无论取什么形式，必须让"只在一个研究里出现"的特征无法得到高分——否则会把孤例误判为稳健信号。

第四步：验证 MCI 类指标真的有预测力

这是最有价值的一步，也是最容易被跳过的：用留出研究验证"MCI 高的特征，在未参与计算的新研究里是否更可能复现"。

留一研究法（leave-one-study-out）：
  for 每个研究 s:
      用其余研究计算每个特征的 score
      检查 s 中该特征是否显著且方向一致
  汇总：score 高分组的复现率 vs 低分组
如果两者无差异 → 该一致性指标没有预测力，只是描述统计

GMrepo v3 论文证明了 MCI 与方向一致性相关（这是定义使然，近乎同义反复），但没有证明它能预测新研究中的表现。这是一个明确的开放问题，也是迁移者最该做的验证。

12.3 场景三：作为 LLM/多模态 agent 的知识底座

背景：一个做医学问答或科研助手的团队，想把 GMrepo 作为"肠道菌群-疾病"事实的结构化来源。

为什么适合

• 表型名对齐 MeSH，可与其他医学词表打通；
• marker 表给出"菌—病—方向—一致性"四元组，天然适合构建知识图谱的边；
• 数据可离线全量下载，不依赖在线 API，适合做检索增强的本地索引。

构建流程

步骤 1  下 gmrepo.sql.gz，导入本地数据库
步骤 2  建三张核心表：
        t_taxon(ncbi_taxon_id, name, rank)
        t_phenotype(mesh_id, name)
        t_marker(ncbi_taxon_id, mesh_id, direction, n_projects, mci)
步骤 3  为每条边生成自然语言陈述：
        "Faecalibacterium prausnitzii 在健康对照中一致富集（MCI > 75%）"
步骤 4  向量化 + 建索引，供 RAG 检索
步骤 5  在答案中强制附带三要素：样本来源数、MCI 值、一致性等级

必须设的三道安全阀

1. 禁止把 MCI 翻译成"证实"。生成文本必须写"多项研究报告一致"，不能写"已证实"。
2. 灰区必须显式披露。若用户问到一个 MCI 在 25%–75% 的菌，答案必须提示"证据方向不一致"。
3. 禁止跨病种外推。某菌在 CRC 中一致性高，不代表在 IBD 中也高——marker 表是按表型对组织的，不能按菌聚合后跨病种传播。

第 3 条是最容易被忽略的。一个常见的错误生成是：“A 菌是 CRC 的稳健 marker，因此 A 菌也与 IBD 相关。” 这在数据上完全无依据，因为 IBD 的表型对可能根本没算过 A 菌，或算了但方向相反。

这个场景的价值与风险对照

价值	风险
四元组结构清晰，易构图谱	MCI 易被误读为"证实"
表型对齐 MeSH，跨库可连	表型对粒度被忽略，跨病种外推
离线可部署，无 API 依赖	license 未声明，商用需授权
数据量大，覆盖 302 疾病	各病种样本量极不均，冷门病结论薄弱

---

§13 分角色阅读路径

本条目信息密度较高，不同读者不必通读。以下按角色给出最短路径。

13.1 临床/流行病学研究者（关心"这个菌到底靠不靠谱"）

顺序	章节	要拿走的结论
1	§0.1–§0.2	它解决什么、不是什么
2	§4.2–§4.4	MCI 怎么读、四个示例 marker
3	§10 坑 10	MCI 高 ≠ 已证实
4	§12.1	从样本量到建模的完整流程

预计耗时：20 分钟。最关键的一句：MCI 衡量的是跨研究一致性，不是诊断效能，临床落地仍需前瞻验证。

13.2 机器学习工程师（关心"能不能直接拿来训模型"）

顺序	章节	要拿走的结论
1	§1 十问十答	快速建立全局
2	§2.1–§2.3	可用样本 68,723，特征 1,683 种
3	§10 坑 3/5/6/7	四个必踩的坑
4	附录 E/F	划分与流程骨架

预计耗时：30 分钟。最关键的一句：按项目划分 train/test，否则指标全部虚高。

13.3 数据工程/平台团队（关心"怎么接进自己的系统"）

顺序	章节	要拿走的结论
1	§6.1–§6.5	静态文件、无 API、license 未声明
2	§2.7	11 个文件的清单与用途
3	§6.2 + 附录 D	该下哪个文件
4	§6.6	五个获取坑

预计耗时：15 分钟。最关键的一句：全库 dump 是唯一能支撑复杂联表的方式，但要先看体积。

13.4 方法学者/综述作者（关心"这篇论文的方法学贡献"）

顺序	章节	要拿走的结论
1	§4 全节	MCI 的定义、统计结果、边界
2	§5 全节	三口径对账，引用规范
3	§8 全节	三条可迁移经验 + 三条短板
4	§12.2	MCI 迁移到其他组学的具体做法

预计耗时：40 分钟。最关键的一句：MCI 把"一致性"从定性描述变成可排序字段，这一步的设计价值大于任何单个发现。

13.5 合规/法务（关心"能不能用"）

顺序	章节	要拿走的结论
1	§6.4	license 未声明的事实与三处核验
2	附录 B	许可清晰度评分 2/10
3	§10 坑 1	商业使用的前置动作

预计耗时：10 分钟。最关键的一句：免费下载 ≠ 授权使用，商业场景必须先取得作者书面许可。

13.6 快速通道：只看三行

若只有一分钟，读这三行：

1. 规模：890 项目、118,965 run、302 种疾病、1299 marker taxa（论文口径；官网实时已增至 196,099 run）。
2. 增量：MCI 把"某菌在多少研究里同向变化"压成 0–100% 分数，400 个高频 marker 中 57% 落在两端、43% 在灰区。
3. 风险：官方未声明 license、无 REST API、工具版本披露不全。

---

§14 常见误解澄清：十二条

误解往往比信息本身更有杀伤力。以下十二条是围绕 GMrepo 最容易形成的错误认知，逐条纠正。

误解 1：GMrepo 是一个新的测序项目

纠正：它是一个汇集与再处理平台。库里没有一个样本是 GMrepo 团队自己采的，全部来自公开数据库的已发表项目。它的贡献在于整理、统一注释与派生分析。

为什么会产生这个误解：论文标题里的 “curated database” 容易被理解为"我们建了一个数据库"，而"建"既可以是采集，也可以是汇集。

误解 2：v3 是"第三个独立数据集"

纠正：v3 是同一数据库的第三代快照，与 v2 是包含关系（大体上，不保证逐条样本都保留）。v2 的 71,642 个 run 基本都在 v3 里。做纵向分析时要注意，跨版本比较不等于跨队列比较。

误解 3：数据下载就是原始测序数据

纠正：完全不提供原始 fastq。下载到的是丰度表、元数据表、共现表、分类表。原始数据必须去 SRA 或 ENA 按 run accession 自取。

误解 4：样本数就是病人数

纠正：118,965 是 run 数（测序次数），不是个体数。同一人多次采样（如 IBD 患者的随访队列）会产生多个 run。个体级分析必须先按元数据去重，而元数据里是否有稳定的个体标识，需自行核对。

误解 5：302 种疾病就是 302 个表型

纠正：论文说"注释的疾病数从 133 增至 302"，官网说"351 个表型"。两者的差异在于后者把健康对照与部分非疾病状态也计入表型。引用时写"302 种疾病"更严谨。

误解 6：marker 就是生物标志物

纠正：marker 是"在某表型对之间丰度显著差异的分类单元"，是一个统计概念。生物标志物需要满足诊断性能（灵敏度、特异度、AUC）、可重复性、临床可及性等多重条件。GMrepo 的 1299 个 marker 中，大多数没有经过诊断性能评估。

误解 7：MCI 高就等于结论可靠

纠正：MCI 高只说明多个研究报告了同向变化。如果这些研究共享同一人群、同一饮食结构、同一方法学偏倚，一致性再高也不能推广。MCI 是关联的一致性，不是因果的确定性。

误解 8：有了 MCI 就不需要 meta 分析

纠正：MCI 是粗粒度的批量筛查，不能替代严格 meta 分析。meta 分析需要效应量（如标准化均值差）、置信区间、异质性检验（I²）、发表偏倚评估（漏斗图），这些 MCI 都不提供。正确用法是"先看 MCI 筛候选，再做 meta 分析定量"。

误解 9：相对丰度相加可以比较总量

纠正：每个样本的相对丰度都归一化到 100%，相加恒等于 100。不同样本的"总丰度"在归一化时已丢失。要研究绝对菌量，需要 qPCR、流式细胞术或加内标。

误解 10：16S 和宏基因组可以直接混在一起分析

纠正：两者的分辨率不同（16S 多到属、宏基因组可到种），特征空间不对齐。混合使用必须先把 16S 的 ASV 注释到属级，再与宏基因组的属级丰度合并，且要意识到两者对同一属的定量系统性偏差不同。

误解 11：库里有 890 个项目，所以每个疾病都有很多项目

纠正：分布极不均。常见病（CRC、IBD、糖尿病）可能几十个项目，冷门病可能只有一两个项目、几十个样本。先查 stats_by_phenotype.txt.gz，不要按平均数规划。

误解 12：数据库一直在更新，所以随时下载都是最新最全

纠正：更新不等于"每次下载都完整"。官网首页的实时数字是统计值，不代表每个表都已刷新到该规模；不同表的更新可能不同步。以自己的实测行数为准，并在方法中写明下载日期。

14.1 误解的共性来源

十二条里有九条源自同一个原因：把"数据量大"误当成"数据可靠"。规模是可见的，质量是隐藏的；MCI、QC 通过率、缺失率这些"质量信号"都埋在文档深处，需要主动去查。

这与影像数据集的经验一致：一个 10 万张的公开数据集，如果标注来自单一来源且未经抽检，其价值可能不及一个 5000 张的多中心精标集。GMrepo 在这一点上做得比多数资源好（它公开了 QC 通过率与 MCI），但仍需使用者主动解读。

14.2 三条自检问句

在把 GMrepo 写进论文之前，问自己三句：

1. 我引用的数字是哪个口径？（论文 / 文档站 / 官网实时）
2. 我的疾病有多少实际可用的样本？（不是全库总数）
3. 我的结论依赖的是关联还是因果？（若写"导致"，需要另找证据）

三句都答得出来，基本可以避免最常见的方法学硬伤。

附录

附录 A：条目信息速查卡

项	内容
slug	gmrepo-v3
官方名	GMrepo v3（Gut Microbiome Data Repository 第三代）
主页	https://gmrepo.humangut.info
下载	https://gmrepo.humangut.info/Downloads/SQLDumps/
文档	https://2909682517.github.io/gmrepodocumentation
论文	Nucleic Acids Res 2026;54(D1):D734–D742
DOI	10.1093/nar/gkaf1190
PMID	41277537
维护方	华中科技大学 陈卫华课题组
许可	未声明（仅版权声明）
获取摩擦	极低（免注册直下）
复现摩擦	中（工具版本披露不全）
主要用途	疾病-菌群关联、marker 筛选、组学 ML 数据源
主要风险	license 未声明、无 API、三口径数字易混用

附录 B：DAIMS 评估全表

维度	评分（1-10）	依据
D 可发现性	8	三代论文连续发表于 NAR 数据库专刊，DOI/PMID 齐全，官网长期在线；扣分在于首页无版本号标签，初次访问难以判断是第几代
A 可获取性	8	免注册、免申请、静态文件直下，11 个 TSV + 全库 dump；扣分在于无 REST API，大规模程序化检索需自建索引
I 可互操作	7	TSV 通用格式 + MeSH 映射 + NCBI 分类 ID，可与主流工具对接；扣分在于 taxon_id 与 ncbi_taxon_id 双 ID 体系易混淆，无 BIOM 等标准组学格式导出
M 元数据质量	7	人工整理、有准入判断（如 AGP 只采信医疗专业人员诊断）；扣分在于年龄/性别/BMI/抗生素使用等字段缺失普遍，完整率未系统公布
S 可持续性	7	2026-10 官网数字较论文增长 65%，显示活跃维护；扣分在于无固定更新周期公告、文档站引用文案与版权年份停留在旧版
R 可复现性	6	QC 阈值与共现规则明确，FastQC 有版本号；扣分在于 QIIME2/MetaPhlAn4 数据库版本、Trimmomatic/Seqtk 版本、LEfSe 参数均未披露，无法严格复现
L 许可清晰度	2	官方全站无 license 文本，仅有版权声明；商业使用与再分发法律状态不明——本表最低分项
综合评级	6.4/10（中上）	作为数据资源本身质量高、获取摩擦极低；被许可缺失与流程版本披露不全拖低，尤其许可一项是硬伤

附录 C：逐项证据链自证

关键数字	来源	位置
890 项目 / 118,965 runs	v3 论文摘要	OUP / PubMed / CNGBdb 三处一致
16S 87,048 + 宏基因组 31,917	v3 论文摘要	同上
302 种疾病	v3 论文摘要	同上
1,299 marker taxa（726 种 + 573 属）	v3 论文摘要	同上
167 表型对 / 275 curated 项目	v3 论文摘要	同上
400 marker / 143 健康富集 / 85 疾病富集	v3 论文摘要	同上
108,176 / 68,723 / 39,453	文档站 Database overview	抓取 2026-10-17
1,683 种 / 1,515 属	文档站 Database overview	同上
20,000 reads / 99.99%	文档站 Data processing & QC	同上
QIIME2 + ASV / MetaPhlAn4 默认参数	文档站 Data processing & QC	同上
FastQC 0.11.8	文档站 Data processing & QC	同上
共现三条件与 0.01% 阈值	文档站 Data processing & QC	同上
11 个 txt.gz + gmrepo.sql.gz	文档站 Download data from GMrepo	同上
无 REST API	文档站 Download data from GMrepo	同上
196,099 / 1,172 / 351 / 1,864 / 335 / 186	官网首页	抓取 2026-10-17
v1：58,903 / 253 / 92	v1 论文摘要（PMID 31504765）	PubMed
v2：71,642 / 353 / 133；592 marker / 47 表型对 / 83 项目	v2 论文（PMC8728112）	PMC 全文

附录 D：数据获取决策树（详版）

开始
 │
 ├─ 目标：只想知道某疾病的样本规模
 │    └─ 下 stats_by_phenotype.txt.gz（最小，几百行）
 │
 ├─ 目标：做疾病分类建模
 │    ├─ 1. sample_to_run_info.txt.gz  → 取 phenotype + 元数据
 │    ├─ 2. species_abundance.txt.gz   → 取特征矩阵
 │    ├─ 3. 交集样本 → 训练/测试划分（按项目划，避免同项目泄漏）
 │    └─ 4. 注意：QC 失败样本不在丰度表内，不必当负例处理
 │
 ├─ 目标：做 marker 复现性研究
 │    ├─ 1. 论文方法节 + marker 表
 │    ├─ 2. 用丰度表自算差异（与原 marker 对照）
 │    └─ 3. 用 MCI 做一致性分层
 │
 ├─ 目标：做共现网络
 │    └─ species_cooccurence.txt.gz（已算好三条件共现）
 │
 ├─ 目标：自建查询服务
 │    └─ gmrepo.sql.gz → 本地 MySQL → 包一层 REST
 │
 └─ 目标：复现 GMrepo 的处理流程
      └─ 需要原始 fastq（SRA）+ 工具版本（部分未披露）→ 无法完全复现

附录 E：可分片训练/测试的划分建议

GMrepo 不做官方 train/test 划分，自建划分时有三条原则：

原则	做法	原因
按项目划分，不按样本	整个项目归入 train 或 test	同项目样本共享实验条件，随机会导致批次泄漏、指标虚高
按人群/国别分层	尽量让 train 与 test 人群不同	检验跨人群泛化，这才是真实部署场景
保留时间外推集	若有项目年份，留一批较新项目做 test	检验模型对"新研究"的稳健性

最小示例骨架：

import pandas as pd

meta = pd.read_csv('sample_to_run_info.txt.gz', sep='\t', low_memory=False)
abund = pd.read_csv('species_abundance.txt.gz', sep='\t', index_col=0)

# 只保留有用样本（丰度表内即有 QC 通过的样本）
common = meta['run_accession'].isin(abund.index)
meta = meta[common]

# 按项目划分，避免批次泄漏
projects = meta['project_accession'].unique()
test_projects = set(pd.Series(projects).sample(frac=0.2, random_state=42))
is_test = meta['project_accession'].isin(test_projects)

X_train = abund.loc[meta.loc[~is_test, 'run_accession']]
X_test  = abund.loc[meta.loc[ is_test, 'run_accession']]
y_train = meta.loc[~is_test, 'phenotype']
y_test  = meta.loc[ is_test, 'phenotype']

（字段名以实际下载文件表头为准；上文为结构示意，具体列名需打开文件确认。）

附录 F：常见分析流程模板

步骤 1  数据加载
        - 读 sample_to_run_info.txt.gz 与 species_abundance.txt.gz
        - 按 run_accession 取交集，确认样本数

步骤 2  子集筛选
        - 限定目标疾病 + 健康对照
        - 统计每组的项目数与样本数（项目数太少要警惕）

步骤 3  组成性处理
        - 零值处理（伪计数或零膨胀模型）
        - CLR / ILR 变换

步骤 4  特征筛选
        - 流行率阈值（如 >10%）
        - 可选：用 MCI 作先验排序

步骤 5  建模
        - 按项目划分 train/test
        - 报告 AUC 同时报告跨项目与跨人群表现

步骤 6  解释与验证
        - 对照 GMrepo marker 表，看命中率
        - 报告灰区 marker 的处理方式

附录 G：条目写作说明

• 本条目所有规模数字均标注口径（论文 / 文档站 / 官网实时），未做四舍五入合并。
• 未核实项统一列入 §10.1 遗留疑点，不在正文以确定语气陈述。
• license 按"官方未声明"处理，不做任何 CC/ODbL 推定。
• 互链 rid 一律不写具体值，由主会话入库后回填，避免导航目标不在架。

---

相关数据集导航

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

• american-gut-project — 共享标签：基因组学与多组学 / 微生物组 / 测序数据 / 队列研究
• china-map — 共享标签：基因组学与多组学 / 测序数据 / 队列研究 / 公共卫生与流行病学
• ckm-gut-metagenome — 共享标签：基因组学与多组学 / 微生物组 / 测序数据 / 队列研究
• hmp — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
• ckb — 共享标签：基因组学与多组学 / 队列研究 / 公共卫生与流行病学
• ega — 共享标签：基因组学与多组学 / 测序数据 / 队列研究
• mgnify — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
• curatedmetagenomicdata — 共享标签：基因组学与多组学 / 微生物组 / 测序数据
• all-of-us — 共享标签：基因组学与多组学 / 队列研究 / 公共卫生与流行病学
• sra — 共享标签：基因组学与多组学 / 测序数据 / 公共卫生与流行病学

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