前几天跟一家三甲医院信息科的朋友喝茶，他苦笑着说：去年全院就3个AI试点，今年各个科室加起来报了十几个，放射科要影像报告辅助，病案室要病历质控，门诊要智能分诊，每个科室都拿着一套模型接口来找我，协议不一样、超时时间不一样、连返回字段都不一样，这还没上线我就先疯了。他说完这句话我特别有共鸣，因为这两年我们做医疗AI项目，几乎每个客户都会撞上同一堵墙：模型好找，落地难。后来我们逐渐收敛出一套打法，就是围绕AI网关做场景化改造，内部代号就叫MAI Gateway，MAI取的是Medical AI的意思。这套方案不是什么高深的新算法，而是把模型接入、路由、编排、安全这些"脏活"统一收口，让医院真正用得起、管得住AI。这篇文章就把我们的设计思路、落地细节、踩过的坑完整梳理一遍，给正在做医疗AI落地的同行做个参考，尤其是医院信息科的朋友，应该能直接拿去用。
1. 医疗行业AI落地的真实现状：为什么缺一道"门"
1.1 模型越来越多，接口越来越乱
先还原一下医院里现在普遍存在的集成乱象。假设一家中型医院同时上了肺结节筛查、病历内涵质控、智能导诊、超声报告辅助四个AI系统，传统做法是每个业务系统直接调用各自的模型服务。体检系统直连影像模型的HTTP接口，HIS系统拉一条WebService去调病历质控模型，小程序端又自己定义一套JSON格式调用导诊模型。表面上看每个系统都能转，但时间一长全是坑。
第一个坑是接口协议不统一。有的模型服务返回XML，有的返回JSON，有的返回纯文本，而且字段命名规则完全是"各说各话"。比如同样的"患者主诉"，A系统叫chiefComplaint，B系统叫mainSymptom，C系统直接是字符串。业务系统要针对每一种模型单独写适配代码，接一个新模型就相当于重做一次集成。
第二个坑是模型升级的影响面没法控制。算法团队把模型从V1升级到V2，输出格式稍微变了一点，下游三个业务系统全部报错。算法团队说自己没改接口，业务系统说自己没改代码，最后吵到信息科。这件事的本质是缺少一层中间人，模型和业务之间没有一个稳定的"翻译"和"缓冲"。
第三个坑是完全无法统一观测。每个模型服务自己记录自己的日志，调用量、成功率、平均耗时这些数据散落在不同的服务器上。领导问一句"我们AI系统用得怎么样"，信息科拿不出来一张整体视图，只能临时去各个系统里翻。这种状态下做容量规划、故障排查都非常被动。
所以我一直跟人强调，医疗AI落地第一步不是选模型，而是先想清楚模型和业务之间用什么连接。AI网关要解决的，正是这个最基础也最容易被忽略的连接问题。它的核心职责可以概括成一句话：让所有业务系统只面对一个API，让所有模型服务只面对一个入口。
1.2 医疗场景对网关的"特殊要求"
有人说，那不就是一个API网关吗，Kong、APISIX拿过来改改不就行了？这话只对了一半。通用API网关解决的是流量治理问题，比如路由转发、限流熔断、负载均衡。但到了医疗领域，网关要处理的远不止流量，还有三件通用网关几乎不碰的事。
第一，数据形态极其复杂。医院里的数据不只是普通的结构化数据或JSON，还有HL7消息、FHIR资源、DICOM影像、非结构化的病历文本、时序波形信号。一个病历结构化场景，输入可能是从HIS里导出的纯文本，里面夹杂着各种口语化表述、缩写、错别字；到了报告生成场景，输入的又是影像所见的结构化条目。网关如果只做HTTP转发，根本处理不了这些五花八门的数据形态，它必须具备医疗数据的理解能力和转换能力。
第二，医疗术语体系是另一个世界。普通行业做语义理解，识别出"头疼"就够了，但医疗场景里，模型输出的病症描述还需要对齐到ICD编码或院内科室字典。比如患者说"胸口闷"，智能分诊场景里，网关要把这个词匹配到心血管内科还是呼吸内科，得先理解医院实际的科室设置、医生擅长领域，这些信息通常散落在门办、医务处和挂号系统里。通用网关完全不知道这些，但场景化网关必须把这些知识内置进去。
第三，安全和隐私要求比其他行业高一个量级。医疗数据属于高敏数据，患者姓名、身份证号、联系方式、主诉信息，任何一条流出院区都可能引发严重问题。所以网关必须支持全链路私有化部署，数据不出内网；必须做请求内容脱敏，让算法团队在调试时看不到明文敏感信息；必须保留完整的操作审计日志，每次模型调用都能追溯到人和系统。
也就是说，医疗行业的AI网关不只是一个流量入口，它更是一个"懂医疗数据的场景编排中枢"。这是整个MAI Gateway方案和普通API网关最本质的区别。
2. MAI Gateway场景化方案的核心设计思路
2.1 从"转发代理"到"场景编排中枢"
前面说的那些痛点，做过技术方案的人都会想到加一层网关，但如果只是加一层通用转发层，很快会发现网关变成了一个"哑管道"，所有脏活还是落在业务系统头上。我们的思路是把它升级成一个会干活的中枢。打个比方，如果医院是一栋大楼，模型是各个专科诊室，那么通用网关是楼下的门禁，而场景化网关是预检分诊台——它不只是放人进去，还会先问清楚患者什么症状、该去哪个诊室、需要做什么初步检查，必要时还帮忙把检查结果带回来。
MAI Gateway的具体实现分三层，每一层都有自己的职责。
接入适配层解决"怎么连"的问题。这一层负责把不同类型的模型服务包装成统一格式，不管是本地私有化部署的大模型、云端的商业化API，还是院内自研的小模型，对上层都暴露成标准接口。同时适配医疗行业常见的通信协议，比如HIS系统推过来的HL7消息可以通过这里解析、转换。这一层还有一个很实用的功能是协议降级，当某个模型服务不稳定时，自动切换到备选模型，切换过程对业务系统透明。
场景编排层解决"怎么用"的问题，这是MAI Gateway和普通网关拉开差距的地方。它把模型调用拆解成可编排的步骤：先调用A模型做文本预处理，再把结果交给B模型做实体抽取，然后把抽取结果丢给规则引擎做校验，最后组织成业务系统需要的格式。这几个步骤可以用配置文件描述，不需要写代码。这样算法工程师可以快速调整场景逻辑，信息科工程师也能看懂。
安全管控层则是贯穿所有场景的底座。统一鉴权、租户隔离、敏感信息脱敏、调用审计、流控降级，全部在这一层实现。这一层做得越厚，业务系统就越轻松。我们见过很多项目，安全功能散落在每个模型服务自己实现，有的模型服务甚至把请求日志原样打到文件里，患者身份证号直接进了日志系统，这非常危险。所以MAI Gateway把安全能力集中收口，默认强制开启，不允许关闭。
2.2 场景化模板：让不懂大模型的工程师也能接入
很多信息科工程师第一次接触大模型，最大障碍是提示词工程。他们不是不会写代码，而是不知道怎么写一段让模型稳定输出结构化结果的提示词。所以我们在网关里做了场景模板机制。
一个场景模板包含四部分内容：输入输出协议、提示词模板、校验规则、兜底策略。
输入输出协议定义了业务系统应该传什么参数、模型返回什么格式。比如病历结构化场景，输入是病历文本和病历类型，输出是JSON数组，每个元素包含字段名、字段值、置信度和原文片段。这部分本质上是把模型不确定的输出"框"成业务系统稳定可用的结构。
提示词模板是预写好的、经过反复调试的系统提示。我们在模板里会明确要求模型"只输出JSON，不要解释，不要使用Markdown"，还会给模型提供字段的中文定义和取值格式。模板里还会放置少量示例，让模型模仿输出格式。这些内容看似简单，实际是影响模型输出稳定性的关键。
校验规则是拿模型输出和真实世界做对齐的闸门。比如诊断结果字段，模型输出"冠心病"没问题，但如果是"冠状动脉粥样硬化性心脏病"，要不要归一化成ICD编码I25.1，就需要校验规则和术语映射表配合完成。规则引擎在这里承担的是"填空题"角色，模型负责理解语义，规则负责保证规范。
兜底策略处理的是模型输出完全不可用的情况，比如调用失败、输出字段缺失、置信度极低，网关会返回一个预设的缺省结果，并标记"需人工处理"，同时触发告警给管理员，而不是让业务系统糊里糊涂拿到一份空结果。
2.3 为什么不用现成开源网关改一改
这个项目当初立项时，团队内部也争论过，直接用APISIX或者Spring Cloud Gateway改造不就行了吗，为什么要自己搭一套场景化网关？后来越推演越觉得不靠谱。
通用API网关确实把流量治理做得很成熟，但它的数据平面是"流量导向"，没有"场景编排"的概念。你可以配置一个请求转发到某个upstream，但没法配置"先调用模型A提取实体，再调用模型B做归一化，最后判断结果是否符合规则"。这些逻辑如果硬塞进网关，就得写一堆自定义插件，最终维护成本比业务系统里写适配代码还高。
更重要的是，开源网关不了解医疗数据。HL7消息怎么解析、FHIR资源怎么映射、病历文本怎么分句、ICD编码怎么归一，这些能力都不可能从通用开源项目里长出来。与其在Kong之上堆一个"医疗能力插件包"，不如直接围绕医疗场景从内到外设计。
还有一个现实原因是，医院环境通常不允许随便引入太多开源组件。很多院内网络是隔离的，安全要求高，部署一个新组件要走流程、过测评。我们最初也试过基于开源网关做定制，后来发现光是让安全部门接受那一堆依赖就消耗了大量时间，而且定制代码跟上游版本冲突严重，升级困难。换成自研场景化网关后，组件边界清晰、依赖少、安全可控，部署反而顺利了很多。
3. 四个典型医疗场景的落地实操
3.1 病历文书结构化与质控辅助
病历结构化是很多医院积累了大量非结构化文本后最想解决的问题。门诊病历、出院小结、护理记录，几十年下来全是自由文本，医生想查某个用药方案的历史数据根本没法查，科研统计更无从谈起。
我们通过MAI Gateway做的方案流程大致这样：HIS系统通过接口把病历文本推给网关，网关先把文本做脱敏处理，把患者姓名、身份证号、手机号替换成占位符，再交给模型做分句和段落识别。为什么要先分句？因为病历文书有固定的结构，比如"主诉""现病史""既往史""辅助检查""初步诊断"这些段落，模型要先识别出段落边界，后续抽取字段才不会串。
字段抽取是模型发挥理解能力的地方。比如现病史里有一句"患者3天前无明显诱因出现胸痛，呈压榨样，向左肩放射，含服硝酸甘油后缓解"，模型需要抽取出发病诱因、症状特点、放射部位、缓解方式这些结构化字段。抽取完成后，结果要过一遍校验规则：诊断编码必须能在ICD字典里查到，日期字段必须符合日期格式，数值型字段必须能转成数字，任何一条不满足都会被标记为存疑。
实际操作中我们发现一个很有用的细节：提示词里要求模型输出每个字段的原文片段以及置信度，这样医生在审核时能看到"这个字段是从哪句话抽出来的"，而不是直接看一个光秃秃的抽取结果，信任度会高很多。整个流程跑完后，网关把结构化结果回传给HIS系统，系统自动写入扩展字段或者展示在医生工作站上。
我们在一家医院做了小范围测试，纯规则方式下科室字段的抽取准确率大概75%，加上大模型理解能力后能到90%左右，但距离临床完全不用审还有差距。所以方案里一定要保留人工复核环节，这在医疗场景是不可逾越的红线。
3.2 智能分诊与就医引导
门诊分诊是一个看起来简单、做起来坑很多的场景。最简单的做法是让患者描述症状，直接丢给大模型问"应该挂哪个科"。但我们接入后发现，这种裸调式方案根本没法直接用。
第一个问题是大模型不了解医院自己的科室目录。市级医院和县级医院科室设置不一样，同一个医院不同院区科室也不一样。模型训练时学到的是通用医学知识，它可能建议患者挂"神经内科"，但这家医院的神经内科只收住院不收门诊。所以我们做了RAG检索增强，把院内科室介绍、医生擅长、号源情况整理成知识库，模型生成建议前先从知识库里检索相关内容，把结果拼进提示词里再让模型做决策。
第二个问题是一次对话往往不够。患者说"肚子疼"，你到底该让他挂消化内科还是急诊科，取决于疼痛位置、剧烈程度、持续时间、有没有伴随症状，模型需要会追问。MAI Gateway里的分诊场景模板内置了多轮对话管理器，由网关保存每一轮的上下文，并结合追问模板引导患者补充信息。如果患者说"疼痛剧烈、出冷汗"，网关会直接生成"建议立即去急诊"的强提醒。
第三个问题是系统边界必须清晰。智能分诊不是诊断，它只是就医引导建议。所以模板里强制要求模型的输出包含免责声明，并且把"建议科室"和"风险提示"分开。这个约束不是靠提示词自觉实现的，是网关在模型输出后加了内容过滤规则，检测到高风险关键词时把普通建议升级为紧急提醒。
3.3 报告草稿生成：影像与超声报告辅助
影像科报告辅助是医疗AI里落地意愿最强的场景，因为报告量实在太大了。超声科一个医生半天要做二三十个患者的检查，每个患者口述报告，旁边助手录入，医生嗓子都哑了。我们的方案不是做自动诊断，而是做报告草稿辅助，目标是把医生从打字中解放出来。
整个流程是：PACS系统把检查所见的结构化条目推给MAI Gateway，比如"肝左叶可见一枚大小约0.8cm强回声光点"，网关会把这些条目和历史报告模板、诊断规范一起交给大模型，生成一份包含诊断意见的报告草稿，再推回PACS供医生修改确认。注意这里推给模型的是"检查所见"而不是"原始影像"，模型不做影像识别，只做文本到文本的辅助生成。影像识别仍然由专门的影像AI模型处理，这就规避了大模型在影像数据上不可控的问题。
报告草稿生成最需要规范的其实不是模型，而是输出格式。每家医院的报告模板都不一样，有的医院要求先写形态描述再写功能判断，有的要求诊断意见里必须写"未见明显异常"而不是"正常"。这些规范不能靠提示词约束，我们把它做成了报告格式模板，在网关里定义好字段顺序、必备段落和默认表述，模型生成后由网关做格式归一化。
还有一个容易踩的坑是"AI幻觉"。大模型在报告生成时可能会把检查所见里没有提到的内容也写进诊断意见。比如检查所见只描述了肝脏，模型却在诊断意见里补了一句"胆囊未见明显异常"。这种幻觉在文本辅助场景里非常危险。我们做了双层防护：第一层在提示词里明确要求"诊断意见只能基于检查所见，禁止推断未见描述的内容"；第二层在网关里做词级校验，把检查所见里出现过的解剖学术语提取出来，诊断意见里如果出现完全未覆盖的术语会触发警告。
注意：医疗报告涉及诊疗行为，无论模型生成质量多高，都必须保留医生审核确认环节。逻辑上可以把"辅助草稿"理解成"输入法联想"，而不是"自动驾驶"。
3.4 术后随访与健康宣教自动化
随访是医院各个科室都喊累但都必须做的重复工作。传统方式是护士出院前叮嘱、一周后电话回访、一个月后再回访，大量时间是填表格和记问题。我们用MAI Gateway把随访流程自动化，流程上有了质的改观。
流程的第一步是定时触发。网关每天凌晨从HIS系统拉取前一天的出院患者清单，结合出院小结生成每位患者的个性化随访计划。第二步是生成随访内容。针对手术患者，模型读取出院记录里的手术名称和出院医嘱，自动生成"术后饮食注意""伤口观察要点""复诊时间提示"等个性化问题。这一步最大的价值是个性化，以前护士给所有患者发的宣教内容都是同一张单子，现在模型能根据患者实际情况生成不同内容。
第三步是多轮交互。患者通过小程序或短信回复随访问题，网关里的会话管理模块负责串联上下文。比如患者第一轮回复说"伤口有点疼"，网关会在下一轮追问"疼痛程度如何、有没有红肿渗液"，这比传统单选问卷体验好太多。第四步是结果回流与预警。患者的回复内容经过模型判断和规则匹配，如果发现危险信号，比如"发热""渗液明显"，网关会立刻向护理部推送预警工单，同时标注"需人工介入"。
这个场景对网关的依赖点在于：它解决的不只是一个模型调用，而是定时任务、会话状态、敏感内容过滤、失败重试、结果分类一套完整流程的组合。如果每个环节都由业务系统自己开发实现，工作量非常大，而且每个科室的随访逻辑又不一样，根本没法复用。用场景模板管理后，新增一个科室的随访方案只需改配置，成本低了很多。
4. 从0到1搭建MAI Gateway的实操要点
4.1 模型侧：本地私有化部署优先
做医疗项目，模型放哪是最先要定的问题。我们的默认建议是：涉及患者数据的场景，一律本地私有化部署；只有完全不接触敏感数据的场景，比如公开医学知识问答，才考虑调用云端API。
原因很简单，医疗数据的问题不是"你敢不敢用公有云"，而是"出了事你能不能证明自己尽到了管理责任"。本地部署至少能保证数据不出院区，责任边界非常清晰。算法团队拿到的训练数据、调试样本都应该是脱敏后的。
模型选型方面，我们踩过一些弯路后形成了自己的参考标准。轻量级场景，比如分诊对话、宣教内容生成，第一批参数规模在7B到14B之间的模型量化后跑在单张24GB显存的卡上就够用；复杂场景，比如病历结构化、疑难报告辅助，建议用更大参数规模的模型，哪怕推理速度慢一点，也要优先保证输出质量。速度问题可以靠网关的异步队列缓解，但质量问题很难靠工程手段补回来。
性能估算上给一个简单参考：2张24GB显存GPU卡部署一个14B量化模型，并发控制在8到16路左右，生成长度控制在500字以内，日均处理量大约在1万到2万次调用之间，足够覆盖一家三甲医院的单场景业务量。这个数字是经验值，实际会因为输入长度、输出长度、并发配置浮动，但可以作为前期规划的起点。
实操心得：前期测试阶段没必要一步到位买高端卡。先用消费级显卡把小流量场景跑通，验证接口和流程没问题，再采购生产级GPU。很多项目前三个月根本没多少真实流量，过早投入只会造成资源浪费。
4.2 网关与院内系统的集成方式
医疗行业常见的系统集成方式有三种，我们做方案时都要评估一遍。
第一种是REST/WebService接口对接，适合实时性要求高的场景，比如医生在门诊工作站里保存病历时实时触发质控。网关暴露统一REST接口，HIS系统按照约定格式POST数据，网关同步或异步返回结果。优点是开发简单、定位问题方便，缺点是双方系统都要在线，高峰期性能压力大。
第二种是消息队列对接，适合批量处理场景，比如夜间跑全量病历质控。HIS把一批病历文本丢到消息队列里，网关从队列消费，处理完再把结果写回结果队列或结果表。优点是一边不用在线等待，天然能削峰填谷，缺点是链路多了一层，排查问题稍复杂。
第三种是数据库中间表对接，适合没有接口通道的老系统。HIS把待处理数据写入中间表，网关定时轮询，处理后回写结果表。优点是实施门槛最低，缺点是数据实时性差、容易出现脏数据。我们一般建议优先用前两种，中间表只用于系统实在无法改造的情况。
集成过程中还有个隐蔽的坑是院内系统的时间格式、编码格式不统一。有的系统用GBK，有的用UTF-8，有的日期用YYYYMMDD，有的用时间戳。这些细节在测试环境根本暴露不出来，到了生产环境才现原形。所以我们要求网关的适配层必须显式声明各业务系统的字符编码和日期格式，在解析时做强制转换，不能依赖默认值。
4.3 安全能力：脱敏、审计、权限一个都不能少
安全这块我单独拎出来说，因为它在项目里的优先级永远是第一，但也是最容易被甲方忽略的。有些医院信息科一开始觉得"我们内网很安全，不用做脱敏"，等出了问题才知道后悔。
脱敏分两个层面。第一层是请求前脱敏，也就是在数据进入模型之前，用正则和命名实体识别把文本里的姓名、电话、身份证号替换成特殊占位符。第二层是日志脱敏，这句话必须加粗强调：绝对不能把模型请求的原始报文直接打到日志系统里。我们有一次排查模型输出异常，顺手翻了网关日志，发现患者主诉文本整段躺在日志文件里，那一刻后背是发凉的。从那以后，所有落盘的日志都强制经过字段过滤，敏感字段只会保留脱敏后的版本，需要定位问题时再按权限申请查看原始数据。
审计能力要能回答三个问题：谁在什么时间调用了哪个模型、目标数据是什么、模型返回了什么。这三个问题串起来就是一条完整的追溯链。我们建议关键调用和异常调用都保留审计记录，正常调用保留统计信息即可，避免日志膨胀淹没真正需要关注的内容。
权限控制的目标是让每个角色只能看到自己该看的。临床医生能看到自己科室的调用记录，算法工程师能看模型返回结果但不能看原始病例，管理员能看全部但不能导出。这个设计一开始执行会遇到阻力，特别是算法团队会抱怨不方便，但医疗项目里权限收得越紧，后面审计时越从容。
5. 常见问题与排查技巧实录
5.1 模型输出格式不稳定怎么办
这是上线后最频繁的工单。明明提示词里写了"只输出JSON"，模型偶尔还是会在JSON前后加一段说明文字，或者输出一个Markdown代码块把JSON包起来。业务系统一解析失败，报错就甩到信息科。
我们的处理套路分三步。第一步看原始输出，确认是格式问题还是内容问题。第二步在网关里加输出清洗器，如果模型返回了带Markdown代码块的内容，先把代码块边界识别出来，剥掉外壳再解析JSON。第三步在清洗之后加schema校验，字段缺失自动补null、字段类型错误尽力做类型转换，实在校验不过就重试一次，重试仍失败走兜底返回。
其实这类问题背后还有一个更根本的解法：优先选用支持结构化输出的推理框架。现在不少模型服务支持JSON Schema约束，让模型严格按照指定schema输出，格式异常率能大幅下降。MAI Gateway在接入层也预留了这类能力，模型服务支持的话就直接开启。
5.2 高峰期并发上去了网关卡死
门诊的高峰时段非常集中，周一到周五上午9点到11点，晚上7点到9点，并发量突然飙升。有一回随访消息推送和门诊分诊同时撞上来，网关里的线程池被打满，所有请求排长队，业务系统的表现就是"转圈圈"。
排查下来发现根因是同步调用占用了大量线程：模型推理本身就要几秒，线上线程池只有20个，高峰期40个请求排队，平均响应时间拉到30秒以上，超时重试又加剧了拥堵。
解决办法是两条腿走路。第一，把非实时请求全部异步化，网关收到请求后先返回一个任务ID，处理完成后通过回调通知业务系统。分诊随访这类场景用户根本感知不到多等了零点几秒，但系统压力天差地别。第二，给不同场景设置不同的优先级和限流阈值。门诊分诊这种患者正在等待的实时场景，配额给高一些；夜间全量病历质控这种批量任务，配额给低一些，闲时再提高并发。
还要在网关层做熔断。当某个模型服务的错误率连续超过阈值时，网关直接短路该模型一段时间，快速失败而不是让请求继续夯在源头。等模型服务恢复健康后再自动放量，这个机制可以避免连锁故障。
5.3 "模型不准"的排查套路
医生反馈最多的就是"这结果不准"，但"不准"其实是一个特别模糊的描述。做过AI项目的人都知道，不先定义清楚什么叫"准"，排查就是无头苍蝇。我们的排查套路是先建立评测集，再定位问题层级。
具体做法是：从真实数据里随机抽50条样本，先让医生打标标准答案，再让网关跑一遍系统流程，把输出结果和标准答案做对比，找出模型输出和标准答案不一致的条目。然后逐条分析不一致的原因，通常落在三个层面。
第一层是输入质量问题。病历文本里如果有大量OCR识别错误、患者口语化表达、医生手写体的转写错误，模型再强也会被带偏。这种情况优化模型没用，要优化输入数据质量，比如在预处理阶段做错别字纠正。
第二层是提示词问题。模型能力没被发挥出来。具体表现是提示词里没有给出输出的详细规范，模型理解不了字段边界，只能自由发挥。这种情况调整提示词、增加示例的效果立竿见影。
第三层才是模型能力不足。前面两层都排除了，模型仍然在专业术语处理上出错，这才考虑换更大的模型或者引入医疗术语词典做后处理。
我把这个排查顺序称做"数据、提示词、模型"三级排查，建议做成团队内部的标准作业程序，避免一遇到"不准"就陷入"换模型"的循环。
5.4 场景模板与科室实际需求不匹配
场景模板的问题在于，我们设计时参考的是通用流程，但每个科室有自己的习惯。比如产科随访关心的是恶露、哺乳、新生儿黄疸，骨科随访关心的是关节活动度、伤口恢复，模板里的问题当然不一样。如果每个科室都要求开发定制，项目就变成了无底洞。
我们的应对办法是模板版本化和字段可配置化。模板本身就是一组配置文件，包含问题库、规则集、输出格式三块，新增科室时先复制一份基础模板再修改配置。模型调用逻辑完全不用动，只是输入到模板里的内容不同。
后来我们还给网关加了一个"模板测试台"功能。配置好一个新科室模板后，可以先在测试台里模拟几轮对话，看看模型在新增问题类型上表现如何，确认没问题再发布到生产。这个功能虽小，但极大降低了科室上线新场景的心理门槛。
6. 最后聊几点个人体会
这个项目做下来，我最大的体会是：AI网关在医疗行业的核心价值不是"网关"两个字，而是"场景化"三个字。一个转发代理解决不了医院真实的问题，真正有用的是把模型能力揉进一个个医疗业务流程里，让医生和护士感觉不到模型的存在，但工作确实变轻松了。
如果你想在院内推这套方案，我建议不要贪大求全，先选两三个高频、痛点明确的场景跑通，让临床科室体感明显，后面推广阻力会小很多。还要记住，医疗AI落地一半靠技术，另一半靠流程。模型输出再准，如果医生不相信、不用，它就没有价值。向一线医生解释清楚"模型能干什么、不能干什么、出错了谁来兜底"，比调十个提示词都重要。
最后再分享一个小经验：方案设计时多跟信息科和临床科室一起坐一坐。信息科懂系统架构，临床懂业务痛点，AI团队懂模型能力，三方坐在一起才能把场景边界定清楚。我们最初几版方案全是问题，就是因为只在办公室对着接口文档设计，没亲眼看医生怎么用系统。后来改为每一项新功能上线前都去科室待半天，还真的提前发现了好几个上线后必然返工的设计漏洞。这些比任何技术选型都重要，但也最容易被技术团队忽略。
