从「答非所问」说起：健康数据孤岛问题
拿到一份体检报告，几个异常指标看不懂，想找医生聊。排队一小时，面诊三分钟。回家把去年报告翻出来对比，发现同一项指标两边的写法和单位都不一样。拍照扔给 AI，回答倒是流畅，但只停留在「这个指标偏高/偏低」的层面——它没法结合我手环里的睡眠心率、上一家医院的病历，给我一个综合的判断。
问题的根源不在 AI 答得不好，而在数据根本没有被组织起来。体检报告锁在医院系统里，穿戴设备数据躺在手表 App 里，病历本压在抽屉里——各是各的孤岛，AI 读不懂，也连不上。
最近在 GitHub 上看到一个刚开源的项目，正好在解这个问题：Mirobody（thetahealth/mirobody）。
它做的事情可以拆成三条链路：收集、标准化、问答。
链路一：收集——先解决数据从哪来
体检报告 PDF 直接拖进界面，几秒内指标被提取、入库、落盘。每条指标都能回溯到原文件的具体页，数据来源有迹可循。穿戴设备的数据同理，统一收进来。
这一步本身不复杂，复杂的是下一步。
链路二：标准化——整个引擎的核心
收集只是前提，关键是让不同来源的数据说「同一种语言」。
Mirobody 的做法是：
- 格式统一为 FHIR R4（医疗健康数据交换标准）；
- 指标名统一映射到 LOINC 编码（国际公认的检验指标标识标准）；
- 单位统一为 UCUM 写法（统一计量单位标准）。
举例：中、日、英、繁体报告里同一个指标的不同写法，落到 Mirobody 里映射到同一个 LOINC 编码，单位归一成 UCUM 标准写法。底层支撑是一张 44 万节点、59 万个来源 ID 的医学概念图谱。
值得注意的一个设计原则：没见过的词不硬猜，主动留空。遇到图谱里没有的指标，宁可空着不映射，也不给一个可能错误的编码。健康数据不同于一般文本数据，一个错误映射比没有映射更危险——它在后续问答里会被当成「已正确的标准数据」参与推理，错误会被放大。
链路三：问答——数据理顺了，AI 才答得有意义
标准化之后，AI 才能跨报告、跨设备做真正的查询。比如问一句「我这两年的糖化血红蛋白变化趋势」，AI 会去检索历史报告，画出趋势图，标注每条数据来源，并主动指出数据的局限性（比如某次检测机构不同、单位换算过等）。
这一步的效果取决于前两步的质量：接入的数据越全、映射越准，回答越可信。
部署：不是 PPT 产品，是真能跑
项目提供一键安装脚本，机器上有 Docker 就能跑。不想手动敲命令，也可以用终端 Agent（比如 Claude Code）发一句：
帮我完整部署这个项目 https://github.com/thetahealth/mirobody
部署完成后浏览器访问服务地址，用内置账号登录即可使用，自带演示数据。
关键配置在 .env 文件里：填入模型 API Key，支持 Google、OpenAI、OpenRouter、阿里云百炼 四家供应商。配置完重启 Docker 生效。
所有上传数据存储在本地——对健康数据这类强隐私数据，数据不出本机这一点值得强调。此外支持创建「关爱圈子」，邀请家人加入，各自管理自己的数据，可选择是否向家人共享。
配套项目：科学清洗 + 评测
团队还开源了两个配套仓库：
- mirobody-science：负责清洗多来源、多格式的科研数据集，保证下游数据质量；
- mirobody-eval：评测健康 AI 回答的可靠性。内置 HealthBench、ESL-Bench 等 6 个评测基准，加上团队自建的 3 个，在 Hugging Face 上近一个月各被下载 4000+ 次，同类数据集中下载量最高。
有一个细节说明他们在用评测反推架构决策：Mirobody 自己的「数据入库还是丢给 RAG」这个架构选型，是用 eval 实测了 13 种方法后定下来的（具体方法清单原文未提供）。
我的判断：价值不在模型，在标准化层
AI 健康赛道不缺模型，缺的是结构化的、可交叉引用的历史数据。连 ChatGPT 的健康类功能上线第一步都是先接电子病历和 Apple Health 数据——瓶颈从来不在模型，而在数据。
Mirobody 的三条链路里，收集和问答其实都有现成方案，标准化层才是真正的护城河：那个 44 万节点的概念图谱、FHIR R4 / LOINC / UCUM 的映射体系、「不认识就留空」的严谨原则，这些是需要在医疗领域长期积累的资产，不是靠堆参数能堆出来的。
如果这套标准化层被越来越多的开发者和机构采纳，它有可能成为健康数据互通的事实标准——类似早年 Markdown 之于纯文本，不是谁钦定的，是用的人多了，自然成为默认对接方式。
往远看，一个人从年轻时开始持续记录健康数据，几十年后 AI 看到的就是一条身体状态的完整时间线，可能从细微变化里提前发现趋势性风险。这等于每个都有了一个持续更新的「健康数字孪生」。这个方向说得通，但需要长期数据积累和医学界认可，目前还远没到验证阶段。
适用场景与边界
适用场景：
- 个人用来归集自己的体检报告、穿戴设备数据，做长期趋势跟踪（比表格直观，比散落各 App 有结构性）；
- 就诊时把趋势图拿给医生参考，减少现场翻报告的时间；
- 家庭场景：集中管理老人和孩子的健康数据，跨时间的指标变化一目了然。
不适用 / 需谨慎的场景：
- 诊断场景：项目做的是数据整理与查询，不替代医生诊断，也不该作为诊疗依据。原文未提供任何临床验证或医学认可信息；
- 数据完整性问题：留空策略保证了准确，但也意味着图谱覆盖不到的指标不会被处理。面向中文报告的覆盖度如何，原文未给出具体数据；
- 隐私边界：数据本地存储解决了服务端泄漏的一部分问题，但「分享给家人」之后的数据流向、本地数据的备份与设备丢失场景，原文未提供详细方案；
- 数据断点：穿戴设备数据目前能做到什么程度的自动接入（还是手动导出导入），原文描述有限，实际使用中可能存在体验断点。
参考：
- GitHub: https://github.com/thetahealth/mirobody
- mirobody-eval: https://github.com/thetahealth/mirobody-eval
- Hugging Face: https://huggingface.co/mirobody
- 论文: https://arxiv.org/abs/2604.02834