晚上十一点家里老人突然发热咳嗽要不要直接冲急诊很多人都有过这种纠结。AI问诊网站设计方案本质上就是给这种纠结提供一条结构化路径——用户用自然语言描述症状系统通过多轮对话收集关键信息输出分诊建议、就医科室、紧急风险提示以及下一步行动指引。它不是线上医生更不是处方工具而是把线下排队前的预检分诊和医患信息整理搬到网站上。这篇文章我会从定位、问诊流程、技术架构、数据合规、交互体验、质量评估到上线避坑完整拆一遍AI问诊网站的设计思路。适合正在做医疗产品方案的产品经理、准备从0到1搭建问诊系统的研发同学也适合想低成本验证AI医疗场景的独立开发者。1. 定边界比写代码更早AI问诊网站到底解决谁的什么问题很多人拿到这个题目上来就讨论模型选型和对话效果但我建议先把边界问题想清楚这个网站到底做到哪一步该停。边界不清后面做的越多返工越狠。1.1 辅助决策和替代医生之间隔着一条红线AI问诊网站的角色更像导诊台的资深护士负责预检、分诊、整理信息而不是门诊室里的主治医生。这个定位决定了从技术到交互的几乎一切后续设计。想明白这一点后很多争议会自然消失。比如“AI能不能直接告诉患者得了什么病”答案是不能。AI可以罗列可能的方向可以说明该注意什么但不该给出最终的确定性诊断更不该给出具体用药方案。在实际项目里常见的情况是团队为了突出卖点总想往“AI医生”的方向靠。结果上线后第一波投诉全是患者拿着AI说的话和线下医生对峙两边都不讨好。这个教训几乎每个做医疗AI的团队都会遇到。所以第一版方案的定位一定写清楚健康咨询、智能分诊、就医引导。所谓“辅助决策”意思是帮助医生更快地了解患者也帮助患者更理性地走向线下医疗资源而不是替代任何环节。1.2 患者、医生、平台同时满意产品才能成立做医疗产品用户画像不能只盯着患者。AI问诊网站需要同时服务在问诊链路里出现的三方终端患者、接诊医生、运营平台。患者要的是“我现在该不该去医院、挂哪个科、去之前准备什么”医生要的是“患者来之前病史已经是结构化整理好的”平台要的是“线上问诊变成可沉淀的复诊和随访入口”而不是用户聊完就走。参与方核心诉求AI问诊网站如何回应患者快速知道严重程度和就医方向多轮对话 分诊建议 紧急预警医生减少重复性的首诊信息收集自动生成结构化病历摘要可对接院内系统平台提升线上问诊转化与留存问诊结束后引导到在线复诊或挂号如果只满足患者这一端产品会做成一个“症状查询器”用完即走如果只满足平台端产品就会变成流量转化的漏斗缺乏医疗专业支撑。好的方案是把三者串在一条主流程上患者完成AI预问诊后结果页给出分诊建议同时生成一份可分享的个人健康摘要在用户授权后提供给线下接诊医生。这一步也是后面做数据资产沉淀的基础。1.3 独立站还是嵌入已有平台取决于冷启动方式是做一个独立的AI问诊网站还是在已有医疗平台里嵌入问诊模块这是方案早期就要拍板的事。独立站的优势是品牌和数据自主适合做垂直病种的轻问诊比如皮肤科、呼吸科用户可以直接触达。劣势是冷启动难没有渠道的用户不会无缘无故打开一个新网站。嵌入已有平台则相反用户进来时已经带着需求转化路径短但要考虑和历史业务的衔接。比如平台已经有在线问诊和挂号服务AI问诊的结果怎么落到医生排班和号源上。我的建议是如果团队没有强大渠道资源先用嵌入方式在现有入口里验证需求如果要走独立品牌第一版也建议从“AI预问诊 线下就医指引”这种轻功能起步不要一上来就做全套互联网医院。1.4 功能范围越小成功概率越大最后是一个反直觉的结论AI问诊网站第一版的功能范围应该比大多数人设想的都小。一个比较稳妥的上线标准是只挑三到五个症状相对清晰、线下分诊需求最强的科室比如呼吸科、消化科、皮肤科、儿科轻症。垂直领域的好处有三层知识库可以建得足够深分诊规则可以梳理得足够细模型幻觉率能被压到可控范围。等跑通一个科室再横向复制到下一个比什么都做要稳得多。我看到不少团队第一版就搞“AI全科医生”看似覆盖面广实际每个科室的知识库都薄得像一张纸。用户稍微问深一点AI就开始车轱辘话。这种体验上线一次就会伤一批用户后面再想拉回信任非常难。2. 从“今天哪里不舒服”开始问诊主流程该怎么设计定位定清楚之后接下来就是用户进入网站后的每一步。问诊主流程是整个产品的骨架流程设计决定了信息能不能收集齐、风险能不能拦住、结论能不能落地。2.1 首屏不该是一张大表单进入网站后的第一屏到底放什么很多方案的首版设计是一张主诉表单年龄、性别、体温、持续时间、过敏史、既往病史全部列出来。数据收集得很整齐但用户的真实感受是“我才不舒服半天就要填半天的表”。流失率会非常高。好的做法是只放一个对话入口和一句开场白“今天哪里不舒服用一句话描述就好。”先让用户用自己的话讲系统后面再在对话里把缺失的结构化字段补齐。这么做有三个原因降低作答成本用户自然会说出最关心的内容自然语言里包含了表单拿不到的信息比如语气、程度词、冷热感受遇到急症情况时系统也能从这句话里提前嗅到风险尽早启动紧急流程。2.2 多轮对话要有一棵清晰的对话树多轮对话不是让AI自由发挥背后要有一棵清晰可追溯的对话树。拿“发热”举例第一轮收集到“发热”之后系统要自动触发这些追问分支体温最高多少度、发热多久了、有没有咳嗽或咳痰、有没有皮疹或咽喉痛、是否伴随胸痛或呼吸困难。每一个分支都有明确目标就是补充分诊和风险评估需要的参数。在实现层我比较推荐用状态机来管理整个对话。每一轮追问都是确定的状态节点什么时候问什么、什么条件下跳转到哪个节点都可以配置。不要遇到什么都丢给大模型现编。对话树和状态机管理的目的是让生成过程可控、可审计、可回退。简化的规则如下主诉采集并进入槽位补全再进风险评估最后生成结论一旦识别到“胸痛伴随向左臂放射”这类组合直接进入紧急提示状态用户说“不是这个意思”就回到最近一个未确认的关键槽位重新收集。2.3 医疗NLP的意图识别与槽位提取不能全指望大模型做医疗问诊意图和槽位的处理可以借助大模型但不能完全交给大模型。原因很现实同一个“疼”字可能是腹痛、头疼、胸口疼程度轻重完全不一样同一个词在不同语境里的指向也不同。方案里需要有明确的NLP模块专门做三件事。第一主诉意图分类判断用户是想咨询症状、想预约复诊还是想查询检查报告解读第二症状实体抽取至少覆盖部位、性质、时间、诱因、伴随症状这几类槽位第三否定表达识别比如“没有发烧”“不咳嗽”这类信息如果抽错后面的风险评估会完全偏离。典型坏例是用户说“三天前有点发热现在已经不烧了”模型却把“发热”当成当前症状继续追问体温最后分诊到发热门诊。这种情况在真实对话里很常见所以否定词和时间状语一定要单独解析不要在提示词里指望模型自动理解。2.4 症状到科室的映射规则比模型更可靠把症状集合映射到科室是分诊的核心动作。这里我的经验是能写规则的先写规则规则覆盖不了的再交给模型兜底。因为分诊场景对可解释性要求很高患者问“为什么推荐我到呼吸内科”系统至少要能说清楚“因为你持续咳嗽3天、伴有黄痰、无呼吸困难”。规则跑出来的结果天然是可解释的。规则设计上要特别注意危险信号优先级。比如“胸痛”这个症状如果同时伴随出汗、胸闷、左臂放射痛就不能简单分到心血管内科要提示立即就医走急诊通道。这属于安全兜底逻辑优先级高于一切分诊逻辑。任何科室推荐都必须先跑一遍危险信号判定过了这关才做映射。分诊准确率目标建议定在95%以上实现时宁可推荐范围大比如拿不准时推荐“内科”而不是具体到“呼吸内科”也不要给出一个错的三级科室。2.5 问诊结论页核心是“下一步做什么”AI问诊的结果展示很多产品会放一个“可能疾病”列表这是我最不建议的做法。疾病列表容易给用户造成不必要的焦虑也容易被截屏断章取义。结论页的内容应该围绕行动来组织而不是围绕病名来组织。一个合格的结论页至少包含四块第一就医方向提示说明建议到哪个科室就诊或是否建议直接去急诊第二需要立即警惕的症状列清楚什么情况下不能再等必须马上就医第三就诊前准备建议比如带上既往病史记录、近期检查单第四免责声明明确提示“本结果不构成诊断”。顺序上紧急提示永远在最上面这个习惯不能改。3. 技术架构模型层、知识库层、业务层的分工与衔接技术架构不是把一个大模型API接进来就完事。AI问诊网站要做到“能跑通”和“能维护”需要把模型能力、知识数据、业务逻辑拆开各司其职。3.1 模型选型和部署形态要根据阶段决定目前做AI问诊模型选型基本在三类里面选通用大模型API、医学垂直模型API、开源模型私有化部署。三类方案各有取舍不能简单说哪个好。方案优势劣势适合阶段通用大模型API对话能力强、开发快医学知识不专深可控性弱原型验证医学垂直模型API医学话术更稳、行业适配好授权成本不透明有预算且速度优先开源模型私有化数据不出域、可控性强运维成本高、需微调稳定运营阶段对AI问诊这个场景我倾向于“通用大模型 私有化知识库 规则兜底”的混合路线而不是一上来就训练自己的医学模型。原因是问诊对话的开放性很高通用模型能接住各种奇怪的说法知识库负责把专业信息固定住规则层负责守住安全底线。三者分工是这个场景下性价比比较高的方案。3.2 医疗知识库要做结构化没有结构的库等于没有库知识库是AI问诊专业性的底座但不少团队把“收集一批文档”当成“建知识库”。真正能支撑问答的是结构化的医疗知识集合。每条知识至少要包含这几个字段症状实体、推荐科室、危险信号、建议动作、知识来源、更新日期。每一条都要可溯源这是医疗场景和其他领域最大的区别。举个例子“发热伴皮疹”这条知识要同时关联推荐科室、危险信号、建议动作和来源。来源不一定是论文可以是权威医学教材、公开诊疗指南、官方健康科普但必须能写清楚出处供后期审核。存储层面可以用“图谱 文档库”的双轨结构图谱负责实体间关系检索文档库负责原文召回。如果精力有限用带全文检索的文档库先跑RAG也能覆盖大部分需求但结构化字段不能省这是后续升级的地基。3.3 RAG是把幻觉压下去的关键手段AI问诊最怕的一件事是模型一本正经地把一个不存在的症状组合说得头头是道。幻觉在健康场景里不可接受。RAG也就是检索增强生成是当前比较实用的克制方法。思路不复杂模型不裸答先根据用户当前输入从知识库检索相关条目再把检索结果作为上下文拼进提示词让模型只能基于这些材料来回答。提示词结构大致是这样系统提示写明“你是智能导诊助手只能基于提供的知识库内容回答知识库中没有的内容要明确告知用户建议线下咨询”然后把检索到的知识条目按编号拼进上下文并规定回答只能在引用条目编号范围内生成。这样做有一个非常实际的好处即使模型说错也能顺着引用编号回溯判断是检索出错还是生成出错修起来有方向。3.4 响应体验用SSE流式输出保住耐心大模型生成一段回复的时间通常在3到8秒如果等待界面是一片空白用户会以为网站卡死了。医疗问诊的用户本身情绪就焦虑多等几秒的体验会被放大成“这个平台不可靠”。所以方案里要强制做流式输出。实现上SSE比WebSocket更轻量适合单方向流式响应前端用EventSource接一下就行。如果后续要做实时双向对话再考虑WebSocket。流式输出的中间状态也要设计好先返回“已经为您整理了问诊信息正在评估风险”再逐字输出正文每隔一段时间给一个进度提示让用户始终知道系统在工作而不是卡死。3.5 服务端模块划分清晰到可以直接拆人服务端不能只是一个chat接口至少要拆成几个边界清晰的模块。接入层负责会话鉴权和限流对话管理服务维护多轮状态机NLP服务做意图识别和实体抽取知识检索服务查知识库生成服务负责调用模型并拼接上下文评估服务做置信度检查和危险信号双重校验审计服务把所有对话和输出落盘。接口层面有三个点要注意幂等性用户网络波动导致重复请求时不能生成两条结论超时处理模型调用超时后要有兜底回复限流高频接口必须区分普通用户和异常流量防止被刷。这些看起来是通用工程问题但在医疗场景里任何一个坑都可能触发安全事件。4. 数据合规不是后续补丁隐私、权限与审核怎么前置设计AI问诊天然涉及大量健康数据。方案里如果先把业务跑起来再补合规后面基本要重做。这一章说的是怎么把数据合规当成设计的一部分而不是上线前交给合规部门去补课。4.1 最小化采集是第一步也是最重要的一步很多产品会把所有能问到的问题全问一遍美其名曰“数据越全评估越准”。但在问诊场景里过度收集既增加用户填写负担也会埋下合规风险。设计原则应该是最小化采集能支持本次分诊决策的数据才收集暂时用不上的等用到时再问。比如第一轮问诊只需要年龄、性别、主诉、持续时间、伴随症状、过敏史。家族史、婚育史这些信息只在问题真正相关时才触发。采集的时候还要让用户明确知道数据仅用于本次问诊评估不用于营销不外泄。这一步虽然只是文案但后台的数据流程必须真的按文案执行虚假承诺比不承诺的风险更大。4.2 脱敏、假名化与访问权限分级健康数据脱敏不能只做姓名和手机号它分好几个层次。第一层从界面和日志里去掉身份标识用户在前端只呈现匿名ID第二层存储拆分用户基本信息、问诊记录、模型调用日志分别存在不同库采用不同密钥管理第三层假名化只有经过授权的主索引表才能把匿名ID关联回真实身份这个表的访问权限要单独审批。权限分级要落到角色上患者本人只能查看自己的历史问诊记录和导出健康摘要医生端只能在用户授权范围内查看问诊记录运营人员只可见统计数据和脱敏后的分析报表模型研究员只能访问脱敏数据集原始对话不开放。每一类访问都要落到操作日志里谁在什么时间改了什么数据必须可回溯。4.3 免责声明和内容审核要做到多级拦截免责声明不能只在注册协议里出现那不是给用户看的是给合规审计看的。面向患者的免责要做到三个位置问诊前有一屏须知说明AI仅提供健康咨询与分诊建议不构成诊断也不能替代线下医生结论页有醒目的提示对话中一旦用户询问“给我开点药吧”AI要自动回复“我不能开药建议到线下医疗机构进行正规诊疗”。输出端必须加一道内容审核服务。审核包括违禁词过滤、广告营销信息拦截、高危关键词识别。比如精神科、肿瘤科相关问题AI可以答最基础的咨询但一旦涉及复杂病情建议一键转人工。这道审核不能放在模型生成之后靠人工看要在生成环节就通过提示词约束和自动过滤规则双重处理。4.4 资质和标准给方案预留扩展窗口医疗赛道的合规设计不能等到产品成型再想。第一版建议避开在线开方、在线售药、远程诊断这类强监管功能只做健康咨询、预问诊、就医分诊。这也是为什么前几章一直强调边界的原因边界越小需要面对的监管复杂度越低。同时在技术管理上向行业标准对齐网络安全等级保护的基本要求按高等级设计涉及核心健康数据时不依赖不可控的第三方链路用户数据的留存期限、删除请求响应流程、最小必要授权范围都要在后台完成配置而不是写个文档放着。这套底座做好了未来要接在线复诊、电子病历、医院合作时成本会低很多。5. 信任感是“做”出来的AI问诊界面的交互细节医疗场景的交互设计核心指标不只是转化率更是信任感和安全感。AI问诊如果让用户感觉对面是个不可知的黑盒子就算答案是对的用户也不敢照着做。5.1 AI的身份展示别把自己包装成真人医生第一件事是管住“人设”。产品里AI的名称我建议用“智能导诊助手”而不是“AI医生”“在线专家”。开场对话里也要有一句明确说明“我是AI基于医学知识库为您提供问诊引导不能代替医生面诊。”这句话不是免责咒语而是在管理用户预期从第一句话就让大家知道边界。视觉设计上蓝色、白色、浅绿色的医疗基调比较合适避免大面积深红色块带来的紧张感。互动元素尽量克制不要用闪烁、弹窗这类促销页面常见的套路。患者进来时已经很焦虑了界面越稳定、越安静越容易建立基本信任。5.2 关键信息必须回显确认用户在多轮对话里说了20个细节全凭AI默默记住用户心里没底。比较靠谱的做法是在生成结论之前把关键信息整理成一段简明摘要回显给用户我理解您目前的主要症状是咳嗽伴随发热已经持续3天体温最高38.5度没有胸痛和呼吸困难对吗点击“以上信息无误”再生成结论点击“需要修改”再进入修正分支。这个确认步骤可能会让一小部分用户觉得多了一步但从实测数据看它降低的投诉率远高于它造成的流失率。医疗决策一旦基于错误信息后果是用户承担。确认机制本质上是在为风险控制和用户信任同时买单。5.3 紧急情况要能识别而且要用产品语言打断紧急情况的识别不能只靠模型。模型有温度但也有延迟和不确定性。方案里应该有一层独立的规则系统对胸痛、呼吸困难、意识模糊、持续大量出血、严重烧伤等关键词做实时判定。一旦命中界面立刻切到高风险提示页全屏展示“这些症状可能属于高风险情况请立即前往最近医疗机构急诊科”同时停止当前对话不再追加任何询问。这条设计要做两个“宁可”宁可误报不可漏报宁可让用户觉得系统谨慎不可让用户回家等一个错误判断。用产品语言直接打断比在大段对话里夹一句警示要有力得多。5.4 可解释性让用户看到结论是怎么来的推荐科室的结论页要把推理链拆给用户看因为你出现咳嗽3天伴随黄痰且没有呼吸困难所以初步建议选择呼吸内科就诊。一条条列出来用户会更有底气。如果系统调用了知识库条目可以在结论下方放一个“这些建议的依据是什么”的折叠区域里面放知识条目摘要和来源名称。这不仅是在提升信任感也是在倒逼内部检索引擎做对。如果给不出依据这条回答一开始就不应该放出来。把可解释性当成产品功能来做而不是合规包袱是医疗AI产品和普通聊天机器人拉开差距的地方。6. 用指标和坏例推动迭代问诊质量评估体系怎么搭AI问诊的性能评估不能用通用对话的文本相似度指标。用户不关心生成文本和参考答案重复了几个词只关心结果是否安全、准确、可执行。所以评估体系要单独设计。6.1 核心评估指标分“结果”和“过程”两类先列几个实际在用的指标指标定义建议目标分诊准确率推荐科室与医生复核的一致率大于等于95%风险识别覆盖率危险信号被系统识别的比例100%零漏报回答合理率医生标注为合理可用的比例大于等于90%患者放弃率进入问诊后未完成流程的比例持续下降坏例找回率运营主动发现问题的比例越高越好风险识别覆盖率是唯一没有商量余地的指标。回答合理率必须靠医生或专业人员抽检标注不能只看AI自评分。标注成本高但这是医疗产品守住底线必须付出的成本。6.2 人工复核闭环是高质量问答的地基每次AI生成结论后都要得到一个质量标签单靠模型自评不够。上线初期建议每100条对话抽检10到20条由具备医学背景的复核人员逐条看产品稳定后可以降到5%但绝不能完全不抽。复核结果要反馈到三个地方更新规则库、改进提示词、丰富知识库。同时要建立bad case库把高风险漏判、常识性错误、答非所问、语气不当的对话都归档。这个库既是运营复盘的数据来源也是后续训练集和回归测试集的重要基础。6.3 坏例复盘怎么做才不流于形式每周固定开一次坏例复盘会不是把所有差评拿出来批判一通而是按原因归类。通常分成几类知识库缺条目、规则冲突、模型生成越界、对话状态错乱。每一类要有明确的后续动作。比如“模型生成越界”这一类常见的是用户询问某种药物可不可以吃模型直接给了说明甚至推荐。这类坏例出现一次就应该在提示词里加强约束只提供通用性建议具体用药由线下医生判断同时规则层加一个“用药询问即转人工”的拦截。坏例之所以要分类讨论就是避免每次都在同一个问题上反复打补丁。6.4 提示词和知识库怎么迭代才稳提示词的改动比代码还敏感改一句话可能导致一片问题。每次迭代都要小步快改同时保留版本回滚能力。知识库按月更新每次更新锁定历史版本审核通过后再切线上提示词的修改按bad case触发每次改动跑一遍全量回归用例。回归用例集要从bad case库里沉淀至少几百条典型对话确保修了A问题不引出B问题。7. 上线前后最容易翻车的四个地方最后讲几个在设计和验证过程中反复遇到的坑如果能避开上线后的运营会省掉很多麻烦。7.1 模型幻觉最隐蔽也最危险模型幻觉是医疗AI的长期对手。它不是偶尔出现而是只要不加约束就会在特定场景反复出现。比如用户问“我最近总感觉头晕乏力”这种不典型症状模型很容易自己编一个“贫血”的方向。这不是它想骗人而是概率生成的本质决定的。解决的组合拳前面已经提到RAG强约束、结论只能引用知识库、检索不到就坦白说不知道、低于置信度阈值直接给“建议线下就医”的模板回复。宁可回答得“笨”不能回答得“险”。7.2 多轮对话的状态错乱比想象中更容易出现真实用户不会按对话树走。前一秒说“我胃疼”后一秒又说“其实主要是右边小腹疼”系统必须识别这是症状修正而不是新增了一个症状。如果不处理最终结论可能同时包含胃炎和阑尾炎两个方向让用户不知所措。工程做法是在槽位层做覆盖确认当新症状实体与已确认实体冲突时自动发起“您刚才说的是胃疼现在说小腹疼以哪个为准”的确认。状态机设计时也要预留回退路径让用户随时可以回到上一步重新选择。7.3 大模型响应延迟和并发突刺会影响口碑上线首日如果遇到流量尖峰模型服务很容易慢到无法接受。一方面要做对话缓存常见症状组合和对应结论可以缓存大幅降低压力另一方面要对长响应做超时降级超过限定时间时先返回简短的安全提示而不是继续转圈。如果预算允许给模型服务单独做弹性扩缩容并预置一组更小的快模型流量高时优先用快模型跑分诊规则避免所有请求都挤在大模型上。7.4 运营侧投诉预案很多团队完全没准备技术团队容易忽略的是产品上线后一定会有投诉。不怕投诉怕的是没有预案。预案包含三层第一层是AI自动兜底话术凡是用户表达不满先回复“非常抱歉给您带来困扰您的问题已转交人工客服”第二层是客服后台能看到完整对话记录并一键生成投诉处理工单第三层是安全值班机制重大风险问题要能在一小时内通知到产品和医疗负责人。这个机制不需要多高级上线前演练一遍就行。我对AI问诊网站设计方案最大的体会是真正决定产品成败的不是模型选得多高级而是边界画得多清晰。把“什么不做”想明白了后面每个环节都会顺很多。最后再分享一个小技巧结论页里一定要加一个“依据”折叠区域把知识库来源放进去。这个设计既能缓解“AI不可信”的疑虑也能逼着团队把知识库质量做好。如果问诊质量闭环能稳定跑上三个月再考虑往在线复诊、随访、慢病管理这些方向扩展地基不会白费。
晚上十一点家里老人突然发热咳嗽要不要直接冲急诊很多人都有过这种纠结。AI问诊网站设计方案本质上就是给这种纠结提供一条结构化路径——用户用自然语言描述症状系统通过多轮对话收集关键信息输出分诊建议、就医科室、紧急风险提示以及下一步行动指引。它不是线上医生更不是处方工具而是把线下排队前的预检分诊和医患信息整理搬到网站上。这篇文章我会从定位、问诊流程、技术架构、数据合规、交互体验、质量评估到上线避坑完整拆一遍AI问诊网站的设计思路。适合正在做医疗产品方案的产品经理、准备从0到1搭建问诊系统的研发同学也适合想低成本验证AI医疗场景的独立开发者。1. 定边界比写代码更早AI问诊网站到底解决谁的什么问题很多人拿到这个题目上来就讨论模型选型和对话效果但我建议先把边界问题想清楚这个网站到底做到哪一步该停。边界不清后面做的越多返工越狠。1.1 辅助决策和替代医生之间隔着一条红线AI问诊网站的角色更像导诊台的资深护士负责预检、分诊、整理信息而不是门诊室里的主治医生。这个定位决定了从技术到交互的几乎一切后续设计。想明白这一点后很多争议会自然消失。比如“AI能不能直接告诉患者得了什么病”答案是不能。AI可以罗列可能的方向可以说明该注意什么但不该给出最终的确定性诊断更不该给出具体用药方案。在实际项目里常见的情况是团队为了突出卖点总想往“AI医生”的方向靠。结果上线后第一波投诉全是患者拿着AI说的话和线下医生对峙两边都不讨好。这个教训几乎每个做医疗AI的团队都会遇到。所以第一版方案的定位一定写清楚健康咨询、智能分诊、就医引导。所谓“辅助决策”意思是帮助医生更快地了解患者也帮助患者更理性地走向线下医疗资源而不是替代任何环节。1.2 患者、医生、平台同时满意产品才能成立做医疗产品用户画像不能只盯着患者。AI问诊网站需要同时服务在问诊链路里出现的三方终端患者、接诊医生、运营平台。患者要的是“我现在该不该去医院、挂哪个科、去之前准备什么”医生要的是“患者来之前病史已经是结构化整理好的”平台要的是“线上问诊变成可沉淀的复诊和随访入口”而不是用户聊完就走。参与方核心诉求AI问诊网站如何回应患者快速知道严重程度和就医方向多轮对话 分诊建议 紧急预警医生减少重复性的首诊信息收集自动生成结构化病历摘要可对接院内系统平台提升线上问诊转化与留存问诊结束后引导到在线复诊或挂号如果只满足患者这一端产品会做成一个“症状查询器”用完即走如果只满足平台端产品就会变成流量转化的漏斗缺乏医疗专业支撑。好的方案是把三者串在一条主流程上患者完成AI预问诊后结果页给出分诊建议同时生成一份可分享的个人健康摘要在用户授权后提供给线下接诊医生。这一步也是后面做数据资产沉淀的基础。1.3 独立站还是嵌入已有平台取决于冷启动方式是做一个独立的AI问诊网站还是在已有医疗平台里嵌入问诊模块这是方案早期就要拍板的事。独立站的优势是品牌和数据自主适合做垂直病种的轻问诊比如皮肤科、呼吸科用户可以直接触达。劣势是冷启动难没有渠道的用户不会无缘无故打开一个新网站。嵌入已有平台则相反用户进来时已经带着需求转化路径短但要考虑和历史业务的衔接。比如平台已经有在线问诊和挂号服务AI问诊的结果怎么落到医生排班和号源上。我的建议是如果团队没有强大渠道资源先用嵌入方式在现有入口里验证需求如果要走独立品牌第一版也建议从“AI预问诊 线下就医指引”这种轻功能起步不要一上来就做全套互联网医院。1.4 功能范围越小成功概率越大最后是一个反直觉的结论AI问诊网站第一版的功能范围应该比大多数人设想的都小。一个比较稳妥的上线标准是只挑三到五个症状相对清晰、线下分诊需求最强的科室比如呼吸科、消化科、皮肤科、儿科轻症。垂直领域的好处有三层知识库可以建得足够深分诊规则可以梳理得足够细模型幻觉率能被压到可控范围。等跑通一个科室再横向复制到下一个比什么都做要稳得多。我看到不少团队第一版就搞“AI全科医生”看似覆盖面广实际每个科室的知识库都薄得像一张纸。用户稍微问深一点AI就开始车轱辘话。这种体验上线一次就会伤一批用户后面再想拉回信任非常难。2. 从“今天哪里不舒服”开始问诊主流程该怎么设计定位定清楚之后接下来就是用户进入网站后的每一步。问诊主流程是整个产品的骨架流程设计决定了信息能不能收集齐、风险能不能拦住、结论能不能落地。2.1 首屏不该是一张大表单进入网站后的第一屏到底放什么很多方案的首版设计是一张主诉表单年龄、性别、体温、持续时间、过敏史、既往病史全部列出来。数据收集得很整齐但用户的真实感受是“我才不舒服半天就要填半天的表”。流失率会非常高。好的做法是只放一个对话入口和一句开场白“今天哪里不舒服用一句话描述就好。”先让用户用自己的话讲系统后面再在对话里把缺失的结构化字段补齐。这么做有三个原因降低作答成本用户自然会说出最关心的内容自然语言里包含了表单拿不到的信息比如语气、程度词、冷热感受遇到急症情况时系统也能从这句话里提前嗅到风险尽早启动紧急流程。2.2 多轮对话要有一棵清晰的对话树多轮对话不是让AI自由发挥背后要有一棵清晰可追溯的对话树。拿“发热”举例第一轮收集到“发热”之后系统要自动触发这些追问分支体温最高多少度、发热多久了、有没有咳嗽或咳痰、有没有皮疹或咽喉痛、是否伴随胸痛或呼吸困难。每一个分支都有明确目标就是补充分诊和风险评估需要的参数。在实现层我比较推荐用状态机来管理整个对话。每一轮追问都是确定的状态节点什么时候问什么、什么条件下跳转到哪个节点都可以配置。不要遇到什么都丢给大模型现编。对话树和状态机管理的目的是让生成过程可控、可审计、可回退。简化的规则如下主诉采集并进入槽位补全再进风险评估最后生成结论一旦识别到“胸痛伴随向左臂放射”这类组合直接进入紧急提示状态用户说“不是这个意思”就回到最近一个未确认的关键槽位重新收集。2.3 医疗NLP的意图识别与槽位提取不能全指望大模型做医疗问诊意图和槽位的处理可以借助大模型但不能完全交给大模型。原因很现实同一个“疼”字可能是腹痛、头疼、胸口疼程度轻重完全不一样同一个词在不同语境里的指向也不同。方案里需要有明确的NLP模块专门做三件事。第一主诉意图分类判断用户是想咨询症状、想预约复诊还是想查询检查报告解读第二症状实体抽取至少覆盖部位、性质、时间、诱因、伴随症状这几类槽位第三否定表达识别比如“没有发烧”“不咳嗽”这类信息如果抽错后面的风险评估会完全偏离。典型坏例是用户说“三天前有点发热现在已经不烧了”模型却把“发热”当成当前症状继续追问体温最后分诊到发热门诊。这种情况在真实对话里很常见所以否定词和时间状语一定要单独解析不要在提示词里指望模型自动理解。2.4 症状到科室的映射规则比模型更可靠把症状集合映射到科室是分诊的核心动作。这里我的经验是能写规则的先写规则规则覆盖不了的再交给模型兜底。因为分诊场景对可解释性要求很高患者问“为什么推荐我到呼吸内科”系统至少要能说清楚“因为你持续咳嗽3天、伴有黄痰、无呼吸困难”。规则跑出来的结果天然是可解释的。规则设计上要特别注意危险信号优先级。比如“胸痛”这个症状如果同时伴随出汗、胸闷、左臂放射痛就不能简单分到心血管内科要提示立即就医走急诊通道。这属于安全兜底逻辑优先级高于一切分诊逻辑。任何科室推荐都必须先跑一遍危险信号判定过了这关才做映射。分诊准确率目标建议定在95%以上实现时宁可推荐范围大比如拿不准时推荐“内科”而不是具体到“呼吸内科”也不要给出一个错的三级科室。2.5 问诊结论页核心是“下一步做什么”AI问诊的结果展示很多产品会放一个“可能疾病”列表这是我最不建议的做法。疾病列表容易给用户造成不必要的焦虑也容易被截屏断章取义。结论页的内容应该围绕行动来组织而不是围绕病名来组织。一个合格的结论页至少包含四块第一就医方向提示说明建议到哪个科室就诊或是否建议直接去急诊第二需要立即警惕的症状列清楚什么情况下不能再等必须马上就医第三就诊前准备建议比如带上既往病史记录、近期检查单第四免责声明明确提示“本结果不构成诊断”。顺序上紧急提示永远在最上面这个习惯不能改。3. 技术架构模型层、知识库层、业务层的分工与衔接技术架构不是把一个大模型API接进来就完事。AI问诊网站要做到“能跑通”和“能维护”需要把模型能力、知识数据、业务逻辑拆开各司其职。3.1 模型选型和部署形态要根据阶段决定目前做AI问诊模型选型基本在三类里面选通用大模型API、医学垂直模型API、开源模型私有化部署。三类方案各有取舍不能简单说哪个好。方案优势劣势适合阶段通用大模型API对话能力强、开发快医学知识不专深可控性弱原型验证医学垂直模型API医学话术更稳、行业适配好授权成本不透明有预算且速度优先开源模型私有化数据不出域、可控性强运维成本高、需微调稳定运营阶段对AI问诊这个场景我倾向于“通用大模型 私有化知识库 规则兜底”的混合路线而不是一上来就训练自己的医学模型。原因是问诊对话的开放性很高通用模型能接住各种奇怪的说法知识库负责把专业信息固定住规则层负责守住安全底线。三者分工是这个场景下性价比比较高的方案。3.2 医疗知识库要做结构化没有结构的库等于没有库知识库是AI问诊专业性的底座但不少团队把“收集一批文档”当成“建知识库”。真正能支撑问答的是结构化的医疗知识集合。每条知识至少要包含这几个字段症状实体、推荐科室、危险信号、建议动作、知识来源、更新日期。每一条都要可溯源这是医疗场景和其他领域最大的区别。举个例子“发热伴皮疹”这条知识要同时关联推荐科室、危险信号、建议动作和来源。来源不一定是论文可以是权威医学教材、公开诊疗指南、官方健康科普但必须能写清楚出处供后期审核。存储层面可以用“图谱 文档库”的双轨结构图谱负责实体间关系检索文档库负责原文召回。如果精力有限用带全文检索的文档库先跑RAG也能覆盖大部分需求但结构化字段不能省这是后续升级的地基。3.3 RAG是把幻觉压下去的关键手段AI问诊最怕的一件事是模型一本正经地把一个不存在的症状组合说得头头是道。幻觉在健康场景里不可接受。RAG也就是检索增强生成是当前比较实用的克制方法。思路不复杂模型不裸答先根据用户当前输入从知识库检索相关条目再把检索结果作为上下文拼进提示词让模型只能基于这些材料来回答。提示词结构大致是这样系统提示写明“你是智能导诊助手只能基于提供的知识库内容回答知识库中没有的内容要明确告知用户建议线下咨询”然后把检索到的知识条目按编号拼进上下文并规定回答只能在引用条目编号范围内生成。这样做有一个非常实际的好处即使模型说错也能顺着引用编号回溯判断是检索出错还是生成出错修起来有方向。3.4 响应体验用SSE流式输出保住耐心大模型生成一段回复的时间通常在3到8秒如果等待界面是一片空白用户会以为网站卡死了。医疗问诊的用户本身情绪就焦虑多等几秒的体验会被放大成“这个平台不可靠”。所以方案里要强制做流式输出。实现上SSE比WebSocket更轻量适合单方向流式响应前端用EventSource接一下就行。如果后续要做实时双向对话再考虑WebSocket。流式输出的中间状态也要设计好先返回“已经为您整理了问诊信息正在评估风险”再逐字输出正文每隔一段时间给一个进度提示让用户始终知道系统在工作而不是卡死。3.5 服务端模块划分清晰到可以直接拆人服务端不能只是一个chat接口至少要拆成几个边界清晰的模块。接入层负责会话鉴权和限流对话管理服务维护多轮状态机NLP服务做意图识别和实体抽取知识检索服务查知识库生成服务负责调用模型并拼接上下文评估服务做置信度检查和危险信号双重校验审计服务把所有对话和输出落盘。接口层面有三个点要注意幂等性用户网络波动导致重复请求时不能生成两条结论超时处理模型调用超时后要有兜底回复限流高频接口必须区分普通用户和异常流量防止被刷。这些看起来是通用工程问题但在医疗场景里任何一个坑都可能触发安全事件。4. 数据合规不是后续补丁隐私、权限与审核怎么前置设计AI问诊天然涉及大量健康数据。方案里如果先把业务跑起来再补合规后面基本要重做。这一章说的是怎么把数据合规当成设计的一部分而不是上线前交给合规部门去补课。4.1 最小化采集是第一步也是最重要的一步很多产品会把所有能问到的问题全问一遍美其名曰“数据越全评估越准”。但在问诊场景里过度收集既增加用户填写负担也会埋下合规风险。设计原则应该是最小化采集能支持本次分诊决策的数据才收集暂时用不上的等用到时再问。比如第一轮问诊只需要年龄、性别、主诉、持续时间、伴随症状、过敏史。家族史、婚育史这些信息只在问题真正相关时才触发。采集的时候还要让用户明确知道数据仅用于本次问诊评估不用于营销不外泄。这一步虽然只是文案但后台的数据流程必须真的按文案执行虚假承诺比不承诺的风险更大。4.2 脱敏、假名化与访问权限分级健康数据脱敏不能只做姓名和手机号它分好几个层次。第一层从界面和日志里去掉身份标识用户在前端只呈现匿名ID第二层存储拆分用户基本信息、问诊记录、模型调用日志分别存在不同库采用不同密钥管理第三层假名化只有经过授权的主索引表才能把匿名ID关联回真实身份这个表的访问权限要单独审批。权限分级要落到角色上患者本人只能查看自己的历史问诊记录和导出健康摘要医生端只能在用户授权范围内查看问诊记录运营人员只可见统计数据和脱敏后的分析报表模型研究员只能访问脱敏数据集原始对话不开放。每一类访问都要落到操作日志里谁在什么时间改了什么数据必须可回溯。4.3 免责声明和内容审核要做到多级拦截免责声明不能只在注册协议里出现那不是给用户看的是给合规审计看的。面向患者的免责要做到三个位置问诊前有一屏须知说明AI仅提供健康咨询与分诊建议不构成诊断也不能替代线下医生结论页有醒目的提示对话中一旦用户询问“给我开点药吧”AI要自动回复“我不能开药建议到线下医疗机构进行正规诊疗”。输出端必须加一道内容审核服务。审核包括违禁词过滤、广告营销信息拦截、高危关键词识别。比如精神科、肿瘤科相关问题AI可以答最基础的咨询但一旦涉及复杂病情建议一键转人工。这道审核不能放在模型生成之后靠人工看要在生成环节就通过提示词约束和自动过滤规则双重处理。4.4 资质和标准给方案预留扩展窗口医疗赛道的合规设计不能等到产品成型再想。第一版建议避开在线开方、在线售药、远程诊断这类强监管功能只做健康咨询、预问诊、就医分诊。这也是为什么前几章一直强调边界的原因边界越小需要面对的监管复杂度越低。同时在技术管理上向行业标准对齐网络安全等级保护的基本要求按高等级设计涉及核心健康数据时不依赖不可控的第三方链路用户数据的留存期限、删除请求响应流程、最小必要授权范围都要在后台完成配置而不是写个文档放着。这套底座做好了未来要接在线复诊、电子病历、医院合作时成本会低很多。5. 信任感是“做”出来的AI问诊界面的交互细节医疗场景的交互设计核心指标不只是转化率更是信任感和安全感。AI问诊如果让用户感觉对面是个不可知的黑盒子就算答案是对的用户也不敢照着做。5.1 AI的身份展示别把自己包装成真人医生第一件事是管住“人设”。产品里AI的名称我建议用“智能导诊助手”而不是“AI医生”“在线专家”。开场对话里也要有一句明确说明“我是AI基于医学知识库为您提供问诊引导不能代替医生面诊。”这句话不是免责咒语而是在管理用户预期从第一句话就让大家知道边界。视觉设计上蓝色、白色、浅绿色的医疗基调比较合适避免大面积深红色块带来的紧张感。互动元素尽量克制不要用闪烁、弹窗这类促销页面常见的套路。患者进来时已经很焦虑了界面越稳定、越安静越容易建立基本信任。5.2 关键信息必须回显确认用户在多轮对话里说了20个细节全凭AI默默记住用户心里没底。比较靠谱的做法是在生成结论之前把关键信息整理成一段简明摘要回显给用户我理解您目前的主要症状是咳嗽伴随发热已经持续3天体温最高38.5度没有胸痛和呼吸困难对吗点击“以上信息无误”再生成结论点击“需要修改”再进入修正分支。这个确认步骤可能会让一小部分用户觉得多了一步但从实测数据看它降低的投诉率远高于它造成的流失率。医疗决策一旦基于错误信息后果是用户承担。确认机制本质上是在为风险控制和用户信任同时买单。5.3 紧急情况要能识别而且要用产品语言打断紧急情况的识别不能只靠模型。模型有温度但也有延迟和不确定性。方案里应该有一层独立的规则系统对胸痛、呼吸困难、意识模糊、持续大量出血、严重烧伤等关键词做实时判定。一旦命中界面立刻切到高风险提示页全屏展示“这些症状可能属于高风险情况请立即前往最近医疗机构急诊科”同时停止当前对话不再追加任何询问。这条设计要做两个“宁可”宁可误报不可漏报宁可让用户觉得系统谨慎不可让用户回家等一个错误判断。用产品语言直接打断比在大段对话里夹一句警示要有力得多。5.4 可解释性让用户看到结论是怎么来的推荐科室的结论页要把推理链拆给用户看因为你出现咳嗽3天伴随黄痰且没有呼吸困难所以初步建议选择呼吸内科就诊。一条条列出来用户会更有底气。如果系统调用了知识库条目可以在结论下方放一个“这些建议的依据是什么”的折叠区域里面放知识条目摘要和来源名称。这不仅是在提升信任感也是在倒逼内部检索引擎做对。如果给不出依据这条回答一开始就不应该放出来。把可解释性当成产品功能来做而不是合规包袱是医疗AI产品和普通聊天机器人拉开差距的地方。6. 用指标和坏例推动迭代问诊质量评估体系怎么搭AI问诊的性能评估不能用通用对话的文本相似度指标。用户不关心生成文本和参考答案重复了几个词只关心结果是否安全、准确、可执行。所以评估体系要单独设计。6.1 核心评估指标分“结果”和“过程”两类先列几个实际在用的指标指标定义建议目标分诊准确率推荐科室与医生复核的一致率大于等于95%风险识别覆盖率危险信号被系统识别的比例100%零漏报回答合理率医生标注为合理可用的比例大于等于90%患者放弃率进入问诊后未完成流程的比例持续下降坏例找回率运营主动发现问题的比例越高越好风险识别覆盖率是唯一没有商量余地的指标。回答合理率必须靠医生或专业人员抽检标注不能只看AI自评分。标注成本高但这是医疗产品守住底线必须付出的成本。6.2 人工复核闭环是高质量问答的地基每次AI生成结论后都要得到一个质量标签单靠模型自评不够。上线初期建议每100条对话抽检10到20条由具备医学背景的复核人员逐条看产品稳定后可以降到5%但绝不能完全不抽。复核结果要反馈到三个地方更新规则库、改进提示词、丰富知识库。同时要建立bad case库把高风险漏判、常识性错误、答非所问、语气不当的对话都归档。这个库既是运营复盘的数据来源也是后续训练集和回归测试集的重要基础。6.3 坏例复盘怎么做才不流于形式每周固定开一次坏例复盘会不是把所有差评拿出来批判一通而是按原因归类。通常分成几类知识库缺条目、规则冲突、模型生成越界、对话状态错乱。每一类要有明确的后续动作。比如“模型生成越界”这一类常见的是用户询问某种药物可不可以吃模型直接给了说明甚至推荐。这类坏例出现一次就应该在提示词里加强约束只提供通用性建议具体用药由线下医生判断同时规则层加一个“用药询问即转人工”的拦截。坏例之所以要分类讨论就是避免每次都在同一个问题上反复打补丁。6.4 提示词和知识库怎么迭代才稳提示词的改动比代码还敏感改一句话可能导致一片问题。每次迭代都要小步快改同时保留版本回滚能力。知识库按月更新每次更新锁定历史版本审核通过后再切线上提示词的修改按bad case触发每次改动跑一遍全量回归用例。回归用例集要从bad case库里沉淀至少几百条典型对话确保修了A问题不引出B问题。7. 上线前后最容易翻车的四个地方最后讲几个在设计和验证过程中反复遇到的坑如果能避开上线后的运营会省掉很多麻烦。7.1 模型幻觉最隐蔽也最危险模型幻觉是医疗AI的长期对手。它不是偶尔出现而是只要不加约束就会在特定场景反复出现。比如用户问“我最近总感觉头晕乏力”这种不典型症状模型很容易自己编一个“贫血”的方向。这不是它想骗人而是概率生成的本质决定的。解决的组合拳前面已经提到RAG强约束、结论只能引用知识库、检索不到就坦白说不知道、低于置信度阈值直接给“建议线下就医”的模板回复。宁可回答得“笨”不能回答得“险”。7.2 多轮对话的状态错乱比想象中更容易出现真实用户不会按对话树走。前一秒说“我胃疼”后一秒又说“其实主要是右边小腹疼”系统必须识别这是症状修正而不是新增了一个症状。如果不处理最终结论可能同时包含胃炎和阑尾炎两个方向让用户不知所措。工程做法是在槽位层做覆盖确认当新症状实体与已确认实体冲突时自动发起“您刚才说的是胃疼现在说小腹疼以哪个为准”的确认。状态机设计时也要预留回退路径让用户随时可以回到上一步重新选择。7.3 大模型响应延迟和并发突刺会影响口碑上线首日如果遇到流量尖峰模型服务很容易慢到无法接受。一方面要做对话缓存常见症状组合和对应结论可以缓存大幅降低压力另一方面要对长响应做超时降级超过限定时间时先返回简短的安全提示而不是继续转圈。如果预算允许给模型服务单独做弹性扩缩容并预置一组更小的快模型流量高时优先用快模型跑分诊规则避免所有请求都挤在大模型上。7.4 运营侧投诉预案很多团队完全没准备技术团队容易忽略的是产品上线后一定会有投诉。不怕投诉怕的是没有预案。预案包含三层第一层是AI自动兜底话术凡是用户表达不满先回复“非常抱歉给您带来困扰您的问题已转交人工客服”第二层是客服后台能看到完整对话记录并一键生成投诉处理工单第三层是安全值班机制重大风险问题要能在一小时内通知到产品和医疗负责人。这个机制不需要多高级上线前演练一遍就行。我对AI问诊网站设计方案最大的体会是真正决定产品成败的不是模型选得多高级而是边界画得多清晰。把“什么不做”想明白了后面每个环节都会顺很多。最后再分享一个小技巧结论页里一定要加一个“依据”折叠区域把知识库来源放进去。这个设计既能缓解“AI不可信”的疑虑也能逼着团队把知识库质量做好。如果问诊质量闭环能稳定跑上三个月再考虑往在线复诊、随访、慢病管理这些方向扩展地基不会白费。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
