企业官网建设流程全解析

最近“AI护士”这个词的热度涨得很快，短视频平台上甚至传出了“完蛋，我被AI护士包围了”的梗。但真点开产品之后你会发现，每个叫“AI护士”的东西做的是完全不同的事：有做智能问诊的，有做住院宣教的，有做用药提醒的，有做挂号导诊的，还有的只是套了一层语音外呼客服壳。这篇就把“AI护士”这个概念拆开，说清楚它到底能做什么、不能做什么，以及如果你是一个开发者，想自己快速搭一个能用的护理问答Demo，应该按什么顺序来做。

先给个结论：AI护士这个方向现在最值得关注的不是它会不会取代护士，而是它能不能在医疗资源的“非诊断环节”里帮人省时间。给什么科室、检查前能不能吃饭、出院后多久复查、药应该怎么存，这些事重复度高、信息相对标准，非常适合做成对话服务。而真正需要医生判断的部分，AI不应该碰。想清楚了这条边界，再去聊产品和技术才不会跑偏。

1. “AI护士”不是一个人，而是一堆产品和能力的总称

1.1 你遇见的“AI护士”，可能来自这几个场景

从我的实际体验来看，目前市场上挂“AI护士”名字的产品，基本落在五个场景里。

第一个是门诊前导诊。用户输入“咳嗽三天”“右边肚子疼”“孩子发烧到38度”这类描述，系统判断可能对应的科室，给出挂号建议。这类产品最常见，体验差异体现在能不能追问、能不能判断急症、能不能给出“立刻去医院急诊”的强提示。

第二个是住院健康宣教。患者在住院期间会有很多流程问题：明天手术几点不能吃饭、CT检查前要不要喝水、出院后伤口怎么护理。住院护士宣教业务量大，但内容高度标准化，很多医院已经把这部分做成知识库和对话机器人。

第三个是出院后随访。患者出院后，系统通过电话、短信或微信回访，问恢复情况、提醒复诊时间、记录异常反馈。这里往往不是单纯的聊天，而是带状态流转的任务系统，比如“随访完成”“需要人工介入”“已预约复诊”。

第四个是慢病管理。高血压、糖尿病这类长期健康管理场景，AI护士负责提醒用药、记录血糖血压、解释检测报告里的正常范围，并发现异常趋势后建议找医生复诊。

第五个是机构内部的员工健康助手。企业和体检机构会提供健康咨询服务，用户问体检指标、疫苗接种、常见营养问题，这类产品也经常叫“AI健康助手”或“AI护士”。

这五个场景的用户、渠道、技术栈都不一样。如果你把它们混在一起看，会觉得所有AI护士都差不多；实际上导诊看重科室映射准确，随访看重任务完整，慢病管理看重数据连续，内部助手看重安全合规，各有各的难点。

1.2 为什么都用“护士”而不是“医生”来命名

这一点很有意思。同样是AI医疗助手，很多产品宁可叫“AI护士”，也不叫“AI医生”。表面上是人设亲和力问题，本质上是能力边界和合规风险的问题。

医生角色的核心职责是诊断和治疗方案决策，这个风险极高，一旦出错就是医疗事故。而护士的核心职责是执行、观察、指导和流程协调，更多是“告诉你怎么做”“提醒你注意什么”，不直接决定“你是不是生了什么病”。用“护士”做产品人设，等于主动给自己划了一条安全线：我只做健康服务和流程引导，不做诊断结论。

这个定位直接影响技术方案。系统提示词里会不断强调“不提供诊断结论”“建议咨询线下医生”，回答里也会带免责话术。不是产品不想显得聪明，而是医疗场景的安全策略比能力展示优先级高得多。

1.3 用一张表快速区分不同形态

看完这张表就明白，想用一个模型解决所有场景是不现实的。每个场景的输入格式、输出格式、通过标准都不一样，技术选型也会不同。

2. 一个能用的AI护士，底层要同时处理这4类技术问题

2.1 意图识别：用户到底是要挂号、问药，还是投诉

不是所有输入都适合直接丢给大模型。用户可能说“护士在吗”，也可能说“我伤口疼怎么办”，还可能说“你们医院怎么这么难挂号”。如果只做关键词匹配，很容易把投诉当成医疗咨询。

我建议在对话最前面加一个轻量意图分诊。基于少量规则加一个分类模型，或者直接用大模型配合严格指令，先判断用户属于哪一类。分类可以做成简单几步：先判断是不是紧急症状；再判断是挂号、检查、用药、费用、住院流程还是投诉；最后决定是走知识库问答、转人工、还是触发线下就医强提醒。

