1. 这个看起来很矛盾的标题到底在说什么“AI问诊5秒出结果医生反而更忙了”——我第一次看到这个说法是在一次医疗信息化的线下交流会上。当时做分享的是一位三甲医院信息科的负责人他讲到自家医院上了AI预问诊系统之后的真实情况台下不少人都在笑但笑完又都觉得这事特别值得琢磨。先说清楚它是什么。所谓“AI问诊5秒出结果”指的是现在不少医院在门诊挂号之后、医生正式接诊之前插了一个AI预问诊环节。患者在手机上或者自助机上回答一系列结构化问题AI根据主诉、病史、症状描述自动生成一份初步的问诊记录然后推送给医生的接诊工作站。从患者点下“确认提交”到医生屏幕上弹出一份结构化病历草稿确实就几秒钟的事。这个事能解决什么解决的本来是“门诊时间被大量重复性问询占满”的问题。你去看过病就知道医生在一个患者身上平均能花的时间可能只有三到五分钟但他要问的问题基本固定哪里不舒服、多久了、什么性质的疼、有没有加重缓解因素、以前有没有类似情况、有没有基础病、有没有过敏史。这些问题AI确实可以提前帮患者“答一遍”理论上医生来了直接看重点就行。那我为什么说“医生反而更忙了”因为真实情况远没有这么理想。我后来陆续接触了多家上线过类似系统的医院包括一些做医疗AI产品的创业团队我发现一个共同的现象技术确实跑通了但工作流被改变了而改变之后的额外负担落在了原本就超负荷运转的医生身上。这篇文章想讲清楚几件事AI预问诊这类系统到底是怎么运作的它在医院里复现时会遇到哪些真实问题为什么它让医生变得更忙以及一个长期做医疗信息化的人对这件事的判断。适合正在做医疗AI产品、医院信息科相关人员、以及关注AI落地场景的从业者参考。2. 一套AI问诊系统的整体设计思路拆解2.1 系统要解决的三个核心问题我接触到的AI预问诊系统不管哪家做的基本都要回答三个问题。第一个是采集什么。患者的主诉、现病史、既往史、过敏史、月经生育史如果需要、用药情况这些都是问诊的基础要素。传统的挂号信息只有患者的基本信息和挂的科室医生接诊后要从零开始问。AI系统的目标是在医生见到患者之前就拿到这些信息。第二个是怎么采集。这就涉及交互方式的设计。早期有一些系统用的是自由文本输入让患者自己打字描述症状。后来发现根本行不通因为患者不是医生他不知道该说什么不会用医学词汇说出来的东西杂乱无章。所以现在主流的方式是结构化单选题加少量开放输入系统根据患者选的科室和首轮主诉动态生成下一轮问题。比如患者选了“消化内科”主诉选了“腹痛”下一轮就问“痛在哪个位置”“什么样的痛”“持续多久了”这类问题。第三个是怎么生成。采集到的信息要变成一份医生能直接看、能直接用来写病历的结构化文档。这一步是AI大模型最擅长的地方——把口语化的描述转成医学术语按现病史、既往史的结构组织好还能自动标出缺失的关键信息。2.2 为什么选大模型方案而不是传统规则引擎说实话早期的预问诊系统不是没用过规则方案。早些年有些公司做“智能导诊”本质上就是决策树你选一个症状它按照预设的分支走问几个固定问题最后给一个挂号建议。这种方案的问题在于太脆了。举个实际例子。患者说“肚子疼”规则引擎只会按流程走疼在哪、疼多久、有没有发烧。但如果患者输入的是“吃东西以后就疼不吃东西就好些”规则引擎基本就抓瞎了因为这句话根本不在预设的路径里。而大模型不一样它能理解这句口语话结合上下文主动追问比如“您说的吃东西后疼痛是吃完立刻疼还是过一段时间疼”之类的后续问题。我参与过的项目里从规则引擎切到大模型之后预问诊的完整率提升了大概百分之三四十。完整率是医疗AI里的一个核心指标指的是系统采集到的主诉、现病史、既往史等字段是否回答齐全。这个问题我们后面细说。另外还有一个非常现实的原因——研发成本。规则引擎设计的是固定流程每增加一个科室、增加一类症状就要重新画流程图。而大模型只需要给它一段好的提示词和足够的知识库它就能覆盖全科内容。一劳永逸这是所有工程团队都会倾向的方案。2.3 5秒出结果后端工作机制“5秒出结果”这个体验技术上不是随随便便能实现的。一套标准的AI预问诊系统从患者提交到医生端看到结果中间经过了好几步。第一步是语言模型理解。患者提交的信息进入模型这一步主要做意图识别和实体抽取比如识别出“疼痛”这个主诉抽取出“疼痛部位在左上腹”“持续三天”“饭后加重”这些关键实体。第二步是信息结构化。把抽出来的实体按病历字段组织好主诉一栏写“左上腹痛伴反酸3天”现病史一栏整理为“患者3天前无明显诱因出现左上腹痛呈阵发性隐痛饭后加重……”这种写法。这里其实有个工程技巧真正部署的时候会先在本地把患者的回答做标准化处理再喂给大模型去生成结构化文本这样既能用上大模型的语义能力又能控制成本和延迟。第三步是缺失信息补问。如果患者提交的信息里缺了关键字段比如既往史全部空白系统可以在对话结束前补问一轮。如果患者已经提交了那就只能靠医生接诊时补录。第四步是推送。生成的结构化文档通过接口推送进医院HIS系统医院信息系统或者医生的接诊工作台在医生打开患者病历的同时弹出来。这四步全部做完在配置了GPU的医院内网服务器上耗时大概在2到5秒。关键在于第三步和第四步要在同一轮请求里完成不能让患者等也不能让医生等。注意这里说的内网部署是关键。医疗数据有合规要求患者的问诊信息属于健康医疗数据不能传到公有云。所以整套系统必须部署在医院内网哪怕医院机房只放一两台GPU服务器也得放内网。这也是做医疗AI和做其他领域AI的一个很大区别你得先解决模型“进院”的问题再谈效果。2.4 部署形态的选择内网一体机方案说到部署这里多展开一点。目前主流的方案是一体机模式内存1TB起步GPU建议用48G显存以上的卡然后预装好整套AI服务。多家厂商都在推这种方案好处在于“开箱即用”部署周期从原本的几个月压缩到一两周。但一体机方案也有它的坑。医疗AI模型更新频率快厂商隔几个月就出一版新模型但医院的采购流程和IT审批流程根本跟不上这个节奏结果就是一体机里的模型版本可能落后一年半年。这个问题的根源是医院和AI厂商的商业逻辑不同厂商希望快速迭代证明自己还在进步医院希望稳定可靠不出事。两者之间的张力决定了AI系统上线后的使用体验上限。3. 核心细节解析为什么能5秒出结果却让医生更忙了3.1 病历质量的参差是最大的隐性负担现在终于要把标题里那个看似冲突的现象拆开了——AI确实能5秒生成一份问诊记录问题在于生成的这份记录质量波动非常大。先说好的情况。如果患者认真答题系统交互设计合理生成出来的病历草稿质量是不错的医生只需要改改用词、补一两个缺失信息就能定稿。这也是厂商在演示PPT里最喜欢放的那种效果。但真实世界里更常见的情况是什么是患者根本没耐心答完十几道题随便点几个选项就交卷了。比如一位痛风复诊的患者他看到“本次主要症状”这个题的时候选了“关节疼痛”后面弹出来一堆“疼痛性质”“疼痛评分”的问题他嫌烦直接跳过不答。最后生成出来的病历草稿主诉写“关节疼痛”现病史一片空白既往史那片倒是填了“痛风”两个字。这种半截病历到了医生手里反而比完全不填更让人头疼。为什么因为医生没法确定AI已经问过的信息里哪些是患者确认过的、哪些是患者漏答的。他必须重新把核心问题问一遍。要是系统直接把老病历结构化推给医生医生看一眼就好了现在多了一道“先判断这份AI病历能不能用”的工序。更麻烦的是词不达意。一位老人患者回答“哪里不舒服”语音识别出来的文字是“心口窝堵得慌”大模型大概率会在主诉里写“心窝部不适”这算是好的。但有些地方方言比如广东人说的“咳到肺都穿了”转成书面语的时候模型搞不好会直接转成“咳嗽伴随剧烈胸痛”——意思没错却又夸大了程度。医生看到这种描述是信还是不信信了可能开一堆不必要检查不信又怕漏了真问题最后只能自己再问一遍。这些被称为“病历噪声”的情况在我的经验里至少占了三分之一到四成。医生本来可以在几秒内完成的判断现在得花一分钟来自理AI生成的不确定信息。在门诊量大的医院一分钟乘以每天一百多个患者这个增加的负担是很可观的。3.2 医生“被追着确认”的时间碎片化AI预问诊还改变了另一个东西就是医生的工作节奏。过去医生的问诊是线性的见到患者从第一句“怎么了”开始按自己的节奏一步步问边问边在脑子里形成判断同时用键盘敲下关键信息。整个过程是连续的思维不容易被打断。现在多了AI预问诊医生打开工作站系统自动弹出一份结构化病历草稿界面上还可能标着“AI生成请核实”。医生的第一反应肯定是先看草稿。如果草稿质量好他确认一下关键信息接着补充提问这是比较理想的情况。但如果草稿质量差医生就陷入了一个非常尴尬的境地他既不能完全信任这份草稿又不好意思当着患者的面把系统关了当它不存在——因为患者已经花了五分钟在手机和自助机上答题了。患者会问“医生我刚才填的那些你看到了吗”医生只好一边安抚一边继续问并反复核对自己看到的草稿和患者口头说的信息是否一致。这个“对照检查”的过程看似每次只多十几二十秒但真正消耗的是注意力。医生必须在AI给的信息和自己的问诊信息之间来回切换这种注意力切换是有认知成本的。门诊时间本来就是碎片化的AI预问诊又在这个已经碎片化的工作里再切了一刀。我听过一个心血管内科医生朋友的吐槽他说“以前我走进诊室脑子里是我上一轮的患者。现在我一坐下屏幕上先冒出一份不知道靠不靠谱的AI报告我得先花三十秒判断它靠不靠谱才知道该从哪里开始接诊。”这句话基本把这个问题的本质说透了。3.3 原本应该省下的时间去了哪里有人可能要问如果AI生成的病历质量好那是不是还是省了时间答案是省了但省下来的时间往往没有流向医生。按照原本的设计预期AI预问诊把基础问询前置医生直接进入诊疗环节每人省下一分钟100个患者就省下100分钟。但医院的管理者在设计这套系统的时候忽略了一个关键变量医生的门诊时间并没有因此减少反而可能因为系统增加了新的输入源而变得更碎片化。更现实的情况是许多医院用的是 “人机协同”模式护士在导诊台引导患者使用AI预问诊患者答完题后AI再自动补一个“健康宣教”环节告诉患者一些注意事项顺便推送一个满意度调查问卷。等患者进到诊室时医生面对的不仅有诊疗任务还要处理AI系统制造的知识前提和期望管理。更隐蔽的一点是AI预问诊系统在医生端生成的结构化病历是会被计入医院的病历质量考核的。也就是说医生如果直接引用AI生成的病历而不做修改这份病历的部分内容可能会被认为不符合书写规范医生就得自己改。改的内容就是额外的工作。以前从零写一份病历可能要三分钟现在改一份AI病历往往也得两三分钟因为这中间多了一道“判断它有无问题”的工序。3.4 医患沟通方式被AI改变但没有变好还有一个不太被讨论但非常重要的影响——AI预问诊改变了医患之间的对话起点。以前医患对话的起点是“空白”医生问什么患者答什么沟通成本高但信息流是可控的。现在起点变成了“一份AI整理好的文件”。这份文件看起来是现成的但它背后的采集过程缺乏医生的引导和判断所以信息必然是降噪后的、错漏的。患者的表达被AI“框”在了单选题和结构化模板里。有些患者会说“手机问我的那些问题我都答了怎么医生还问我一样的”这种被重复提问的体验让患者觉得医院系统不联通也增加了对医生的不信任感。而对医生来说解释“为什么还要再问一遍”又占据了本就不够的时间。这个循环走到最后就是标题里描述的结果AI问诊5秒出结果医生看的还是病但沟通成本反而上升了。4. 实操过程我在项目里踩过的坑既然前面几节把逻辑讲清楚了这一节我想分享一些实操层面的经验毕竟光有认识还不够真要落地一套AI预问诊系统里面的坑比想象中多。4.1 提示词工程比预想中重要得多这一部分是整套系统能不能让医生“少忙一点”的关键。我见过很多团队把精力全放在模型选型和微调上结果提示词写得非常草率——一段话丢给模型就算完事。这在已有demo阶段看不出问题一上真实病历就全线崩。我们最终用的提示词结构上包含了几个部分角色设定、输出格式约束、专业术语改写规则、缺失信息标记规则、敏感词上报规则。角色设定很好理解就是告诉大模型你是“一位有20年临床经验的消化内科医生”这能帮助模型校准输出风格。真正麻烦的是输出格式约束。医生看惯了病历的特定写法比如主诉要精炼、现病史要按时间顺序、既往史要按病种分类枚举。你需要用提示词把这些格式要求一条条约束清楚最好用few-shot的方式给模型看两三个标注过的例子让模型照着填。缺失信息标记规则是我特别想强调的。我们在最开始的时候模型写出来的现病史特别“顺”但其实是模型自己脑补的。比如患者说“肚子疼三天了”模型在“近一周饮食”这个子项里直接填了“饮食不规律”。为了杜绝这种幻觉提示词里加了强约束未被患者明确提及的内容一律标注“患者未提及”不得推测。这一步虽然会让病历看起来不那么“完整”但真实性大幅提升医生的信任度也上来了。4.2 结构化输出的坑JSON解析与格式错误大模型的输出是文本但医院系统要的是结构化数据。所以工程师会要求模型输出JSON然后解析后写入系统。听起来简单实际跑起来全是幺蛾子。模型偶尔会输出不合法JSON比如多了个逗号、字符串没有闭合引号、嵌套花括号层级乱了解析直接报错。更大神的是模型偶尔会在JSON里插入一段跟格式无关的说明文字比如“医生请注意此患者暂无发热”。我们当时的解决方案有两层。第一层是让模型输出纯JSON并在提示词里明确指出“只能输出JSON对象不要包含任何其他文本”。但光靠提示词并不能百分之百解决。第二层是写了一套修复机制发现解析失败就自动重试一次如果再次失败就标记为低置信度病历不推送给医生直接走人工确认流程。这套兜底方案上线后因为解析失败导致的推送失败率降到了百分之一以下。4.3 医学术语的区域适配模型训练数据里的医学术语很多是基于教科书和医学指南的但真实医院场景里医生有自己的缩写习惯和方言偏好。比如“慢阻肺”有些医生写“COPD”有些写“慢喘支”“冠心病”有的写“CHD”。AI生成病历默认用教科书说法医生每改一处就是在给系统“做标注”。我们后来做了一版区域化适配在提示词里加了“本医院医生习惯将XX表述为XX”这样的规则才勉强把改稿率降下来。注意区域化适配这件事没有一个通用的标准只有到了现场才能知道。做医疗AI项目一定要提前驻场调研看看医生们平时怎么写病历、用什么词再做提示词层面的适配。这一步不作后面整个系统的使用率都会受影响。4.4 模型选择的实际对比关于模型选型我自己的感受是大参数模型强在对复杂语义的理解、对模糊表述的容错上但推理速度慢、部署成本高小参数模型速度快但在理解方言、俚语、错别字时明显不如大模型。我们最终采用的是“两条腿走路”入口模块用大参数模型比如72B以上做主诉理解和病历生成出口辅助功能用小模型做分类打标和科室推荐。大模型在GPU上一秒钟大概能跑一次推理用在问诊对话这种低并发场景完全够了小模型跑起来毫秒级适合高频调用。如果团队预算有限只部署一套模型我的建议是优先选通用能力强的模型然后用提示词做领域约束而不是选专门的“医学版”模型。因为专用医学模型容易在少见表述上翻车通用模型配合好的提示词整体稳定性反而更好。5. 常见问题与排查技巧实录5.1 患者答到一半不答了怎么办这是系统上线后第一个被投诉最多的问题。一个内科门诊一天接诊一百多人其中有相当一部分患者是老年人他们对手机操作不熟悉答了几道题就没耐心了。处理方案是“按需收集”而不是“全量收集”。系统在题目设计上做成树形结构根据患者上一题的回答决定下一题要不要问。比如患者选了“复诊”就不再追问症状发作时间只更新“近一周情况”。这样大部分复诊患者两分钟就能答完初诊患者八到十分钟也能完成。还有一套兜底规则患者中途退出时已答信息直接保存提交不要求全部答完再提交。5.2 医生反馈对AI病历不信任怎么办这个问题的根源在于医生不了解AI的能力边界。我们做过一个动作在医生端界面增加了一个“查看AI依据”的按钮医生点开就能看到AI生成的主诉是基于患者的哪几条原始回答。透明了之后医生对AI生成信息的信任度明显提升因为他们能判断哪些内容是患者本人说的、哪些是AI归纳的。5.3 问诊结果和最终诊断差距大怎么办这个问题最常见也最容易被过度解读。AI预问诊本质是采集信息和整理信息它不做诊断。它的结果是“病历草稿”不是“诊断意见”。如果医生拿AI生成的病历去对照最终诊断发现描述不准确甚至方向都错了首先要查的不是AI模型而是采集环节。患者是否认真答题、题目的逻辑是否合理、有没有引导性错误这些才是根本原因。5.4 系统上线初期使用率低怎么推广推广这事关键在“让医生有获得感”。很多项目一上来就考核医生使用率这种KPI导向反而让医生反感。我们当时做的一个有效动作是在上线前直接跟科主任沟通给科室提供一份“AI病历质量周报”每周反馈AI病历的完整率和修改率让科主任看到哪些环节可以减少医生的重复劳动。医生只要在实际使用中感到省事使用率自然就上去了。6. 反思与改进让医生从“更忙”变回“更闲”6.1 与其“替医生问”不如“帮医生管”经过一整轮项目实施我现在倾向于一个观点AI预问诊这套产品设计方向需要从“替医生完成问诊”转向“帮医生管理工作流”。为什么这么说“替医生完成问诊”这个定位天然把AI放在了“医生替代者”的位置上那就不可避免要面对“AI生成质量不够好怎么办”的灵魂拷问——因为只要它不是百分之百合格医生就得花精力去纠错纠错成本比从零开始写可能还高。如果把定位改成“帮医生管理工作流”产品就改变了它相当于是医生诊前的一个信息助理帮患者把基础信息填好、把缺失项标出来、把关键风险提示出来。即使内容质量不完美医生也只需要处理那几项缺失而不是通篇重写。6.2 从“5秒出结果”到“5秒看完结果”“5秒出结果”是技术指标“5秒看完结果”才是使用体验。后者要求的是信息呈现的效率提升而不是生成速度的提升。这就涉及到系统在设计上的一个细节结果推送给医生时一定不要推一个整段长文本而要推结构化摘要加高亮。医生最想知道的是患者的主诉是什么、病程多久了、有没有红色警示信号。这些信息要给在最显眼的位置剩下的细节折叠起来想看再展开。6.3 数据闭环才是这套系统的长远价值AI预问诊有一个很隐秘但很重要的长期价值它在采集患者数据的同时也在构建一个高质量的结构化医疗数据集。这些数据反过来可以用于提升医院的病历质控、科研统计、甚至未来的辅助诊断模型训练。但前提是数据得有闭环。所谓闭环指的是患者端的交互数据、模型输出数据、医生的修改数据三者要对得上。也就是说每次医生修改病历修改的痕迹要能记录成结构化增量返回给模型侧模型才能越用越准。绝大多数医院和厂商都没有做这一步导致AI问诊系统上线一个月之后效果并没有随数据积累而提升。这是我觉得最可惜的地方。7. 写在最后的实操手记说回到标题那个问题AI问诊5秒出结果医生反而更忙了。我想给出的判断是这个“更忙”不是AI的必然结果而是当前产品定位、工作流设计和数据闭环策略还不够成熟时的阶段性现象。我自己的体会是做医疗AI产品最忌讳的是用技术想象替代临床现场的真实体验。任何一个看起来“提高效率”的AI功能都要问一句在真实流程里它到底给谁省了时间又给谁增加了时间如果省时间的是患者和管理者增加时间的是医生那从系统层面看它可能是“成功”的但从使用者的角度看它就是失败品。最后再说个小技巧也是我踩过几次坑之后总结出来的判断一套AI问诊系统的好坏不要看演示视频也不要看测试集上的准确率去医院跟一位内科医生待半天看他如何处理AI生成的病历就全明白了。他如果直接把AI病历改几个字就落盘说明这套系统是及格的他如果先把AI病历从头到尾复述一遍给患者确认再顺手把它关掉那这套系统可能还在帮倒忙。我们做这行的目标不应该是让演示漂亮的系统而应该是让医生在忙完一天之后能早十分钟下班。