企业官网建设流程全解析

这几年我落地了不少医疗行业的AI项目，有一个感受特别深：真正难的不是选哪个大模型，而是怎么把模型安全可控地接进医院的业务系统里。影像科、门诊医生工作站、患者端App、随访中心，每个系统都在说要接AI，但各自的接口规范不同、数据敏感程度不同、调用频率不同，如果不做一层统一治理，很快就会变成一团乱麻。这也是我为什么一直在推AI网关的落地，更准确说，是像MAI Gateway这类面向场景的AI接入治理方案。这篇文章不聊空概念、不摆大架构图，直接把这套方案在医疗行业的整体拆解、场景配置、部署要点和我踩过的坑一次讲清楚，给准备在医院里做AI落地的同学一点参考。

1. 医疗行业上AI，真正的卡点不在算法，而在接入

1.1 我在医院现场看到的真实情况

先说说医院里的实际状态。大多数医院的临床信息化建设走了十几年，HIS、电子病历、LIS、PACS、体检系统各自独立，数据模型和接口风格差异很大。大模型火起来之后，各科室的需求冒得很快：门诊想上智能预问诊和病历生成，影像科想做肺结节和骨折的辅助筛查，医务处想要临床知识库问答，随访中心想用AI批量生成随访脚本。需求听起来都合理，但到了信息科这里就很头疼。

头疼在哪儿？一是厂商杂。影像有影像的AI厂商，病历有病历的AI厂商，知识问答又可能接的是不同的语言模型，每家给的API格式不一样、鉴权方式不一样、限流策略也不一样。二是数据敏感。医疗数据必须留在院内，所有模型调用都要在院内网络闭环内完成，第三方SaaS基本不用考虑。三是管理缺失。没有统一的调用记录，AI到底被哪个系统用了、调了多少、输出过什么，信息科心里没底。

这些凑在一起，最直接的结果就是：每个业务系统各自对接各自的模型，密钥散落，日志分散，出了问题只能一家一家查。医疗行业的AI落地，算法选型当然重要，但真正决定项目能不能用得起来的，是接入这一层有没有治理能力。

1.2 网关这层到底解决了什么问题

用生活化的方式理解AI网关，可以把它看成医院访客系统的升级版。没有统一访客系统的时候，每栋楼门口各自设闸机，访客要到几栋楼就得办几张临时卡，安保记录也分散在各处。有了统一入口之后，闸机集中管理，一卡走全院，每次进出都有记录。

AI网关做的事情类似。它处在业务系统和模型服务之间，所有模型调用都从网关这一个口子走，网关负责鉴权、路由、限流、脱敏、审计。业务系统不再需要关心背后接的是哪个模型、API格式怎么兼容，只要按约定向网关发起请求就行。模型方也不用担心被各个业务系统直连导致密钥泄露，只需要信任网关这一个调用方。

但这里要强调一点：如果网关只是一个透传代理，那它给医疗行业带来的价值会很有限。真正让网关在医疗行业立住的，是“场景化”这三个字。

1.3 MAI Gateway的核心差异：场景化治理

MAI Gateway这类方案和普通API网关最大的区别，是它把“场景”作为配置和管理的基本单位。医疗场景不是一个笼统的概念，智能导诊、病历生成、影像筛查、知识问答、患者随访，它们对模型能力、响应速度、数据脱敏、输出格式的要求完全不一样。

比如智能导诊面向患者端，流量波动大、响应要求快、姓名和身份证号必须脱敏；病历生成面向医生工作站，输出要结构化、术语要准、必须有审计追溯；影像筛查面向院内影像数据，文件大、处理耗时、需要异步任务机制。如果所有调用共用一套策略，要么过于宽松导致风险，要么过于严格拖慢效率。

MAI Gateway的思路是把这些差异固化成“场景配置”：每个场景绑定指定的模型、提示词模板、脱敏规则、限流阈值、日志级别。业务系统调用时带上场景标识，网关自动套用对应策略。这样既解决了接入混乱，也解决了治理颗粒度的问题，信息科可以从场景维度看全院的AI使用情况。

2. 场景化方案该怎么搭：我的架构拆解思路

2.1 接入层、策略层、服务层，三层各管各的事

我在设计这类部署方案的时候，习惯把整个体系拆成三层，每层职责单一，方便后续扩展。