这一步虽然看起来不复杂，但直接影响后续所有逻辑。意图分错，后面的任何优化都没有意义。

2.2 知识库检索：回答靠不靠谱，关键在知识来源

AI护士不能只靠大模型背知识。大模型虽然能记住很多医学通识，但医院自己的科室安排、医生出诊时间、病房规定、报销比例这些信息，模型并不知道，而且这些信息会变。

所以要做知识库检索。先把医院提供的科室介绍、宣教手册、FAQ、注意事项整理成文本片段，做向量化并存入向量数据库。用户提问时，先把问题转成向量，检索出最相关的片段，再连同问题一起交给大模型生成回答。

这里有个常见误区：知识库不是越大越好。小范围的、更新及时的知识库，加一些人工审核过的标准答案，效果比丢了一百个PDF进去要好。因为医疗知识对准确率要求高，检索不准时模型就会编造。初期建议控制在几百条到几千条，后续再慢慢扩。

2.3 话术生成：怎么说话才像护士，而不是像一个答题机器

同样一个回答，用不同提示词写出来，体验能差很多。比如“你这个情况应该挂呼吸内科”和“根据你的描述，建议您优先挂呼吸内科门诊，同时带上前几天做过的血常规检查结果给医生看”，后者明显更贴近护士的口吻。

话术生成可以通过系统提示词来约束。基本的角色设定可以包括：身份、职责边界、语气、是否需要追问、哪些话必须说、哪些话绝对不能说。如果想让回答更稳定，还可以给一两组少样本示例，把理想答案的样子直接给模型看。

需要注意一个地方：不要让提示词里的“关怀感”压过“准确性”。有的模型为了说话温柔，会把“需要立刻去急诊”说得模棱两可。所以在提示词里一定要写清楚：涉及急症时，必须使用强烈建议就医的表达，不允许安慰拖延。

2.4 渠道适配：小程序、App、电话外呼是完全不同的工程

很多团队做完一个对话接口，就想同时接到小程序、App和电话上，结果发现根本不是同一个产品。

在小程序里，对话可以一边流式输出一边展示卡片。用户能看到科室名称、挂号入口、注意事项列表，交互可以做得比较丰富。在App里，可能还要接用户档案，自动识别用户是哪个科室的患者。

到了电话外呼，场景就完全变了。语音交互需要ASR和TTS，用户说话可能带口音、有环境噪声，而且电话里不能展示文字卡片，所有信息只能靠语音播报。电话外呼的响应时间更严格，用户不能容忍每次回答都等三四秒。所以电话场景通常会把常用话术做成固定音频或提前生成好的静态回答，而不是每次实时调大模型。

渠道决定了架构，不是先把模型跑通再随便套渠道，而是先确认主渠道，再决定接口的流式、超时和消息格式。

3. 手把手搭一个“AI护士”Demo：从最简单开始

3.1 先准备环境和接口

想快速验证一个AI护士Demo，不需要自己训练模型，也不需要部署本地大模型。最稳妥的方式是接一个商用大模型API，先用最小代码跑通，再逐步加功能。

我这边的建议环境是：

• Python 3.9 或更高版本
• 一个支持OpenAI兼容接口的大模型API Key
• 一个本地的小型知识文件，比如医院科室列表和常见问题
• 基础依赖：openai、python-dotenv

先确认能正常调用API，再开始写业务逻辑。不要一上来就写几百行的聊天服务。

3.2 最小示例：用system prompt约束护士角色

下面的代码是一个兼容OpenAI接口的最小示例，只做一件事：让模型扮演护士，回答用户问题。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("YOUR_API_KEY"), base_url=os.getenv("API_BASE_URL") # 根据你的服务商配置 ) system_prompt = """ 你是一个医院门诊导诊助手，角色类似护士。 你的职责是根据用户的症状描述，建议用户可能需要的科室。 你必须遵循以下规则： 1. 不要给出任何诊断结论，比如“你这是感冒”或“你这是阑尾炎”。 2. 如果你认为症状可能属于急症，请立即建议用户前往急诊或拨打急救电话。 3. 回答要简洁，每条回复控制在100字以内。 4. 如果信息不足，可以追问一两个关键问题。 5. 结束回答时，加上一句“以上建议仅供参考，请以医生当面诊断为准。” """ messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": "我右边肚子疼，已经疼了半天了，我应该挂什么科？"} ] resp = client.chat.completions.create( model="your-model-name", # 以你的服务商实际模型名为准 messages=messages, temperature=0.3 ) print(resp.choices[0].message.content)

这个代码最核心的部分就是system prompt。我一般会先把prompt写好，单独测试十几条输入，再决定要不要继续加功能。

