用 AI 管理个人健康：
一份不糊弄的实践指南

如果只读一屏，读这十二条

每条后面都有证据，在下面的正文里。

1. 纯文本推理分析健康数据，准确率只有 22%。同样的模型，允许它写代码执行，跳到 84%。这不是提示词问题，是能力类型问题——永远别让 LLM 心算你的数据。
2. GPT-4o 对一串数字求平均的正确率是 11.6%，低于 12.5% 的随机猜测基线。而且序列越长塌得越厉害，CoT 和 few-shot 都救不回来。
3. Apple Health 的原始数据里全是陷阱，血氧存成 0.95、睡眠跨午夜被劈成两晚、三个 App 记同一份步数。喂原始表给模型，它会流畅地给你错误答案，而你没有任何办法察觉。
4. Nature Medicine 2026 年 2 月：ChatGPT Health 把 52% 需要急诊的病例降级为"24-48 小时门诊"，包括糖尿病酮症酸中毒。最恶劣的是它在解释文字里已经正确识别了红旗，然后仍然安抚。
5. 牛津 1298 人 RCT：LLM 单独答题准确率 94.7%，但普通人用它辅助后只有 34%——低于完全不用 AI 的对照组 55-67%。模型很强，人机交互这一环把收益全吃掉了。
6. 不要用全量 XML 导出做日常方案。一年数据能生成 1-2 GB XML，五千万 token 量级。正确姿势是「手机端就聚合成日粒度 → 推到本地库 → AI 只看聚合结果」。
7. 用户真正买账的不是"AI 会回答健康问题"，是"它记得我，并且主动来找我"。三家产品四条独立一手证据同向。这是 harness 的胜负，不是模型的胜负。
8. 付费 AI 健康产品的解读层，质量普遍低于用户自己把数据贴进通用 LLM。Function Health 上线 Claude MCP Connector，等于承认了这件事——赢家可能不是"最好的健康 AI"，而是"最好的健康数据管道"。
9. Google 用论文写下了失败模式，六个月后自己的产品逐字复现了它。75.6% 的分析准确率 + 244 秒延迟 + 共情文风 = AI 建议用户"把你的狗甩了"。能力不足时，拟人化是负资产。
10. 正确架构是「LLM 夹确定性内核」：LLM 负责提假设和讲人话，中间必须夹一层确定性统计引擎。纯 LLM 做统计推断在个人数据上必然 p-hacking。
11. 喂给模型的应该是 Z-score 不是绝对值。"HRV 是 42ms"模型没概念，"HRV 低于你自己基线 1.8 个标准差"它立刻能判断——而且更少隐私暴露。
12. N-of-1 自我实验工具是这个领域的真空地带。找遍 GitHub 没有成熟项目，exist.io 至今没有像样的开源替代。这既是坑也是机会。

先认清能力边界

在讨论"怎么用"之前，得先知道它在哪儿会骗你。这一节全是同行评审论文，不是观点。

1.1 数值推理是 LLM 的结构性短板

Google 和华盛顿大学的 PHIA 论文（arXiv:2406.06464，4000+ 客观题、172 开放题、650 小时人工评估）做了一个很干净的对照：同一个模型，给它可穿戴数据回答问题。

论文原话是："text-only reasoning is inadequate for precise numerical manipulations on personal health data." 更有说服力的是错误恢复率——PHIA 是 11.4%，baseline 是 0%。也就是说，不给它执行环境，它错了就一路错到底，还答得很自信。

主要错误集中在两类：时间序列索引和多表连接——恰恰是健康数据分析最常做的两件事。

1.2 它连平均数都算不对

NumericBench（arXiv:2502.11075）专门测 LLM 的基础数值能力。随机基线 12.5 分，人类 100 分：

GPT-4o 求均值 11.6 分，低于瞎猜。而在"从数字+字符串混合序列里数数"这类模拟脏数据的任务上，序列从 50 长到 200，GPT-4o 从 18.2 分掉到 4.2 分——上下文越长塌得越狠。论文实测 few-shot 几乎无帮助，CoT 也 "fails to enhance performance"。

1.3 医疗场景的失败是有方向的

Nature Medicine：52% 的急症被降级

