晚上十一点，家里老人突然发热咳嗽，要不要直接冲急诊？很多人都有过这种纠结。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不可信”的疑虑，也能逼着团队把知识库质量做好。如果问诊质量闭环能稳定跑上三个月，再考虑往在线复诊、随访、慢病管理这些方向扩展，地基不会白费。
