马克·库班最近提出的观点很有意思医生应该教患者使用 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 在受限环境里安全地帮助普通人。