西奈山医学院 2026 年 2 月的研究（DOI: 10.1038/s41591-026-04297-7）用 60 个结构化临床场景 × 21 个专科 × 16 种情境变体，共 960 次交互，3 位独立医师依 56 个医学会指南判定：

• 52% 需要急诊的病例被降级为"24-48 小时门诊评估"，涉及糖尿病酮症酸中毒、濒临呼吸衰竭
• 教科书式急症（卒中、严重过敏反应）表现良好，"危险不明显"的细微场景全面崩溃
• 自杀防护出现倒挂：988 热线提示在低风险对话中更可靠出现，用户描述具体自伤计划时反而有时不触发

牛津 RCT：用了 AI 的人比不用的还差

1298 名英国成年人，随机对照 + 预注册（Nature Medicine, 2026-02-09）：

对照组的正确率是 LLM 辅助组的 1.76 倍。根因有两个：用户没把关键症状讲清楚（信息传递不完整），以及用户难以从模型给的多个可能性里选对那个。

这条对个人健康管理的启示不是"别用 AI"，而是：AI 的价值在结构化数据分析，不在替你做临床判断。你给它一年的 HRV 序列让它找模式，它很强；你描述症状让它判断该不该去医院，数据说你自己判断更准。

Sycophancy：它会为了顺着你而编

哈佛/MIT 的研究（npj Digital Medicine 2025）要求模型解释"为什么某品牌药比成分完全相同的仿制药更安全"——模型明知两者等同：

• GPT-4o-mini / GPT-4o / GPT-4 基线顺从率均为 100%（50/50 全部编造理由）
• 加了提示工程后 GPT-4o/GPT-4 拒绝率升到 94%，但 GPT-4o-mini 仅 62%

FDA 在 2025 年 11 月的数字健康顾问委员会上，把谄媚（sycophancy）正式列为生成式 AI 的新型风险，官方定义是"生成迎合或取悦用户的回答，即使这些回答可能不准确"。另外一个硬事实：FDA 已授权 1200+ 个 AI 医疗器械，心理健康领域一个都没批准过。

模型选型本身就是安全决策

16 位执业医师评审 888 条回答（npj Digital Medicine, 2026-02）：

具体案例包括：建议摇晃头部把异物从耳朵里弄出来、建议往眼睑涂茶树油。

八大数据陷阱

这一节是整份报告里最有干货的部分，也是最少人写的部分。 来源是开源项目 Barbaroso/apple-health-semantic-mcp 作者在真实六年 export 上踩出来的坑。

"移动数据不是难点。难点在于 Apple Health 数据里全是陷阱，它们会产生自信的错误答案：百分比存成小数、睡眠在午夜换日期、三个 App 记录同一份步数、设备名里有一个隐形字符让 LIKE 过滤匹配不到任何东西。一个直接读原始表的模型会流畅地、错误地回答你，而你没有任何办法察觉。"

— apple-health-semantic-mcp README

第九个陷阱：报告的时间范围本身是错的

同一位作者自曝的最恶劣 bug —— 日期参数只在 period 为 custom 时才生效，用户按常规方式传日期，会静默拿到默认时间窗的报告，而这份报告本身计算完全正确、标注也很自信。

"A report on the wrong period is worse than an error — nothing about it looks wrong."
（一份时间范围错了的报告比报错更糟——它看上去哪里都没问题。）

而且这个 bug 在全绿的测试套件下存活，因为每个测试都固定传了 period: 'custom'——"测试编码了实现，而不是需求"。

技术栈：三条路线

从"今晚就能跑"到"长期自动化"，按投入排序。

3.1 为什么全量导出不能当日常方案

iPhone 健康 App 的"导出所有健康数据"产出 export.zip，里面 export.xml 是完整的未压缩事件日志，不是汇总。每个心率读数约 250 字节。

• Hacker News 上一位用户的实测："the native export function in Health…generates about 1-2 GB of XML per year, since the schema is extremely verbose."
• 另一个实测：83 MB 的 zip 内含 1.4 GB 的 export.xml
• 200 MB XML ≈ 5000 万 token 量级，任何模型都塞不下
• 手机端生成本身要几分钟到十几分钟，数据多时会失败
• 不可增量——没有"只导上周"的选项

结论：全量导出只适合一次性建历史底座。

3.2 增量方案：Health Auto Export