3.3 加入医院科室信息，让回答落到本地场景

模型不知道你所在医院的科室设置，也不知道发热门诊在什么位置。这时可以把知识片段拼到提示词里。

knowledge = """ 本院科室设置： - 呼吸内科：咳嗽、咳痰、胸闷、发热 - 消化内科：腹痛、腹泻、恶心、呕吐、反酸 - 心内科：胸痛、心悸、胸闷 - 神经内科：头痛、头晕、肢体麻木 - 急诊科：高热不退、剧烈疼痛、意识不清、严重外伤 """ content = f""" 请结合下面的院内信息回答用户问题。 院内信息： {knowledge} """ messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": content + "用户咨询：我右边肚子疼。"} ]

这种直接拼知识的方式只适合知识量很小的情况，大概几十条以内。知识条目一旦超过几十条，模型会忽略中间内容，这时就需要用向量检索，只把最相关的几条拼进去。

3.4 加上流式输出和基础对话历史

真实项目里，用户不喜欢一直等。流式输出能提升体验，哪怕只是逐字显示，也会让人觉得系统在思考。这里给一个流式调用的示例：

stream = client.chat.completions.create( model="your-model-name", messages=messages, temperature=0.3, stream=True ) for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="", flush=True)

对话历史也需要管理。不要每次把整段历史都丢给模型，因为历史越长，延迟越高，越容易超过上下文窗口。我建议只保留最近六到八轮，每轮都做长度截断。

如果做的是电话语音场景，历史记录还要考虑ASR的误识别。用户说“我不舒服”，被识别成“我不舒服吗”，这种错误如果进入历史，会让后续对话越来越偏。

4. 参数和验证标准：别只看“回答得像不像”

4.1 关键参数怎么调

很多人调AI护士，只盯着temperature，这是不够的。我实际调参时会重点关注下面这几个维度。

我通常的做法是先把temperature固定在0.2，其他参数用系统默认跑一轮，再看失败样例集中在哪。如果回答总是偏离知识库，优先检查知识库检索；如果回答太机械、像复读机，才考虑把temperature调高一点点。

4.2 验证回答质量时的判断标准

AI护士的回答质量，不能只看“用户觉得好不好”，更不能只看“句子通不通顺”。我一般按下面的优先级来判断：

1. 有没有输出。接口是否稳定返回，有无超时和空回复。
2. 是否越界。回答里有没有出现“你这是某某病”这类诊断结论。
3. 是否包含必要的安全提示。比如急症场景有没有提醒急诊。
4. 是否使用了准确的知识库。可不可以追溯到具体的科室或宣教条目。
5. 是否自然。语气是否接近护士，有没有明显机器腔。
6. 是否完成了业务目标。比如用户问挂什么科，是不是明确给出了科室名称。

如果前两条不满足，后面再好也要打回重做。

4.3 低配置环境能不能跑

如果你想在本地跑一个小模型，比如7B、13B参数级别的开源模型，也不是不行，但要做很多取舍。

显存是核心限制。7B模型量化后大概需要6GB左右显存，13B模型需要10GB以上，还要考虑输入长度和并发数。如果你的机器只是16GB内存、没有独立显卡，不建议直接本地推理，还是先调API更靠谱。

低配置环境下，不要一上来就跑最高质量的模型，也不要开太多并发。可以先设置单并发，用小批量测试。本地模型用于生产，还需要考虑吞吐量、队列、故障恢复，这个复杂度比调用API要高很多。如果只是学习，默认配置通常够用。

5. 从Demo到正式环境：还要补上这些工程细节

5.1 输入安全校验和内容兜底

AI护士的输入是自由文本，意味着用户可能输入各种内容：可能是突发急症描述，可能是负面情绪表达，也可能包含诱导模型给出诊断的恶意文本。这些都要在输入层做校验。

第一步是做长度限制。单条用户输入建议控制在200字以内，超出直接截断或提示用户精简。第二步是做风险词表。如果命中“割腕”“自杀”“大出血”等词，不要继续用日常话术，而是直接返回紧急求助信息和线下急诊建议。第三步是做模型输出检测。即使模型没有直接给诊断，也可能被用户套话输出不当内容，需要在输出侧做一次过滤。

这份兜底不是模型能解决的，必须做成独立的规则服务。

5.2 会话上下文和隐私边界

医疗场景对隐私要求极高。用户在对话里可能透露手机号、身份证号、疾病史、用药信息。这些信息不应该被当作普通聊天记录长期保存。

