企业官网建设流程全解析

互联网医院的项目我前后跟过好几套，业务方每次提需求时几乎都会说同一句话：“能不能让AI先把问诊流程给接了？”坦白讲，这个问题的答案没有想象中简单。AI问诊系统开发不是把一个大模型对话接口怼到医生端就算完事，它牵扯到线上问诊链路怎么拆、数据怎么结构化、医生在哪里接管、合规边界在哪里，一环扣一环。这篇文章我会从实际做过的互联网医院项目出发，把AI问诊系统的应用场景、技术架构和落地方案掰开揉碎讲清楚，适合正在做线上问诊产品，或者准备从0到1搭建AI问诊模块的团队参考。

1. 线上问诊的瓶颈到底在哪：不解决“低效”问题，AI就没有位置

很多团队立项AI问诊时，第一反应是“我们要做一个能回答患者问题的智能助手”。这个出发点不算错，但它很容易把项目带入歧途。真正有价值的AI问诊，首先要回答一个更朴素的问题：互联网医院的线上问诊流程，到底慢在哪、累在哪、浪费在哪？

1.1 线上问诊和线下看病有着本质差异

线下门诊里，医生能看见患者，能观察到对方的气色、动作、语气，甚至能直接查体。线上问诊把这些信息全部切掉了，医生只能依赖患者自己敲出来的文字。可患者不是专业医学术语使用者，他们描述情况往往很随意——“胃那边不太舒服”“头昏昏的”“老是觉得累”，这类表述对医生来说信息密度太低，医生不得不反复追问。

我在其中一个项目里统计过，普通图文问诊的完整会话平均要经历7到10轮问答，其中有将近一半是医生在追问基础信息：症状持续多久了、之前有没有类似情况、有没有用药、有没有过敏史。整段对话看起来是有来有回，实际效率很低。医生一天能接的问诊量被这种重复劳动卡住了。

1.2 主链路拆解：从患者提交主诉到医生给出建议，中间全是被浪费的时间

把互联网医院的一次问诊拆开看，大致是这么一条链路：

患者进入问诊入口后，先选科室、选医生，然后填写主诉。主诉提交后，队列把订单推给医生端。医生看到的第一屏往往只有一行字，比如“最近总是咳嗽”，接下来他得在聊天窗口里一点一点问清楚。问完之后，医生结合患者既往史和已有资料，写病历、开具建议或处方，最后患者收到结论。

这个流程里有四个明显问题：主诉信息太单薄、双方需要多轮问答补齐信息、医生要手动把聊天内容整理成结构化病历、问诊结束后缺少自动化的随访触达。这些问题每一个都是AI能介入的点，但传统客服机器人式对话只能解决“多轮问答”的局部问题，其他三个同样需要单独设计的模块去承接。

1.3 适合AI介入的位置，以及不适合AI硬碰的位置

如果用一个表格来看，AI在问诊链路中的价值点其实很清晰：

我也碰到过一些团队想把“AI自动诊断”放在最前面，我通常建议别碰。当前技术条件下，AI可以做采集、分诊建议、病历整理、风险提醒，但最终诊断权必须留在有执业资质的医生手里。这个定位一定得在项目启动时就定死，否则后面所有技术方案都会跑偏。

2. 系统架构与技术选型：为什么我坚持用大模型+知识库，而不是纯规则

确定了AI的介入位置，接下来是技术选型。很多老项目的病根在于一开始选错了底座：有的用纯规则关键词匹配，有的用传统意图分类模型，上线后发现患者说话一自由就崩，维护成本高到吓人。我在近两年的项目里基本都转向“大模型对话底座 + 医学知识库”的架构，但它也不是无脑堆参数，配套模块缺一个都不行。

2.1 整体架构：一个可以落地的参考分层

从工程角度看，AI问诊系统可以分成四层，每一层解决一个明确的问题。

接入层负责对接互联网医院的小程序、App、H5，以及医生端工作站。对话引擎层负责多轮会话管理、意图识别、实体抽取和话术生成。业务服务层负责具体的问诊流程编排、病历生成、分诊计算和风险预警。数据层负责医学知识库、病历结构库、脱敏日志和运营反馈数据的存储。