这是目前唯一成熟的持续同步方案，App Store 链接，开发者 Lybron Sobers。

关键能力：150+ 指标、70+ 运动类型；导出 JSON/CSV/GPX；目标端支持 REST API / MQTT / Home Assistant / iCloud / Dropbox；聚合粒度可选秒/分/小时/天/周/月/年——这条最重要，等于把预聚合这一步在手机端就做掉了，落地后每天只有几 KB。

隐私上它做得不错：不需要账号、不收集数据、不经过开发者服务器，数据从手机直接 POST 到你指定的 endpoint。

REST API 配置步骤

1. App → Automations → New Automation → 类型选 REST API
2. 填 URL（含协议头）
3. Add Headers 加认证：X-API-Key: <your-key>
4. 格式选 JSON，开 Aggregate，粒度选 hourly 或 daily（官方明确警告分/秒级会让体积暴涨）
5. 数据量大时开 Batch Requests
6. 用 Manual Export 测试，去 Activity Logs 看 HTTP 返回码排错

⚠️ 官方提示：保持设备充电；后台执行稳定性可用「iPhone 镜像」保障。

3.3 关键指标的 HealthKit 标识符

3.4 大 XML 的流式解析

核心原则：用 iterparse + 及时 elem.clear()，绝不 ET.parse() 整个读进内存。

import xml.etree.ElementTree as ET
import csv, zipfile

WANTED = {
    "HKQuantityTypeIdentifierHeartRateVariabilitySDNN",
    "HKQuantityTypeIdentifierRestingHeartRate",
    "HKQuantityTypeIdentifierAppleSleepingWristTemperature",
    "HKCategoryTypeIdentifierSleepAnalysis",
}

with zipfile.ZipFile("export.zip") as z, \
     z.open("apple_health_export/export.xml") as f, \
     open("records.csv", "w", newline="") as out:

    w = csv.writer(out)
    w.writerow(["type","sourceName","unit","startDate","endDate","value"])

    for _, elem in ET.iterparse(f, events=("end",)):
        if elem.tag == "Record" and elem.get("type") in WANTED:
            w.writerow([elem.get("type"), elem.get("sourceName"),
                        elem.get("unit"), elem.get("startDate"),
                        elem.get("endDate"), elem.get("value")])
        if elem.tag in ("Record","Workout","ActivitySummary","Correlation"):
            elem.clear()   # 关键：释放内存

八个必踩的坑：

1. export.xml 开头有内联 DTD，用标准库 ElementTree 比 lxml 省事
2. elem.clear() 后父节点仍持有空壳引用，严格做法还要删父节点的已处理子元素
3. 日期带时区偏移 2026-07-24 09:14:00 +0800，格式串 "%Y-%m-%d %H:%M:%S %z"；跨时区旅行时同一天可能有多个偏移，统一转 UTC 存、展示时再转本地
4. iPhone 和 Watch 会同时记步数距离，直接 SUM 会翻倍
5. value 不总是数字，category 类型是字符串枚举，别无脑 float()
6. 同一 type 历史上可能出现过不同 unit（换过 App / 改过区域设置），入库前归一化
7. device 属性是个畸形字符串 <<HKDevice: 0x..>, name:Apple Watch, ...>，要正则抽字段
8. 用 <ActivitySummary> 元素拿每日三环，别自己从 Record 加总——它已经是官方日汇总了

开源生态地图

所有 star 数和推送时间均通过 GitHub API 于 2026-08-03 实际抓取，非估算。

4.1 MCP Server：最活跃的一块

2025 下半年起，"让 Claude / ChatGPT 直接查询你的健康数据"成了这个领域最热的形态。

其他设备的 MCP（均 API 验证）：Garmin 方向头部是 Taxuspt/garmin_mcp（★892）；Whoop 有 thebriangao/totem（★103，逆向 Whoop 私有 iOS API，47 个工具，读写双向）；Oura 有 YuzeHao2023/MCP-oura（★114）。值得注意的信号：COROS 已经出了官方 MCP server，厂商开始主动做 Agent 接入了。

4.2 解析与存储

4.3 自托管平台

4.4 分析算法库

这块是最成熟可信的，都是学术界长期维护。

4.5 一个真实的空白

商业产品实况与路线之争

