医疗预约分诊案例：高风险场景先设计拒答和转人工

从一个上线事故说起

去年帮一个互联网医疗平台做分诊模块的 code review，他们的第一版直接把用户描述的症状丢给大模型，让模型返回「建议科室 + 可能疾病 + 注意事项」。产品经理验收的时候觉得挺好用——直到上线第三周，一个用户输入「胸口像被石头压着，出冷汗」，模型回复了「建议挂心内科，可能是胃食管反流」。

用户真的去挂了消化内科。后来家属投诉时才知道，那是一个急性冠脉综合征的典型表现，幸亏患者最后自己去了急诊。

这件事让我重新审视了医疗 AI 分诊系统的设计思路。问题不在模型不够聪明，而在于整个系统的边界没有画清楚——哪些事该做，哪些事不该做，哪些事做了反而会害死人。

这篇文章把我在几个医疗分诊项目中积累的经验整理出来，重点聊高风险场景下怎么设计拒答和转人工。

理论基础：医疗 AI 不是诊断系统

系统定位决定了功能边界

《互联网诊疗监管细则（试行）》（国卫办医发〔2022〕2 号）明确规定：人工智能软件等不得冒用、替代医师本人提供诊疗服务。2026 年发布的《医疗机构人工智能应用与治理专家共识》进一步要求，高风险场景必须单独签署知情同意书，且患者对 AI 建议有「一票否决权」——当患者质疑 AI 建议时，系统必须强制切换至人工服务。

这意味着医疗预约分诊系统的定位只能是：

1. 信息收集：结构化采集用户的症状、持续时间、既往史
2. 风险提示：识别红旗症状，触发紧急就医建议
3. 科室推荐：基于症状模式匹配推荐就诊科室
4. 预约引导：帮助用户完成挂号和排班选择

它不能做的事同样清楚：不能下诊断、不能开处方、不能替代医生判断。张文宏在 2026 年两会上讲得很直接：「临床医生作为最终决策者才能守住安全底线，普通患者不具备这种能力，极易因盲从 AI 导致误诊。」

The Lancet TRUST 框架

2025 年 The Lancet 提出了初级医疗 AI 部署的 TRUST 框架，包含五个维度：

这个框架很实用，因为它直接告诉你：分诊系统不是一个「问答机器人」，而是一个有严格边界、有人工兜底、有审计追踪的信息中介。

CLARITY 框架的三层安全模型

arXiv 上 2025 年发布的 CLARITY 论文提出了一个混合架构（FSM + LLM + 微服务），在 55,000 多次真实对话中验证。它的核心思路是把分诊安全拆成三层：

值得注意的是它的紧急检测器设计取舍：Precision 只有 0.72，Recall 只有 0.49，但 FPR 控制在 2% 以下。原因是「每一次警报都会触发值班医生审核，甚至可能导致救护车调度」。在约 7% 对话确实危急的部署场景中，更高的召回率会让警报量翻倍，直接压垮人工分诊资源。

这种「保守但可靠」的设计哲学，在医疗场景中比「激进但全面」更安全。

案例一：症状收集的「诱导陷阱」

场景

用户输入「我最近老是头疼」。系统需要追问细节来推荐科室。

翻车：引导性提问暗示诊断

# ❌ 坏做法：问题暗含诊断方向，诱导用户顺着回答
def collect_symptoms_bad(user_input: str) -> list[str]:
    questions = [
        "头疼的时候会不会恶心呕吐？",  # 暗示偏头痛
        "是不是太阳穴两边跳着疼？",       # 暗示血管性头痛
        "有没有视力模糊？",               # 暗示颅内高压
    ]
    return questions

这段代码的问题在于：每个问题都预设了一个诊断方向。用户本来只是紧张性头痛，被连续追问恶心、跳疼、视力模糊之后，很可能「配合」地回答是，导致系统误判。

CLARITY 论文把这叫做「碎片化、不一致的对话」——模型在多轮问诊中容易生成过于简化的回复，无法像医生一样遵循逻辑化的问诊序列。

修复：开放式追问 + 结构化字段采集

# ✅ 好做法：先开放式追问，再用结构化表单采集关键字段
def collect_symptoms_good(user_input: str) -> dict:
    # 第一轮：开放式追问，不带诊断暗示
    open_questions = [
        "能描述一下头疼的具体位置吗？",
        "大概什么时候开始的？持续多久了？",
        "除了头疼，还有其他不舒服吗？",
    ]
 
    # 第二轮：结构化采集（用户主动填写，非引导）
    structured_fields = {
        "location": None,      # 部位（额部/颞部/枕部/全头）
        "duration": None,      # 持续时间
        "severity": None,      # 疼痛等级 1-10
        "onset": None,         # 起病方式（突然/逐渐）
        "aggravating": None,   # 加重因素
        "relieving": None,     # 缓解因素
        "associated": [],      # 伴随症状（多选）
    }
 
    return {
        "open_questions": open_questions,
        "structured_fields": structured_fields,
    }

