从“蚂蚁阿福”到安诊儿：AI医疗商业化提速与上市公司新战局

【摘要】AI医疗在政策、技术与产业多方共振下加速商业化，“蚂蚁阿福”与“安诊儿”正重构产品形态和上市公司竞争格局。

引言

AI医疗这几年走过了一个很典型的技术曲线。前期是算法和论文驱动，更多停留在影像读片、辅助诊断等单点突破，现在则进入一个明显不同的阶段，开始直面真实用户和真实付费场景。

一端是像“蚂蚁阿福”这样的 C 端产品，切入体检报告解读和健康管理，在应用商店冲到免费榜前列，流量和口碑双重出圈。另一端是以“安诊儿”为代表的医疗大模型和国家级中试基地，背后是顶层设计、医保机制和基础设施的系统升级。两者叠加，构成了当前 AI 医疗商业化提速的关键窗口。

对于开发者、架构师和技术决策者，这一轮 AI 医疗并不只是一款产品的爆红，而是产业栈从底层算力到上层业务逻辑的一次系统再布局。理解“蚂蚁阿福”这种解释型 AI 医疗的产品结构，结合“安诊儿”这类行业级大模型和地方产业集群的推进，有助于看清上市公司在这一赛道的新战局和可落地的技术路径。

● 一、AI 医疗的关键窗口期与结构性机会

1.1 供给压力转向效率压力

过去很长时间，医疗信息化更多在解决有无问题，例如电子病历、HIS、影像归档等基础系统建设。如今在老龄化和慢病负担加重的背景下，矛盾开始从绝对供给不足，转向效率和质量的结构性问题。

门急诊量高位运行，医生人均问诊时长被不断压缩，体检机构和基层医疗机构长期处于“检查做得多、解释做得少”的状态。大量体检报告、化验结果、病历记录被沉淀为“冷数据”，很少参与后续健康管理和医疗决策。

在这样的供需结构下，AI 不再只是锦上添花，而是天然指向几个高价值空间，比如体检报告解释、问诊记录结构化、辅助决策和科研赋能。这些环节数据量大、规则相对清晰，又长期缺乏人力投入，是典型的“性价比优势”场景。

1.2 技术条件从单点算法走向大模型平台

早期 AI 医疗项目多围绕单点算法建设，例如肺结节检测、眼底病筛查等，模型训练高度依赖单一模态和人工设计特征。现在行业基础已经出现明显变化。

一方面，医疗大模型快速演进，主流模型已经具备较强的中文医疗语义理解能力，能处理问诊对话、结构化病历和指南文献，并在推理链条上做出接近住院医水平的分析。

另一方面，多模态能力开始在真实医疗场景落地。图像、文本、语音、表格数据可以在统一框架下处理，支持“拍一张体检单就能解释”的体验。这给面向 C 端的健康助手和面向 B 端的智能临床工作站都提供了新的可能性。

配合各地正在建设的算力集群和医学数据平台，大模型不再只是实验室里的原型，而是可以通过 API、微调和工具链快速嵌入业务系统，成为一个可重用的“智能中枢”。

1.3 商业化窗口的现实含义

华福证券等机构的研报已经明确把当前阶段定义为 AI 医疗商业化落地的关键期。这里的关键不在于一个单点技术突破，而在于三个维度的同步成熟。

一是政策侧给出了相对清晰的应用边界和鼓励方向。国家层面的“人工智能 加 医疗卫生”实施意见，将 AI 应用拆解到基层服务、临床诊疗、患者服务等多个环节，并给出可被验收的场景清单。

二是支付和价格机制开始承认 AI 价值。国家医保局将“人工智能辅助诊断”纳入病理类医疗服务价格项目立项指南，未来进入医保目录的空间逐步打开。

三是 C 端需求被真实验证。以“蚂蚁阿福”为代表的产品在短时间内取得可观的下载量和活跃度，说明在健康科普、体检解释、就医决策这些接近生活的场景，用户已经愿意和 AI 建立稳定交互关系。