业务服务层是最容易被忽视的一层。很多团队把大模型接进来就跑Demo，对话确实流畅，但没法挂到真实业务流程上。真实流程里必须要有状态机：当前患者在哪个问诊阶段、系统已经收集了哪些字段、还有哪些关键字段缺失、下一步该问什么，这些状态必须由业务服务层控制，不能全交给大模型自由发挥。

2.2 意图识别和实体抽取，和普通客服机器人不是一回事

普通客服机器人的意图识别，常见就是分几个类别：查订单、退换货、开发票。AI问诊系统要处理的是完全不同的问题——患者既有可能在描述症状，也可能在询问某种药的用法，还可能突然问一句“这个病严重吗”。同样一句话在不同语境下，答案完全不同。

我比较推荐的做法是三层意图体系。第一层判断“当前患者想做什么”，比如描述症状、补充病史、询问用药、表达焦虑。第二层做医学实体抽取，从自由文本里找出症状词、部位、时间、诱因、缓解因素。第三层判断“信息完整度”，结合当前问诊阶段和目标字段，决定继续追问还是结束采集。

实体抽取是硬骨头。患者说“右边脑袋一抽一抽地疼，已经三天了，昨天晚上睡觉的时候也疼醒过”，这句话里至少包含部位（右侧头部）、症状（搏动样疼痛）、持续时间（3天）、诱因或加重因素（夜间睡眠时）。靠规则去枚举是不可能的，必须让模型学会从医学实体库中进行关联识别。但医学实体库的构建和维护又是另一个大工程，不可能一步到位，通常是从高频症状开始，逐步做增量覆盖。

2.3 知识库和RAG：不把大模型的幻觉直接端给患者

大模型很聪明，但它也会一本正经地编造医学知识。AI问诊系统绝不能把这种未经校验的“自信”直接展示给患者，所以知识库必须成为对话的中枢，而不是装饰品。

我的做法是把知识库分成三个层级。第一层是权威公开信息，比如药品说明书、常见诊疗指南，这些内容要做结构化切分并建立索引。第二层是医院自有的问诊模板和历史脱敏病历中的典型问答对，用来让模型理解院内表达习惯。第三层是动态规则库，比如不同危险信号的触发词、分诊科室映射表、需要转急诊的紧急征象清单。

对话过程中，我先从患者语句中抽取关键医学实体，再到知识库里检索相关证据，最后把检索结果和对话上下文拼给大模型做生成。RAG不是万金油，但它的价值在于让大模型在生成回答的时候，有一个可以回溯的事实依据。哪怕最后生成的话术和检索结果不是逐字一致，至少能在日志里定位到依据来源，这对医疗场景非常重要。

2.4 和HIS、互联网医院平台的对接：顺序错了会返工

AI问诊不是独立系统，它必须嵌入到互联网医院的整套业务流里。我见过最闹心的案例是，AI预问诊做完了，结果数据结构跟医院HIS系统对不上，最后靠人肉复制粘贴把字段挪过去。

对接顺序建议这样走：先理清院内主数据，包括科室字典、医生排班、挂号类别，这些是分诊和队列的底层依赖；再定问诊业务表结构，预问诊收集的信息、医生补充的信息、最终病历信息，都要在同一套字段规范下流转；最后才做对话引擎的接口埋点。反过来做的项目，基本都要推倒重来。

接口调用要特别注意幂等。患者可能因为网络问题反复提交同一份预问诊结果，后端必须能识别重复请求，避免生成多条问诊记录。实践中我会给每次预问诊生成一个全局唯一的会话ID，接口层按会话ID做去重，核心状态用数据库事务保护，不能只依赖前端按钮置灰。

3. 我拆过的几个AI问诊应用场景：预问诊、分诊导诊、辅助接诊、智能随访

聊完架构，说几个我实际拆过的场景。这些场景不是凭空想的，都是业务方提出来、真实上线跑过的东西。每个的核心逻辑、技术要点和产出形态都不太一样，值得单独拆开看。