最底下是接入层，负责对接各种模型服务。医院里不太可能只有一家模型供应商，常见的是私有化部署的大语言模型、OCR模型、语音识别模型、医学影像模型，甚至可能是几个科室自建的模型。接入层要把它们在网关里统一注册成“模型实例”，统一鉴权方式、统一请求格式，屏蔽底层的API差异。

中间是策略层，这是场景化方案的核心。所有请求进来以后，先根据调用方携带的场景标识找到对应的场景配置，再依次执行鉴权、路由、限流、提示词注入、数据脱敏、内容审核、审计日志等动作。场景配置可以理解成一张策略清单，网关在转发请求前逐项执行。

最上面是服务层，用来承载与场景相关的增强能力。最典型的是RAG检索增强，问答场景需要先在院内知识库里检索相关资料再让模型生成；还有缓存服务、异步任务队列、定时批量任务。服务层做得好不好，直接决定场景的实际效果。

三层之间通过配置中心联动，新增一个场景不需要动代码，只需要在管理后台添加配置、绑定模型和策略，这正好匹配医院信息科人力有限、又要频繁响应临床需求的现实。

2.2 场景配置的本质：把人对AI的使用方式固化成规则

我经常跟客户讲一句话：场景化不是简单的“给场景起个名字”，而是把“人怎么用AI”翻译成“系统怎么管AI”。

怎么理解？临床医生用AI生成病历的时候，他心里有一整套隐含规则：只能基于本次问诊信息生成，不能自由发挥；诊断术语要跟院内术语库一致；涉及患者隐私的信息不能出现在对外输出里；生成的内容必须能被追溯。人要遵守这些规则靠培训和自觉，系统要遵守这些规则，就得靠网关把规则写进调用链路里。

落到配置上，一个完整的场景配置至少包含四块。第一块是模型绑定，明确这个场景用哪个模型、什么版本、温度参数等默认值；第二块是提示词模板，预置场景专用的系统提示词，约束模型的角色和输出规范；第三块是安全策略，包括脱敏规则、审核规则、敏感词库；第四块是流量策略，包括并发上限、超时时间、限流阈值。这四块组合在一起，才是一个可落地的场景配置。

2.3 私有化部署：医疗行业绕不开的底线

医疗行业的部署形态没有太多讨价还价的余地。患者诊疗数据、病历数据、影像数据属于高度敏感数据，行业中通行的原则是数据不能出院。这也决定了MAI Gateway在医疗行业的部署方式基本只能走两条路：要么整体部署在医院内网，要么部署在医院专属的私有云环境里。

我建议优先做院内内网部署。现在主流的网关方案都支持容器化交付，信息科只要有服务器资源，就能把网关和模型服务一起放到内网。网关与业务系统、模型服务之间的通信全部走内部网络，不依赖外部环境，某些情况下即使与外部网络断开，AI服务在院内依然可以正常使用。日志、审计数据、知识库全部存在院内的存储设备上，数据链路全程闭环。

部署形态上要注意管理面和数据面的隔离。管理面用于配置场景、查看监控、管理密钥，访问权限严格控制在信息科少数人手里；数据面承载实际的模型调用流量，按院内网络分区策略做访问控制。两部分即便部署在同一台物理机上，也要通过独立的服务端口和网络策略做隔离。

3. 五个典型医疗场景的落地拆解

3.1 智能导诊与预问诊：流量入口先打通

智能导诊是很多医院最早跑起来的AI场景，因为它在患者端、可见度高、需求明确。患者在医院的App或自助机上描述症状，AI初步判断应该挂哪个科室，甚至可以先完成预问诊，把信息推给医生。

这个场景的接入特点有两个。一是流量波动明显，一般早上八点到十一点是挂号高峰，其他时间相对平缓，网关需要调整并发上限和限流策略；二是输入输出都涉及个人信息，患者描述里带着姓名、手机号、身份证号是常态，网关必须在请求进入模型前完成脱敏，模型输出内容在回传前还要做二次校验。

实操上，我通常会把这个场景的网关超时时间设置在5秒左右，超过直接返回降级提示，避免患者端长时间转圈。限流按挂号时段动态调整，高峰时段对非核心问答接口适当收紧，保证核心导诊链路优先。每个请求的脱敏命中率要单独监控，如果某一段时间脱敏率为零但输入里明显有个人信息，说明规则可能漏了。