我的建议是：在进入大模型前做脱敏处理。把手机号、姓名、住址等用正则或实体识别替换成占位符；用户画像信息单独存储，不拼进对话上下文；日志里不要记录完整聊天内容，只记录脱敏后的片段和统计信息。

另外，会话记忆不要追求“永远记住”。很多健康咨询是一次性的，用户下次问同样的问题，系统不应该想当然地认为“上次他说过什么”。如果需要连续随访，就单独设计结构化字段，而不是全凭对话记忆。

5.3 日志、监控和用户反馈

Demo阶段可以不关心日志，正式环境必须关心。不是只看接口成功率，而是要记录更细的信息。

每条请求建议记录：输入长度、输出长度、token消耗、耗时、命中的知识库文档编号、是否触发风险规则、用户是否点击了“有帮助”按钮。这样才能发现模型在哪个环节开始胡说。

我见过一个案例：模型回答一直有延迟，但接口成功率是99%，后来查日志发现，延迟主要集中在长文本回答上。用户问一个简单挂号问题，模型却输出三百字，导致等待时间过长。这其实是提示词和max_tokens的问题，不改prompt只加服务器，解决不了根本。

6. 我实测时踩过的坑和排查顺序

6.1 现象一：模型一直复读“建议就医”

这种问题常出现在把安全提示写得过重的情况下。提示词里一旦频繁出现“不能诊断”“请就医”，模型就会变得极其保守，用户问“嗓子疼挂什么科”，它只回“建议您线下就医”，没有任何信息增量。

处理方式不是删安全提示，而是把“安全”和“有用”分开写。告诉模型：涉及急症必须强提醒；常见症状推荐科室时，可以正常给出具体建议，然后加一句“以医生诊断为准”。

6.2 现象二：回答引用了不存在的信息

模型可能会说“本院周六上午有王主任的专家门诊”，但医院并没有这条信息。这是典型的知识幻觉。

规避方法有两个。一是在检索结果不足时不回答，让模型输出“抱歉，这个信息本院暂时没有收录”；二是在回答后标注信息来源编号，例如“根据门诊排班规定（文档ID: 023）”。如果信息来自模型内部而非知识库，宁可不写。

6.3 现象三：批量测试时突然变慢

一次性提交几十条测试用例，每条都要检索、拼接、调用模型，如果并发设置过高，API服务会限流，出现大量超时。这时候先不要急着换模型，先降低并发数，再加指数退避重试。

测试时还要注意输入顺序。不要把所有类似症状的用例排在一起，否则你很难判断模型是记住了规则还是记住了上一句话。

6.4 我的统一排查链路

遇到AI护士相关的报错或异常回答，我一般按这个顺序排查：

1. 先看输入原文。是不是用户输入里有特殊符号、表情、电话号码，导致预处理出错。
2. 再看日志。确认请求是否到达模型接口，返回的status code和延迟是多少。
3. 再看提示词。是不是最近改过system prompt，导致风格或边界变化。
4. 再看知识库。命中了几条文档，检索结果和用户问题是否真正相关。
5. 再看参数。temperature和max_tokens是否被改得异常。
6. 最后才怀疑模型本身。

大多数问题都不是模型能力不够，而是前置输入、提示词和知识库没有处理干净。

7. 最后聊两句：被“AI护士”包围之后，我反而更安心了？

7.1 几个被问得最多的判断题

“AI护士能不能替代医生？”不能。至少在诊断、用药决策、手术判断这类关键环节，AI只能做辅助，责任主体必须是真人。技术上可以做得很像，但合规和责任承担完全不一样。

“AI护士能不能替代护士？”也不能。它能替代的是宣教、提醒、预约、回访这些重复性事务，但打针、换药、观察病情、处理突发情况，这些事不是对话系统能做的。

“AI护士适合从哪个场景切入？”我建议从信息标准化最高的场景切入。比如单科室的术前宣教，或者体检报告指标解释。越小越垂直，越容易做准。

7.2 我个人的建议

如果你被各种“AI护士”产品刷屏，想自己动手试一下，我建议先不要追求完整产品。第一步只是用一个API加一段护士角色prompt，跑通一轮问答。第二步加一个十几条知识的小文件，让它学会只有你这里有的信息。第三步再考虑流式、检索、语音渠道这些东西。

真正落地时，最该盯住的不是功能列表，而是三条线：输入是否安全、输出是否越界、知识是否准确。把这三条线守住，AI护士才有机会成为一个让人放心的助手。

被“AI护士包围”这件事，本质上说明医疗健康服务已经开始被大模型改造了。这个方向会一直有需求，但能走多稳，取决于我们每一个做产品、写代码的人，是否真的把安全边界放在了模型能力前面。