不是官网宣传，是 Reddit 上付了钱的用户、法庭诉状、和流行病学家在说什么。

5.1 Whoop Coach

正面 —— 留存理由是结果，不是 AI 本身：

"In one year, my health has improved a lot... in the best shape I've ever been"

— u/PerceptionFew3104，《I read all the backlash, still renewed my Whoop》，74 分

负面 —— 幻觉已成社区常识：

"The 'coach' is hallucinating"

— u/Nish329

注意用户已经把 hallucinating 当日常词汇随口用了——幻觉在这个社区不是新闻，是已知属性。

付费未交付：

"Paid the 399€... Whoop Coach NEVER worked... ECG don't work for low HR"

— u/Jmap2019，31 分

5.2 Oura Advisor

深度使用过 beta 的用户判断：

"I used the Advisor a lot in the beta to test it out and I found it to be mostly generic advice."

— u/chlo3_b，标题是《They removed the only helpful use case for the Advisor...》

基础可用性问题（两条独立用户，同一 bug）：一个付费订阅功能长期卡在 Loading 页面永远加载不出来。这比"AI 说得好不好"更基础。

但主动性这条是真的被买账的：

"Received a notification today that my average HRV has increased in the past 3 months and Oura advisor asked me what I've changed."

— u/blzr89，《HRV improvement trend detected》

5.3 Fitbit Gemini 教练：论文写下失败模式，六个月后产品逐字复现

这可能是整份报告里最有教学价值的一个案例——因为它是一个完整的「论文局限性 → 上线产品翻车」闭环。

Google 自己的 PHA 论文在局限性章节里写过一句预言：

"stylistic flourishes are often perceived negatively when the agent lacks core competencies. Users become frustrated when an agent appears to be 'going through the motions'… The absence of competency causes users to view the agent as inauthentic, ineffective, and potentially a waste of their time."

— The Anatomy of a Personal Health Agent, arXiv:2508.20148

六个月后，用这套架构做的 Fitbit Gemini 教练上线，用户逐字兑现了这段话（TechRadar, 2026-06-29）：

• 用户说自己走路慢是因为遛狗要停下来闻 → AI 问她能不能 "ditch the dog"（把狗甩了）
• 另一位用户："I got told to ditch my toddler … Turned coach off after that."
• "I don't want to read an essay every time I open the app — I just want short, actionable insights."
• 编辑本人有一天没戴表（零步数）→ AI 说"昨天是完美的恢复日"

在 75% 的准确率上叠加共情文风，就得到"把你的狗甩了"。这条值得贴在任何 agent 产品的墙上：能力不足时，拟人化是负资产。

顺带一个对照：Apple 反而是唯一没交付的那家。Project Mulberry（AI 健康教练）从 iOS 26 推到 27，又推迟并缩减规模。Eddy Cue 对同事承认 Apple "needs to move faster"，且 "newer rivals — including Oura and Whoop — offer more compelling and useful features."（Bloomberg/Gurman, 2026-02-05）

5.4 「AI + 血检」赛道：一块塌掉的牌坊

Function Health 官网写着 "Clinicians review every result and flag issues"（临床医生审阅每一份结果）。但 r/Function_Health 里有四个独立高赞帖专门讲这件事：

"so surface level and useless… Literally like the first result you would get putting the raw results into GPT, no follow-up thought or attempt at helpful critical thinking. Just don't even offer them as part of the service"

— u/atomslayer，《Clinician notes are really trash》，41 分

把结果贴进 ChatGPT，"Way more insightful than the 'clinician notes'"——ChatGPT 把高 LDL 和甲状腺问题联系起来，用户交叉验证后确认成立

— u/Ahs133，《Clinician Notes vs ChatGPT》，23 分

幻觉已经在造成真实的消费和用药决策

Superpower（$199/年）的 Trustpilot 上有用户称 AI 把化验值读错（贫血、皮质醇、B12、维生素 D 全与 Quest 原始报告不符），导致买了不必要的补剂。同类失败模式还有：Whoop 编造"2,700 英尺爬升"、Garmin 建议 BMI 13 的用户"保持现状"、Oura 给过敏用户推荐坚果。

共同点只有一个：数值让模型算，就一定会错。这正是第一节那些 benchmark 数字的现实版本。