3.2 门诊病历生成：与医生工作站深度对接

病历生成是医生呼声最高、但对治理要求也最严的场景。医生在诊室里的操作节奏很快，AI要能把问诊对话自动转写成结构化病历，并且写进电子病历系统之前必须经过格式校验和术语核对。

网关在这里承担的责任，是病历数据的“出”和“入”两道关卡。请求出去之前，门诊对话里的冗余信息、口头语、重复描述要清洗掉，患者标识性信息要脱敏或者替换成内部编号；响应回来之后，要校验结构是否完整、必填字段是否缺失、诊断术语是否在院内术语库中，校验不通过的自动拦截并触发重新生成。

医院门急诊的电子病历通常会遵循行业通用的结构化标准，比如用HL7或FHIR这类数据交换规范对接。网关在转发时要把模型输出映射成规定格式再交给EMR系统，而不是让医生工作站直接对接模型原始的JSON。这个映射逻辑放在网关来做，后续切换模型时业务系统完全不用动。

3.3 医学影像辅助筛查：模型链路的编排与异步

影像AI和文本AI的调用模式很不一样。一张CT序列可能包含几百张DICOM图像，单次请求的Payload很大，处理耗时动辄几十秒甚至几分钟，走的不是同步请求-响应模式，而是“提交任务-异步回调”的模式。

MAI Gateway在影像场景里要解决的问题，一个是文件上传链路，一个是任务编排。上传链路方面，网关需要支持流式上传或者分片上传，避免大文件一次性载入内存导致服务崩溃；任务编排方面，网关要在提交影像模型前完成格式转换、序列筛选、质控检查，再进入模型推理队列，推理完成后通过回调把结果返回给PACS系统。

还有一个很实际的问题：模型版本迭代。影像模型更新后，不可能一次性全量切换，万一新版本在某个影像特征上表现异常，整个影像科都会受影响。我建议在网关里做版本灰度，先让5%到10%的请求走新版本，观察一个病例周期没有异常再逐步放量。

3.4 医疗知识库问答：RAG与多权限分组的组合

临床知识库问答是典型的RAG场景。医生问一个用药问题，AI不能光靠模型记忆回答，要先在院内知识库（临床指南、药品说明书、院内制度）里检索相关段落，再基于检索结果生成带引用的答案。

网关在这个场景里的关键点，一是RAG服务怎么对接，二是知识库权限怎么隔离。RAG服务建议作为网关服务层的一部分，检索逻辑可以复用，业务系统不需要各自搭一套向量检索；知识库权限隔离则是必需品，不同科室能看到的知识范围不一样，住院医师和主任医师的权限级别也不一样，这个权限控制要在网关层统一判断，而不是把整个知识库开放给所有调用方。

引用溯源是医疗问答区别于通用问答的一条硬要求。AI答完必须给出内容依据，比如引用了哪份指南的哪一节。这个要求需要在网关的提示词模板里强制约束，同时网关出口做校验，没有引用来源的答案直接拦截。

3.5 患者随访与健康管理：批量任务的治理

患者随访看起来不复杂，但它是批量调用最密集的场景之一。出院患者成百上千，随访中心不可能一个个手动打电话，AI生成随访脚本和随访记录汇总就成了刚需。

批量调用和实时调用的治理逻辑差异很大。实时调用要求低延迟，批量调用要求高吞吐和可控节奏。我通常会在网关里给随访场景配置批次级别的限速，比如每分钟不超过一定数量的请求，配合任务队列在夜间低峰期执行，避免大批量请求把模型服务打满，影响白天正常的临床AI使用。

随访内容还有一个容易踩的坑：AI生成的随访话术容易越界。比如患者说有点不舒服，模型可能会给出具体用药或者处置建议，这在随访场景里是不允许的，随访内容只能做提示就医、记录症状、分诊引导，不能直接给诊疗结论。网关的内容审核规则要单独配置医疗场景的边界话术库，命中敏感边界就转人工复核。

下表是我在项目中沉淀下来的场景速查，配置新场景时可以先对着这个表捋一遍需求：

4. 从零部署MAI Gateway的实操记录

4.1 上线前先把信息盘点做扎实