综合来看，AI 医疗从“是否有用”的探索阶段，转向“如何稳定、合规、可持续落地”的工程阶段，技术团队需要更重视整体架构和运营设计，而不是单点模型指标。

● 二、“蚂蚁阿福”样本：解释型 AI 医疗的产品结构

2.1 定位与场景 穿透体检后半场

“蚂蚁阿福”由蚂蚁集团推出，定位是面向普通用户的 AI 全科健康助手。它的核心目标不是充当线上医生，而是做一件现实医生很难持续投入精力做好的事，把复杂医疗信息翻译成普通人能听懂并能执行的健康建议。

应用围绕三个主场景展开。第一类是用户拿到体检报告后的集中焦虑期，阿福提供报告上传、智能结构化、异常项解释和风险等级提示。第二类是日常小病小痛或长期慢病管理场景，通过文字或语音问答帮助用户梳理症状和可能路径。第三类是健康科普和生活方式管理，以问答和随访形式推动用户做出一些可行的小调整。

真正有差异的地方在于产品选择了从 体检报告“二次解释”切入，而不是单纯做问答机器人。机构负责“查”，阿福负责“讲清楚并给行动建议”，两者之间形成互补关系。

2.2 体检报告解释的技术链路

从架构视角看，体检报告解释能力背后是一条相对完整的数据和推理链。可以将这一链路拆解为几个关键模块。

2.2.1 多模态采集与结构化解析

用户与阿福交互的入口形态比较多，可以手动输入检查指标，也可以直接上传报告图片或 PDF。

系统在接收端要做两件事。第一步是 版面识别与 OCR，识别出体检报告里的表格结构、项目名、数值、参考范围等元素。第二步是 语义标准化映射，把不同机构、不同模板中的项目映射到统一的指标字典，例如把“空腹血糖”“FPG”“GLU”统一识别为同一含义的血糖项目。

这一步完成后，原始报告被转换成一份内部使用的结构化 JSON 或类似格式，后端模型和规则引擎才能在统一语义空间中处理后续推理。

2.2.2 风险计算与异常聚合

解析出结构化结果后，系统需要做风险分析和指标聚合。这里通常会结合三类能力。

一类是以指南和共识为基础的 规则引擎，例如对血压、血糖、血脂、肝肾功能等常规指标按既定分级标准打标签，判断是轻度异常还是高度危险信号。

二类是基于大规模历史数据的 统计与机器学习模型，通过指标组合判断特定综合征或疾病风险倾向，例如代谢综合征、高危心脑血管事件倾向等。

三类是对用户个体信息的 个性化校准，包括年龄、性别、过往病史、家族史等维度，用于调整风险阈值和随访建议频率。

这一过程的输出不是单一疾病诊断，而是围绕“问题严重程度”“需要多快行动”“应关注哪些组合风险”这些维度形成分层结果。

2.2.3 解释生成与行动建议

在风险评估基础上，大语言模型负责把技术结果转换成自然语言解释和行动建议。这里的难点不在中文生成本身，而在 受控生成和 合规约束。

系统通常会先构造一份中间语义表示，把每个异常项的医学含义、常见原因、对应指南建议、生活方式干预点等结构化表示出来，然后由大模型在这个受控空间内完成自然语言表达。在生成过程中叠加若干约束，例如不直接给出“确诊”表述，对需要线下就诊的情况优先强调就医科室和推荐检查，而不是在线给出替代方案。

简单概括，阿福在体检解释链路上走的是“结构化抽取 规则 风险建模 控制生成”的路线，大模型起到的是懂医学知识的语言接口作用，而不是单一黑盒判定器。

下面用一个简化的流程图描述这一链路。

2.3 多模态问诊与对话体验

除体检报告解释以外，“蚂蚁阿福”还支持文字、语音、图片等多模态交互，并呈现出类似真实门诊的多轮问答体验。