3.1 智能预问诊：把患者的“啰嗦话”变成结构化病历草稿

预问诊是AI问诊里落地最顺、投入产出比最高的功能，原因是它的目标非常聚焦。患者点开问诊入口后，AI先用一段自然的话引导患者描述不舒服的地方，然后按照标准问诊模板逐项补信息。

标准模板一般包括主诉、现病史、既往史、过敏史、用药信息。但要注意，不能把五个问题一次性全抛给患者，那样体验太像填表。我的做法是把问题拆成一条或多条对话路径：先收主诉，再根据主诉涉及的系统追问伴随症状，然后问时间线、既往史、用药情况，最后让患者确认一遍。

预问诊结束的产出是一份结构化病历草稿。比如患者说“最近两天一躺下就头晕，翻身的时候特别明显，还有点恶心想吐”，系统可以生成类似这样的结构：

{ "chief_complaint": "间断头晕恶心2天", "present_illness": { "symptom_list": [ {"symptom": "头晕", "trigger": "躺下/翻身时", "duration": "2天"}, {"symptom": "恶心", "relation": "伴随头晕发生"} ], "aggregation": "症状与体位变化相关" }, "past_history": "", "allergy_history": "", "medication_history": "", "risk_flags": [], "suggested_department": "神经内科", "status": "draft_ready" }

这份草稿直接进入医生端，医生可以在上面修改，而不是从零开始写。实际统计中，一个优秀的预问诊能把医生端问诊时长缩短三到五分钟，这个数字在线问诊场景里已经非常可观了。

3.2 分诊导诊：解决“患者自己选错科”的老大难

互联网医院最常见的用户路径，是患者先选科室再提交问诊。但医疗分诊本身是很专业的事，别说普通患者，很多医生换个科室也不一定能一次判断准。我见过“肚子疼”被挂到消化内科，结果最后是妇科问题的案例。

分诊导诊场景里，AI的目标不是给出“你得了什么病”，而是判断“你这次不舒服最可能对应哪个临床科室方向”。它要做的事是：先从患者主诉里抽取关键症状和相关部位，再对照“症状-科室”映射表得到候选科室，最后结合患者年龄、性别等上下文做一次排序。

这里有个细节坑：主诉里可能有多个症状，分属不同科室方向。比如“咳嗽伴胸闷”，呼吸内科和心血管内科都可能沾边。这种情况下不能武断给一个科室，要生成多个候选并按匹配度排序，同时把候诊理由也展示出来，让患者和后续接诊医生都看得明白。

3.3 辅助接诊：医生在会话中看不到的东西，AI帮忙盯着

辅助接诊是在医生端起作用的功能。医生在接诊时，AI不是替医生说话，而是实时把患者历史信息、风险评估、建议追问点推送到工作台旁边。

我做过的一个版本里，辅助接诊面板会显示三块内容。第一块是患者预问诊的结构化摘要，医生不用重新翻聊天记录。第二块是风险提示，比如患者提到“胸痛伴出汗”，系统会弹出高危预警，建议优先接诊或转线下急诊。第三块是建议追问项，根据患者已提供的信息，推荐医生补充询问哪些问题。

这个场景的AI不面向患者输出一句话，所以相对安全，但它对系统稳定性要求更高。医生工作台的中断会导致业务事故，因此这部分功能我一般做成独立服务，故障时自动降级，即使AI能力全部挂掉，医生的基础接诊流程也不能受影响。

3.4 智能随访：问诊结束后还有半程没跑完

问诊不是交付完建议就结束了，慢病和术后患者的后续状态跟踪，同样是互联网医院的核心场景。但这个场景以前高度依赖人工，护士拿着名单一个一个打电话，效率低，覆盖面也窄。

智能随访的做法是把随访表单、追问条件和提醒通知全部自动化。比如患者回答“最近血压控制得怎样”，AI根据预设的量表追问，得到结果后写回随访记录。如果患者反馈异常指标，系统立即触发人工复核工单。

