先说结论很多人以为“AI 原生健康公司”就是把 ChatGPT 接到医院系统后面做一个自动回复客服。但真正 Mt. Sinai 级别的医疗平台不会这么做Maven Clinic 的做法也完全不是这个思路。作为一家估值超过十亿美元级别的虚拟女性健康与家庭健康平台Maven Clinic 的 CTO Dan Feng 在技术分享中反复强调一个观点AI 原生不是“在已有系统上补几个 AI 功能”而是从数据架构、产品流程、临床协作、合规治理的底层开始就把 AI 当成第一公民来设计。这篇文章会围绕这个核心展开从概念、架构、代码实战到常见排错完整拆解一条可落地的 AI 原生健康公司建设路径。1. 背景与核心概念1.1 什么是 AI-Native Health Company健康医疗领域的数字化转型已经走过了好几个阶段。早期是信息化把纸质病历变成电子病历后来是互联网化把挂号、缴费、问诊搬到线上再后来是“数字化 AI”在已有的 EHR、CRM、客服系统上单独接入 NLP、推荐模型。而 AI-Native Health Company 的核心理念完全不同AI 不只是某一个模块而是贯穿数据采集、护理路径规划、临床辅助、支付方协作、会员运营、风险预测的底层基础设施。Maven Clinic 就是用这个思路做起来的。它从女性健康、备孕、孕期、产后、育儿这些场景切入把“虚拟护理”做成了一个端到端的平台。用户进入系统后平台需要理解她的健康状况、风险因素、意图和情绪然后给出个性化的护理方案、匹配医生或导乐、安排随访、推送内容和干预措施。整个过程如果靠人工规则硬编码基本不可维护但如果一开始就用 AI 来设计数据流和决策流整个系统就能像“一个懂医疗的智能助手”一样运转。1.2 关键词解析要理解这类平台有几个基础概念必须搞清楚术语含义在健康平台中的作用AI-Native业务系统从设计之初就把 AI 作为核心基础设施决定推荐、分诊、预测等模块的架构位置PHIProtected Health Information受保护的健康信息涉及隐私合规所有数据处理链路必须纳入管控EHR/EMR电子健康档案/电子病历输入数据源之一通常以 HL7/FHIR 标准输出FHIRFast Healthcare Interoperability Resources医疗互操作数据标准统一患者数据模型是 AI 训练和推理的“数据底座”LLM大语言模型承担分诊对话、内容生成、意图识别、报告摘要等任务RAGRetrieval-Augmented Generation检索增强生成让模型基于临床知识库、指南和患者历史生成回答减少幻觉Human-in-the-loop人机协同流程高风险决策必须有临床人员复核AI 不能独立下诊断值得一提的是AI 原生并不是“什么都让模型自己做”。在医疗场景恰恰相反模型负责任务的碎片化处理但临床决策闭环必须保留人审环节。这个理念贯穿了 Maven Clinic 的整个产品体系。1.3 为什么健康公司必须重新设计 AI 架构传统健康科技公司通常是这样做的数据散落在 EHR、表单、呼叫中心、可穿戴设备、保险理赔系统中。每个业务团队各自建一套表数据口径不统一。AI 团队需要数据时花 80% 的时间在清洗数据。模型做出来之后很难上线因为临床团队不信任。而 Maven Clinic 的做法是先把“AI 原生”落到三层设计数据层所有健康数据进入统一数据平台使用 FHIR 等标准建模保证模型可以跨场景复用。能力层意图识别、风险分层、个性化推荐、生成式对话等服务化业务系统调用 API 而非重复造轮子。治理层PHI 访问控制、审计日志、模型版本管理、人工复核机制嵌入到平台基因中。所以建设 AI 原生健康公司的第一步不是急着训练大模型而是先搭建一个“数据 模型 人审”三者咬合的技术底座。2. Maven Clinic 的方法论AI 原生的四个设计原则2.1 原则一AI 要为临床增强而不是替代医生在医疗领域AI 如果定位成“替代医生”会同时遇到技术、合规、用户信任三重阻力。Maven Clinic 的定位更准确AI 负责“提效”——比如把用户长达十几分钟的主诉语音转成结构化病历草稿、根据用户风险评估推荐对应科室的专家、自动生成给医生的会诊摘要。这意味着产品界面上每个 AI 输出都要可追溯基于哪些数据、用了哪些知识、置信度如何、是否有临床人员复核。2.2 原则二数据从源头开始为 AI 准备很多公司做 AI 失败不是因为模型不好而是因为数据没准备好。Maven Clinic 的做法是在用户第一次进入平台时就把问卷、语音、文字、可穿戴设备数据、历史医疗记录统一汇入同一个患者画像Patient Profile。这个画像不是简单的关系表而是一个实时更新的知识图谱用户的主诉、诊断编码、用药记录、孕周、风险指标、过往护理交互记录AI 可以根据这个画像动态调整推荐策略。2.3 原则三把安全和合规做成系统默认属性健康数据不是普通业务数据它涉及 HIPAA 等合规要求。AI 原生平台的安全设计不能是上线前补一个“加密”而要从代码层面默认启用PHI 字段自动脱敏。所有模型训练数据必须经过去标识化处理。模型日志不能记录完整患者主诉。访问控制基于最小权限原则。每次 AI 决策都要有审计追踪。2.4 原则四小步快跑用“影子模式”上线模型Maven 在做新模型时倾向采用“影子模式”模型先在线上并行运行但它的输出不直接干预用户而是和专家规则、历史结果做对比。跑一段时间后用真实数据评估模型的准确率和风险再逐步放量。这样既不会因为一次模型错误造成医疗事故又能拿到高质量的线下评估数据。3. AI 原生健康公司的总体技术架构如果从工程角度重新设计一个 AI 原生健康公司我会将系统拆成下面几层。3.1 总体分层层级职责典型组件接入层用户通过 App/Web/语音/可穿戴设备产生数据iOS/Android、Web、Twilio、Fitbit APIAPI 网关统一鉴权、限流、审计Kong、APISIX、Spring Cloud Gateway数据接入与采集层接收 EHR、问卷、设备数据FHIR API、Kafka、CDC、ETL 管道统一数据平台患者画像、事件存储、特征存储PostgreSQL、Snowflake、Delta Lake、Feature StoreAI 能力层意图识别、分诊、推荐、生成、预测LLM、RAG 服务、风险模型、推荐引擎业务应用层护理路径、问诊、随访、会员运营服务编排、工作流引擎合规与安全层PHI 脱敏、审计、权限、模型监控审计日志、模型 Registry、数据治理工具3.2 一条数据流全景下面用一个用户从进入到被推荐护理路径的过程来解释各层如何协同。用户输入主诉文本/语音 ↓ API 网关鉴权、限流 ↓ 意图识别与信息抽取 - 症状关键词抽取 - 孕周/年龄等结构化信息抽取 - 风险关键词检测如出血、剧烈疼痛 ↓ 风险分层引擎 - 高风险立即转人工急诊通道 - 中风险当天预约医生 - 低风险进入护理建议流程 ↓ RAG 服务检索内部医学知识库 合规护理指南 ↓ LLM 生成个性化建议经过脱敏、引用来源 ↓ 临床审核Human-in-the-loop ↓ 写入用户护理记录FHIR同步审计日志这个流程看起来不复杂但真正落地时每一环都有大量细节。下面用几个实战示例来说明。4. 实战一用 FHIR 统一患者数据模型4.1 为什么是 FHIR健康数据的行业痛点在于格式混乱。有的医院导出 JSON有的是 HL7 V2有的是 XML字段命名也不统一。FHIR 是 HL7 组织推出的互操作标准用 RESTful API 加资源Resource的方式来描述患者、化验、诊断、用药、流程等实体。在 AI 原生平台里我们建议把 FHIR 作为“数据中枢”的 schema 基础而不是为每个业务建立独立数据模型。这样算法团队拿到的数据是统一的跨场景复用会容易很多。4.2 一个最小的 FHIR 患者资源示例下面是一个简化版的患者资源 JSON{ resourceType: Patient, id: patient-12345, identifier: [ { system: http://hospital.example.org/patient-id, value: PNT-2024-00921 } ], active: true, name: [ { use: official, family: Zhang, given: [Xiaoyu] } ], gender: female, birthDate: 1993-05-17, maritalStatus: { coding: [ { system: http://hl7.org/fhir/administrative-gender, code: M } ] }, contact: [ { relationship: [ { coding: [ { system: http://hl7.org/fhir/contact-relationship, code: emergency } ] } ], name: { family: Li, given: [Ming] }, telecom: [ { system: phone, value: 138****5678, use: mobile } ] } ], communication: [ { language: { coding: [ { system: urn:ietf:bcp:47, code: zh-CN } ] }, preferred: true } ], managingOrganization: { reference: Organization/org-maven-demo } }注意这里刻意省略了详细地址等敏感信息生产环境中 PHI 字段必须分级控制。实际接入时建议使用 HAPI FHIR 或 fhirclient 之类的库来解析和校验资源不要自己手写解析器。4.3 保存到患者画像平台在项目里可以写一个简单的 Repository 层把 FHIR 资源写入统一数据表。这里用 PostgreSQL 加 JSONB 字段存储CREATE TABLE patient_profile ( patient_id VARCHAR(64) PRIMARY KEY, fhir_resource JSONB NOT NULL, risk_level VARCHAR(16), pregnancy_week INT, updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), source_system VARCHAR(64) ); CREATE INDEX idx_patient_risk ON patient_profile(risk_level); CREATE INDEX idx_patient_updated ON patient_profile(updated_at DESC);为什么用 JSONB因为 FHIR 资源结构比较复杂生产环境中不同专科会有自定义扩展字段完全关系化表设计会导致频繁 DDL 变更。JSONB 在 Postgres 里支持索引和查询适合作为“湖仓一体”中的操作数据存储层。写入代码片段如下import json import psycopg2 from datetime import datetime def save_patient_profile(patient_id: str, fhir_resource: dict, risk_level: str): conn psycopg2.connect( hostlocalhost, dbnamehealth_platform, userapp_user, passwordyour_password ) cur conn.cursor() cur.execute( INSERT INTO patient_profile (patient_id, fhir_resource, risk_level, updated_at) VALUES (%s, %s, %s, %s) ON CONFLICT (patient_id) DO UPDATE SET fhir_resource EXCLUDED.fhir_resource, risk_level EXCLUDED.risk_level, updated_at EXCLUDED.updated_at; , (patient_id, json.dumps(fhir_resource, ensure_asciiFalse), risk_level, datetime.utcnow()) ) conn.commit() cur.close() conn.close()这里只是一个最小写入示例。生产环境建议使用连接池、事务管理以及专门的医疗数据迁移工具。5. 实战二构建 PHI 脱敏与安全防护管道5.1 PHI 脱敏的核心思路在把数据用于模型训练或第三方大模型之前必须先做去标识化。常见 PHI 包括姓名、地理位置、日期、电话、邮箱、社保号、病历号、照片等。脱敏有几种级别遮盖138****5678。替换把姓名替换为随机 ID。泛化把生日 “1993-05-17” 泛化为 “1993-05” 或 “25-30岁”。删除直接删除不必要字段。在 AI 原生平台中建议在数据进入统一数据平台之前就完成 PHI 脱敏。这样才能让算法工程师放心使用数据同时减少合规审计时的问题。5.2 一个简单的 Python 脱敏示例下面是一个用于演示的最小脱敏模块。生产环境建议结合 Azure Presidio、AWS Comprehend Medical、Google Healthcare API 等专业工具。import re import hashlib PHONE_PATTERN re.compile(r(?!\d)(1[3-9]\d{9})(?!\d)) ID_PATTERN re.compile(r[A-Za-z0-9]{10,}) EMAIL_PATTERN re.compile(r[\w.-][\w-]\.[\w.-]) def mask_phone(match): return match.group(1)[:3] **** match.group(1)[-4:] def mask_email(match): email match.group(0) local, domain email.split() return local[0] *** domain def deidentify_text(text: str) - str: text PHONE_PATTERN.sub(mask_phone, text) text EMAIL_PATTERN.sub(mask_email, text) # 注意这里用哈希是为了保持同一 ID 的可追溯性 # 生产环境应使用密钥 HMAC而不是直接 sha256 return text def deidentify_document(doc: dict) - dict: if name in doc: doc[name] USER- hashlib.sha256( doc[name].encode(utf-8) ).hexdigest()[:12] if notes in doc: doc[notes] deidentify_text(doc[notes]) if phone in doc: doc[phone] mask_phone(re.match(r(?!\d)(1[3-9]\d{9})(?!\d), doc[phone])) return doc if __name__ __main__: sample { name: 张小雨, phone: 13812345678, email: xiaoyuexample.com, notes: 患者孕周32周主诉头痛。联系电话 13812345678。 } print(deidentify_document(sample))运行示例输出大致如下{ name: USER-1a2b3c4d5e6f, phone: 138****5678, email: x***example.com, notes: 患者孕周32周主诉头痛。联系电话 138****5678。 }一定要强调这只是一个教学示例。真实医疗数据脱敏远比这个复杂例如“孕周32周”这种文本本身可能间接指向个人还需要结合上下文去处理。5.3 模型访问安全策略在 AI 原生平台里模型不是只有训练时才涉及 PHI。调用外部大模型 API 时必须做到默认不把原始 PHI 发送给第三方。如果必须发送先脱敏并在合规评估通过后执行。请求日志只记录脱敏后的文本和用量。模型服务与业务服务隔离网络策略按最小权限配置。下面是一个请求前脱敏的切面示例示意from functools import wraps def phi_safe(model_func): wraps(model_func) def wrapper(text: str, *args, **kwargs): safe_text deidentify_text(text) result model_func(safe_text, *args, **kwargs) return result return wrapper phi_safe def call_llm(prompt: str): # 实际调用大模型 API return {answer: 示例回答}6. 实战三实现一个带人工复核的 AI 分诊助手6.1 模块拆解分诊助手是健康平台里很典型的一个 AI 场景用户输入主诉系统解析意图、识别风险、给出护理建议。我们从工程角度实现一个最小闭环包含FastAPI 服务。意图与风险关键词规则引擎演示用生产建议用模型。RAG 检索接口这里用一个本地知识库 JSON 模拟。LLM 生成回答使用 OpenAI 兼容 SDK。置信度与风险等级判断。人工复核队列。项目结构如下ai-triage-demo/ ├── app.py ├── risk_engine.py ├── knowledge_base.py ├── requirements.txt └── data/ └── clinical_guidelines.json6.2 风险规则引擎# risk_engine.py HIGH_RISK_KEYWORDS [大出血, 呼吸困难, 剧烈腹痛, 失去意识, 胸痛, 抽搐] MEDIUM_RISK_KEYWORDS [发烧, 头痛, 宫缩频繁, 胎动减少, 呕吐] def assess_risk(text: str) - str: 返回 high / medium / low 三个等级。 text_lower text.lower() for kw in HIGH_RISK_KEYWORDS: if kw in text_lower: return high for kw in MEDIUM_RISK_KEYWORDS: if kw in text_lower: return medium return low这只是一个高度简化的示例。生产环境应该使用基于临床指南构建的规则库或微调分类模型而且必须经过临床团队审核。6.3 模拟知识库与 RAG 检索这里用一个 JSON 文件模拟内部医学知识库[ { id: 1, condition: 孕期头痛, advice: 建议先测量血压记录头痛频率。若伴随视力模糊或剧烈呕吐需尽快就医。, keywords: [头痛, 偏头痛, 孕期头痛] }, { id: 2, condition: 胎动减少, advice: 建议先静坐休息记录一小时内胎动次数。如果胎动持续减少请及时联系您的医生。, keywords: [胎动减少, 胎动少, 不动] } ]检索函数# knowledge_base.py import json class KnowledgeBase: def __init__(self, path: str data/clinical_guidelines.json): with open(path, r, encodingutf-8) as f: self.docs json.load(f) def search(self, query: str, top_k: int 2): scored [] for doc in self.docs: score sum(1 for kw in doc[keywords] if kw in query) if score 0: scored.append((score, doc)) scored.sort(keylambda x: x[0], reverseTrue) return [doc for _, doc in scored[:top_k]]在生产环境中这一步通常会用向量数据库如 Pinecone、Weaviate、Milvus做语义检索并将文档经过切片、向量化后入库。文本关键词匹配无法理解近义词所以这里仅作为演示。6.4 FAISS 向量检索版本可选如果希望更贴近生产场景可以用 FAISS 做向量检索。下面是核心思路from sentence_transformers import SentenceTransformer import faiss import numpy as np # 加载模型 encoder SentenceTransformer(BAAI/bge-small-zh-v1.5) doc_texts [doc[advice] for doc in docs] doc_vectors encoder.encode(doc_texts, normalize_embeddingsTrue) index faiss.IndexFlatIP(doc_vectors.shape[1]) index.add(np.array(doc_vectors)) def vector_search(query: str, top_k: int 2): query_vec encoder.encode([query], normalize_embeddingsTrue) scores, indices index.search(np.array(query_vec), top_k) return [docs[i] for i in indices[0]]注意embedding 模型和向量库的版本更新较快实际部署时需要锁定模型版本避免因升级导致向量空间偏移。6.5 构建 FastAPI 分诊接口下面实现完整的/triage接口包含脱敏、风险判断、知识检索、LLM 生成和人工复核标记。# app.py import os import uuid from datetime import datetime from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field from risk_engine import assess_risk from knowledge_base import KnowledgeBase from phi_guard import deidentify_text # 如果你使用 OpenAI SDK需要 pip install openai # 也可以换成其他兼容接口比如 Azure OpenAI、本地 vLLM 服务 try: from openai import OpenAI client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL) # 可选兼容中转服务 ) except ImportError: client None app FastAPI(titleAI Triage Demo) kb KnowledgeBase() class TriageRequest(BaseModel): user_message: str Field(..., min_length3, max_length500) session_id: str class TriageResponse(BaseModel): triage_id: str risk_level: str need_human_review: bool review_reason: str ai_answer: str sources: list created_at: str def build_prompt(user_message: str, risk_level: str, contexts: list) - str: context_text \n.join([f- {c[condition]}: {c[advice]} for c in contexts]) return f 你是一位健康平台的智能助手。你的任务是根据用户主诉和已有的内部指南给出安全、可执行的初步护理建议。 你必须遵守以下规则 1. 不进行明确诊断不使用绝对化用语。 2. 所有建议必须基于给定的内部指南不得凭空编造。 3. 如果用户是高危情况必须强调需要立即联系医生或拨打紧急电话。 4. 回答尽量简洁、温和、结构化。 用户风险等级{risk_level} 内部指南 {context_text} 用户主诉{user_message} 请给出建议 def generate_answer(user_message: str, risk_level: str, contexts: list) - str: if client is None: # 如果没配置 LLM SDK这里返回一个基于规则的回退答案 if risk_level high: return 根据您的描述这属于需要尽快处理的情况请立即联系医生或前往最近的急救中心。 return 平台已记录您的描述相关护理团队会尽快与您联系。 prompt build_prompt(user_message, risk_level, contexts) resp client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: prompt}], temperature0.2, max_tokens300 ) return resp.choices[0].message.content app.post(/triage, response_modelTriageResponse) def triage(req: TriageRequest): # 1. 脱敏生产环境下原始 message 不应进入日志和 LLM safe_message deidentify_text(req.user_message) # 2. 风险等级 risk_level assess_risk(safe_message) # 3. 知识检索 contexts kb.search(safe_message, top_k2) # 4. LLM 生成 ai_answer generate_answer(safe_message, risk_level, contexts) # 5. 高风险自动转人工 need_human_review risk_level in (high, medium) review_reason if risk_level high: review_reason 检测到高危关键词需要临床人员优先复核 elif risk_level medium: review_reason 中风险主诉建议护理团队关注 # 6. 生成审计记录演示代码仅打印生产环境应持久化 triage_id str(uuid.uuid4()) audit_log { triage_id: triage_id, session_id: req.session_id, risk_level: risk_level, need_human_review: need_human_review, safe_message: safe_message, created_at: datetime.utcnow().isoformat() } print(AUDIT_LOG:, audit_log) return TriageResponse( triage_idtriage_id, risk_levelrisk_level, need_human_reviewneed_human_review, review_reasonreview_reason, ai_answerai_answer, sources[{condition: c[condition]} for c in contexts], created_ataudit_log[created_at] ) app.get(/health) def health(): return {status: ok}requirements.txtfastapi0.110 uvicorn0.29 pydantic2.6 openai1.306.6 运行与验证启动服务pip install -r requirements.txt export OPENAI_API_KEYyour-key # 生产环境用密钥管理服务 uvicorn app:app --host 0.0.0.0 --port 8000调用分诊接口curl -X POST http://localhost:8000/triage \ -H Content-Type: application/json \ -d {session_id: demo-001, user_message: 我孕32周今天胎动明显减少有点担心。}预期响应结构如下{ triage_id: 6f65bfea-5ecf-4a87-8a5a-4e32b6b9e1a4, risk_level: medium, need_human_review: true, review_reason: 中风险主诉建议护理团队关注, ai_answer: 您好胎动减少是一个需要重视的信号。建议您先静坐休息记录一小时内胎动次数。如果胎动持续减少请及时联系您的医生或前往医院检查。, sources: [ {condition: 胎动减少} ], created_at: 2025-XX-XXT12:00:00.000000 }注意如果你没有配置 OpenAI Key代码会走回退逻辑返回固定的安全提示。这只是工程演示不代表真实诊疗建议。6.7 Human-in-the-loop 怎么落接口里已经标记了need_human_review。在实际平台需要把这类记录写入一个“审核队列”数据库表临床团队通过内部看板处理CREATE TABLE triage_review_queue ( triage_id VARCHAR(64) PRIMARY KEY, risk_level VARCHAR(16), user_message TEXT, ai_answer TEXT, status VARCHAR(16) DEFAULT pending, -- pending/reviewed/dismissed reviewer_id VARCHAR(64), reviewed_at TIMESTAMP WITH TIME zone, review_note TEXT );只有状态变成reviewed之后护理团队才会基于 AI 生成的建议去联系用户。整个过程允许 AI 犯错但最终负责任的是人和组织流程而不是模型。7. 常见问题与排查思路7.1 模型幻觉导致回答不专业问题现象常见原因解决思路模型给出了具体药名或诊断Prompt 没有限制输出范围在系统提示词中明确“不得建议具体药物”“不得给出确诊”模型回答与内部指南不一致RAG 检索结果没有约束模型只允许模型基于检索到的上下文回答不满足时要求“转人工”不同用户相同问题回答差异大温度参数过高医疗场景温度建议设在 0.1-0.3并固定模型版本7.2 数据合规问题导致上线阻塞问题现象常见原因解决思路安全审计发现日志包含 PHI日志打印了原始请求体全局拦截器统一脱敏后再记录模型训练数据包含可识别用户去标识化环节缺失构建强制脱敏管道所有入库数据先经过校验外部 LLM API 访问受限数据出境合规要求改用私有化部署的开源模型例如 Qwen、ChatGLM、Llama 系列7.3 RAG 检索效果差问题现象常见原因解决思路检索不到相关文档知识库切片粒度太大或太小按段落/语义单元切片测试不同 chunk size语义混淆找回无关内容Embedding 模型与领域不匹配评测多个 embedding 模型或在医疗语料上微调检索结果有但回答没用没有重排序增加 reranker 模型用交叉编码器精排7.4 模型“答非所问”或拒绝回答问题现象常见原因解决思路模型过度谨慎一律拒绝Prompt 安全边界过严设置分级安全策略低风险问题正常回答高风险问题转人工模型输出之前的历史记录上下文没有隔离每个请求只携带必要的对话摘要不传全量历史问“头痛”回答“怀孕”知识库噪音过多检查检索结果的相关性加入阈值过滤8. 工程最佳实践与组织建议8.1 数据治理从第一天开始就做健康平台的数据很难在后面补。建议在立项阶段就定义好数据字典、字段负责人、数据质量监控指标。所有源系统接入统一数据平台时至少要包含三个字段数据来源、采集时间、数据可信度。医疗领域最忌讳“先拉数据看看再说”不在源头控制质量后面 AI 模型的准确率都会受影响。8.2 模型管理版本、评估、回滚在健康场景模型更新不能像普通互联网项目那样“发了再说”。建议实践每个模型注册到 Model Registry记录训练数据、验证集、指标。上线前通过离线指标评估和在线影子模式评估。线上监控回答拒绝率、转人工率、用户投诉率、平均延迟。一旦发现问题能一键回滚到上一个稳定版本。8.3 临床团队与算法团队协同AI 原生健康公司最容易犯的错误是算法团队闭门造车。正确做法是临床团队参与数据标注标准制定、Prompt 编写、模型输出评审、风险等级阈值设定。每周至少安排一次“临床-AI”联合评审会把上周模型误判案例拿出来复盘。误判案例是模型的自然语料应该进入下一轮微调或检索优化流程。8.4 安全和可观测性生产环境一定要做好健康平台特有的可观测性每次 AI 调用的 prompt 与 completion 需留存脱敏后。记录用户反馈是否有“答案帮助不大”按钮。记录护理团队对 AI 建议的修改率。对风险等级分布做监控如果高风险的占比突然飙升要检查规则引擎是否被误改。这些指标不只是为了排查问题更是为了向监管方证明你的 AI 系统是可控的。8.5 优先走“保守但可用”的路线不管你的模型能力多强在产品设计上仍建议采用“AI 提议人决定”的默认模式AI 先做文字提取、摘要、分诊、推荐。人工专家做最终决策。用户最终看到的信息可以注明“由 AI 辅助生成已由平台护理团队审核”。这套模式不一定是最惊艳的但它是医疗合规场景下最快能上线、也最容易获得用户信任的方式。9. 从零到一怎么推动 AI-Native 落地如果你不是 Maven Clinic 这样的大型平台而是一个从零开始的健康项目可以按下面这个节奏推进。9.1 阶段一统一数据底座先把所有健康数据统一到 FHIR 模型或自定义的患者模型中建立一套字段规范。这一步不涉及任何模型但它是后续所有 AI 能力的基石。9.2 阶段二做单个高价值场景不要一开始就做“全科智能医生”。选择一个数据基础较好、临床协作顺畅的场景比如“孕期高风险人群识别”或“常规咨询自动分诊”把这个场景做深。9.3 阶段三建立评估闭环模型上线后记录每一次推荐结果的反馈包括用户是否采纳、医生是否修改、最终结果是否良好。这些反馈会成为下一轮模型迭代的数据资产。9.4 阶段四扩展能力层当数据、评估、安全合规验证都顺利后再把 AI 能力沉淀为平台能力层比如统一的意图识别服务、统一的分诊服务、统一的 RAG 服务让新业务线通过 API 直接调用。AI 原生的终局不是某几个酷炫的模型而是让公司任何一个新业务模块都能低门槛地使用已有的数据、模型和治理能力。如果你准备动手可以先做一件小事把当前系统里最核心的一条主流程画出来标出哪些节点每次都需要人肉判断哪些节点可以用 NLP、推荐、预测模型减轻人力负担。然后把其中一个节点用最小代码跑通。把这个闭环做完你离 AI-Native 健康公司就不再是概念上的理解而是一套可以持续迭代的工程能力了。