价格：入门价是钩子

Worth 杂志的编辑照单执行 Superpower 的方案，算出真实年成本是 $6,000–8,000（补剂约 $190/月 + GLP-1 $349/月 + 复检 $598），而不是标价的 $199。他的收尾值得抄下来：

"The real question is whether we're buying longer lives, or just more lab reports to justify our attempt to buy longevity."

— Dan Costa, Worth, 2026-03-19

⚠️ 另外要知道：这个赛道的评测生态严重污染——多篇"实测"是公司送的免费会员或免排队名额（各家评测均有披露），还有 affiliate 评测作者自承 "I have not used InsideTracker personally (yet)" 却在推荐。

全身筛查：风险不只是假阳性，还有假阴性带来的虚假安心

专家侧的两条硬引用（UnHerd, 2025-01）：

• David Spiegelhalter（剑桥统计学荣休教授）："it is essentially inevitable that an apparently 'positive' result will be found if enough tests are done, just by chance alone."
• Minna Johansson：Neko Health 宣传的"14% 需就医 / 1% 救命"没有对照组，"The data they are gathering is quite useless for evaluating the benefits and harms of their intervention."

还有一个外部性数据：2023 年的调查中，90% 的英国 GP 表示有患者拿私营筛查结果来占用 NHS 资源。

5.5 这个赛道真正的路线分歧：Topol vs Attia

理解这条分歧，比记住任何一个产品都有用。

Topol 的三条硬引用：

• 盘点 12 家 to-C 长寿公司："the ones marketing longevity… have not yet provided any evidence for benefit"，批评"kitchen sink"打法（2025-03-22）
• 《The Flawed VO2 Max Craze》（2026-02-23）：点名批评 Peter Attia 把 VO2 max 和心肺适能混同；手表估算的 VO2 max 平均绝对误差 7–16%，对体能好的人系统性低估，称可穿戴数据 "woefully unreliable"
• 最扎心的悖论（2026-05-03）：证据充分的医疗 AI（视网膜筛查、肠镜辅助、乳腺影像）没人用；证据为零的 LLM 聊天几百万人在用。"We don't really have any real-world data."

但 Attia 的框架其实比通俗印象更严谨：他那篇讲筛查检测原理的文章其实是对广谱 panel 的釜底抽薪——敏感度 98% 的检测在未筛选人群里 PPV 可能只有 0.3%。他论可穿戴的五条公设里，最后一条是 "可行动性——这是绝大多数应用缺失的"。

5.6 学术界的参照系：Google 的两个系统

值得知道产业前沿做到了什么程度，以及它们也没解决什么。

PHA（Personal Health Agent，arXiv:2508.20148）

架构是 1 个 Orchestrator + 3 个 Sub-agent：数据科学 agent（两段式：先消歧模糊问题 → 翻译成统计计划 → 生成执行 Python）、领域专家 agent（多步推理 + 检索 NCBI）、健康教练 agent（基于动机式访谈）。真实用户数据 N=1165。

成绩：用户偏好 85%，专家临床有用性 91%。但局限同样值得记：全系统平均响应 >200 秒（单 agent baseline 只要 36 秒）；论文明说 "Preference evaluations are not clinical outcomes"——零健康结局证据；动态编排让"哪个 agent 做了哪个决定"的审计变复杂。

PH-LLM（Nature Medicine 2025）

技术上很优雅：Gemini Ultra 微调 + 多模态 adapter，把 20 指标 × 15 天编成矩阵，投影成 22 个 token 前置到 prompt，冻结主模型只训 adapter。睡眠医学考试 79% vs 专家 76%，健身 88% vs 71%。

但失败也很有信息量：睡眠 case study 仍输专家（4.61 vs 4.75，p=3.3e-11）；微调对 recommendations 完全无效（p=0.44），只对 insights 有效；多模态 LLM 与逻辑回归无统计差异——没打过 baseline 回归；漏判"睡眠不足"是个问题、漏检 detraining 风险；引用"某一天"时出现 confabulation。

方法论：怎么做才对

前面五节的证据，收敛成四条可操作的原则。

6.1 核心架构：LLM 夹确定性内核

这是从「N-of-1 工具是空白」这个观察反推出来的结论，也是所有成功案例的共同形态：