我在部署这类网关方案之前，最花时间的不是安装配置，而是信息盘点。需要摸清楚三张清单：模型清单、业务系统清单、网络分区清单。

模型清单要记录院内用到的所有模型服务，包括模型名称、版本、调用地址、鉴权方式、并发上限、平均响应时间。业务系统清单要记录哪些系统要接入AI，分别涉及哪些场景，调用方的IP网段和运维负责人是谁。网络分区清单要确认业务系统、网关、模型服务分别处于哪个网段，防火墙放行策略谁负责、审批流程是什么。

这三张清单看起来基础，但能少走很多弯路。我碰过项目进行到一半发现影像模型和网关跨了两个网段，防火墙审批流程走了快两周的情况。前期不盘点清楚，后面全是返工。

4.2 网关实例的初始化与模型供应商接入

信息盘点完成之后，就可以开始部署网关实例。现在主流方案基本都支持容器化部署，通过编排平台一键拉起。配置上建议给网关实例单独划分资源，别跟业务系统抢资源，因为网关是全院AI调用的咽喉，它一旦抖动，所有AI场景都会跟着抖。

网关起来以后，第一步是把模型服务注册进来。在MAI Gateway的管理后台里，每种模型供应商对应一套接入配置，核心就是填调用地址、API密钥、模型标识，再加上该模型的默认参数，比如温度、最大输出长度。这个环节有两个容易忽略的点：一是要把模型供应商侧的限流上限填准，网关要做本地限流，不能等上游模型把请求打回来才发现超限；二是密钥在网关里要做加密存储，建议配置定期轮换策略。

模型接进来之后，先做一轮连通性验证。用一个最小请求逐一对每个模型发起调用，确认鉴权、响应格式、超时设置都正常，再进入下一步。这一步别省，很多“接入后第一个请求就报错”的问题都出在证书或鉴权头这类细节上。

4.3 用场景模板把策略固化下来

模型就绪之后，就到了场景配置的环节，这也是MAI Gateway方案最核心的操作。我会在管理后台针对每个业务场景创建一个场景模板，然后按前面说的四块内容逐项配置。

拿病历生成场景举例：模型绑定选好指定的病历模型；提示词模板里写入“你是一名资深临床医生，基于以下问诊记录生成结构化的门诊病历草稿，要求使用院内标准诊断术语，不添加任何未在问诊记录中出现的信息”；安全策略里配置脱敏规则，对所有患者姓名、身份证号、手机号做替换，并开启内容审核；流量策略里设置单请求超时10秒，单个医生工作站的并发上限为5。

每个场景配置完成之后，都要先通过管理台调试入口跑一遍测试用例。我习惯准备一套每个场景专用的测试数据，比如脱敏测试用带个人信息的话术，病历测试用一段真实结构但全部打码的问诊记录，影像测试用样例DICOM文件。测试全部通过再开放给业务系统，这个习惯能拦下绝大多数低级问题。

4.4 业务系统切换流量与上线监控

场景配置验证完毕，剩下的就是让业务系统从原来的直连模型改为走网关调用。这一步的核心操作是替换调用地址：把原先指向模型服务直连地址的调用改成指向网关的统一入口，并在请求参数里带上场景标识。

切换流量不建议一步到位。我一般是先选一个科室、一个系统先切，观察几天，确认链路稳定、监控指标正常，再逐步扩大到全院。监控指标重点看几个：请求成功率、平均延迟、错误码分布、限流命中次数、脱敏命中率、审计日志写入量。这些指标要建一个独立的监控面板，信息科每天扫一眼，比出问题再排查有效得多。

另外别忘了密钥轮换和权限收口。业务系统侧原来可能存了好几个模型的API密钥，切换到网关之后，模型侧的密钥要全部回收或作废，只保留网关这一个调用凭证。这一步做不干净，前面的治理工作就白费了。

5. 踩坑实录：医疗场景里最常遇到的几个问题

5.1 跨网段调用慢得离谱，先查防火墙放行策略

第一个让我印象深刻的坑是网关和影像模型服务跨网段之后，调用延迟从几十毫秒涨到了几百毫秒，偶尔还会超时。一开始怀疑是网关性能问题，查了半天CPU、内存都没异常，最后发现是防火墙会话表对长连接配置了很短的闲置超时，模型推理耗时长，连接被中间设备断开后要重新握手，延迟自然飙升。