语音输入降低了用户在非标准场景下的操作门槛，适合老年人或打字不便的用户。图片上传可以满足外用药包装、化验单截屏等场景的快速识别。系统通过语音识别、图像理解和文本语义统一到同一个会话语境中，让大模型在对话中可以不断追问和确认关键信息，例如症状持续时间、伴随症状、以往用药情况。

从工程角度看，这类多轮问诊对话通常会采用 会话状态机 控制策略 模型调用的混合模式。对一些高风险症状触发固定安全策略，对常见场景开放大模型更大自由度，对特殊人群例如孕妇、儿童、老年人增加额外的提醒与限制。

2.4 合规定位与用户预期管理

在当前监管框架下，这类 C 端应用必须非常明确自己的角色边界。

国内互联网诊疗管理办法对谁有权开具处方、谁能开展复诊服务等有清晰规定。同时，国家层面的 AI 医疗政策也强调人工智能要定位在 辅助决策，不得替代医务人员作出最终诊断结论。

所以“蚂蚁阿福”这类产品普遍采用几项策略。首先在注册协议、界面文案和关键交互节点反复强调自身是健康管理和科普工具，不提供正式诊断和处方。其次在对话逻辑中对高风险内容实行 自动上收，例如一旦涉及急性胸痛、呼吸困难、意识障碍等症状，引导用户尽快线下就诊。最后在日志和审计层面保留足够的数据，以便后续复盘和风险追踪。

这套做法的目标是通过 技术产品设计 合规边界管理，建立起一个既有用又尽量可控的健康助手，而不是一个容易被误解为“线上 AI 医生”的系统。

● 三、从“蚂蚁阿福”到“安诊儿” 医疗大模型与基础设施

3.1 “安诊儿”与浙江基地的组合拳

如果说“蚂蚁阿福”代表的是 C 端解释型 AI 医疗的一种样本，“安诊儿”则更接近 行业级医疗大模型枢纽。浙江在行动计划中提出要打造国家人工智能医疗行业应用基地，把“安诊儿”等大模型作为核心，构建医疗智能体集群。

与单一应用不同，“安诊儿”这类大模型面对的是医院、公共卫生机构和产业合作伙伴需要的多场景能力，包括辅助问诊、病历自动生成、临床路径推荐、科研文献阅读与归纳等。大模型本身不会直接以一个 APP 形式面对大众，而是通过接口、SDK 或行业应用平台为上层产品提供底层能力。

支撑这一模式的，是国家人工智能应用中试基地在浙江的落地。基地覆盖从 算力保障 数据支撑 模型研发 验证评估 应用推广的全链条，把原本零散的基础设施汇集成一个“公共底座”，让企业不必在每一环重造轮子。

3.2 医疗大模型在医院侧的部署现状

根据相关数据，国内排名前一百的医院已经在不同程度上完成大模型部署，涵盖影像科、病理科、内科门诊、护理、科研管理等多个科室。

在影像和病理领域，大模型更多承担候选病灶标注、结构化报告生成和异常优先排序的角色，帮助医生在高负荷环境下提升效率和准确性。在临床一线场景，大模型可以参与问诊记录自动整理、诊疗计划初稿生成和用药风险提示，为医生节省时间并增加安全冗余。

对医院信息中心和信息化部门来说，大模型不再是一个孤立的实验系统，而是逐渐变成 HIS、EMR、LIS、PACS 等现有系统的智能增强层，需要在权限、审计、集成和性能上与原有架构深度融合。

3.3 大模型能力与基础设施之间的耦合

医疗大模型的能力发挥高度依赖底层基础设施。浙江基地这类中试平台的作用可以抽象成三个方面。

第一类是 算力和环境标准化。通过统一的 GPU 集群和容器化调度环境，企业可以以较低门槛获取实验和推理能力，不必单独建设小规模集群，也更容易在安全合规前提下访问医疗数据。

第二类是 数据与评测体系建设。平台可以汇聚多家医疗机构的数据资源，在统一脱敏和治理规则下，用于模型预训练、微调和评测。配套建立医学问答、病例推理、影像识别等多维度 benchmark，为大模型能力提供可对比的客观标尺。