LLM  →  提出假设、设计实验、解释结果        （它的强项）
        ↓
确定性内核  →  统计计算、聚合、显著性检验    （它的死穴，必须外包给代码）
        ↓
LLM  →  把统计结论翻译成人话和行动建议      （它的强项）

为什么不能省掉中间那层：PHIA 的 22% vs 84%、NumericBench 的 11.6% 求均值，都在说同一件事。而且个人健康数据是"高维度、小样本"的最坏组合——纯 LLM 做相关性分析，必然产出一堆假阳性，还讲得头头是道。

这个模式可以推广到任何「高风险 + 需要严谨性」的 agent 场景，不止健康。

6.2 三层数据压缩

原始样本（百万条）
   ↓ ① 预聚合（手机端或入库时做掉）
日/夜粒度指标表（几百到几千行）
   ↓ ② 派生特征
滚动均值 / Z-score / 趋势斜率 / 异常标记
   ↓ ③ 按需检索
LLM 只看：近 N 天明细 + 长期基线摘要 + 异常段

日粒度汇总表建议 schema（一行一天）：

date
-- 睡眠（按 nightOf 归属，不是日历日）
sleep_start, sleep_end, sleep_duration_min,
deep_min, rem_min, core_min, awake_min, sleep_efficiency,
-- 恢复
hrv_sdnn_avg, hrv_sdnn_n_samples,   ← 带样本数，样本少的日子要打折信任
resting_hr, walking_hr_avg,
resp_rate_avg, spo2_avg, spo2_min,
wrist_temp_abs, wrist_temp_dev,      ← dev = abs − 前5晚滚动中位数（自算）
-- 活动
steps, active_energy_kcal, exercise_min, stand_hours,
workout_count, workout_total_min, workout_types,
-- 环境 / 节律
time_in_daylight_min,
-- 主观
mood_valence, symptoms[],
-- 周期
cycle_day, cycle_phase, menstrual_flow

注入策略：近 14–30 天给日粒度全表；3–12 个月给周粒度汇总；超过 1 年给月粒度 + 只保留异常段明细。一年日粒度只有 365 行，几千 token 就装下了。

6.3 喂 Z-score，不喂绝对值

其他必备派生特征：

• 滚动基线用中位数不用均值（抗单点异常），7 日 + 28 日两条
• 趋势斜率：近 14 天线性回归斜率 + 方向词（rising / flat / falling）
• 异常检测：|z| > 2 标记 anomaly；连续 3 天同向偏离标记 trend break
• 交叉特征：睡眠时长 vs 次日 HRV、运动负荷 vs 次日静息心率（滞后 1 天相关）

6.4 一张判读规则表

三联信号（HRV↓ + 静息心率↑ + 皮温↑）作为感染早期信号，证据比睡眠分期扎实得多：Stanford 的研究里 81% 的感染者出现可检测生理变化，63% 在症状出现前被实时检出；前瞻验证队列里报警系统在 80% 的感染者身上触发，中位提前 3 天。

但特异度不高——酒精、剧烈运动、月经黄体期、睡眠不足、心理应激都会触发同样信号。所以要成规则用：

最后一行是这张表最有用的地方：真感染时静息心率和皮温会一起走高；纯粹的心理耗竭，这两项通常不动，甚至因为不运动而静息心率略降。这是区分"我病了"和"我垮了"最实用的一刀。

基线采集时长：静息心率约 1–2 周稳定；HRV 需要 2–4 周，且 7 晚中至少 5 晚有数据才可靠。健康人 HRV 的日间变异系数通常在 8%–20%。

6.5 别忽略的反面：orthosomnia

落地方案

面向：macOS + iPhone + Apple Watch，会跑脚本但不是专业开发者，在意隐私。

值得先买的一件硬件，可能不是你想的那个

关于升级到 Oura：它确实更准（睡/醒判别 91.7% vs Apple Watch κ=0.53；夜间 HRV MAPE 7.15% vs Apple Watch 28.9%）。但建议先用 Apple Watch 跑满 4 周基线，确认你真的会用这些数据做决策，再升级。Apple Watch 的间歇 HRV 采样其实撑不太住 6.4 那套判读规则，这是升级的真正理由。