开放式追问让用户用自己的语言描述，结构化表单把信息约束在可处理的字段里。两步配合，既避免了诱导，又拿到了后续分诊需要的数据。

对比

案例二：红旗检测与紧急升级

场景

用户在对话中提到「胸口闷，喘不上气，左胳膊也发麻」。这是典型的急性冠脉综合征表现，需要立即触发紧急升级。

翻车：模型把红旗症状当普通咨询处理

# ❌ 坏做法：把症状直接丢给 LLM，让它「自由发挥」
def triage_bad(symptoms: str) -> str:
    prompt = f"""
    用户描述了以下症状：{symptoms}
    请推荐适合的科室，并给出注意事项。
    """
    return llm.generate(prompt)
    # 可能返回：「建议挂心内科或骨科，注意休息」
    # 完全忽略了紧急程度

这种写法有两个致命问题：一是模型可能不识别紧急症状组合，二是即使识别了，也没有机制强制输出紧急提示而不是常规建议。CLARITY 论文的测试显示，现有 LLM 在「区分时间敏感症状与非紧急症状」方面表现很差，尤其是在症状描述不够标准的时候。

修复：规则前置 + 模型辅助 + 强制升级

# ✅ 好做法：先用确定性规则检测红旗，再决定是否继续走模型
RED_FLAG_KEYWORDS = {
    "cardiac": ["胸痛", "胸闷", "左臂疼痛", "出冷汗", "呼吸困难"],
    "stroke": ["口角歪斜", "肢体无力", "言语不清", "突发眩晕"],
    "anaphylaxis": ["严重过敏", "喉头水肿", "全身荨麻疹", "呼吸困难"],
    "consciousness": ["意识模糊", "晕厥", "抽搐", "呼之不应"],
}
 
def detect_red_flags(text: str) -> list[str]:
    """确定性红旗检测，不依赖模型"""
    flags = []
    for category, keywords in RED_FLAG_KEYWORDS.items():
        if any(kw in text for kw in keywords):
            flags.append(category)
    return flags
 
def triage_with_escalation(user_input: str) -> dict:
    # 第一步：确定性红旗检测
    red_flags = detect_red_flags(user_input)
 
    if red_flags:
        # 触发紧急升级协议，不走模型
        return {
            "action": "EMERGENCY_ESCALATION",
            "flags": red_flags,
            "message": (
                "您描述的症状可能需要紧急医疗处理。"
                "请立即拨打 120 或前往最近的急诊科。"
                "在等待救援期间请保持安静，不要自行驾车。"
            ),
            "log_level": "CRITICAL",
        }
 
    # 第二步：无红旗时才走常规分诊流程
    return regular_triage(user_input)

关键设计点：

1. 红旗检测用确定性规则，不用模型。关键词匹配看起来「笨」，但它的行为是完全可预测的。在医疗场景中，可预测比聪明更重要。
2. 紧急升级是一个硬分支，不走模型的「建议」路径。模型永远不会有机会输出「建议注意休息」这种废话。
3. 日志级别标记为 CRITICAL，便于事后审计。

CLARITY 的实际数据参考

CLARITY 框架的紧急检测器用了更精细的混合方案（TF-IDF + 关键词独热编码 + LLM 二元判断 + 梯度提升分类器），在真实部署中的表现：

对于大多数项目来说，关键词规则 + LLM 辅助判断的两层方案已经够用。如果部署量大、安全要求高，可以参考 CLARITY 的多特征融合方案。

案例三：转人工机制的设计

场景

系统推荐了科室，但用户追问「我这个情况严重吗？会不会是癌症？」。这类问题涉及预后判断和诊断确认，超出了分诊系统的职责范围。

翻车：模型硬答超出能力边界的问题

# ❌ 坏做法：模型强行回答诊断和预后问题
def handle_followup_bad(question: str, context: dict) -> str:
    prompt = f"""
    用户追问：{question}
    之前的分诊信息：{context}
    请回答用户的问题。
    """
    return llm.generate(prompt)
    # 可能返回：「根据您描述的症状，癌症的可能性不大，
    #            但建议做进一步检查排除。」
    # 系统无权做出这种判断

模型给出的「可能性不大」会让用户信以为真。如果真的有早期病变，用户可能因此拖延就医。

修复：识别越界问题，主动转人工

# ✅ 好做法：定义越界问题类型，命中后直接转人工
OUT_OF_SCOPE_PATTERNS = [
    r"(是不是|会不会|可能是).*(癌|肿瘤|恶性)",
    r"(能治好吗|预后|生存率|存活率)",
    r"(吃什么药|用什么药|剂量)",
    r"(确诊|确定是|到底什么病)",
]
 
