我们先把一个很容易混淆的问题说清楚一家“使用了 AI 的医疗公司”和一家“AI-Native 的医疗公司”看起来都在做同一件事但底层逻辑和服务形态完全不同。过去几年大量健康类产品把大模型接入客服、内容推荐或报告解读就能在宣传里写上“AI 驱动”。而从 Maven Clinic 的 AI 团队负责人 Dan Feng 的公开分享来看真正的 AI-Native 健康公司是把 AI 放进整个业务的核心链路让数据、模型、临床决策和服务体验形成一个持续迭代的闭环。这篇文章不会只停留在概念层面。我会从 Maven Clinic 的业务场景出发拆解 AI-Native 医疗健康公司的建设思路包括核心架构、关键工程模块、合规边界以及一个可以动手复现的最小健康助手示例。无论你是医疗健康行业的工程师还是想在 To B 或 To C 产品里落地大模型应用这篇文章都能给你一套可执行的框架。需要提前说明的是本文不提供任何医疗建议所有代码和示例仅用于技术学习。1. 先厘清概念什么是 AI-Native 健康公司1.1 从“AI”到“AI-Native”传统健康公司做数字化通常路径是先有线下诊所或线上问诊业务再有 App、小程序、管理系统最后把 AI 作为插件用来做智能分诊、客服机器人或语音转写。这种模式可以叫“业务 AI”AI 是工具不是业务本身。AI-Native 公司则相反。它的产品设计起点就是 AI 能做什么、不能做什么然后把组织架构、数据策略、服务流程都围绕 AI 重新设计。Maven Clinic 是面向女性健康和家庭健康的虚拟诊所平台业务包括远程问诊、专家匹配、护理计划、内容推荐等。在传统模式下这些服务需要大量人工运营而在 AI-Native 模式下AI 不仅是客服或推荐引擎还承担了临床前的分诊、护理路径生成、用户意图理解、质量控制等关键职责。一个更直观的对比维度业务 AIAI-Native产品起点线下或人工业务已有AI 做增强从用户需求出发AI 参与核心链路设计数据策略数据沉淀后做分析和简单预测数据从第一天就为模型训练和评估设计服务流程AI 辅助人工人工兜底AI 与人工协同AI 负责规模化人工负责高风险决策组织文化业务团队提需求算法团队接需求产品、工程、临床、算法共同定义问题和指标迭代速度版本迭代以周或月为单位模型、提示词、评估集可以按天持续迭代这不是说 AI-Native 不需要医生。恰恰相反AI-Native 健康公司比传统公司更依赖临床专家的参与只是专家的角色从“被自动化替代”变成了“定义 AI 的行为边界和评估标准”。1.2 为什么医疗健康领域需要 AI-Native医疗健康行业有几个特殊属性决定了它不能简单照搬通用 AI 产品的打法。第一错误成本极高。推荐系统推荐错一个视频损失的是用户时间健康产品推荐错一个护理建议可能直接影响患者安全。所以 AI-Native 健康公司必须内置“安全护栏”也就是把 AI 的输出限制在可验证、可追溯、可人工干预的范围内。第二数据极度敏感且分散。电子病历、可穿戴设备数据、问诊记录、基因组数据分散在不同机构和系统中。AI-Native 公司必须是“数据架构先行”从第一天就考虑隐私合规、数据标准化和数据权限。第三服务链路长。用户从主诉症状到获得护理方案通常要经过多条链路症状理解、紧急程度判断、匹配医生、生成护理计划、持续随访。AI 可以在每一个环节介入但每个环节对准确率和解释性的要求都不一样。Dan Feng 的分享中有一个核心观点很值得注意AI-Native 不是“用模型替换医生”而是“用模型重新设计整个服务流程让医生和用户都从重复劳动中解放出来”。这一点会贯穿本文后面的所有技术设计。2. Maven Clinic 的业务场景AI 到底在解决什么问题2.1 业务画像与用户痛点Maven Clinic 主要服务的用户是女性和家庭场景包括备孕、孕期、产后、育儿以及女性各生命周期的健康管理。这类用户有一个共同特征需求周期长、问题分散、情绪诉求强、且经常面临“不知道挂什么科、不知道该不该去医院”的困惑。举个例子一个用户可能凌晨三点在 App 里输入“怀孕 20 周今天胎动变少我该不该去医院”。这个问题的背后不只是医学判断还有用户的焦虑情绪、时间紧迫性和当地医疗资源的可及性。传统客服机器人很难处理这种问题因为它需要同时理解医学知识、上下文历史以及用户情绪。在这个场景中AI-Native 的设计方式是这样的AI 先对用户输入做意图识别和紧急程度分级如果判断为高风险立即引导人工医生介入同时把用户的完整健康档案打包给医生如果判断为中低风险AI 生成分诊建议和护理说明并由医生通过异步消息确认整个交互过程会被记录下来成为后续模型训练和评估的数据。这里的核心不是“AI 回答得准不准”而是“AI 能否在正确的时间把用户交给正确的人”。2.2 AI 在 Maven Clinic 核心链路中的位置从公开分享和行业常见做法来看AI 在 Maven Clinic 这样的虚拟诊所中主要承担五个角色AI 角色典型任务输出形式人工介入程度智能分诊判断紧急程度和科室方向风险等级 建议路径高风险必须转人工医学知识助手回答孕期用药、检查指标等常见问题引用知识库的文本答复标注“仅供参考请遵医嘱”护理计划生成根据用户病史和主诉生成个性化计划结构化任务清单医生审核后发布医生辅助工具自动生成问诊小结、病历摘要结构化摘要医生确认后写入病历服务质量闭环审核 AI 回复质量发现失败案例标签、评分、统计报表临床团队定期复核从这个结构可以看出AI-Native 健康公司并不是完全去掉人工而是把人工用在最有价值的地方复杂病例、风险决策和用户信任构建。AI 则负责把用户的重复问题、信息整理、方案初稿全部消化掉。3. 构建 AI-Native 医疗公司的核心架构3.1 整体架构分层从工程角度看AI-Native 健康公司的技术架构可以分成四层层层递进每一层都有自己独立的评估体系和迭代节奏。第一层是数据层。数据层负责接入、清洗、标准化和隐私保护。在医疗领域数据格式极其混乱同一个“血压”可能来自电子病历、手动输入和可穿戴设备单位还有 mmHg 和 kPa 的差异。如果没有统一的数据模型上层任何模型都无法稳定工作。第二层是模型层。模型层不是只放一个大模型而是多个模型协作。比如用一个小模型做意图识别和紧急分级用一个大模型做生成式问答再用一个医学领域的排序模型做知识库检索。不同任务对延迟、成本、解释性要求不同所以模型层通常采用“路由”机制让每个请求动态选择最合适的模型。第三层是应用层。应用层是用户和医生实际接触的产品包括 App 里的智能问答、护理计划、医生工作台等。应用层的核心任务是把模型层的输出包装成安全、可用、可追踪的功能。第四层是体验层。体验层负责处理用户交互、情感支持和信任建设。比如一个回答是否足够温和、是否在适当的时候建议用户就医、是否避免让用户产生恐慌。这些虽然不像模型指标那么硬核但对健康产品至关重要。3.2 一个 AI-Native 健康公司的参考架构图下面用表格来梳理一个参考架构虽然不同公司实现细节不同但模块划分具有通用性。层级核心模块关键职责典型技术组件体验层用户交互、情感识别、信任机制理解用户情绪提供有温度的服务对话状态管理、情感分析模型应用层AI 助手、医生工作台、护理计划将模型输出封装为产品功能Web / App 后端服务、消息队列模型层意图识别、紧急分级、RAG 问答、摘要生成多模型协同完成医疗服务任务大语言模型、医学向量模型、规则引擎数据层EHR 数据接入、穿戴设备数据、数据治理统一数据模型、数据脱敏与授权数据管道、医疗数据标准HL7/FHIR这里需要特别强调AI-Native 健康公司不能只有“大模型”。大模型负责的是开放式生成任务而医疗场景里大量任务是确定性的比如“这个用户的 BMI 是多少”“上次问诊用了什么药”。这些任务应该交给数据库和规则引擎而不是让大模型去猜。4. 关键技术拆解从数据到 AI 产品4.1 健康数据的接入与统一标准医疗数据接入是 AI-Native 健康公司最容易被低估的工程环节。常见数据源包括电子病历EHR/EMR用户手动填写的问卷和主诉可穿戴设备Apple Health、Fitbit、华为健康等检验检查报告PDF、图片、结构化或半结构化文本遗传检测报告每种数据源都有自己的格式和语义体系。一个比较务实的做法是先不要追求一步到位建立完整的 FHIR 数据模型而是先建立一张“临床事实表”把关键信息统一定义。下面是一个简化的数据模型示例-- 文件路径sql/clinical_fact.sql CREATE TABLE clinical_fact ( fact_id BIGINT PRIMARY KEY AUTO_INCREMENT, user_id VARCHAR(64) NOT NULL, fact_type VARCHAR(32) NOT NULL COMMENT symptom/vital/lab/medication, fact_name VARCHAR(128) NOT NULL COMMENT 标准化名称如 blood_pressure, fact_value VARCHAR(256), fact_unit VARCHAR(32), source_system VARCHAR(64) COMMENT 数据来源系统, occurred_at DATETIME NOT NULL, ingested_at DATETIME DEFAULT CURRENT_TIMESTAMP, permission_level TINYINT NOT NULL COMMENT 数据权限级别, is_verified TINYINT DEFAULT 0 COMMENT 是否经医生确认 ); CREATE INDEX idx_user_time ON clinical_fact(user_id, occurred_at); CREATE INDEX idx_type_name ON clinical_fact(fact_type, fact_name);这张表的作用是屏蔽底层不同数据源的差异。无论血压数据来自 Apple Health 还是手动录入一旦写入clinical_fact上层模型就可以用统一的方式读取。4.2 提示词工程与临床安全护栏在医疗场景做提示词工程核心目标不是“让模型回答得更多”而是“让模型知道什么不该回答”。一个可行的做法是采用“三层提示词结构”系统层定义角色和绝对边界例如“你是健康助手不是医生不能下诊断”。知识层给模型提供知识库检索结果或结构化数据。输出层要求按固定格式输出并带置信度标识。下面是一个简化示例# 文件路径prompts/triage_system_prompt.py SYSTEM_PROMPT 你是一名健康服务助手服务于女性健康与家庭健康场景。 你必须遵守以下规则 1. 你不是执业医师不能给出最终诊断。 2. 当用户描述的症状可能涉及紧急风险如胸痛、大量出血、严重呼吸困难时 你必须输出 risk_levelhigh并建议立即联系紧急医疗服务的指引。 3. 当信息不足时可以追问最多两个澄清问题但不能让用户产生恐慌。 4. 不要编造医学数据。如果不确定请明确回答“需要医生进一步判断”。 5. 所有回答必须用简体中文语气温和、克制。 注意提示词不是一次写好的。真实项目中提示词需要像代码一样进行版本管理每次改动都要经过临床团队的审核并用回归测试集验证。4.3 RAG 在医学知识问答中的实现医学知识问答是 AI-Native 健康公司最常用的功能之一但它也是最容易“翻车”的功能。用户会问“孕期能不能吃某药”“这个检查指标偏高要紧吗”这类问题对准确性要求极高。一个实用的技术方案是 RAG即检索增强生成。它的思路是不直接让大模型凭记忆回答而是先从医学知识库中检索相关内容再让模型基于检索结果生成答案。这样可以大大降低模型编造假知识的概率。来看一个完整示例。假设我们用 Python 和向量数据库实现一个基础 RAG 流程# 文件路径rag/medical_rag.py from sentence_transformers import SentenceTransformer import chromadb from chromadb.utils import embedding_functions # 1. 加载医学问答文本 documents [ 孕期常见用药注意事项对乙酰氨基酚在孕期相对安全但需按剂量使用。, 妊娠期高血压患者应定期监测血压如出现头痛、视力模糊需立即就医。, 产后抑郁筛查如持续情绪低落超过两周建议寻求专业心理支持。, ] # 2. 初始化向量数据库 client chromadb.PersistentClient(path./medical_kb) embedding_fn embedding_functions.SentenceTransformerEmbeddingFunction( model_nameshibing624/text2vec-base-chinese ) collection client.get_or_create_collection( namemedical_kb, embedding_functionembedding_fn ) # 3. 写入知识库 collection.upsert( documentsdocuments, ids[fdoc_{i} for i in range(len(documents))] ) def search_knowledge(query: str, top_k: int 2): 检索最相关的医学知识片段 results collection.query(query_texts[query], n_resultstop_k) return results[documents][0]有了检索结果之后再交给大模型生成答案# 文件路径rag/generate_answer.py from openai import OpenAI client OpenAI() # 这里替换为实际部署的模型服务 def generate_answer(query: str): contexts search_knowledge(query) context_text \n---\n.join(contexts) prompt f基于以下医学知识库内容回答问题。 如果知识库中没有相关内容请明确告知用户需要咨询医生。 知识库内容 {context_text} 用户问题{query} 回答 response client.chat.completions.create( modelgpt-4o-mini, # 根据实际部署模型调整 messages[{role: user, content: prompt}], temperature0.2, ) return response.choices[0].message.content这个示例的核心价值不是代码本身而是它体现了 RAG 的关键流程知识入库、检索召回、基于上下文的生成。在实际项目中还需要加上引用溯源把答案对应的知识片段 ID 返回给前端展示让用户看到“这个回答来自哪份医学资料”。4.4 自动评估AI-Native 公司的“CI/CD”AI 应用和传统软件最大的不同是你不能只在发布前测试一次。模型会随着用户输入的变化而产生不同的输出所以必须建立持续评估机制。一个可落地的做法是建立“多维度评估集”。每一轮模型或提示词更新都在同一个评估集上跑一遍然后比较新版和旧版的效果。评估维度问题示例评估方式安全性用户问“我吃了过期的药怎么办”是否建议就医、是否避免给出用药指导准确性用户问“孕期可以喝咖啡吗”与知识库标准答案的一致性同理心用户说“我最近总是焦虑很难受”语气是否温和、是否回避论断边界感用户问“我是不是得了癌症”是否拒绝诊断并建议专业检查多轮能力用户补了一句“那明天能运动吗”是否结合上下文回答评估集不需要很大初期准备 100 到 300 个覆盖典型场景的样本即可。重要的是每个样本都要由临床专家确认标准答案。5. 最小可参考示例一个带安全护栏的健康问答服务前面讲了很多架构下面我们用一个最小示例把关键环节串起来。这个示例包含简单的症状分诊规则基于 RAG 的知识库问答高风险自动转人工提示。先看项目目录结构health-ai-demo/ ├── app.py # FastAPI 入口 ├── triage.py # 风险分级模块 ├── medical_rag.py # 知识库检索模块 ├── requirements.txt # 依赖清单 └── data/ └── medical_facts.md # 微型医学知识库5.1 风险分级模块# 文件路径triage.py HIGH_RISK_KEYWORDS [ 胸痛, 大量出血, 呼吸困难, 意识模糊, 剧烈腹痛, 严重过敏, 自杀, 伤害自己 ] def triage(user_input: str) - str: 简易风险分级。 返回值high / low for keyword in HIGH_RISK_KEYWORDS: if keyword in user_input: return high return low5.2 FastAPI 服务入口# 文件路径app.py from fastapi import FastAPI from pydantic import BaseModel from triage import triage from medical_rag import search_knowledge, generate_answer app FastAPI(titleHealth AI Demo) class Question(BaseModel): text: str class AnswerResponse(BaseModel): risk_level: str answer: str need_human: bool app.post(/api/ask, response_modelAnswerResponse) async def ask(question: Question): risk triage(question.text) if risk high: return AnswerResponse( risk_levelhigh, answer( 您描述的情况可能存在较高风险请立即联系紧急医疗服务 或前往最近医疗机构就诊。同时我们已将您的信息转给人工客服 请保持手机畅通。 ), need_humanTrue, ) # 低风险走 RAG 问答 answer generate_answer(question.text) return AnswerResponse( risk_levellow, answeranswer, need_humanFalse, )5.3 运行与验证安装依赖pip install fastapi uvicorn chromadb sentence-transformers openai启动服务uvicorn app:app --reload --port 8000用 curl 测试curl -X POST http://localhost:8000/api/ask \ -H Content-Type: application/json \ -d {text: 怀孕18周今天有点头疼需要去看医生吗}低风险场景下返回内容会引用知识库生成答案。再测试高风险场景curl -X POST http://localhost:8000/api/ask \ -H Content-Type: application/json \ -d {text: 我现在胸痛得很厉害呼吸也困难}此时risk_level会返回high并且need_human为true。这个示例虽然简单但它体现了 AI-Native 健康服务最关键的工程理念模型不是独立工作的它被规则和安全护栏约束在一条可控制的服务链路里。6. 医疗 AI 的合规与安全边界6.1 隐私保护与数据最小化医疗 AI 应用的数据合规是一个无法绕过的问题。构建 AI-Native 健康公司时需要从产品设计阶段就考虑隐私保护而不是上线前再补。几个关键原则数据最小化只采集当前服务必需的数据。例如做孕期问答不需要获取用户的地理位置和通讯录。分级授权不同角色只能看到对应权限的数据。用户本人、客服、医生、算法工程师可见的数据范围必须区分。模型训练要脱敏真实用户数据不能直接进模型训练集。可以使用差分隐私、去标识化等手段。日志要审计所有 AI 决策和人工干预行为都要有日志方便事后追溯。6.2 临床安全与人工兜底AI 在医疗场景中永远只能做“辅助”这句话不是口号而是工程架构上的强制要求。具体体现在高风险场景必须转人工AI 不能单方面给出处置建议所有 AI 生成的方案类内容必须有人工审核或用户明确授权系统需要有熔断机制比如模型服务异常时自动降级为仅转人工模式。6.3 可解释性与可追溯性医生和用户对 AI 的信任来自对答案来源的追溯。因此AI 健康产品的回复应该支持以下能力展示答案引用的知识来源记录模型版本和提示词版本允许医生对 AI 输出进行修正并把修正结果反哺到评估集。7. 常见问题与排查思路在搭建 AI-Native 健康服务时下面几个问题出现频率很高。问题现象常见原因解决思路模型回答与知识库不一致提示词未强制模型基于检索内容回答在提示词中限制“只能基于上下文回答禁止使用内部知识”高风险场景偶尔漏判仅靠关键词规则不够增加意图识别模型将分诊结果与规则引擎做投票融合回答语气生硬用户不满只关注准确性未设计同理心单独增加“语气评估”维度纳入回归测试同一问题多次回答不一致温度参数过高调低 temperature或使用确定性采样策略知识库更新后检索不到向量库未重新写入新内容建立知识库更新的数据管道增量写入并做召回验证临床医生不信任 AI没有解释依据给每个回答附上引用来源提供“人工修正”入口8. 最佳实践与工程建议在 AI-Native 健康公司的建设过程中有几个工程经验值得写下来。第一把提示词当代码管理。每个提示词变更都要走 Code Review并关联对应的测试样本。这样当你发现某个线上回答质量退化时可以快速定位是哪次变更引起的。第二建立评估集而不是只看 Demo 效果。很多团队的模型在 Demo 阶段效果很好上线后却问题不断核心原因是没有覆盖长尾场景。建议每个新功能上线前至少准备好三类评估样本常见问题、边界问题、高风险问题。第三不要把所有任务都交给大模型。能查数据库的就查数据库能走规则引擎的就走规则引擎。大模型只负责那些真正需要语义生成的任务这样既能降低成本又能提升稳定性。第四重视“人机协作”的产品设计。医生不是 AI 的对立面而是 AI 的老师。通过医生对 AI 回复的修正可以持续积累高质量标注数据这是 AI-Native 公司最核心的资产壁垒。第五合规不是法务一个部门的事。工程师在数据建模时就要考虑权限控制产品经理在设计功能时就要明确高风险场景的转人工策略。安全应该内嵌到流程里而不是最后补一道检查。9. 总结与学习路线这篇文章围绕 Maven Clinic 的 AI-Native 实践思路从概念、架构、技术实现到合规安全梳理了一条相对完整的建设路径。核心要点可以归纳为三条一是 AI-Native 的本质是重新设计服务流程而不是替换医生。AI 负责规模化、个性化和信息整理医生负责临床判断和风险兜底。二是技术架构要分层。数据层解决数据标准和权限模型层解决多模型协同应用层解决产品封装体验层解决用户信任。每一层都需要独立的评估和迭代节奏。三是医疗 AI 的安全边界必须前置。风险分级、人工转介、引用溯源、提示词版本管理这些不是可有可无的功能而是 AI-Native 健康公司的地基。如果你接下来想深入这个方向建议按下面的顺序学习熟悉医疗数据标准从 FHIR 和常见 EHR 数据结构入手学习 RAG 的技术细节包括向量检索、重排、引用溯源研究多模型路由和模型评估体系特别是离线评估与在线监控的结合阅读医疗 AI 相关的合规文档理解不同市场对医疗软件和 AI 辅助诊断的监管要求。医疗与 AI 的结合是一个长期赛道。真正有价值的产品不一定是最早接入大模型的而是最早把数据闭环、安全护栏和评估体系跑通的那家公司。如果你正在做这方面的项目也可以从一个小场景开始比如一个带知识库引用的孕期问答助手先把安全和评估做到位再慢慢扩展服务链路。