FDE-医院上 AI-从分诊和用药解读开始，别一上来就想做诊断

医院上 AI：从分诊和用药解读开始，别一上来就想做诊断

一、先泼一盆冷水：Demo 做得快，不代表能上线

现在用现成接口搭一个“看起来挺聪明”的医疗问答 Demo，几天就够了。但这恰恰是最容易让人产生误判的地方。Demo 证明的是可能性——模型能听懂人话、能说出像样的医学句子。而生产环境要的是确定性——同样的问题问一百遍，答案得稳；接口挂了得有退路；答不上来时必须明确告知，绝不能硬编。所以我们后来改了一种做法：前期把力气花在验证技术链路和最小可行场景上，而不是急着写功能。需求设计和方案评审阶段投入的精力，要跟后面测试迭代的量级相当，形成两个高峰，中间那段“开发”反而不是最重的。甲乙双方也不再是签合同、交活走人的接力关系，而是混编成一个团队，一起扛上线后的事。

这套做法没什么玄学，纯粹是医疗这个行业的容错率太低，逼出来的。

二、切入口怎么选：找"有规可循、错了也不死人"的环节

很多项目出问题，根源在于试图一次性把 AI 铺满全流程。正确的做法是先画一张业务大图，然后老老实实回答三个问题：

谁在用？省的是谁的时间？ 如果说不清终端用户和具体省下的环节，这个场景基本可以搁置。

知识有没有可靠的来源？ 药品说明书、地方医保政策这类东西，必须有明确、可更新、归医院自己管的底稿。没有底稿的场景，模型只能靠训练记忆里的东西说话，那就管不住了。

出问题时怎么退回去？ 模型幻觉、接口超时、知识库没命中——这三种情况各准备一条退路，想不清楚就别立项。

按这三条筛下来，结论通常很一致：

暂缓的：直接给诊断（依据太复杂、不容错）；涉及真实支付（走既有信息系统，AI 只做引导）；医生端的核心决策（法律责任问题，现阶段不碰）。

可以上的：诊前分诊挂号（本质是引导，有一定容错空间，还能实打实减轻分诊台压力）；诊后用药和报告解读（有说明书和规范当底稿，逻辑闭合）；医保政策问答（文档边界清晰，适合做检索增强）。

分诊和用药解读之所以是首选，不是因为它们技术含量高，恰恰是因为它们技术含量不高但价值实在。先把这两个跑通闭环，团队才有资格谈后面的事。

三、技术层面：怎么把"概率模型"压成一个"可用的工具"

这一部分没有银弹，全是约束。

知识库要做物理隔离，不能靠模型自觉。 医保库和用药库必须彻底分开。用户问报销比例，检索就只能落在医保库里，不允许它顺手去调药品的性状知识。不同领域的知识一旦交叉污染，就会出现那种“说得特别自信但完全不着边”的回答。

历史处方要有时效判定。 一年前的处方不该作为当前用药建议的依据，代码里需要写死这条规则，而不是指望模型自己判断时间远近。

上下文要设边界。 患者描述症状往往是碎片化的，实测下来完整表达意图大概需要十轮左右。我们留了十二轮的滑动窗口，保留原始对话以保证意图抓取精度；超出窗口就压缩成背景摘要，但患者 ID、科室 ID 这类关键标识绝不允许在压缩中丢失。

涉及系统动作时，模型不许自己编答案。 查实时号源、下挂号指令，必须通过接口去调 HIS 的实时数据。模型只负责理解意图和组装参数，真正的执行权留在确定性系统手里。这是整条链路上最重要的一个设计——让模型的推理和系统的执行之间只有一条合法通道。

四、安全红线：提示词约束不住生产环境

有个数据值得记住：单靠提示词去约束模型行为，合规率大概只有七到八成。剩下那两成在日常聊天里无伤大雅，在医疗场景里可能就是事故。

所以敏感操作必须在代码层面加钩子。模型识别出“挂号”意图后，不能由它直接生成结果文本，而是强制跳转到人工核验或固定表单界面，由程序逻辑收尾。写入 HIS、取消挂号、删除记录，全部照此处理。

另外还有三条比较朴素但很管用的做法：每轮请求静默注入当前时间、所在科室等环境信息，防止模型时空错乱；医生 ID、排班 ID 视作不可丢弃字段，在上下文流转里全程携带；主备模型热备，主模型因限流或故障响应异常时自动切备用，用户侧无感知。

五、上线不是终点，Bad Case 才是真正开始积累资产的地方

评测不能只看单轮准确率。拿“头晕”挂什么科来说，重点要看模型会不会追问——有没有问伴随症状、既往病史、持续时间，最终能不能落到心内科而不是泛泛地推个神经内科。这种追问能力，才是医疗 Agent 和普通问答机器人的分水岭，也应该是评测集里的核心指标。

每个 Bad Case 归因时只分三类：提示词理解偏了，就改提示词；工具调用参数或返回结构不对，就修接口层；知识缺失或过时，就补知识库。分类标准统一了，复盘才不会变成互相甩锅。

这么干一段时间，产出的就不只是一个应用，而是一套可以复用的东西：框架、模板、常见场景的解决方案、封装好的工具和接口。这些才是跨科室复制时真正省时间的部分。

六、最后说人：AI 进来之后，医护和管理者干什么

未来的医院大概率会分层运转：最上面是多模态的交互入口，往下是定义好边界的各类角色型 Agent，中间是负责协同调度的编排层，再下面是运行环境和算力模型。这套结构听起来有点重，但它的实际意义在于——把 Agent 的职责写清楚，人的职责也就清楚了。

人退到幕后，主要做三件事：定目标（AI 的业务边界和考核指标）、立规范（它必须遵循的临床指南和技术标准）、划红线（绝对不许碰的地方）。剩下的执行交给系统。

说到底，AI 的价值不在于取代谁，而在于按业务逻辑把工作流重新排一遍。人和系统真正变成一支队伍的时候，效率的提升才会发生在那之前，所有的讨论都只是在试工具。