这种场景里，AI扮演的不是医生，而是结构化数据采集器。它不负责判断病情好坏，只负责把患者自述的事实准确记录并推给对应角色。随访计划的规则要由业务人员和临床专家共同配置，不能由模型自己发挥。

4. 最难的一关：自由文本抽取和追问策略，怎么从“能聊”到“聊得对”

架构和场景都清楚了，但项目真正难的地方不在架构图上，而在那句“最近有点难受”背后藏着的若干种可能性。这是AI问诊系统落地时最磨人的环节，值得单独拿出一章讲。

4.1 患者说话方式的三个特征，决定了规则系统一定会失败

我梳理了上千条真实问诊对话记录，发现患者表达有几个典型特征，和结构化测试数据完全不一样。

第一，口语化严重，大量省略和替代。患者很少说“上腹部疼痛”，更常说“胃疼”或者“心口窝不舒服”。第二，时间线混乱。很多人是先说现在的感受，再说三天前的情况，然后又跳到去年的病史，顺序完全打乱。第三，包含无关情绪信息。患者会花大量篇幅描述自己的担心、害怕，或者周围人的看法，这些情绪信息对病情判断有参考价值，但结构上难以直接归类。

早先某项目组试图用关键词规则覆盖这些表达，结果规则库膨胀到数千条，还是不断被新说法突破。后来切换到模型方案后才明白，规则可以做兜底，但理解层必须交给模型。

4.2 结构化抽取的数据形态，比对话本身更重要

AI问诊系统的核心资产是结构化的医学信息字段。如果没有这个，大模型聊得再好，医生也不愿意用。抽取结果至少要包含以下维度：核心症状、症状部位、时间特征、严重程度、伴随症状、诱因、缓解因素、就诊经历、用药经历、既往史、过敏史、家族史。

每个维度都可能有多个值，所以要设计成数组而不是单字段。比如一个人同时头痛和恶心，就应当抽成两个症状节点，并尝试标记它们的关系是“伴发”还是“主诉+伴随”。

抽取结果同时要保留原始语句的引用，医生和系统日志随时可以回溯到患者原话。这一点在做风险审查时特别重要，不能只留结论没有依据。

4.3 追问策略：关键信息缺失时，不要一股脑全问

自由文本抽取做完之后，系统通常会发现病例模板里还有空字段。下一步就是决定要不要追问。这里的核心策略是分级追问，不是一口气把所有缺失项都抛给患者。

我把追问优先级分成三个等级。第一优先级是安全风险项，一旦涉及紧急信号，立即停止常规追问，直接提示人工介入。第二优先级是分诊必需项，比如症状持续时间、主要部位、是否首次发作，这些直接决定科室方向和接诊紧急程度。第三优先级是完善病历的补充项，比如家族史、生活习惯，这些可以在主要信息已经收齐后再问，甚至可以留给医生端。

追问时的措辞也很重要。不要说“请补充家族史”，那是表单系统的话。AI问诊应该自然地问：“家里人有没有类似的情况？”落到对话引擎里，就是根据当前缺失字段动态拼接问题模板，再结合上下文做一点润色。

4.4 一个全链路样例，把整个过程串起来

我举个实际常见的场景做演示。患者输入：“我这两天左边肋骨下面疼，一阵一阵的，尤其是吃完饭走几步路就开始疼。之前做过胆囊手术，不知道有没有关系。”

系统在这个会话里做的事情大致如下：先抽取主诉症状为“左侧季肋区疼痛”，性质为“阵发性”，诱因为“进食后活动”，既往史为“胆囊手术史”。因为涉及左季肋区疼痛与进食相关，分诊方向会同时考虑消化系统问题与外科术后相关问题。系统不会直接给“胆囊术后综合征”这类诊断性结论，而是把抽取结果和分诊候选提交到医生端。

同时，模型会生成一条追问：“疼痛会往其他地方串吗？有没有发烧或者恶心？”这个问题的作用是帮助区分疼痛性质，为医生提供更多线索。所有内容汇总成病历草稿后，由接诊医生校对后签名。这一套流程走下来，患者的原始输入、抽取后的结构化字段、模型生成的追问记录、医生最后的修改版本，全部留存可追溯。