第三类是 中试与认证路径。企业在平台上完成小范围试点和稳定性验证后，可以更快通过行业评估和监管审核，缩短从实验室到商业部署的周期。

这样一来，类似“安诊儿”的大模型就不再只是单个企业的内部资产，而是通过基础设施平台进入一个更公开、更易协作的生态环境，为后续上市公司和创业企业叠加业务能力打下基础。

● 四、上市公司新战局 平台化与垂直细分并行

4.1 平台型企业 和仁科技的临床智能工作站

在上市公司中，和仁科技是典型的 平台化布局代表。公司依托长期的医院信息化经验，构建了自有 AI 应用开发平台，在此基础上推出 AI 临床工作站、AI 智能病历、AI 移动诊疗助手等应用集群。

以 AI 临床工作站为例，实际运行场景中系统可以自动监听医生与患者的对话或查房口述，将语音内容转写为结构化病历草稿，同时结合指南和院内路径给出初步诊断思路和医嘱建议。医生在终端上进行审核和修订，效率比完全手工录入提升明显。

这种模式把大模型能力嵌入到临床工作流中，通过与 HIS、EMR、检查申请和用药系统对接，在医生原有操作路径上叠加一层智能辅助，从而提升接诊能力和文书质量，同时降低漏项和不规范记录风险。

4.2 垂直领域深耕 润达医疗与康众数字医疗

与平台化路线并行的是垂直细分领域的深度布局。润达医疗在临床检验和实验医学领域积累较深，围绕临床辅助、患者管理和科研创新推出二十余款 AI 智能体产品，包括检验结果智能解读、质控预警和科研数据挖掘工具。

康众数字医疗的路径则集中在医学影像装备和智能影像解决方案。例如在 RSNA 2025 展会上展示的精准低剂量放射影像方案，将第三代无线平板探测器、全视野自动曝光剂量控制技术和智能束光器整合为一体，既体现硬件创新能力，也为上层 AI 图像重建和病灶识别提供更优质的输入。

这类企业通过掌握高壁垒的细分技术，例如剂量控制、图像信噪比优化、质控算法和专科知识图谱，使得外部竞争者很难简单复制，同时也更容易通过医疗器械注册和专业认证形成护城河。

4.3 企业布局维度对比

下面用一张表格对几类代表性企业的布局路径进行简要梳理。

对技术团队而言，不同类型公司的架构优先级差异很大。平台化公司更重视统一的 AI 中台和多场景复用能力，垂直领域公司则强调与专科业务的深度耦合，C 端科技平台要平衡大规模用户访问、风控和体验。

无论路线如何，在当前阶段，大多数公司的共识是 从“卖软件”转向“卖解决方案和长期服务”，通过订阅、算力托管、运维升级等方式建立可持续现金流。

4.4 商业模式从产品到“方案 服务”

在 To B 侧，单次软件授权模式已经难以覆盖 AI 系统后续模型更新、规则维护和安全监控的成本，越来越多项目采用以下组合结构。

一类是 基础平台订阅，医院按年支付 AI 平台使用费，包括模型调用、系统升级和基础支持。二类是 场景化解决方案项目费，针对影像科、病理科、门诊、护理等具体场景的实施、集成和定制收取一次性项目费用。三类是 持续服务费，包括模型再训练、质控报告、性能评审和新功能开通。

在 To C 侧，以“蚂蚁阿福”为代表的产品多数仍采用免费模式，收入更多来自与保险、体检机构、互联网医院等合作方的协同，例如导流、健康管理打包方案等。长期看，随着健康管理付费习惯的逐渐形成，基于订阅的“私人健康顾问”服务也具备一定空间。

● 五、长尾市场 与基层医疗的智能化路径

5.1 基层医疗的现实约束

很多技术方案在三甲医院运行顺畅，在基层机构却落不了地，原因通常不在算法，而在资源和流程。

基层医疗机构普遍面临医生数量有限、信息系统陈旧、网络条件不稳定、用户数字素养参差等问题。大体量、高门槛的大模型系统如果不做针对性简化，很难在这样的环境下稳定运行。

