最近“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 用一张表快速区分不同形态产品形态典型输入典型输出核心技术重点门诊导诊“咳嗽两天有痰”推荐呼吸内科提醒带好病历科室映射、急症识别住院宣教“明天手术能喝水吗”按科室规则说明禁食禁水时间结构化知识库、流程判断出院随访电话接通确认恢复状态发起复诊提醒或人工介入工单任务状态机、语音交互慢病管理“今天的空腹血糖6.1”记录数值并提示正常范围数据解析、异常检测员工健康助手“体检报告尿酸偏高”解释指标含义建议饮食注意知识库、安全兜底看完这张表就明白想用一个模型解决所有场景是不现实的。每个场景的输入格式、输出格式、通过标准都不一样技术选型也会不同。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_keyos.getenv(YOUR_API_KEY), base_urlos.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( modelyour-model-name, # 以你的服务商实际模型名为准 messagesmessages, temperature0.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( modelyour-model-name, messagesmessages, temperature0.3, streamTrue ) for chunk in stream: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end, flushTrue)对话历史也需要管理。不要每次把整段历史都丢给模型因为历史越长延迟越高越容易超过上下文窗口。我建议只保留最近六到八轮每轮都做长度截断。如果做的是电话语音场景历史记录还要考虑ASR的误识别。用户说“我不舒服”被识别成“我不舒服吗”这种错误如果进入历史会让后续对话越来越偏。4. 参数和验证标准别只看“回答得像不像”4.1 关键参数怎么调很多人调AI护士只盯着temperature这是不够的。我实际调参时会重点关注下面这几个维度。参数作用一般建议temperature控制确定性和随机性值越低越保守医疗场景建议0.1到0.3top_p核采样和temperature配合使用建议0.8到0.9不要同时调两个上限max_tokens控制回答长度导诊建议200到500宣教解释可以更长stop定义停止标记防止模型继续输出可以设置结束符也可以不设system prompt定义角色、边界、必须输出的免责话术每次必须单独审计历史轮数控制上下文量建议6到8轮超出丢弃我通常的做法是先把temperature固定在0.2其他参数用系统默认跑一轮再看失败样例集中在哪。如果回答总是偏离知识库优先检查知识库检索如果回答太机械、像复读机才考虑把temperature调高一点点。4.2 验证回答质量时的判断标准AI护士的回答质量不能只看“用户觉得好不好”更不能只看“句子通不通顺”。我一般按下面的优先级来判断有没有输出。接口是否稳定返回有无超时和空回复。是否越界。回答里有没有出现“你这是某某病”这类诊断结论。是否包含必要的安全提示。比如急症场景有没有提醒急诊。是否使用了准确的知识库。可不可以追溯到具体的科室或宣教条目。是否自然。语气是否接近护士有没有明显机器腔。是否完成了业务目标。比如用户问挂什么科是不是明确给出了科室名称。如果前两条不满足后面再好也要打回重做。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护士相关的报错或异常回答我一般按这个顺序排查先看输入原文。是不是用户输入里有特殊符号、表情、电话号码导致预处理出错。再看日志。确认请求是否到达模型接口返回的status code和延迟是多少。再看提示词。是不是最近改过system prompt导致风格或边界变化。再看知识库。命中了几条文档检索结果和用户问题是否真正相关。再看参数。temperature和max_tokens是否被改得异常。最后才怀疑模型本身。大多数问题都不是模型能力不够而是前置输入、提示词和知识库没有处理干净。7. 最后聊两句被“AI护士”包围之后我反而更安心了7.1 几个被问得最多的判断题“AI护士能不能替代医生”不能。至少在诊断、用药决策、手术判断这类关键环节AI只能做辅助责任主体必须是真人。技术上可以做得很像但合规和责任承担完全不一样。“AI护士能不能替代护士”也不能。它能替代的是宣教、提醒、预约、回访这些重复性事务但打针、换药、观察病情、处理突发情况这些事不是对话系统能做的。“AI护士适合从哪个场景切入”我建议从信息标准化最高的场景切入。比如单科室的术前宣教或者体检报告指标解释。越小越垂直越容易做准。7.2 我个人的建议如果你被各种“AI护士”产品刷屏想自己动手试一下我建议先不要追求完整产品。第一步只是用一个API加一段护士角色prompt跑通一轮问答。第二步加一个十几条知识的小文件让它学会只有你这里有的信息。第三步再考虑流式、检索、语音渠道这些东西。真正落地时最该盯住的不是功能列表而是三条线输入是否安全、输出是否越界、知识是否准确。把这三条线守住AI护士才有机会成为一个让人放心的助手。被“AI护士包围”这件事本质上说明医疗健康服务已经开始被大模型改造了。这个方向会一直有需求但能走多稳取决于我们每一个做产品、写代码的人是否真的把安全边界放在了模型能力前面。