5. 合规、隐私和临床兜底：安全不是上线后补的，而是设计出来的

AI问诊涉及医疗行为，这是它和普通AI客服最大的区别。系统做得再聪明，只要在安全设计上开了口子，就随时可能捅娄子。这块没有商量余地，只能从架构层面硬性兜底。

5.1 定位：AI是“采集助手”和“提醒助手”，不是“诊断医生”

整个AI问诊系统的话语体系都需要反复校准。AI可以引导采集信息，可以提示医生关注某类风险，可以在分诊层面给出参考方向，但绝对不能面向患者输出“你得了某病”“这个药你可以吃”这类确定性的诊断和用药结论。

我在项目中严格限定AI生成内容的两类话术。一类是信息收集类，比如“能再描述一下疼痛的具体位置吗”。另一类是通用知识类，比如“出现剧烈胸痛伴出汗时，应及时就医”这类基于常识的安全提醒。所有涉及个体判断的内容，全部只做内部参考，必须由医生审核后才能对外送达。

5.2 医生人工接管机制：一切自动化的终点都是人工确认

AI问诊无论多流畅，都要保证人工接管通道永远通畅。具体来说，预问诊阶段，如果患者明确表达“不想跟机器人说话”或连续两次答非所问，系统应当自动转入人工客服通道，而不是继续执拗地模型生成。

接诊阶段，AI生成的病历草稿、分诊建议、风险提示都只是提示卡片。医生有权一键清空重来，也可以局部修改。系统绝对不能在医生没有确认的情况下，把AI生成的病历自动归档成正式病历。

对于高危风险信号，系统还需要在问诊最前端设置一道硬闸门。比如检测到“胸痛且出冷汗”“意识模糊”“呼吸困难”这类文字时，不能等对话结束再提示，而是立刻中断常规流程，弹出紧急就医提示，同时通知平台客服人工关注。

5.3 隐私保护与数据脱敏：健康数据是最敏感的那一类

患者的问诊内容属于非常敏感的个人信息，互联网医院接入AI问诊后，数据流向会变得更复杂，隐私保护的颗粒度必须更细。基础工作是传输全链路加密、存储加密、权限分级和审计日志，但这些只是底线，实际上还要做到几个具体动作。

第一，尽量在模型调用层做数据最小化。提交给外部模型的文本中，把姓名、手机号、就诊号、家庭住址等身份字段剥离掉，只保留必要的医学描述。第二，日志中禁止记录明文的患者全名和联系方式，需要定位时用系统内脱敏ID关联。第三，敏感字段的访问要按角色拆分：医生看诊断相关信息，运营人员只能看统计聚合信息，研发人员在调试时看到的也必须是脱敏样例。

还要特别关注跨系统共享的边界。AI预问诊的结果要流向HIS、医生工作台和随访系统，每一个流转节点都要有独立的授权配置，不能图省事做一个全局可读权限。健康数据的访问记录也要可审计，监管要求回溯时能完整还原谁在什么时间看过什么。

5.4 输出风险控制与话术兜底：大模型生成的那句话，最后还得过一道闸

模型生成的内容，不管前面的RAG和知识库做得再好，都存在输出走偏的可能。所以我坚持在模型输出层加一道后置校验，哪怕只是简单的规则校验，也能拦住大部分明显问题。

校验规则分成三类。第一类是关键词规则，拦截诊断性词汇、绝对化承诺等敏感表达。第二类是逻辑校验，检测输出内容是否和患者实体抽取结果存在矛盾。第三类是知识库溯源校验，要求生成话术中涉及的医学结论能在知识库中找到对应依据，找不到就降级为通用话术。

同时，任何面向患者展示的AI生成内容，都要带一句统一的免责提示：“以上信息由AI辅助整理，仅供参考，不能替代医生诊断。”这不是多余的字，它既是合规要求，也是帮患者建立正确预期的基本操作。

6. 上线之后的迭代：从能运行到真正被医生依赖

