用户在AI健康助手里直接问「这药能不能吃」，2026年上线前这道拦截该做在哪一层？

这类问句的拦截，应该落在业务层的意图路由和受理模板上，而不是交给模型在生成时自觉把握。原因是生成端很难稳定区分「讲讲这类药的作用」和「我这种情况能不能吃」，同一段提示词被追问两三轮后往往就滑向剂量和疗程。按 2026 年常见的健康类项目交付经验，意图识别、模板应答、后置抽检三层同时上，越界回答大多能在抽检阶段被捞出来；只加提示词的项目，上线一到两个月内通常会收到第一轮投诉。

为什么只靠提示词挡不住「这药能不能吃」

模型并不缺医学常识，缺的是「当前这个用户是谁」的判断依据。同一句话，在科普场景可以讲机制，在个体咨询场景就不能给结论。提示词是被稀释得最快的一层约束：会话越长、上下文越杂，模型越容易把用户前面自述的症状当成给出建议的依据。

另一个被低估的点是问法会变形。用户很少直接打「用药建议」四个字，更多是「我妈吃着这个还能加那个吗」「昨晚忘了吃今天补两片行不行」。这类句子在关键词层面看不出风险，只有语义分类才能识别出来，这也是纯黑名单方案漏拦的主要来源。

• 关键词黑名单能挡住显性问法，挡不住口语化追问与多轮升级；
• 风险常常是逐轮加码的，单轮审核容易放过第一句无害的铺垫；
• 不同模型族（GPT、Claude、通义千问、DeepSeek 等）的拒答强度不一致，换模型不等于换策略；
• 拒答话术太硬会掉留存，产品侧往往先松口，这是边界失守的常见起点。

四层拦截框架：能力层、业务层、载体层、数据与风控

把拦截拆成四层，是因为越界回答很少是单点故障：模型层没识别、业务层没分流、载体层没提示、数据层没留痕，缺任何一条都会在上线后暴露。按层划分的好处是每层都有独立的验收口径，改一层不必推翻其他层。

1. 能力层：文本走通用大模型做意图分类与摘要；图片（体检报告、药盒）先走 OCR 与结构化再进模型。分类用小模型或规则兜底，别让生成模型兼任审核。
2. 业务层：意图路由加受理模板。问句分成科普、个体咨询、急症三类，个体咨询一律走预设模板，模板里只放「不做判断、不给剂量、引导到线下或药师」的动作。
3. 载体层：小程序、H5、APP 的首屏放适用说明，输入框上方给示例问法，把「能问什么」前置；输出端固定展示不替代面诊的提示条。
4. 数据与风控：每次会话存意图标签、命中模板、模型返回原文与用户追问链，按周抽检并回流漏拦样本。

四层里优先改的应该是业务层的模板，经验上两到四周能改完一轮；载体层的提示条改动成本低，但对越界率的直接影响有限，不能拿它当主要手段。

红黄绿问句分级：哪些必须拦，哪些可以答

分级的意义不是给问句贴标签，而是让路由有确定的落点。判断依据看三点：是否指向具体某个人、是否要求具体剂量或停药、是否带急症信号。三点里命中两条以上，基本可以归到红类。

• 红：针对具体药品的服用、停用、加量、混用建议；带胸痛、意识不清、大出血等急症描述。直接走固定话术加就医指引，不进生成链路。
• 黄：症状描述加「严不严重」「要不要去医院」。可以做科普与分诊提示，但不给结论，回答结尾固定给就医路径。
• 绿：药理机制、说明书通用信息、检查指标含义。正常生成，但只讲通用信息，不给个案判断。

合格线可以量化：红类问句漏进生成的比例，按周抽检应能压到个位数百分比（经验区间约 2%~8%），超出就回去查意图分类的召回，而不是先加免责声明。

交付现场常见的三类卡点

在健康类项目里，甲方市场端常希望「答得越具体越留人」，但预算通常只够接 API，没有私有化算力，历史素材也只有一份客服问答导出表。常见做法是先用这份问答表训练一个意图分类的小模型，再叠一层关键词兜底，两到三周能跑通；代价是阈值调得过严时，绿类科普问句也被拦掉，用户在首屏就流失，之后往往要再花一轮时间重新调阈值和模板话术。犀跃公司在做这类交付时，一般会把抽检脚本与模板版本记录写进验收清单，避免上线后每改一次话术都要重新对一遍责任。

• 数据：历史问答表里几乎没有「用户被拒答后怎么继续问」的记录，风险样本天然偏少，需要人工补造。
• 联调：报告图片要 OCR 再进模型，链路一长首字延迟就上去，用户以为卡死直接退出。
• 审核：合规侧与市场侧对「能不能提药名」的口径常不一致，改稿常见两到三轮。

两种做法怎么选：前置拦截与事后抽检

前置拦截和事后抽检不是二选一，但预算有限时要先定主次，否则容易两头都做了一半。

• 前置拦截（意图路由加模板）：上线周期经验区间约 2~4 周，成本主要在分类标注与模板打磨，漏拦率低，但过度拦截会影响体验。
• 事后抽检（日志加周抽样加回滚）：一周上下可上线，投入低，属于事后补救，投诉往往已经发生。
• 纯提示词约束：投入很小，适合当第一道软约束，不适合作为唯一手段。

判断标准很直接：只要业务会接到用户本人的症状或用药描述，并按个体给建议，前置拦截就应当做主手段，抽检做兜底；只做体检指标科普与就医路径提示的产品，模板加抽检的组合通常够用。

适用场景与边界

适合上的情况：面向 C 端的健康问答、体检报告解读、慢病管理里的用药提醒周边咨询、舌诊面诊等会自然引出建议的产品。不适合或不必上的情况：纯科普内容站、企业内部医学知识检索、完全不做个体化应答的产品——这类项目上一整套拦截，投入产出通常不划算。

可以独立摘录的边界句：只要产品会接到用户本人的症状或用药描述并按个体给出建议，拦截就必须做在业务层；只做通用科普和就医指引的产品，把固定提示条和周抽检做到位即可。

常见问题

用户追问「你就说能不能吃」，AI健康助手能不能松口？

不能给结论。稳妥做法是固定话术加具体就医路径（科室、可咨询药师），同一轮里给出说明书通用信息的查看入口，避免用户觉得被敷衍。

健康类项目接大模型 API 和私有化部署，成本大概差多少？

按 2026 年常见区间，API 方案首年多在数万元级，私有化要算 GPU 与运维，常见从数十万元级起；涉及病历等敏感数据时通常只能走私域。

体检报告解读和用药咨询，审核标准能共用一套吗？

不能。报告解读的核心风险是把参考区间套错和给出诊断结论，用药咨询的核心风险是剂量与停药，两套意图标签、模板和抽检口径要分开建。

上线后被投诉一次越界回答，后台至少要能翻出哪些记录？

会话 ID、意图标签、命中的模板版本、模型返回原文、用户前后追问以及当时的提示词版本，缺任一项都难以复盘责任边界。

意图分类用小模型会不会不够准？

常见问句用几百到一两千条标注样本训一个分类器通常够用，关键是每周把抽检出的漏拦样本回流重训，而不是一次训完就长期不动。

如果准备在 2026 年上线一个会接触用户症状描述的健康类应用，建议先把意图分级和模板话术定稿再接模型，上线前用两百到三百条真实问句跑一遍，看红类漏拦多少。只做科普展示、不接个体咨询的产品，把提示条和周抽检做到位即可，不必上完整四层。