ChatGPT Health 直接進主對話

以前健康功能要進專區，現在直接跟在主對話裡。

我盯 ChatGPT Health 很久了。OpenAI 一開始把它塞在一個專門的健康入口，我用起來總覺得卡卡的。我要先想「現在是不是該切到那個模式」，再重連資料、再確認權限，整個流程像在辦手續。問題是，真實世界根本沒人在等你切模式。人就是在聊天框裡順手丟一句：我今天能不能吃這個、這份檢查結果怎麼看、我最近的步數是不是怪怪的。工具如果要人先記規則，它就還沒真的進到產品裡。

更煩的是，這種設計很容易把自己活成一個側門。你以為你做的是「健康功能」，結果使用者根本不去那裡。OpenAI 這次把健康層搬回一般 ChatGPT，我反而覺得合理多了。因為它終於承認一件事：人不是為了健康去開聊天工具；人是先開聊天工具，然後順手問健康問題。

這篇拆解的起點是 Ivan Mehta 在 TechCrunch 的文章，OpenAI makes ChatGPT Health available to all US users。文中提到 OpenAI 說有 70% 的健康相關查詢其實發生在專區外面，還說這功能正擴到美國登入用戶、18 歲以上、Free/Go/Plus/Pro 都能碰到。這個數字很刺眼，因為它直接把產品問題講穿了。

70% 的查詢跑出專區，代表專區本身就有問題

OpenAI says 70% of health-related queries were happening outside the dedicated hub.

翻譯一下就是：使用者早就用腳投票了。他們不想先去一個「健康區」，他們只想在平常聊天的地方問到有用的健康答案。這不是 UX 小瑕疵，這是產品定位錯位。

我之前做過一個內部工具，裡面有一個很「安全」的敏感案件模式。理論上很完整，實際上根本沒人記得切。大家還是在主工作流裡問問題，只是希望系統能看懂上下文。後來我們把那些規則直接塞回主介面，使用率才開始像樣。原因很土：少一個切換，就少一次放棄。

OpenAI 這次的動作其實很像承認自己前面繞遠路了。它不是在說健康專區沒價值，而是在說：如果大部分需求都已經在主對話裡發生，那健康能力就該跟著對話走，而不是叫人搬家。

實操上我會這樣看：先找使用者的預設路徑，再決定要不要做專區。如果 60% 以上的請求都自然發生在主流程，專區通常只是在增加心智負擔。你不是在做入口，你是在替自己製造摩擦。

• 先看使用者在哪裡提問，不要先看你想把功能放哪裡。
• 如果使用者要記模式、記 tab、記權限，使用率通常會掉。
• 高頻需求應該貼在主動作上，不要掛在旁邊當裝飾。

健康層不是一個頁面，是一種上下文能力

OpenAI 這次的重點不是開一個新頁面，而是讓健康資訊能跟著一般對話一起跑。文章寫得很直白：使用者可以把醫療紀錄接進來，來源包含 Epic、Oracle Health、One Medical、Function Health，還有 Apple Health 與 MyFitnessPal。這些資料不是拿來炫技，是拿來讓回答有上下文。

也就是說，健康功能真正的價值不是「會講健康話」，而是「知道你在講誰的健康、哪一段資料、哪一種情境」。如果沒有這層上下文，模型講得再順都只是泛用建議，包一層個人化外皮而已。那種東西最危險，因為看起來像懂你，其實只是會講話。

我對這種功能一直很挑。很多產品喜歡把「個人化」當賣點，結果只是把名字塞進 prompt。真正有用的是資料接得夠不夠完整、夠不夠新、夠不夠可追溯。健康尤其如此。你如果連過敏史、用藥、最近檢查值都沒接好，模型最好不要裝得像有把握。

實操寫法很簡單：先從低風險問題開始驗證上下文有沒有真的被用上。像是飲食、過敏、作息、運動摘要，這些都比診斷安全，也更容易看出資料串接有沒有成功。不要一上來就碰最嚴肅的醫療決策，那只會把風險跟誤判一起放大。

• 先接使用者真的會維護的資料源，不要貪多。
• 讓系統明講「我用了哪些資料」而不是只給結論。
• 先做好日常問答，再談高風險場景。

300 million queries 不是炫耀，是壓力測試

TechCrunch 這篇有提到 OpenAI 說每週有 3 億筆健康相關查詢。這個數字我不會拿來當戰績看，我會把它當壓力測試。因為一旦量級到這裡，產品就不再只是「有沒有功能」，而是「會不會在大量模糊問題下穩住邊界」。

翻譯一下就是：人們問健康問題時，通常不是問得很漂亮。很多問題都很含糊、很焦慮、很跳躍。今天問飲食，明天問檢查報告，後天問是不是要看醫生。模型如果只會接球，不會踩煞車，問題就大了。