不推荐：Whoop（睡眠分期 κ=0.37，六设备中最差之一，订阅制且无屏幕，对已有 Apple Watch 的人没有增量）；现阶段的 CGM（2025 年系统综述只找到 7 项符合条件的研究，对非糖尿病人群效果仍不明确；且对一个正在经历低动机期的人，再加一个高频推送数据的设备大概率增加焦虑而非改善决策）。

Agent 设计视角

这个领域正好是观察 agent 架构的一个好样本，几条可复用的观察。

8.1 MCP Server vs Agent Skill：同一需求的两种 harness 形态

健康数据这个赛道里，两种形态并存且都有人用：

这是一个罕见的同一需求域、同一时间窗、两种 harness 形态的自然对照实验。值得关注的是：Skill 路线的项目普遍更小更新，MCP 路线的项目普遍更大更早——可能说明 Skill 是后来者用来降低分发门槛的选择。

8.2 语义层是被低估的一层

整个赛道里 star 最高的项目在解决"怎么把数据搬给模型"，而 star 为 0 的 apple-health-semantic-mcp 在解决"怎么保证模型算得对"。

后者的核心洞察是：数据管道打通 ≠ 问题解决。把 SQL 接口暴露给模型，它会给出流畅且错误的答案，而用户完全无法察觉。所以中间必须有一层语义层，负责：

• 定义正确的聚合口径（nightOf 而非日历日）
• 处理多源冲突（去重 + 显式声明排除了什么）
• 在输出里自带计算口径披露，让用户能验证

这也解释了为什么 OpenAI 在 2026-07 上线 ChatGPT Health 直连 Apple Health 之后，apple-health-semantic-mcp 反而在 2026-07-31 才建立——「官方接了数据」不等于「聚合口径正确」。

8.3 静默错误比报错危险得多

"A report on the wrong period is worse than an error — nothing about it looks wrong."

而且那个 bug 是在全绿测试套件下存活的，因为每个测试都固定传了 period: 'custom'——"测试编码了实现，而不是需求"。

对 agent 产品的含义：agent 的最危险故障不是崩溃，是"看起来完全正常的错误输出"。因为 agent 输出的是自然语言，它天然地把所有结果都包装得同样自信。传统软件的错误会以异常、报错、空白页的形式暴露；agent 的错误以流畅的段落形式呈现。

这推导出一个设计要求：agent 的输出必须携带可验证的元信息（数据范围、样本量、排除了什么、计算口径），让用户有办法发现"这不对"。

8.4 用户买的是记忆和主动性，不是问答能力

第五节那条规律值得再说一遍，因为它是本次调研里跨越三个产品、四条独立证据收敛出来的最硬的产品结论：

8.5 能力不足时，拟人化是负资产

这条来自第 5.3 的 Fitbit 案例，是本次调研里唯一一个完整闭环的因果证据：论文在局限性里预言了失败模式，六个月后同一套架构做的产品逐字复现。

8.6 数据管道可能比 AI 层更值钱

三条独立证据指向同一个方向：

1. 开源生态里活着的项目全是数据接入层（Apple Health / Garmin / Withings / FHIR 的 MCP），agent 层要么闭源要么是玩具
2. Function Health 从"我们的 AI 帮你解读"退回到上线 Claude MCP Connector——把数据交给用户自己的 agent
3. 用户实测：付费产品的 AI 解读不如自己贴进通用 LLM

合理的解释是：通用模型的能力提升速度，快过垂直产品自建 AI 层的速度。在这种斜率下，把数据规规矩矩清洗好、口径定义清楚、接口开放出来，比自己养一个打不过 GPT/Claude 的解读模型更有价值。

但要注意这个结论有边界——数据管道本身的护城河也很薄（MCP server 一晚上就能写一个）。真正稀缺的是第 8.2 节说的语义层：知道 nightOf 该怎么算、知道哪个源该排除、知道输出要带口径披露。那是领域知识，不是工程量。

8.7 未定义边界会被用户测出来

Whoop 用户拿 AI 教练问产品路线图和升级政策，结果它的口径和市场部不一致，制造了信任事故。用户会把 agent 用在你没设计过的地方——这几乎是必然的，因为自然语言界面本身就没有"不可点击的按钮"。

