夜雨聆风
真正的平台能力，必须既能服务自己的系统，也能服务竞争对手的系统
文章简介
上一章我们讨论了医院需要的不是一个聊天框，而是一套完整的AI生产系统。
但建设AI平台以后还有一个更加关键的架构问题：
AI能力应该直接写进手麻系统、重症系统和中央监护系统，还是应该独立出来？
我的答案很明确AI必须被拆成独立模块。
病情小结，术前评估，术中预警，术后质控，转归分析，智能排程。
这些能力不应该只属于某一套软件。
它们应该由统一AI平台生产。
再通过标准接口嵌入迈瑞自己的手麻系统、重症系统和监护平台，也能够接入其他公司的业务系统。
这看起来是在帮助竞争对手。
实际上它可能是迈瑞把AI能力迅速推向全国医院。
并建立医疗AI平台地位的最有效路径。
⸻
最容易走的路是把AI直接写进现有产品
迈瑞已经拥有或正在发展的软件产品。
可能包括：手麻系统，重症系统，急诊系统，中央监护系统，设备管理平台。
每个产品团队都拥有自己的临床场景。
当AI能力开始成熟以后。
最自然的做法是：
手麻团队开发术前评估AI。
重症团队开发危重患者总结。
监护团队开发智能报警。
急诊团队开发病情分诊。
表面上看这样离场景最近，开发速度也可能最快。
但是如果每个系统都各自建设AI功能。
很快就会出现新的问题：
每套系统分别连接模型，分别管理Prompt，分别建设知识库，分别开发任务队列，分别处理结构化输出，分别做日志、审核和评价。
同一种AI能力被重复开发多次。
同一位患者在不同系统里可能得到不同结论。
模型升级一次所有产品线都要分别修改。
这不是AI平台只是把AI功能分散到了更多软件里。
⸻
AI一旦与业务系统绑死能力边界也会被绑死
假设术前病情小结直接写在迈瑞手麻系统内部。
那么只有购买迈瑞手麻系统的医院才能使用这项能力。
但现实是全国已经有大量医院在使用其他厂商的手麻系统。
这些医院可能很认可迈瑞的AI能力。
却不愿意为了使用一个AI模块立即更换整套手麻系统。
原因很简单：
已有系统积累了大量历史数据。
医护人员已经形成使用习惯。
与HIS、LIS和设备的接口已经完成。
更换核心系统的成本和风险很高。
如果迈瑞AI只能依附迈瑞手麻系统存在。
那么它的市场范围就被现有手麻系统的市场份额限制了。
AI本来可以服务全国医院，却因为绑定某一套软件，只能服务其中一部分客户，这是一种不必要的自我设限。
⸻
AI模块化不是简单做成几个按钮
所谓模块化不是把不同AI功能，分别放进几个菜单。
而是让每一种AI能力成为边界清楚、可以独立调用的服务。
例如术前病情小结模块，接收经过标准化的患者资料，输出结构化病情摘要、风险信息和待核查项目。
麻醉风险评估模块接收病历资料和床旁评估数据，输出ASA分级建议、麻醉风险、依据和缺失信息。
术中智能预警模块接收实时生命体征、设备数据和手术阶段，输出风险等级、可能原因和处理提示。
术后质量分析模块接收术中记录、用药、生命体征和术后转归，输出质量指标、异常事件和改进建议。
智能排程模块接收手术申请、人员、手术间和资源信息，输出排程建议和冲突提示。
每个模块都有明确的输入标准，输出格式，权限范围，审核流程，版本信息，调用接口。
它不需要知道最终结果显示在迈瑞手麻系统还是其他公司的业务页面中。
业务系统负责提供场景和交互，AI模块负责生产标准化能力。
⸻
同一套AI能力应该服务迈瑞自己的多个系统
独立模块化以后一项AI能力不必重复开发。
例如患者病情总结。
可以出现在：手麻系统的术前访视页面，重症系统的患者总览页面，急诊系统的接诊页面，中央监护平台的患者详情页，医生移动端的任务列表。
不同系统需要的内容深度可以不同但底层可以复用：数据准备，模型路由，RAG，Prompt框架，引用溯源，结构化输出，质量评价。
这会明显降低重复研发。
也能够保证不同系统对同一患者的基础事实理解一致。
否则手麻系统说患者正在服用抗凝药，重症系统却没有识别出来，中央监护平台又给出另一套风险结论。
医生面对的不是智能协同而是多个AI互相矛盾。
⸻
AI模块也必须能够接入其他公司的手麻系统
这一步最有战略意义。
假设一家医院已经使用其他厂商的手麻系统。
迈瑞可以通过本地适配层。
获取经过授权的患者资料和业务上下文。
然后由独立AI平台完成：
病情小结，术前风险评估，术中趋势分析，术后质控。
结果再通过标准接口嵌入原有手麻系统页面。
或者以独立小程序、侧边栏、工作站和移动端形式展示。
医院不需要先更换原系统就能够购买和使用迈瑞AI。
这会把销售逻辑从先替换整套系统，才能使用AI。
变成先用AI解决最迫切的问题，再逐步进入更多流程。
后者的部署阻力显然更小。
也更适合目前医院信息系统高度分散的现实。
⸻
服务竞争对手的系统会不会削弱迈瑞自己的软件？
这是一种很自然的担心。
如果迈瑞AI可以嵌入其他公司的手麻系统。
会不会帮助竞争对手提高产品能力？
会不会让医院更没有必要更换迈瑞手麻系统？
短期看确实可能存在这种影响。
但更深一层看。
如果迈瑞拒绝开放医院也不会因此自动更换原有系统。
它们可能转而选择其他独立AI公司。
原手麻厂商自己开发的AI。
医院内部团队建设的工具。
或者其他开放平台。
迈瑞失去的不只是一次手麻系统销售。
而可能是进入这家医院AI流程的机会。
真正需要选择的不是帮助不帮助竞争对手，而是迈瑞愿意只做自己产品内部的AI功能。
还是愿意成为整个行业都需要调用的AI能力提供者。
平台公司的目标不是让所有外部系统都消失。
而是让不同系统在需要关键能力时都愿意连接自己的平台。
⸻
真正的平台必须能够在竞争对手的环境中创造价值
一家产品公司通常希望用户全部购买自己的产品。
一家平台公司则需要接受现实世界的异构性。
微软的软件运行在其他品牌电脑上。
云平台服务彼此竞争的软件企业。
支付平台连接不同商家和应用。
它们的价值并不来自消灭所有外部产品。
而来自成为不同产品之间共同依赖的基础能力。
迈瑞如果希望AI成为平台，就不能只问怎样让AI帮助迈瑞手麻系统卖得更多？
还应该问怎样让全国不同手麻系统、重症系统和监护平台都能够调用迈瑞AI？
当竞争对手的系统也需要迈瑞提供的模型治理、临床知识库、风险评估和质量分析能力时。
迈瑞获得的就不再只是一套软件订单，而是更高层的平台位置。
产品追求占领一个系统，平台追求成为许多系统都离不开的基础能力。
⸻
AI模块可以独立销售形成新的产品入口
传统医疗软件销售经常需要完成一个较大的整体项目。
招标周期长，接口建设复杂，更换成本高。
AI模块化以后可以形成更轻量的产品组合。
例如医院可以先采购：
术前病情小结模块。
围术期风险评估模块。
术后质量分析模块。
监护报警优化模块。
科研数据提取模块。
这些模块可以按照：
平台授权，年度订阅，患者数量，手术量，床位数量，AI任务调用量，或者私有化部署服务收费。
医院先从一个明确场景开始。
验证效果以后再扩展到其他模块。
这比一开始要求医院更换整套系统。
更加符合医疗软件的实际采购和推广规律。
⸻
AI独立销售反而可能带动迈瑞软件
假设一家医院原来使用第三方手麻系统。
后来部署了迈瑞术前评估和术后质控AI。
使用一段时间以后医院会逐渐接触到迈瑞的：统一患者上下文，任务中心，知识库，AI审核流程，质量评价体系，数据平台。
当医院未来准备更换手麻系统时。
迈瑞自己的手麻系统因为与AI平台原生整合，部署更简单，数据更完整，体验更统一，自然会获得更大优势。
这就形成了一条新的路径：
过去通过硬件带入软件，现在也可以通过AI带入软件。
AI不再只是现有产品的附加功能，而成为进入医院、建立信任和扩大产品组合的新入口。
⸻
AI模块还可以带动设备生态
当AI开始分析实时生命体征、设备状态和临床阶段以后。
数据质量会变得越来越重要。
第三方设备可以通过标准接口接入。
但迈瑞自己的监护仪、麻醉机、呼吸机和输注泵可以提供更完整、更稳定、更低延迟的数据。
还可以实现更深层协同：患者信息自动写入，设备状态自动同步，报警数据统一上报，采样频率更完整，设备参数语义更准确，断点数据自动补传。
这样，平台对第三方设备保持开放。
迈瑞硬件又能够提供更好的原生体验。
医院不必因为部署AI被迫一次性更换所有设备。
但在以后采购新设备时会更重视与现有AI平台的协同程度。
开放兼容负责扩大平台边界，原生协同负责放大迈瑞硬件优势，两者并不冲突。
⸻
但必须防止AI模块成为新的接口项目
模块化并不意味着每接入一家第三方系统。
都重新开发一套专属AI版本。
如果这样做只是把过去的软件定制问题，转移到了AI平台。
真正的模块化必须建立在统一标准上。
第三方业务系统需要提供患者身份，当前就诊信息，业务场景，必要病历数据，用户权限，结果接收地址。
AI平台则按统一方式返回：
任务状态，结构化结果，引用依据，风险等级，人工审核状态，版本信息。
医院差异和厂商接口差异由本地适配层处理，AI核心模块不做医院专属修改。
新增一家医院应该主要完成：
接口适配，字段映射，权限配置，流程配置，而不是重新训练一套模型，重写一份核心Prompt，或者复制一套AI服务。
⸻
AI模块之间也需要保持边界
AI平台内部不能把所有任务做成一个无所不能的大模块。
不同场景的输入、风险和审核要求不同。
例如病情小结可以提前批量生成。
术中预警需要实时处理。
正式术前评估必须由医生签名。
质量分析可以在术后异步完成。
智能排程又涉及人员和资源优化。
所以各模块应该共享底层能力，但保持业务边界。
共享的是：模型路由，Prompt管理，RAG框架，任务队列，引用溯源，质量评价，权限审计，成本统计。
各自独立的是：
临床目标，数据范围，输出结构，审核规则，部署节奏，底层能力统一。
上层模块独立这样既能复用平台。
又不会让一个模块的修改影响所有业务。
⸻
开放出去之前还要建立明确的安全边界
AI接入其他厂商系统以后数据流向和责任边界会更复杂。
必须提前明确：谁有权发起任务？平台能够读取哪些数据？第三方系统如何验证身份？AI结果由谁审核？结果写回哪里？出现错误以后如何追溯？不同医院的数据是否严格隔离？第三方系统能否访问平台内部Prompt和模型？接口调用是否全部留痕？
因此模块开放不能只是提供几个API。
还需要：统一认证，最小权限，租户隔离，数据加密，接口限流，版本兼容，调用审计，安全认证，服务等级协议。
真正可销售的AI模块必须同时是一项可管理、可审计的企业服务。
⸻
迈瑞最应该掌握的不是某个模型，而是模块标准
模型更新速度很快。
今天使用Qwen，明天可能切换DeepSeek，以后还可能使用迈瑞自己的专用模型。
如果AI模块与某个模型绑定。
模型变化一次整个产品就要重构。
迈瑞真正应该掌握的是模块的长期标准：
临床任务怎样定义，需要哪些输入，输出结构是什么，证据怎样引用 医生怎样审核，效果怎样评价，接口怎样调用，结果怎样回写。
这些标准稳定以后底层模型可以不断更换，上层业务系统不需要跟着变化。
模型决定一次能力上限，模块标准决定平台能否长期扩展。
⸻
可以形成一个怎样的产品结构？
未来迈瑞可以把AI能力分成三个层次。
第一层：AI基础平台
提供模型、Prompt、RAG、任务、审核、评价、成本和版本管理。
第二层：标准AI能力模块
例如：病情小结，术前风险评估，术中预警，术后质控，智能排程，科研数据服务。
第三层：业务系统嵌入组件
为迈瑞和第三方系统提供：
API，SDK，标准页面组件，侧边栏，移动端入口，小程序。
这样，同一个AI模块既可以原生进入迈瑞手麻系统，也可以通过组件嵌入第三方手麻系统，还可以作为独立工作台销售。
医院按照自己的现状选择接入方式，迈瑞则始终维护同一套核心AI能力。
⸻
写在最后
AI如果直接写进每一套业务系统短期看起来开发更快，长期却会形成新的孤岛。
手麻系统拥有自己的AI，重症系统再建设一套，中央监护平台又开发第三套。
功能重复，标准分裂，模型升级困难，也无法面向第三方市场独立销售。
如果我是迈瑞软件系统架构师，我会从一开始就把AI能力拆出来。
建设成边界清楚、接口统一、可以独立部署和销售的模块。
它可以服务迈瑞手麻系统，嵌入迈瑞重症系统，连接中央监护平台，支持急诊和其他业务。
也能够接入其他公司的手麻系统和医院软件。
因为真正的平台能力，必须既能服务自己，也能服务竞争对手的系统。
这句话看起来像是在让出产品边界。
实际上它是在争夺一个更大的市场。
只服务自己的软件，AI只能成为产品功能。
能够服务整个行业的软件，AI才有机会成为平台。
未来迈瑞的竞争优势不一定是全国医院都必须使用迈瑞的全部系统和全部设备。
更现实、也更有力量的目标可能是：
无论医院使用谁的手麻系统，无论设备来自哪一家厂商。
只要它需要围术期AI能力，就会想到迈瑞。
到了那一步AI模块不仅能够独立创造收入。
还会反过来带动迈瑞的软件、设备和服务生态。
这才是平台战略真正的价值。
知而后行，行而求知。
从手术室到机房，从临床到系统。记录一名麻醉医生关于医疗AI、医院信息化与持续成长的探索。
—— 医路智行录