很多AI问诊项目死在上线后。原因不是技术不先进，而是产品没人用。医生觉得改动不了、患者觉得回答不自然、运营团队不知道怎么迭代，最后整个模块变成摆设。要从“能运行”走到“被依赖”，靠的是上线后的反馈闭环。

6.1 冷启动：先让医生参与润色，而不是急着追求端到端自动化

AI问诊系统刚上线时，准确率一定是不达标的。这时候最忌讳的做法是把所有问题都抛给算法团队，然后等着下一轮模型训练。合理的方式是先设定一个较低的自动化目标，比如预问诊只做信息采集，医生端所有草稿仍需人工确认，但允许医生直接在草稿上修改。

修改记录就是最好的训练样本。我会把所有医生编辑过的病历草稿和AI原始生成版本做比对，抽取出医生改动的字段，把它们变成修正后的标准答案。冷启动阶段不需要标注团队大规模干活，只需要让系统聪明地收集“医生在哪里动了笔”。

6.2 用真实问诊记录不断修正，从错误里学反而更快

模型训练数据可以来自公开医学对话，但真实场景里的表达习惯是公开数据给不了的。上线后建议建一个持续反馈管道：每一条被医生修改的病历草稿，都回流到抽取和追问模块，作为修正样本。

还有一个容易被忽略的数据源是客服记录。患者的投诉和转人工原因，往往直接揭示了AI在哪些环节失败。比如如果大量患者反映“回答重复”，说明追问策略出了问题；如果医生反映“病历草稿里有一堆没用的信息”，说明抽取和陈列的优先级需要调整。

我建议把运营反馈分到两个池子。一个是“语气体验池”，收集患者反馈的非结构化问题，交给对话设计人员和模型调试人员去优化话术。另一个是“医学准确性池”，收集医生修改记录和高危风险误报，邀请相关科室的医生定期参与评估，定期修正知识库和抽取规则。

6.3 关注哪些指标：别只盯着“对话轮数”这种表面数字

AI问诊系统的效果评估，不能只看用户愿意聊几轮。我常用的指标体系分四个层面。第一层是业务效率指标，包括医生接诊平均时长、病历书写时长、分诊准确率。第二层是患者体验指标，包括预问诊完成率、投诉率、转人工率。第三层是医学安全指标，包括高风险信号识别率、风险漏报数、医生对草稿的修改频率。第四层是系统稳定指标，包括接口稳定性、模型调用时长、降级次数。

其中最需要盯紧的是“医生对AI输出的修改频率”。如果这个值长期很高，说明AI生成的内容虽然看起来自然，但实际没有对齐医生的临床习惯。这时候不能反复重训模型去硬凑，要先跑去跟医生聊清楚他们到底想要什么格式。

6.4 日常迭代节奏：小步快跑，但医疗功能要单独走审核通道

迭代节奏上，非医疗功能，比如话术优化、交互体验调整，可以按照互联网产品的小步快跑方式走，每周甚至每天发布。涉及医疗决策、分诊逻辑、知识库内容的改动，必须有更严格的审核流程。

建议在项目启动时就约定：哪些改动属于医疗相关改动，哪些属于纯体验改动。医疗相关改动要配置临床审核角色，每次上线前由具备对应资质的人确认。这个过程听起来比常规软件迭代“重”，但它恰好是AI问诊系统能长期稳定运行的保障。

我印象最深的一次，是某项目上线一个月后，模型把一个患者主诉里的“心跳快”错误抽成了“心悸”，然后分诊结果偏向心血管科，耽误了几分钟才被医生纠正。那之后，我们给“主诉关键词到标准医学词的映射”加了人工审核环节，所有高风险、高歧义的实体映射都必须有医生确认才能生效。虽然速度慢了一点，但后面没有再出过同类问题。AI问诊系统在互联网医院里最有价值的形态，不是替医生思考，而是变成一条更顺畅的信息流水线：患者说得更清楚，采集得更准确，医生看得更轻松，风险拦得更及时。把这条流水线真正打磨顺，比单独追求“模型多聪明”要重要得多。