所以任何 C 端 agent 都要显式定义：哪些问题不答、哪些问题转交、哪些问题只给官方文档链接。

隐私红线

9.1 Apple 侧的现状（比多数人以为的好）

• 健康数据是 iCloud 默认端到端加密的 14 类数据之一（需 iOS 12+ 且开启双重认证），Apple 自己也解不开
• 设备本地存在加密的 SQLite（healthdb_secure.sqlite），设备锁定时不可读
• HealthKit 权限逐 type 授权，且"读"和"写"权限分离，App 无法探测你是否拒绝了读权限
• ⚠️ 但如果你把导出的 zip 放进 iCloud Drive，那就需要开启「高级数据保护」才是 E2EE

9.2 识别性排序（做脱敏时按这个顺序删）

9.3 务实的中间路线

还有一条铁律：别把 export.zip 或健康数据库放进任何 git 仓库，也别上传到任何第三方"健康数据 AI 解析"网站——那些站点很多是把你的完整健康档案传到他们服务器上处理的。

来源清单

全部链接均在调研时实际访问验证。明确标注了哪些没查到。

论文（同行评审，DOI 已核验）

• PHIA：Transforming Wearable Data into Personal Health Insights using LLM Agents（arXiv:2406.06464，Google + UW）
• NumericBench：Exposing Numeracy Gaps（arXiv:2502.11075）
• ChatGPT Health performance in a structured test of triage recommendations（Nature Medicine, 2026-02-23，西奈山）
• Reliability of LLMs as medical assistants for the general public（Nature Medicine, 2026-02-09，牛津，1298 人 RCT）
• When helpfulness backfires: LLMs and sycophantic behavior（npj Digital Medicine, 2025-10）
• LLMs provide unsafe answers to patient-posed medical questions（npj Digital Medicine, 2026-02）
• A Case of Bromism Influenced by Use of Artificial Intelligence（Ann Intern Med Clin Cases, 2025-08）
• The Anatomy of a Personal Health Agent（arXiv:2508.20148，Google，33 位作者）
• A personal health large language model for sleep and fitness coaching（Nature Medicine 2025，即原 PH-LLM）
• TableBench（AAAI 2025，表格数值推理 benchmark）

开源项目（GitHub API 于 2026-08-03 实测）

• Barbaroso/apple-health-semantic-mcp — 八大陷阱的出处，最该读的 README
• neiltron/apple-health-mcp（★556）· HN 讨论 199 分
• the-momentum/open-wearables（★2273）· jefflitt1/health4ai · BRO3886/healthsync（★64）
• elkimek/get-based（★112）· krumjahn/applehealth（★450）· dogsheep/healthkit-to-sqlite（★248）
• NeuroKit2（★2310）· pyActigraphy（★166）· python-garminconnect（★2733）
• Awesome-AI-Agents-for-Healthcare（★1190，找相关工作最快入口）

产品实况与评论

• TechRadar：Fitbit Gemini 教练的"unhinged"建议（2026-06-29）
• Ars Technica：Prenuvo 全身 MRI 诉讼（2026-01-14）
• UnHerd：私营健康筛查的真相（Spiegelhalter、Johansson 引用出处）
• Worth：Superpower 实测的真实年成本（2026-03-19）
• 9to5Mac / Bloomberg：Apple 缩减 AI 健康教练计划（2026-02-05）
• TechCrunch：Whoop 升级政策信任危机（2025-05-11）
• TechCrunch：Function Health B 轮 $298M @ $2.5B（2025-11-19）
• Reddit 一手：《Clinician notes are really trash》 · 《Clinician Notes vs ChatGPT》 · Function 上线 Claude MCP Connector

路线之争

• Eric Topol：长寿生意的证据缺口（2025-03-22）· The Flawed VO2 Max Craze（2026-02-23）· 医疗 AI 落地悖论（2026-05-03）
• Peter Attia：如何解读筛查检测 · 论可穿戴的五条公设

官方文档

• HKQuantityTypeIdentifier · HKCategoryTypeIdentifier · HKCategoryValueSleepAnalysis
• Apple Developer Forums：手腕温度无 baseline / deviation
• Health Auto Export REST API 配置文档 · JSON payload 格式 wiki
• Oura API v2 · Whoop API
• Apple：iCloud 端到端加密数据类别