同时，基层机构承担大量慢病随访和基本公共卫生服务任务，这些工作数据量大、重复度高，却长期缺乏智能化工具支撑。这里正是 AI 医疗可以释放价值的空间。

5.2 低代码 AI 工具与轻量智能体

针对基层场景，越来越多企业开始尝试 低代码 AI 工具和轻量级智能体方案。其核心思路是用简单配置方式，在有限资源环境下快速落地几个刚需场景，例如初步分诊、健康教育推送和随访记录整理。

从架构视角看，一套适配基层的轻量 AI 医疗系统可以拆为几层。

第一层是前端形态，既可以是 Web 页，也可以嵌入已有 HIS 或微信小程序，以尽量少改动前端为原则。第二层是低代码规则配置，允许基层医生或信息员用图形界面定义随访流程、问卷模板、提醒规则等，而不必编写代码。第三层是与云端大模型的轻量集成，通过 API 完成问答、文本生成和结构化抽取，同时在本地缓存部分结果降低网络依赖。

这种设计的关键是把复杂性收敛在云端，把本地部署部分控制在一个很小的资源足迹内，同时提供清晰的运维边界，减少对基层机构运维能力的要求。

5.3 区域医疗大数据平台与协同创新

不少地区在推进区域医疗大数据平台建设，目标是整合辖区内医院、基层医疗机构和公共卫生机构的数据，为分级诊疗和公共卫生决策服务。

对 AI 医疗企业而言，接入这类平台既是机会也是约束。一方面，可以在合规前提下获取更广泛的真实世界数据，用于模型优化和新场景开发。另一方面，必须遵循统一的接口标准、安全规范和审计规则，接受第三方或监管部门的评估。

在更长的周期里，这类平台有望成为 算法 业务 数据三者协同的中枢，支持跨机构应用，例如跨院随访、区域慢病管理、突发公共卫生事件研判等，对 AI 医疗厂商的架构弹性和标准化能力提出更高要求。

● 六、风险、监管与工程实践

6.1 合规边界与责任划分

AI 医疗的核心风险之一在于用户对系统能力的认知偏差。对 C 端用户来说，很容易把聊天界面里给出的建议当作“医生说的”，一旦出现用药错误或延误诊治，责任界定就会变得复杂。

因此在工程实践中，团队需要在多个层面设计“刹车机制”。界面层面通过显著提示减少“权威错觉”，例如将系统回答标注为“健康建议 不构成诊断”，对高危提示加粗处理，引导就医。交互层面在检测到用户有明确诊断或用药诉求时，优先引导其使用正规互联网医院或线下就诊。后台则要建立风控规则和人工审核通道，对异常查询集中爆发等情况进行干预。

在 To B 侧，合同条款中通常会明确 AI 系统的使用边界和双方责任划分，技术团队则需要通过日志归档、结果可追溯和人工复核机制，为潜在争议提供证据支撑。

6.2 算法透明与效果评估

医疗场景天然需要更高的可解释性和可信度。虽然大模型本身是黑盒结构，应用层可以通过若干工程手段提升透明度。

一类做法是 分层展示推理依据。例如在给出体检解释时，同时呈现参考的指南片段、指标阈值和风险分级标准，让专业用户可以快速审阅系统依据。

另一类做法是构建 统一评测体系。在中试基地或企业内部建立标准测试集，对问诊理解、诊断建议合理性、文书生成质量等多项指标进行持续评估，并形成版本演进曲线。

此外，随着多家机构参与，同一任务上不同模型的横向对比也会更加普遍，这迫使企业在效果交付上从宣传走向可量化。技术团队需要在产品迭代流程里引入严格的 A/B 测试和灰度发布机制，逐步优化线上表现。

6.3 数据安全与隐私保护的工程路径

医疗数据具备高度敏感性，任何泄露事件都会带来严重后果。工程实现中需要从数据生命周期视角进行系统设计。