def is_out_of_scope(question: str) -> bool:
    """判断问题是否超出分诊系统职责"""
    return any(
        re.search(pattern, question)
        for pattern in OUT_OF_SCOPE_PATTERNS
    )
 
def handle_followup_good(question: str, context: dict) -> dict:
    if is_out_of_scope(question):
        return {
            "action": "TRANSFER_TO_HUMAN",
            "reason": "out_of_scope_question",
            "message": (
                "这个问题需要医生根据您的具体情况来判断。"
                "我帮您转接人工客服，可以协助您预约相关科室的医生。"
            ),
            # 把之前的对话摘要一起传给人工，减少重复沟通
            "context_summary": summarize_context(context),
        }
 
    # 范围内的追问（如科室具体位置、挂号流程）可以回答
    return answer_logistical_question(question)

对比

系统整体架构

把上面三个案例串起来，一个相对完整的医疗分诊系统架构如下：

这个流程的核心原则是：每一步都有「退出到人工」的路径，没有任何一个分支是模型单独走完整个诊断过程的。

关键设计决策对比

架构选型

拒答策略对比

转人工触发条件

日志与审计

上线前检查清单

需求与设计阶段

• 明确系统定位文档：只负责信息收集、风险提示、科室推荐，不涉及诊断和处方
• 列出所有拒答场景清单，经医学顾问审核签字
• 定义红旗症状列表，覆盖心梗、脑卒中、严重过敏、急性腹痛等至少 20 种紧急情况
• 设计转人工的完整路径，确保每个对话分支都有「出口」
• 确认患者知情同意流程，高风险场景单独签署同意书

开发与测试阶段

• 红旗检测使用确定性规则（关键词/正则），不依赖模型
• 紧急升级是硬分支，模型无法覆盖或跳过
• 结构化信息采集不包含引导性问题
• 越界问题检测覆盖诊断确认、预后判断、用药建议三大类
• 用至少 500 条历史急诊病历做红旗检测回归测试，召回率 ≥ 95%
• 对抗性测试：故意输入模糊描述、矛盾信息、非医疗话题，验证系统不误判

上线与运维阶段

• 所有分诊决策写入审计日志，包含用户输入、规则命中、模型输出、人工介入
• 建立模型版本管理和配置回滚机制
• 设置性能监控仪表板：红旗触发率、转人工率、用户满意度
• 每月复盘转人工对话，提取 bad case 补充规则库
• 定期开展公平性测试，按年龄、性别、地区分层检查分诊准确率差异

小结

做医疗分诊系统最反直觉的一点是：最有价值的设计不是「系统能做什么」，而是「系统不做什么」。

拒答不是能力不足，而是边界清晰。转人工不是系统失败，而是安全兜底。

The Lancet 的 TRUST 框架和 CLARITY 的三层安全模型，本质上都在解决同一个问题：怎么让一个「什么都能说」的 AI，在一个「说错了会出人命」的场景里，只说该说的话。

如果你正在做类似系统，我建议先画一张图：把所有可能的对话路径画出来，然后逐一检查每条路径的终点——是安全出口，还是悬崖。

参考资料

1. The Lancet Primary Care — Artificial intelligence in primary care: frameworks, challenges, and recommendations (TRUST Framework, 2025). https://www.thelancet.com/journals/lanprc/article/PIIS3050-5143(25)00079-2/fulltext

2. arXiv — CLARITY: Clinical Assistant for Routing, Inference, and Triage (2025). https://arxiv.org/html/2510.02463v2

3. PMC/NIH — AI Triage in Primary Care: Building Safer and More Equitable Real-World Systems. https://pmc.ncbi.nlm.nih.gov/articles/PMC13000377/

4. 《互联网诊疗监管细则（试行）》（国卫办医发〔2022〕2 号）. https://www.nhc.gov.cn/yzygj/s3594q/202203/b29c8b6b3f8b4ddc8b3e3a9f6f5e7c8a.shtml

5. Censinet — The AI Policy Playbook: Essential Guardrails for Healthcare Innovation (2026). https://censinet.com/perspectives/ai-policy-playbook-essential-guardrails-healthcare-innovation

6. ECRI — Artificial Intelligence Tops 2025 Health Technology Hazards List. https://home.ecri.org/blogs/ecri-news/artificial-intelligence-tops-2025-health-technology-hazards-list

7. 科学网 — 张文宏委员谈AI问诊：仅靠AI有风险 (2026). https://news.sciencenet.cn/htmlnews/2026/3/561044.shtm

8. 知乎 — 逐条拆解《医疗机构人工智能应用与治理专家共识（2026版）》. https://zhuanlan.zhihu.com/p/2027318051566098339