最近接了一个轻量级的医疗健康类小项目需求很明确把 DeepSeek 接进来做一个能陪用户聊症状、做初步分诊的 AI 智能问诊助手。这个方向最近特别热很多人都在问 deepseek 怎么做智能问诊、怎么调用 API、怎么处理多轮对话和流式输出。我整理了一下实际落地过程中的完整思路、代码实现和踩坑记录希望对准备做类似 AI 问诊、AI 客服、AI 辅助诊断场景的朋友有帮助。先说清楚一个边界所谓“智能问诊”本质上是利用大模型的医疗知识储备和对话能力帮用户做症状描述梳理、常见病初步判断、就医科室推荐和健康建议它不能替代医生诊断更不是远程医疗。我在整个系统里也做了明确的风险提示和兜底逻辑这块后面单独讲合规问题千万别抱着侥幸心理。1. 为什么选 DeepSeek 做问诊底座项目定位与选型思路1.1 智能问诊到底解决什么问题大部分线上问诊场景用户最烦的是“挂错科”和“描述不清”。小病小痛想查一下该看哪个科室、要不要去医院、有没有什么居家缓解办法搜出来的全是广告和“某某医院在线咨询”。智能问诊的核心价值就是把这一层拦住通过多轮对话引导用户把症状说清楚再给出一份结构化摘要和初步建议帮用户减少茫然感。这里要明确我们做的不是“让 AI 直接看病”而是“让 AI 变成一个懂分诊的对话助手”。它能做三件事收集症状信息、判断紧急程度、推荐就医路径。很多初学者一上来就想让模型输出“你可能得了某某病”这非常危险大模型幻觉本来就存在医疗场景下不能这么干。1.2 选型对比DeepSeek API 相比其他方案的取舍做这个项目之前我对比过几套方案自建开源模型、调用商业大模型 API、用专门医疗问答接口。考虑到时间成本和团队技术栈最后选了 DeepSeek 的 API。原因有几个。第一是中文医疗语料表现足够好。DeepSeek 在中文理解和生成上属于第一梯队对症状描述的解析、追问的合理性实测下来比某些通用英文模型可靠得多。第二是价格非常友好。问诊场景是多轮对话用户可能连续聊十几轮Token 消耗比普通问答大很多DeepSeek 的定价让这个模式在成本上跑得通。第三是接口兼容 OpenAI 格式改造成本极低很多现成的开源组件可以直接复用。也有人说本地部署 deepseek 更稳。我建议除非你的问诊系统要部署在完全内网环境、对数据有严格隔离要求否则直接走 API 更划算。本地部署小参数量模型问诊质量会明显下降部署满血版又需要多卡推理运维成本和响应延迟都会上来。做 MVP 阶段API 是最优解。2. 问诊系统整体架构从对话到“问诊记录”的闭环2.1 核心模块划分整个系统我拆成了四层接入层、会话层、规则层、存储层。接入层负责和 DeepSeek API 通信包括鉴权、流式接收、异常重试。会话层维护多轮对话的状态也就是把用户每次说的话、AI 每次的追问都拼接成上下文。规则层是最关键的它做三件事时间窗口校验、敏感词过滤、紧急情况拦截。存储层把每轮对话和最终问诊摘要落到数据库里方便用户后续查看和医生追踪。我见过不少项目把规则层省了让模型纯自由对话结果就是问诊经常跑偏。用户上一秒在说肚子疼下一秒就问到“你能写诗吗”模型也跟着跑了。有了规则层系统可以在关键节点把话题拉回问诊主线上。2.2 提示词工程让模型扮演合格的“首诊助手”问诊系统的灵魂在提示词。我第一次写的时候很糙就一句“你是医生助手请回答用户问题”结果模型回答得很随意有时候还直接给用药建议。后来把提示词重构成了带明确指令的版本效果立刻不一样。我用了三段式结构角色设定、行为约束、输出格式。角色设定里明确“你是分诊助手不是诊断医生”行为约束里写“只做症状采集和分析不给确诊结论不推荐具体药品遇到紧急情况立刻提示就医”输出格式里规定“每次回复不超过 120 字结尾必须给用户一个可选择的追问方向”。还有一个很实用的技巧把典型问诊流程写进 System Prompt。比如要求模型按“症状描述—持续时间—伴随症状—既往病史—最近生活状态”这个顺序追问每轮只问 1 到 2 个问题不要一次抛一堆。这样模型的行为会稳定很多不会出现东一榔头西一棒子的情况。2.3 状态机设计多轮问诊如何保证不跑偏多轮问诊最怕用户乱答。用户说“我肚子疼”模型问“持续多久了”用户回复“我今天吃了个西瓜”这种偏离就需要状态机兜底。我的做法是把问诊拆成几个阶段收集主诉、补充细节、风险评估、输出建议。在系统里用一个 status 字段标记当前阶段每次用户回复后先做意图判断。如果判断用户还在描述主要症状就继续留在当前阶段如果信息足够了就推进到下一阶段。这个状态判断不依赖模型用关键词和简单规则就能做大部分。举几个真实的判断规则出现“怎么办”“要不要去医院”时进入风险评估阶段出现“XX天了”“XX小时”时视为补充了病程信息出现“没”“没有了”“就这些”时视为结束当前阶段。规则和模型结合比单靠模型判断稳得多。3. 接入 DeepSeek 的实际操作API 调用与关键代码3.1 API 基础调用五分钟跑通第一个问诊对话DeepSeek 的接口地址和 OpenAI 兼容所以不需要额外封装太复杂的东西。下面这段代码是我在项目里实际用的调用函数。import os from openai import OpenAI client OpenAI( api_keyos.environ.get(DEEPSEEK_API_KEY), base_urlhttps://api.deepseek.com ) def chat(messages, temperature0.3): response client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperaturetemperature, max_tokens800, streamFalse ) return response.choices[0].message.contenttemperature 我刻意调到了 0.3。问诊场景要的是稳定和保守不是天马行空。温度太高模型容易给出一些听起来很专业但其实不严谨的表达温度太低回复会变得机械追问不够自然。0.3 是我在几十轮测试后觉得比较舒服的平衡点。messages 列表是标准的多轮对话结构。System Prompt 放在第一条用户每次输入追加一条 user 消息AI 每次回复追加一条 assistant 消息。这里有个容易踩的坑不要只传最近几轮而是要把系统提示词和早期症状描述一直保留在上下文里否则模型会忘记用户最开始说过的关键症状。3.2 流式输出与超时控制优化用户体验的关键如果问诊回复卡顿好几秒才一次性吐出来用户体验会非常差。医疗场景下用户可能本身就焦虑等太久会不断重发消息把上下文搞乱。所以生产环境我强烈建议开启流式输出。def chat_stream(messages): response client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.3, max_tokens800, streamTrue ) for chunk in response: if len(chunk.choices) 0 and chunk.choices[0].delta.content: yield chunk.choices[0].delta.content流式接口在循环里逐个返回内容片段前端用 SSEServer-Sent Events接收打字机一样展示出来。用户感受到的响应时间会从几秒缩短到几百毫秒这个提升非常直观。但流式也带来一个问题中断处理变复杂了。用户可能在 AI 输出一半时直接发来新消息这时候系统层面需要做并发控制最简单的做法是给每个会话加一把锁AI 未回复完之前不接收新输入或者直接丢弃新输入并提示“医生正在输入中请稍候”。超时控制更得做。我在网关层设置了 120 秒的总超时但实际业务里不能死等我会把 DeepSeek API 的超时设置为 60 秒超过 60 秒没返回就切换备用提示词告诉用户“当前咨询人数较多请稍后重试”并把这次请求的所有上下文缓存下来用户重试时可以无缝续聊。这个方案实测下来比硬等成功率高很多。3.3 结构化输出让模型返回可解析的 JSON问诊对话本身是自然语言但系统需要结构化的数据去做后续处理比如把“症状-持续时间-病史”抽取出来存库。我在提示词里要求模型在某些关键节点输出 JSON。collect_prompt 现在你已完成症状采集请以JSON格式输出当前问诊信息字段如下 {main_symptom: 主诉症状, duration: 持续时间, accompanying: 伴随症状, past_history: 既往病史, urgency: 紧急程度(低/中/高)} 只输出JSON不要输出其他内容。 这里有个典型问题模型偶尔会输出带 Markdown 代码块标记的 JSON直接 json.loads 会报错。我的处理办法是加一层容错解析函数先把 json 这种包裹剥掉再尝试解析解析失败就返回默认值并记录一条日志。日志这个细节很重要它能帮你发现哪些情况模型经常输出异常格式然后针对性地优化提示词。另外要提醒不要要求模型在每一轮对话都输出 JSON那样会干扰自然交流。只在问诊进入收尾阶段时通过一个独立的附加调用让模型做总结效果最好。多一次 API 调用的成本很低但稳定性提升很明显。4. 智能问诊里的“安全护栏”合规这件事不能省4.1 医疗免责声明与风险提示做 AI 问诊隐私和合规是绕不开的话题。我在做这个项目时第一件事不是写代码而是和需求方确认了三条红线不诊断、不处方、不承诺。所有 AI 输出内容都必须围绕这三条展开。UI 层和系统层都加了免责声明。UI 层在对话框上方固定展示“本服务为 AI 辅助分诊不构成医疗诊断如有不适请及时就医”。系统层在每次问诊开始时会在 Prompt 里注入一句“你只能提供健康建议不能确诊不能推荐处方药”。这个双重保障能让模型时刻记得自己的边界。我还加了一个紧急情况拦截机制。结合关键词和模型判断如果用户输入里出现“胸痛、呼吸困难、意识模糊、大出血、持续剧痛”这类高危急特征系统不经过模型直接返回“建议立即拨打 120 或前往急诊”并停止继续问诊。这类场景等不起多轮对话法律和道德层面都不是模型该处理的事情。4.2 内容过滤与兜底逻辑虽然 DeepSeek 本身有安全对齐但问诊场景涉及敏感词汇较多比如自杀倾向、家暴、心理危机等我仍然加了一层独立的内容过滤服务。这层不走大模型用关键词表和简单分类器实现。它的作用是双重的一方面拦截明显不合适的输入比如用户在测试时故意说一些诱导模型输出危险内容的话另一方面检测到心理危机相关词汇时会转接人工客服或展示公益援助信息。为什么不让模型做这件事因为大模型对模糊表达的判断不够稳定而且响应延迟偏高。关键词表虽然粗暴但胜在可解释、可快速迭代。我上线初期用了一个约 200 条的关键词表后续根据用户反馈逐步扩充。这里要特别强调问诊数据属于高度敏感数据存储必须加密。数据库连接要开 TLS用户敏感字段如姓名、电话号码做 AES 加密存储对话原文不保留超过留存期。云服务商如果提供医疗数据合规方案建议直接用别自己造轮子。5. 上线后的几个坑问题排查与性能调优实录5.1 上下文长度达到上限对话聊着聊着就断了DeepSeek 的上下文长度有限制问诊这种超长多轮对话很容易在十几轮后就触顶。用户正聊到关键病史突然收到报错“达到对话长度上限请开启新对话”体验非常崩。这其实是很多 calling API 的人都会遇到的问题。处理办法有两个。一是“截断保留”策略把上下文从最早的历史开始逐步压缩比如把前 5 轮对话无损保留再往前的对话用模型生成一段摘要替换原始内容。问诊场景下早期往往包含最关键的主诉所以我会把 System Prompt 里嘱托模型“在后续对话中先复述并确认用户的最早主诉”这样即使历史被压缩模型也能记得。二是给对话长度设置一道“软上限”。我在每次调用 API 前估算 messages 的总 Token 数超过阈值时主动触发问诊收尾流程让模型输出一份完整的问诊总结然后友好提示用户“本次咨询信息已完整记录你可以截图或下载”。这个做法比硬生生报错体面得多。5.2 并发飙升导致超时与限流上线后遇到一个非常实际的问题用户集中在晚上 8 点到 11 点问诊流量峰值一上来DeepSeek API 时不时超时偶尔还会返回限流错误。排查下来主要是两个原因大量并发请求没有做本地队列导致直连 API 的数量超过了服务端承受能力某些重试逻辑写得不好失败后立即重试反而加剧了拥堵。我的优化方案是在 API 调用外层加了本地限流和退避重试机制。限流采用线程池加信号量控制最大并发数重试则采用指数退避第一次失败等 1 秒第二次等 2 秒第三次等 4 秒超过 3 次就不重试了直接走降级话术。降级话术也不赖至少用户有个交代。还有一个容易被忽视的点流式接口的超时设置和普通接口不一样。普通接口等待首字节返回就行流式接口要额外判断 chunks 之间的间隔如果 30 秒内没有新的 chunk 返回应该主动断开。否则连接挂着用户看着界面卡住后台的线程也被白白占着。5.3 模型“一本正经胡说八道”幻觉怎么压问诊场景最让人头疼的是幻觉。模型在回答某些偏门问题时会一本正经地给出错误信息。有一次用户问“蚊虫叮咬后局部红肿怎么办”模型回复里居然冒出来一个具体药膏牌子的建议。虽然只是轻微医疗建议但这是红线绝不能允许。我这里做了三层防护。第一层提示词巅峰约束里明确禁止推荐任何具体药物如果必须给缓解建议只能说“冷敷”“保持清洁”这种不具备风险的非药物类建议。第二层输出内容过一遍药品名称库凡是命中常见药品名称的句子直接整段拦截不做展示。第三层针对高危科室相关内容比如肿瘤、心血管疾病直接强制转人工并告知用户“AI 无法处理此类场景”。药品名称库我维护了一个约 3000 词表来源是中英文药品词典过滤准确率非常高。这里有个取舍误杀很少但偶尔会把一些自然表达里的词当成药品名比如“阿司匹林”这种本来就是药品名被过滤是合理的但如果用户说“我听说打头孢不能喝酒”这句话里含有药品名但讲的是常识直接整段过滤会丢失信息。所以我做的是“句子级拦截”加“预警提示”而不是阻塞整个回复。命中药品库时前端会给用户看到一条系统消息“AI 回复中包含药品相关表述已隐藏如有疑问请咨询医师”。5.4 请求扩展准备失败一个容易被忽略的报错对话过程中偶尔会碰到一个报错英文是 request extension preparation failed中文直译“请求扩展准备失败”。我第一次遇到时以为是网络问题排查了大半天后来发现是请求上下文里带了某些特殊的 Unicode 字符或异常格式导致接口解析失败。这种情况多发于用户复制粘贴了一些特殊符号、网页上的乱码文字或包含非标准换行符的内容。解决办法是在发送前对用户输入做一次清洗把控制字符、零宽空格、异常空白符全部剥掉。清洗规则看着简单但对稳定性提升非常明显。后来我养成了习惯所有进入 API 的文本都过一遍清洗函数。import re def clean_input(text: str) - str: # 移除控制字符和异常空白符 text re.sub(r[\x00-\x08\x0b\x0c\x0e-\x1f\x7f], , text) # 移除零宽字符 text re.sub(r[\u200b-\u200f\u202a-\u202e\u2060], , text) # 统一换行 text text.replace(\r\n, \n).replace(\r, \n) return text.strip()这个函数虽然只有几行但它是项目上线后修复率最高的代码之一。很多用户反馈的“聊天突然失败”“AI 不回话”问题最后都定位到这里。6. 个人实践建议如果我现在重做一遍会怎么规划问诊系统做到第二个版本后我复盘整理了几条非常实际的经验现在分享出来。第一第一版不要贪多。别想着一次性把症状记录、报告解读、用药提醒全做了。先把“分诊、追问、输出问诊记录”这条线跑通模型能力不够的地方用规则补等用户反馈和数据积累够了再拓展功能。第二医疗场景的提问往往非常“跳跃”。用户可能一条消息说“头疼”下一条消息说“我妈说我小时候也这样”。不要试图让模型理解所有跳跃表达规则层需要识别这种偏离并重新引导用户回到问诊主线。我写了一个简单的兜底话术“关于这个问题我稍后回答我们先把刚才的症状聊清楚这对判断很重要。”第三问诊记录是最大的资产对话本身更是。把每一轮对话、用户点击、AI 回复、模型 token 消耗全部埋点记录你会惊讶地发现很多用户反馈和模型问题都能从日志里直接定位。但记得脱敏日志里不要存真实姓名、手机号等敏感信息。第四DeepSeek 的模型能力迭代速度很快API 的调用方式基本稳定但提示词层面值得定期优化。我每隔两周会把真实对话日志抽样拿回来人工标注那些 AI 回复质量差的 case然后针对性修复。这个工作看起来枯燥却是问诊效果提升最明显的一环。最后再分享一个小技巧治疗型问诊场景对“确定性”要求高我的经验是让 AI 在拿不准时明确说“我不确定建议问医生”而不是硬着头皮给答案。这一点写在 Prompt 里的效果远远好于事后兜底。实际使用中用户对“AI 承认不知道”的接受度比对“AI 胡猜”的接受度高得多还能降低平台风险。如果你也在做类似的 AI 问诊助手或者想把自己的业务通过 DeepSeek 实现智能化升级不妨按这个思路先搭一个最小闭环API 接入、提示词约束、状态机流转、风险拦截。把这四块跑通了后面加什么都只是锦上添花。