数据采集阶段，通过最小必要原则限制采集内容，能在本地设备端完成脱敏处理的尽量下沉到本地，例如身份证号和联系方式的掩码化。数据传输过程中采用端到端加密，并对跨境访问做强约束。

数据存储和训练阶段，尽量采用去标识化或匿名化数据，对能通过少量特征重新识别个人的情况进行特殊处理。在多机构联合建模场景中，可以探索联邦学习和安全多方计算方案，将原始数据留在本地，只交换模型参数或统计量。

最后在访问控制层，引入细粒度权限管理和多级审计，对每一次查询和模型调用记录操作人、时间和目的，为安全合规检查提供基础。这类工作虽然繁琐，却是 AI 医疗系统能够长期稳定运行的底座。

● 七、中长期展望 从工具到医疗智能体生态

7.1 从单点工具到智能体网络

当前的 AI 医疗产品更多还处在“工具”形态，例如体检解释助手、影像读片助手、科研写作助手等。随着大模型能力增强和基础设施完善，这些工具之间的边界会逐渐模糊，形成一个由多个 医疗智能体组成的网络。

一个可能的演进方向是，面向患者的健康助手、面向医生的临床助手、面向管理者的运营分析助手和面向科研人员的文献助手在统一大模型和统一身份体系下协同工作。它们共享部分知识和用户画像，在各自界面上给出定制视角。

对架构师来说，这意味着未来的系统设计需要预留更多跨角色协作的能力，例如统一的对话上下文管理、全局权限控制和跨系统事件总线，让不同智能体在需要时可以交换信息，同时不突破隐私和职责边界。

7.2 对开发者与架构师的几点建议

面对这一轮 AI 医疗加速落地，技术团队可以考虑几条实践路径。

其一，优先锚定清晰的业务场景，避免一开始就做“大而全”的 AI 平台。体检报告解释、病历生成、随访记录整理、质控预警等都是可度量效果、易于闭环的入口场景。

其二，在系统设计中划清“模型中台 业务编排 前端体验”三层边界。模型部分专注能力复用和性能优化，业务层通过配置和工作流编排实现快速适配不同机构和科室，前端层则围绕不同用户群体做细致体验打磨。

其三，把合规、安全和监控当作首等公民，而不是上线后的补丁。为每一次模型调用保留可审计记录，为每一种高风险交互设计兜底策略，这些工作都会在产品扩张后发挥作用。

其四，积极参与区域平台和行业标准建设。与其在各地重复适配各种接口标准，不如在早期就对接国家或省级平台的技术规范，让自己的系统更易融入公共基础设施，也更容易获得监管信任。

结论

从“蚂蚁阿福”到“安诊儿”，AI 医疗正在从两个方向同步推进。一端是面向用户的解释型健康助手，在体检报告解读和日常健康管理中迅速获得关注，验证了 C 端对可理解、可执行健康建议的需求。另一端是以大模型和国家级中试基地为核心的产业基础设施，为医院和企业的大规模部署提供算力、数据和评测支撑。

在这样的格局下，上市公司正在沿着平台化和垂直细分两条路径展开布局。前者围绕 AI 临床工作站和智能病历构建统一应用平台，后者在影像、检验等高壁垒领域深耕专业技术。同时，基层医疗和长尾市场通过低代码工具和轻量智能体获得切入点，区域医疗大数据平台提供了跨机构协同的可能。

风险和挑战依然存在，包括合规边界、算法透明和数据安全等方面都需要扎实工程实践来支撑。不过在政策引导逐步清晰、基础设施日益完善、真实场景不断涌现的背景下，AI 医疗已经从概念阶段进入务实建设阶段。对技术团队而言，下一步比拼的不只是模型指标，而是能否在复杂医疗环境中构建一个可靠、可持续、对各方都有明确价值的智能系统。

📢💻 【省心锐评】

AI 医疗已从技术秀场转向工程战场，谁能在合规和可落地之间找到平衡，谁就更有机会在下一轮产业分层中占据关键位置。