我以前看過不少 AI 產品拿 benchmark 成績說嘴，分數漂亮得像要上天，結果一到真實使用情境就開始亂飄。健康場景最討厭的就是這種落差：測試集上小錯，現實裡大翻車。因為使用者不是在做 demo，他是在處理自己的身體。

OpenAI 也知道這點，所以它一邊推功能，一邊講自己跟醫師合作、資料不拿去訓練、而且不能用來診斷或治療。這些話不是廢話，這些話是護欄。你不講清楚，使用者就會自己補腦補到失控。

實操上，我會把高量級功能當成「邊界管理」專案，不只是功能專案。你要測的不是模型答得多漂亮，而是它在焦慮、模糊、重複追問時會不會失手。

把醫療邊界寫在介面裡，不要藏在條款頁

OpenAI 明講它的服務「not intended for use in the diagnosis or treatment of any health condition」。這句話我很喜歡，因為它至少誠實。它在擴大可用性，但沒有假裝自己變成醫師了。

也就是說，這個產品的定位其實很清楚：它要的是健康資訊輔助，不是臨床決策權。這條線如果不畫，最後一定會有人拿它當醫療建議。到那時候，問題不是模型會不會答，而是誰來負責。

我很討厭那種把警語藏在條款頁的做法。那等於你嘴上說有提醒，實際上是希望沒人看到。健康、財務、法律這類高風險功能，警語要放在使用者做決定的地方，不是在事後補一張保險單。

實操寫法我會這樣做：在輸入框旁邊、資料接入前、以及回答結果下方，都放同一套簡短邊界文案。不要每個地方講不同版本，使用者會被你搞混。文案要短，直接，能看懂。

另外，OpenAI 這次也強調不會用使用者資料訓練模型。這點在健康場景很重要，因為只要資料用途講不清楚，信任就會掉很快。你可以做得很強，但只要資料故事講不乾淨，使用者就會先退一步。

評測分數好看，不代表你敢拿去問醫生

文章提到 OpenAI 的小模型在 HealthBench 上表現比前一版更好。這種消息我會看，但不會迷信。因為 benchmark 只能說模型在某個題型上更穩，不代表它在真實世界就安全。

翻譯一下就是：分數上升，通常代表少掉一些明顯錯誤；但健康場景真正可怕的，往往不是明顯錯，而是很自信的錯。尤其是半夜、焦慮、資訊不完整的時候，模型如果講得太像真的，使用者就很容易把它當答案。

我以前在產品評審裡最怕這種情況。demo 看起來很順，評測也很好，結果一到現場資料就破功。不是模型不夠強，是你拿錯了衡量方式。健康不是一般客服問答，不能只看平均分，還要看錯一次會不會出事。

所以我會把 benchmark 當門檻，不當結論。你可以先用它確認模型至少不笨，但真正上線前，還是得有人看邊界、看例外、看會不會把不確定講成確定。

實操上，最少要有三件事：人工抽查、風險分流、以及明確的升級路徑。只要問題碰到診斷、治療、用藥調整，就該立刻收斂成提醒與轉介，而不是硬答。

可抄的模板

# ChatGPT Health-style product pattern for any sensitive domain

## Product shape
Move the domain-aware layer into the main chat flow.
Do not force users into a separate hub unless the workflow truly needs it.

## What the assistant may use
- Connected user data only when the user has granted access
- Only the sources that are fresh enough to matter
- Only the context relevant to the current question

## What the assistant is for
- Everyday informational questions
- Summaries of connected data
- Low-risk decision support
- Explaining what data is missing

## What the assistant is not for
- Diagnosis
- Treatment decisions
- Replacing professional advice
- Acting certain when the data is incomplete

## In-product copy
This feature uses connected data to help answer everyday questions.
It is not intended for diagnosis or treatment.
If the question could affect medical decisions, talk to a licensed clinician.
If data is missing or stale, say so instead of guessing.

## UI rules
- Show when connected data is being used
- Show which source was used
- Keep the main chat as the default entry point
- Measure how often users ask the same question outside the special flow
- Review edge cases with a domain expert before broad rollout

## Prompt pattern
You are a domain-aware assistant.
Use connected data only when it helps answer the current question.
If the question involves diagnosis, treatment, or anything urgent, stop and recommend professional help.
For everyday questions, answer plainly and cite the connected context you used.
If the data is missing, incomplete, or stale, say that clearly.
Do not guess.

這份模板是我把 OpenAI 這次的產品動作拆成可用版本後整理出來的。原始觀點來自 TechCrunch 的報導與 OpenAI 的說法；上面這套結構、文案和 prompt pattern 是我整理過後能直接拿去改的版本。

如果你要看原始來源，先從 Ivan Mehta 的 TechCrunch 文章開始：https://techcrunch.com/2026/07/23/openai-makes-chatgpt-health-available-to-all-u-s-users/。我這篇是衍生拆解，不是原文重寫；模板段落是我自己整理出來的可抄版本。