这类问题现在我会在部署初期就盯住，网络策略里把几个关键配置确认掉：网关到模型的端口放行状态、防火墙会话超时时间、负载均衡设备的空闲连接保持时间。排查手段就是看网关里单条请求的耗时拆解，确认时间耗在哪个跳段，别自己瞎猜。

5.2 提示词里的患者信息，脱敏规则不是万能的

脱敏最容易翻车的不是身份证号、手机号这种规则明确的字段，而是自由文本里嵌套的零散信息。比如患者在问诊记录里写“我母亲去年在XX医院住院”，这中间的人称关系、机构名称都可能构成识别维度，但普通的正则脱敏根本识别不出来。

我的处理办法是实体识别预脱敏加后置二次脱敏的组合。请求进入网关后，先用医学命名实体识别把姓名、机构名、地名这类实体识别出来做替换，送到模型的内容已经是脱敏版本；模型返回的内容里，模型可能会把脱敏后的信息又还原成自然表述，所以出口还要再做一次扫描，发现疑似敏感信息就拦截或者召回重新生成。脱敏命中率要纳入日常监控，规则更新要有审批记录。

5.3 影像大文件把网关内存击穿，改流式上传

影像场景上线初期，上传一个几百MB的DICOM文件时，网关进程直接内存溢出重启。原因是模型服务要求整包上传，网关默认把整个请求体读进内存再转发，文件一大内存就不够用了。

解决方向是改造成流式上传，网关边收边转，不在内存里堆积完整文件；如果模型服务不支持流式接收，则在网关和模型之间加一个对象存储中转区，文件先落到存储再通知模型服务拉取。同时给上传接口设置文件大小上限、分片数上限和上传超时时间，超出直接拒绝并返回明确提示。影像大流量场景，网关的内存配置还得留足余量，至少按峰值文件大小的两倍来估。

5.4 审计日志要能对接院内已有的安全平台

医疗机构对网络和数据安全的要求普遍严格，信息科往往有统一的安全审计平台，会要求各系统的操作日志接入平台做集中分析。网关默认的审计日志格式通常偏技术化，字段命名和经验对不上，导致运维得手工做字段映射，既费时又容易漏。

这种情况我建议在网关部署前就和信息科确认好审计平台的接入方式，一般是Syslog或者HTTP上报，提前把场景ID、调用方、模型名、脱敏状态、请求耗时这些核心字段的映射关系定义清楚。网关侧开启审计日志自动上报，平台侧建好对应的日志源，联调几笔真实请求确认字段解析无误再算完成。

5.5 模型灰度放量太快，差点全院翻车

某次影像模型发布新版本，灰度配置到30%观察了一天觉得没问题，直接放量到100%，结果第二天有医生反馈某些切面识别结果质量明显下降，紧急回滚到旧版本，好在只影响了半天。事后复盘，问题出在观察周期不够，影像场景的病例类型分布有周期性，一天的时间根本覆盖不到各类典型病例。

模型版本灰度，周期和放量梯度都要保守。我现在的习惯是：第一周放5%，观察各类病例和错误率指标；第二周放到20%；稳定后再逐步到50%、100%。每次放量都保留回滚入口，旧版本模型实例至少保留两个版本周期，方便随时切回。

把常见问题整理成一张速查表，方便一线运维同学直接对照：

6. 给准备上车的团队几句实在话

最后说点题外的、但我觉得比技术更重要的东西。MAI Gateway这类场景化AI网关方案，真正改变的不是调用方式，而是医院里AI项目的推进方式。以前临床科室提出AI需求，信息科只能当作一个个独立的项目去对接、去维护；现在有了场景化网关这一层，AI能力变成了可配置、可管理的公共服务，新增场景不用再做一遍原子化对接，整体效率完全不一样。

我个人的建议是：不要一上来就追求大而全，先把一个高频、低风险的场景跑通。智能导诊或者知识库问答都是很好的切入点，流程走通、监控跑起来、信息科熟悉了这套工具的运维方式，后面再横向复制到病历、影像、随访这些更复杂的场景就会顺很多。网关上线其实不是终点，把场景配置管理、模型灰度、审计合规这些机制形成日常习惯，才是这套方案在医院里真正生根的开始。