信息速览
细胞生物学里有一类结构，没有膜，却能在一锅均匀的细胞质里维持自己的边界：应激颗粒、核仁、P 小体、生殖颗粒。它们靠蛋白质与核酸的多价弱相互作用聚成液滴，几秒内成形，几十秒内散开。过去二十年，这类被称为生物分子凝聚体的结构从边缘概念变成主线，论文数量陡增，名词却始终没有统一——同一个颗粒在不同实验室有不同叫法，同一个蛋白在不同物种里被反复报告。
CD-CODE 就是为收拾这个局面而建的。它把散落在文献里的“哪个蛋白属于哪个凝聚体、证据是什么、在哪个物种里看到”抽成结构化记录，用 UniProt 对齐蛋白、用 Disease Ontology 对齐疾病、用 PubChem 与 ChEMBL 对齐化合物，再让社区像编辑百科一样补充与修订。项目由德累斯顿的马克斯·普朗克分子细胞生物学与遗传学研究所与系统生物学中心维护，2023 年首版，2026 年 10 月已到 2.4 版。
它不是一个能直接喂进模型的大表，而是一份带出处的证据集合：815 个凝聚体、一万一千五百余个蛋白、一万五千余条关系、409 个调节化合物、133 条凝聚体病。用得好，它是知识图谱的骨架与弱监督的种子；用不好，它会把“没人研究过”误读成“不存在”。一屏速览见下表。
| 维度 | 内容 |
|---|---|
| 全名 | CD-CODE: CrowDsourcing COndensate Database and Encyclopedia |
| 中文名 | 生物分子凝聚体众包数据库与百科 |
| 维护机构 | MPI-CBG 与 CSBD（德国德累斯顿） |
| 通讯作者 | Agnes Toth-Petroczy（MPI-CBG / CSBD） |
| 首次发布 | 2023 年 1 月（数据 1.01 版），网站 2023 年 4 月上线 |
| 当前数据版本 | 2.4 版，2026 年 10 月 20 日发布 |
| 凝聚体数 | 815 个（2.4 版） |
| 蛋白数 | 11,502 个（2.4 版） |
| 关系数 | 15,091 条凝聚体—蛋白关系（2.4 版） |
| 调节化合物 | 409 个 c-mod（2.4 版） |
| 凝聚体病 | 133 条（2.4 版） |
| 实体类型 | 凝聚体、蛋白、化合物、疾病关联四类，另有核酸组分标注 |
| 主键体系 | 凝聚体 8 位十六进制编号；蛋白 UniProt 编号；疾病 DOID |
| 取数方式 | 网页浏览、版本数据包、REST API（v1 公开，v2 需令牌） |
| 许可 | CC BY-NC 4.0（非商业） |
| 更新节奏 | 约每季度一个数据版本 |
§1 它要解决的具体麻烦
1.1 同一句话，五种写法
假设你想知道“G3BP1 是不是应激颗粒的组分”。查文献，你会看到至少五种表述：它是应激颗粒的标记蛋白；它在 arsenite 处理后与 G3BP2 共定位；它是应激颗粒组装的核心驱动者；它在体外能自组装成液滴；它在某种癌细胞里异常聚集。这五句话在实验层面是五件不同的事，在数据库里却常常被压成同一个布尔值——属于，或不属于。
压缩的代价在跨研究比较时暴露。A 组用质谱从纯化的颗粒里鉴定出这个蛋白，B 组只做了共定位显微，C 组做了体外相分离。三篇文章都说“是”，但证据强度差了两个量级。若数据库只存“是”，下游任何按关系计数的分析都会把三者等同，热门蛋白被反复确认，冷门蛋白只有一条弱证据，最后得到的网络看起来是生物学，其实是研究资源的分布图。
CD-CODE 的第一层设计就是拒绝这种压缩：每条关系都带证据类型与星级，你能看出这条边是“质谱看到的”还是“活细胞里看到的”。第二层设计是给名词立规矩：凝聚体名称标准化，同一结构的不同别名归并，物种单独成列，感染性凝聚体把宿主与病原分开记。第三层是让缺口语义化——官方在关于页明确写了，缺失有三种可能，不提供预测。
1.2 三条常见的错误期待
第一条，期待它是“凝聚体版的 UniProt”。UniProt 追求的是蛋白序列与功能的穷举式覆盖，一个物种的蛋白组可以被完整注释。CD-CODE 追求的是文献覆盖，只收被研究过、被报告过的关系。人类蛋白组约两万条，这里只有四千余条人类蛋白出现在至少一个凝聚体中，剩下的不是“不在凝聚体里”，而是“还没人报告”。
第二条，期待它给出“负例”。这是做机器学习的人最容易踩的坑。库里没有一行写着“该蛋白不属于该凝聚体”。要把关系表变成分类数据集，必须自己造负例，而造法直接决定结论：随机抽蛋白当负例，模型会学到表达量与研究热度；抽同家族蛋白当负例，模型会学到序列相似度；只有抽经过实验否证的对象，才是真负例，而这类记录在库里几乎不存在。
第三条，期待它覆盖临床。它有 133 条凝聚体病记录，看上去像疾病数据库，但每条只是一个“凝聚体异常—疾病”的关联摘要，来自细胞或动物模型，没有患者数、没有分期、没有结局。把它当临床队列或药物疗效证据用，会立刻越界（§7.3）。
1.3 它能给到的与给不到的
| 你的需求 | 它给的 | 够不够 |
|---|---|---|
| 某蛋白是否被报告为某凝聚体组分 | 关系记录 + 证据类型 + PubMed 编号 | 够，且能区分强弱证据 |
| 某凝聚体有哪些已知组分 | 组分清单，按物种过滤 | 够，热门的应激颗粒、核仁覆盖较全 |
| 跨物种比较同一凝聚体 | 物种列与分类号，感染性记录另列病原 | 可做，但各物种研究深度极不均衡 |
| 凝聚体相关药物的候选清单 | 409 个 c-mod，含作用类别与审批状态 | 够做假设生成，不够做疗效结论 |
| 疾病与凝聚体异常的对应 | 133 条记录，映射 DOID | 够做线索，不够做流行病学 |
| 蛋白—凝聚体二分类的完整标签 | 只有正例，没有确认的负例 | 不够，须自建负例方案 |
| 蛋白结构或序列特征 | 仅给 UniProt 编号，需外连 | 不够，库内不含序列与结构 |
| 表达量、定位、互作网络 | 仅给外链入口（HPA、STRING 类） | 不够，需跨库拼接 |
| 临床表型与患者数据 | 无 | 完全不够 |
1.4 你的处境与它能帮到的事
| 你的处境 | 它能帮你什么 | 下一步该做什么 |
|---|---|---|
| 你在做蛋白功能注释模型，缺少“是否参与相分离”的标签 | 提供带证据分级的正例集合，可按物种与证据强度筛选 | 只用四星以上（活细胞或体内）建高置信集，其余做弱监督 |
| 你要构建生物医学知识图谱，缺一层“蛋白—细胞结构”关系 | 提供以 UniProt 与 DOID 为锚点的三元组，可直接并入 | 先做编号归一化，再处理一蛋白多凝聚体的多边 |
| 你在评估某个药物是否可能通过凝聚体起效 | c-mod 表给出化合物、靶凝聚体、作用类别与审批状态 | 把 ChEMBL 活性数据接进来，别只看“已批准”标签 |
| 你在写综述，需要一份凝聚体研究的时间切片 | 版本发布页保留每季度计数与新增删除记录 | 引用时写清版本号与日期，勿混用不同版本 |
| 你的课题组发现了一个新凝聚体，想让它被检索到 | 注册后可提交新记录，维护者审核后入库 | 准备好人名、物种、组分与至少一条实验证据 |
| 你在做感染性疾病与宿主因子的交叉研究 | 感染性凝聚体单独成类，宿主与病原物种分列 | 注意同名不同病原的记录，务必按物种过滤 |
1.5 一句话判断
它更像一张标注了出处的细胞结构地图，而不是一份可以直接下锅的原料：价值不在覆盖多少蛋白，而在每条边上都写着“谁在什么实验里看到的”。
1.6 不适合谁：四条边界
不适合只要大表的人。 全库的凝聚体与蛋白表加起来是几万行的量级，但真正可用的关系只有一万五千余条，且分布极不均匀。想要百万级三元组的知识图谱项目，它只能当种子层，不能当主体。
不适合把缺失当否证的人。 官方明确不提供预测，也不保证覆盖。任何“不在表里即阴性”的推断都不成立。做分类任务时，负例必须另有来源。
不适合商业闭源产品直接集成。 CC BY-NC 4.0 禁止商业性使用。企业内部模型训练、SaaS 产品内置都落在受限范围，需先取得授权。
不适合临床决策或药物疗效论证。 它记录的是实验模型中的关联，不是患者结局。133 条凝聚体病是研究线索，不是适应证。
§2 数据构成与规格
2.1 四类实体，一张关系网
CD-CODE 的数据模型是典型的实体—关系结构，四类实体加一层核酸标注。凝聚体是中心，蛋白通过“属于”关系挂上来，化合物通过“调节”关系挂上来，疾病通过“凝聚体病”记录挂上来。2.0 版把底层的 MongoDB 换成了 PostgreSQL，正是为了让这种多对多关系可以被联合检索。
| 实体 | 含义 | 主键 | 规模（2.4 版） |
|---|---|---|---|
| 凝聚体 | 一个被命名的无膜结构，分生物分子、感染性、合成三类 | 8 位十六进制编号 | 815 |
| 蛋白 | 被报告为某凝聚体组分的蛋白，按物种区分 | UniProt 编号 | 一万一千五百余 |
| 调节化合物 | 改变凝聚体性质的小分子、肽或寡核苷酸 | 整数 modulator_id | 409 |
| 凝聚体病 | 疾病相关的凝聚体异常表型 | 无独立编号；疾病用 DOID | 133 |
| 关系 | 蛋白属于凝聚体，附证据与星级 | 凝聚体编号 + UniProt 编号 | 一万五千余 |
四类实体不是平级的。凝聚体与蛋白构成主体，化合物与疾病是 2.0 版新增的两翼；核酸不是独立实体，而是挂在凝聚体上的属性列，取值为 RNA 或 DNA。这个设计决定了取数时的连接方式：想找“某个药作用于哪些蛋白”，路径是药→凝聚体→蛋白，中间必须经过凝聚体，不能直接连。
2.2 字段与记录的完整字典
先看凝聚体。网页端把字段分成“一般信息”和“实验”两组，API 返回的字段更少，只保留检索与列表需要的部分。下表按网页端字段整理，括号内为 API 字段名。
| 字段 | 含义 | 取值示例 | 来源 |
|---|---|---|---|
| uid（uid） | 凝聚体唯一编号 | E12AB6E0 | 系统生成 |
| name（name） | 标准名称 | 53BP1 Mitotic Stress Body (MSBs) | 策展人命名 |
| description | 一段文字描述 | 每条不同，例：53BP1 在分裂应激下于着丝粒附近形成 | 策展人撰写 |
| synonyms | 别名列表 | MSBs、MSB、Mitotic Stress Bodies | 文献归并 |
| condensate_type（condensate_type） | 类型 | biomolecular / infectious / synthetic | 策展人判定 |
| species_name（species_name） | 物种名 | Homo sapiens | 文献 |
| species_taxon_id（species_taxon_id） | NCBI 分类号 | 9606 | 映射 |
| infectious_agent_species_name | 病原物种 | 仅感染性记录有值 | 文献 |
| markers | 标记蛋白 | 蛋白清单 | 文献 |
| regulators | 调控蛋白 | 蛋白清单 | 文献 |
| protein_count（protein_count） | 组分蛋白数 | 3 | 系统计数 |
| confidence_score（confidence_score） | 星级 | 1–5 | 由成员蛋白星级取中位数 |
| nucleicacids（详情为 nucleic_acids） | 核酸组分 | [“dna”]、[“rna”] | 文献 |
| cmods_count（cmods_count） | 关联化合物数 | 0 | 系统计数 |
| condensatopathies_count | 关联疾病数 | 0 | 系统计数 |
| experiments | 实验条件组 | 方法、pH、温度、盐、浓度、形态 | 文献 |
| pubmed | 证据文献编号 | PMID 列表 | 文献 |
再看蛋白。蛋白表的字段比凝聚体少，但多了转录后修饰与角色两列，这两列是判断“驱动者还是乘客”的关键。
| 字段 | 含义 | 取值示例 |
|---|---|---|
| uniprot_id | UniProt 登录号 | F4JWP9 |
| uniprotkb_id | UniProt 记录名 | GFL_ARATH |
| name | 蛋白全名 | 109 kDa U5 small nuclear ribonucleoprotein component GFL |
| gene_name | 基因名 | GFL |
| species_name | 物种 | Arabidopsis thaliana |
| species_taxon_id | 分类号 | 3702 |
| ensembl_id | Ensembl 基因编号 | 以物种前缀开头，如 ENSG… |
| human_protein_atlas | HPA 链接 | 仅人类蛋白 |
| verified_biomolecular | 是否在生物分子凝聚体中验证 | 是 / 否 |
| verified_synthetic | 是否在合成凝聚体中验证 | 是 / 否 |
| ptm | 影响凝聚体形成的修饰 | 名称、类型、酶、位点、描述 |
| role | 在该凝聚体中的角色 | driver / member |
| biomolecular_condensate_count | 参与的生物分子凝聚体数 | 1 |
化合物与疾病关联的字段更窄，但每条都带外部编号，便于跨库连接。
| 实体 | 字段 | 含义 |
|---|---|---|
| c-mod | modulator_id | 整数编号 |
| c-mod | modulator_name | 化合物名 |
| c-mod | biomolecular_type | 分子类型（小分子、肽等） |
| c-mod | target_molecule | 直接靶分子，可为空 |
| c-mod | annotations | 每条含靶凝聚体、作用类别、标记蛋白 |
| c-mod | moa_class | 诱导、溶解、定位、改形四类 |
| c-mod | approval | 审批状态（据 ChEMBL） |
| c-mod | pubchem / chembl | 外部结构编号 |
| 凝聚体病 | condensates | 受累凝聚体编号 |
| 凝聚体病 | diseases | DOID、疾病名、定义 |
| 凝聚体病 | dysregulation_type | 失调现象的文献摘要 |
| 凝聚体病 | condensate_markers | 相关蛋白的 UniProt 编号 |
| 凝聚体病 | publications | PMID |
关系表本身没有独立字段文件，它由两端的实体与证据列组成。理解这一点很重要：关系不是一张可以单独下载的边表，而是从凝聚体记录里展开的成员列表。
一条关系至少要有两端的编号与一条文献。网页端还展示角色、证据类型、星级、PMID、实验条件与核酸标记六项；API 的列表端点只给两端编号与计数，细粒度字段要逐条展开才拿得到。这个差异意味着：做批量统计时，你能拿到的是骨架；做证据核查时，必须回到单条记录（§5.3）。
§4.3 的案例提醒，病原列不是装饰：没有它，感染性记录会被误并入普通凝聚体，宿主与病原的边界也随之消失。
2.3 一条记录的完整解剖
以 2.4 版 API 列表中的一条记录为例，一条记录在 JSON 里是这样的（字段已按原样保留，仅去掉未展开的子对象）：
{
"uid": "E12AB6E0",
"name": "53BP1 Mitotic Stress Body (MSBs)",
"condensate_type": "biomolecular",
"species_name": "Homo sapiens",
"species_taxon_id": 9606,
"infectious_agent_species_name": null,
"nucleicacids": ["dna"],
"protein_count": 3,
"confidence_score": 4,
"cmods_count": 0,
"condensatopathies_count": 0
}
这十几个字段可以分三层读。第一层是身份：uid 是稳定标识，name 是人读的名称，两者不可互相替代——名称会改，编号一般不变，但编号也会因记录合并而消失（§7.3）。第二层是生物学上下文：类型、物种、病原、核酸，四项合起来才能唯一确定“哪一个凝聚体”，因为同名不同物种的情况在感染性记录里很常见，官方明确说库里有六个不同病原来源的包涵体都叫 inclusion body。第三层是聚合量：蛋白数、化合物数、疾病数、星级，它们是导航用的指针，不是分析用的变量。
真正的内容在展开后的成员表里。点开一个凝聚体，看到的是蛋白列表与每条边的证据列；再点开一个蛋白，看到的是它参与的所有凝聚体与角色。这种以凝聚体为中心的存储方式，决定了 API 的取数顺序：先取凝聚体，再逐条展开成员，而不是反过来。
| 读一条记录时的顺序 | 看什么 | 常犯的错 |
|---|---|---|
| 第一步 | uid 与 name 是否匹配你要的对象 | 拿名称做连接，遇到同名记录就错配 |
| 第二步 | condensate_type | 把感染性记录混进普通凝聚体统计 |
| 第三步 | species 与 taxon_id | 忽略物种，把跨物种证据合并 |
| 第四步 | protein_count 与成员表 | 用计数当规模，实际成员可能只公开了部分 |
| 第五步 | confidence_score | 把星级当质量分，忽略它是中位数 |
| 第六步 | 证据列 | 只看“有”，不看是质谱还是体内实验 |
2.4 置信度是一套五级量表
星级不是模型打分，是证据类型的代理。官方给出的定义把五档写得很清楚，每一档对应一种实验强度。
| 星级 | 判定依据 | 典型实验 | 可信程度 |
|---|---|---|---|
| 1 星 | 仅有 PubMed 文献标注 | 共定位、免疫荧光 | 最弱，只能说明被报告过 |
| 2 星 | 高通量实验 | 质谱、蛋白质组筛选 | 较弱，假阳性率高 |
| 3 星 | 体外实验 | 纯化蛋白相分离、液滴实验 | 中等，缺细胞内上下文 |
| 4 星 | 活细胞实验 | 活细胞成像、FRAP | 较强 |
| 5 星 | 体内实验 | 动物模型、内源标记 | 最强 |
凝聚体本身的星级取成员蛋白星级的中位数。这个规则有一个容易被忽略的后果：一个只有三个蛋白、其中一个做了体内实验的凝聚体，中位数可能仍是 4 星；而一个有八十个蛋白、大量质谱证据的凝聚体，中位数可能只有 2 星。星级高不代表研究透，只代表“成员证据的中位强度高”。
2.5 与同类资源的字段差异
做凝聚体研究的数据库不止一家。差别不在谁收录得多，而在各自把什么当作一等公民。
| 资源 | 中心 | 主要字段 | 与 CD-CODE 的差异 |
|---|---|---|---|
| CD-CODE | 凝聚体 | 凝聚体、蛋白、化合物、疾病 | 唯一把四类实体与疾病本体连起来 |
| PhaSePro | 蛋白 | 驱动蛋白、区域、突变 | 以驱动蛋白为中心，凝聚体是附属 |
| LLPSDB | 实验 | 序列、条件、相行为 | 以试管实验条件为中心 |
| DrLLPS | 蛋白 | 蛋白、调控因子、疾病 | 偏计算与预测整合 |
| PhaSepDB | 蛋白 | 蛋白、定位、疾病 | 偏蛋白定位注释 |
| 凝聚体百科（wiki） | 术语 | 定义、同义词 | 只有词条，没有关系表 |
从字段差异能看出一件事：如果你要的是“某个蛋白在哪些凝聚体里、证据多强”，CD-CODE 的边属性最全；如果你要的是“某条序列在什么盐浓度下相分离”，LLPSDB 更合适；如果你要的是“哪些蛋白被预测为驱动者”，DrLLPS 一类才收录预测。三者不是替代关系，混用时要先统一“凝聚体”的边界定义。
把三个维度并排看，差别一目了然：预测收录上，只有蛋白中心库部分收录，CD-CODE 与实验条件库都不收；证据分级上，只有 CD-CODE 有完整的五级；跨物种与疾病连接上，CD-CODE 做得最全；化合物连接则是它独有的。更新方式也不同，CD-CODE 是季度版本加众包，另外两类多为不定期。选库时先问自己要的是边、是序列还是条件，答案不同，库也不同。
§3 它是谁的数据库：一个研究所的策展工程
3.1 机构、作者与钱从哪来
CD-CODE 的常驻团队在德累斯顿。马克斯·普朗克分子细胞生物学与遗传学研究所提供场地、服务器与计算支持，德累斯顿系统生物学中心提供交叉学科编制，另有德累斯顿工业大学的生命物理卓越集群参与。产业侧的 Dewpoint Therapeutics 有作者署名，这家公司本身就在做凝聚体相关的药物开发，这一点在读“化合物”部分时值得留意——数据库收录 c-mod 的动机，与一家凝聚体药物公司的商业方向是同向的。
这些机构的角色可以一句话概括：MPI-CBG 出人、出机器、出场地；CSBD 出跨学科编制与策展流程；德累斯顿工业大学的生命物理卓越集群以作者身份参与方法学；Dewpoint Therapeutics 带来化合物注释的产业经验；经费来自马克斯·普朗克学会、NOMIS 基金会与欧洲研究理事会。五方各管一段，没有一方单独拥有数据。
作者列表在 2.0 版论文里长到二十余人，第一作者为 Ksenia Kuznetsova 与 Maxim Scheremetjew（共同一作），通讯作者为 Agnes Toth-Petroczy，另有 Diana Mitrea 作为共同通讯。这个规模说明它不是一个小作坊式的附录数据库，而是一个有专职工程与策展人员的长期项目。
3.2 时间线：三年从两百多到八百多
| 时间 | 事件 | 规模 |
|---|---|---|
| 2023 年 1 月 | 数据 1.01 版随 Nature Methods 投稿发布 | 首批数据 |
| 2023 年 4 月 | 网站 1.0 上线，含 wiki 与提交系统 | — |
| 2023 年 5 月 | Nature Methods 论文刊出 | 244 个凝聚体、9,861 个蛋白、49 个物种 |
| 2024 年 6 月 | 2.0 版文献策展截止 | — |
| 2025 年 8 月 | 数据 2.0 版发布 | 782 个凝聚体、一万零三百余个蛋白 |
| 2025 年 11 月 | 网站 2.0 与 API v2 上线 | 底层改为 PostgreSQL |
| 2025 年 12 月 | 数据 2.1 版 | 788 个凝聚体、10,616 个蛋白、253 个 c-mod |
| 2026 年 3 月 | 数据 2.2 版 | 798 个凝聚体、11,133 个蛋白、368 个 c-mod |
| 2026 年 6 月 | 数据 2.3 版 | 805 个凝聚体、11,144 个蛋白、374 个 c-mod |
| 2026 年 10 月 | 数据 2.4 版 | 815 个凝聚体、一万一千五百余个蛋白、409 个 c-mod |
这张表里最值得注意的是 2025 年下半年的跳变：数据从 1.10 版的 719 直接到 2.0 版的 782，蛋白从九千八百余到一万零三百余，同时新增了化合物与疾病两类实体。这不是自然增长，是一次模型扩展。此后的季度增量回到十几到几十的量级，说明扩展完成后进入了稳定策展节奏。
3.3 一条记录是怎么被造出来的
官方在论文里把流程写得很细，可以拆成五步。第一步，用一套自建的凝聚体术语本体去检索 PubMed 新入库文献的标题与摘要，命中者进入候选池。第二步，自动文本挖掘按实验相关性排序，把纯计算建模类排到后面，把有生物学实验的排到前面。第三步，策展人逐篇读原文，确认这是不是一个凝聚体、组分是谁、证据是什么。第四步，把蛋白名归一化为 UniProt 编号，疾病名映射到 DOID，化合物对齐 PubChem 与 ChEMBL。第五步，登记证据类型与 PMID，写入数据库。
| 步骤 | 输入 | 动作 | 输出 |
|---|---|---|---|
| 检索 | PubMed 新文献 | 术语本体匹配标题与摘要 | 候选文献池 |
| 排序 | 候选池 | 按实验相关性自动排序 | 待读清单 |
| 阅读 | 单篇论文 | 人工确认凝聚体、物种、组分 | 原始抽取结果 |
| 归一化 | 蛋白名、疾病名、化合物名 | 映射 UniProt、DOID、PubChem/ChEMBL | 标准编号 |
| 登记 | 抽取结果 | 写证据类型、星级、PMID | 入库记录 |
论文还提到一个细节：辅助文献筛选时“零星使用”了 AI 工具 ScienceOS，但抽取结果全部由维护者复核。这句话的分量在于责任归属——工具可以帮忙筛，判断仍由人做。对于在意数据出处的使用者，这比“全自动抽取”更可信，也意味着吞吐量受人力限制。
3.4 三种角色与一场工作坊
众包不是开放编辑。系统把用户分成查看者、贡献者、维护者三级，权限逐级收紧。
| 角色 | 能做什么 | 不能做什么 | 是否需要注册 |
|---|---|---|---|
| 查看者 | 浏览、检索、下载数据包 | 修改任何内容 | 否 |
| 贡献者 | 提交新记录、修订建议、补充文献 | 直接改动线上数据 | 是 |
| 维护者 | 审核、接受或驳回建议、合并重复记录 | 绕过证据要求 | 是 |
除了线上提交，团队还在 MPI-CBG 内部办“凝聚体工作坊”（condensathon），把研究凝聚体的实验组集中起来，当场补记录、当场核文献。2.0 版论文致谢里列了十余位工作坊贡献者。这种线下策展的效率高于等待陌生网友提交，但也带来一个结构性偏差：被德累斯顿周边实验室研究的凝聚体，记录质量与完整度天然更好。
3.5 数据的三个来源层次
三层来源的可靠性递减：一手文献最硬，有 PMID 与证据类型；外部库整合次之，编号对得上但版本会漂；社区提交最软，取决于审核严格度。三者混在一起，使用时需要区分。蛋白的序列与基因名来自 UniProt 与 Ensembl，不是 CD-CODE 原创；化合物的结构来自 PubChem 与 ChEMBL；疾病定义来自 DO。真正属于 CD-CODE 原创的是“哪条证据支持哪个蛋白属于哪个凝聚体”这一层判断。引用时若只说“据 CD-CODE”，会把外部库的功劳也揽进来；更准确的说法是“据 CD-CODE 整理的文献证据，蛋白编号取自 UniProt”。
§4 它最独特的东西：把证据强度写进关系里
4.1 为什么一条边需要重量
网络分析有个默认假设：边是同质的。两个节点相连就是相连，最多给个权重。凝聚体研究不适用这个假设，因为“相连”的实验含义跨度太大。质谱从一千个蛋白里捞出某个蛋白，与在活细胞里看到它随颗粒一起消失，是两种完全不同强度的主张。
CD-CODE 的解法是把证据类型变成边的属性，再用星级汇总。这一步看似只是加了一列，实际改变了数据的用法：你可以只取四星以上的边，得到一个高置信子网；也可以保留全部边，观察研究热度的分布。同一份数据，两种读法，结论不同，但都诚实。
| 读法 | 取的边 | 适合的问题 | 风险 |
|---|---|---|---|
| 高置信子网 | 4–5 星 | 机制研究、药物靶点论证 | 边太少，网络碎片化 |
| 全量网络 | 1–5 星 | 覆盖度分析、文献计量 | 弱证据淹没强证据 |
| 仅高通量 | 2 星 | 发现新候选 | 假阳性率高 |
| 仅低置信 | 1 星 | 找研究空白 | 多数是未跟进的老报道 |
4.2 证据类型如何落到字段
官方把实验分成几类，分别对应不同的星级。这套映射不是严格的量表，而是粗略的分层：越靠近体内、越接近原生环境，星级越高。
| 证据类别 | 具体做法 | 星级 | 能说明什么 | 不能说明什么 |
|---|---|---|---|---|
| 文献提及 | 只有一篇论文说它在 | 1 | 被报告过 | 是否可重复 |
| 高通量 | 质谱、蛋白质组 | 2 | 物理上共同纯化 | 是否同一结构内 |
| 体外 | 纯化蛋白相分离 | 3 | 有自组装能力 | 细胞内是否发生 |
| 活细胞 | 成像、FRAP、光遗传 | 4 | 细胞内存在动态交换 | 内源环境是否相同 |
| 体内 | 动物模型、内源标签 | 5 | 生理条件下存在 | 人体是否相同 |
这套分层的实用价值在于筛选阈值。做药物靶点论证时，四星以下的边基本不能单独支撑结论；做候选发现时，二星边反而是富矿，因为质谱数据往往先于机制研究出现。
4.3 案例：GCRV viroplasm 如何被拆成宿主与病原两半
2.0 版论文里用了一个具体记录说明感染性凝聚体的建模方式：草鱼呼肠孤病毒（GCRV）感染草鱼后形成的病毒质，编号 5FC38D49。这个记录被官方标为“混合组分”——颗粒里既有病原自己的蛋白，也有被劫持的宿主蛋白。若按普通凝聚体建模，只能写“草鱼的一种凝聚体”，病原信息无处安放；CD-CODE 的做法是把宿主物种与病原物种分成两列，再在成员表里逐条标注来源。
| 字段 | 该记录的取值 | 为什么重要 |
|---|---|---|
| 类型 | infectious | 与普通生物分子凝聚体区分统计 |
| 宿主物种 | Ctenopharyngodon idella（草鱼） | 决定实验模型与温度条件 |
| 病原 | 草鱼呼肠孤病毒 | 决定这条记录属于病毒学而非细胞生物学 |
| 组分来源 | 混合（宿主 + 病原） | 影响“谁在驱动形成”的判断 |
| 编号 | 5FC38D49 | 跨版本连接的锚点 |
这个案例说明了一个常被忽略的问题：同一个名字在不同宿主—病原组合下可能是不同的凝聚体。官方提到库里有六个包涵体都叫 inclusion body，但分属不同病原。若你用名称做检索再合并，会把六个不同的生物学对象压成一个，后续任何统计都失真。正确做法是先按物种与病原过滤，再用编号连接。
§4.3 的案例还可以反着用：当你要找“哪些宿主蛋白被病毒劫持进凝聚体”时，普通凝聚体表里没有病原列，必须走感染性这一支；而感染性记录只占少数（2.0 版为 29 个），覆盖率远低于普通凝聚体，这也是这类研究常感到数据稀疏的原因。
4.4 核酸组分与感染性凝聚体：2.0 版的两块新地
1.0 版只记蛋白。2.0 版把 RNA 与 DNA 加进组分，并把感染性凝聚体单列。这两项扩展的意义不同：核酸扩展是对生物学事实的补课，因为很多凝聚体的核心组分本来就是 RNA；感染性扩展是对疾病场景的补课，因为病原形成的凝聚体在宿主—病原界面上有独特的药物学价值。
| 扩展项 | 2.0 版规模 | 数据形态 | 使用注意 |
|---|---|---|---|
| 核酸组分 | 挂在凝聚体上的 RNA/DNA 标记 | 属性列，非独立实体 | 只标有无，不标序列与比例 |
| 感染性凝聚体 | 29 个 | 独立类型，宿主与病原分列 | 同名记录多，须按物种过滤 |
| 多物种凝聚体 | 124 个生物分子凝聚体中 52 个有多物种注释 | 同一凝聚体挂多个物种 | 跨物种合并前先确认同源关系 |
| 化合物 | 236 个（2.0 版） | 独立实体，连 PubChem/ChEMBL | 作用类别是文献判断，非实验统一测 |
| 凝聚体病 | 102 条（论文口径） | 独立实体，连 DOID | 与发布页的 101 条差一条 |
最后一行是两个口径的真实例子：2.0 版论文写 102 条凝聚体病，同期的数据发布页写 101 条。差额的构成官方没有说明，可能是统计时点差一次审核，也可能是某条记录在打包时被排除。遇到这类差异，正确做法是引用时写明“论文口径”或“发布页口径”，不要替官方下结论。
4.5 证据不对称带来的使用边界
这五种不对称叠在一起，决定了任何全局统计都要加一句限定。物种不对称让跨物种模型偏向哺乳动物；凝聚体不对称让网络中心度反映研究热度；证据类型不对称让高星级子网很小；时间不对称让同一凝聚体的证据新旧混杂；疾病不对称让罕见病关联稀疏。报告结果时，把这几条写进局限性，比事后解释更省力。
§5 怎么拿到：三条通道与各自的坑
5.1 三条通道，先选对再动手
| 通道 | 入口 | 适合 | 限制 |
|---|---|---|---|
| 网页浏览 | cd-code.org | 查单个凝聚体、看证据表 | 不适合批量 |
| 版本数据包 | 发布页的外部网盘链接 | 一次性拿全量、做离线分析 | 格式未标注，链接按版本变 |
| REST API | /api/ 与 /api-docs | 程序化取数、增量同步 | v1 公开分页，v2 需令牌 |
三条通道的数据同源，但字段完整度不同。网页端能看到证据表与实验条件，API 列表只返回摘要字段，数据包则是打包时的全量快照。要拿“证据类型”这种细粒度列，网页端或数据包更稳；只做实体清单，API 足够。
5.2 用公开 API 取一页凝聚体
v1 接口不需要令牌，返回 JSON，带总数、当前页、总页数与数据数组。下面这条命令取第一页并列出编号与名称：
#-- 取第一页凝聚体，打印编号、名称、蛋白数与物种
curl -s "https://cd-code.org/api/condensates" \
| jq -r '.data[] | [.uid, .name, .protein_count, .species_name] | @tsv' \
| head -20
返回的外层结构固定为四个键：count、current_page、data、pages。写分页循环时用 pages 做上界，不要用 count 除以页大小自行推算，因为页大小可能随接口调整。
#-- 查看总数与页数，确认分页规模
curl -s "https://cd-code.org/api/condensates" | jq '{count, pages, current_page}'
5.3 分页抓全量并落成表
下面这段 Python 只依赖标准库，按页拉取三类实体，写成三个 JSONL 文件。加入短暂停顿是为了不连续冲击对方服务器。
#-- 分页抓取凝聚体、蛋白、化合物，落成 JSONL
import json, time, urllib.request
BASE = "https://cd-code.org/api"
def fetch_all(kind):
page, rows, pages = 1, [], 1
while page <= pages:
url = f"{BASE}/{kind}?page={page}"
with urllib.request.urlopen(url, timeout=30) as r:
payload = json.load(r)
pages = payload.get("pages", 1)
rows.extend(payload.get("data", []))
page += 1
time.sleep(0.5)
return rows
for kind in ("condensates", "proteins", "c-mods"):
data = fetch_all(kind)
with open(f"{kind}.jsonl", "w", encoding="utf-8") as f:
for row in data:
f.write(json.dumps(row, ensure_ascii=False) + "\n")
print(kind, len(data))
跑完会得到三份行式 JSON。凝聚体约八百余行，蛋白一万一千余行，化合物四百余行。这个体量在单机上几分钟可以处理完，不需要分布式。
5.4 v2 接口要令牌，先申请再谈自动化
2.0 版把接口升到 v2，改成 OpenAPI 3.0 描述，全部端点要求 Bearer 令牌。令牌不在网页上自助生成，需要发邮件向团队申请。拿到之后，调用方式与常见 REST 服务一致：
#-- 令牌放在环境变量里，避免写进脚本
export CD_CODE_TOKEN="申请到的令牌"
curl -s -H "Authorization: Bearer ${CD_CODE_TOKEN}" \
"https://cd-code.org/api/v2/condensates?page=1" \
| jq '.count, (.data | length)'
v2 的文档页给出四类端点：凝聚体、蛋白、化合物、疾病关联，另有跨实体检索。字段命名与 v1 不完全一致，迁移脚本要做一次映射，不能假设同名同义。
两版的差别不只在鉴权。v1 没有正式规范，只有列表与分页；v2 用 OpenAPI 3.0 描述，支持全字段检索、排序与过滤，实体字段也更全。v1 仍保留但不再扩展，新项目应直接对接 v2。迁移时要注意字段命名不完全一致，不能假设同名同义。
5.5 数据包：链接稳定，格式要自己看
发布页每个版本都挂一个“下载数据文件”的链接，指向 MPI-CBG 的 ownCloud 分享。链接本身不带文件名，下载前无法从页面判断格式与体积。
#-- 下载 2.4 版数据包；先看响应头再决定保存名
curl -sIL "https://owncloud.mpi-cbg.de/index.php/s/rMUqyxDidyevpOS/download" \
| grep -i -E "content-type|content-length|content-disposition"
这一步的实用价值是避免把压缩包当成 CSV 直接读。官方页面没有标注格式，若响应头也没有给出文件名，就按二进制下载后再用 file 命令判断。更早版本的数据包不直接挂在页面上，官方写明需要发邮件索取。
数据包的获取方式分三档：2.4 至 2.2 是直链，点开即下；2.1 与更早是带 path 参数的目录式链接，需要逐版点进去；若需要页面上没有列出的特定版本，则要发邮件向维护团队申请。链接不带文件名，下载前无法从页面判断格式与体积，这一点在规划存储时容易低估。
5.6 五个最容易出错的地方
| 坑 | 表现 | 正确做法 |
|---|---|---|
| 用名称做连接 | 同名不同物种的记录被合并 | 用 uid 与 UniProt 编号连接 |
| 把分页当全量 | 只取第一页就统计 | 读到 pages 上界为止 |
| 跨版本拼接 | 编号在合并后消失，出现孤儿边 | 固定一个版本快照，记录版本号 |
| 把 c-mod 直接连蛋白 | 中间缺凝聚体，关系错配 | 走 药→凝聚体→蛋白 的路径 |
| 忽略许可 | 直接用于商业产品 | 先确认 CC BY-NC 范围并申请授权 |
§4.3 的案例里的同名包涵体，就是名称连接失效的典型：六个对象都叫 inclusion body，分属不同病原。若按名称去重，六条会变成一条；按编号连接，六条各归各位。
§6 与库内记录的关系
6.1 关系图谱：它是蛋白记录的下游，不是替代
库内与 CD-CODE 最近的邻居是 UniProt。两者的关系不是竞争，而是上下游：UniProt 回答“这个蛋白是什么”，CD-CODE 回答“这个蛋白在哪个无膜结构里被看到过”。前者是身份登记，后者是场景登记。把 CD-CODE 当蛋白注释库用，会立刻发现它只有一万余个蛋白，且大部分字段要靠 UniProt 补。
| 库内记录 | 与 CD-CODE 的连接点 | 关系类型 | 使用建议 |
|---|---|---|---|
| UniProt | 蛋白主键、序列、功能注释 | 上游身份源 | 先用 UniProt 取序列，再回连凝聚体 |
| Ensembl | 基因编号、转录本 | 并行注释 | 做基因级聚合时用 Ensembl ID 对齐 |
| Human Protein Atlas | 组织表达、亚细胞定位 | 侧向验证 | 检验“凝聚体组分”与“定位注释”是否一致 |
| PDB | 实验结构 | 结构层 | 看是否有凝聚体相关结构域 |
| AlphaFold | 预测结构 | 结构层 | 补 PDB 缺口的折叠信息 |
| STRING | 蛋白互作 | 网络层 | 区分“互作邻居”与“同颗粒成员” |
| ChEMBL | 化合物活性 | 化合物层 | 给 c-mod 补剂量与活性 |
| DrugBank | 药物与靶点 | 化合物层 | 核对审批状态与适应证 |
| GtoPdb | 受体与通道药理学 | 化合物层 | 补靶点药理学注释 |
| PRIDE / ProteomeXchange | 质谱原始数据 | 证据层 | 追质谱证据的原始谱图 |
这张表最重要的是第一行与第六行。第一行决定了你必须做编号归一化；第六行提醒你不要把“互作”当“共处一室”——两个蛋白在 STRING 里有边，不代表它们在同一个凝聚体里，反之亦然。
6.2 检索路径
| 你要找的东西 | 检索词 | 落点 |
|---|---|---|
| 某蛋白的序列与功能 | UniProt 编号或基因名 | UniProt 记录，再回连本库 |
| 某蛋白在细胞里的位置 | 蛋白名 + subcellular localization | HPA 记录 |
| 某凝聚体的全部已知组分 | 凝聚体名 + condensate | 本库凝聚体页 |
| 某化合物的凝聚体作用 | 化合物名 + c-mod | 本库化合物页，再连 ChEMBL |
| 某疾病的凝聚体机制 | 疾病名 + condensatopathy | 本库疾病关联页，再连 DOID |
| 质谱证据的原始数据 | 蛋白名 + mass spectrometry | PRIDE 或 ProteomeXchange |
6.3 分工判据
| 任务 | 主力库 | CD-CODE 的位置 | 原因 |
|---|---|---|---|
| 蛋白序列与结构域注释 | UniProt | 辅助 | 本库不含序列 |
| 组织与细胞定位 | HPA | 辅助 | 本库只标凝聚体归属 |
| 蛋白互作网络 | STRING | 不可替代 | 本库不建互作边 |
| 化合物活性与剂量 | ChEMBL | 上游线索 | 本库只标作用类别 |
| 药物审批与适应证 | DrugBank | 上游线索 | 本库审批状态转自 ChEMBL |
| 凝聚体归属与证据强度 | CD-CODE | 主力 | 别处没有同粒度的证据列 |
| 疾病—凝聚体关联 | CD-CODE + DO | 主力之一 | 本库给关联，DO 给定义 |
| 临床表型与结局 | 专科队列库 | 不适用 | 本库无患者数据 |
§7 质量评估与局限性
7.0 阅读本节前的一个前置校正
先纠正一个容易发生的误判：把“记录少”当成“质量差”。CD-CODE 的 815 个凝聚体不是自然界凝聚体的总数，而是被论文报告过、被策展人确认过的数量。它的目标从来不是穷举，而是可追溯。评价它的时候，尺子应该是“每条边有没有出处、证据分不分级”，而不是“覆盖了多少蛋白”。
这个校正会改变后面五维评分的读法。规模一项它拿不到高分，但在“关系可追溯”这一项上，它比多数整合型数据库更严格。把两件事混在一起，就会得出“数据太少不值得用”的结论，而忽略了它本来就不是为规模训练准备的。
7.1 五维评分
按 DAIMS 的常用维度打分，每项 1–5 分，分数针对“作为凝聚体知识与弱监督来源”这个用途：
| 维度 | 分数 | 理由 |
|---|---|---|
| 数据规模 | 3 | 八百余凝聚体、一万余蛋白，做知识图谱种子够，做预训练不够 |
| 标注质量 | 4 | 证据分级明确，逐条挂 PMID，但星级是粗分层 |
| 任务适配 | 5 | 蛋白—凝聚体关系加证据强度，几乎无替代品 |
| 文档完整 | 4 | 论文、关于页、API 文档齐全，个别口径不一致 |
| 可获取性 | 4 | 免注册浏览与公开 API，但数据包格式与体积未标注 |
五项合计 20 分（满分 25）。许可不在这五项里，但它是一道硬门槛：CC BY-NC 意味着商业使用要先谈授权，分数再高也不能绕过。分数结构说明它的强弱很分明：适配性拉满，规模中等，文档与获取都稳。对学术研究，这是一份高性价比的骨架；对企业，许可一项就足以否决直接集成。
7.2 证据覆盖的两层
第一层是有没有证据。库里每条关系都有 PMID，这一点比很多整合库严格。你可以顺着编号回到原文，检查实验类型与结论是否被正确抽取。这层质量取决于策展人的阅读，而不是算法。
第二层是证据够不够强。五级量表把“质谱看到”与“体内看到”分开，但同一级内部的差异仍很大：同样是活细胞成像，过表达与内源标记的可信度不同；同样是质谱，交联与共纯化的假阳性率不同。这些差异在库里被压平成一个星级，使用时不能把四星当成统一质量。
门槛不是越高越好，而是跟着用途走。机制综述引用四星以上，因为需要活细胞或体内证据；药物靶点假设三星以上，同时要看实验条件，体外能相分离不等于体内发生；候选发现可以用全部边，按星级加权；负例构造不要用本库，因为这里没有否证记录；网络中心度分析也要用全部边，但必须同时报告研究热度，否则中心度会被热度污染。
7.3 已知的、可枚举的偏差
| 偏差 | 表现 | 影响 |
|---|---|---|
| 物种偏差 | 人类与小鼠占多数，官方统计接口覆盖 117 个蛋白物种、80 个凝聚体物种 | 跨物种模型偏向哺乳动物 |
| 研究热度偏差 | 应激颗粒、核仁等热门结构收录密集 | 网络中心度反映资源分布 |
| 证据类型偏差 | 质谱与成像多，体内实验少 | 高星级子网稀疏 |
| 时间偏差 | 2.0 版文献截至 2024 年 6 月，后续增量补充 | 新旧证据混存，未统一重审 |
| 名称偏差 | 同一结构多种叫法，官方做归并但仍有别名 | 按名称检索会漏 |
| 编号变动 | 2.1 版删除 5 个冗余凝聚体，2.4 版删除 1 个 | 跨版本连接出现断链 |
| 缺失语义 | 官方明确缺失有三种可能 | 不能把未收录当否证 |
| 疾病偏差 | 肿瘤、神经、感染三类居多 | 罕见病关联稀疏 |
编号变动这一条值得单独说。发布页明确记录每个版本“删除的冗余凝聚体”数量，说明合并是常态。若你把两个版本的编号做外连接，会遇到一类孤儿边：旧编号在新版不存在，新编号在旧版不存在。正确做法是固定快照，或保存每次发布的全量包做版本对照，而不是用线上 API 拼历史。
7.4 外部验证矩阵
CD-CODE 的可信度不靠自证，靠与外部库的交叉引用。官方在 UniProt 的亚细胞定位区做了交叉引用，可以用一条查询列出所有被 CD-CODE 收录的蛋白；化合物连到 PubChem 与 ChEMBL，疾病连到 DO。这些连接是可检验的。
| 验证方向 | 做法 | 讲得通的地方 | 风险 |
|---|---|---|---|
| 蛋白身份 | UniProt 交叉引用 | 编号唯一，可回溯 | 异构体与修饰未区分 |
| 化合物身份 | PubChem/ChEMBL 结构 | 结构唯一 | 盐型与活性形式可能不同 |
| 疾病分类 | DOID 映射 | 标准本体 | 罕见病映射粒度粗 |
| 表达与定位 | HPA 对照 | 独立实验 | 细胞类型不同，结论可能相反 |
| 文献证据 | PMID 回溯 | 可读原文 | 抽取错误需人工发现 |
| 社区修订 | 提交与审核记录 | 有纠错机制 | 审核标准未公开 |
外部研究的使用方式也能侧面验证。2.0 版论文提到，社区已用这份数据开发预测蛋白—凝聚体关联的机器学习工具；这类工具把本库当正例来源，正好说明它的强项是“可信正例”，弱项是“完整标签”。
7.5 它为何能持续：策展的复利
它没有订阅费，也没有大型联盟背书，却按季度更新了三年多。原因不神秘：每一条被审核的记录都会降低下一次策展的成本。术语本体让检索越来越准，编号体系让跨库连接越来越顺，社区提交让增量不必全由内部团队承担。策展是一种复利生意，前期慢，后期每新增一条的边际成本下降。
另一个支撑是生态位。凝聚体研究需要一个中立的名称与证据登记处，否则每个实验室都用自己的叫法。只要这个需求在，CD-CODE 就有存在理由；而只要它继续按季度发布，引用它的人就会继续提供新记录。这是一个正反馈，不保证永远成立，但目前仍在运转。
§8 生态位与历史
8.1 从两百多到八百多：一条扩展曲线
2023 年首版时，官方口径是 244 个凝聚体、九千八百余个蛋白、49 个物种。三年后，凝聚体增至 815，蛋白增至一万一千五百余，物种覆盖按官方统计接口为 117 个蛋白物种。增长不是线性的：2025 年下半年因为模型扩展出现跳变，之后回到季度增量。
这条曲线说明两件事。第一，凝聚体研究的文献产出仍在增长，数据库有东西可收。第二，策展人力是瓶颈，季度增量只有十几到几十个凝聚体，不可能靠堆人追上文献增速。所以它永远是一个抽样，而不是全集。
8.2 三个口径：关于页、发布页与论文
同一份数据在不同位置给出不同数字，这不是错误，而是时点差。把它们并列，能看出引用时该怎么写。
| 来源 | 对应版本 | 凝聚体 | 蛋白 | 其他 |
|---|---|---|---|---|
| 关于页正文 | 静态措辞 | “七百余” | “一万余” | 未提化合物 |
| 2.0 版论文 | 2.0 版 | 782 | 一万零三百余 | 107 个物种、236 个 c-mod、102 条凝聚体病 |
| 2.0 版发布页 | 2.0 版 | 782 | 一万零三百余 | 236 个 c-mod、101 条凝聚体病 |
| 2.4 版发布页 | 2.4 版 | 815 | 一万一千五百余 | 409 个 c-mod、133 条凝聚体病 |
关于页的“七百余、一万余”是安全措辞，不会过期；发布页给精确值，但每季度变；论文给的是截稿时的快照。写论文引用时，最稳的写法是“CD-CODE 2.4 版（2026 年 10 月）收录 815 个凝聚体”，把版本与日期一起给出，而不是只写数据库名。
8.3 生态位：名称登记处，不是数据仓库
在凝聚体研究的工具链里，它占据的是“名称与证据登记”这一格。上游是文献，下游是预测工具、知识图谱与药物筛选。它不做序列，不做结构，不做表达，也不做互作；这些都由邻居负责。
这条链的分工可以用一句话记住：PubMed 提供文献，UniProt 提供身份，PDB 与 AlphaFold 提供结构，HPA 提供表达与定位，ChEMBL 与 PubChem 提供化合物，DO 提供疾病分类；CD-CODE 只做最后一件事——把“谁在哪个结构里、证据是什么”登记下来，并指向上述来源。
这个位置决定了它的不可替代性有限但明确：任何人都可以重建一个凝聚体列表，但很难重建“每条关系都带证据类型与 PMID”的版本。后者需要人力，而人力是最难复制的部分。
8.4 谁在用它，用来做什么
使用者可以分成六类：细胞生物学家查已知组分、找研究空白；药物化学家找已报道的调节剂；知识图谱工程师取三元组；机器学习研究者取正例与弱监督种子；科学编辑与综述作者核对名称与规模；数据库互操作项目做交叉引用。六类人要的字段不同，取数路径也不同，别用同一套导出应付所有人。
§9 使用指引
9.1 三种角色的路径
| 角色 | 第一周做什么 | 不要做什么 |
|---|---|---|
| 生物学研究者 | 用网页查目标凝聚体，读三条高星证据的原文 | 不要用总数推断覆盖度 |
| 数据工程师 | 拉一页 API 看字段，再写分页与入库 | 不要用名称当主键 |
| 药物发现团队 | 从 c-mod 表筛已批准化合物，回连 ChEMBL 活性 | 不要把审批状态当疗效证据 |
| 策展贡献者 | 注册账号，按模板提交一条带 PMID 的新证据 | 不要提交无原文支撑的推断 |
9.2 一条最短的可用流程
目标：拿到“人类、四星以上”的凝聚体—蛋白关系，并附上蛋白名。整条流程只用公开接口与命令行工具。
#-- 取人类的高置信凝聚体，再逐条取成员（示例取前 5 个）
curl -s "https://cd-code.org/api/condensates" \
| jq -r '.data[] | select(.species_name=="Homo sapiens" and .confidence_score>=4) | .uid' \
| head -5 > uids.txt
while read -r uid; do
curl -s "https://cd-code.org/api/condensates/${uid}/proteins" \
| jq -r --arg u "$uid" '.data[] | [$u, .protein.uniprot_id, .protein.gene_name, .confidence_score] | @tsv'
done < uids.txt
第二段走的是成员端点 /api/condensates/{uid}/proteins，返回结构与列表端点相同，外层是 count、current_page、data、pages，data 里每条再包一层 protein 对象。写成 .protein.uniprot_id 而不是 .uniprot_id，是因为成员记录把蛋白信息放在嵌套对象里，这一点与 /api/proteins 的扁平结构不同。
#-- 校验：统计每个凝聚体的成员数，确认没有空数组
while read -r uid; do
n=$(curl -s "https://cd-code.org/api/condensates/${uid}/proteins" | jq '.count')
printf "%s\t%s\n" "$uid" "$n"
done < uids.txt
9.3 引用方式
引用分两种：引用数据库本身，引用它背后的论文。前者用于说明数据来源，后者用于说明方法学。
Kuznetsova K, Scheremetjew M, Yin J, et al.
CD-CODE 2.0: an enhanced condensate knowledgebase integrating
pathobiology, condensate modulating drugs, and host-pathogen
interactions. Nucleic Acids Res. 2026;54(D1):D375-D382.
doi:10.1093/nar/gkaf1104
Rostam N, Ghosh S, Chow CFW, et al.
CD-CODE: crowdsourcing condensate database and encyclopedia.
Nat Methods. 2023;20(5):673-676.
doi:10.1038/s41592-023-01831-0
数据版本也要写。推荐格式：“CD-CODE v2.4（2026-10-20 发布），访问于 2026-10-28”。只写网址不写版本，半年后别人无法复现你的计数。
§10 AI 使用声明
| 项目 | 声明 |
|---|---|
| 数据性质 | 文献策展的知识库，不含患者数据、影像或序列 |
| 标注来源 | 人工阅读原文后抽取；AI 工具辅助筛选与初抽，结果经维护者复核 |
| 证据粒度 | 关系级，带证据类型、星级与 PMID |
| 适用任务 | 知识图谱构建、正例集合、候选生成、弱监督 |
| 不适用任务 | 二分类完整标签、临床预测、疗效论证 |
| 许可约束 | CC BY-NC 4.0，商业使用需授权 |
| 版本要求 | 引用与复现须写明版本号与访问日期 |
| 已知风险 | 缺失不等于否证；名称与编号会变动 |
常见误读（避坑清单）
| 说法 | 实际 | 证据 |
|---|---|---|
| 它是 PhysioNet 上的数据集 | 不在 PhysioNet，托管于 cd-code.org | PhysioNet 该路径返回 404，站内检索 0 结果 |
| 它收录患者队列 | 只收文献中的凝聚体与关联 | 关于页与论文均无受试者描述 |
| 一万一千余蛋白就是全部人类蛋白 | 跨 117 个物种，人类仅四千余 | 官方统计接口按物种分列 |
| 星级是模型置信度 | 是证据类型的五级代理 | 关于页给出五档定义 |
| 没收录就说明不存在 | 可能是未研究、未录入或确实不存在 | 关于页“Limitations”明写三种可能 |
| 可以直接做二分类负例 | 库内没有否证记录 | 官方说明只收实验验证关系，未提供阴性记录 |
| 化合物审批状态等于疗效 | 只是 ChEMBL 的审批标记 | 论文说明审批状态转自 ChEMBL |
| 凝聚体病是临床诊断 | 是实验模型中的关联表型 | 关于页定义要求细胞、动物或临床模型证据 |
| 各页面数字应完全一致 | 三个口径分属不同时点 | 关于页、发布页、论文并列可见 |
| 它是 UniProt 的替代 | 只复用编号，不含序列 | 蛋白表只给 UniProt 与 Ensembl 编号 |
FAQ
Q1：CD-CODE 和 PhysioNet 是什么关系？
没有关系。它托管在 cd-code.org，由德累斯顿的 MPI-CBG 与 CSBD 维护。PhysioNet 的 cd-code 路径返回 404，站内检索也没有同名项目；把两者混在一起，通常是因为都出现在生物医学数据清单里。
Q2：它收录的是患者数据吗？
不是。全部记录来自公开文献，对象是凝聚体、蛋白、化合物与疾病关联，没有受试者、病历、影像或测序个体。所谓凝聚体病是疾病与凝聚体异常的关联描述，不是患者队列。
Q3：能不能直接拿来做蛋白—凝聚体二分类？
只能取正例。库里没有经过确认的负例，未出现的蛋白可能是没研究过。直接把其余蛋白当负例，模型学到的是研究热度而不是生物学。较稳妥的做法是只在有实验否证的对象上构造负例，或采用正例—未标注学习。
Q4：商业项目可以用吗？
默认不行。站点页脚与论文都写明 CC BY-NC 4.0，禁止商业性使用。企业内训模型、把数据并入商业产品之前需要向维护团队申请授权。另需注意 API 文档页标注的是 CC BY-SA 4.0，两个口径不一致，正式使用前应书面确认。
Q5：为什么不同页面的蛋白数对不上？
因为分属不同时点。关于页仍写“七百余凝聚体、一万余蛋白”的旧措辞，发布页给的是 2.4 版的 815 与一万一千五百余，论文给的是 2.0 版的 782 与一万零三百余。引用时写明版本与日期，不要跨页混用。
Q6：星级是怎么算的？
蛋白属于凝聚体的星级按证据类型定：1 星只有文献标注，2 星高通量，3 星体外，4 星活细胞，5 星体内。凝聚体的星级取成员蛋白星级的中位数。它衡量的是证据强度，不是研究完整度。
Q7：为什么没有负例？
因为文献很少报告“某蛋白不属于某凝聚体”。阴性结果难以发表，策展人也没有材料可抽。官方明确不收录预测，因此负例只能由使用者另行构造。这是这份数据作为机器学习标签集时最大的结构性缺口。
Q8：c-mod 是什么？
凝聚体调节化合物，包括小分子、肽与寡核苷酸。按作用方式分四类：诱导形成、促进溶解、改变定位、改变形态。每条记录连到靶凝聚体、作用类别、审批状态，以及 PubChem 与 ChEMBL 的结构编号。
Q9：凝聚体病能当临床诊断依据吗？
不能。它是“凝聚体异常与疾病相关”的实验证据摘要，来源可以是细胞、动物或临床模型，但没有患者数、分期与结局。它适合做机制假设与靶点线索，不适合做诊断或预后。
Q10：它能替代 UniProt 吗？
不能。它只给 UniProt 编号与基因名，不含序列、结构域、功能描述与变异。正确用法是把 UniProt 当身份与序列源，把 CD-CODE 当“参与哪个无膜结构”的场景源，两者用编号连接。
Q11：怎么引用才算规范？
引用论文说明方法学，引用数据库说明数据来源，并写明版本与访问日期。例如“CD-CODE v2.4（2026-10-20），访问于 2026-10-28”。只写网址不写版本，别人无法复现你的计数。
Q12：数据多久更新一次？
约每季度一个数据版本。2025 年 12 月、2026 年 3 月、6 月、10 月各有一次。网站功能更新不跟数据版本同步，API v2 与网站 2.0 是 2025 年 11 月上线，晚于数据 2.0 版。
术语表
| 术语 | 英文 | 含义 |
|---|---|---|
| 生物分子凝聚体 | biomolecular condensate | 无膜、靠多价弱相互作用富集分子的细胞结构 |
| 液液相分离 | liquid-liquid phase separation | 均相溶液分成两相、形成液滴的过程 |
| 凝聚体病 | condensatopathy | 与疾病相关的凝聚体异常表型 |
| 调节化合物 | c-mod | 改变凝聚体性质的小分子、肽或核酸 |
| 驱动蛋白 | driver | 能诱导形成或维持凝聚体完整性的蛋白 |
| 成员蛋白 | member | 出现在凝聚体中但角色未知的蛋白 |
| 标记蛋白 | marker | 用于定义与标记某凝聚体的蛋白 |
| 调控蛋白 | regulator | 影响凝聚体形成或性质的蛋白 |
| 客户蛋白 | client | 被招募进凝聚体但不驱动形成的蛋白 |
| 星 | confidence score | 1–5 级的证据强度标记 |
| 感染性凝聚体 | infectious condensate | 病原感染宿主后形成的凝聚体 |
| 合成凝聚体 | synthetic condensate | 体外实验中形成的凝聚体 |
| 包涵体 | inclusion body | 一类常以同名出现的聚集结构 |
| 病毒质 | viroplasm | 病毒复制时形成的凝聚体样结构 |
| 应激颗粒 | stress granule | 应激条件下形成的 mRNA—蛋白聚集体 |
| 核仁 | nucleolus | 核糖体合成相关的无膜核内结构 |
| P 小体 | P-body | 胞质中参与 mRNA 降解的结构 |
| 多价相互作用 | multivalency | 多个弱结合位点协同形成稳定结合 |
| 内在无序区 | IDR | 缺乏固定结构、常驱动相分离的蛋白区段 |
| 荧光漂白恢复 | FRAP | 测分子在凝聚体内交换速度的方法 |
| 疾病本体 | DO / DOID | 标准化疾病分类与编号体系 |
| 登录号 | accession | 数据库中的唯一标识 |
| 众包策展 | crowdsourcing | 社区提交、维护者审核的建库方式 |
| 快照 | snapshot | 某一版本打包的完整数据副本 |
附录 A：核心数字核对表
| 项 | 值 | 来源 | 来源层级 |
|---|---|---|---|
| 凝聚体数（2.4 版） | 815 | 发布页 | 官方页面 |
| 蛋白数（2.4 版） | 11,502 | 发布页 | 官方页面 |
| 关系数（2.4 版） | 15,091 | 发布页 | 官方页面 |
| 化合物数（2.4 版） | 409 | 发布页 | 官方页面 |
| 凝聚体病数（2.4 版） | 133 | 发布页 | 官方页面 |
| 凝聚体数（2.0 版） | 782 | 发布页与论文 | 官方页面 + 论文 |
| 蛋白数（2.0 版） | 10,340 | 发布页与论文 | 官方页面 + 论文 |
| 化合物数（2.0 版） | 236 | 发布页与论文 | 官方页面 + 论文 |
| 凝聚体病数（2.0 版） | 102（论文）/ 101（发布页） | 两处并列 | 两个口径 |
| 物种数（2.0 版） | 107 | 论文 | 论文摘要/正文 |
| 蛋白物种数（当前） | 117 | 统计接口 | 官方 API |
| 凝聚体物种数（当前） | 80 | 统计接口 | 官方 API |
| 首版凝聚体数 | 244 | 机构新闻稿 | 机构新闻 |
| 首版蛋白数 | 9,861 | 机构新闻稿 | 机构新闻 |
| 首版物种数 | 49 | 机构新闻稿 | 机构新闻 |
| 感染性凝聚体（2.0 版） | 29 | 论文 | 论文正文 |
| 多物种凝聚体（2.0 版） | 52 / 124 | 论文 | 论文正文 |
| 人类蛋白数 | 4,509 | 统计接口 | 官方 API |
| 人类凝聚体数 | 349 | 统计接口 | 官方 API |
附录 B：数字的来源分层
- 官方页面：发布页、关于页、API 统计接口直接给出，对应附录 A 的官方页面行。
- 论文：经同行评议的正文或摘要，对应附录 A 的论文行。
- 机构新闻：研究机构发布的新闻稿，非同行评议，仅用于首版的三个数字。
- 未核实：官方未公布、本文不采用，包括数据包体积、API 速率限制与审核通过率。
附录 C：完整参考文献
- Kuznetsova K, Scheremetjew M, Yin J, et al. CD-CODE 2.0: an enhanced condensate knowledgebase integrating pathobiology, condensate modulating drugs, and host-pathogen interactions. Nucleic Acids Res. 2026;54(D1):D375–D382. doi:10.1093/nar/gkaf1104. PMID: 41207295.
- Rostam N, Ghosh S, Chow CFW, et al. CD-CODE: crowdsourcing condensate database and encyclopedia. Nat Methods. 2023;20(5):673–676. doi:10.1038/s41592-023-01831-0. PMID: 37024650.
- CD-CODE 数据发布页. https://cd-code.org/release（访问于 2026-10-28）.
- CD-CODE 关于页与局限性说明. https://cd-code.org/about（访问于 2026-10-28）.
- CD-CODE REST API 文档. https://wiki.cd-code.org/en/api-docs-v2（访问于 2026-10-28）.
- Center for Systems Biology Dresden. CD-CODE – Database and Encyclopedia for membraneless liquid droplets. 机构新闻稿.
附录 D：任务代码
#-- 一键拉取 2.4 版三类实体，并统计行数
set -e
for kind in condensates proteins c-mods condensatopathies; do
curl -s "https://cd-code.org/api/${kind}" -o "${kind}_p1.json"
jq -r '"\(.count)\t\(.pages)\t\(.data | length)"' "${kind}_p1.json" \
| awk -v k="$kind" '{print k"\t"$0}'
done
输出的三列分别是总数、总页数、当前页行数。若总数与页数乘以页大小不一致，说明最后一页未满，属正常。
附录 E：如果只记五件事
- 它是凝聚体知识库，托管在 cd-code.org，与 PhysioNet 无关。
- 2.4 版有 815 个凝聚体、一万一千五百余个蛋白、一万五千余条带证据的关系。
- 每条关系有证据类型与 1–5 星，星级是证据强度而非模型置信度。
- 只收实验验证，不收录预测，也没有负例；缺失不等于不存在。
- 许可是 CC BY-NC 4.0，商业使用需授权，引用要写版本与日期。
编辑说明
本篇的事实核对以 2026 年 10 月 28 日访问的官方页面为准，规模数字取自 2.4 版发布页与公开统计接口；历史数字取自 2.0 版论文与 2023 年机构新闻稿。凡官方未公布的项目（数据包体积、API 速率限制、审核通过率、单条描述文本覆盖率），正文标注为未公布，未作推算。关于页、发布页与论文之间的计数差异按原样并列，未替官方裁定。许可条款存在 CC BY-NC 4.0 与 CC BY-SA 4.0 两个表述，已在正文与 FAQ 中同时标出。
相关数据集导航
以下为站内 AI-Ready 数据集百科中与本词条共享多个主题标签的相关数据集，按相关度降序排列：
- ecod — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学 / 知识图谱
- alphafold — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学
- string — 共享标签：基因组学与多组学 / 蛋白质组学 / 知识图谱
- disgenet — 共享标签：基因组学与多组学 / 药物发现与化学 / 知识图谱
- open-targets — 共享标签：基因组学与多组学 / 药物发现与化学 / 知识图谱
- alphafold — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学
- omnipath — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学 / 知识图谱
- phosphositeplus — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学 / 知识图谱
- pdb — 共享标签：基因组学与多组学 / 蛋白质组学 / 药物发现与化学
- gene-ontology — 共享标签：基因组学与多组学 / 蛋白质组学 / 知识图谱
导航说明：本章节由全站统一标签体系自动计算生成（标签重合度算法），双向可达；点击链接可跳转至对应数据集词条。
