BEST MINDS · NUTRITION DATA
中国版：营养 App 的开源数据底座
2026-01-23 · 中国用户 / 产品·工程 · 开源数据清单 + MVP 数据路线
先用开源跑通闭环：包装食品 OCR → 生鲜过渡 → 授权数据接入
这份中国版总结把“能立刻用的开源数据”与“你最终需要但可能要授权的权威数据”分开处理：先用 FDC + OFF + Wikidata/FoodOn + GB 28050 跑通记录与分析的闭环，再把 CFCT 等中国权威数据作为可插拔数据源接入。
中国
营养
开源数据
FoodData Central
Open Food Facts
GB 28050
Wikidata
FoodOn
ODbL
数据治理
要点（先做中国版）
- 现实：中国权威“食物成分表/DRIs”多数不是开源；条码产品库也多为商业授权。
- 开源可用底座：USDA FoodData Central（通用营养素） + Open Food Facts（部分中国包装食品） + Wikidata/FoodOn（中文名/分类/映射）。
- 中国 MVP 最稳：包装食品先做“营养标签 OCR + 人工校对”闭环；生鲜/原料先用 FDC 过渡，后续再接入授权的中国成分表。
- 合规关键：把每条数值的来源、版本、单位、换算（每 100g / 每份）做成一等公民；尤其注意 ODbL（Open Food Facts）与数据再分发方式。
中国版最大的“数据缺口”是什么？
缺口 1：权威数值数据的开放度
- 中国权威食物成分与 DRIs 多以书籍/付费数据库/有限授权形式发布，很难直接作为“开源数据底座”嵌入 App。
- 这不是技术问题，而是许可与可再分发的问题。
缺口 2：条码产品数据的可用性
- 中国市场的包装食品 SKU 极多，且信息更新快；商业条码库价值高但通常有授权与反爬限制。
- 开源条码库在中国覆盖不均，最稳的 MVP 方案往往是直接从包装营养标签提取数值。
结论：中国版先跑通“数据闭环”，再补齐“权威底座”。你需要的不是“一个完美数据库”，而是一套可以持续扩展的数据治理架构。
可用开源/开放数据（中国版优先级）
| 数据源 | 能提供什么 | 怎么用在中国版 | 许可/注意 |
|---|---|---|---|
| USDA FoodData Central (FDC) | 结构化营养素数值（多维：每 100g、来源、类别）；支持 API/批量下载 | 先做“生鲜/原料”的过渡底座；用 Wikidata/自建词典做中文名映射 | 美国政府数据通常可自由使用；仍建议保留来源字段与版本号 |
| Open Food Facts (OFF) | 条码产品：营养成分表、配料、过敏原、图片；API/导出 | 用于“扫码→命中→补全”；覆盖不足时回退到 OCR/手动录入 | ODbL：衍生数据库再分发义务需评估（尤其是本地缓存+二次发布） |
| Wikidata | 中文名称/别名、多语言、实体链接、部分分类 | 做“中文搜索词典/同义词/映射层”，把不同数据源连到同一食物概念 | CC0；注意实体质量参差，需人工校对与白名单 |
| FoodOn（食物本体） | 食物概念体系（分类/关系） | 做分类与跨库映射的骨架（尤其是“原料→食材类目→菜谱”） | 开源但需核对具体许可；建议只存 ID/映射，不复制大段文本 |
| GB 28050（营养标签标准） | 中国包装食品营养标签的字段口径（能量/蛋白质/脂肪/碳水/钠等）与 NRV% 计算逻辑 | 把“标签口径”变成 App 的默认 schema；支持 OCR 后自动计算 NRV% | 标准文本可能受版权；建议引用数值/口径并记录版本，避免复制整段原文 |
中国权威数据（通常不是开源，但你大概率最终需要）
- 中国食物成分表（CFCT）：如果你要做到“可信的中国本地食物营养”，几乎绕不开；更适合作为授权数据源插件接入，而不是硬塞进开源底座。
- 中国 DRIs / 膳食指南：用于目标与评价（达标/不足/上限）；同样需要核对授权与引用方式。
建议的数据架构（中国版可持续扩展）
中国版数据源对比（能用 vs. 必要但不一定开源）
中国版 MVP（3 个阶段）
Phase 1 · 2–4 周
包装食品：OCR 闭环
- 拍照 → OCR → 结构化（能量/蛋白质/脂肪/碳水/钠）
- 手动校对 → 保存为“我的食品”
- 用 GB 28050 口径计算 NRV%
Phase 2 · 1–2 个月
生鲜/原料：开源过渡底座
- 接入 FDC（批量/缓存）
- 建立“中文常见食物词典”映射（Wikidata 辅助）
- 把单位与口径统一到你自己的 schema
Phase 3 · 持续迭代
权威中国底座：授权接入
- 接入 CFCT/本地数据（授权/采购）
- 同一 schema 下做“来源优先级/置信度”
- 用 AB 测试验证体验提升（而不是假设）
数据治理（决定你能否扩展到“可信的中国版”）
- 一条数值必须可追溯：source（数据集）/sourceId（原始主键）/version（批次）/unit（单位）/basis（每 100g/每份/每 100ml）/method（测定/估算/标签）
- 把“映射”独立出来：food ↔ foodConcept（Wikidata/FoodOn） ↔ barcodeProduct ↔ recipeIngredient
- ODbL 先想清楚：你是否要分发离线数据库？是否会对 OFF 数据做清洗再发布？这些会影响合规路径。
- 质量闭环：用户纠错 + 版本回滚 + 对比多来源（同食物不同来源差异要能解释）
One Next Action
先定一个最小 schema（按 GB 28050：能量/蛋白质/脂肪/碳水/钠 + 每 100g/每份）并做出“拍照 OCR → 校对 → 保存 → 今日达标”的端到端闭环；同时在后端把 source/version/license 字段做成必填。
来源线索（你接下来可验证/拉取的关键词）
- USDA FoodData Central：
FoodData Central API/FDC bulk download/Foundation Foods - Open Food Facts：
Open Food Facts API/data export/ODbL - Wikidata：
SPARQL food/Chinese labels/CC0 - FoodOn：
FoodOn ontology/OBO Foundry/license - 中国营养标签标准：
GB 28050 预包装食品营养标签通则/NRV%
先把闭环跑起来，再把权威数据接进来。
Best Minds · China MVP First