医疗信息化圈子里，最近大半年聊得最多的，必然是“大模型在医疗场景里到底怎么落地”。很多人第一反应是做个对话机器人，可真放进生产环境才发现，聊天只是最外层的东西，真正的难点是把它接入到门诊、住院、随访的主流程里，同时还要保证回答质量、数据安全和一线医护的使用体验。我做过的某三甲妇儿专科医院数字医生项目，属于比较典型的人机共智方案：让模型处理预问诊、知识查询、随访触达这类高重复、标准化的工作，让医生继续掌握诊疗决策的最终解释权。它没有追求全自动，而是把人和机器的能力边界划得很清楚。
这套数字医生上线后，日活咨询量稳定在几千人次，其中大量是孕产妇和儿童家长的常规问题。模型实时调取院内知识库回答，遇到超出范围的提问自动转人工。医生工作台每天收到AI生成的预问诊结构化摘要和可能的诊断线索，整条流程有一层人机互认的校验环节。下面我把这个项目的设计思路、技术选型、功能落地和踩坑过程逐一拆开说清楚。
1. 第一刀先切在哪里：场景与需求的取舍
1.1 门诊数据倒逼出来的选择
启动这个项目之前，团队最常被问的一句话是：大模型在医院能做什么。市面上能想到的答案很多，辅助诊断、病历生成、患者教育、科研检索，样样听起来都很有价值，但样样都铺开做，结果大概率是什么都做不成。所以我们定了一个原则：不按功能去找场景，而是按业务痛点去切场景。
当时院方给出的核心痛点是门诊咨询量太大、重复度太高。妇幼专科有一个典型特点，就是孕产妇和儿童家属的常规问题特别多：“产检报告这个指标是不是偏高”“孩子发烧要不要立刻来医院”“出院后黄疸怎么观察”，这些问题占掉分诊台和医生诊间大量时间。很多问题临床指南里有明确答案，只是患者不知道去哪查、查到了也看不懂。这类需求天然适合大模型来做，因为它的表达能力强、可以多轮追问、能把专业内容翻译成普通患者听得懂的话，同时又能把回答来源挂到知识库里，避免凭空发挥。
另一个倒逼因素是夜间和节假日咨询的缺口。不少患者晚上突然焦虑，打电话不方便，在线又没人即时回应。传统聊天机器人只能给固定话术，遇到复杂问题就卡死。大模型最大的增量价值在于它能处理开放式提问，同一个问题换个问法也接得住。于是项目范围很快收敛成三块：智能预问诊、诊后随访、基于知识的患者咨询，再加一块辅助医生决策的线索提示。前三块面向患者，最后一块面向医生，构成人机共智的完整闭环。
1.2 人机共智不等于AI全自动
很多甲方一上来就希望AI能自己完成问诊、自己给诊断结论，这样医生就轻松了。这个想法听起来很美好，但放在医疗场景里非常危险。疾病的诊断依赖体征、检验、影像和医生的临床经验，光靠对话很难覆盖所有变量；而且一旦AI给出错误判断，责任归属也说不清楚。所以我们把“人机共智”定义成三层协同：
第一层是机器接管信息采集和普及性解释。患者跟数字医生对话，AI负责收集主诉、既往史、过敏史、用药情况，然后生成结构化病历摘要；患者问“这个药饭后吃还是饭前吃”，AI直接从药品知识库调取说明并做通俗化解释，不需要医生介入。
第二层是机器提供线索，医生负责确认。AI根据预问诊结果生成初步考虑方向和下一步建议，但系统里所有带“可能诊断”的内容都要经过医生确认后才出现在正式记录中。推送形式类似“AI工作台提醒”，医生可以一键采纳、修改或忽略，操作成本很低，但决策权始终在医生手里。
第三层是机器做全量随访和提醒，医生只处理异常反馈。系统按病种规则生成随访任务，定时触达患者，回收恢复情况，只有出现智能预警指标时才把病例推送给医生。这样既扩大了随访覆盖面，又不会给医生增加额外负担。
这三层关系明确了，后面所有设计和开发都不会跑偏。
2. 支撑数字医生的架构设计与模型选型
2.1 分层架构里，每层解决什么问题
整个系统分成四层来搭：数据层、模型层、应用层和交互层。
数据层是基础，也是最花时间的部分。医院的知识源很分散：临床指南、诊疗规范、药品说明书、院内自制的健康宣教手册、既往病历脱敏样本。这些材料格式不统一，有PDF、Word、Excel，还有扫描图片，必须先做清洗和结构化。我们把材料按科室、病种、内容类型打上标签，切成适合检索的片段，再同步到向量数据库和搜索引擎里。这一步做到什么程度，直接决定后续回答质量的天花板。
模型层是核心，跑了两类模型：一类是大语言模型，负责对话理解、意图识别、文本生成和结构化输出；另一类是Embedding模型，负责把知识片段和用户问题转换成向量，供检索使用。另外还接入了语音识别模型，为不方便打字的家长提供语音输入能力。这里要特别强调，Embedding模型的质量经常被忽略，但它在RAG链路里和主模型同样重要，选不好，检索出来的知识就是驴唇不对马嘴。
应用层承上启下，封装了统一问诊引擎、知识检索服务、结构化输出服务和人工复核接口。所有对话请求先经过问诊引擎判断当前对话阶段，再决定调用检索还是直接生成。人工复核接口连接医生工作台，AI生成的内容不会直接落库，而是要等医生确认或修改后才变成有效记录。
交互层相对简单，包括患者端的微信小程序、医生工作台的插件、随访短信链接等。这块的难点不在技术，而在产品细节，比如字号、颜色、按钮位置，错误提示语气，都会影响患者愿不愿意用下去。
2.2 RAG：让模型先查再说
医疗场景里最不能接受的就是模型胡编。大模型虽然知识面广，但训练语料和院内真实规定之间一定存在偏差，更别说很多院内规范更新后，模型根本不知道。所以我们从一开始就确定：所有涉及诊疗和用药的回答，必须先走检索增强生成，也就是RAG，不允许模型仅凭自身记忆直达答案。
RAG的基本链路是：用户输入问题、系统把问题转成向量、从知识库检索TopK相关内容、把检索结果和原始问题一起塞进提示词、模型基于这些材料生成回答。实际使用中，我们还会在检索前加一步查询改写。因为患者说话比较口语化，“娃儿拉肚子两天了要不要吃蒙脱石”这种问题，直接拿去检索效果不好，要先把关键词补全成“儿童腹泻 蒙脱石散 用药建议”，再做向量检索。
检索结果还要加相关性判断，不能拿到什么就用什么。我们设置了一个相关性打分阈值，分数不够就认为知识库没有覆盖，系统会走兜底话术，回答说“这个问题需要更专业判断，建议预约门诊或咨询在线医生”。这一步看似简单，却把幻觉大幅降下来。后来统计，走了RAG的回答，引用来源可追溯的比例接近九成，剩下的二重Biz部分主要靠兜底和人工接管来解决。
2.3 模型选型和部署上的安全碰撞
模型选型是整个项目里争议最多的事。选项大致有两个方向：调用外部成熟大模型接口，或者本地私有化部署。外部接口的效果确实更好、迭代更快，但医疗数据出院的合规压力、网络依赖和成本模型都让人犹豫。本地部署的优势是数据可以全程留在院内，方便做审计，也能按业务需求灵活调整，劣势是初期硬件投入高，且模型能力需要自己调优。
我们最后采用的是“本地化部署为主，外部接口兜底”的混合模式。面向患者的主流程全部走院内集群，保证医疗数据不出院；一些非敏感的场景，比如健康科普文案生成，允许调用外部接口来提高生成质量。模型选择上，主对话模型用了开源的中大型模型，Embedding模型和语音识别模型也都选了开源版本。这么做不是因为开源一定更好，而是院内团队能拿到模型权重，推理过程出了问题有地方排查，也不会被单一供应商绑住。
推理部署上用的容器化加多副本，平时跑4到8卡，高峰期自动扩容到16卡。模型推理的并发能力和响应速度是一对矛盾，控制并发数才能避免显存溢出，但排队时间又会变长。我们通过一个简单的滑动窗口控制，在患者体感不明显的前提下，把单次请求响应时间压在一到三秒。这里有一个经验：别把大模型当成普通API来压测，它的Token输出是逐步生成的，实际并发能力比预估低很多，必须预留资源余量。
3. 三个核心功能从设计到落地
3.1 智能预问诊：从混乱对话到结构化病历
智能预问诊是第一个上线的功能，目标很明确：患者进入诊间之前，系统已经把主诉、现病史、既往史、过敏史、月经婚育史这些信息收集完整，医生坐下来只看摘要就能开始判断。
设计上难点在对话管理。患者陈述症状时往往没逻辑，先说最难受的，又跳到几天前的事，中间还可能夹杂情绪。模型要能在这种混乱对话里做两件事：一是多轮追问补全关键信息，比如“阵痛大概是几分钟一次”“昨天最高体温多少”；二是自动把对话内容映射到预设的病历字段。这两件事都需要用结构化的方式定义清楚。
我们在提示词里放了明确的输出格式要求，让模型以JSON格式输出结构化结果，避免自由发挥。给一个简化的示例：
{ "chief_complaint": "发热伴咳嗽3天，最高体温38.5℃", "present_illness": "3天前无明显诱因出现发热，以夜间为著…", "past_history": "既往体健，否认手术外伤史", "allergy_history": "否认药物及食物过敏史", "followup_needed": [ "咳嗽是否伴有痰液", "近期接触过发热人群吗", "是否服用过退热药物" ], "initial_impression": [ "急性上呼吸道感染可能", "需排查流感等传染病" ] }这里面的“followup_needed”就是模型自己判定的待追问问题，程序解析后会继续发起下一轮对话。返回的“initial_impression”不会直接出现在病历里，只是推送给医生作参考。临床医生前期比较排斥AI生成的判断，但当他们发现AI的定向其实只是一个引导思路、不替代结论时，接受度反而逐渐高了。
预问诊的另一个细节是退出机制。患者可能在对话中途不耐烦，或者已经挂完号从线上转到线下。系统要在每一轮对话结束都保留草稿，患者随时可以退出，下一次进来继续，也能选择直接跳过，不给患者制造必须做完的压力。
3.2 诊后随访和健康宣教：让知识跑在正确的时间点上
如果说预问诊是“诊前”，那随访就是“诊后”。做完检查或者出院的患者，后续恢复情况没人跟踪，一直是医院的痛点。传统人工随访根本覆盖不了全部患者，只能抽查高风险人群。数字医生把这个空白补上了。
随访流程是这样设计的：医生开单时选择随访模板，系统当天生成第一版随访任务，按时间线自动给患者发消息。以产科出院后的随访为例，第一天询问出血量、体温、精神状态，第三天提醒新生儿黄疸观察方法，第七天推送产后恢复注意事项和情绪自评量表。每一条随访消息都是从院内知识库生成，并由对应科室医生审核过模板之后才上线的。
这里面的技术难点不是推送本身，而是异常识别。患者在回复里说“今天伤口有点红”、系统不能只回复一句“建议保持清洁”就结束，要能判断这可能是感染征兆，自动把对话升级到紧急提醒并提示患者尽快就诊，同时把这条记录标记为黄色标签，推送给护士站人工关注。我们用了一套分级响应规则：轻度问题由知识库回答，中度问题给出观察建议并预约复诊入口，重度异常直接触发人工电话联系。这套机制把大模型的判断能力和医学规则很好地结合了起来，比单纯让模型自己处理更稳。
3.3 辅助决策线索：医生工作台里的“AI提示”
外科医生听感最敏感的莫过于让他用AI做诊断。所以这块功能的定位，不是替代医生写诊断，而是帮医生扫一遍AI生成的提示，把有用的留下、没用的删掉。整个交互做得非常克制：医生打开病历页，右侧栏出现一条“AI参考”，列出患者主诉、关键症状、可疑诊断方向和鉴别要点，每条参考都挂着知识来源，医生可以展开看原文，也可以一键收藏到自己的专属学习库。
实现上，这条侧边栏内容由大模型基于预问诊结构化结果加检验数据生成，再用规则引擎过滤掉明显不合理的建议。规则引擎里有几条硬性红线，比如未成年人不开成人口径的用药建议、孕产妇不推荐无循证依据的检查、急性重症倾向必须急诊就诊。这些规则不是模型学出来的，是临床专家手工配置的，属于“机器跑得再快也不能越界”的护栏。
这个功能上线后意外地提升了医生满意度。原因是它帮医生省下了阅读长预问诊摘要的时间，同时把容易遗漏的鉴别诊断放在眼前。实际口径上我们也做得很清楚：AI参考只出现在医生本人工作台，不出现在患者端，不作为最终诊断依据，所有记录的采纳和修改都可追溯。
4. 试点、评估与迭代的真实玩法
4.1 选科室先看场景，不只看人情
项目最怕一开始就铺到全院，所以我们第一波只在两个门诊科室试点，一个是产科门诊，一个是儿童内科门诊。为什么选这两个，因为它们的患者咨询重复度最高、标准临床路径最明确，而且模型早期只做预问诊和宣教，不碰高风险诊断，风险相对可控。
试点科室选完，还要做一件事：跟科室主任和一线医生深度访谈，把他们的顾虑提前消解掉。医生最常问的问题是“这系统出错谁负责”，我们统一口径：AI只是辅助，正式医疗行为由医生完成，系统所有输出都带“供参考”字样的标识；再问就是“会不会增加我工作量”，我们用数据说话，预问诊摘要直接填充到病历模板里，医生只要确认修改，整体时间是节约而不是增加。
试点阶段还有一个容易被忽略的凶险点：用真实患者数据做模型优化必须格外小心。我们所有用于构建评估集的病历都做了脱敏，姓名、身份证、手机号、地址全部替换成模拟信息，而且只在脱敏后的样本上做模型调优，绝不拿原始数据直接喂提示词。
4.2 回归测试集：锁住模型质量的下限
医疗场景不能拿“感觉还行”来评判模型，必须有一套可量化的验收标准。我们组织临床专家和算法工程师一起构建了一个“黄金评估集”，包含一千多对问答和对应的评分标准。每对包含输入问题、标准答案、参考答案来源和评分维度，评分维度分为准确性、完整性、安全性、表达友好度四个方向。
每次升级模型、调整提示词或者扩充知识库，都要先跑一遍这个评估集。用脚本批量请求数字医生接口，再把回答导出交给标注团队打分，准确率超过阈值才允许上线。这个流程后来成了项目组的雷打不动制度，虽然每次跑全量要花一两个小时，但拦下了很多看似微小实则致命的问题。
重点说一个指标：安全性。准确率再高，也不能容忍一条可能误导患者用药的回答出现。我们专设了一个高危问题集，里面只放容易出事的题目，比如“孕妇能吃不”“儿童用量多少”“是不是癌”。这些题目的正确率必须满分，否则整个版本上线就得叫停。这套高标准也反过来逼着团队不断优化检索逻辑和兜底策略。
4.3 运营指标不能只看“AI答了多少”
评估模型是一回事，评估整个数字化服务又是另一回事。团队在立项时就定下来看四类运行指标：服务覆盖率、解决率、转人工率、人工介入成本。
服务覆盖率看的是有多少门诊量走了预问诊流程，一开始只有三成，稳定后推到八成以上；解决率看的是患者咨询里有多少能由数字医生完成闭环，完成闭环的定义是患者不再追问，或者追问转化成预约挂号，而不是系统里聊两句就丢；转人工率是安全红线，观察是否出现了模型不能处理的场景；人工介入成本则统计医生每份病历因为AI摘要节省出来的时间。
对比组设计上，我们用同一科室同一病种做前后对照，而不是随机分患者组，因为随机分组涉及患者体验不均，医院伦理审查会难过。前后对比虽然会引入一些干扰因素，但从运营视角看已经足够说明趋势：数字医生上线后，科室平均预问诊填写时间从五分钟缩短到两分钟，随访完成率提升了一倍以上，医护团队的线上重复咨询量明显下降。
4.4 迭代的节奏：算法、知识库、产品三位一体
系统上线后不是结束，反而是迭代工作的开始。每周会有一轮回溯例会，临床人员、产品经理和算法工程师坐在一起看上周的badcase。每次筛选出大概两三种典型问题，比如某个回答过于保守、某个药品说明改版后知识库没跟上，再决定是改提示词、改知识库、还是调模型。
知识库更新频率比想象中要高得多。院内制度、药品说明书、门诊流程一调整，知识库就得同步。我们建了一个知识库发布管理系统，更新内容先走临床审核，审核通过后形成新版本，部署推送到检索服务，旧版本自动归档。所有回答里的引用来源，都是知识库里的具体片段ID，一旦版本更新，引用也会跟着回溯，后续如果出现纠纷可以精准定位到是哪一版知识造成的。
模型本身的迭代反而不需要太频繁。预训练模型每半年升级一次，但日常质量提升主要靠提示词模板和检索策略的调整。这两者的调优成本低、见效快，适合小步快跑。
5. 这些坑，我替大家先踩过了
5.1 幻觉不是玄学，是没有兜底机制
最开始测试时，模型确实会在回答里混入“看起来合理但没依据”的内容。有次患者问“一岁孩子能不能喝蜂蜜水”，模型居然顺着上下文回答“适量可以”，实际上婴幼儿摄入蜂蜜有肉毒杆菌风险，这是明确的禁忌。这个case当时把团队吓出一身冷汗。
后来把所有回答都改成了“先检索再回答”的模式，并且加了三层兜底：第一层是知识库检索相关性过滤，查不到相关内容就不许回答；第二层是高危问题强制转人工，自动识别包括“孕妇、儿童、中毒、急救”这类高危关键词，直接给预案；第三层是回答末尾固定展示“以上信息仅供科普参考，不能替代面诊建议”。三层兜底上了以后，再没出现类似的高危错误。这个教训可以一句话总结：大模型本身并不可怕，可怕的是你把所有信任都交给它。
5.2 患者情绪复杂时，要让它学会慢下来
还有一类问题不是医疗知识性的，而是情绪性的。一些患者反复追问，并不是想得到一个标准答案，他真正需要的是“有人重视我这件事”。那个阶段我们发现，模型如果单纯追求效率，会在几次问答之后就给出“请及时就诊”的终止话术，给患者的感受非常冷漠，容易变成投诉来源。
针对这个问题，我们在提示词里加入了共情引导要求，让模型先确认患者感受，比如“听起来您比较担心宝宝的黄疸情况”，再给出处理建议。同时增加了一道情绪识别服务，模型判断患者表述中包含焦虑、恐惧、情绪激动等信号时，会切换成更温和的表达，并主动询问是否需要转到人工在线客服。这个细节看上去很小，对患者满意度的影响却很大。
5.3 审计与权限不能等出了事再补
医疗系统里最难的不是算法，而是权限和审计。刚开始我们觉得数字医生只是信息服务，访问控制简单做就行，结果信息科在验收时提了一长串整改意见：所有AI调用要记录完整日志、问题文本要先脱敏再作为优化样本、不同角色只能访问不同功能模块、模型后台要屏蔽session关联信息。这些需求一开始没设计的话，后期返工成本极高。
整改后我们落地了一套权限体系：患者端只能访问自己的对话记录，医生端能看到患者授权后的数据，运营分析人员只拿到脱敏统计结果，模型优化工程师仅能访问Quota脱敏样本库。所有对话的请求参数、返回内容、处理状态全部落日志，保留周期按院内数据管理规定执行。这套体系虽然增加了开发量，但它让数字医生项目在合规审查时真正站得住脚。
5.4 并发和延迟的控制要留足余地
技术上线前的压测数据很好看，并发两百没问题，但真到门诊高峰期，模型推理服务经常被老百姓的咨询量打成热点。后来分析原因是患者访问有明显的高峰期，集中在早上九到十一点和下午二到四点，并发模型预估完全失准。我们重新做了按时间段的扩缩容策略：高峰期前二十分钟预热扩容，门诊结束后自动缩容，同时给模型推理服务加了队列长度告警，太长就直接让前端弹“当前咨询量大，建议稍后再试”，避免用户傻等超时。
另一个容易踩的坑是流式输出和超时控制。患者端使用打字机式逐字输出，体验好但超时出错的概率也高，我们最后做了折中：按句输出，不按字输出，也就是检测到模型生成了一个标点符号就推送一句，这样既保留了流畅感，又减少了前端频繁渲染的压力。这个细节做与不做的差异，技术人员在真机上一试就知道。
6. 最后的一点私货体会
把这个项目做完，我的体会是：医院场景做AI，其实是在跟“安全感”打交道。患者要安全感，医生要安全感，信息科要安全感。大模型能力再强，如果不能让系统里每个角色都感觉到边界清晰、责任明确、退路充足，项目就很难走远。所以我在每次面对新技术都会问一个问题：它到底在帮人做决策，还是帮人做选择？人机共智的意义不在于用AI替代任何人，而在于把人的时间和注意力释放出来，放到真正需要人的地方。
如果你也在筹划类似的项目，我会建议从预问诊和随访这种低风险、高重复的场景切入，先跑通数据链路和协作机制，再往里走。千万别一上来就做一个“万能AI医生”，那样只会让所有人都害怕它。技术选型上优先考虑本地化部署和RAG，这能解决一半以上的合规和幻觉问题。迭代上把评估集建好，比调一万次模型参数都管用。我自己最满意的一个设计，其实是那条“AI参考只出现在医生侧，并且永远可以被一键删除”的规则。因为它让医生这张专业王牌，始终握在自己手里。
