我们做了一个AI临床助手,但医生几乎不用

我们一直在思考AI如何落地临床应用，就会形成一种条件反射：看到医生在几个系统之间来回切换、复制粘贴、改病程、查Deepseek、补出院小结，我们就会忍不住想，能不能让AI来干？

最好是医生少点几下鼠标，护士少追几次材料，信息科也少接几个“这个系统能不能再智能一点”的电话。

这就是我们做这个 AI 临床助手的初心。

我们不是想做一个替医生诊断的“神器”，也不是想证明大模型有多厉害。最朴素的想法是：医院里已经有很多数据，医生又有大量重复文书工作，如果 AI 能在安全边界内帮忙整理出院小结、生成诊断框架、优化病历文书，大家可能都会轻松一点。

后来系统做出来了。

完全院内网部署，数据不出院，Nginx 能转发，FastAPI 能接请求，SSE 能流式输出。本地 vLLM 也跑起来了，两张 NVIDIA A10 承载 Qwen3.6，通过 OpenAI 兼容接口给后端调用。

账号、权限、科室、Session、历史会话、多轮追问、提示词后台、操作审计、隐私过滤、脱敏校验，也都做了。

从工程角度看，它已经不是一个网页 Demo。

但上线试点近一个月后，我们看使用记录：真实活跃医生只有 8 位，模型调用 88 次，分布在 17 个自然日。

标题里的“没人用”，不是说一次都没人点，而是它没有进入医生每天自然打开的工作流。

这件事提醒我们：系统能上线，和大家愿意用，是两回事。

我们做了什么

这个项目部署在医院内网，不调用公网 API。前端由 Nginx 提供静态页面，后端是 FastAPI，数据库是 MySQL，推理服务是本地 vLLM。

模型侧用两张 A10 做张量并行。为了在有限显存里跑 35B 级别模型，我们用了 AWQ 4bit、FP8 KV cache、prefix caching 和 MTP 推测解码。

业务上，我们没有为每个任务单独部署模型，而是做了“科室 +任务”的 Prompt 矩阵。不同科室维护自己的提示词，不同任务走不同配置。

系统支持病历文书的四类入口：

我们原来怎么想

我们最初的设想很直接。

医生输入患者资料，选择“鉴别诊断”，系统给出诊断思路和补充检查建议；选择“病程记录”，系统生成一版文书草稿；选择“出院小结”，系统整理住院经过和出院医嘱。

如果结果不合适，医生继续追问：再简洁一点，改成主任查房语气，补充检验变化，按病程格式重写。

我们以为，只要模型部署在内网，任务入口做出来，提示词写细一点，医生自然会用。

现在看，这个想法有点理想化。

我们把“能生成”理解成了“能省事”。但临床工作里，真正耗时的往往不是写一句提示词，而是把患者这次就诊的上下文整理出来。

数据给我们的提醒

在两个科室试点近一个月，真实使用数据并不好看。

8 位真实医生，88 次模型调用，50 次首次提交，38 次多轮追问。

任务里用得最多的不是“鉴别诊断”，而是自由对话。自由对话 37 次，病程记录 21 次，鉴别诊断 12 次，出院小结 5 次。

这个结果一开始有点意外，后来觉得很正常。

医生并不总是想点一个固定按钮，然后拿一段完整答案。更常见的需求是：把这段改成病程格式，把检查结果揉进去，这段太像机器写的，再自然一点，按我的意思再改一版。

自由对话多，说明医生真正需要的是“生成之后继续改”，而不是一个一次性按钮。

所以，这套系统不是完全没人用。它的问题是没有成为刚需。

问题不只在模型

试点后我们越来越清楚：最大问题不是模型不够强，而是临床数据没有进入工作流。

医生要从 HIS、LIS、PACS、电子病历、医嘱系统里复制患者信息、检验结果、影像报告、用药情况和既往病程，再粘贴给 AI。

这一步太重。

AI 看不到完整病史，看不到检验趋势，看不到影像报告原文，看不到当前医嘱，也不知道哪些数据是今天的，哪些是三天前的。模型只能基于医生贴进来的材料生成内容。

医生少贴一项关键检验，AI 就不知道。医生没贴最近影像报告，系统也不会主动提示缺失。

所以，聊天框不是临床系统的终点。

医生、护士、科室管理者真正需要的，不是多一个页面，而是少一次查找、少一次复制、少一次返工。

为什么大家没有每天打开它

原因其实很具体。

入口不在原有系统里。医生每天打开的是 HIS、电子病历、医嘱、LIS、PACS，不是额外的 AI 页面。

复制粘贴太多。一次病程记录可能需要病史、查体、检验、影像、用药和治疗经过。让医生手动拼上下文，本身就是工作量。

生成结果还要核对。医疗文书不能直接信任模型输出，医生必须逐句看、逐项改。前面复制，后面核对，如果总成本不低于原来，系统就留不住人。

名字也有影响。“AI 诊断助手”听起来很强，但诊断是高责任场景。模型依据是什么，漏掉了什么，结果能不能信，出了问题责任怎么界定，医生自然会谨慎。

更关键的是，系统没有数据来源和更新时间。它不能告诉用户“最近 24 小时缺血常规”“没有取到影像报告”“当前医嘱未同步”。它也不能直接定位当前患者，更不能回写或半自动导入病历。

于是它就成了一个外挂工具，而不是临床工作台的一部分。

下一步怎么改

我们仍然认为方向是对的，但不能一上来就做开放式自主 Agent。

临床场景里的 Agent，首先应该是受限、可审计、固定工作流优先的。

第一步，先修基础。把隐私落库链路重新梳理一遍，统一 schema，补齐依赖清单，让任务参数真正生效，建立测试集和审计策略。

第二步，做患者任务工作台。医生先选择授权患者和本次就诊，系统自动展示基础信息、关键病情、检验异常、数据更新时间和缺失项。

第三步，只读接入 HIS、LIS、PACS、EMR 和医嘱系统。通过服务端 Encounter Context 绑定医生、患者、本次就诊、科室、权限和使用目的。模型不能自由传 `patient_id`，真实患者标识必须由后端校验后注入。

第四步，先做固定工作流。比如病程记录：拉取近 24 或 48 小时病程、检验、生命体征、医嘱；规则层标记变化和异常；系统提示缺失项；模型生成草稿；医生确认。

第五步，建设可信工具层。临床评分、ICD 查询、指南 RAG、文书结构校验、药品说明书检索，都要有版本、来源、审计和测试。

第六步，再做受限 Agent。模型只能在白名单工具内选择，限制工具轮次、总超时、调用次数和任务范围。所有工具失败都必须明确展示，不能假装结果完整。

等这些边界清楚以后，再考虑把 HIS、LIS、PACS、指南检索、临床评分等能力封装成可复用工具服务。

结尾

我们做的 AI 诊断助手，却没真正用起来。

这个结果不体面，但它帮我们找到了下一步真正该做的事：不是再做一个更会聊天的页面，而是把 AI 接回临床工作流。