本文要点
- ChatGPT 从接收单次健康提问，扩展到读取用户主动连接的纵向健康数据。
- Health 开始面向美国成年登录用户滚动开放，并限定平台与方案范围。
- 连接数据获得专门的训练、广告与断开后删除承诺。
阅读辅助
先看数字、证据和来源，再读正文。
Health 在美国开始滚动开放，不是已经向所有美国用户全量上线。
2025-05-12 · OpenAI 发布 HealthBench，建立面向健康对话能力的评测背景，但不等于证明 Health 产品安全。
7 月 23 日这项发布最需要记住的动词是“开始”：OpenAI 开始滚动开放 Health in ChatGPT，并没有宣布美国用户已经全量可用。它把 ChatGPT 的健康用途从“用户在对话里描述症状或粘贴报告”，推进到“用户主动授权后读取纵向记录”，但地区、年龄、登录状态、终端、方案与产品入口都有清楚边界。
当前可确认的范围是美国、18 岁及以上、已登录 ChatGPT 的用户；终端是 Web 和 iOS；方案是 Free、Go、Plus、Pro。用户可以连接 Apple Health、受支持的美国医院系统医疗记录，以及公告列出的 One Medical 或 Function Health。Health 目前尚未在 Codex 中提供。
公开材料没有说明这次滚动开放已经覆盖多少人、需要多久完成、支持多少家医院，也没有发布真实世界中的错误率。OpenAI 给出的每周超过 3 亿人是向 ChatGPT 提出健康相关问题的人数，不是 Health 活跃用户；HealthBench 是既有评测背景，也不能替代对这项新产品的数据连接、长上下文总结和实际医疗风险评估。
对用户而言，直接收益是把药物、化验、就诊、睡眠和活动变化放进同一上下文，减少反复整理记录的成本。代价则是更复杂的授权与删除责任：撤销数据源连接、删除同步数据、删除已经进入聊天的内容是三件不同的事。医疗机构和监管者需要追问的不只是模型会不会回答，还包括它读了什么、保留多久、何时应停止回答并建议线下就医。
一次滚动开放，五层适用边界
官方公告中的状态词不能压缩成“Health 已在美国上线”。beginning to roll out 表示当天开始滚动开放，因此符合条件也不保证立即看到入口。OpenAI 的官方 X 同日同样使用 starting to roll out，与公告的状态一致。
| 原文状态或范围 | 忠实中文 | 需要保留的边界 |
|---|---|---|
| beginning to roll out | 开始滚动开放 | 不是全量可用，也没有公布完成日期 |
| logged-in users 18 and older in the U.S. | 美国 18 岁及以上已登录用户 | 地区、年龄和登录状态缺一不可 |
| on web and iOS | Web 与 iOS | 公告没有把 Android 列入当前范围 |
| Free, Go, Plus, and Pro | Free、Go、Plus、Pro | 不能省略为“所有 ChatGPT 方案” |
| not yet available in Codex | Codex 尚不可用 | not yet 是当前状态，不代表永久不支持 |
这五层边界决定了产品报道应如何写。美国用户不是同一时间获得入口；免费用户被列入范围，也不等于无登录用户可用；iOS 支持不能自然推导出 Android 已支持；ChatGPT 的四种消费方案被列出，也不能延伸到公告没有写明的企业方案。产品可见性应以账户中的实际入口为准。
连接能力同样有范围。OpenAI 写的是 Apple Health 与“受支持”的医疗记录，意味着医院系统覆盖并不天然完整。One Medical 与 Function Health 是公告列出的连接来源，但这不能证明所有记录字段、历史年份和附件都能同步。药物、化验、就诊、睡眠、活动等只是产品举例，真正可读内容仍取决于来源授权、结构化程度和兼容性。
数据怎样进入上下文，又怎样退出
Health 的机制变化在于跨对话使用。经用户许可，ChatGPT 可以调用连接在 Health 中的相关上下文，用来比较新旧检查结果、总结上次就诊后的变化，或讨论睡眠和活动之间的关系。专用 Health 入口则承担连接与管理信息、浏览记录和回看健康对话的“主页”角色。
OpenAI 对这部分数据给出了一项范围明确的承诺：已连接的医疗记录、Apple Health 信息，以及使用这些连接数据的对话，不用于训练 OpenAI 的基础模型，也不用于定向广告。这里的主语必须保留；承诺仅覆盖连接到 Health 的信息及使用这些信息的对话，不能扩大到所有 ChatGPT 对话、上传文件或产品数据。
数据退出不是单按钮完成。公告区分了来源同步数据与聊天记录中的信息：
| 用户动作 | OpenAI 公布的处理 | 仍需用户处理或外部验证的部分 |
|---|---|---|
| 撤销 Apple Health 或医疗记录授权 | 停止后续连接访问 | Apple 侧可在 Health 的应用权限中调整读写授权 |
| 断开某个数据来源 | 该来源同步的数据在 30 天内从 OpenAI 系统删除 | 公告未提供删除进度、备份口径或审计日志 |
| 数据已经进入某段聊天 | 不随数据源断开而自动从聊天中消失 | 用户需要删除相关对话，才能清除聊天里的信息 |
Apple 的官方用户指南提供了设备侧的另一半控制：用户可在 Health 的隐私设置中查看请求访问的应用或设备，并开启或关闭读写权限。这能说明授权可被用户调整，却不能代替 OpenAI 对服务端副本和聊天内容的删除承诺。两侧权限都处理，才接近完整退出。
30 天内也要按原文理解。它是断开后删除从该来源同步数据的期限，不是所有相关信息实时删除，更不是“断开即清空历史对话”。若某项化验结果已经被模型写入回答或保留在对话上下文，用户仍需删除相关聊天。对处理高敏感健康数据的产品而言，这种差异应在断开流程中直接提示，而不能只藏在帮助文本里。
“超过 70%”衡量的是入口分流
OpenAI 公布，早期获专用体验权限人群中，超过 70% 的健康相关对话发生在 Health 专用体验之外。这个数字揭示了产品设计动机：即使提供一个专用健康入口，用户仍会在普通对话中谈健康，因此系统希望在获得许可后跨对话调用相关 Health 上下文。
这个比例不能写成“超过 70% 的 ChatGPT 健康对话发生在 Health 外”。它的分母是早期获专用体验权限人群的健康相关对话，不是全体 ChatGPT 用户，也不是所有美国用户。公告没有公开早期人群人数、观察周期、纳入标准和对话分类方法，所以它适合解释为什么要支持跨对话上下文，不适合估算整体采用率。
更值得关注的是产品边界随之移动。专用入口原本能让用户凭界面判断“现在进入了健康场景”；跨对话调用则可能让 Health 数据出现在普通聊天中。便利性会提高，但用户需要更清楚的可见性：这次回答调用了哪一项记录、记录日期是什么、能否只授权某类数据、怎样让某段普通对话不再使用健康上下文。公告给出了“经许可使用”的原则，尚未给出这些细粒度交互的完整答案。
医疗安全不能从入口发布直接推出
OpenAI 称每周有超过 3 亿人向 ChatGPT 提出健康相关问题，并与全球数百名医生合作衡量和改进准确性、安全性、沟通、上下文意识、完整性与适当升级。这个规模解释了为何公司要把健康用途产品化，也放大了低概率错误的绝对影响。
但“能接入记录”和“能安全解释记录”是不同命题。纵向数据能帮助模型看到趋势，也会引入新的失败方式：同名检查项目可能单位不同，药物清单可能过期，跨医院记录可能重复，穿戴设备数据可能缺失，模型还可能把相关性写成因果关系。记录越丰富，回答看起来越有根据；如果来源日期、单位和缺失项没有显式呈现，用户反而更难发现错误。
HealthBench 能证明 OpenAI 已建立健康对话评测工作，不能证明 Health 在真实连接数据上的表现已经得到独立验证。基准测试通常在预先构造或整理的任务上评分，而产品需要处理持续更新、来源冲突、权限变化和高风险升级。此次公告没有给出 Health 专用的错误率、医生复核结果、不同人群表现或严重事件数据。
产品定位因此应保持克制：Health 用于支持用户理解信息和准备更充分的交流，不替代专业医疗照护。对于胸痛、呼吸困难、自伤风险、药物剂量调整等高风险问题，评估重点应放在能否识别紧急性、避免越界建议、清楚表达不确定性并及时升级到专业照护，回答流畅度并非核心安全指标。公告列出“适当升级”作为改进维度，但尚未公开本次产品的阈值与实测。
Health 的产品意义来自上下文连续性：通用聊天助手第一次可以在用户主动授权后，把化验、用药、就诊与日常活动放进一条长期信息链。对慢病管理、复诊准备和记录整理，这比一次性粘贴报告更有实用价值，也比新增一个“医疗问答”标签更接近真实需求。
这份价值与治理负担是同一枚硬币。跨对话调用让用户少做整理，也让“我现在是否在使用健康数据”变得不那么显眼。OpenAI 已给出不训练基础模型、不做定向广告以及断开后 30 天内删除同步数据的承诺；下一步应把承诺变成可见控制，例如逐次显示数据来源、提供删除状态，并允许用户按记录类型或对话关闭调用。
医疗安全的判断不能由厂商的用户规模或评测投入代替。超过 3 亿人说明影响面，HealthBench 说明评测基础，两者都不等于真实世界安全已经成立。若 OpenAI 后续公开连接记录场景的错误类型、升级成功率和独立审计结果，这项产品才会从“高价值入口”走向“可验证的健康基础设施”。
反向边界也应保留。更完整的上下文可能减少用户漏报信息，却无法消除记录本身的错误、不同医疗系统之间的冲突或模型推理偏差。Health 最合理的角色是帮助用户组织问题、理解变化并准备与专业人员沟通；聊天回答不能被包装成诊断结论。
后续验证要落到可审计指标
开放进度首先需要量化。OpenAI 应说明符合条件账户中的实际覆盖率、候补时间和地区扩张安排，并持续更新受支持医院系统、记录类型、同步延迟与失败状态。只有“开始滚动开放”而没有覆盖数据，外界无法区分小规模试点与接近全面可用。
安全评估需要从静态问答走向纵向记录。可复现测试至少应覆盖单位变化、过期用药、重复记录、缺失数据、跨来源冲突和紧急症状升级，并分别报告总结错误、关键遗漏、不当建议与过度升级。厂商自测可以快速迭代，重大医疗风险仍需要独立研究者和临床机构参与。
隐私承诺则应提供用户可核查的证据。断开后可以显示删除倒计时与完成状态；普通对话可以标示本次调用了哪些 Health 来源；删除对话时可以明确是否同时清除由连接数据生成的摘要。30 天内是一项可测量承诺，若没有状态和审计接口，用户只能相信结果而无法验证。
最后要观察跨对话体验是否尊重情境边界。超过 70% 的早期人群健康对话发生在专用体验之外，证明普通聊天是实际入口；它也要求产品在便利与惊讶之间找到平衡。用户应能随时看见、撤销并限制健康上下文，避免直到回答出现敏感信息时才发现系统调用了旧记录。