馬克·庫班最近提出的觀點很有意思醫生應該教患者使用 AI 輔助治療而不是擔心 AI 取代醫生。這個觀點從商業和技術圈傳出來后很多人的第一反應是“又是一個 AI 樂觀主義者的雞湯”但如果你把自己放到醫療信息化開發者的位置上重新看會發現它實際上指出了一個被大多數醫療 AI 項目忽略的工程方向過去我們拼命做“AI 替代醫生做診斷”但真正的需求缺口可能是“AI 幫患者理解疾病再由醫生確認方案”。本文不會去爭論“AI 會不會取代醫生”這種立場問題而是從架構設計、知識管理、提示詞工程和隱私安全四個角度拆解一句聽起來像口號的觀點到底對應哪些可落地的技術動作。讀完你會明白為什么“教患者用 AI”比“用 AI 替代醫生”更難做也更值得做以及如果你要開發一個面向患者的 AI 輔助工具應該怎么設計知識邊界和復核流程。1. 這篇文章真正要解決的問題馬克·庫班這句話真正值得注意的地方不是“醫生該不該用 AI”而是“醫生應教患者用 AI”。這兩個動作的邏輯完全不同。前者假設 AI 是醫生的效率工具本質上是 to 醫生后者假設 AI 是患者的認知工具本質上是 to 患者。如果按照傳統醫療軟件的思路to 醫生的 AI 通常做成診斷輔助、影像分析、病歷摘要目標是縮短單個病例的判斷時間。而 to 患者的 AI挑戰點不再是如何輸出更準的醫學結論而是如何把醫學知識翻譯成患者能理解、能執行、能復述的內容同時不越界、不產生誤導、不泄露隱私。很多開發者在做醫療 AI 時都會踩同一個坑把模型當成“會說話的醫學知識庫”以為只要接一個大模型 API就能讓患者隨便提問。但實際上面向患者的 AI 系統工程復雜度遠高于面向醫生的系統。原因很簡單醫生有專業判斷力知道模型哪些話可信、哪些話要復核患者沒有。一旦面向患者開放AI 的每一句話都可能被當成醫囑執行。這里真正要解決的技術問題不是“模型能不能答對”而是“模型答錯時系統能不能兜住”以及“患者理解錯時醫生有沒有機會糾正”。這篇文章要寫的內容包括四個部分患者 AI 工具和醫生 AI 工具在架構上的本質差異醫療問答場景下的提示詞約束與知識邊界控制一個可運行的最小示例演示“患者提問→知識檢索→答案約束→醫生復核”的完整鏈路以及從工程規范視角總結出的常見坑和最佳實踐。適合的人群包括醫療信息化方向的后端開發、正在做 AI Agent 或 RAG 應用的工程師、對醫療大模型落地感興趣的產品經理以及想在自己的項目里引入患者教育模塊的團隊。2. 醫療 AI 的兩個方向診斷替代與患者賦能要理解馬克·庫班的判斷先要把醫療 AI 拆成兩個方向。一個方向是“替代型”目標是讓 AI 直接完成醫生的部分工作比如影像識別、病理分析、輔助診斷。這個方向已經跑了十幾年技術難度高監管門檻更高因為它直接涉及醫療行為。另一個方向是“賦能型”目標是讓 AI 幫助患者理解自身狀況從而在就診過程中更好地和醫生溝通。比如患者拿到一份檢查報告看不懂術語醫生下了診斷但患者記不住注意事項出院之后患者需要持續管理飲食和用藥但找不到人及時答疑。這些場景過去主要由護士或醫生人工完成現在可以用 AI 做前置解釋再由醫生做最終確認。兩個方向的核心區別可以用下面這張表說明對比維度替代型 AI輔助診斷賦能型 AI患者支持使用對象醫生、影像科專家患者、家屬、護理人員核心目標提高診斷準確率和效率提高疾病認知和治療依從性風險等級極高直接影響診療決策中高間接影響患者行為知識邊界需要嵌入醫院信息系統需要做患者可讀性改造監管要求多作為醫療器械管理通常作為健康信息服務但仍需合規審查技術難點模型精度、數據標注、系統集成內容安全、可解釋性、隱私保護、醫生復核機制從這個表能看出一件事患者賦能型 AI 看起來門檻低因為“只是解釋醫學知識”但它也有獨特的技術難度而且這個難度常被低估。首先患者的提問是開放式的不會按照數據庫里的字段來提問。同一個問題“我血壓高能吃柚子嗎”“血壓高是不是不能吃柚子”“柚子對我這個高血壓有沒有影響”表達完全不同但語義接近。模型需要有很強的意圖識別能力。其次患者的醫學素養參差不齊系統必須用簡單的語言回答不能直接甩一段“鈣通道阻滯劑與西柚汁的 CYP3A4 代謝相互作用”這種話。也就是說AI 要做“翻譯”把醫學語言翻譯成日常生活語言。這就是為什么馬克·庫班說“醫生應該教患者用 AI”而不是“AI 直接教患者”。醫生的角色在患者賦能型 AI 體系里不是消失了而是變成了“AI 內容的審核者”和“患者提問的引導者”。從工程實現角度看這種三角關系患者-AI-醫生天然要求系統具備三條鏈路患者提問鏈路、AI 回答鏈路、醫生復核鏈路。三條鏈路缺一不可缺了任何一條都不是完整的患者賦能系統而是一個危險的“醫療信息堆”。3. 為什么“教患者用 AI”在工程上是一個新命題很多人會覺得患者直接用 ChatGPT 或者文心一言問問題不就行了為什么還要單獨做一個系統這就要說到“教患者用 AI”和“給患者一個 AI”之間的差別了。給患者一個通用 AI問題出在三個層面。第一通用 AI 沒有患者的個性化上下文。它不知道患者多大年紀、有什么基礎病、正在吃什么藥、做過什么手術、有沒有過敏史。同樣一句“可以多吃蛋白質”對一個腎病患者和一個術后恢復患者的意義完全不同。第二通用 AI 不會主動約束自己的回答邊界。它可能自信地給出一個看似專業、但實際上不適用于該患者狀況的建議而患者不具備辨別能力。第三通用 AI 沒有和醫院的診療流程打通。患者在 AI 上獲得的建議醫生看不到、也無法復核等于整個系統處于“黑盒”狀態。“教患者用 AI”在工程上要求的是另一套設計。不再是“一個對話框”而是一套受控流程患者先建立自己的信息檔案AI 基于檔案和經過審核的醫學知識庫回答回答內容包含明確的邊界提示同時進入醫生的復核隊列。如果把通用 AI 比作一個“博學的自由職業者”那么患者賦能 AI 更像一個“只讀醫院的培訓教材、并且說話必須留有余地”的接線員。后者需要做的工程工作包括結構化患者檔案、建設領域知識庫、設計受限的提示詞模板、實現人工復核界面、記錄全鏈路日志。所以“教患者用 AI”本質上不是產品文案層面的問題而是產品架構層面的問題。它要求開發者在設計階段就回答幾個關鍵問題AI 能說什么、不能說什么、拿什么知識說、說的過程中患者隱私如何保護、說錯了由誰來糾正。這些問題沒有一個靠調 prompt 就能解決必須落到代碼和流程里。這也是為什么這篇文章要把重點放在“患者 AI 的工程實現框架”而不是“模型選型對比”上。在當前階段模型能力差異已經不是最大的瓶頸最大的瓶頸是圍繞模型構建的安全、可控、可復核的應用層。4. 患者 AI 系統的核心技術知識邊界、RAG 與提示詞約束如果你要做一個面向患者的 AI 輔助系統核心技術棧并不復雜但每層都需要仔細設計。一個典型的架構包含四層患者信息層、知識庫層、模型交互層、醫生復核層。下面分別說明每一層要解決的問題。4.1 患者信息層個性化上下文的結構化表達患者信息層解決的是模型“不知道患者是誰”的問題。架構上可以采用“結構化檔案 向量化描述”的方式。結構化檔案存年齡、性別、過敏史、當前用藥、診斷歷史等字段用于精確匹配向量化描述存患者的自然語言病情描述用于語義檢索。需要注意患者信息是高度敏感數據所有字段都必須在合規前提下脫敏存儲模型層只接收必要信息不能把完整病歷直接交給外部模型服務。比較穩妥的做法是在本地完成檔案整理后只向模型傳入本次對話所需的最小上下文。# 演示患者檔案的最小化上下文構造 # 實際開發時應根據合規要求調整字段和脫敏規則 patient_context { age: 54, sex: female, known_disease: [高血壓, 2型糖尿病], current_medication: [二甲雙胍 500mg bid], allergy_history: [青霉素過敏], recent_checkup: 血壓140/90血糖空腹6.8 }4.2 知識庫層用 RAG 控制信息來源知識庫層是整個系統能否安全運行的關鍵。患者 AI 絕對不能只靠模型內部知識回答因為模型訓練數據里包含大量過時、不準確甚至互相矛盾的醫學觀點。更穩妥的做法是采用 RAG檢索增強生成架構所有回答都基于一個經過醫院或專業機構審核的知識庫。這套知識庫里可以存放患者教育手冊、藥品說明書、飲食注意事項、術后康復指南等。檢索時系統先通過患者問題匹配相關知識片段再把片段作為上下文交給模型生成回答。這樣做的好處是模型回答可以被追蹤到知識庫里的具體來源醫生復核時可以直接看到 AI 引用了哪一段資料。// 演示RAG 檢索結果的結構 { query: 服用二甲雙胍期間需要注意什么飲食問題, retrieved_chunks: [ { source: patient_education/diabetes_2024.md, content: 服用二甲雙胍期間應避免大量飲酒以免增加乳酸酸中毒風險。, score: 0.91 }, { source: drug_manual/metformin.md, content: 用藥期間如出現嚴重胃腸道不適、呼吸急促等應及時就醫。, score: 0.87 } ] }4.3 模型交互層提示詞約束與回答邊界模型交互層的核心是兩條第一把檢索到的知識片段和患者上下文拼裝成受限 prompt第二在 prompt 里明確要求模型只回答知識庫覆蓋范圍內的問題超出范圍必須拒絕回答并提示用戶咨詢醫生。這兩條缺一不可。只做檢索不做約束模型依然會自由發揮只做約束不做檢索模型會頻繁拒絕回答產品就沒有可用性。正確的做法是檢索提供“可以說什么”約束保證“不越界說”。4.4 醫生復核層人機協同的回環最后是醫生復核層。系統可以自動回復一些低風險的科普問題但對涉及用藥調整、癥狀判斷、緊急情況的問題必須進入人工隊列由醫生確認后發送給患者。實現上可以通過規則引擎做風險分級命中“急救詞表”的問題直接提示就醫命中“用藥調整”等關鍵詞的問題進入醫生復核隊列其他普通知識問題可以自動回復。這不是一個可選項而是患者 AI 系統的安全底線。5. 一個可落地的最小示例患者 AI 助手流程拆解為了把上面四個層次串起來下面給出一套簡化的代碼流程。這個示例使用 Python 編寫重點展示流程不綁定具體模型廠商。實際開發時你可以把generate_answer函數替換為任一合規模型服務的調用。5.1 項目目錄結構patient_ai_demo/ ├── app.py # 主流程 ├── knowledge_base/ # 知識庫markdown 文件 │ ├── diabetes_2024.md │ └── drug_manual.md ├── patient_profile.py # 患者檔案構造模塊 ├── retriever.py # 簡易檢索模塊 ├── prompts.py # 提示詞模板 └── review_queue.py # 醫生復核隊列模擬5.2 簡易知識庫檢索模塊# 文件路徑patient_ai_demo/retriever.py # 說明此模塊為演示用簡易關鍵詞檢索生產環境可使用向量數據庫 def search_knowledge_base(query: str, top_k: int 2): 根據患者問題返回知識庫中的相關片段模擬 RAG 的檢索階段 knowledge_items [ { source: patient_education/diabetes_2024.md, content: 服用二甲雙胍期間應避免大量飲酒以免增加乳酸酸中毒風險。, keywords: [二甲雙胍, 飲酒, 乳酸酸中毒] }, { source: drug_manual/metformin.md, content: 用藥期間如出現嚴重胃腸道不適、呼吸急促等應及時就醫。, keywords: [二甲雙胍, 不適, 呼吸急促] }, { source: patient_education/hypertension.md, content: 高血壓患者應減少鈉鹽攝入每日食鹽不超過5克。, keywords: [高血壓, 鹽, 鈉] } ] matched [] for item in knowledge_items: if any(k in query for k in item[keywords]): matched.append(item) matched.sort(keylambda x: sum(k in query for k in x[keywords]), reverseTrue) return matched[:top_k]5.3 受限提示詞模板# 文件路徑patient_ai_demo/prompts.py # 說明提示詞模板是限制 AI 回答邊界的關鍵位置。 SYSTEM_PROMPT 你是一名患者健康教育助手你的職責是幫助患者理解醫生已經給出的診斷和醫囑內容。 你必須遵守以下規則 1. 只根據【參考資料】中的內容回答不要使用資料之外的醫學知識。 2. 如果問題超出了參考資料的范圍明確回答“這個問題需要咨詢您的主治醫生”。 3. 不得提供用藥劑量建議不得給出疾病診斷結論不得推薦具體治療方案。 4. 遇到“胸痛、呼吸困難、意識模糊”等緊急癥狀關鍵詞時立即提醒患者撥打急救電話或前往急診。 5. 使用日常生活中容易理解的語言回答不要直接粘貼醫學術語。 6. 在回答末尾添加提示以上內容僅為健康教育參考不能替代醫生的診斷和治療建議。 def build_user_prompt(patient_context: dict, question: str, retrieved: list) - str: context_text \n.join( f[參考資料]{item[source]}:{item[content]} for item in retrieved ) patient_text ( f患者年齡{patient_context[age]}性別{patient_context[sex]} f已知疾病{,.join(patient_context[known_disease])} f當前用藥{,.join(patient_context[current_medication])} f過敏史{patient_context[allergy_history]} f最近檢查{patient_context[recent_checkup]} ) return f{patient_text}\n\n患者問題{question}\n\n{context_text}5.4 醫生復核隊列與風險分級# 文件路徑patient_ai_demo/review_queue.py # 說明使用規則判斷哪些回答需要進入醫生復核流程。 URGENT_KEYWORDS [胸痛, 呼吸困難, 意識模糊, 大出血, 抽搐] MEDICATION_KEYWORDS [停藥, 加量, 減量, 換藥, 副作用, 過敏] def classify_risk(question: str) - str: 返回風險等級low / medium / high if any(k in question for k in URGENT_KEYWORDS): return high if any(k in question for k in MEDICATION_KEYWORDS): return medium return low def push_to_review(question: str, answer: str, patient_id: str, risk: str): 模擬進入醫生復核隊列 if risk in (medium, high): print(f[復核隊列] 患者 {patient_id} 的問題需要醫生確認風險等級{risk}) print(f問題{question}) else: print(f[自動回復] 患者 {patient_id} 的低風險問題已由 AI 直接回復。)5.5 主流程# 文件路徑patient_ai_demo/app.py # 說明這是一個串聯完整流程的最小演示。 from patient_profile import build_patient_profile from retriever import search_knowledge_base from prompts import SYSTEM_PROMPT, build_user_prompt from review_queue import classify_risk, push_to_review def generate_answer(system_prompt: str, user_prompt: str) - str: 調用模型服務生成回答。 生產環境中這里應替換為所選云服務或開源模型的 SDK 并按合規要求處理數據傳輸與脫敏。 # 演示環境返回固定值實際開發請接入真實模型服務 print(系統提示詞, system_prompt) print(用戶提示詞, user_prompt) return 根據您的情況二甲雙胍用藥期間建議避免大量飲酒。如有不適請及時復診。以上內容僅為健康教育參考不能替代醫生的診斷和治療建議。 def main(): # 1. 構建患者檔案 patient_id 2025001 patient_context build_patient_profile(patient_id) # 2. 患者提問 question 我吃二甲雙胍平時要注意什么飲食 # 3. 檢索知識庫 retrieved search_knowledge_base(question) if not retrieved: answer 您的問題超出了健康教育資料范圍建議直接咨詢主治醫生。 else: # 4. 構造受限提示詞并生成回答 user_prompt build_user_prompt(patient_context, question, retrieved) answer generate_answer(SYSTEM_PROMPT, user_prompt) # 5. 風險分級與醫生復核 risk classify_risk(question) push_to_review(question, answer, patient_id, risk) if __name__ __main__: main()# 文件路徑patient_ai_demo/patient_profile.py def build_patient_profile(patient_id: str) - dict: profiles { 2025001: { age: 54, sex: female, known_disease: [高血壓, 2型糖尿病], current_medication: [二甲雙胍 500mg bid], allergy_history: [青霉素過敏], recent_checkup: 血壓140/90血糖空腹6.8 } } return profiles.get(patient_id, {})運行python app.py預期輸出會是類似下面的流程記錄系統提示詞你是一名患者健康教育助手... 用戶提示詞患者年齡54... [自動回復] 患者 2025001 的低風險問題已由 AI 直接回復。從上面這套流程可以看到患者 AI 助手并不復雜真正復雜的是那些不顯眼的安全邏輯檢索不到時要拒絕回答、涉及用藥問題時進入復核隊列、遇到緊急癥狀關鍵詞時直接觸發就醫提示。這些邏輯才是“教患者用 AI”和“讓 AI 隨便聊”之間的本質區別。6. 醫生如何設計“可教給患者”的 AI 工作流馬克·庫班說醫生應該“教”患者用 AI。這個“教”字落在產品設計上就是醫生需要在診療過程中給患者一個明確的 AI 使用規范而不是丟一個鏈接讓患者自己去試。從工程角度醫生可以用下面三步流程來組織患者 AI 工作流。6.1 門診階段讓 AI 成為醫囑的補充解釋器醫生在門診結束后可以引導患者通過 AI 助手查閱跟本次診斷相關的健康教育資料。這里的系統設計要點是AI 回答的內容必須與醫生給出的診斷結論保持一致。實現上醫生在 HIS 系統里下診斷時可以自動觸發一個“患者教育包”把該診斷對應的知識庫標簽關聯到患者的檔案上。AI 在回答時會優先檢索這些被打上標簽的知識片段。這樣患者看到的內容就是醫生本人認可的、和本次診斷匹配的教育內容。6.2 院外階段用 AI 做康復管理和用藥提醒患者離開醫院后AI 的價值更大但風險也更集中。系統可以設置每日用藥提醒、飲食建議推送、復診提醒等。每次推送都帶著知識庫來源并且保留消息記錄醫生在下次復診時可以在系統里看到患者這一個月里問過什么、看過什么、理解程度如何。這實際上是把傳統醫療里“患者教育”這個難以度量的環節變成了可記錄、可分析的數據流。6.3 復診階段讓患者和醫生的溝通更高效復診時AI 助手可以自動生成一份“患者溝通摘要”整理患者在兩次就診之間的問題、癥狀記錄、用藥反應。這份摘要可以進入醫生工作站幫助醫生在接診前快速了解患者這段時間的情況。這樣做不會增加醫生的工作負擔反而能把患者從“流水賬式”的敘述中解放出來讓醫生直接看到有價值的變化。從這個流程看醫生不是被 AI 取代而是被 AI 賦予了新的角色AI 內容的管理者、復核者和患者健康教育的指導者。這個角色的核心能力不是醫學知識本身而是判斷 AI 給出的信息是否適用于具體患者以及能否把 AI 使用規范教給患者。這也解釋了為什么“醫生應教患者用 AI”在工程上是一個真實存在且持續增長的需求。7. 患者 AI 系統中的常見問題與排查方法面向患者做 AI 應用常見問題比普通業務系統更多下面列幾個典型的并給出排查思路。問題現象可能原因排查方式解決方案模型回答了超出知識庫的問題提示詞約束不足模型“自由發揮”查看完整 prompt確認是否包含拒絕規則測試多輪邊界問題強化提示詞邊界規則在生成層增加規則校驗對包含診斷、劑量類關鍵詞的輸出進行攔截患者收到互相矛盾的建議知識庫不同來源存在沖突檢查檢索結果的來源和版本確認是否同時命中新舊指南建立知識庫版本管理對沖突內容做人工審核標記失效文檔患者隱私信息出現在模型請求中系統直接傳了完整病歷抓包或查看日志確認請求體字段在調用模型前進行字段級脫敏只傳最小必要上下文外部模型服務需簽署合規協議緊急癥狀問題被自動回復風險分級關鍵詞表缺失檢查 classify_risk 規則確認緊急癥狀關鍵詞是否覆蓋擴充緊急關鍵詞表對風險等級為 high 的請求直接拒絕自動回復AI 回答使用大量醫學術語患者看不懂提示詞未要求通俗表達檢查系統提示詞看是否寫明“日常語言”要求在提示詞中增加語言風格約束增加回答可讀性評測指標患者歷史記錄無法追蹤缺少對話日志和操作審計查看日志存儲配置確認是否記錄 prompt、輸出、來源、復核狀態引入全鏈路日志系統記錄所有必要信息并設置合理保留期8. 患者 AI 工程的最佳實踐與安全建議從工程規范角度面向患者的 AI 系統比普通 AI 應用更需要紀律。這里整理幾條經過驗證的建議供開發團隊參考。第一知識庫是產品安全的第一道防線。不要把知識庫當成簡單的文檔堆砌要建立審核、發布、下架的完整生命周期流程。醫學知識更新很快一份過期的飲食指南可能帶來完全相反的結論。建議為知識庫引入版本號和生效時間發布前經過專業醫護團隊審核。第二模型調用必須設底線。無論使用哪個模型都要在提示詞之外加一道規則校驗層。比如命中用藥調整關鍵詞的輸出必須進入人工復核命中急救關鍵詞的輸出必須附上急救提示檢測到模型輸出包含“劑量”“停藥”“治愈”等高危詞匯時直接降級為人工處理。規則校驗層不需要復雜的算法用關鍵詞表加正則表達式就可以實現但它是系統安全的兜底。第三隱私保護遵循最小化原則。患者 AI 系統涉及的是高度敏感的健康數據應默認采用最小權限策略只向模型傳入本次對話所需的最小字段日志中不保存完整病歷測試環境使用脫敏后的假數據。任何患者數據的傳輸都應當加密對外部模型服務的調用應經過專門的隱私審查。第四醫生復核流程要可追蹤、可回滾。復核不是簡單的“人工看一下”而是要在系統里保留操作記錄誰復核的、什么時候復核的、復核前后內容是什么、最終版本發送給患者的是哪一版。一旦出現糾紛完整的時間線記錄比任何口頭解釋都有價值。第五提示詞模板要經過系統化測試。不要把提示詞當成一勞永逸的配置它和代碼一樣需要版本管理和回歸測試。建議為每個提示詞模板準備一組邊界測試用例定期用這些用例檢查模型輸出是否仍然符合預期。模型升級后必須重新跑一遍回歸用例確認新的模型版本沒有打破安全邊界。9. 總結患者 AI 不是 AI 的消費級應用而是醫療系統的延伸馬克·庫班這句話讓我想到一個更本質的問題醫療 AI 的落地瓶頸從來都不是模型能力不夠而是缺少一個讓醫生、患者和 AI 三方都舒服的協作流程。替代型 AI 想取代醫生結果卡在責任歸屬和監管審批上賦能型 AI 讓患者掌握更多主動權反而更容易在現有診療流程里找到位置。對于開發者來說如果要做這個方向最重要的不是追逐最新模型而是踏踏實實把下面這幾件事做好建設經過審核的知識庫設計邊界清晰的提示詞模板用規則引擎做風險分級搭起醫生復核的閉環最后用日志和審計守住安全底線。這幾件事沒有一件是“換了更強的模型就能跳過”的。建議對醫療 AI 感興趣的工程師可以先從一個小場景開始比如“術后患者飲食問答助手”用三周時間把知識庫、檢索、受限生成、復核四個環節跑通。這個方向的行業價值正在被越來越多的人看見而它的工程方法論本質上是通用 AI 應用里最難也最值得積累的那部分讓 AI 在受限環境里安全地幫助普通人。